部署策略：Blue/Green、Canary 與 Rolling

Deployment strategies are the deciding factor between a release that quietly rolls out to millions of users and a release that takes your application down for an hour. On the AWS Certified Developer Associate (DVA-C02) exam, deployment strategies are one of the top three tested areas of Domain 3 — Deployment, right next to the CodeDeploy toolchain and Infrastructure-as-Code. Every deployment strategies question the exam asks is ultimately about the same two axes: how much risk you accept per release, and how fast you can roll back when a release misbehaves. This chapter walks through every deployment strategies pattern the DVA-C02 exam expects you to know — In-Place, Rolling, Rolling with Additional Batch, Immutable, Blue/Green, Canary, Linear, and Feature Flag — and maps each of those deployment strategies to concrete AWS compute platforms: AWS Lambda, Amazon ECS, Amazon EC2 Auto Scaling, and AWS Elastic Beanstalk. By the end, you will be able to look at any exam scenario and pick the single correct deployment strategies answer in under 45 seconds.

What Are Deployment Strategies?

Deployment strategies are the rules that govern how a new version of an application replaces an older version. Every deployment strategies decision involves four variables:

1. How many instances / tasks / alias weights the new version takes at once.
2. How long the new version runs alongside the old version before full cutover.
3. What signals trigger a rollback to the old version.
4. How long rollback takes when it triggers.

Those four variables combine into a taxonomy of deployment strategies that AWS implements in slightly different names on every compute service. The DVA-C02 exam tests whether you can map the generic deployment strategies vocabulary (Blue/Green, Canary, Linear) to the specific parameter names in AWS CodeDeploy, AWS Elastic Beanstalk, Amazon ECS, and AWS Lambda aliases.

Why Deployment Strategies Matter for DVA-C02

Deployment strategies questions make up roughly 30–40 percent of Domain 3 content. Expect at least five scenarios per exam sitting where you must pick between two deployment strategies that both technically "work" — for example, Canary10Percent5Minutes versus Linear10PercentEvery10Minutes, or Rolling versus Rolling with Additional Batch. Deployment strategies also thread through Domain 4 (Troubleshooting) when a failed release must be rolled back via CloudWatch alarm triggers. Memorize deployment strategies trade-offs once and you earn points in two domains.

The DVA-C02 Deployment Strategies Mental Model

Before diving into each AWS service, internalize this two-question triage that every deployment strategies problem reduces to:

• Can the old and new versions run simultaneously? If yes, you can afford Blue/Green or Canary deployment strategies. If no (e.g., incompatible database schema), you are stuck with In-Place or All-at-Once deployment strategies.
• What is the blast radius of a bad deploy? High blast radius pushes you toward Canary or Linear deployment strategies with automated CloudWatch alarm rollback. Low blast radius tolerates Rolling deployment strategies.

Plain-English Explanation of Deployment Strategies

Deployment strategies are abstract. Three analogies lock the whole taxonomy into muscle memory.

Analogy 1 — The Restaurant Menu Change

Imagine you run a restaurant and want to switch to a new menu. The deployment strategies available to you map one-to-one onto AWS deployment strategies:

• All-at-Once (In-Place): close the restaurant for an hour, reprint every menu, reopen. Fast, cheap, but customers see downtime. Matches CodeDeploy AllAtOnce and Beanstalk All at once deployment strategies.
• Rolling: swap one table's menu at a time. No closure, but for 20 minutes two different menus exist and the kitchen must support both. Matches CodeDeploy OneAtATime / HalfAtATime and Beanstalk Rolling deployment strategies.
• Rolling with Additional Batch: add an extra table before you start swapping, so at no point is seating capacity reduced. Matches Beanstalk Rolling with additional batch deployment strategies.
• Immutable: build a whole second restaurant next door with the new menu, move all customers over on cutover night, demolish the old building. Matches Beanstalk Immutable deployment strategies.
• Blue/Green: same as Immutable but you keep the old building running for a week "just in case" — if the new menu bombs, you reopen the old restaurant in seconds. Matches CodeDeploy Blue/Green and ECS Blue/Green deployment strategies.
• Canary: let 5 percent of customers order from the new menu. If they complain, scrap the new menu. If they love it, roll it to everyone. Matches Lambda Canary10Percent5Minutes and API Gateway canary deployment strategies.
• Linear: every 10 minutes, add 10 percent of customers to the new menu. Matches Lambda Linear10PercentEvery10Minutes deployment strategies.
• Feature Flag: the new dish is on the menu but hidden behind "ask the waiter" — you flip a switch to reveal it to named customers. Matches AWS AppConfig feature-flag deployment strategies.

