AWS Certified Developer - Associate (DVA-C02) #11 Domain 3-3 Deployment — Deployment Strategies

Now that we’ve covered the deployment tools in #10 IaC and Serverless Deployment, the last topic of the deployment domain is the strategies themselves for updating safely with zero downtime. The exam asks how to “deploy with no downtime, reduce risk, and roll back quickly when something goes wrong.”

in-place vs blue/green #

The key: blue/green’s strengths are fast rollback and zero downtime. The answer to “must revert immediately on a deployment failure” is usually blue/green. The downside is the cost of temporarily running two environments.

Traffic-Shifting Methods #

There are three ways to move traffic to the new version. CodeDeploy and SAM use these exact names.

Canary and linear are lower risk because they first validate the new version with a portion of traffic. The answer to “expose the new version to a small set of users first, watch the metrics, then expand” is canary.

Lambda Versions,Aliases and Weighted Routing #

The aliases we saw in #2 become central here.

• Version — An immutable snapshot created each time you publish (:1, :2).
• Alias — A pointer to a specific version (prod → :2).
• Weighted routing — An alias distributes traffic between two versions by ratio (e.g., 90% to :2, 10% to :3).

Gradually raising this weight is Lambda’s canary/linear deployment. In SAM, declaring AutoPublishAlias and DeploymentPreference (e.g., Canary10Percent5Minutes) makes CodeDeploy shift traffic automatically and roll back on failure.

The answer to “send only 10% to the new Lambda version, then everything if there’s no problem” is alias weighted routing (SAM DeploymentPreference canary).

API Gateway Gradual Deployment #

API Gateway can also send a portion of traffic to a new deployment via a stage’s canary settings. Used together with stage variables, it enables per-environment,per-version branching.

ECS/EC2 Deployment Strategies #

• ECS — Blue/green with CodeDeploy (deploy to a new task set, then switch the listener). Rollback is fast.
• EC2 (CodeDeploy) — In-place or blue/green. Validate the deployment with the ValidateService of the appspec lifecycle hooks.
• Elastic Beanstalk — Immutable/Blue-Green is the safest.

Automatic Rollback #

Judging whether a deployment is actually healthy, and automatically reverting when it’s bad, is the heart of operations.

• CloudWatch alarm integration — If an error-rate,latency alarm fires during a deployment, CodeDeploy rolls back automatically.
• Rollback on deployment failure — Reverts to the previous version on lifecycle-hook validation failure or health-check failure.
• SAM/CodeDeploy canary deployment, tied to alarms, automates “stop the expansion + roll back if metrics worsen.”

The answer to “automatically revert if the error rate spikes after deploying a new version” is CloudWatch alarm + CodeDeploy automatic rollback.

Strategy Quick-Select Table #

Exam question patterns #

• “Must revert to the previous version immediately on a deployment failure.” → Blue/Green.
• “Roll out a new feature to 10% of users first.” → Canary.
• “Gradually shift traffic to a new Lambda version.” → Alias weighted routing (SAM DeploymentPreference).
• “Auto rollback when the error rate spikes after deployment.” → CloudWatch alarm + CodeDeploy.
• “Validate the application is healthy after an EC2 deployment.” → appspec ValidateService hook.

Common traps #

1) Confusing blue/green and in-place rollback speed #

With blue/green, just shifting traffic back makes rollback instant. In-place is slow because it requires redeployment.

2) Confusing version and alias #

A version is an immutable snapshot; an alias is a pointer (+ weight distribution). Weighted deployment is driven by the alias.

3) Thinking automatic rollback is only health checks #

The key to metric-based automatic rollback is CloudWatch alarm integration.

Wrap-up #

What this post locked in:

• in-place (low cost,slow rollback) vs blue/green (zero downtime,fast rollback,double cost)
• Traffic shifting — Canary (a portion first), Linear (step increase), All-at-once
• Gradual shifting between versions via Lambda alias weighted routing (SAM DeploymentPreference)
• Reverting on worsening metrics via CloudWatch alarm + CodeDeploy automatic rollback

Next — Domain 4-1 Observability #

We’ve finished deployment. The last domain is troubleshooting and optimization at 18%. In #12 Observability, I’ll cover CloudWatch Logs,Metrics,Alarms, X-Ray distributed tracing, and how to extract metrics from logs with EMF (Embedded Metric Format).