DevOps

Deployment alarms are the easiest of the ECS failure detectors to describe. You name some CloudWatch alarms on the service, and if one goes into ALARM during a deployment, ECS fails that deployment and rolls it back. We ran that path repeatedly against both a blue/green service and a rolling one, and the mechanism was never the interesting part. What matters is how late the alarm arrives, what a quiet metric does to it afterwards, and the documented behaviour that switches monitoring off at the worst (or best?) possible moment. Every number below comes from a measured run (July 2026, eu-west-1).

When we measured a full ECS blue/green deployment in the first post of this series, one number stood out: 28 seconds. That’s how long the new revision sits on the test listener before production traffic shifts to it, and it’s the only period in which a smoke test could stop a bad release before users see it. No realistic test suite fits in that time. Pause hooks are the fix. Announced in May 2026, they make the deployment stop at a stage you choose and wait for you, turning those 28 seconds into a smoke test phase of whatever length you need. Third-party coverage of the feature is still close to zero, so we measured the whole workflow on our test stack: the continue path, the rollback path, an alarm firing mid-pause, and one case where the hook is accepted and then does nothing at all. Every number below comes from a measured run (July 2026, eu-west-1).

We hit a frustrating issue recently while building PHP images in AWS CodeBuild: composer install started failing, often, with an HTTP/2 400 from codeload.github.com while downloading a package archive. The package that failed changed from run to run, and the same Dockerfile and composer.lock that broke in one pipeline built cleanly in another. The short version is that this is GitHub wobbling rather than anything wrong in your project, that the same failure has come and gone for years, and that the usual environment-variable fixes only take the edge off. If your deployments run composer install, here is what is actually going on and how to stop it taking your builds down.

Validating an IaC template before you hand it to CloudFormation is one of the cheapest ways to avoid the dreaded UPDATE_ROLLBACK_IN_PROGRESS. You can catch a lot without ever creating a stack - but only if you understand what the tool you use actually checks. Here are the two we usually use, and where one stops and the other takes over.

A while back we wrote about our automatically updated docker image for cfn-lint - a public, daily-rebuilt image for cfn-lint that fills the gap left by the lack of an official one. Two changes have just landed in that build, and both are worth a few words: the images are now multiplatform, and we have fixed a problem that, from cfn-lint v1.52.0 onwards, left the image unable to recognise any resources.