India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Warm Standby DR: A Scaled-Down Live Copy Ready in Minutes
Warm standby DR is a recovery pattern in which a smaller but fully functional copy of the production stack runs continuously in a second region, with live data replication, and is scaled up to full capacity when disaster is declared. NTSPL designs and operates warm standby on AWS, Azure and Google Cloud for services needing roughly 5-15 minute recovery.
Delivered on
In scope
A Smaller Copy That Is Always Running and Always Proven
Some services cannot wait for servers to boot and caches to warm. A hospital's imaging viewer during an emergency shift, a telecom operator's rating engine at bill run, or an insurer's cashless authorisation desk lose money and trust within minutes. For these, pilot light's 45-90 minute recovery is too slow, and active-active is too expensive or too hard to make consistent. The common failure in warm standby is drift: the standby runs, but on older code, with expired certificates or a missing integration, and nobody notices until failover day.
NTSPL builds warm standby as a real environment that does real work every day. The DR stack runs at 10-30% of production capacity, receives every release through the same pipeline, and serves synthetic transactions or read-only traffic so its health is proven continuously. Data replicates synchronously within the region and asynchronously across regions. Scale-up rules, capacity reservations and a tested traffic switch take it to full load within the agreed RTO.
When Minutes of Recovery Justify a Running Standby
Signals you need Warm Standby DR
- The agreed RTO is 5-20 minutes and the measured pilot light drill exceeded it because of compute and application start-up time.
- Outage cost is above roughly INR 10-20 lakh per hour, or clinical, safety or regulatory impact begins within minutes.
- Application start-up involves heavy cache warm-up, index loading or licence handshakes that take more than 15 minutes.
- You want the DR stack to handle read-only or reporting load daily, so standby capacity earns its keep.
- Integrations with banks, payment gateways, government portals or partners require pre-registered endpoints or whitelisted IPs in the DR region.
When to choose something else
- An RTO of an hour or more is acceptable. Pilot Light DR delivers it at roughly half the run cost.
- The business needs zero downtime and zero data loss during a regional failure. That requires Active Active Resilience with a data layer designed for multi-region writes.
- The application cannot run two instances against replicated data without licence or design changes. Resolve that first; a standby that cannot be started is not warm.
What a Warm Standby Build Includes
Standby stack at reduced scale
Every tier of the application running in the DR region at 10-30% capacity, including web, app, cache, search and integration components.
Data replication
Asynchronous cross-region database replication, object and file replication, and message queue mirroring, with lag monitored against RPO.
Unified release pipeline
One pipeline deploys to production and standby in the same run, so code, configuration and secrets never diverge.
Continuous health proof
Synthetic transactions against the standby every few minutes, plus optional read-only or reporting traffic routed to it daily.
Scale-up and capacity
Scaling policies, pre-approved quota and capacity reservations so the standby reaches full production capacity within RTO.
Traffic switch and integrations
Global load balancer or DNS failover with health checks, and partner integrations registered for the DR region's IPs and certificates.
How Warm Standby DR Works, Step by Step
Warm Standby Topology with Continuous Health Proof
Production and a reduced-capacity standby run concurrently in two regions, fed by one release pipeline and linked by asynchronous data replication. Synthetic probes prove the standby every few minutes; on declaration, scale-up policies and a traffic switch bring it to full load.
Select any component
Warm Standby Topology with Continuous Health Proof: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Warm Standby on AWS, Azure and Google Cloud
Standby runs in Hyderabad with Aurora secondary clusters able to serve reads; Application Recovery Controller routing controls give a deliberate, audited switch instead of relying on health checks alone.
Failover groups provide a readable secondary and listener endpoints that move on failover; Front Door handles HTTP failover between Central India and South India origins.
A global external Application Load Balancer fronts backends in Mumbai and Delhi; the Delhi backend runs at reduced size and receives traffic automatically if Mumbai backends fail health checks.
Sizing and Scaling Choices for a Warm Standby
Standby capacity level
Start at the larger of 10% of production or two instances per tier for the app layer. Raise to 25-30% if scale-up from 10% to 100% cannot complete within RTO, which is common for JVM or .NET apps with long warm-up. Size the database replica at 50-100% of production, because database instance resizing usually takes longer than RTO allows.
Should the standby serve live traffic?
Routing read-only or reporting traffic to the standby gives continuous proof and offsets cost. Do it for reporting, search or read APIs that tolerate replica lag of a few seconds. Do not route writes unless the data layer supports multi-region writes; at that point you are building active-active and should design for it explicitly.
Automatic or manual failover
Automatic failover on health checks avoids decision delay but risks flapping on a partial outage and split-brain on the database. NTSPL defaults to automated preparation with a human approval for the final traffic switch, targeting a decision within 5-10 minutes. Fully automatic failover is reserved for stateless tiers or where the data layer arbitrates.
Integrations in the DR region
List every inbound and outbound integration: payment gateways, NPCI or bank APIs, GSTN, ABDM, SMS and email providers. Register DR-region egress IPs and certificates with each partner during build, not during a disaster. Integrations that cannot be dual-registered need a documented manual step and are often the real bottleneck on RTO.
Six-Phase Warm Standby Rollout
Standby sizing and data design
Capacity levels, replication methods and RPO alarms are set per tier, and integrations are inventoried for dual registration.
DR region build
The full stack is deployed in the DR region from the same infrastructure code as production, at standby scale.
Pipeline unification
The release pipeline is changed to deploy to both regions in one run, with a gate that fails the release if either region fails.
Health proof and drift checks
Synthetic probes, optional read traffic and daily drift reporting are switched on.
Scale-up and switch automation
Scale-up policies, capacity reservations and the traffic switch are automated with an approval gate.
Full failover drill
Production traffic is moved to the standby in a planned window, held at full load for at least one hour, then failed back.
What you receive
Warm Standby Readiness Measures
| KPI | Typical target |
|---|---|
| Time from declaration to full-capacity service | 5-15 minutes |
| Standby synthetic probe success | 99.9%+ over 30 days |
| Configuration drift items open longer than 24 hours | Zero |
| Cross-region replication lag at peak | Seconds; under RPO with margin |
| Standby run cost as share of production | Typically 25-50% |
How Warm Standby Environments Drift and How NTSPL Stops It
| Risk | How NTSPL prevents it |
|---|---|
| Standby silently falls behind on version or config | One pipeline deploys both regions, and the daily drift check compares versions, certificates and secrets with a ticket for any difference. |
| Scale-up blocked by regional capacity | On-demand capacity reservations or committed capacity cover the first half of required scale, and instance types are diversified across two or three families. |
| Partner integrations reject DR traffic | Every partner registers DR-region IPs and certificates during build; the drill includes at least one live transaction through each critical partner. |
| Split-brain after automatic failover | Database promotion requires runbook approval and the old primary is fenced before writes are accepted in DR. |
Warm standby vs active-active: when is the extra cost of active-active justified?
Warm standby gives minutes of recovery and seconds of data loss for roughly 25-50% of production cost, using conventional single-writer databases. Active-active removes failover time almost entirely but costs 80-120% of production and usually requires application changes: multi-region write data stores, idempotent operations and conflict handling. Justify active-active only when even a few minutes of downtime is unacceptable to customers or regulators, or when you already need two regions for latency or capacity. For most Indian enterprise systems, a well-drilled warm standby with a 10-minute RTO is the better investment.
Key facts: Warm Standby DR
Warm Standby DR in Practice
2 Warm Standby DR scenarios, from Hospital radiology (PACS) and Telecom billing (ISP and enterprise connectivity), plus related platform case studies.
Hospital network's PACS viewer fails over to Chennai in 9 minutes during drill
Regional telecom billing platform keeps bill runs on schedule with a Delhi standby
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
Warm Standby DR: Frequently Asked Questions
What does warm standby cost to run?
Usually 25-50% of production, driven by database replica size and standby app capacity. For a system costing INR 10 lakh a month in production, expect INR 2.5-5 lakh for warm standby. Routing reporting or read traffic to the standby can offset part of that by retiring separate reporting replicas.
How fast can warm standby recover?
Measured recoveries are typically 5-15 minutes from declaration to full-capacity service. Data loss is limited to cross-region replication lag, usually seconds. The decision to fail over often takes longer than the technical steps, so NTSPL sets a decision timebox in the runbook.
Is warm standby suitable for hospital systems under ABDM or DPDP?
Yes. Both regions can be in India, encryption keys can be region-specific, and access is governed by the same identity controls. DPDP Act 2023 obligations apply to both copies equally, so the standby needs the same access logging and breach-response coverage as production.
Can the standby double as our UAT or training environment?
Not safely. Testing changes on the standby risks leaving it inconsistent with production. It can safely serve read-only and reporting traffic. Keep UAT separate, but you can schedule UAT to shut down during drills to free quota. Training users can also be given read-only access to the standby to learn on live-like data.
How often should we run a full failover?
At least once a year with real traffic, ideally twice, plus quarterly component tests. Because the standby is proven daily by synthetic probes, full drills focus on scale-up, integrations and the human decision, rather than on whether the stack starts.
Do we need capacity reservations?
For fleets above about 20 instances or for GPU and large-memory types, yes, because regional capacity can be tight in an incident that affects many customers. Reservations cost the same as running instances, so NTSPL usually reserves 40-60% of required scale-up capacity.