Analogy 2 — The Hospital Staff Handoff

Deployment strategies also resemble a hospital shift change. All-at-Once is "everyone clocks out at 7 pm and the new shift starts at 7:01" — a gap where nobody is on duty. Rolling is "each nurse hands off to their replacement one at a time" — continuous coverage but cross-shift coordination is painful. Blue/Green is "the new shift arrives at 6:30, shadows for 30 minutes, and takes over on the manager's signal" — the old shift stays on-site until the handoff is confirmed clean. Canary is "only the triage desk switches to the new shift first, so any training gap shows up in low-stakes cases before the ICU swaps over." Feature Flag is "the new protocol is written on every nurse's clipboard, but nobody uses it until the chief of medicine flips the switch." This second analogy highlights why deployment strategies are fundamentally about observability windows: the period during which both versions run is exactly when you learn whether the new version is safe.

Analogy 3 — The Toll Booth Lane Switch

Traffic-shifting deployment strategies map cleanly onto highway toll booths. Imagine twelve toll lanes carrying all highway traffic (your production load balancer). A Blue/Green deployment strategies is "open six brand-new lanes next to the existing twelve, close the existing twelve once traffic has fully moved." A Canary deployment strategies is "leave the twelve old lanes open and open one new lane; send 10 percent of traffic through the new lane for five minutes, then reopen the rest." A Rolling deployment strategies is "repave one lane at a time while the other eleven keep working." A Linear deployment strategies is "every ten minutes repave two more lanes until all twelve are done." A Feature Flag deployment strategies is "build the new lanes behind a removable barricade — flip the barricade up or down at will without touching the lanes themselves." Route 53 weighted DNS, ALB weighted target groups, and API Gateway canary settings are each just a different mechanism for implementing these deployment strategies at a different OSI layer.

The Deployment Strategies Taxonomy

Every deployment strategies conversation on DVA-C02 draws from the same seven archetypes. Memorize this taxonomy once and you can match any exam scenario to the correct pattern.

In-Place (All-at-Once) Deployment Strategies

The In-Place deployment strategies style replaces the application on the existing infrastructure. Every host, task, or function version is updated in the same location. CodeDeploy calls the fastest form of this AllAtOnce. Elastic Beanstalk calls it All at once. All-at-Once deployment strategies are the cheapest and fastest deployment strategies but also the riskiest — there is no concurrent old version to fall back to if the new release fails, so rollback means re-deploying the previous artifact from scratch. Use All-at-Once deployment strategies only for dev/test environments or internal tools.

Rolling Deployment Strategies

Rolling deployment strategies replace instances in batches on the same underlying infrastructure. CodeDeploy exposes OneAtATime, HalfAtATime, and custom percentage configurations. Elastic Beanstalk names this Rolling and lets you pick batch size. Rolling deployment strategies reduce risk per batch (a bad version only breaks a fraction of hosts), but they temporarily reduce capacity — if your batch size is 25 percent, 25 percent of your fleet is unavailable during deploy.

Rolling with Additional Batch Deployment Strategies

Rolling with Additional Batch deployment strategies solve the capacity-reduction problem. Beanstalk launches an extra batch of instances before terminating any old instances, so the running fleet temporarily grows rather than shrinks. This deployment strategies variant is the default exam answer when the scenario says "no capacity reduction during deploy" without demanding full Blue/Green isolation.

Immutable Deployment Strategies

Immutable deployment strategies never modify existing instances — they launch an entirely new Auto Scaling group (or Beanstalk environment), verify it passes health checks, then terminate the old fleet. Elastic Beanstalk has a dedicated Immutable deployment strategies setting. The difference from Blue/Green is that Immutable treats old + new as sequential, not simultaneous traffic-serving — old traffic is not split between blue and green.

Blue/Green Deployment Strategies

Blue/Green deployment strategies provision a complete parallel environment (green) alongside production (blue), then shift traffic en masse once green is verified. CodeDeploy supports Blue/Green on EC2 (via Auto Scaling group swap), on Lambda (via alias weight shift), and on ECS (via CodeDeploy-managed listener rules). Rollback is instantaneous because blue is still running. Blue/Green deployment strategies are the default exam answer when the scenario emphasizes "zero downtime" and "instant rollback."

Canary Deployment Strategies

