Risk, resilience and compliance · AWS · CPS 230 · Resilience
A technical design that traces each critical operation to the services behind it, sets recovery capability from tolerance levels, replicates to a second region, and proves the result through game days and continuous service-level monitoring.
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.
Customers and staff reach the critical operation through a public name. Route 53 health checks the primary endpoint and holds the failover record for the recovery region.
DNS answers with the primary Region while health checks pass. A failed health check, or a deliberate decision by the incident lead, moves answers to the recovery Region.
The load balancer spreads traffic across the Availability Zones and removes unhealthy targets, so the loss of a zone is absorbed without a human decision.
Stateless services run as tasks spread over three Availability Zones. They write to a Multi-AZ Aurora cluster and keep no state on the container itself.
Aurora Global Database replicates to Melbourne asynchronously, normally with lag measured in seconds. Replica lag is the live measure of recovery point capability.
In the recovery Region a scaled-down copy of the services is deployed by the same pipeline. Promotion of the replica and scale-up are scripted steps in the runbook, not manual console work.
Backups are copied to a vault in the recovery Region with immutable retention, in a separate account with separate administrators. This protects against deletion, corruption and ransomware that replication would faithfully copy.
The critical operations register lists each operation, its owner, its tolerance levels (maximum disruption, maximum data loss and minimum service level), and the services and providers it depends on. Game day scenarios are derived from it.
Controlled faults are injected on a schedule: zone loss, dependency latency, credential expiry, failed deploys and regional failover. Results are compared with the tolerance levels and any gap becomes a tracked action.
Synthetic probes and service-level alerts measure each operation from the customer's point of view. Test results, probe history and incident records feed the register as evidence for the board and the regulator.
| Component | What it does | Why this choice |
|---|---|---|
| Critical operations register | A maintained list of critical operations, their tolerance levels, owners and dependency map. | CPS 230 expects the entity to identify critical operations and set tolerance levels. A register that engineers can query keeps design tied to the obligation. |
| Route 53 health checks and failover records | Detect regional failure and steer traffic. | Simple, independent of the application, and testable. |
| ECS Fargate across three Availability Zones | Runs stateless services with no servers to patch. | Removes host management risk and recovers quickly from zone loss. |
| Aurora PostgreSQL with Global Database | Relational store with a cross-region replica. | Low replica lag gives a short, measurable recovery point. Point-in-time restore covers logical corruption. |
| Immutable backup vault | Separate-account, locked copies in the recovery Region. | Replication does not protect against deletion or encryption by an attacker. Locked copies do. |
| AWS Fault Injection Service | Runs repeatable fault experiments with stop conditions. | Tests that failover and runbooks work under realistic faults instead of assuming they do. |
| Synthetic probes and service-level alerts | Measure the operation from outside, against tolerance. | Tolerance is defined for the operation, so it needs measuring at the operation, not the server. |
Where recovery capability comes from
Why. CPS 230 sets tolerance levels per critical operation. Starting from them avoids over-engineering low-value systems and under-protecting critical ones.
Trade-off. It needs a dependency map and business input before engineering starts, which takes time.
Recovery pattern
Why. Warm standby gives minutes of recovery without paying for full active-active.
Trade-off. Standby capacity costs money while idle, and failback needs its own rehearsed procedure.
Failover trigger
Why. False regional failovers can cause more disruption than they prevent. Zone loss is routine and should need no decision.
Trade-off. Regional failover takes minutes of human time. Practise it so it stays inside tolerance.
Backups
Why. Backups only count if they restore within tolerance, and survive a compromised production account.
Trade-off. Restore tests consume engineer time and storage.
Proof
Why. CPS 230 expects business continuity plans to be tested against severe but plausible scenarios, with the test program covering all critical operations.
Trade-off. Controlled faults carry risk. Start in pre-production, then run in production with stop conditions and a rollback path.
Separate accounts for production, backup and logging. Customer-managed keys per Region. Least-privilege task roles. Backup administrators are separate from production administrators.
Three-zone design, health-checked routing, replica in a second Region, immutable backups and rehearsed failover. Deployments use blue-green with automatic rollback.
Capacity is sized from load tests. Autoscaling covers demand spikes, and the standby Region is load-tested at least once a year at the scale a failover would need.
Keep standby small and scale on promotion, and apply the warm standby pattern only to operations whose tolerance demands it. Use lifecycle rules on backups.
Runbooks live beside the code, are versioned and are exercised in game days. Change freezes and on-call rosters are tied to the critical operation calendar.
Right-size standby, scale to zero in non-production and prefer managed services that share infrastructure efficiently.
Three-tier subnets in three zones. Services reach AWS APIs through VPC endpoints, and egress goes through inspected paths. The same network layout is deployed in the recovery Region from the same infrastructure-as-code. Third-party endpoints that sit on the critical path are listed in the register and given their own health checks.
Workforce access through the identity provider with MFA and just-in-time elevation for production. Break-glass accounts are stored offline, monitored and tested. Pipeline and task identities are workload roles with no long-lived keys. Recovery runbooks list who can approve failover and who deputises.
Classify data by operation. Use customer-managed encryption keys with a documented recovery path in each Region. Define and monitor RPO as replica lag and last successful backup age. Keep retention aligned with records obligations and test restores into an isolated environment.
| Control | How this design addresses it |
|---|---|
| Critical operations and tolerance levels | Register of operations with maximum disruption time, maximum data loss and minimum service levels, linked to measured service indicators. CPS 230. |
| Business continuity plan and testing | Runbooks, scheduled game days and an annual exercise covering all critical operations, with results retained. CPS 230. |
| Dependencies and service providers | Each operation lists cloud, SaaS and network providers it relies on, feeding the service provider register. CPS 230. |
| Information asset protection | Encryption, access control and logging for the assets behind each operation. CPS 234. |
| Regular backups and patching | Immutable backups, restore tests and automated patch pipelines. Essential Eight. |
| Continuity and ICT readiness | Evidence of planned and tested recovery supports ISO/IEC 27001:2022 Annex A controls on continuity and ICT readiness. |
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 |
|---|---|
| Availability Zone failure | Load balancer and scheduler move traffic to healthy zones. Alert on reduced capacity and confirm headroom is enough. |
| Regional failure of the primary | Scripted promotion of the replica and scale-up in Melbourne. Decision by the named incident lead, with the clock started at declaration. |
| Bad deployment or configuration | Blue-green release, automatic rollback on error budget burn and feature flags to disable new behaviour. |
| Data corruption or ransomware reaches replicas | Point-in-time restore and immutable backups in a separate account. Rehearse restore into isolation and validate before cutover. |
| A third-party dependency fails | Timeouts, circuit breakers and a degraded mode that meets the minimum service level. The dependency appears in the provider register. |
| Failover works but cannot be exercised by staff | Break-glass access and runbook steps are tested in game days, including with the primary identity provider unavailable. |
Standby compute, cross-region replication and data transfer, backup storage, and engineering time for tests.
Multi-cloud · Exit planning · CPS 230
How to depend on cloud, SaaS and AI providers without being trapped by them: a provider register tied to critical operations, a portability layer you own, tested data export and a second-provider path for the services that matter most.
AWS · Azure · Continuous compliance
Turn point-in-time audits into continuous assurance. Cloud configuration, findings and policy results flow into one evidence store, are mapped to named controls across several standards, and reach owners and auditors through dashboards and read-only access.
Incident response · Regulatory notification
A detection and response design that starts the right notification clocks from one incident record: materiality assessment against tolerance levels, pre-drafted regulator forms, approvals, evidence capture and a post-incident review that feeds back into the risk register.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.