Whether you've just heard about CodeDeploy, are preparing for an AWS certification exam, or want to add automated deployments to your project, this guide is for you. I've tried to make this understandable for all levels, and this is the clearest explanation I've come across, so I wanted to share it with everyone.
Key Concepts to Know First
Before diving in, here are some AWS terms you'll encounter:
- EC2 (Elastic Compute Cloud) – Virtual servers in the AWS cloud
- S3 (Simple Storage Service) – Object storage for files, often used to store deployment packages
- ECR (Elastic Container Registry) – A container image registry (like Docker Hub, but AWS-managed) where you store your Docker images
- ECS (Elastic Container Service) – AWS's container orchestration service that runs and manages Docker containers
- Lambda – Serverless compute service where you run code without managing servers
What is Deployment, Really?
At its core, deployment means sending your application from your local machine (or a repository) to servers (also called instances) where it will actually run.
The Old Way (Manual Deployment)
Before automation tools, deploying meant:
- SSH into the server
- Download the new code
- Stop the old application
- Start the new one
- Test if it's working
- Repeat for every server
Doing this for 2-3 servers? Manageable. Doing it for 100 servers? A nightmare.
The CodeDeploy Way
AWS CodeDeploy automates all of this. It handles stopping old applications, downloading new code, starting new versions, and validating everything is working—across as many servers as you need.
Where Can CodeDeploy Deploy To?
CodeDeploy supports four deployment targets:
| Target | Description |
|---|---|
| EC2 Instances | Virtual servers in AWS |
| On-Premises Servers | Your own physical servers in a data center |
| Lambda Functions | Serverless functions (CodeDeploy handles traffic shifting from v1 to v2) |
| ECS Services | Container-based applications running in ECS |
Note on ECS & Containers: Each container holds a version of your application, but they all run in the same standardized environment. Thanks to Docker, your app runs the same way on any device.
Where Does the Code Come From?
The application code doesn't magically appear in CodeDeploy—it needs a source.
For EC2 and On-Premises Deployments
| Source | How It Works |
|---|---|
| S3 Bucket | Upload your code as a .zip file; CodeDeploy downloads and extracts it |
| GitHub | CodeDeploy clones the repository directly |
| Bitbucket | Same as GitHub—clones the repository |
For Lambda Deployments
The code is already in Lambda (typically uploaded via S3 as a .zip file). CodeDeploy's job here is to shift traffic from the old version to the new version—not to move code around.
For ECS Deployments
The container image lives in ECR (Elastic Container Registry). CodeDeploy orchestrates deploying the new container version to your ECS service.
No Code Changes Required!
Here's something important: you don't need to modify your application code to use CodeDeploy.
You don't need to:
- Add the AWS SDK to your app
- Include special CodeDeploy libraries
- Write CodeDeploy-specific code in CloudFormation templates
Instead, you use a single configuration file: appspec.yml
The AppSpec.yml File
The appspec.yml file sits alongside your application files and tells CodeDeploy how to deploy. Think of it as deployment instructions.
It defines:
- Where to put files
- What scripts to run
- When to run them (using lifecycle hooks)
Example Structure
version: 0.0
os: linux
files:
- source: /
destination: /var/www/myapp
hooks:
BeforeInstall:
- location: scripts/backup.sh
timeout: 300
AfterInstall:
- location: scripts/install_dependencies.sh
timeout: 300
ApplicationStart:
- location: scripts/start_server.sh
timeout: 300
CodeDeploy Lifecycle Hooks
Understanding lifecycle hooks is crucial for debugging. When something fails, CodeDeploy typically tells you which hook failed. Knowing what each hook does helps you pinpoint the problem.
Here's the deployment sequence:
| # | Hook | What Happens |
|---|---|---|
| 1 | ApplicationStop | Stops the currently running application |
| 2 | DownloadBundle | Downloads new code from S3/GitHub/Bitbucket |
| 3 | BeforeInstall | Runs pre-installation tasks: backup current files, decrypt files, clean up old deployments |
| 4 | Install | Copies new files to the destination directory |
| 5 | AfterInstall | Post-installation tasks: configure the app, set file permissions, install dependencies |
| 6 | ApplicationStart | Starts the new version of the application |
| 7 | ValidateService | Verifies the application is running correctly (health checks) |
Clarifications
"Decrypt files" (BeforeInstall): If your deployment bundle contains encrypted files (for security—like config files with secrets), this hook runs scripts to decrypt them before installation.
"Set permissions" (AfterInstall): This means setting Linux file permissions (like chmod 755) so the application can read, write, or execute files as needed. For example, making a script executable or ensuring log directories are writable.
Deployment Strategies
CodeDeploy offers several deployment strategies. Choosing the right one depends on your tolerance for risk vs. speed.
Strategy Availability by Target
- EC2/On-Premises: All strategies focused on instance-by-instance deployment
- Lambda: Traffic-shifting strategies (Canary, Linear, All-at-Once)
- ECS: Container-focused strategies (Blue/Green, Canary, Rolling)
1. All-at-Once
Deploy to all servers simultaneously
- ✅ Fastest deployment
- ❌ Riskiest—if something breaks, everything breaks
- 📍 Best for: Development/testing environments
2. One-at-a-Time
Deploy to one server, verify, then move to the next
- ✅ Safest—issues affect only one server at a time
- ❌ Slowest—100 servers = 100 sequential deployments
- 📍 Best for: Critical production systems where safety > speed
3. Rolling Deployment
Deploy to servers in batches (e.g., 25% at a time)
- ✅ Balanced approach between speed and safety
- ❌ Reduced capacity during deployment
- 📍 Best for: Production systems with some traffic tolerance
4. Rolling with Additional Batch
Add extra servers first, then do rolling deployment
- ✅ Maintains full capacity throughout deployment
- ❌ Temporarily higher infrastructure costs
- 📍 Best for: Production systems that can't afford reduced capacity
5. Blue/Green Deployment
Create a complete duplicate environment (Green), deploy there, then switch traffic
- ✅ Zero downtime
- ✅ Easy rollback—just switch traffic back to Blue
- ❌ Requires double the infrastructure temporarily
- 📍 Best for: Mission-critical applications requiring zero downtime
6. Canary Deployment
Deploy to a small percentage first (e.g., 10%), monitor, then deploy to the rest
- ✅ Limits blast radius of failures
- ✅ Real production testing with minimal risk
- ❌ Requires good monitoring to catch issues
- 📍 Best for: Gradual rollouts, A/B testing scenarios
7. Immutable Deployment
Launch entirely new instances with the new version, then terminate old ones
- ✅ Clean deployments—no state carried over
- ✅ Easy rollback
- ❌ Slower and more resource-intensive
- 📍 Best for: Environments where consistency is critical
Quick Comparison Table
| Strategy | Speed | Risk | Downtime | Best For |
|---|---|---|---|---|
| All-at-Once | ⚡ Fastest | 🔴 High | Possible | Dev/Test |
| One-at-a-Time | 🐢 Slowest | 🟢 Lowest | Minimal | Critical systems |
| Rolling | ⚡ Fast | 🟡 Medium | Minimal | Balanced needs |
| Rolling + Batch | ⚡ Fast | 🟡 Medium | None | Full capacity needed |
| Blue/Green | ⚡ Fast | 🟢 Low | None | Zero-downtime required |
| Canary | 🐢 Slow | 🟢 Low | None | Gradual rollouts |
| Immutable | 🐢 Slow | 🟢 Low | None | Clean deployments |
Summary
AWS CodeDeploy transforms deployment from a manual, error-prone process into an automated, reliable workflow. Key takeaways:
- CodeDeploy automates deployments to EC2, on-premises servers, Lambda, and ECS
- Source code comes from S3, GitHub, or Bitbucket (or ECR for containers)
-
No code changes needed—just add an
appspec.ymlfile - Lifecycle hooks control what happens at each deployment stage
- Choose your strategy based on your risk tolerance and downtime requirements
I'm at the very beginning of my AWS journey, and I tried my best to explain this concept in my own words. If you have any additional information, corrections, or insights about CodeDeploy, please share in the comments, I'd happy to learn from you as well!
Top comments (0)