Canary deployment strategies shift a small percentage of traffic to the new version, wait, verify, then shift the remaining traffic. CodeDeploy for Lambda defines canonical configurations: Canary10Percent5Minutes, Canary10Percent15Minutes, Canary10Percent30Minutes, Canary10PercentAnHour. Canary deployment strategies differ from Blue/Green in that traffic is split, not swapped, and the canary window is explicitly short and fixed. Canary deployment strategies are the default exam answer when the scenario says "test with a small percentage of real users."

Linear Deployment Strategies

Linear deployment strategies shift traffic in equal increments over time. CodeDeploy for Lambda defines Linear10PercentEvery1Minute, Linear10PercentEvery2Minutes, Linear10PercentEvery3Minutes, and Linear10PercentEvery10Minutes. Linear deployment strategies differ from Canary in that the shift is gradual and continuous, not "small-batch-then-big-batch." Linear deployment strategies are the right answer when the scenario says "gradually shift traffic" without specifying an initial small percentage window.

Feature Flag Deployment Strategies

Feature Flag deployment strategies decouple deployment from release. Code ships to production disabled; operators flip the flag to turn on the behavior. AWS AppConfig is the managed feature-flag store on AWS. Feature Flag deployment strategies are the right answer when the scenario says "deploy now but turn on later" or "enable the feature only for beta customers."

Deployment Strategies for Amazon EC2 Auto Scaling

EC2 Auto Scaling groups (ASGs) are the DVA-C02 classic compute target and support four different deployment strategies.

In-Place Deployment Strategies with EC2 and CodeDeploy

CodeDeploy with compute platform Server and deployment type In-place runs the CodeDeploy agent on each existing EC2 instance and executes the lifecycle hooks (ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService) sequentially. Deployment configurations CodeDeployDefault.AllAtOnce, CodeDeployDefault.HalfAtATime, and CodeDeployDefault.OneAtATime control batch size. In-Place deployment strategies are appropriate when blast radius is low, infrastructure cost matters, and you do not need instant rollback.

Rolling Deployment Strategies via ELB Draining

When EC2 instances are attached to an Elastic Load Balancer, CodeDeploy coordinates with the ELB to drain connections (via deregistration delay, default 300 seconds) before stopping the old application on each instance. This ensures in-flight requests finish before replacement. Rolling deployment strategies with ELB draining are the exam default when the scenario says "minimize in-flight request loss."

Blue/Green Deployment Strategies via ASG Swap

CodeDeploy Blue/Green on EC2 provisions a brand-new Auto Scaling group with the new application version, attaches it to the existing ELB target group, shifts traffic, and optionally terminates the old ASG. Required ingredients are an ELB (the traffic-shifting mechanism), a launch template, and a CodeDeploy deployment group with deployment type Blue/green. This Blue/Green deployment strategies variant supports instant rollback (re-attach the old ASG to the ELB) because the old ASG is retained for a configurable wait window.

Immutable Deployment Strategies via Instance Refresh

Amazon EC2 Auto Scaling Instance Refresh is a built-in replacement mechanism that launches new instances matching the latest launch template, then terminates old instances once new ones pass health checks. Instance Refresh supports a MinHealthyPercentage parameter (default 90%) that controls Rolling vs full Immutable deployment strategies behavior. Set MinHealthyPercentage to 100% to force new capacity to come online before old capacity leaves — this is effectively Immutable deployment strategies at the ASG level.

Deployment Strategies for AWS Lambda

AWS Lambda gets the deepest deployment-strategies treatment on the DVA-C02 exam. Memorize every named configuration.

Lambda Aliases and Weighted Routing: The Foundation

A Lambda alias is a named pointer to a specific Lambda function version. The critical feature for deployment strategies is routing configuration: an alias can point to two versions at once and split invocation traffic between them by weight. For example, an alias configured with "AdditionalVersionWeights": {"2": 0.1} while the primary version is 1 routes 90 percent of invocations to version 1 and 10 percent to version 2. This is the primitive that powers every Lambda canary and linear deployment strategies in CodeDeploy.

# AWS SAM fragment showing a Lambda alias with weighted traffic
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: nodejs20.x
      AutoPublishAlias: live
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref ErrorAlarm
        Hooks:
          PreTraffic: !Ref PreTrafficHook
          PostTraffic: !Ref PostTrafficHook

Lambda Canary Deployment Strategies: Canary10Percent5Minutes

CodeDeploy for Lambda exposes four canary deployment strategies configurations, all shaped "10 percent first, wait N minutes, then 100 percent":

