Pilot light vs warm standby: same data, different compute posture
Both keep your data hot in a second Region. The only real difference is whether the standby servers are running, and that difference is what sets your recovery time.
The DR spectrum, and why the middle matters
AWS describes four disaster recovery strategies along a single spectrum that trades cost against recovery speed: backup and restore, pilot light, warm standby, and multi-site active/active. Backup and restore is cheapest but slowest, because you must redeploy infrastructure and restore data in the recovery Region before you can serve anything. Multi-site active/active is fastest (recovery time near zero) but the most complex and costly, because you run full production in more than one Region at once.
Pilot light and warm standby sit in the middle and are the two that get confused most often. Both are active/passive: the primary Region serves all traffic, and a second Region stands by for recovery. Both keep data continuously replicated to the DR Region so the recovery point is small. What separates them is not the data layer at all, it is the compute posture in the standby Region.
The four DR strategies on one cost-vs-recovery spectrum
Trace
All four strategies keep one primary Region serving live traffic. What changes is the DR Region posture: backup and restore holds only backups and redeploys on demand (cheapest, slowest); pilot light keeps data hot but compute off; warm standby runs a small live fleet; multi-site runs full production in both Regions (costliest, near-zero recovery). Moving right raises steady-state cost and lowers recovery time. Pilot light and warm standby sit in the middle and both keep data continuously replicated, so the data layer is not what separates them.
Pilot light: data hot, compute cold
With the pilot light approach you replicate your data to the DR Region and provision a copy of your core infrastructure, but you keep the application servers switched off. The resources needed for data replication and backup, such as databases and object storage, are always on. The application servers are loaded with code and configuration but are not running; the AWS best practice for 'switched off' is actually to not deploy the server at all and instead hold the configuration to deploy it when needed.
Because the compute layer is cold, a pilot light Region cannot process requests until you take additional action first: you turn on (or deploy) the servers, possibly deploy additional non-core infrastructure, and then scale up. This keeps the ongoing cost low, since you are not paying for running application capacity you are not using. AWS Elastic Disaster Recovery (DRS) is a managed implementation of exactly this strategy: it continuously block-level replicates servers into a staging area of switched-off resources, then builds a full-capacity deployment when failover is triggered.
Pilot light: data hot, compute cold, built by AWS DRS on failover
Trace
In pilot light the DR Region keeps the data layer always on (Aurora replica with sub-second lag, S3 cross-Region replication) while the application servers are switched off; the AWS best practice is to not deploy them at all and hold the configuration. AWS Elastic Disaster Recovery (DRS) implements this by continuously block-level replicating servers into a switched-off staging area. Because compute is cold, the Region cannot process requests until failover triggers a full-capacity build (CloudFormation deploys the ALB and app fleet, DRS launches the staged servers), which keeps steady-state cost low but adds a turn-on step to recovery.
Warm standby: a small copy that is always awake
Warm standby extends the pilot light concept by keeping a scaled-down but fully functional copy of the production environment always running in the second Region. Because that copy is already deployed and running, it can handle traffic at reduced capacity immediately. On failover you only need to scale it up to full production capacity; you do not need to turn anything on first.
That 'always awake' property is the whole point of the trade. AWS notes that the difference between pilot light and warm standby can be hard to see because both hold copies of the primary Region's assets. The distinction is precise: pilot light cannot process requests without additional action taken first, whereas warm standby can handle traffic (at reduced levels) immediately. Because warm standby only requires a scale-up rather than a turn-on-then-scale-up, it gives a lower recovery time than pilot light, at a higher steady-state cost because the small fleet runs continuously. It also makes continuous testing easier, since there is always a live environment to exercise.
Warm standby: a scaled-down fleet that is always awake
Trace
Warm standby keeps a small but fully functional copy of production always running in the DR Region, so it can take reduced traffic the instant Route 53 flips DNS. Failover needs only a scale-up, not a turn-on: EC2 Auto Scaling grows the always-on fleet from reduced to full capacity while the small fleet already serves. The Aurora replica is promoted to writer in under a minute. Steady-state cost is higher than pilot light because the small fleet runs continuously, but recovery time is lower and the live environment makes continuous testing easy.
Failover mechanics: keep the trigger on the data plane
For an active/passive design, all traffic initially goes to the primary Region and switches to the DR Region when the primary is unavailable. Amazon Route 53 health checks monitor the endpoints and can trigger automatic DNS failover; this is a highly reliable operation because it runs on the data plane, which AWS designs for higher availability than the control plane. For manually initiated failover, Amazon Application Recovery Controller (ARC) provides Route 53 routing controls that act as on/off switches you toggle through a data plane API, rather than editing DNS records directly (a weighted-record change would be a less resilient control plane operation).
The data layer follows the same logic. An Amazon Aurora global database replicates to the secondary Region with typical latency under one second, and if the primary Region degrades you can promote a secondary to take read/write responsibility in under one minute. One caution the exam likes: Amazon EC2 Auto Scaling is a control plane activity, so relying on it to scale your DR Region up during a disaster lowers overall resiliency. A common mitigation is to pre-provision enough capacity to absorb the initial traffic (ensuring a low recovery time) and then let Auto Scaling ramp up for the rest.
Failover mechanics: trigger on the data plane, beware the control plane
Trace
For active/passive DR, traffic goes to the primary until it fails. Route 53 health checks (a data plane operation AWS builds for high availability) flip DNS to the DR endpoint automatically; for manual failover, Application Recovery Controller exposes routing controls you toggle through a data plane API instead of editing weighted DNS records (a less resilient control plane change). The Aurora global database promotes a secondary to writer in under a minute. The caution: EC2 Auto Scaling is a control plane activity, so pre-provision enough baseline capacity to absorb initial traffic and let Auto Scaling only ramp the remainder.
