Designing DR Infrastructure for Web Applications
Imagine: at 3 AM, the primary AWS region fails, your service is down, and each hour of downtime costs thousands of dollars. Without a backup data center (DR Site), recovery could take hours. We design and implement Disaster Recovery solutions that minimize downtime. Implementing a DR Site is crucial for business continuity and disaster recovery planning. Over 5 years, we have delivered more than 20 projects for e-commerce and fintech. We know how to achieve RTO as low as 5 minutes.
Clients are often surprised that cold standby costs only 10% of production. For a medium project, that's $200 to $500 per month (20,000–50,000 rubles). However, recovery takes up to 8 hours. Warm standby offers the sweet spot: RTO 30–60 minutes at 30–50% of production cost ($600–$1,500 monthly or 60,000–150,000 rubles). As a concrete example, a medium-sized web application with warm standby typically requires an additional $800–$1,200 per month in cloud costs. Contact us — we will help you choose the optimal balance for your budget and RTO/RPO requirements.
How to Choose the Type of DR Readiness?
For cold standby, infrastructure is not running. Data is replicated, and configuration is stored as IaC. On failure: spin up the environment from Terraform, then restore data from backup, then launch the application. RTO: 2–8 hours.
Warm standby means basic infrastructure is running in reduced size (1 instance instead of 10). Data is current via replication. On failure: scale to production size, then switch DNS. RTO: 15–60 minutes.
Hot standby — a full infrastructure copy runs continuously. Data synced with sub-minute lag. On failure: switch DNS/load balancer. RTO: 1–5 minutes.
Warm standby is 3–5 times cheaper than hot standby. It offers RTO up to 60 minutes. Therefore, it is the optimal choice for most web applications.
Cost and Performance Comparison
| Standby Type | RTO | RPO | Relative Cost |
|---|---|---|---|
| Cold Standby | 2–8 hours | hours | Low (10% of prod) |
| Warm Standby | 15–60 minutes | minutes | Medium (30–50% of prod) |
| Hot Standby | 1–5 minutes | seconds | High (80–100% of prod) |
Choosing the DR Site Location
Key requirements:
- Physically independent power grid and internet channels
- At least 100 km from the primary site (protection against regional disasters)
- Compliance with regulations (user data from Russia must stay in Russia, GDPR for Europe)
Options:
- Second AWS/GCP/Azure region (simplest)
- Different cloud provider (protection against vendor outage)
- Own or rented colocation (for regulated industries)
Why Infrastructure as Code Is the Foundation of a DR Site
The entire DR Site is described in Terraform. Primary and DR environments use different workspaces or separate configuration directories. They are parameterized via variables:
module "app_cluster" { source = "./modules/app" region = var.region instance_type = var.dr_mode ? "t3.medium" : "c6i.2xlarge" replica_count = var.dr_mode ? 1 : 5 } Cold standby: terraform apply only when DR is activated. Warm standby: terraform apply immediately with dr_mode = true. IaC ensures environment identity and prevents configuration drift.
Data Replication
PostgreSQL to DR Site: Streaming replication with asynchronous standby in DR. For critical data, use synchronous_commit = remote_apply. This guarantees data availability on standby after primary failure. However, it increases write latency.
Monitor replication lag:
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag; Alert if lag > 30 seconds.
File storage: S3 Cross-Region Replication (AWS) — automatic, RPO < 15 minutes; Rclone sync on schedule — for rarely changed objects; Lsyncd for real-time filesystem sync between servers.
Redis: Redis Sentinel with a replica in DR or Redis Cluster with geo-distribution.
Network Connectivity
A dedicated channel for data replication is required between the primary site and DR Site. Options include AWS VPC Peering or Transit Gateway within AWS. For on-premises to cloud, use AWS Direct Connect or GCP Interconnect. Site-to-site VPN is a budget option but less reliable.
The replication channel must be isolated from user traffic. Peak application load must not affect replication.
How to Ensure Minimal RTO?
To achieve RTO in minutes, use hot or warm standby with automatic DNS failover. Also, configure health checks that trigger the recovery procedure. Store Terraform state in a remote backend accessible from both data centers.
DR Site Activation Procedure
A documented runbook with exact commands, not generalities:
- Confirm the primary site failure (not a false alarm)
- Declare a DR incident, assign an incident manager
- Check database replication lag before switching
- If warm/hot: promote the DB replica (
pg_promote()) - Update DNS (Route 53 / Cloudflare) to DR addresses
- Verify functionality through the DR Site
- Notify the team and, if necessary, users
- Record RTO time
What Is Included in DR Site Setup
| Stage | Result | Duration |
|---|---|---|
| Infrastructure audit | Report with recommendations | 2–3 days |
| DR architecture design | Diagram, strategy selection | 1–2 days |
| Data replication setup | DB, file, Redis replication | 3–7 days |
| IaC deployment for DR | Terraform configurations | 5–10 days |
| Runbook writing and testing | Documentation, test failover | 3–5 days |
| Team training | Webinar/documentation | 1 day |
Deliverables: infrastructure audit report, DR architecture diagram, data replication configuration, IaC code repository, runbook documentation, team training session, and 30 days of post-setup support.
Implementation Timeline
- Analysis of current infrastructure and strategy selection — 2–3 days
- Data replication setup — 3–7 days
- DR infrastructure deployment in IaC — 5–10 days
- Network connectivity and security — 2–5 days
- Procedures, runbook, testing — 3–5 days
Total: 2–5 weeks depending on infrastructure complexity and DR type.
Estimated Cost
Cost is calculated individually based on the chosen standby type, data volume, and infrastructure complexity. We will help you find the optimal balance between budget and recovery time.
Request a consultation — we will assess your project and propose a solution with the required RTO and RPO.
Disaster Recovery is not a luxury but a necessity for any serious service.