Cargando...
Cargando...
Automate application deployments to any compute target — EC2, Lambda, ECS, or on-premises — with zero downtime strategies
AWS CodeDeploy is a fully managed deployment service that automates application deployments to Amazon EC2 instances, AWS Lambda functions, Amazon ECS services, and on-premises servers. It eliminates the need for manual, error-prone deployment steps by supporting advanced strategies like blue/green, canary, and rolling deployments. CodeDeploy integrates natively with CodePipeline, CloudWatch, and Systems Manager to provide end-to-end deployment automation with built-in rollback capabilities.
Automate and standardize application deployments across diverse compute environments while minimizing downtime and deployment risk through configurable deployment strategies and automatic rollback
Use When
Avoid When
EC2/On-Premises Deployments
Requires CodeDeploy agent installed on target instances; supports in-place and blue/green
AWS Lambda Deployments
Shifts traffic between Lambda function versions using aliases; supports Canary, Linear, and AllAtOnce configurations
Amazon ECS Deployments
Blue/green only for ECS; integrates with Application Load Balancer to shift traffic between task sets
Blue/Green Deployments
Supported for EC2, Lambda, and ECS; for EC2, CodeDeploy can automatically provision new instances via Auto Scaling
In-Place (Rolling) Deployments
EC2/On-Premises only — NOT supported for Lambda or ECS
Canary Traffic Shifting (Lambda/ECS)
e.g., CodeDeployDefault.LambdaCanary10Percent5Minutes shifts 10% then 90% after 5 minutes
Linear Traffic Shifting (Lambda/ECS)
e.g., CodeDeployDefault.LambdaLinear10PercentEvery1Minute shifts 10% per minute
Automatic Rollback
Triggered by deployment failure or CloudWatch alarm breach; rolls back to last known good revision
Lifecycle Event Hooks
appspec.yml hooks vary by compute platform: EC2 has 8 hooks, Lambda/ECS have BeforeAllowTraffic and AfterAllowTraffic
On-Premises Server Support
Register on-premises servers with IAM user or IAM role credentials; requires CodeDeploy agent and outbound internet/VPC endpoint access
GitHub Integration
Direct integration with GitHub repositories as a deployment source without S3
CodePipeline Integration
CodeDeploy is a native deploy action provider in CodePipeline
Load Balancer Integration
Deregisters instances during deployment to prevent traffic to unhealthy instances; required for blue/green ECS
SNS Notifications
Trigger SNS on deployment events (start, success, failure, rollback)
CloudWatch Alarms-based Rollback
Monitor metrics during deployment; auto-rollback if alarm fires — a key differentiator from manual deployments
Cross-Account Deployments
Supported via CodePipeline cross-account actions with appropriate IAM role trust policies
AWS Systems Manager Integration
Can use SSM Parameter Store for configuration values referenced in deployment scripts
Full CI/CD Pipeline Deploy Stage
high freqCodePipeline orchestrates the end-to-end pipeline with CodeDeploy as the Deploy action. CodePipeline passes the artifact location (S3) to CodeDeploy, which executes the deployment. This is the most common exam scenario — understand that CodePipeline triggers CodeDeploy, not the reverse.
Build-then-Deploy Pattern
high freqCodeBuild compiles code and produces a deployment artifact (ZIP with appspec.yml) stored in S3. CodeDeploy then pulls this artifact and deploys it. CodeBuild does NOT deploy — it only builds. CodeDeploy does NOT build — it only deploys.
Serverless Canary/Linear Deployment
high freqCodeDeploy manages traffic shifting between Lambda function versions using aliases. The appspec.yml defines the Lambda function name, alias, and current/target versions. BeforeAllowTraffic and AfterAllowTraffic hooks validate the deployment. CloudWatch alarms auto-rollback if error rates spike.
Alarm-Driven Automatic Rollback
high freqConfigure CloudWatch alarms on key metrics (error rate, latency, CPU). Associate alarms with the CodeDeploy deployment group. If an alarm fires during or after deployment, CodeDeploy automatically rolls back to the previous revision. This is the recommended production safety net.
Infrastructure + Application Deployment
high freqCloudFormation provisions the infrastructure (EC2, ALB, Auto Scaling Groups, ECS clusters). Once infrastructure exists, CodeDeploy handles application code deployments. CloudFormation can also trigger CodeDeploy deployments via custom resources or CodePipeline stages.
Hybrid Fleet Management
high freqSystems Manager manages on-premises and EC2 instances at scale. CodeDeploy deploys application code to the same fleet. SSM Parameter Store provides environment-specific configuration values consumed by CodeDeploy lifecycle hook scripts. SSM can also install/update the CodeDeploy agent via Run Command.
ECS Blue/Green with ALB Traffic Shifting
high freqCodeDeploy creates a replacement ECS task set (green), registers it with the ALB target group, shifts traffic from the original (blue) task set, then terminates the blue set after a configurable wait time. The ALB has two target groups — one for blue, one for green. This is the ONLY deployment type supported for ECS via CodeDeploy.
CodeDeploy is PURELY a deployment automation service — it does NOT migrate databases, transfer data, provision infrastructure, or build code. If a question asks about application deployment automation to EC2/Lambda/ECS/on-premises, CodeDeploy is the answer. If it asks about database migration, the answer is AWS DMS.
In-place deployments are ONLY for EC2 and on-premises. Lambda and ECS deployments are ALWAYS blue/green with traffic shifting. This is a direct exam question: 'Which compute platforms support in-place deployments?' Answer: EC2 and on-premises ONLY.
The appspec.yml file MUST be at the ROOT of the deployment bundle for EC2/on-premises deployments. For Lambda and ECS, the appspec.yml can be provided directly (not necessarily in a ZIP). A misplaced appspec.yml causes an immediate deployment failure — this is tested in scenario questions.
CodeDeploy does NOT provide API call logging or audit trails — that is AWS CloudTrail. CloudWatch provides metrics and logs monitoring. Do not confuse: CodeDeploy deployment events → CloudWatch Events/EventBridge; API calls to CodeDeploy → CloudTrail; application metrics during deployment → CloudWatch Metrics.
For Lambda deployments, CodeDeploy uses ALIASES to shift traffic between function versions. You cannot shift traffic between Lambda functions without aliases. The appspec.yml must specify CurrentVersion and TargetVersion. Understand the three traffic-shifting configurations: AllAtOnce, Canary (two increments), and Linear (equal increments over time).
In-place deployments = EC2/On-premises ONLY. Lambda and ECS = blue/green with traffic shifting ONLY. This is non-negotiable and directly tested.
CodeDeploy deploys code artifacts — it does NOT build code (that's CodeBuild), does NOT provision infrastructure (that's CloudFormation), and does NOT migrate databases (that's DMS). Know the service boundary cold.
CloudTrail logs WHO made API calls to CodeDeploy (audit). CloudWatch monitors metrics/logs DURING deployments. These are different services — do not conflate monitoring with auditing.
Only ONE deployment can run per deployment group at a time. If a new deployment is triggered while one is running, you can configure it to stop the current deployment and start the new one, or queue it. This single-deployment-per-group constraint is a frequent exam distractor.
The three built-in deployment configurations are: CodeDeployDefault.AllAtOnce, CodeDeployDefault.HalfAtATime, and CodeDeployDefault.OneAtATime. For EC2, these define what percentage of instances receive the deployment simultaneously. For Lambda/ECS, the built-in configs use Canary and Linear naming conventions (e.g., LambdaCanary10Percent5Minutes).
CodeDeploy requires the CodeDeploy agent on EC2 and on-premises instances. The agent is NOT required for Lambda or ECS deployments. The agent polls CodeDeploy for deployment instructions — it uses HTTPS outbound traffic. Ensure security groups and NACLs allow outbound HTTPS (443) from instances.
For blue/green EC2 deployments, CodeDeploy can automatically provision replacement instances through an Auto Scaling Group. The original instances are the 'blue' environment; CodeDeploy creates new instances (green), deploys to them, shifts the load balancer, then optionally terminates the blue instances after a wait period. This is different from ECS blue/green which uses task sets.
Automatic rollback in CodeDeploy can be triggered by: (1) deployment failure (a lifecycle hook script exits with non-zero), (2) CloudWatch alarm breach during deployment, or (3) manual rollback. Rollback deploys the LAST SUCCESSFULLY DEPLOYED revision — it does NOT undo file changes on instances; it redeploys the previous artifact.
EC2/On-Premises deployments are FREE for instances within AWS. You are only charged for on-premises instance updates beyond the free tier (first 100 instance updates per month are free). Lambda and ECS deployments are always free. This pricing model is tested in cost-optimization scenarios.
When integrating CodeDeploy with an Auto Scaling Group, instances launched by scale-out events automatically receive the last successful deployment. This ensures new instances always run the current application version without manual intervention — a key benefit for exam scenarios about maintaining consistency in auto-scaled fleets.
Common Mistake
CodeDeploy can be used to migrate databases or transfer data between environments as part of a deployment
Correct
CodeDeploy is exclusively an application deployment automation service. It deploys code artifacts (ZIP files, JAR files, Docker image references) to compute targets. Database migrations require AWS DMS, custom scripts in lifecycle hooks (as a workaround, not the primary purpose), or dedicated migration tools. Data transfer uses AWS DataSync, S3, or Transfer Family.
Exam questions frequently present scenarios involving 'moving an application to a new environment' and include CodeDeploy alongside DMS as answer choices. The key discriminator: CodeDeploy = application code deployment; DMS = database migration. If the scenario mentions schema changes, data replication, or database engine changes, CodeDeploy is NOT the answer.
Common Mistake
CloudWatch provides comprehensive logging of all API calls made to CodeDeploy, so you can audit who triggered deployments
Correct
CloudWatch monitors metrics and logs (application/system logs). AWS CloudTrail logs API calls to CodeDeploy (who triggered a deployment, from which IP, with which credentials). CodeDeploy deployment events are published to Amazon EventBridge/CloudWatch Events for automation triggers. These are three distinct services with distinct purposes.
This misconception appears directly in exam questions asking 'Which service provides an audit log of CodeDeploy API calls?' The answer is always CloudTrail, not CloudWatch. Remember: CloudTrail = WHO did WHAT API call; CloudWatch = WHAT is happening with metrics/logs.
Common Mistake
In-place deployments can be used for Lambda functions to update function code without downtime
Correct
Lambda deployments via CodeDeploy are ALWAYS blue/green with traffic shifting using Lambda aliases. There is no in-place deployment type for Lambda. CodeDeploy shifts traffic from the current Lambda version to a new version using an alias, enabling canary and linear traffic shifting strategies. In-place is only valid for EC2 and on-premises.
This is tested by presenting a scenario where a developer wants to 'update a Lambda function with zero downtime using CodeDeploy' and asking which deployment type to choose. Candidates who don't know that Lambda only supports blue/green will incorrectly choose 'in-place.' Always remember: Lambda = blue/green only via CodeDeploy.
Common Mistake
CodeDeploy automatically builds and packages the application artifact before deploying it
Correct
CodeDeploy is a pure deployment service — it does NOT build code. The deployment artifact (ZIP, TAR, or S3 bundle) must be pre-built and stored in S3 or GitHub before CodeDeploy can deploy it. CodeBuild handles the build step. In a CodePipeline, the typical flow is: Source (CodeCommit/GitHub) → Build (CodeBuild) → Deploy (CodeDeploy).
Exam scenarios describe a complete CI/CD pipeline and ask which service performs which function. Candidates who think CodeDeploy builds code will misidentify the Build stage. The clear separation: CodeBuild = compile/test/package; CodeDeploy = deploy the package.
Common Mistake
You can run multiple simultaneous deployments to the same deployment group to speed up large fleet updates
Correct
Only ONE deployment can be active per deployment group at a time. This is a hard constraint. If you trigger a second deployment while one is in progress, CodeDeploy will either queue it or stop the current deployment (configurable). To deploy to multiple environments simultaneously, use MULTIPLE deployment groups (e.g., one per environment or region).
Exam questions about 'how to deploy to dev and prod simultaneously' are traps if you think one deployment group handles both. The correct answer is separate deployment groups per environment. The single-deployment-per-group constraint also means you need proper pipeline gates to prevent accidental concurrent deployments.
Common Mistake
The CodeDeploy agent is required on all compute targets including Lambda and ECS
Correct
The CodeDeploy agent is ONLY required for EC2 instances and on-premises servers. Lambda and ECS deployments are managed entirely through AWS APIs — no agent is needed on Lambda functions or ECS container instances. Installing or managing an agent for Lambda/ECS deployments is unnecessary and impossible.
This appears in questions about deployment prerequisites. If a scenario asks 'what must be installed on the target before CodeDeploy can deploy?' — for EC2/on-premises the answer includes the CodeDeploy agent; for Lambda/ECS there is no agent requirement. Confusing this leads to incorrect architecture recommendations.
Common Mistake
CodeDeploy rollback restores files on instances to their previous state by reversing the deployment changes
Correct
CodeDeploy rollback works by redeploying the last successfully deployed revision as a NEW deployment — it does not reverse individual file changes or run an 'undo' operation. This means rollback creates a new deployment entry in the deployment history. If the rollback deployment fails, the instance may be in an indeterminate state.
Understanding rollback mechanics is critical for designing resilient deployment strategies. Exam scenarios may ask 'what happens when a CodeDeploy rollback is triggered?' The answer is: a new deployment of the previous revision is initiated, not a file-system-level restore.
BLIC — CodeDeploy supports: Build? No. Launch? Yes (blue/green EC2). In-place? EC2/On-prem only. Canary/Linear? Lambda/ECS only.
Agent = EC2 + On-Prem ONLY. Remember 'AEO' — Agent for EC2/On-premises, Never for Lambda/ECS.
Deployment Platform Matrix: 'EL Blue, EC In-Place' — ECS and Lambda = Blue/green ONLY; EC2 = both In-place AND Blue/green.
CloudTrail = WHO called the API (audit); CloudWatch = WHAT is happening (metrics/logs); CodeDeploy Events = WHEN deployment state changes (triggers).
AppSpec ROOT rule: 'Root or Ruin' — appspec.yml at the root of your bundle or your deployment is ruined.
CertAI Tutor · DVA-C02, SAA-C03, SAP-C02, DEA-C01, DOP-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns