Two related PRs for review please. This allows us to use more recent versions of the datadog lambda forwader: • https://github.com/cloudposse-terraform-components/aws-datadog-credentials/pull/69 • https://github.com/cloudposse-terraform-components/aws-datadog-lambda-forwarder/pull/103

Looks like we don't have sufficient tests to validate the provider pinning or not. These are working for you locally?

Applied the change in our dev account and I haven’t seen any issues. Logs are still being forwarded from multiple sources (lambda, cloudwatch, and s3)

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.datadog_lambda_forwarder.aws_lambda_function.forwarder_log[0] will be updated in-place
  ~ resource "aws_lambda_function" "forwarder_log" {
      ~ architectures                  = [
          - "x86_64",
          + "arm64",
        ]
        id                             = "foo-plat-usw2-dev-datadog-lambda-forwarder-logs"
      ~ last_modified                  = "2026-03-28T16:23:55.000+0000" -> (known after apply)
      ~ runtime                        = "python3.11" -> "python3.14"
      ~ source_code_hash               = "8d3CkzwS8iZZ1cZAqg/oyl7bqvpWJuVUDLHedk9jXLw=" -> "6Itxx32eGAnSeMYys2kprv16mgrQXHR2jAFtphAaKVs="
        tags                           = {
            "Attributes"  = "logs"
        }
        # (22 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

I also added a local override to pass in the arm64 architecture. I can push that same into my PR, but that felt a bit out of scope

Thanks, I escalated to @Igor Rodionov to merge

Thanks for the merges @Igor Rodionov. I think we now need to set an upper bound on the datadog provider. Their recently released v4 changed a lot.

│ Error: Invalid resource type
│
│   on <http://main.tf|main.tf> line 92, in resource "datadog_integration_aws_lambda_arn" "rds_collector":
│   92: resource "datadog_integration_aws_lambda_arn" "rds_collector" {
│
│ The provider datadog/datadog does not support resource type
│ "datadog_integration_aws_lambda_arn".
╵
╷
│ Error: Invalid resource type
│
│   on <http://main.tf|main.tf> line 99, in resource "datadog_integration_aws_lambda_arn" "vpc_logs_collector":
│   99: resource "datadog_integration_aws_lambda_arn" "vpc_logs_collector" {
│
│ The provider datadog/datadog does not support resource type
│ "datadog_integration_aws_lambda_arn".
╵
╷
│ Error: Invalid resource type
│
│   on <http://main.tf|main.tf> line 106, in resource "datadog_integration_aws_lambda_arn" "log_collector":
│  106: resource "datadog_integration_aws_lambda_arn" "log_collector" {
│
│ The provider datadog/datadog does not support resource type
│ "datadog_integration_aws_lambda_arn".
╵
╷
│ Error: Invalid resource type
│
│   on <http://main.tf|main.tf> line 113, in resource "datadog_integration_aws_log_collection" "main":
│  113: resource "datadog_integration_aws_log_collection" "main" {
│
│ The provider datadog/datadog does not support resource type
│ "datadog_integration_aws_log_collection".

Setting the upper bound on the component comes back clean for me

@david merged.

plans are looking good. I’m going to let these workflows apply and monitor

Great, glad we were able to get a release cut. Thanks for the contribution.

unsure if you have any other work around getting the DD provider updated to v4, but it’s something I’ll probably tackle soonish

Unfortunately not much... We've been doing a bit more work with AWS Managed Prometheus/Grafana, due to Datadog costs.

fair 💸

@Michael ☝️ Any updates you have not upstreamed yet? 😃

yeah, that would be pretty nice. Especially around syncing components that lack variables the underlying modules support

We ran into some issues with deprecated resources disappearing and ended up hard pinning our local components like this. No updates since sadly