Your recovery plan is only as reliable as the capacity, data and deployment state available when an outage starts.
For CIOs and infrastructure leads running AI-enabled products, disaster recovery now reaches beyond restoring a database. The recovery environment must support the models, queues, identities and software versions that the business actually depends on. A second region can exist on an architecture diagram while still lacking the compute needed to serve customers. This article explains how to design an AWS recovery path with Aurora PostgreSQL Serverless v2, where AWS Database Migration Service fits, and when a GCP fallback is worth the operational cost. The aim is a measurable recovery contract that survives capacity constraints and frequent software changes.
Contents
- Why recovery capacity needs a new review
- What active-active means for your application and database
- Build the regional Aurora foundation first
- Design the multi-region recovery path
- Where DMS adds resilience and portability
- Pilot light versus warm failover on AWS and GCP
- What resilience costs and what it takes
- Test recovery under constrained capacity
- Common mistakes that invalidate the plan
- FAQ
- Infrastructure Resilience & DR Audit
Why recovery capacity needs a new review
Treat recovery compute as a dependency you must secure in advance, rather than an unlimited resource you can obtain during an incident.
AWS describes GPU demand outpacing supply and offers mechanisms for securing accelerated compute ahead of time. That supports a specific concern about GPU availability. It does not establish that every CPU family, region or cloud is experiencing the same shortage. AWS’s GPU capacity guidance
For a CPU-based service, the practical question is still concrete: can the recovery location supply your chosen instance family, networking configuration and required scale? AWS distinguishes capacity reservations from discount commitments. A Savings Plan or regional Reserved Instance does not itself reserve launch capacity. EC2 capacity reservation documentation
AI-assisted delivery adds another design pressure. If your organisation releases more frequently, a recovery environment rebuilt from last month’s templates can be incompatible with today’s schema or model interface. This is an operational risk to test, rather than a claim that AI agents increase deployment frequency in every business.
Pre-provision the components that cannot tolerate provisioning uncertainty. Decide separately whether optional inference, batch training or analytics can pause while the transaction service recovers.
What active-active means for your application and database
Active-active applications serve traffic from multiple locations during normal operation. That does not automatically make their database a multi-writer system.
Aurora Global Database replicates asynchronously from a primary region to secondary regions. Secondary clusters support regional reads and can be promoted during disaster recovery. Write forwarding sends writes back to the primary cluster; it does not create independent writers. Aurora global replication, write forwarding
For an Aurora PostgreSQL design, state the architecture accurately: active-active application serving, with a single primary database writer and a tested regional promotion path. During a primary-region outage, reads and degraded services may remain available while writes wait for database recovery.
If independent writes in multiple regions are a hard requirement, evaluate a database designed for that topology or explicitly partition write ownership. Define conflict resolution, transaction boundaries and consistency requirements before selecting the technology. DMS replication is not a substitute for that design.
Establish two business measures: recovery time objective (RTO), the acceptable interruption, and recovery point objective (RPO), the acceptable data-loss window. Set them for complete workflows, including agent actions and downstream systems, rather than for the database alone.
Build the regional Aurora foundation first
Start with an Aurora PostgreSQL Serverless v2 writer and a reader in a different Availability Zone. Aurora’s storage and instance failover mechanisms provide regional high availability; DMS is not required to replicate the Aurora cluster across AZs.
AWS recommends distributing writer and reader instances across AZs. For Serverless v2, a reader in promotion tier 0 or 1 tracks the writer’s capacity so it is better prepared to take over. Lower-priority readers can scale more independently. Choose supported engine versions and regions before implementation. Aurora Serverless v2 high availability
For a latency-sensitive recovery path, configure a nonzero minimum capacity and test the maximum capacity against the recovery workload. A serverless label removes some sizing work; it does not prove that a cold database can immediately absorb peak traffic.
Run an AZ failover exercise with real connection pools, retries and transaction behaviour. Verify that clients reconnect, retried requests are idempotent and interrupted agent jobs do not repeat a payment, shipment or external notification.
Design the multi-region recovery path
Keep a secondary region ready to deliver the minimum business service without waiting for a new infrastructure deployment.
A practical topology separates responsibilities:
| Layer | Primary region | Recovery region | Recovery decision |
|---|---|---|---|
| Application | Serves normal traffic | Serves normal traffic or a reduced service | Route traffic only after dependency checks |
| Database | Aurora PostgreSQL primary writer | Aurora Global Database secondary with compute already present | Fence the old writer and promote the chosen secondary |
| AI inference | Required production models | Preloaded model capacity or a tested degraded path | Continue, queue or disable each AI feature deliberately |
| Jobs and events | Active workers | Workers with explicit ownership rules | Transfer ownership without duplicate side effects |
| Operations | Regional telemetry and access | Independent access, logs and recovery tooling | Recover without relying on the failed region |
Aurora’s planned switchover and unplanned failover are different operations. Unplanned failover can lose changes that have not reached the secondary. Monitor AuroraGlobalDBRPOLag, rehearse promotion, and verify fencing so a returning primary cannot accept competing writes. A replication metric is useful evidence, but not proof of the RPO for every dependent service. Aurora Global Database recovery procedures
Capacity must also survive the loss of a region. In an illustrative two-region application where each region normally carries half the load, the survivor needs enough already-running or appropriately reserved capacity for the required recovery load. A deployment that serves both regions but requires untested emergency scaling still has a capacity gap.
Replicate container images, model artefacts and recovery configuration. Make secrets, encryption access, networking and operational credentials available through a recovery path that does not require the primary region to work.
Where DMS adds resilience and portability
Use DMS when you need a separate logical copy of supported database data, such as a migration target or a recovery database outside Aurora Global Database’s replication topology.
For an Aurora-to-Aurora regional DR design, prefer evaluating native Global Database replication first. For an AWS-to-GCP PostgreSQL recovery target, evaluate a supported PostgreSQL endpoint and validate connectivity, permissions, types and engine-specific features. Aurora and Cloud SQL are different managed products; PostgreSQL compatibility does not make their operations interchangeable. DMS PostgreSQL target documentation
A DMS recovery pipeline needs more than a running task:
- Prepare the source. Configure logical replication, permissions and table identity requirements for the chosen PostgreSQL version. Monitor retained write-ahead log (WAL) growth when replication falls behind.
- Load and replicate. Establish the target schema, perform the initial load, and enable change data capture (CDC). Validate data before calling the target recoverable.
- Protect the replication service. A provisioned DMS replication instance can use Multi-AZ with a synchronous standby in another AZ. This protects the replication instance; it does not turn the source and target databases into a synchronous pair.
- Make promotion a controlled operation. Stop or fence competing writers, establish the last applied change position, reconcile database objects and sequence state, redirect applications, and test writes.
- Plan failback. Decide how to rebuild or synchronise the original environment from the newly authoritative database. Do not reconnect an old primary and hope the datasets converge.
AWS documents PostgreSQL CDC limitations, including unsupported changes and table-key requirements. Review schema migrations against those limitations before deployment. Monitor both source capture lag and target apply lag; source capture alone does not establish target freshness. DMS PostgreSQL source requirements
The DMS Multi-AZ option provisions a standby replication instance for availability. An exercise should verify task continuity and data validation after its failover. If the source region disappears, DMS cannot retrieve changes that never reached the target. DMS replication instance availability
Keep backups and tested point-in-time recovery as a separate protection. Replication can carry an accidental deletion or corrupt application write into the recovery database.
Pilot light versus warm failover on AWS and GCP
Pilot light retains essential data and recovery components but needs additional action before it can serve requests. Warm standby maintains a working environment at reduced capacity. “Warm failover” describes the switch to that environment; warm standby is the architecture you maintain beforehand. AWS recovery strategy definitions
| Strategy | AWS implementation | GCP or cross-cloud implementation | Capacity trade-off |
|---|---|---|---|
| Pilot light | Replicated data, prepared network and deployable application artefacts; application capacity starts during recovery | Prepared target data and infrastructure; application VMs or services start during recovery | Lower running footprint, but launch and configuration work remain in the recovery path |
| Warm standby | Running application baseline, recovery database compute and required model capacity | Running GCP application baseline and independently validated PostgreSQL target | Can serve a defined reduced service; additional scale remains uncertain unless secured beforehand |
| Active-active application | Multiple AWS regions serve real traffic with explicit database write ownership | Both providers serve compatible application paths with explicit data and job ownership | Highest operating burden; the survivor still needs sufficient capacity for the promised service |
Google’s DR guidance describes cold, warm and hot patterns. Match their behaviour to your recovery objectives instead of assuming labels imply equivalent services across providers. Google Cloud DR planning guide
For GCP compute, a reservation provides capacity assurance for a specified configuration in a zone, subject to availability when created. Reserved resources incur charges even when unused. Quota and physical capacity are separate checks. Confirm reservation compatibility with the service that will consume it. Compute Engine reservations
A GCP-native database design also needs to distinguish zonal from regional recovery. Cloud SQL PostgreSQL HA uses a primary and standby within one region. Regional DR requires a separate cross-region design; advanced DR capabilities are edition-specific. These mechanisms do not automatically provide failover from Aurora in AWS. Cloud SQL HA, advanced DR
Cross-cloud recovery can reduce dependence on one provider, but adds identity, networking, database compatibility and operating responsibilities. Choose it when the business benefit justifies testing those additional failure paths.
What resilience costs and what it takes
Budget for the service you intend to preserve, including the capacity you hold when nothing is failing.
The cost model should include running or reserved compute, database capacity, replication and cross-region or cross-cloud transfer, model storage, observability and recurring exercises. GPU standby can be disproportionate if the core business workflow does not require inference during recovery.
AWS Capacity Blocks secure accelerated compute for specified time windows. A block for a scheduled training job is not continuous coverage for an unpredictable outage. Map reservation periods, supported locations and resource types to the actual recovery commitment. AWS Capacity Blocks
A useful business example is an order-processing platform with an AI exception assistant. The recovery contract might preserve order acceptance and queue exception analysis until inference returns. That is a proposed design choice, not a claim that every platform can safely defer AI.
Compare this reduced service with the cost of full model availability in another location. Price the selected regions and configurations at design time; a generic monthly estimate conceals the dependencies that matter most.
For portability, maintain a database-feature inventory, exportable configuration, reproducible images and an exercised exit procedure. Containers alone do not make Aurora, IAM, queues or managed inference portable. Related reading: building dependable data foundations and moving an AI prototype into production.
Test recovery under constrained capacity
Run an exercise in which new compute launches are deliberately unavailable. This reveals whether the architecture can deliver its minimum service using resources that already exist.
Measure the recovery of an end-to-end transaction, including authentication, database writes, event delivery and any essential model call. Record elapsed interruption, missing or duplicate transactions, replication lag and the throughput actually sustained by the recovery environment.
Also test recovery after a software release. Use a known compatible application, schema and model set, then exercise rollback and regional promotion. Deploy regions in a controlled sequence so a bad release does not remove both recovery paths at once.
Maintain a runbook that names the decision-maker, promotion conditions, accepted data-loss boundary, degraded features and failback procedure. Automate observations and repeatable actions; keep approval for irreversible data decisions explicit.
Common mistakes that invalidate the plan
- Calling Multi-AZ a regional disaster recovery strategy. It addresses a different failure boundary.
- Calling a single-writer Aurora topology a multi-writer database.
- Treating DMS CDC as zero-loss replication or complete database-object synchronisation.
- Leaving model files, deployment artefacts, credentials or observability dependent on the failed region.
- Assuming a small warm environment can absorb full traffic without a tested capacity plan.
- Treating a successful infrastructure deployment as a successful recovery exercise.
Choose pilot light when the measured rebuild and capacity acquisition path fits the business tolerance. Choose warm standby when a reduced service must resume with existing resources. Choose active-active serving when normal operation in multiple locations earns its additional cost and complexity.
FAQ
Does Aurora PostgreSQL Serverless v2 eliminate DR capacity planning?
No. You still need an appropriate minimum and maximum capacity, readers in suitable AZs, a regional recovery design and tests of the actual application workload. Serverless scaling does not establish your end-to-end recovery objective.
Can DMS make AWS and GCP databases active-active?
A replication task does not provide application write ownership, conflict resolution or a safe promotion protocol. Treat a cross-cloud DMS target as a separately validated recovery or migration path unless you have designed and tested the broader distributed system.
Should every AI service run GPUs in two regions?
Only if the recovery contract requires that capability. A tested smaller model, queued work or a non-AI business path may be appropriate. Validate the degraded service with its users before relying on it.
Infrastructure Resilience & DR Audit
If your DR plan depends on capacity appearing during an outage, start with the assumptions that support your most important workflow.
Request an Infrastructure Resilience & DR Audit from Zimozi. Bring your current topology, recovery objectives, deployment process and latest exercise results. The proposed audit scope covers capacity dependencies, Aurora and DMS recovery paths, AWS/GCP portability gaps, and a prioritised plan for a measurable failover exercise.
