ECS

Some things people ask the terraform-aws-modules/ecs/aws module for cannot be implemented by any module, in any registry: they are limits of Terraform and OpenTofu themselves. This page is for engineers who hit one of them. For each it says what causes it, gives the native workaround in full, and, where one exists, shows the Operational Rule that removes the need for a fork. Read the native option first; several are the right answer on their own.

Terraform reverts the task definition my pipeline just deployed

The deployment pipeline registers a new task definition revision and points the service at it. Terraform holds the revision it created and rolls the service back to it on the next apply, which un-deploys whatever was released.

Why Terraform cannot fix this. Terraform's model is that it owns every attribute it can see. When a controller, an autoscaler, a scanner, or a deployment pipeline writes to one of those attributes, Terraform reads the new value as drift and plans to put its own value back. Both systems are behaving correctly; they simply disagree about who owns the field.

The only mechanism Terraform offers for splitting ownership is ignore_changes, and that is a lifecycle argument, which brings the literal-value restriction above with it. A module cannot accept the list of attributes to ignore as an input, so a module consumer has no way to declare the split.

The native workaround. This module has a native option: set ignore_task_definition_changes = true. The module then builds the service from a second resource block, aws_ecs_service.ignore_task_definition, which ignores task_definition and load_balancer. Turning it on for a service that already exists moves it to a new state address, so add a moved block from the module's aws_ecs_service.this[0] to aws_ecs_service.ignore_task_definition[0] in the same change, or Terraform plans to replace it. The rule below ignores task_definition on the resource where it is, with no state move.

The alternative is to give ownership back to Terraform: have the pipeline update the Terraform configuration with the new image tag rather than calling the ECS API directly. That is more work in the pipeline and it removes the disagreement completely.

The rule that answers it. lifecycle_ignore_deployed_artifacts adds the block for you, server-side, while the module is being downloaded. What arrives in .terraform/modules/ is ordinary HCL with this change already in it, and nothing else about the module changes: same inputs, same outputs, same version.

 resource "aws_ecs_service" "this" {
   # ... the module's own configuration, unchanged ...
+
+  lifecycle {
+    ignore_changes = [task_definition]
+  }
 }

Use the rule

This source line applies the rules above during terraform init. The inputs and outputs stay the upstream module's.

module "ecs" {
  source = "https://registry.compliance.tf/terraform-aws-modules/ecs/aws?version=x.y.z&add_rules=lifecycle_ignore_deployed_artifacts"

  # ... the same inputs you pass today; the version is in the URL above ...
}

• Pin the version in the URL. ?version= takes an exact release; without it the registry serves the latest. Delete the version argument, which Terraform accepts only on registry-protocol sources. Several rules go in ?add_rules=, separated by commas.
• Keep the token out of the source line. Register a free compliance.tf account and configure an access token; it never goes in the source line or in git.
• Preview in the Playground, within its limits. The Rules Playground shows the diff with no account, at the version it pins for ECS, which need not be yours. It reads the module root only: a rule whose resource lives in a submodule shows no diff there even though the download applies it, and a module that publishes nothing but submodules cannot be previewed. It takes the list as ?rules= because it previews rules on their own rather than against your Baseline.

On registry.compliance.tf, or on a framework host, ?add_rules= adds to whatever Baseline your organization has Enforced; on an organization host that organization's configuration decides. A module compliance.tf builds for you carries a compliancetf-manifest.json naming every rule the build received, each with an outcome recording what it did.

Related

• Rules overview - what rules are, and how they differ from compliance controls
• Rule definitions - the HCL of every selectable rule
• lifecycle_ignore_deployed_artifacts - the rule page, with limits and failure modes
• Stop paying the Terraform fork tax - why forking a module to add a lifecycle block costs more than it looks
• ECS module reference - inputs, outputs, and the controls applied to it