Deploying Your Apps Into ECS

Hey folks,

No one should be managing their AWS ECS deployments with IaC.

Hot take from an IaC consulting firm owner, amirite?

But let me break it down.

We see this pattern a lot with clients: Terraform manages the ECS service, the task definition, and the container image tag. Deployments are managed through terraform plan and apply.

At super small scale for your POC project? Sure, do your thing.

At scale? You've now slowed down your deployment considerably and you're asking TF to manage application deployments. That is something it's not intended for.

Teams evolve and quickly realize this doesn't work. They start deploying directly via the ECS API in their application CI/CD pipelines:

• build and push the image

• register a new task def revision

• update the service

• done in ~5 seconds

Way faster.

But now Terraform doesn't know about those deployments, even though it's tracking the state of the cloud infra. Suddenly, every plan shows noisy diffs on the task definition.

Devs start slapping ignore_changes on random things.

You've got consistent drift that people just shrug at, apply, and hope for the best.

No good.

But there is a better way. We call it “The Task Definition Template Pattern”:

1. Terraform owns a template task definition with all your infra config (env vars, secrets, resource limits, log config) but uses a placeholder image tag like :latest.

2. This task def template gets deployed on first provision of the corresponding ECS Service, but then the ECS Service resource uses ignore_changes = [task_definition]. This means no future updates to that task def config in the code will trigger a "TF Deployment". The task def config might get updated and a new revision will be created, but that revision will not be set to be used by the Service yet.

3. Your deploy pipeline is responsible for owning the updates for which ECS Service task definition is live. The pipeline reads that latest template revision directly from AWS, injects any new image tag, registers a new revision, and updates the service.

This keeps the single source of truth for the ECS task definition configuration where you want it to be: in your infrastructure as code. At the same time it enables fast, efficient deployments from your CI/CD tooling.

No drift. No noisy plans. No bottleneck. Each tool does what it's good at.

May your ignore_changes arguments be few and far between,

Matt @ Masterpoint

PS If you want to chat about the Task Definition Template Pattern, grab some time on my calendar here. If you’ve found this newsletter helpful, please forward it to a friend. Or if you want to share on your company slack, here’s the archive of all my newsletters.