In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
👋 👋 A big thank you to today's sponsor MINTLIFY
Ship Docs Your Team Is Actually Proud Of
Mintlify helps you create fast, beautiful docs that developers actually enjoy using. Write in markdown, sync with your repo, and deploy in minutes. Built-in components handle search, navigation, API references, and interactive examples out of the box, so you can focus on clear content instead of custom infrastructure.
Automatic versioning, analytics, and AI powered search make it easy to scale as your product grows. Your docs stay accurate automatically with AI-powered workflows with every pull request.
Whether you're a dev, technical writer, part of devrel, and beyond, Mintlify fits into the way you already work and helps your documentation keep pace with your product.
👀 Remote Jobs
Northflank is hiring a Cloud Infrastructure Engineer
Remote Location: Worldwide
Xapo Bank is hiring a Platform Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
Looking to promote your company, product, service, or event to 48,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
Amazon ECS Deployment Strategies
Every time you ship a new version of your application, you face the same fundamental tension. You want the new version running as quickly as possible. You also want zero downtime and the ability to roll back instantly if something goes wrong. These two goals conflict directly. The faster you replace old tasks with new ones, the less time you have to catch problems before all your users are affected.
We discuss Amazon ECS deployment strategies that trade off speed, risk, and cost in different ways. Understanding which strategy fits each situation is one of the most important operational decisions you make when running services on ECS.
What is an ECS deployment?
Before the strategies make sense, the underlying model needs to be clear. An ECS service maintains a desired count of running tasks. A task is a running instance of your task definition, which is a JSON specification describing your container image, CPU, memory, environment variables, and port mappings. When you deploy a new version of your application, you register a new task definition revision and tell the ECS service to use it.
The deployment strategy determines how ECS transitions from running tasks of the old revision to running tasks of the new revision. The three strategies are Rolling, Blue/Green, and Canary. Each uses the Application Load Balancer's target group mechanism to control which tasks receive traffic.
Linear Deployment: Steady Incremental Progression
The linear strategy is a specific variant of the canary approach where traffic shifts in equal increments on a fixed schedule.
The diagram shows an intermediate linear state: 70% traffic to the Blue target group and 30% to the Green target group. In a linear deployment, you might configure steps of 10 percent every 5 minutes. Traffic shifts from 10/90 to 20/80 to 30/70 and so on until it reaches 100% Green. Each step is equal in size and happens on a fixed timer rather than based on metric evaluation.
Linear is simpler to configure than canary because it does not require defining evaluation logic. The trade-off is that linear continues progressing even if the new version is performing poorly. At 30% traffic, if error rates are elevated, linear will continue to 40% unless you have CloudWatch alarms configured to trigger an automatic rollback. In practice, you should always pair linear deployments with CloudWatch alarm based automatic rollback. Without alarms, linear is just a slower version of an all at once deployment.
The practical difference between linear and canary is the decision logic.
Linear is schedule driven: advance every N minutes regardless of metrics.
Canary is evaluation driven: advance only if the metrics are healthy.
For most production services where you want automated protection, canary with metric evaluation is the stronger choice.
Rolling Deployment: Task by Task Replacement
The rolling deployment is the default ECS strategy and the simplest to understand. ECS replaces old tasks with new tasks incrementally, one batch at a time, while the service stays live throughout.
The four step sequence shown above is exactly what happens under the hood.
Step 1 is the starting state: four tasks running the old v1 image, all receiving traffic.
Step 2 begins the rollout: ECS scales up one new v2 task alongside the three remaining v1 tasks. The new task must pass health checks before ECS proceeds.
Step 3 continues the replacement: another old task is drained, removed from the load balancer target group, and replaced with a new v2 task. Two old and two new tasks are running simultaneously.
Step 4 is completion: all four tasks are now running v2.
The key parameters that control rolling deployments are minimumHealthyPercent and maximumPercent. If you set minimumHealthyPercent: 50 and maximumPercent: 200 on a service with four tasks, ECS can take two tasks out of service at once while spinning up to eight tasks total. This makes the rollout faster but increases double running cost during the transition.
If you set minimumHealthyPercent: 100, ECS must add new tasks before removing old ones, meaning you always have full capacity but pay for extra tasks during the transition.
Rolling deployment is the right default for most services. It requires no additional infrastructure, costs nothing extra beyond the brief period when old and new tasks run simultaneously, and handles straightforward application updates cleanly. The limitation is rollback speed. If v2 is running and causing errors, rolling back means triggering another rolling deployment with the v1 task definition, which takes the same amount of time as the original rollout.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
