Introduction

The smarter disaster recovery pattern for systems that can’t afford to lose data but can wait a few minutes.

Some systems can live with a bit of downtime. Others can’t afford to lose a single transaction. The challenge is finding a disaster recovery strategy that respects both realities without draining your cloud budget. That’s where the Pilot Light pattern comes in. It keeps your core systems, like the database, always ready, while letting everything else rest until it's needed. It’s not overbuilt. It’s not underprepared. It’s just smart. And for many teams, it’s the sweet spot between peace of mind and cost control.

What Is Pilot Light?

Pilot Light is a disaster recovery strategy that focuses on keeping only the most critical parts of your infrastructure, typically the database, running at all times in a secondary region. Everything else, including application servers, load balancers, and APIs, remains dormant until disaster strikes. At that point, the rest of the stack is restored quickly using automation, snapshots, or pre-configured infrastructure templates.

This approach significantly reduces cost compared to fully redundant environments, while still ensuring that your most important data and transactional integrity are always protected. For many systems, this strategy provides a near-instant recovery of the core and a rapid recovery of the surrounding application layer, all without the cost of hot-hot duplication.

Why This Pattern Works

Where traditional backup-only strategies offer low cost at the expense of long recovery time, and fully mirrored regions offer near-zero RTO at great expense, Pilot Light offers a middle path.

It works because it recognizes that not all parts of your system are equal. Your database might handle revenue-generating transactions or mission-critical analytics, while your frontend or API tier can tolerate a few minutes of downtime. Pilot Light embraces that difference. It keeps the “core” always-on, and rebuilds the rest just-in-time.

This results in:

• Database availability 24/7 in a failover region
• Failover times in the tens of minutes, not hours
• Roughly 70% lower cost compared to running full standby environments
• Transaction safety and state integrity, even during major outages
• Minimal blast radius, isolating risk to the application tier

When to Use Pilot Light

This pattern is ideal when your architecture can tolerate partial downtime, but not data loss.

It’s a strong fit for:

• Systems with continuous data updates that must be preserved
• Workloads where frontends can relaunch quickly, but the backend must remain hot
• APIs backed by queues, where messages can buffer while the app layer is restored
• SaaS platforms with acceptable RTOs in the 10–30 minute range
• Organizations that need compliance-level database protection without the cost of full-region duplication

This is not a fit for low-latency applications or systems where every service must remain available at all times. But for 80% of business-critical workloads, it hits a rare balance of speed, cost, and resilience.

How It Works on AWS

A typical Pilot Light setup on AWS includes:

• An always-on database replica in a secondary region (e.g., Amazon RDS cross-region read replica or continuously replicated DynamoDB)
• Ongoing backups and image snapshots of application servers, stored in AWS Backup or S3
• Infrastructure-as-code templates (e.g., CloudFormation or Terraform) that can quickly stand up the rest of the stack when needed
• Manual or automated DNS failover using Route 53 to redirect traffic post-recovery
• A runbook or automation for promoting the database replica to primary, restoring EC2 or container instances, and validating the restored environment

The goal is to have all critical data always available, and all supporting services ready to launch with minimal delay.

Operational Tips

To make the Pilot Light pattern successful, you need to design for rapid bootstrapping. This means keeping your application stateless where possible, ensuring that all infrastructure dependencies are captured in code, and verifying that configuration and secrets are synchronized across environments.

Regular testing is non-negotiable. Recovery procedures should be exercised in staging environments, and metrics like RTO and RPO should be measured and refined. Even a simple quarterly drill can expose drift, gaps, or misconfigured permissions that might otherwise be discovered during an actual outage.

Conclusion

Pilot Light is a practical, cost-aware approach to disaster recovery for teams that want to go beyond backup but stop short of running a full second production environment. It protects your data continuously, restores your apps rapidly, and avoids the cost and complexity of always-on duplication.

If your systems need to stay available where it matters most, but you're willing to wait a few minutes for the rest, this pattern gives you exactly that. It takes your DR game up a notch without sending your cloud bill with it.