Lesson 188 · AWS Learning Path

AWS 188: Warm standby strategy

Anil Jalela · Published Dec 30, 2025 · 7 min read

Labelled process diagram for AWS 188: Primary and replicated state to Running reduced recovery stack to Controlled traffic shift and scale to Sustained test and failback, with decision, proof and rejection evidence.

Why this lesson matters

Run a scaled-down but functional copy in another Region and define how it scales, receives traffic, protects data, and returns to steady state.

What you will be able to do

By the end, you can:

explain warm standby strategy in plain language;
locate the current service controls in the AWS Management Console;
run the matching CloudShell or AWS CLI queries and explain every important field;
draw the identity, network, data, failure, and monitoring path;
choose the service from requirements and reject it when those requirements are absent;
diagnose a failed or misleading result from evidence;
state the cost owner and prove cleanup or a no-create result.

Before you start

Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

Question	What it means in this lesson
Purpose	Run a scaled-down but functional copy in another Region and define how it scales, receives traffic, protects data, and returns to steady state.
Scope and boundary	The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Warm standby disaster recovery.
Evidence of success	Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Warm standby disaster recovery.
Cost model	Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Safe rejection rule	Avoid calling untested infrastructure warm standby or assuming auto scaling instantly solves cold quotas and dependencies.

How the request flows

+--------------------------------+
|  Primary and replicated state  |
+--------------------------------+
                |
                v
+----------------------------------+
|  Running reduced recovery stack  |
+----------------------------------+
                 |
                 v
+--------------------------------------+
|  Controlled traffic shift and scale  |
+--------------------------------------+
                   |
                   v
+-------------------------------+
|  Sustained test and failback  |
+-------------------------------+

Warm means functional at reduced scale

Warm standby is active/passive DR with a complete, continuously running recovery workload at smaller capacity. It must process a synthetic or restricted business transaction before a disaster. If application tiers are absent until failover, the design is pilot light, not warm standby.

The secondary includes network, edge endpoint, load balancing/API, application compute, data replication, secrets/keys, observability and dependencies. During failover it promotes/fences data where necessary, scales vertically/horizontally, validates production capacity and receives traffic. This raises steady cost but removes major deployment steps from RTO.

Capacity and readiness engineering

Requirement	Proof
Reduced environment is functional	scheduled synthetic write/read through the same request path, with safe test tenant/data
Can absorb production peak	tested scale-out time, quotas, instance/container availability, database scale and queue drainage
Data meets RPO	replication lag/checkpoint and point-in-time backup evidence
No split brain	explicit writer fencing/promotion and failback protocol
Traffic can move	health/readiness gate, certificate, DNS/accelerator configuration and client-cache behavior
Dependencies work	third-party allow lists, email/payment modes, secrets, identity and outbound network path tested

Autoscaling alone is not capacity proof. Minimum/maximum settings, warm-up, target metrics, launch templates, image availability, service quotas and regional capacity all matter. Database scaling or promotion may dominate RTO even when stateless compute grows quickly.

Deployment and configuration parity

Deploy the same immutable release and IaC pipeline to both Regions. Parameterize only true regional differences. Detect drift in policies, routes, certificates, runtime versions, feature flags and schema. A standby many releases behind is not safer; it creates untested migrations during recovery. Use canaries/synthetic transactions continuously without sending real notifications or financial side effects.

Failover and failback gates

Failover order is declare/fence → confirm recovery point → promote data → scale → validate → shift traffic → monitor → establish backup. Automatic traffic failover should depend on application readiness and data role, not one endpoint ping. Failed recovery must have a rollback decision while the primary is still safe.

Failback is another migration: reconcile writes made in recovery, rebuild or validate the former primary, replicate in the reverse direction, test, shift traffic gradually and restore normal replication/backup. Never simply point DNS back.

Architecture decision table

Situation	Direction	Reason
Requirement matches	Use warm standby when the business needs faster recovery and can fund continuous reduced capacity.	Select only after scope, behavior, security, recovery, operations, and price evidence agree.
Requirement does not match	Avoid calling untested infrastructure warm standby or assuming auto scaling instantly solves cold quotas and dependencies.	Rejecting an attractive service is a valid architecture result.
No create permission or cost approval	Use supplied evidence and local design work	Learning does not depend on creating an hourly resource.
Existing resource is unknown or unowned	Inspect only, then stop	Never change or delete a resource merely because it resembles a course example.

AWS Management Console, step by step

Use the Console service search and open Global or replicated database, load balancer, Auto Scaling, ECS, Route 53, and CloudWatch read-only views; confirm the account and Region before reading the page.
Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws autoscaling describe-auto-scaling-groups --query 'AutoScalingGroups[].{Name:AutoScalingGroupName,Min:MinSize,Desired:DesiredCapacity,Max:MaxSize}' --output table
aws elbv2 describe-load-balancers --query 'LoadBalancers[].{Name:LoadBalancerName,State:State.Code,DNS:DNSName}' --output table
aws route53 list-health-checks --output table

Expected interpretation

Warm means the recovery application is continuously runnable at reduced capacity. A failover test must measure data state, scale-up, user path, downstream limits, and sustained load.

Practical work

Design a 20 percent warm standby. Define minimum compute, data replication, background jobs, external integrations, health, traffic shift, scaling time, capacity reservations, RPO/RTO, failover, and failback.

Diagnose this topic from its own evidence

Standby health is green but business transaction fails: test identity, secrets, writes and external dependencies, not /health only.
Scale-out stalls: inspect quota, capacity, launch failure, target health, warm-up and database bottleneck.
Data promotion refuses or creates two writers: inspect replication role/state and fencing runbook before retrying.
Configuration differs: compare IaC release, parameters, policies, routes, certificates and schema migration state.
RTO claim excludes detection/validation/DNS: recompute from incident timeline end to end.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

What operational purpose is this lesson solving?

Expected direction: Run a scaled-down but functional copy in another Region and define how it scales, receives traffic, protects data, and returns to steady state.

Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Warm standby disaster recovery.

What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Warm standby disaster recovery.

Which tempting design or shortcut must be rejected?

Expected direction: Avoid calling untested infrastructure warm standby or assuming auto scaling instantly solves cold quotas and dependencies.

Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

Prove the recovery workload is functional before disaster and distinguish it from pilot light.
Produce tested reduced-to-full capacity timings and quota evidence.
Demonstrate release/configuration parity and safe synthetic transactions.
Document readiness-gated failover, single-writer fencing and observability.
Treat failback as a tested migration with reverse replication and rollback.

Official sources

View complete AWS learning path