Designing deployment solution là part của building well-architected application. Consider:
| Service | Use Case |
|---|---|
| CodeDeploy | Automate deployments to EC2, on-premises, Lambda, ECS |
| CloudFormation | Infrastructure as Code |
| Elastic Beanstalk | PaaS deployment |
| ECS/EKS | Container deployments |
| OpsWorks | Chef/Puppet configuration management |
| S3 + CloudFront | Static website deployment |
Scenario: Single Docker container trong Elastic Beanstalk. Ensure no downtime, no degradation, full capacity during deployment.
Answer: Rolling with Additional Batch + Immutable
| Configuration | Description |
|---|---|
| Linear | Shift traffic in equal increments with equal minutes between |
| Canary | Shift in two increments |
| All-at-once | Shift all traffic immediately |
Scenario thi: Lambda functions, SAM, CodeDeploy, shift traffic every 15 minutes.
Answer: Linear deployment
Why: Linear shifts traffic in equal increments with equal number of minutes between each increment.
Linear10PercentEvery1Minute - 10% every minuteLinear10PercentEvery2Minutes - 10% every 2 minutesLinear10PercentEvery3Minutes - 10% every 3 minutesLinear10PercentEvery10Minutes - 10% every 10 minutesCanary10Percent5Minutes - 10% first, wait 5 min, then 90%Canary10Percent10Minutes - 10% first, wait 10 min, then 90%Canary10Percent15Minutes - 10% first, wait 15 min, then 90%Canary10Percent30Minutes - 10% first, wait 30 min, then 90%$LATEST = mutable, latest codeWorkflow:
1. Develop in $LATEST
2. Test in dev environment
3. Publish version (e.g., v4)
4. Test in beta environment
5. Update prod alias to point to v4
6. Prod now uses v4 (no config changes needed)
Key benefit: Event sources (S3, API Gateway) reference alias ARN, not version ARN. Change alias → change prod version without touching event source config.
$LATEST (development)
↓ publish
v3 (current prod) ← prod alias
v4 (new version) ← beta alias
↓ test & validate
Update prod alias to v4
↓
v4 becomes prod (prod alias → v4)
| Script | Purpose |
|---|---|
| cfn-init | Retrieve metadata, install packages, start services, create files |
| cfn-signal | Signal CloudFormation when resource ready |
| cfn-get-metadata | Retrieve metadata |
| cfn-hup | Detect changes, run hooks |
Scenario thi: Retrieve metadata, install packages, start services, create files?
Answer: cfn-init
# Deploy to specific environment
sam deploy --template template.yaml --stack-name my-app-dev
# Override default template
sam deploy --template custom-template.yaml
Option: --template to specify specific template
Use case: Services behind API Gateway not set up same as consumers. Test all API responses to ensure no issues.
After initial deployment, add more stages:
Stage variables = configuration attributes associated with deployment stage
API
├── Stages (dev, staging, prod)
├── Resources (/orders, /users)
├── Methods (GET, POST, PUT, DELETE)
└── Integrations (Lambda, HTTP, Mock)
Deployment = snapshot of API associated with stage
{proxy+}) - Catches all paths beneath resourceScenario thi: API Gateway passes client requests to backend without intervention after API method set.
Options: HTTP_PROXY, AWS_PROXY, HTTP
Answer: HTTP_PROXY (or AWS_PROXY for AWS services)
Two ways to integrate:
Mock service integrations without calling actual services:
Benefit: Test service integration calls without actual API calls
Exam Tips: