Pilot Light

Pilot light is a disaster recovery strategy in which a small, essential part of a workload remains operational in a recovery location. The name refers to a small flame that can ignite a larger system when needed. In cloud architectures, that essential core commonly includes replicated databases or a replication staging environment, while application servers and other production components are stopped or deployed only during recovery. The recovery environment is not normally ready to serve the full application without additional actions.

Start by defining the recovery time objective, or RTO, and recovery point objective, or RPO. RTO is the target maximum time to restore service after disruption. RPO expresses the acceptable amount of data loss measured in time. Pilot light can support a low RPO through ongoing replication, but asynchronous replication can still lose recent writes. Its RTO includes incident detection, recovery authorization, data promotion or recovery, infrastructure provisioning, application startup, validation, and traffic redirection. Neither objective is guaranteed simply by selecting this strategy.

For example, an online retailer might operate its production application in one cloud region and maintain a replicated database in another. Network definitions, machine images, application artifacts, configuration, and infrastructure templates are prepared for the recovery region. Application compute remains absent or stopped. During a regional outage, an automated workflow promotes the recovery database, launches application instances, configures their database endpoints, verifies checkout transactions, and redirects customer traffic. Database promotion and compute provisioning should follow a tested dependency order.

The distinction from other disaster recovery strategies is important. Backup and restore primarily rebuilds from stored recovery copies rather than maintaining an operational replicated core. Warm standby maintains a scaled-down but functional copy of the complete workload that can already handle traffic at reduced capacity. Active-active operates the workload in multiple locations serving production traffic. Pilot light generally costs less than warm standby because less infrastructure runs continuously, but it usually requires more recovery work and a longer RTO. These are relative trade-offs, not fixed recovery-time guarantees.

Infrastructure as code and recovery automation make pilot light practical. Engineers should prepare identity permissions, encryption-key access, network connectivity, secrets, certificates, software artifacts, and service quotas in the recovery location. A database replica alone does not make an application recoverable. Available compute capacity must also be considered: a quota increase permits resource creation but does not reserve physical capacity.

Replication is not a substitute for backups. Accidental deletion, corruption, or malicious changes can propagate into the recovery environment. Retain independently recoverable backups, use appropriate retention and protection controls, and test point-in-time recovery where supported. On AWS, AWS Backup can complement the replicated core with protected recovery points, but scheduled backup copies alone do not constitute a pilot light architecture.

Run recovery exercises that measure application-level results rather than just successful resource creation. Check replication lag, restore or promotion duration, capacity availability, dependency connectivity, and the effect of DNS caching on traffic cutover. Prevent simultaneous conflicting writers by isolating the original primary before enabling recovery writes. Finally, document failback: recovering in a second region does not automatically synchronize changes back to the original environment or make the return transition safe.