<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ECS on Mysterious Code - Senior AWS, DevOps &amp; security engineering</title><link>https://mysteriouscode.com/blog/category/ecs/</link><description>Recent content in ECS on Mysterious Code - Senior AWS, DevOps &amp; security engineering</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Mon, 27 Jul 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://mysteriouscode.com/blog/category/ecs/index.xml" rel="self" type="application/rss+xml"/><item><title>ECS native blue/green deployments with CloudFormation: how it actually works</title><link>https://mysteriouscode.com/blog/ecs-native-blue-green-deployments-with-cloudformation-how-it-actually-works/</link><pubDate>Mon, 27 Jul 2026 08:00:00 +0000</pubDate><guid>https://mysteriouscode.com/blog/ecs-native-blue-green-deployments-with-cloudformation-how-it-actually-works/</guid><description>&lt;p&gt;In July 2025, ECS introduced a &lt;a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html"&gt;native blue/green deployment type&lt;/a&gt;
comprising two target groups, a test listener, a bake period and managed rollback, all of which are run by ECS itself
with no involvement from CodeDeploy. The documentation covers the ideal scenario. However, it says much less about how
the feature behaves with CloudFormation on top, such as where &lt;code&gt;UPDATE_COMPLETE&lt;/code&gt;
lands relative to the bake, how long each stage really takes and whether stack updates end up conflicting with the
listener rules that the feature rewrites. We built a small test stack and ran the machinery repeatedly, documenting
everything. This post opens a series on how ECS deployment strategies behave when driven by CloudFormation - every
number in it comes from a measured run.&lt;/p&gt;</description></item></channel></rss>