AWS Deployment Strategies: Master Guide for DVA-C02

Deploying application versions effectively is a core competency for an AWS Developer. This guide focuses on the various strategies used to roll out updates, specifically within the context of AWS Elastic Beanstalk, while maintaining the balance between cost, deployment speed, and application availability.

Learning Objectives

After studying this guide, you should be able to:

Differentiate between the five primary deployment strategies: All-at-Once, Rolling, Rolling with Additional Batch, Immutable, and Traffic Splitting.
Select the appropriate strategy based on requirements for downtime and cost.
Explain the rollback mechanism for each deployment type.
Identify the impact of each strategy on Auto Scaling Groups (ASG) and instance capacity.

Key Terms & Glossary

In-place Update: An update where the existing instances are modified to run the new application version.
Downtime: The period during which an application is unavailable to users.
Rollback: The process of returning to a previous stable version of the application after a failed deployment.
Canary Testing: A technique where a small percentage of traffic is routed to a new version to test stability before a full rollout.
ASG (Auto Scaling Group): An AWS service that manages a collection of EC2 instances to ensure the desired number of instances are running.

The "Big Idea"

In the cloud, deployment is not just about moving code; it is about managing risk and resources. Every deployment strategy represents a trade-off between Velocity (how fast can we update?), Availability (will users experience downtime?), and Cost (do we need to pay for extra instances during the transition?). Choosing the right strategy depends on whether the environment is for development (prioritize speed/cost) or production (prioritize availability/safety).

Formula / Concept Box

Strategy	Downtime	Performance Impact	Cost	Rollback Difficulty
All-at-Once	High	High	Low	High (Manual/Re-deploy)
Rolling	None	Moderate (Reduced Capacity)	Low	Moderate
Rolling w/ Batch	None	None	Moderate	Moderate
Immutable	None	None	High (Double capacity)	Low (Delete new ASG)
Traffic Splitting	None	None	High	Low

Hierarchical Outline

In-Place Strategies (Existing Instances)
- All-at-Once: Pushes code to all nodes simultaneously. Fast but lacks high availability.
- Rolling: Updates instances in batches. The environment stays up, but with reduced capacity during the batch update.
Resource-Heavy Strategies (New Instances)
- Rolling with Additional Batch: Launches a new batch of instances first, then updates existing instances in batches to maintain 100% capacity.
- Immutable: Creates a temporary second ASG to test one instance, then scales it up to match the original size before cutting over. Safest but most expensive.
Advanced Traffic Management
- Traffic Splitting (Canary): Uses a weighted approach to send a percentage of real users to the new version while monitoring health.

Visual Anchors

The Immutable Deployment Flow

Loading Diagram...

Traffic Splitting (Canary) Representation

\begin{tikzpicture} % Load Balancer \draw[thick, fill=blue!10] (0,0) rectangle (2,1) node[midway] {ALB};

code

% Arrows
\draw[->, thick] (2,0.5) -- (4,1.5) node[midway, sloped, above] {90\% Traffic};
\draw[->, thick] (2,0.5) -- (4,-0.5) node[midway, sloped, below] {10\% Traffic};

% Target Groups
\draw[thick, fill=green!10] (4,1) rectangle (7,2) node[midway] {v1.0 (Prod)};
\draw[thick, fill=orange!10] (4,-1) rectangle (7,0) node[midway] {v1.1 (Canary)};

\end{tikzpicture}

Definition-Example Pairs

All-at-Once: Deploying updates to all instances at the same time.
- Example: A developer updating a personal blog in a development environment where a 2-minute outage is acceptable to save time.
Immutable Deployment: Provisioning a completely new set of resources instead of updating existing ones.
- Example: A mission-critical financial application where a failed update must be reverted instantly without touching the old, stable servers.
Rolling with Additional Batch: Maintaining full capacity by adding new nodes before taking old ones offline.
- Example: A retail site during a sale that cannot afford any drop in processing power while updating a bug fix.

Worked Examples

Scenario: The Budget-Conscious Production App

Problem: You are managing a production application with 4 instances. You cannot afford downtime, but your company is very strict about cloud costs and does not want to pay for double capacity.

Solution:

Discard All-at-Once (causes downtime).
Discard Immutable and Traffic Splitting (doubles capacity/costs).
Select Rolling Deployment.
Process: Specify a batch size (e.g., 1 instance). One instance is taken offline and updated. 3 instances continue to serve traffic (75% capacity). Once healthy, the next instance is updated. This ensures availability with zero additional instance costs.

Checkpoint Questions

Which deployment strategy results in the longest deployment time but the safest rollback?
If an application is running 10 instances and you use a Rolling deployment with a batch size of 20%, how many instances are active at any given time?
What is the primary difference between a Blue/Green deployment and an Immutable deployment in Elastic Beanstalk?

[!TIP] For the DVA-C02 exam, remember: All-at-Once is the only strategy that causes an actual outage. Immutable is the choice for maximum safety. Rolling is the choice for cost-efficiency.

▶Click to see Checkpoint Answers

Immutable Deployment (Time is high because it provisions a whole new ASG, but rollback is just a delete operation).
8 instances (10 nodes - 20% = 8 nodes active during the batch update).
Immutable creates a new ASG within the same environment; Blue/Green usually involves swapping CNAMEs between two entirely separate Elastic Beanstalk environments.