Availability zones share the same regional network backbone. In December 2021, an AWS us-east-1 incident took down theoretically "multi-AZ" services because the control plane (the service that orchestrates failover) was itself centralised and affected. Multi-AZ protects against a single physical datacentre failure. It does not protect against control plane failures, regional network failures, or shared management service failures.

Furthermore, multi-AZ costs. Every duplicated resource is billed. Traffic between AZs is billed. An RDS Multi-AZ instance costs approximately 2x a Single-AZ instance. A complete multi-AZ architecture can cost 1.5x to 2x the primary infrastructure — not counting replication egress fees.

Multi-region replication is real but complex. It requires solving the data consistency problem: in synchronous mode (zero data loss), inter-region latency degrades performance. In asynchronous mode (non-zero RPO), one must accept a data loss window. This architectural choice is not trivial — it depends on the nature of the data, the business, and regulatory requirements.

Implementation requires mastery of Route 53 (DNS failover with health checks), Aurora Global Database or DynamoDB Global Tables, S3 Cross-Region Replication, CloudFront, WAF, ACM (certificates in each region), and dozens of other services — each with its own subtleties, failure modes and hidden costs. A well-built multi-region AWS BCP costs between 2x and 5x the primary infrastructure cost.

Testing a multi-region failover in production is high-stakes surgery. It requires a maintenance window, team coordination, a rollback plan. It is expensive — test traffic is billed like production traffic. And it is frightening — a configuration error can worsen the incident instead of resolving it.

Result: in most organisations, the multi-region BCP is only tested in staging — which is never identical to production. When the real incident arrives at 3am, DevOps discover that the failover site's Terraform has not been updated since the last database migration. That the secondary region's load balancer SSL certificate expired three weeks ago. That the DNS TTL is still set to 3600 seconds.

The managed service failover begins at the physical level — where the hyperscaler BCP begins at the software level. When datacentre A loses its main power supply, the UPS takes over (milliseconds), then the generator starts (30 to 60 seconds). During this time, network flows are rerouted to datacentre B via the dedicated fibre — not via the Internet backbone, whose availability is outside the provider's control.

This physical layer mastery is what cloud cannot offer. When the problem is a cut transoceanic cable, a major BGP incident, or a saturated regional backbone — the cloud's software BCP does nothing. The managed service provider who controls their dedicated fibre has resilience orthogonal to Internet infrastructure incidents.

The managed service provider does not propose a BCP services catalogue — they design a continuity architecture adapted to the client's real needs. This conversation starts with fundamental questions:

RPO (Recovery Point Objective): how much data can be lost? Billing database: RPO zero (synchronous, no loss). Application logs: RPO 4h acceptable (asynchronous). User sessions: RPO 15 minutes (semi-synchronous).

RTO (Recovery Time Objective): how quickly must operations resume? Website: RTO 5 minutes (DNS failover + HAProxy). Back-office: RTO 30 minutes. Batch processing: RTO 4h.

These nuances are implemented in custom scripts, bespoke HAProxy configurations, MySQL or PostgreSQL replication rules specific to each service's RPO. Not a checkbox in a catalogue — a tailored architecture.

The managed service team has a failover Runbook for every incident type. Not a bureaucratic document — an operational guide tested and updated after every real or simulated incident. It says exactly: who does what, in what order, with what command, with what success criterion. And it notes the traps: service X always takes 3 minutes longer than expected, service Y requires a manual restart if the failover lasted more than 10 minutes.

In most cloud organisations, BCP testing follows this scenario:

Month 1: the team decides to test failover. They realise staging is not up to date.
Month 2: staging updated. Test in staging. Partially works — 3 of 12 services do not failover correctly.
Month 3: fixes. Re-test in staging. Better, not perfect.
Month 4: decision not to test in production this year — "too risky before the holidays".
Month 12: real incident. Production Terraform has diverged from staging for 4 months. Secondary database has 6 hours of replication lag. Secondary region SSL certificate expired 3 weeks ago. Real RTO: 4 hours instead of the promised 15 minutes.

A reputable managed service provider integrates BCP testing into the client's contractual lifecycle. Not as a one-off project — as a recurring, planned event with a dedicated Steering Committee.

Typical failover test schedule:
D-30: client notified of date and maintenance window. Verification that all target services are documented and the Runbook is current.
D-7: technical review — which services failover in what order, what are the success criteria, what is the rollback procedure.
Day of test, maintenance window: real production failover. The client is present (in person or remote). They observe. They validate. They measure the real RTO.
After failover: post-incident COPIL. Which services took longer than expected? Why? What changes in the Runbook? The Runbook is updated before end of week.

The client goes home with a conviction: their BCP works. Not with an architecture diagram.

Progressive: the failover happens service by service, in dependency order. First the database (source of truth), then the APIs that consume it, then the frontend. Each step is validated before moving to the next. There is no "everything failovers simultaneously" — because simultaneous failover creates unpredictable timing problems.

Reversible: each failover step has a documented rollback procedure. If service Y does not start correctly on site B, the team knows exactly how to return to site A without worsening the situation. This reversibility is tested — not assumed.

Observed: the failover is observed in real time by the provider's and client's teams. Key metrics are monitored (latency, error rate, active connections). "Continue" or "rollback" decisions are made on real data, not assumptions.

The Gentle BCP is the business continuity declension of two corpus theses. "The Gentle Exit" proposes progressive migration without rupture — the Gentle BCP applies the same principle to emergency failover. "The Accompanied Exodus" proposes a managed service provider as migration guide — the Gentle BCP makes the same provider the guide of continuity.

The organisation that migrated to the managed service provider via the Accompanied Exodus has, as a bonus, a Gentle BCP — because the provider knows the infrastructure they themselves migrated, wrote the TAD, and integrated the BCP into the initial design rather than as a later addition.