ECS

The Amazon ECS console has an Event history tab on every cluster. It shows the events ECS generated for that cluster (task state changes, service actions, deployment state changes) for as long as you choose to keep them, instead of the last 100 events or the one hour ECS keeps stopped tasks for. It’s a useful troubleshooting tool. The catch is how you turn it on: a “Turn on event capture” button in the console, which you need to press separately for every cluster. There’s no API call, no CLI command and no CloudFormation resource for it. You can create the underlying resources yourself, and events do get captured, but the console still tells you event capture isn’t configured. The reason is the name of the EventBridge rule. This post explains what the console checks for and shares a small CloudFormation custom resource that computes that name for you.

Amazon ECS has a new observability feature: Action Logs, released in July 2026. They record every action ECS takes on your behalf during service deployments and Managed Daemon operations, and deliver those records to CloudWatch Logs, Amazon S3 or Amazon Data Firehose. The documentation shows how to enable them in the console and through the API, but there’s no infrastructure-as-code example. This post fills that gap with a CloudFormation template. It also flags a value the documentation currently gets wrong.

Eight posts ago we built a small test stack to answer one question: how do ECS deployments and CloudFormation actually behave together, underneath what the documentation says? The answer turned out to be mostly reassuring and occasionally alarming, and the alarming parts share a theme. An ECS deployment with default settings doesn’t fail loudly. It fails silently, succeeds falsely, or hangs invisibly. This closing part collects everything in one place: the catalogue of silent failures the series found, the CloudFormation configuration we ship to close them, the pipeline rules the template can’t express, and one last measurement that makes new services cheaper to add than we expected.

Every failure in this series so far happened to one service at a time. Real stacks don’t deploy like that. A typical application template carries a web service, a worker fleet and a singleton, and one CloudFormation stack update moves all of them together. That opens questions the single-service tests can’t answer. If the web deployment fails, what happens to workers that already finished? If a worker fails while the web service is mid blue/green, who backs out first? So we ran the combinations, and two findings stand out. When one service fails, CloudFormation rolls the healthy ones back too, each with a full backward deployment. And the update where all three services failed at once was the easiest one to recover from.

A container health check is four lines of task definition, and on most services it looks like paperwork. The load balancer already checks the web tasks. A container that crashes already fails its own deployment. So many people never bother with them, and we often skipped them too, until a release that started, stayed up and did nothing useful was marked successful by every layer. The obvious follow-up question was which of our other services would fail the same way. The answer turned out to be all of them. This post covers what a container health check costs, what it catches on each type of service, and the one place where it does noticeably less than you would expect.