Pilot Light
A disaster recovery posture where core data is continuously replicated and minimal infrastructure runs, with the rest provisioned only on failover.
Named for the small flame that stays lit so a larger system can be started quickly. The critical components — databases replicating, machine images and infrastructure definitions ready, DNS and network configured — exist and run at minimum scale. Application capacity is created at failover time.
It sits between backup-and-restore (hours to days, cheapest) and warm standby (minutes, more expensive). Typical RTO is tens of minutes to a couple of hours; RPO depends on replication and can be near zero.
The risks are specific and each has bitten people:
Provisioning during an incident depends on the control plane, at exactly the time it may be under stress or capacity-constrained — and a regional event means everyone else is trying to provision in the same secondary region simultaneously. This is the argument against pure pilot light for critical systems and for keeping some capacity reserved.
Untested automation. The infrastructure code that stands up the application must be exercised, or it will fail on a stale AMI reference, an expired certificate, a quota, or a dependency nobody recorded.
Quotas in the secondary region are frequently far lower than in the primary, because nothing ever ran there. This is the single most common pilot-light failure and it is cheap to check in advance.