• CodeDeployDefault.LambdaCanary10Percent5Minutes
• CodeDeployDefault.LambdaCanary10Percent15Minutes
• CodeDeployDefault.LambdaCanary10Percent30Minutes
• CodeDeployDefault.LambdaCanary10PercentAnHour

During the wait window, 10 percent of invocations hit the new version; 90 percent hit the old version. If any CloudWatch alarm attached to the deployment group transitions to ALARM during the wait window, CodeDeploy rolls back by re-pointing the alias at 100 percent old version. The exam will often give you a scenario ("the team wants to catch errors in 10 percent of traffic before a full shift") and ask you to pick the correct named Lambda canary deployment strategies.

Lambda Linear Deployment Strategies: Linear10PercentEvery10Minutes

Lambda linear deployment strategies configurations ramp traffic in equal increments:

• CodeDeployDefault.LambdaLinear10PercentEvery1Minute
• CodeDeployDefault.LambdaLinear10PercentEvery2Minutes
• CodeDeployDefault.LambdaLinear10PercentEvery3Minutes
• CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

Under Linear10PercentEvery10Minutes, the alias weight moves from 0% new to 100% new in ten 10-percent steps spaced ten minutes apart — total rollout takes 100 minutes. Linear deployment strategies differ from Canary deployment strategies in that there is no single "verification window" at 10 percent; the whole rollout is the verification window.

Lambda All-at-Once Deployment Strategies

CodeDeployDefault.LambdaAllAtOnce shifts 100 percent of traffic to the new version immediately. Use this deployment strategies option only for dev environments; there is no automated canary buffer for errors.

Pre-Traffic and Post-Traffic Hooks

CodeDeploy for Lambda supports two lifecycle hooks that are themselves Lambda functions:

• BeforeAllowTraffic (pre-traffic hook): runs before any traffic shifts. Use it to run smoke tests against the newly deployed version using Lambda:InvokeFunction against the functionVersion the hook receives.
• AfterAllowTraffic (post-traffic hook): runs after 100 percent of traffic has shifted. Use it to run integration tests or warm caches.

Both hooks must call codedeploy:PutLifecycleEventHookExecutionStatus with Succeeded or Failed. A Failed status triggers automatic rollback.

Automatic Rollback on CloudWatch Alarms

Every CodeDeploy deployment group for Lambda can list CloudWatch alarms under AlarmConfiguration. If any listed alarm enters ALARM state at any point during the deployment (canary window, linear window, or post-traffic hook), CodeDeploy immediately halts the shift and rolls back the alias weight to 100 percent old version. Typical alarms for Lambda deployment strategies monitor:

• AWS/Lambda Errors metric (function-level error count).
• AWS/Lambda Throttles metric.
• Custom CloudWatch metrics emitted via Embedded Metric Format (EMF).
• API Gateway 5XXError metric on the stage that invokes the Lambda.

Deployment Strategies for Amazon ECS

Amazon ECS supports two deployment strategies flavors: the native rolling update (ECS deployment controller) and CodeDeploy-managed Blue/Green (CODE_DEPLOY deployment controller).

ECS Rolling Update Deployment Strategies

The default ECS deployment controller (ECS) updates a service by gradually replacing old tasks with new tasks. The minimumHealthyPercent (default 100) and maximumPercent (default 200) service parameters bound the rolling deployment strategies window — minimumHealthyPercent = 100 and maximumPercent = 200 means ECS can temporarily double the task count during deploy without ever dropping below the desired task count. ECS rolling deployment strategies are the right answer when the scenario says "gradually replace tasks with no dedicated load balancer listener switch."

ECS Blue/Green Deployment Strategies with CodeDeploy

Setting deployment controller to CODE_DEPLOY on an ECS service unlocks full Blue/Green deployment strategies via CodeDeploy. The mechanism requires two target groups attached to the Application Load Balancer:

• A production listener on port 80 or 443 pointing to the current target group.
• A test listener on a separate port (commonly 8080) that always points to the replacement task set, enabling pre-production validation against real infrastructure.

Deployment flow:

1. CodeDeploy creates a new ECS task set (green) in the service.
2. Green task set registers with the test listener target group.
3. The AppSpec AfterAllowTestTraffic hook (a Lambda function) runs validation against the test listener URL.
4. Traffic shifts on the production listener from blue task set to green task set using one of the CodeDeploy traffic-shifting configurations (AllAtOnce, Linear, or Canary).
5. A wait period (configurable up to 2 days) holds the old blue task set idle in case of manual rollback, then CodeDeploy terminates blue.

