AWS Deployment Methodologies: EC2, Containers, and Serverless
Deployment methodologies for various platforms (for example, Amazon EC2, Amazon Elastic Container Service [Amazon ECS], Amazon Elastic Kubernetes Service [Amazon EKS], Lambda)
AWS Deployment Methodologies: EC2, Containers, and Serverless
Learning Objectives
After studying this guide, you should be able to:
- Differentiate between mutable and immutable deployment patterns across various compute platforms.
- Select the appropriate deployment strategy (Blue/Green, Canary, Rolling) based on business resiliency requirements.
- Configure CodeDeploy components, including Deployment Groups and AppSpec files, for EC2, ECS, and Lambda.
- Analyze deployment lifecycle events to troubleshoot failed updates.
- Implement cross-Region and Multi-AZ deployment patterns to minimize downtime.
Key Terms & Glossary
- Mutable Infrastructure: Infrastructure that is updated in place. For example, SSH-ing into an EC2 instance to update software versions.
- Immutable Infrastructure: Infrastructure that is never modified after deployment. Instead, new instances or containers are launched from a fresh image (AMI or Docker image) to replace the old ones.
- Canary Deployment: A strategy where a small percentage of traffic is shifted to the new version to test stability before a full rollout.
- Blue/Green Deployment: A strategy that involves two identical environments. "Blue" is the current production, and "Green" is the new version. Traffic is toggled once Green is validated.
- AppSpec File: A YAML or JSON formatted file used by CodeDeploy to manage the deployment hooks and permissions.
- Deployment Group: A set of individual instances or a service (like ECS) targeted for a deployment.
The "Big Idea"
In the AWS DevOps Professional domain, deployment is not just about moving code; it is about orchestrating risk. By moving from mutable, manual updates to automated, immutable pipelines, teams can achieve high availability and rapid recovery. Whether you are managing long-running EC2 instances, elastic container clusters (ECS/EKS), or event-driven Lambda functions, the goal remains the same: Zero-downtime updates with automated rollbacks.
Formula / Concept Box
| Deployment Type | Primary Characteristic | Best For... |
|---|---|---|
| In-Place | Updates existing instances (Mutable) | Non-critical apps, small fleets |
| Rolling | Updates instances in batches | Balancing cost and availability |
| Blue/Green | Provisions new fleet, swaps traffic (Immutable) | High availability, fast rollbacks |
| Canary | Incremental traffic shifting (e.g., 10% then 100%) | Testing new features with real users |
Hierarchical Outline
- Deployment Foundations
- Mutable vs. Immutable: Risks of "configuration drift" in mutable setups.
- Artifact Management: Using S3, ECR, and CodeArtifact for versioned source control.
- Platform-Specific Methodologies
- Amazon EC2: Uses CodeDeploy Agent; supports In-place and Blue/Green.
- Amazon ECS: Managed via Task Sets; primary strategy is Blue/Green via CodeDeploy.
- AWS Lambda: Uses Traffic Shifting (Aliases); Linear vs. Canary updates.
- Amazon EKS: Utilizes Kubernetes-native strategies (RollingUpdate) or external tools like Flux/ArgoCD.
- The Deployment Lifecycle (CodeDeploy Hooks)
- BeforeInstall / AfterInstall: Pre/Post scripts for dependencies.
- ApplicationStart / ValidateService: Checking health before routing traffic.
Visual Anchors
Deployment Strategy Selection
Blue/Green Traffic Shifting Concept
Definition-Example Pairs
- Immutable Pattern
- Definition: A deployment approach where you never patch a server, but replace it entirely.
- Example: Using EC2 Image Builder to create a new AMI for every software update, ensuring every instance in a cluster is bit-for-bit identical.
- Traffic Shifting
- Definition: The process of incrementally moving user requests from an old version of a Lambda function to a new version.
- Example: Updating a Lambda function alias to point 10% of traffic to version 2 (Canary) for 10 minutes before shifting the remaining 90%.
Worked Examples
Scenario: Configuring a Lambda Canary Deployment
Goal: Deploy a new Lambda function version where 10% of traffic is sent to the new version for a 5-minute bake period.
- Version the Function: Publish a new version of the Lambda code.
- Create an Alias: Point an alias (e.g.,
prod) to the old version. - Define AppSpec:
yaml
version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "MyProcessor" Alias: "prod" CurrentVersion: "1" TargetVersion: "2" Hooks: - PreTraffic: "BeforeAllowTrafficLambdaFunction" - PostTraffic: "AfterAllowTrafficLambdaFunction" - Deployment Configuration: Select
LambdaCanary10Percent5Minutesin CodeDeploy.
Checkpoint Questions
- Which CodeDeploy lifecycle hook is used to verify that a service is running correctly before it starts receiving production traffic?
- What is the main advantage of an Immutable deployment over a Mutable one regarding "configuration drift"?
- In an ECS Blue/Green deployment, what AWS service handles the actual rerouting of traffic?
[!TIP] Answers: 1.
ValidateService. 2. It eliminates drift because instances are replaced rather than modified. 3. Application Load Balancer (ALB).
Muddy Points & Cross-Refs
- ECS vs. EKS Scaling: While ECS is AWS-native and integrates deeply with CodeDeploy for Blue/Green, EKS often requires Kubernetes Autoscalers (HPA/VPA) and differs in how it handles rolling updates (via
Deploymentmanifests). - Lambda@Edge: Note that Lambda@Edge (used for CloudFront) does not support CodeDeploy traffic shifting aliases; deployments here are managed through CloudFront distribution updates.
Comparison Tables
Platform Comparison: CodeDeploy Capabilities
| Feature | EC2 | ECS | Lambda |
|---|---|---|---|
| Agent Required? | Yes | No | No |
| AppSpec Format | YAML | YAML/JSON | YAML/JSON |
| Traffic Shifting | DNS/LB Swap | ALB Target Group Swap | Alias Weighting |
| In-Place Support | Yes | No | No |
| Rollback Method | Redeploy old version | Swap Target Groups | Update Alias |
Comparison: Mutable vs. Immutable
| Aspect | Mutable | Immutable |
|---|---|---|
| Process | Patching existing servers | Replacing servers with new ones |
| Speed | Faster for small changes | Slower (image build time) |
| Reliability | Low (drift occurs) | High (consistent state) |
| Rollback | Complex (must undo changes) | Simple (terminate new, keep old) |