Cloud platforms · AWS and Azure
Choose recovery capability by business impact, not by habit. Three patterns with honest RTO and RPO, a cross-Region data path, an immutable backup vault and a failover that is rehearsed rather than hoped for.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
Normal operation: Route 53 health checks keep traffic on the primary Region.
On a declared disaster, failover routing sends traffic to the standby. Choose manual or automatic, and manual is usual for data-bearing systems.
The database replicates continuously to the recovery Region. Promotion of the secondary is a deliberate runbook step.
Objects replicate asynchronously by S3 cross-Region replication, with replication time control if the RPO needs a defined target.
Backups are copied into a separate account with a locked vault so ransomware or an admin mistake cannot delete the last good copy.
The pipeline brings up or scales out the standby from code. In pilot light only data stores run, and compute is created at failover.
| Component | What it does | Why this choice |
|---|---|---|
| Backup and restore | Backups copied to another Region and account. Rebuild everything on disaster. | Lowest cost. RTO in many hours. Right for most internal and non-critical systems. |
| Pilot light | Data replicated live, minimal core running, compute launched from code on demand. | RTO of tens of minutes to a few hours at modest cost. |
| Warm standby | A scaled-down but running copy of the full stack that can scale up. | RTO in minutes and the ability to test traffic continuously. |
| Aurora Global Database or Azure SQL failover group | Continuous cross-Region database replication. | Low replication lag and defined promotion procedures. |
| S3 Cross-Region Replication (or Azure GRS and object replication) | Asynchronous object copy. | Native and simple. Pair with versioning and delete marker policy. |
| AWS Backup (or Azure Backup) with Vault Lock | Policy-based, centrally managed immutable backups. | Immutable copy is the defence against destructive attacks. |
| Route 53 (or Azure Front Door and Traffic Manager) | Health-checked DNS failover. | Simple and well understood. Mind DNS TTL. |
| Terraform or CDK | Recovery environment definition. | Rebuild is repeatable and reviewed. |
Pattern per system
Why. Warm standby for everything is wasteful. Backup-only for the payment system is reckless.
Trade-off. Needs a business impact analysis, which takes effort.
Failover trigger
Why. Automatic failover on a false alarm can cause data divergence.
Trade-off. Adds minutes to the RTO. Staff must be reachable and trained.
Backup protection
Why. Backups in the same account are deleted in the same incident.
Trade-off. Locked backups cannot be removed early, which has cost implications.
Recovery Region
Why. Preserves residency.
Trade-off. Some services launch later in the second Region, so verify parity.
Immutable vaults, separate credentials for recovery and encryption keys replicated or multi-Region.
Defined RTO and RPO per tier, tested failover and failback.
The standby must be sized or able to scale to carry production load, and quotas must be raised in advance.
Cost rises from backup-only to warm standby roughly in proportion to resources kept running. Data replication and egress are the constant.
Quarterly or half-yearly game days with recorded timings, and runbooks that a person who did not write them can follow.
Do not run idle capacity you do not need. Pilot light often meets requirements.
Mirror the VPC design in the recovery Region from code, with Transit Gateway or VPN and DNS prepared. Private DNS and certificates must also exist in the recovery Region.
Break-glass roles work in both Regions. Recovery runbooks use pre-approved roles, not ad hoc admin rights. KMS multi-Region keys avoid the trap of encrypted data you cannot decrypt.
Decide the RPO per dataset. Use multi-Region KMS keys or re-encryption on replication. Test restore from backup, not only replication, because replication copies corruption faithfully.
| Control | How this design addresses it |
|---|---|
| Regular backups | Daily backups, tested restores and offline or immutable copies. Essential Eight regular backups. |
| Business continuity | Documented RTO and RPO and test evidence support ISMF and tender continuity questions. |
| Restrict administrative privileges | Backup deletion requires separate credentials. Essential Eight. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| Replication copies corruption or deletion | Point-in-time recovery, versioning and separate immutable backups. |
| Standby capacity not available | Raise quotas, pre-provision capacity reservations for critical tiers. |
| DNS failover too slow | Low TTL on the failover record and health check design tested. |
| Failover works but failback is never planned | Include failback and data reconciliation in the runbook and exercise. |
Replicated storage, standby compute, inter-Region transfer, backup storage.
AWS and Azure
One way to see every workload: OpenTelemetry instrumentation, central storage per signal, SLO-based alerting that wakes people only for user impact, and runbooks linked from every alert.
AWS
The default for marketing sites, documentation and public information: a private S3 origin behind CloudFront with WAF, managed TLS and a pipeline that deploys with short-lived credentials.
AWS
A scale-to-zero API for web and mobile apps. Cognito authenticates, API Gateway enforces, Lambda runs the business logic, DynamoDB stores state and SQS or EventBridge decouple the slow work.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.