# appspec.yaml for ECS Blue/Green
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:...:task-definition/my-app:42"
        LoadBalancerInfo:
          ContainerName: "web"
          ContainerPort: 80
Hooks:
  - BeforeInstall: "arn:aws:lambda:...:function:PreInstallHook"
  - AfterInstall: "arn:aws:lambda:...:function:PostInstallHook"
  - AfterAllowTestTraffic: "arn:aws:lambda:...:function:TestTrafficValidator"
  - BeforeAllowTraffic: "arn:aws:lambda:...:function:PreTrafficHook"
  - AfterAllowTraffic: "arn:aws:lambda:...:function:PostTrafficHook"

ECS Manual Validation Wait Time

The CodeDeploy ECS Blue/Green deployment group supports a terminationWaitTimeInMinutes (up to 2880 minutes = 48 hours) during which the old blue task set stays alive after traffic shift. This manual validation window is the ECS exam trap — if a question says "keep the old version ready to instantly restore for one day after deploying," the answer is ECS Blue/Green with a terminationWaitTimeInMinutes set to 1440 minutes.

Automatic Rollback Hook in ECS Blue/Green

Just like Lambda, ECS Blue/Green deployment groups attach CloudWatch alarms via AlarmConfiguration. If any alarm enters ALARM during the deployment, CodeDeploy re-points the production listener at the blue task set and terminates the green task set.

Deployment Strategies for AWS Elastic Beanstalk

AWS Elastic Beanstalk exposes deployment strategies as named deployment policies on the environment configuration.

Beanstalk Deployment Policy Matrix

Traffic splitting is Beanstalk's managed canary deployment strategies — it launches an immutable new fleet, routes a configured percentage of incoming traffic to it, waits for a configured evaluation window, and shifts 100 percent or rolls back based on health.

Beanstalk Blue/Green via CNAME Swap

Beanstalk does not have a native "Blue/Green" deployment policy name. The canonical Beanstalk Blue/Green deployment strategies approach is:

1. Clone the current environment (blue) into a new environment (green).
2. Deploy the new application version to green.
3. Validate green using the Beanstalk-assigned green URL.
4. Swap environment URLs in the Beanstalk console. The CNAME flip is near-instant; DNS propagation is the only delay.
5. Terminate the old blue environment after a validation window.

Traffic-Shifting Mechanisms Beyond CodeDeploy

Deployment strategies that involve percentage-based traffic shifts require a routing mechanism. AWS offers several, each tested on DVA-C02.

Route 53 Weighted DNS Deployment Strategies

Route 53 weighted routing records assign a Weight (0–255) to each record. DNS resolvers return each record with probability proportional to its weight. Weighted DNS is the coarsest-grained traffic-shifting deployment strategies mechanism: TTLs (often 60 seconds) mean the shift is not instant, and DNS caching at clients can hold stale answers for minutes. Route 53 weighted deployment strategies are typically used for cross-region Blue/Green cutover or for shifting between two entirely different stacks (e.g., monolith to microservices rewrite).

API Gateway Stage Canary Deployment Strategies

Every REST API Gateway stage can define a canary release configuration: canarySettings.percentTraffic splits requests between the main deployment and a canary deployment at the API Gateway layer. API Gateway canary deployment strategies are the right answer when the scenario says "test a new API version on a small percentage of traffic without involving Lambda aliases" — for example, when the backend is an HTTP endpoint rather than a Lambda function.

ALB Weighted Target Groups Deployment Strategies

Application Load Balancer supports multiple target groups per listener rule with per-target-group weights (0–999). ALB weighted target groups are the right answer for ECS, EC2, or Fargate Blue/Green deployment strategies when you want to split traffic between two target groups without using CodeDeploy as the orchestrator. CodeDeploy ECS Blue/Green itself uses ALB weighted target groups internally.

Comparison of Traffic-Shifting Deployment Strategies Mechanisms

AWS AppConfig and Feature Flag Deployment Strategies

AWS AppConfig is the managed feature-flag and configuration-deployment service on AWS. It implements deployment strategies at the configuration layer rather than the code layer.

AppConfig Building Blocks

• Application: logical grouping for your app (e.g., checkout-service).
• Environment: deployment target (e.g., prod, staging).
• Configuration Profile: versioned configuration document (feature flag map or free-form JSON/YAML).
• Deployment Strategy: rules for how a configuration version rolls out to the environment.

AppConfig Deployment Strategies Catalog

AppConfig ships four predefined deployment strategies plus support for custom deployment strategies:

