Skip to main content
Welcome. This lesson explains the deployment strategies AWS CodeDeploy supports for Amazon EC2, Amazon ECS, and AWS Lambda, and the common approaches used for Amazon EKS. This material is important for real-world deployments and is commonly tested on AWS certification exams.
This topic is frequently tested on AWS exams. Understand the trade-offs between deployment methods (risk, speed, observability, rollback) and when to use rolling, blue‑green, canary, or linear strategies.
Conceptually, deployment is when changes become visible to real users — your “opening day.” Deployment strategies aim to balance speed of release with safety and rollback options. Many modern approaches are variations of blue‑green deployments: maintain two environments (blue = current, green = new) and shift traffic from blue to green. Variants include canary and linear (staged) rollouts as well as simple rolling and all‑at‑once updates. Broad categories of deployment strategies
  • Rolling / one-at-a-time: replace instances or tasks sequentially (low blast radius, slower).
  • Batched (e.g., half-at-a-time): replace in controlled groups and validate between batches.
  • All-at-once: replace everything simultaneously (fast, highest risk).
  • Blue‑green with traffic shifting: duplicate environment and route traffic to the new version; can be staged with canary or linear percentages.
Below we describe how these approaches apply to EC2, ECS, Lambda, and EKS.

​
EC2 (On‑Premises / EC2 instances)

For EC2 instances (including on-premises machines using the CodeDeploy agent), CodeDeploy requires the agent installed on each instance. You choose the concurrency of replacements:
  • One at a time (rolling): update and validate each instance sequentially.
  • Batched (e.g., half-at-a-time): update a subset, validate, then continue.
  • All at once: replace every instance concurrently.
Example behaviors:
  • All‑at‑once: if you have 10 servers, CodeDeploy replaces all 10 simultaneously.
  • Half‑at‑a‑time: update 5, run health checks, then update the remaining 5.
  • One‑at‑a‑time: sequential update and verification per server.
A presentation slide titled "Deployment Methods for EC2/On-Premises Compute Platform" featuring the Amazon EC2 icon and three deployment options: "One at a Time," "Half at a Time," and "All at Once."
The diagram below visualizes a one‑at‑a‑time rollout: v1 instances are replaced by v2 sequentially, allowing verification at each step.
A diagram titled "EC2: One-at-a-Time Deployment Method" showing blue boxes labeled v1 being replaced step-by-step by orange boxes labeled v2 across deployment steps (before, during, after). It illustrates a sequential, one-at-a-time rollout from version v1 to v2.
Use cases:
  • Rolling / batched: stateful services, long startup times, or when you must keep capacity available.
  • All‑at‑once: short-lived tasks or non-critical environments where speed matters more than risk.

​
ECS (Amazon Elastic Container Service)

ECS deployments commonly follow blue‑green principles: new task sets (containers) are launched and traffic is shifted according to a chosen strategy. Common ECS strategies:
  • Linear (staged): shift a fixed fraction at regular intervals (e.g., 25% every 10 minutes).
  • Canary: route a small initial percentage to the new task set, validate, then promote remaining traffic.
  • All‑at‑once: replace all tasks immediately.
Linear deployments allow you to define a fraction and an interval so ECS gradually replaces tasks until the new task set takes 100% of traffic.
A slide titled "ECS: Linear Deployment Method" showing a sequence of boxes representing four service instances that are gradually updated from blue "v1" to orange "v2" across Deployment Steps 1–4.
All‑at‑once is the fastest method and updates every task immediately; it’s suitable for stateless services with fast startup and robust health checks.
A slide titled "ECS: All‑at‑Once Deployment Method" showing a "Before Deployment" row with four blue v1 instances and an "After Deployment" row with four orange v2 instances, illustrating that all instances are updated at once.
When to choose which:
  • Canary: use when you want to validate production traffic against a small sample.
  • Linear: use when you want predictable, time-based ramp-ups.
  • All‑at‑once: use for safe, fast rollouts where risk is acceptable.

​
Lambda (AWS Lambda functions)

Lambda supports blue‑green style deployments by creating new function versions and shifting traffic between versions according to your configuration. Supported patterns:
  • Linear: move a fixed percentage at set intervals (e.g., 25% every 10 minutes).
  • Canary: route a small portion to the new version for a test window (e.g., 10%) then shift to 100% if healthy.
  • All‑at‑once: point 100% of traffic to the new version immediately.
Lambda handles versioning and aliases so you can define traffic routing rules between versions and monitor for errors or latency before promoting.
A diagram showing a linear deployment for a Lambda function: four blue boxes labeled "v1" are initially running, then two are updated to orange "v2" in step 1, and finally all four are "v2" in step 2. The colored boxes represent staged version updates during the rollout.
A canonical canary example: route 10% to v2 and 90% to v1, then, if health checks and metrics look good, move to 100% on v2.
A diagram titled "Lambda: Canary Deployment Method" that shows Phase 1 routing 90% of traffic to blue v1 instances and 10% to orange v2 instances, and Phase 2 switching to 0% v1 and 100% v2.

​
EKS (Amazon Elastic Kubernetes Service)

Kubernetes/EKS workflows are most often managed with GitOps or Kubernetes-native tools rather than CodeDeploy. Common tooling includes kubectl, Helm, Argo CD, Flux, or service-mesh controllers (Istio, AWS App Mesh) and ingress controllers. Typical EKS approaches:
  • Declarative rollouts (Deployment/ReplicaSet) with rolling updates.
  • Canary/Blue‑green via service selectors, traffic-splitting mesh/Ingress, or a Rollout CRD (e.g., Argo Rollouts).
  • GitOps tools (Argo CD, Flux) to automate and observe controlled deployments.
While AWS integrates CodeDeploy with some services, many teams use Kubernetes-native patterns and GitOps controllers to implement staged traffic shifting and rollbacks in EKS.
Tooling and service integrations evolve quickly. Always consult the official AWS and Kubernetes documentation for the latest capabilities and CodeDeploy integrations for EKS.

​
Quick Comparison: Deployment Methods by Service

​
Practical Recommendations

  • Prefer staged rollouts (canary/linear) for user-facing or high-risk changes to limit blast radius and gather real metrics.
  • Use all‑at‑once for low-impact or internal deployments where speed is primary.
  • For stateful services on EC2, favor rolling or batched updates to maintain capacity.
  • For EKS, adopt GitOps or rollout controllers (Argo Rollouts, Istio/App Mesh) to implement fine-grained traffic shifting and automated promotion/rollback.
  • Instrument health checks, telemetry, and automated rollback hooks (CloudWatch alarms, Prometheus alerts) to detect regressions early.

​
Summary

  • Deployment strategies reduce to: rolling (one‑at‑a‑time), batched, all‑at‑once, and blue‑green with traffic shifting (canary/linear).
  • EC2 (with CodeDeploy agent) supports rolling, batched, and all‑at‑once updates.
  • ECS and Lambda support blue‑green style rollouts with linear and canary traffic shifting, plus all‑at‑once.
  • EKS is typically managed with kubectl/Helm or GitOps controllers; use Kubernetes-native tools and service meshes for traffic control.
Good luck on the exam and in your deployments.

Watch Video