Phase 3: Architecture Patterns

Backup & restore, pilot light, warm standby & multi-site active

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building the most amazing Lego castle ever – one with a drawbridge, towers, and even tiny knights! You’ve spent hours on it, and it’s truly a masterpiece. But what if, disaster strikes? Maybe your little sibling accidentally knocks it over, or a mischievous pet decides it’s a chew toy. All that hard work gone in a flash! In the computer world, websites and apps are like those important Lego castles. They need to stay working, even if there’s a power cut or a big computer glitch. This is called "Disaster Recovery" – making sure your awesome digital creations don't get lost or broken forever.

The simplest way to protect your Lego castle is by taking lots of pictures from every angle and writing down notes about how you built each section. If your castle gets knocked down, you can look at your photos and notes, gather new blocks, and start rebuilding it piece by piece. This works, but it takes a lot of time and effort to put everything back together from scratch. In the computer world, we call this "Backup & Restore." It means saving copies of all your important data and computer settings in a safe place. If the main system breaks, you get new computers and then use those saved copies to rebuild everything. It’s the cheapest way, but it also takes the longest to get your website or app working again.

Now, what if your Lego castle is super important, like for a competition, and you need it rebuilt much faster? Instead of just photos, you might build a miniature version of your castle in a separate room. This mini castle already has the most important parts built, like the main keep and the entrance arch, and all your special pieces are carefully organized nearby. If your main castle falls, you can quickly grab your mini version, add those special pieces, and then build out the rest of the walls and towers around it. This is much quicker than starting from just pictures! In the computer world, this is called "Pilot Light." We have a tiny, basic version of our website or app already running in a different, safe location. It holds the crucial information (like your game scores or what’s in your shopping cart), but the parts that handle lots of visitors are mostly off. If the main system breaks, we quickly "turn on" and "grow" those extra parts around our already-running essentials.

So, when you grow up and start building amazing websites or apps for millions of people, understanding these ideas helps you make sure your creations stay online and available, no matter what surprises come your way. It's all about being prepared so your awesome digital Lego builds don't get lost!

As a Cloud Architect, understanding Disaster Recovery (DR) strategies is paramount for building resilient systems. These strategies exist on a spectrum, balancing Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) against cost and operational complexity. At the foundational end, Backup & Restore involves regularly backing up data and infrastructure configurations to a separate, secure location. In the event of a disaster, new infrastructure is provisioned, and data is restored. This approach offers the lowest cost and complexity but comes with the highest RTO and RPO, making it suitable for less critical applications or components where extended downtime is acceptable.

Moving up the spectrum, Pilot Light involves deploying a minimal, scaled-down version of your environment in a separate DR region, with critical data continuously replicated. Only essential core services are running, like databases or messaging queues, while compute resources are dormant or significantly scaled back. When a disaster strikes, you "light up" the remaining services and scale out the compute, significantly reducing RTO compared to backup & restore. Warm Standby takes this further: a fully functional, but often scaled-down, replica of your production environment is continuously running in the DR region, with active data replication. This ensures a much faster failover as the environment is already largely operational, offering lower RTO/RPO but at a higher cost due to continuous resource consumption.

At the most advanced and expensive end is Multi-site Active (Active-Active). Here, full production environments run concurrently in two or more separate regions, actively serving traffic. Users are typically routed to the nearest or healthiest region. This strategy provides near-zero RTO and RPO, offering maximum availability and resilience. However, it introduces significant complexity in managing data consistency across multiple active sites, requiring sophisticated traffic management, global load balancing, and careful application design. The choice among these strategies hinges entirely on your application's criticality, business-mandated RTO/RPO targets, and available budget.

Key Takeaways

  • DR strategies are a trade-off between RTO/RPO, cost, and complexity.
  • Backup & Restore: Highest RTO/RPO, lowest cost, suitable for non-critical systems.
  • Pilot Light: Core services always on, faster RTO/RPO than B&R, moderate cost.
  • Warm Standby: Scaled-down replica running, continuous data replication, low RTO/RPO, higher cost.
  • Multi-site Active: Full active-active in multiple regions, near-zero RTO/RPO, highest cost/complexity (data consistency is key).

Code Example

terraform
provider "aws" {
  region = "us-east-1" # Your primary region
  alias  = "primary"
}

provider "aws" {
  region = "us-west-2" # Your DR region
  alias  = "dr"
}

resource "aws_instance" "dr_pilot_light_db_server" {
  provider      = aws.dr
  ami           = "ami-0abcdef1234567890" # Placeholder: Use a valid AMI for your region
  instance_type = "t3.micro"            # Smallest instance type for pilot light
  key_name      = "my-dr-key"
  tags = {
    Name = "DR-PilotLight-DB-Server"
    Purpose = "PilotLightCore"
  }
  # Ensure proper security group, subnet, and EBS volume for data in a real scenario
}

How this code works

This code establishes the foundational infrastructure for a "pilot light" disaster recovery strategy. Its job is to configure Terraform to manage resources across two distinct AWS regions – a primary one and a dedicated disaster recovery (DR) region – and then provision a core, minimal database server in that DR region. This server is kept in a low-cost, operational state, ready to be scaled up rapidly should the primary region become unavailable, effectively minimizing recovery time and ongoing DR expenses.

The setup begins by defining two provider "aws" blocks, each targeting a different AWS region and distinguished by unique alias names like "primary" and "dr". This allows Terraform to understand and interact with both environments simultaneously. Subsequently, the resource "aws_instance" block declares an EC2 virtual machine. A key element is provider = aws.dr, which explicitly directs Terraform to deploy this specific EC2 instance into the DR region, not the primary. The chosen instance_type = "t3.micro" highlights the "pilot light" approach, keeping resources small and cost-efficient. A subtle but critical omission for a real-world scenario is the lack of specific security_group, subnet_id, and dedicated ebs_block_device configurations, which are vital for network access, isolation, and persistent data storage for any production database server.

Related Articles

Hand-picked reads to go deeper on disaster recovery.

Back to Cloud Architect Roadmap