Pilot Light and Warm Standby

When your RTO requirement is tighter than a few hours, Backup and Restore is insufficient. The next two DR tiers — Pilot Light and Warm Standby — keep some or all of your infrastructure running in the DR region at all times, reducing the time to recover significantly. Both strategies involve maintaining a DR environment continuously and using Route 53 health-check failover to redirect traffic during a disaster. The difference is how much of the DR environment is actively running.

In the Pilot Light strategy, you keep only the critical core of your system running in the DR region — typically just the database tier with continuous replication. The application servers are NOT running; instead, you maintain pre-built AMIs, launch templates, or infrastructure-as-code that can launch them quickly. Think of it as a gas pilot light that burns very small and can ignite the full flame within minutes when needed. RTO is typically 30-60 minutes.

When the primary region fails and Pilot Light failover is triggered: Step 1 — Promote the RDS Read Replica in the DR region to a standalone primary database. Step 2 — Launch EC2 instances from the pre-built AMI or launch template. Step 3 — Create or activate the Application Load Balancer and register the new EC2 instances. Step 4 — Update application configuration to point to the promoted database endpoint. Step 5 — Route 53 health check failover completes the DNS cutover. Total time: 30-60 minutes.

In the Warm Standby strategy, a complete but scaled-down version of your production environment runs continuously in the DR region. All application tiers are active — web servers, app servers, database — but at reduced capacity (e.g., 2 instances instead of 20). During failover, you scale up the DR environment to match production load. Route 53 automatically cuts over traffic via health-check failover. RTO is typically under 15 minutes. Warm Standby is the most popular DR tier for business-critical applications.

Aurora Global Database is the ideal database technology for Warm Standby DR. The secondary region cluster is always running, always receiving replication (<1 second lag), and can be promoted to a primary in under 1 minute — far faster than promoting an RDS Read Replica (which requires stopping replication and applying remaining lag). This makes Aurora Global Database the recommended choice when your RTO requirement is in the range of minutes rather than tens of minutes.

Both Pilot Light and Warm Standby rely on Route 53 failover routing to automatically redirect traffic. Configure a Primary record pointing to your production region's ALB or endpoint with a health check attached. Configure a Secondary record pointing to your DR region's endpoint. When Route 53 detects the primary health check has failed for the configured threshold, it stops returning the primary record and serves only the secondary record — all within the DNS TTL period.

For Warm Standby to achieve its RTO target, the DR environment must be pre-warmed — fully configured and tested so that scaling up during failover is the only action required. This means: database connections are established and cached, application configuration files reference DR-region endpoints, EC2 instances are in service behind the ALB (even at low count), and health checks are passing. Perform monthly DR drills where you simulate failover to ensure the environment stays current with production configuration.

Keeping your DR environment in sync with production is the hardest operational challenge. If you manually configure production and forget to update DR, your DR environment may not work correctly during a real disaster. The solution is Infrastructure as Code (IaC) with the same templates deployed to both regions. Use AWS CloudFormation StackSets or Terraform with multiple workspaces to deploy identical infrastructure to both regions from a single code base. This eliminates configuration drift.

The cost difference between the two strategies is significant. Pilot Light only costs you the database replica (typically 50-100% of primary DB cost) plus minimal networking in the DR region. Application servers are off, so no EC2 costs. Warm Standby adds the cost of running scaled-down EC2 instances, an ALB, and potentially a smaller cache cluster — typically 15-30% of total production environment cost. The question is whether the faster RTO of Warm Standby justifies the higher ongoing cost.

After the primary region is restored, you need a failback plan to return to it. Failback is often the trickiest part of DR: during the outage, the DR region may have processed new data that needs to be synced back to the primary. For databases, you may need to set up reverse replication or re-sync from DR to primary. For Route 53, you reinstate the primary record with its health check. Always plan and test your failback procedure as carefully as the failover itself.

Choose Pilot Light when: your RTO allows 30-60 minutes and you want to minimise DR costs. The primary risk is the time needed to launch and configure application servers during a disaster under pressure. Choose Warm Standby when: your RTO requires recovery within 15 minutes, your application is complex enough that launching it fresh during a disaster is risky, or your SLA commitment to customers demands faster recovery. For most medium-criticality production workloads, Warm Standby is the right balance.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Pilot Light keeps only the database running in DR and launches application servers during failover, Warm Standby runs a complete scaled-down environment that scales up during failover, and Infrastructure as Code prevents configuration drift between primary and DR environments. Always test and plan failback procedures as well as failover. Next up we explore multi-site active-active with DynamoDB Global Tables and Route 53.