[Bug]: AWS pipes set container override memory by default to 0

[Azmah-Bad]

Terraform Core Version

1.9.6

AWS Provider Version

5.73.0

Affected Resource(s)

• aws_pipes_pipe

Expected Behavior

When creating an AWS Eventbridge Pipe with an ECS task as target that has container_overrides terraform sets explicitly the Memory field even if in the container override to 0 even if the user didn't set it explicitly in his configuration or set it to null

Actual Behavior

The Memory field is set to 0, causing the ECS task to crash due to "unknown error". but if the Memory field was omitted it wouldn't have crashed.

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

resource "aws_pipes_pipe" "jobs" {
  name     = "xxx"
  source   = aws_sqs_queue.trigger_job.arn
  target   = aws_ecs_cluster.cluster.arn
  role_arn = aws_iam_role.pipe.arn

  source_parameters {
    sqs_queue_parameters {
      batch_size = 1
    }
  }

  enrichment = aws_lambda_function.enrichment.arn
  target_parameters {
    ecs_task_parameters {
      task_count          = 1
      launch_type         = "FARGATE"
      platform_version = "1.4.0" 
      task_definition_arn = aws_ecs_task_definition.task.arn_without_revision
      propagate_tags      = "TASK_DEFINITION"
      network_configuration {
        aws_vpc_configuration {
          subnets = var.network.subnets
          security_groups = [aws_security_group.ecs_task.id]
        }
      }
      overrides {
        cpu    = "$.cpu" 
        memory = "$.memory"
        container_override {
          name   = "jobs"
          // memory = 0 even if not set terraform will set it to 0 and not omit it from the config 

Steps to Reproduce

1. create an SQS queue / ECS Cluster (with a basic task definition with a 1 container)
2. create an AWS Pipes that reads the messages from SQS and trigger an ECS task in the cluster created above
3. in the target settings of the pipe override the container's env variables
4. Terraform will also set the Memory field to 0 even if it's not explicitly set (even if it's set to null, terraform will still set it to 0)

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[nickjoanis]

Since the current AWS provider has limitations with EventBridge Pipes configuration (especially with ECS targets requiring container overrides), I've implemented a functional workaround that might help others.

The approach:

1. Creates the pipe initially through normal Terraform resources
2. Uses AWS CLI (via null_resource) to update the pipe with the complex configuration
3. Ensures the update happens after each Terraform apply when dependencies change

The critical benefit of this workaround is that you end up with the same overrides that the module would create but without the Memory:0 and CPU:0 values that the provider currently sets, which prevent Fargate containers from starting. This allows your ECS tasks to launch properly while still maintaining infrastructure-as-code principles.

Hopefully this helps until the issue is fixed!