• AppConfig.AllAtOnce — 100 percent of targets receive the new configuration immediately.
• AppConfig.Linear50PercentEvery30Seconds — 50 percent at T+0, 100 percent at T+30s.
• AppConfig.Linear20PercentEvery6Minutes — 20 percent every 6 minutes for 30 minutes total.
• AppConfig.Canary10Percent20Minutes — 10 percent for 20 minutes, then 100 percent.

Custom deployment strategies let you specify DeploymentDurationInMinutes, GrowthFactor, GrowthType (LINEAR or EXPONENTIAL), and FinalBakeTimeInMinutes for a post-100% observation window.

AppConfig Automatic Rollback

AppConfig monitors CloudWatch alarms specified in the deployment strategy; if an alarm enters ALARM during the deployment or during the FinalBakeTime, AppConfig automatically rolls back the environment to the previous configuration version. This is the feature-flag deployment strategies equivalent of CodeDeploy's alarm-based rollback.

AppConfig Feature Flag Deployment Strategies Use Cases

Feature flag deployment strategies are the correct exam answer whenever the scenario says:

• "Deploy the code now but enable the feature later."
• "Turn the feature on only for specific user segments."
• "Kill-switch an existing feature without redeploying."
• "Roll out a config change gradually with automatic rollback on error rate."

Monitoring and Rollback Triggers for Deployment Strategies

Every production-quality deployment strategies implementation requires observability to trigger rollback. The DVA-C02 exam tests three primary rollback trigger mechanisms.

CloudWatch Alarms as Deployment Strategies Rollback Triggers

CloudWatch alarms are the canonical rollback trigger across CodeDeploy (Lambda, ECS, EC2) and AppConfig. The deployment configuration references alarm ARNs; any alarm entering ALARM halts the deployment and initiates rollback. Common alarm targets for deployment strategies:

• Lambda Errors, Throttles, Duration P99.
• API Gateway 5XXError, Latency P99.
• ECS service RunningTaskCount drop, ALB target group UnHealthyHostCount.
• Custom EMF metrics for business-level errors (failed checkouts, payment failures).

CloudWatch Synthetics Canaries

CloudWatch Synthetics canaries are scheduled Puppeteer/Selenium scripts that hit your application as a real user would and publish pass/fail metrics. Pair a synthetic canary with a CloudWatch alarm on the canary's SuccessPercent metric, and you have end-to-end functional rollback triggers for any deployment strategies — covering the gap that metric-only alarms miss (e.g., the API returns HTTP 200 but the HTML is broken).

X-Ray Error Rate as a Deployment Strategies Signal

AWS X-Ray publishes trace-level error and fault rates that CloudWatch can alarm on via X-Ray metrics. In a deployment strategies context, X-Ray catches regressions that pure Lambda or API Gateway metrics miss — e.g., downstream DynamoDB throttling that only appears once the new Lambda code changes its access pattern. X-Ray-based alarms feed into the same CodeDeploy AlarmConfiguration mechanism.

The Deployment Strategies Decision Tree

Use this decision tree to pick the right deployment strategies for any DVA-C02 scenario.

Step 1: Can old and new versions run simultaneously?

• No (breaking schema change, incompatible clients): All-at-Once deployment strategies with maintenance window. Accept downtime.
• Yes: proceed to Step 2.

Step 2: What is the target compute platform?

• AWS Lambda: Step 3L.
• Amazon ECS: Step 3E.
• EC2 Auto Scaling: Step 3A.
• Elastic Beanstalk: Step 3B.
• Configuration-only change (no code): AppConfig deployment strategies (Canary10Percent20Minutes or Linear20PercentEvery6Minutes).

Step 3L: Lambda Deployment Strategies Selection

• Need "test small percentage then full shift": Canary10Percent5Minutes (or 15/30/60-min variant depending on validation time).
• Need "gradual continuous ramp": Linear10PercentEvery10Minutes (or faster variants for low-risk changes).
• Dev/test only, speed > safety: AllAtOnce.
• Need feature toggle without redeploy: AppConfig feature flag.

Step 3E: ECS Deployment Strategies Selection

• Need instant rollback + test listener validation: CodeDeploy Blue/Green on ECS with ALB.
• Need simple gradual task replacement, no second listener: ECS rolling update with minimumHealthyPercent=100, maximumPercent=200.
• Need long manual validation window (hours to days): ECS Blue/Green with terminationWaitTimeInMinutes up to 2880.

Step 3A: EC2 Auto Scaling Deployment Strategies Selection

