CloudFormation

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.

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.

This post is about the question that started the whole series: when an ECS deployment fails while CloudFormation is driving, who puts things back - ECS, CloudFormation, or both, one after the other? We had once watched a service roll back twice in a row on another stack, every task replaced once by ECS and then again by CloudFormation, and that fear is why we built the test stack. Nothing in the AWS documentation says what happens to a service resource when ECS rolls a deployment back in the middle of a stack update. So we measured it: deployments where the new tasks never come good, first with no failure detector at all, then with the circuit breaker in both of its modes, on both deployment strategies. Every number below comes from a measured run (July 2026, eu-west-1).

Rolling is the ECS deployment strategy most people start with, and the one everyone assumes they already understand. Old tasks out, new tasks in, two percentages to control the pace. The percentages are documented properly. What the documentation never actually defines is when a rolling deployment is done. Three separate layers each declare completion at their own moment (the deployment record, the service’s own events, and the CloudFormation resource), and on an update they disagree by well over a minute. We measured where each one lands, on two very different rolling services, and this post is what came out of it.