AWS CodeDeploy
Managed deployment service that automates rolling out application code to EC2, on-premises servers, Lambda, and ECS.
Verified against AWS documentation · 2026-08-28
Key facts
- 01Deploys to four targets: EC2, on-premises instances, Lambda, and ECS — EC2/on-prem need the CodeDeploy agent installed, Lambda/ECS don't
- 02Two deployment types: in-place (update instances where they run, EC2/on-prem only) and blue/green (spin up new environment, shift traffic, keep old one for rollback)
- 03The appspec file (appspec.yml) defines what to copy where and which lifecycle hook scripts to run — no appspec, no deployment
- 04Deployment configs control rollout speed: AllAtOnce, HalfAtATime, OneAtATime for EC2; canary and linear traffic shifting for Lambda/ECS
- 05Automatic rollback triggers on deployment failure or a CloudWatch alarm going off mid-deployment
Exam triggers
Phrases and scenarios that point here.
- "Automate deployments", "eliminate manual deployment steps", "deploy to a fleet of EC2 instances"
- "Zero-downtime deployment" or "gradually shift traffic" → blue/green or canary via CodeDeploy
- "Roll back automatically if the new version fails" → CodeDeploy with rollback on alarm
- Deploying to on-premises servers alongside EC2 with one tool → CodeDeploy (agent + AWS endpoint access is all it needs)
- "Gradually shift a percentage of Lambda traffic to a new version" → CodeDeploy canary/linear deployment config
Not this service
- Full end-to-end pipeline orchestration (source → build → test → deploy) → CodePipeline (CodeDeploy is just the deploy stage)
- Upload code and let AWS manage the whole environment → Elastic Beanstalk
- Provisioning infrastructure itself → CloudFormation (CodeDeploy ships code onto infra that already exists)
Use cases
- 01Replacing the "SSH in and copy files" ritual — a 50-instance web fleet gets the new release rolled out OneAtATime, so a bad build takes down one box, not fifty
- 02Blue/green for a payments API: new version gets full production traffic only after health checks pass, and rollback is a traffic switch, not a redeploy
- 03Canary-releasing a Lambda function — send 10% of traffic to the new version for 10 minutes, auto-rollback if error alarms fire, then shift the rest
- 04Hybrid shops deploying the same release to EC2 and their own data center servers with one deployment group and one appspec
- 05Lifecycle hooks that drain an instance from the load balancer, run DB migrations, then re-register it — deployment choreography as code instead of a runbook
How it's charged
- 01Free for deployments to EC2, Lambda, and ECS — you only pay for the underlying compute resources involved
- 02On-premises deployments are billed per instance update (a deployment to three on-prem servers = three updates); skipped instances aren't charged
- 03No minimum fees, no upfront commitment, no charge for idle applications or deployment groups
- 04Supporting resources bill normally — S3 storage for revisions, plus the duplicate environment running during a blue/green deployment