• Need ASG-level swap with instant rollback: CodeDeploy Blue/Green with ASG swap behind ELB.
• Need AMI rotation only, no CodeDeploy: ASG Instance Refresh with MinHealthyPercentage=100.
• Need app-only update on existing instances, low-risk: CodeDeploy In-place (OneAtATime or HalfAtATime).

Step 3B: Elastic Beanstalk Deployment Strategies Selection

• Speed matters, risk tolerated (dev): All at once.
• No capacity drop, low complexity: Rolling with additional batch.
• Need new fleet with no in-place changes: Immutable.
• Need percentage-based canary: Traffic splitting.
• Need near-instant rollback with environment isolation: Beanstalk Blue/Green via CNAME swap (environment clone).

Deployment Strategies Cheat Sheet by Risk Profile

Common DVA-C02 Deployment Strategies Exam Traps

The exam repeatedly tests the same deployment strategies distinctions. Study these traps.

Canary vs Linear Deployment Strategies Confusion

Canary deployment strategies shift a fixed small percentage first (typically 10%), wait a fixed window, then shift 100%. Linear deployment strategies shift equal small increments throughout the rollout. If the scenario mentions "10 percent first, wait, then rest," the answer is Canary. If the scenario mentions "equal shifts every N minutes," the answer is Linear.

Alias vs Version Distinction in Lambda Deployment Strategies

Lambda versions are immutable frozen snapshots; they cannot be shifted or weighted. Lambda aliases are mutable pointers that can carry weighted routing configuration. Any Lambda deployment strategies question asking "which construct carries the weighted traffic split" is always alias — never version.

Rolling vs Rolling with Additional Batch Deployment Strategies

Rolling deployment strategies temporarily reduce capacity by the batch size; Rolling with Additional Batch does not (extra capacity is provisioned first). If the scenario mentions "no capacity reduction during deploy," the answer is Rolling with Additional Batch.

Blue/Green vs Immutable Deployment Strategies

Blue/Green keeps both environments live during cutover for instant rollback. Immutable tears down the old environment once the new one is healthy — rollback requires rebuilding the old environment. Scenarios stressing "instant rollback" pick Blue/Green; scenarios stressing "never modify live hosts" pick Immutable.

API Gateway Stage Canary vs Lambda Alias Canary Deployment Strategies

Both are canary deployment strategies at different layers. API Gateway canary deployment strategies operate at the HTTP stage; they are configured via canarySettings on the stage and split traffic between two API Gateway deployments. Lambda alias canary deployment strategies operate at the function invocation level; they are configured via alias weighted routing and split invocations between two function versions. Use API Gateway canary when the scenario specifies REST API changes; use Lambda alias canary when the scenario specifies Lambda code changes.

Beanstalk Blue/Green Is Not a Deployment Policy

Beanstalk deployment policies do not include Blue/Green. Blue/Green deployment strategies on Beanstalk are implemented via cloning and a CNAME swap. Any answer listing "Blue/Green" as a Beanstalk deployment policy is wrong.

ECS Blue/Green Requires ALB

ECS Blue/Green deployment strategies via CodeDeploy require an Application Load Balancer with two target groups and two listeners. If the scenario describes NLB, CLB, or direct Fargate task exposure, ECS Blue/Green is not available; the correct answer is ECS rolling update.

CodeDeploy AllAtOnce Has No Alarm Rollback Window

CodeDeploy AllAtOnce for Lambda shifts 100 percent instantly — there is no canary or linear window during which CloudWatch alarms could fire to trigger rollback. If the scenario requires "automated rollback on error spike," AllAtOnce is wrong; the answer is Canary or Linear.

Deployment Strategies Limits and Quotas

• CodeDeploy deployments per account per region: 1,000 active deployments.
• Lambda alias weighted routing: maximum 2 versions per alias (primary + one additional version).
• CodeDeploy Lambda deployment configurations: custom configs accepted via CreateDeploymentConfig.
• ECS Blue/Green terminationWaitTimeInMinutes: 0–2880 minutes (0–48 hours).
• AppConfig custom deployment strategies DeploymentDurationInMinutes: 0–1440 minutes.
• AppConfig FinalBakeTimeInMinutes: 0–1440 minutes.
• API Gateway canary percent traffic: 0.0–100.0 percent.
• Route 53 weighted routing weight: 0–255.
• ALB weighted target group weight: 0–999.

FAQ: Deployment Strategies Top 7 Questions

Q1: Which Lambda CodeDeploy deployment configuration shifts 10 percent of traffic for 5 minutes then the remaining 90 percent?

