Why zero-downtime deployment has become critical for scale-ups
For a scale-up or a mid-market company operating on AWS, every minute of downtime directly affects customer satisfaction and revenue. In the artisanal era, a deployment might inconvenience a few users or cause a minor loss. But once a cloud infrastructure supports millions of requests per day, zero tolerance becomes the rule: a faulty deployment that breaks production represents an immediate loss, an escalation response, and a loss of trust.
Zero-downtime deployment is not a comfort option, it is a necessity for staying competitive. Customers expect availability of 99.9% or more, which means only 43 minutes of allowed downtime per month. A single failed deployment can consume that entire budget. Add to this the fact that modern teams deploy several times a day, and the stakes become obvious: without a controlled deployment strategy, every release becomes a source of stress and unpredictability.
The three major strategies (blue-green, canary, and rolling deployment) solve this challenge by separating the risk tied to the update from the risk tied to downtime. They make it possible to validate the new code before 100% of traffic touches it, to roll back within seconds if something breaks, and to deploy several times a day without organizational paralysis.
Blue-green, the instant-switch strategy
Blue-green deployment is the easiest approach to conceptualize: you maintain two identical production environments, blue and green. At any given moment, only one carries customer traffic (say, blue). You deploy the new version to green in the background, without anyone noticing. Once green is operational and validated, you switch the load balancer or router in a few seconds so that all traffic moves to green.
The great advantage of blue-green is near-instant reversibility. If the switch reveals a catastrophic bug, you point the router back to blue in seconds. There is no gradual degradation: it is all-or-nothing, which eliminates half-broken states where half the users would be affected and the other half not.
However, blue-green requires doubling your production resources. If your infrastructure costs 10,000 euros per month, you double that cost. For some scale-ups with tight margins, this infrastructure investment is unacceptable. Moreover, if your database is shared between blue and green (which is almost always the case for reasons of cost and complexity), the database schemas must be backwards-compatible: a new version of the code cannot drop a column if the old version is still running on blue. This constraint slows down product iteration.
On AWS, blue-green is typically deployed via two Auto Scaling groups (or two sets of EC2 instances or two ECS services) behind a single Application Load Balancer (ALB). The ALB target groups switch from one group to the other by modifying the routing rules.
Canary, incremental validation with real users
Canary deployment aims to validate the new version progressively, first exposing it to a small fraction of users (5 to 10%), then to 25%, then 50%, up to 100% if no problem arises. Unlike blue-green where the switch is binary, canary is a gradient of risk: the further you advance, the more confident you are, but the more exposed you also are.
The advantage of canary is early detection of bugs or performance regressions on real production data with real users, before 100% are affected. If the new version imperceptibly slows down the payment system, only a fraction of canary users experience this increased latency. The metrics (error rate, latency, CPU) on the canary group will warn you before you deploy broadly.
Canary requires an infrastructure capable of routing traffic finely by criteria (user ID, geolocation, device type, etc.). On AWS, this is done via load balancing with weighted target groups or via a service mesh such as Istio or AWS App Mesh. You need solid observability (metrics, logs, distributed traces) to quickly detect if something is going wrong in the canary group. A platform engineer must define alerts and automatic rollback thresholds: if the canary group's error rate exceeds 1%, roll back immediately.
Canary deployment is more complex than blue-green, but cheaper in infrastructure. You do not double your resources, you only add 5 to 10% for the initial canary. It is the approach favored by the hyperscalers (Google, Amazon, Netflix) because it balances risk and cost well.
Rolling deployment, gradual server-by-server rollout
Rolling deployment updates servers progressively, one by one or in small batches. You stop a server running the old version, restart it with the new code, wait for it to stabilize and accept traffic, then move on to the next. During this time, the other servers on the old version keep serving traffic, ensuring the overall availability of the service.
Rolling deployment is cheaper in infrastructure than blue-green (no need to double), simpler than canary (no granular routing mechanism required), but slower: updating 20 servers one by one takes 20 to 30 minutes. Moreover, for most of the rolling process, you have a mix of old and new code answering the same request. This creates a risk of incompatibility: if version 2.0 of the code expects a column to exist in the database, but version 1.9 dropped that column on access, you are stuck. Bidirectional compatibility (backward and forward) becomes mandatory.
On AWS, rolling deployment is configured on Auto Scaling groups by defining an update policy: minimum healthy hosts, desired capacity, max batch size. You can also use it with ECS by configuring the service deployment strategies (ECS rolls out tasks progressively). Rolling deployment shines for stateless workloads where deployment order does not matter and where the load can be handled by N-1 servers.
The choice between these three approaches depends on your risk tolerance, your infrastructure budget, and your observability capability. A team without solid monitoring cannot do canary. An infrastructure with a centralized database and an evolving schema prefers blue-green. A microservices architecture with native load balancing leans toward rolling or canary.
Combining strategies for multi-layer deployments
Few applications live on a single layer. A realistic cloud architecture includes a frontend, a backend API, asynchronous workers, a database, and a cache. You can combine the strategies: deploy the frontend as canary (low risk, few resources), then the backend API as blue-green (critical), then the workers as rolling (stateless, no direct impact).
The real challenge arises when dependencies intertwine the layers. If your new API requires a database schema migration, you cannot deploy the API to green in blue-green until blue supports the new schema. This requires an intermediate step where blue supports both the old schema (for the old API) and the new one (for the preparations). This bidirectional-compatibility dance becomes the bottleneck, not the deployment strategy itself.
This is where multi-service orchestration (a related topic on this site) becomes important: sequencing deployments in the right order, ensuring dependencies are respected, and setting up appropriate health checks for each step. A platform engineer or an IT department must define the deployment dependency: "the backend API can only go canary if the database has already migrated its schema, and not before."
On AWS, this orchestration can rely on AWS CodePipeline to sequence deployments, with manual approvals if needed, or on tools such as Spinnaker or ArgoCD for more complex multi-service and multi-region scenarios.
Metrics, alerts, and automatic rollback to secure every deployment
Whatever strategy you choose, it is useless without solid observability and automatic rollback. A canary deployment on an unmonitored application can let a serious bug through just as easily as a classic monolithic deployment. This is why teams that master zero-downtime deployment invest upfront in metrics, structured logs, and distributed traces.
The critical metrics to track during a deployment are: the error rate (5xx, timeouts), p95 and p99 latency, CPU and memory usage, and business metrics (number of orders, conversion rate, if applicable). You define alert thresholds: if the canary group's error rate goes above 1% for 2 minutes, trigger an automatic rollback. If p95 latency increases by more than 50%, alert. These thresholds must not be rigid: an error rate of 0.5% on a canary group covering 5% of traffic may be normal (that user would have hit the error anyway), but above a certain cumulative threshold, it is a signal.
Automatic rollback must be extremely fast and reliable. On AWS, this means you switch the load balancer or reduce the canary instances within seconds, without waiting for human approval. Logs and traces must be backwards-compatible: if your new version changes the log format, the old monitoring will no longer work. Use structured logs (JSON) to avoid this problem.
In practice, the DevOps teams of mature scale-ups define runbooks: automated procedures that capture the logic "if error rate > X%, then do Y." These runbooks are tested before deployment (chaos engineering, load testing) to make sure that the rollback itself does not break anything. A platform engineer must also verify that the rollback to the old version does not trigger an unwanted database migration or data loss (a rare scenario but catastrophic if it happens).
Adapting the strategy to your AWS context and your team's maturity
Choosing between blue-green, canary, and rolling is not an architectural decision made once and for all. It depends on your DevOps maturity stage, your AWS infrastructure, and your risk tolerance.
A young scale-up that has just moved to AWS and does not yet have robust observability should start with rolling deployment. It is simple to implement (a single Auto Scaling group, no complex load balancer), easy for the team to understand, and sufficient if you deploy once a week. Failures are costly but infrequent.
A scale-up that has stabilized its infrastructure and invested in monitoring can move to blue-green for critical services. This requires a well-designed AWS infrastructure (ALB with target groups, double Auto Scaling) and discipline around the database's bidirectional compatibility, but it eliminates deployment stress: the rollback takes one or two seconds.
A mid-market company with several hundred engineers and a complex microservices architecture will benefit from canary. The investment in a service mesh (AWS App Mesh or Istio), in granular monitoring (Prometheus, Grafana, distributed tracing), and in automatic rollback is quickly amortized by the reduction in production incidents and the increased confidence to deploy several times a day.
In practice, many scale-ups do not choose a single strategy: they combine several. They deploy business code as rolling, database migrations as blue-green (if the change is complex), and new features that need validation as canary. This flexibility is key: the strategy must adapt to the stakes of the deployment, not the other way around. An experienced platform engineer alternates between the three depending on the scenario of the day.
Common pitfalls and how to avoid them
The first pitfall is confusing the deployment strategy with the robustness of the code. A canary deployment on buggy code detects the bug faster, but does not prevent it. A blue-green allows a fast rollback, but does not guarantee the code was not broken from the start. Automating zero-downtime deployment must go hand in hand with good test coverage (unit, integration, e2e) upstream of the deployment.
The second pitfall is database technical debt. If you have rigid schemas and monolithic migrations, every deployment becomes a negotiation between blue and green. Many scale-ups discover too late that their database is a brake on deployment speed. The solution is to adopt progressive migrations: each schema change is done in two or three steps, each deployable and backwards-compatible. This slows down each deployment in total duration, but accelerates the cadence in terms of confidence.
The third pitfall is entrusting the rollback to human vigilance. "A developer will check the metrics every 30 seconds and click Rollback if needed." This is an anti-pattern. Humans sleep, are in meetings, or simply forget. The rollback must be automatic, triggered by observable thresholds defined in advance. If it is a business decision ("we tolerate an additional 0.1% error rate"), that is an exception, not the rule.
The fourth pitfall is neglecting communication. A canary deployment that takes 30 minutes without the rest of the team knowing can paralyze the support team if customers report temporary slowness. Post a message on Slack when the deployment starts, with the estimated duration and the metrics to watch. If a rollback is triggered, inform everyone immediately.
Finally, many teams deploy without having tested the rollback. A canary deployment that rolls back in 5 seconds is only theoretical if you have never tested a real rollback. Do chaos engineering: simulate failures during a deployment and verify that the automatic rollback triggers correctly and that the application returns to a healthy state.