8.3 Deployment Strategies & Container Deployments

8.3 Deployment Strategies & Container Deployments

CloudOps Blueprint Focus: Delivering continuous application updates without customer downtime or capacity degradation is a vital operational competency on the AWS Certified CloudOps Engineer – Associate (SOA-C03) exam. You must master the architectural trade-offs of in-place, rolling, blue/green, canary, and linear deployments, configure AWS CodeDeploy lifecycle hooks and deployment configurations, govern Amazon ECS rolling update capacity bounds, and enable automated rollbacks using the ECS Deployment Circuit Breaker.

Comparative Architecture of Deployment Strategies

Choosing a deployment strategy balances downtime, costs, release velocity, and rollback complexity:

---

AWS CodeDeploy Architecture & AppSpec Lifecycle Hooks

AWS CodeDeploy automates application deployments across Amazon EC2, on-premises instances, Amazon ECS, and AWS Lambda.

A CodeDeploy deployment comprises:

• Application & Deployment Group: Identifies the software and defines target instances (filtered by EC2 tags or Auto Scaling group), ECS services, or Lambda functions, alongside deployment style and rollback alarms.
• Deployment Configuration: Dictates rollout pace and host health thresholds.
• AppSpec File (appspec.yml): Declarative configuration file specifying file mappings, permissions, and lifecycle hook execution scripts.

CodeDeploy EC2 Lifecycle Hook Execution Order

On Amazon EC2 and on-premises instances, the host-installed CodeDeploy Agent executes lifecycle hook scripts in strict sequential order:

1. ApplicationStop: Stops running application daemons or drains connections.
2. DownloadBundle: Reserved phase where agent extracts revision archives from S3 or GitHub.
3. BeforeInstall: Executes pre-installation tasks (e.g., backing up files, decrypting secrets).
4. Install: Reserved phase where agent copies files to destination directories.
5. AfterInstall: Executes post-installation tasks (e.g., database configs, permissions).
6. ApplicationStart: Starts the updated application daemon or service.
7. ValidateService: Runs verification scripts (e.g., querying /health endpoints). Non-zero exit code halts deployment on that host.

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/app
hooks:
  AfterInstall:
    - location: scripts/configure.sh
      timeout: 120
  ApplicationStart:
    - location: scripts/start.sh
      timeout: 60
  ValidateService:
    - location: scripts/health_check.sh
      timeout: 30

CodeDeploy Deployment Configurations

For EC2 and Auto Scaling groups, CodeDeploy enforces minimum healthy host thresholds:

• CodeDeployDefault.OneAtATime: Updates instances one by one, providing lowest capacity risk.
• CodeDeployDefault.HalfAtATime: Updates up to 50% of the fleet simultaneously, retaining 50% capacity.
• CodeDeployDefault.AllAtOnce: Updates all instances simultaneously, incurring maximum downtime risk.
• Custom Configurations: Defines MinimumHealthyHosts as a count (FLEET_COUNT) or percentage (FLEET_PERCENT), e.g., enforcing 75% fleet availability.

---

Amazon ECS Rolling Updates & Capacity Boundaries

When deploying container updates to Amazon ECS services without CodeDeploy blue/green routing, ECS performs native Rolling Updates governed by two capacity boundaries:

• Minimum Healthy Percent (minimumHealthyPercent): The lower bound of active tasks that must remain in RUNNING state (and pass ALB health checks) during deployment, expressed as a percentage of desiredCount.
• Maximum Percent (maximumPercent): The upper bound of total running tasks (old plus new) permitted during deployment, expressed as a percentage of desiredCount.

Calculating Capacity Boundaries

• Desired: 4, Min: 100%, Max: 200%: Launches 4 new tasks first (total 8). Once healthy, terminates 4 old tasks. Zero downtime, requires 2x compute capacity.
• Desired: 4, Min: 50%, Max: 100%: Terminates 2 old tasks first to free capacity (total drops to 2), then launches 2 new tasks. Incurs temporary 50% capacity reduction.
• Desired: 6, Min: 100%, Max: 150%: Launches 3 new tasks (total 9). Once healthy, terminates 3 old tasks, then provisions final 3. Preserves 100% capacity within account vCPU quotas.
• Desired: 1, Min: 0%, Max: 100%: Terminates the lone task before launching its replacement. Incurs brief downtime.

---

ECS Deployment Circuit Breaker & Automated Rollback

If a new container image crashes on startup or fails container health checks, ECS repeatedly attempts task launches. Without guardrails, this creates an infinite crash-loop where the deployment stalls indefinitely.

The Amazon ECS Deployment Circuit Breaker resolves this failure pattern:

1. Automated Failure Detection: Monitors task launches during rolling updates. If tasks repeatedly fail to enter RUNNING or fail health checks, the deployment is marked as FAILED.
2. Automated Rollback: When configured with rollback: true, the circuit breaker immediately reverts the service to the last stable task definition without manual operator intervention.

---

Amazon ECS Capacity Providers: EC2 & AWS Fargate

An ECS Capacity Provider abstracts compute infrastructure management from container task scheduling:

• AWS Fargate Capacity Providers: Uses FARGATE and FARGATE_SPOT strategies with base allocations and weight ratios to balance cost against interruption resilience.
• EC2 Auto Scaling Capacity Providers: Pairs ECS clusters with Auto Scaling groups, using Managed Scaling (CapacityProviderReservation) and Managed Termination Protection to right-size EC2 capacity without terminating instances hosting running tasks.