CodeDeployDefault.LambdaCanary10Percent5Minutes. This is a canary deployment strategies configuration — fixed 10 percent window, fixed 5-minute wait, then 100 percent. It is the most commonly cited canary answer on DVA-C02 because the 5-minute window is long enough to catch error-rate spikes via CloudWatch alarms but short enough to keep total deployment time under 10 minutes.

Q2: How does automatic rollback work for Lambda deployment strategies?

CodeDeploy for Lambda deployment strategies rolls back automatically when a CloudWatch alarm listed in the deployment group's AlarmConfiguration enters ALARM at any point during the canary or linear window, OR when a pre-traffic or post-traffic hook reports Failed. Rollback re-points the Lambda alias to the previous version with 100 percent weight, restoring the pre-deployment state within seconds.

Q3: What is the difference between ECS rolling update and ECS Blue/Green deployment strategies?

ECS rolling update uses the ECS deployment controller and gradually replaces tasks within the same service, bounded by minimumHealthyPercent and maximumPercent. ECS Blue/Green deployment strategies use the CODE_DEPLOY deployment controller and require an ALB with two target groups and two listeners; CodeDeploy manages a test listener for validation before shifting production traffic, and supports a manual validation wait window up to 48 hours before terminating the old task set.

Q4: Can I use Blue/Green deployment strategies on Elastic Beanstalk?

Yes, but not as a deployment policy. Beanstalk Blue/Green deployment strategies are implemented by cloning the current environment, deploying the new version to the clone, validating on the clone's URL, and swapping environment CNAMEs. Beanstalk deployment policies (All at once, Rolling, Rolling with additional batch, Immutable, Traffic splitting) do not include "Blue/Green" — CNAME swap is the Blue/Green mechanism on Beanstalk.

Q5: What is the difference between a pre-traffic hook and a CloudWatch alarm for Lambda deployment strategies?

A pre-traffic hook (BeforeAllowTraffic) is a Lambda function that runs synthetic tests against the newly deployed version BEFORE any production traffic shifts to it. A CloudWatch alarm monitors metrics (errors, throttles, latency) DURING the canary or linear window after traffic has started shifting. Pre-traffic hooks catch issues before users see them; CloudWatch alarms catch issues that only appear under real-user load. Best practice is to layer both for any production Lambda deployment strategies.

Q6: When should I use AWS AppConfig feature flag deployment strategies versus Lambda canary deployment strategies?

Use AppConfig feature flag deployment strategies when the change is configuration-only (a flag, a threshold, a string) and the code to handle both states is already deployed. Use Lambda canary deployment strategies when the change involves new code in the Lambda function itself. Feature flags decouple deployment from release — you ship code dark, then flip the flag — while Lambda canaries are the code-level deployment mechanism. Combine them: deploy new code behind a feature flag via Lambda canary deployment strategies, then roll the flag via AppConfig.

Q7: How does Route 53 weighted routing compare to ALB weighted target groups for Blue/Green deployment strategies?

Route 53 weighted DNS operates at the DNS layer with minute-scale TTLs; shifts propagate slowly and client-side DNS caching can keep stale answers alive. ALB weighted target groups operate at the HTTP layer with per-request granularity; shifts are immediate. Use Route 53 weighted routing for cross-region or cross-stack Blue/Green deployment strategies (e.g., migrating between two entirely separate AWS accounts). Use ALB weighted target groups for within-region Blue/Green or canary deployment strategies where immediate, precise traffic percentages matter. Lambda alias weights are even finer-grained and operate at the invocation level for Lambda-backed services.

Deployment Strategies Summary for DVA-C02

Deployment strategies are the skeleton of Domain 3. Master the seven-archetype taxonomy (In-Place, Rolling, Rolling with Additional Batch, Immutable, Blue/Green, Canary, Linear, Feature Flag) and memorize the exact CodeDeploy configuration names for Lambda (Canary10Percent5Minutes, Linear10PercentEvery10Minutes, AllAtOnce). Know that Lambda deployment strategies pivot on alias weighted routing; ECS Blue/Green deployment strategies require an ALB with dual listeners; EC2 deployment strategies include CodeDeploy Blue/Green with ASG swap and native Instance Refresh; Beanstalk Blue/Green is a CNAME swap, not a deployment policy; AppConfig feature flag deployment strategies decouple deployment from release. Always pair deployment strategies with CloudWatch alarms, Synthetics canaries, and pre-traffic hooks for layered rollback triggers. Walk into the exam with the decision tree above and every deployment strategies question becomes a sub-minute answer.