Notes from our work with AWS, DevOps and security: news and new features, fixes for common problems, and how we solved real client issues.
Our founder, Paulina Budzoń, joined Andrew Morris on Beyond Co-Sell, a podcast about the people and machinery behind AWS partnerships. Most of its guests run alliances at software companies. This episode is the view from a boutique services partner: how we use the AWS partner programme, what we hand to a machine, and where our customers actually come from.
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.
Start with a free second opinion: 30 minutes with our founder, who has held AWS Professional certifications since 2016. No account access needed, and you keep a short written note of what we covered.
