This chapter covers canary and linear deployment patterns for deploying applications on AWS, which are key topics in the DVA-C02 exam under Domain 3: Deployment (Objective 3.4: Deploy and manage applications using AWS services). These patterns allow you to shift traffic gradually to a new version, reducing risk and enabling quick rollback. Expect 2-3 exam questions on these patterns, often comparing them to blue/green deployments or testing your understanding of how they work with AWS services like CodeDeploy, Elastic Beanstalk, and Lambda.
Jump to a section
Imagine you are a building manager responsible for upgrading the lighting system in a 100-floor office tower. A canary deployment is like testing a new light fixture on just one desk on the first floor. You watch that desk for a week — if no one gets a headache and productivity doesn't drop, you roll the fixture out to the whole floor, then to all floors. A linear deployment is like a dimmer switch: you start with the lights at 10% brightness (10% of users get the new fixture), then gradually turn it up to 20%, 30%, and so on until 100% — each step happens on a fixed schedule, like 10% every 5 minutes. In both cases, if a problem appears (a flicker or a fire), you can instantly turn the dimmer back to 0% or remove the canary fixture. The key difference: canary tests a small sample for a fixed observation period before proceeding; linear shifts traffic in predictable increments without waiting for validation between steps. Both reduce blast radius compared to a full cutover, but canary is safer because it includes a manual or automated verification gate.
What Are Canary and Linear Deployment Patterns?
Canary and linear deployments are strategies for releasing a new version of an application to production incrementally, rather than replacing all instances at once. They are part of the broader category of "rolling deployments" but differ in how traffic is shifted.
Canary deployment: A small percentage of traffic (e.g., 5%) is routed to the new version for a defined observation period (e.g., 10 minutes). If no errors occur, the traffic percentage is increased in steps (e.g., 25%, 50%, 75%, 100%) with validation at each step. The term comes from the "canary in a coal mine" — the early warning of a problem.
Linear deployment: Traffic is shifted from the old version to the new version in equal, predefined increments at fixed time intervals, without waiting for validation between steps. For example, shift 10% of traffic every 10 minutes until 100%.
Both patterns are supported by AWS CodeDeploy, Elastic Beanstalk (rolling with additional batch), and can be implemented manually using Application Load Balancer (ALB) target groups or Lambda traffic shifting.
Why Use These Patterns?
The primary goal is to reduce the blast radius of a bad deployment. If the new version has a bug or performance issue, only a small subset of users is affected initially. This allows you to detect problems early and roll back quickly. In contrast, a blue/green deployment swaps all traffic at once — if the new version is broken, all users are impacted until the rollback.
How It Works Internally
#### AWS CodeDeploy Implementation
CodeDeploy supports canary and linear deployments for EC2/On-Premises and Lambda. For EC2, it uses a load balancer (ALB or ELB) to shift traffic. The deployment configuration defines:
Traffic percentage per increment: e.g., 10%
Time between increments: e.g., 5 minutes
Number of increments: Determined by the percentage and the final target (100%)
For a canary deployment, you typically have a single canary increment (e.g., 10%) followed by a full deployment after a wait time. For linear, you have multiple equal increments.
Example: CodeDeployDefault.LambdaCanary10Percent5Minutes means:
Shift 10% of traffic to the new version.
Wait 5 minutes.
Shift the remaining 90% (or 100% depending on definition).
Example: CodeDeployDefault.LambdaLinear10PercentEvery5Minutes means:
Every 5 minutes, shift 10% of traffic to the new version.
After 50 minutes, 100% of traffic is on the new version.
#### Elastic Beanstalk Rolling Deployments
Elastic Beanstalk offers "rolling" and "rolling with additional batch" deployment policies. While not strictly canary/linear, they are similar:
Rolling: Deploy the new version to a percentage of instances (e.g., 50%) at a time, with a health check pause between batches. If health checks fail, the deployment stops.
Rolling with additional batch: Same as rolling, but first launches a new batch of instances (e.g., 1 instance) with the new version, then proceeds with rolling updates. This preserves full capacity during deployment.
#### Lambda Traffic Shifting
Lambda aliases can shift traffic between two versions using a weighted alias. This is a pure canary/linear pattern:
Create two versions: $LATEST (new) and a stable version (e.g., v1).
Configure the alias with a routing config: e.g., "routingConfig": { "additionalVersionWeights": { "2": 0.1 } } sends 10% of invocations to version 2.
Update the weights over time.
This can be automated with CodeDeploy using the same deployment configurations mentioned above.
Key Components, Values, and Defaults
- Deployment configurations in CodeDeploy: Predefined configurations include:
- CodeDeployDefault.LambdaCanary10Percent5Minutes
- CodeDeployDefault.LambdaCanary10Percent10Minutes
- CodeDeployDefault.LambdaCanary10Percent15Minutes
- CodeDeployDefault.LambdaLinear10PercentEvery1Minute
- CodeDeployDefault.LambdaLinear10PercentEvery2Minutes
- CodeDeployDefault.LambdaLinear10PercentEvery3Minutes
- CodeDeployDefault.LambdaLinear10PercentEvery10Minutes
- For EC2: similar but with EC2 prefix.
- Traffic shifting interval: For canary, a single interval; for linear, multiple intervals.
- Health check grace period: In Elastic Beanstalk, the time to wait before checking health after deploying to a batch (default: 600 seconds).
- Rollback triggers: CloudWatch alarms can automatically roll back a CodeDeploy deployment if metrics breach thresholds.
Configuration and Verification
To configure a canary deployment in CodeDeploy for Lambda:
Create an application and deployment group.
In the deployment group, select a deployment configuration (e.g., CodeDeployDefault.LambdaCanary10Percent5Minutes).
Specify the Lambda function alias and the new version.
Optionally, add an alarm that triggers a rollback.
To verify the deployment:
aws deploy get-deployment --deployment-id d-EXAMPLELook for deploymentInfo.status and deploymentInfo.deploymentOverview.
Interaction with Related Technologies
CloudWatch Alarms: Used to trigger automatic rollbacks if the error rate or latency spikes.
Auto Scaling Groups: In EC2 deployments, CodeDeploy works with ASGs to update instances.
Application Load Balancer: Used to route traffic between old and new target groups in blue/green deployments, but can also be used for canary by adjusting weights.
AWS Lambda: Supports traffic shifting via aliases and weighted routing.
Exam Tips
The exam often asks you to choose between canary, linear, and blue/green for a given scenario.
Know the predefined configurations: canary has a single wait, linear has multiple equal waits.
Remember that canary deployments require a validation step (manual or automated) before proceeding; linear does not.
Be aware that Elastic Beanstalk's "rolling with additional batch" is not exactly canary but is often compared.
Understand that Lambda traffic shifting is done via alias weights, not through CodeDeploy directly (though CodeDeploy orchestrates it).
Create deployment group and config
In AWS CodeDeploy, you define a deployment group that specifies the target compute platform (EC2, Lambda, or ECS), the service role, and the deployment configuration. For a canary deployment, you choose a configuration like `CodeDeployDefault.LambdaCanary10Percent5Minutes`. This configuration tells CodeDeploy to shift 10% of traffic to the new version and then wait 5 minutes. For linear, you choose a configuration like `CodeDeployDefault.LambdaLinear10PercentEvery1Minute`. The deployment group also includes optional rollback triggers — CloudWatch alarms that can automatically revert the deployment if metrics indicate failure.
Deploy new version to target
You initiate a deployment by specifying the application name, deployment group, and the revision (the new version of your code). For Lambda, this is a Lambda function version or alias. For EC2, it's a ZIP file or GitHub repository. CodeDeploy then deploys the new version to the target instances or Lambda function. At this point, the new version is installed but not yet serving traffic — it exists alongside the old version.
Shift initial traffic percentage
CodeDeploy shifts the specified percentage of traffic to the new version. For a canary deployment with `10Percent5Minutes`, it shifts 10% of traffic. For linear with `10PercentEvery1Minute`, it shifts 10%. This is done by updating the load balancer target group weights (for EC2) or the Lambda alias routing configuration (for Lambda). The old version continues to serve the remaining traffic.
Wait for observation period
For canary deployments, CodeDeploy waits for the specified time (e.g., 5 minutes) before proceeding. During this time, you or an automated system should monitor metrics like error rates, latency, and CloudWatch alarms. If an alarm is triggered, CodeDeploy can automatically roll back to the previous version. For linear deployments, CodeDeploy does not wait for validation — it proceeds to the next increment after the time interval expires. This is a critical difference: canary includes a validation gate, linear does not.
Complete traffic shift
After the observation period (canary) or after all increments (linear), CodeDeploy shifts the remaining traffic to the new version. For a canary with 10% initial shift, it shifts the remaining 90%. For linear, it continues shifting at fixed intervals until 100%. Once complete, the old version can be terminated or kept for rollback. The deployment status changes to "Succeeded" if all health checks pass.
Enterprise Scenario 1: E-Commerce Checkout Microservice
A large e-commerce company deploys a new checkout microservice version that includes a payment gateway change. They use a canary deployment with CodeDeploy and Lambda. They route 5% of checkout traffic to the new version for 10 minutes. During the canary, they monitor the transaction success rate and latency via CloudWatch. If the error rate exceeds 1%, a CloudWatch alarm triggers an automatic rollback. This setup catches a bug where the new payment API returns a different error code for declined cards, which was not handled by the frontend. The canary prevents 95% of users from seeing the error. After fixing, they complete the deployment. The configuration uses CodeDeployDefault.LambdaCanary5Percent10Minutes.
Enterprise Scenario 2: Social Media Feed Update
A social media platform wants to update its feed algorithm. They choose a linear deployment to gradually expose users to the new algorithm over 30 minutes. They use Elastic Beanstalk with a rolling deployment policy that deploys to 20% of instances every 6 minutes. This is not a true linear traffic shift but a linear instance replacement. However, they also configure the load balancer to route traffic to old and new instances proportionally. The linear approach allows them to monitor overall system health without a manual gate. If they had used a canary, they would have needed a longer observation period, which might delay the launch. The deployment is considered successful if no major spikes in CPU or error rates occur.
Performance Considerations
Canary: The observation period should be long enough to detect issues (e.g., 5-15 minutes). Too short, and you might miss latent bugs. Too long, and deployment time increases.
Linear: The interval between increments must be sufficient for the system to stabilize (e.g., 1-10 minutes). If too short, you might overwhelm the system with rapid changes.
Rollback: Automatic rollback via alarms is critical in production. Without it, a bad deployment can propagate to 100% before a human intervenes.
Common Misconfigurations
Setting the canary percentage too high (e.g., 50%) defeats the purpose of limiting blast radius.
Not configuring rollback alarms — if the canary fails, the deployment continues to full rollout.
Using linear deployment for mission-critical systems without automated monitoring — a bug can spread quickly.
Confusing canary with blue/green: blue/green swaps all traffic at once after validation; canary shifts gradually.
What DVA-C02 Tests on This Topic (Objective 3.4)
The exam focuses on your ability to select the appropriate deployment pattern based on requirements such as risk tolerance, deployment speed, and validation needs. Specific objectives include: - 3.4: Deploy and manage applications using AWS services. - Sub-areas: Implement deployment strategies (rolling, blue/green, canary, linear) using AWS CodeDeploy, Elastic Beanstalk, and Lambda.
Common Wrong Answers and Why Candidates Choose Them
Choosing blue/green when canary is better: Blue/green is faster and simpler, but it has a larger blast radius. Candidates often pick it because they think it's "safer" due to the ability to roll back instantly. However, the exam scenario may emphasize "minimizing impact of a bad deployment" — that points to canary.
Selecting linear over canary for risk-averse scenarios: Linear deployments shift traffic without validation, so they are riskier. Candidates might assume linear is safer because it is gradual, but the lack of a validation gate is a key difference.
Confusing canary with rolling in Elastic Beanstalk: Elastic Beanstalk's "rolling" replaces instances in batches, not traffic percentages. Candidates may incorrectly apply canary concepts to instance-based deployments.
Misremembering predefined configurations: For example, thinking CodeDeployDefault.LambdaLinear10PercentEvery10Minutes has a validation step. It does not — it shifts 10% every 10 minutes regardless of health.
Specific Numbers and Terms That Appear on the Exam
Predefined configuration names: LambdaCanary10Percent5Minutes, LambdaLinear10PercentEvery3Minutes.
Default percentages: 10% for canary, 10% for linear.
Time intervals: 1, 2, 3, 5, 10, 15 minutes.
The term "canary" comes from "canary in a coal mine."
Edge Cases and Exceptions
Lambda canary deployments require an alias with routing config; you cannot shift traffic to a version directly.
CodeDeploy canary and linear are not supported for in-place deployments on EC2 — only blue/green or rolling updates are available for EC2 in-place.
Elastic Beanstalk does not natively support canary traffic shifting; you would need to use a load balancer and target groups manually.
How to Eliminate Wrong Answers
If the scenario says "gradually shift traffic with automatic rollback on alarm," look for canary or linear with alarm. But if it says "validate before proceeding," it must be canary.
If the scenario says "deploy to 10% of instances every 5 minutes," that is a rolling update, not a traffic shift.
If the scenario mentions "minimize blast radius," canary is usually best.
If the scenario says "deploy quickly without manual intervention," linear may be preferred.
Canary deployments shift a small percentage of traffic, wait for validation, then shift the rest.
Linear deployments shift traffic in equal increments at fixed intervals without validation.
CodeDeploy predefined configurations: LambdaCanary10Percent5Minutes, LambdaLinear10PercentEvery1Minute.
Canary is safer than linear because it includes a validation gate.
Lambda traffic shifting uses alias weights; EC2 uses load balancer target groups.
Elastic Beanstalk rolling deployments replace instances, not shift traffic percentages.
Automatic rollback can be triggered by CloudWatch alarms in CodeDeploy.
For risk-averse scenarios, choose canary; for speed without validation, choose linear.
These come up on the exam all the time. Here's how to tell them apart.
Canary Deployment
Shifts a small percentage of traffic initially (e.g., 10%)
Includes a waiting period for validation (e.g., 5 minutes)
Requires a manual or automated gate before proceeding
Safer for high-risk deployments due to validation
Predefined configurations: LambdaCanary10Percent5Minutes
Linear Deployment
Shifts traffic in equal increments (e.g., 10% every 1 minute)
No waiting for validation between increments
Proceeds automatically on schedule
Faster but riskier; suitable for low-risk deployments
Predefined configurations: LambdaLinear10PercentEvery1Minute
Mistake
Canary and linear deployments are the same thing.
Correct
They differ in validation: canary includes a wait and validation step after the initial traffic shift; linear shifts traffic in fixed increments without waiting for validation.
Mistake
Elastic Beanstalk's 'rolling' deployment is a canary deployment.
Correct
Elastic Beanstalk's rolling deployment replaces instances in batches, not traffic percentages. It is not a true canary traffic shift; it is an instance-level rolling update.
Mistake
Linear deployments are safer than canary because they are gradual.
Correct
Linear deployments shift traffic without validation between increments, so a bug can propagate to all users quickly. Canary is safer because it includes a validation gate.
Mistake
CodeDeploy canary deployments require manual approval.
Correct
CodeDeploy canary deployments can be fully automated with CloudWatch alarms triggering rollback. Manual approval is optional via approval stages in CodePipeline, not inherent to canary.
Mistake
You can use canary deployments for in-place updates on EC2 with CodeDeploy.
Correct
CodeDeploy supports canary/linear only for Lambda and ECS. For EC2, CodeDeploy supports blue/green deployments, not canary/linear traffic shifting in-place.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Blue/green deployment involves running two full environments (blue = current, green = new) and switching all traffic at once after validation. Canary deployment shifts traffic gradually, starting with a small percentage. Blue/green has a larger blast radius because if the green environment fails, all traffic is affected until rollback. Canary limits impact to a small subset initially. Blue/green is simpler and faster for rollback (just switch back to blue), while canary provides more granular control.
Use Lambda aliases with traffic shifting. Create an alias that points to the stable version. Then update the alias routing configuration to send a percentage of traffic to the new version. This can be automated with AWS CodeDeploy using a canary deployment configuration like `CodeDeployDefault.LambdaCanary10Percent5Minutes`. CodeDeploy will shift 10% of traffic, wait 5 minutes, then shift the rest. You can also use CloudWatch alarms to trigger automatic rollback.
Elastic Beanstalk does not natively support canary traffic shifting. Its rolling deployment policies replace instances in batches, which is not a traffic shift. To achieve canary-like behavior, you can use an Application Load Balancer with two target groups: one for the current version and one for the new version. Gradually adjust the weights on the load balancer listener rules. This requires custom scripting or CodeDeploy integration.
For canary: `CodeDeployDefault.LambdaCanary10Percent5Minutes`, `10Percent10Minutes`, `10Percent15Minutes`. For linear: `CodeDeployDefault.LambdaLinear10PercentEvery1Minute`, `2Minutes`, `3Minutes`, `10Minutes`. Also available: `CodeDeployDefault.LambdaAllAtOnce` (blue/green). These are the only predefined configurations for Lambda; you can create custom ones.
In CodeDeploy, you can configure rollback triggers using CloudWatch alarms. For example, if the error rate exceeds a threshold, the alarm triggers a rollback. CodeDeploy will automatically redeploy the previous version and shift all traffic back. You can also manually roll back using the AWS CLI or console. The rollback uses the same deployment configuration but with the previous revision.
The predefined canary configurations use 10% as the initial traffic percentage. You can create custom configurations with different percentages (e.g., 5%, 20%). However, the exam focuses on the predefined ones. For linear, the default increment is also 10%.
CodeDeploy supports canary/linear only for Lambda and ECS (blue/green). For EC2, CodeDeploy supports blue/green deployments (replace instances in a new Auto Scaling group) and in-place rolling updates. To achieve canary-like traffic shifting for EC2, you would need to use an Application Load Balancer with target groups and manually adjust weights, possibly with a custom script or a third-party tool.
You've just covered Canary and Linear Deployment Patterns — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?