CPS 230 does not tell you which cloud services to use. It tells you what outcome to demonstrate: that each critical operation can continue within tolerance through a severe but plausible disruption. This guide turns that outcome into cloud architecture and testing choices for AWS and Azure workloads in Australian regions. It is general guidance, not legal advice, and an architecture alone does not make an entity compliant.
Start with the operation, not the workload
Architects often begin with the application. CPS 230 begins with the critical operation, for example “process an inbound payment” or “pay a claim”. Draw a dependency map from the operation to each application, data store, integration, identity service, network path, cloud region and third party it needs. Anything on that path inherits the operation's tolerance levels. This frequently reveals the weak points: a shared identity provider, a single DNS zone, a SaaS fraud service, or an on-premises mainframe job.
Turn tolerance levels into engineering targets
| Tolerance level | Engineering measure | Typical design response |
|---|---|---|
| Maximum period of disruption | RTO per dependency, and time to detect and decide | Multi-zone by default, warm standby in a second region for tight tolerances, scripted failover |
| Maximum data loss | RPO, replica lag, backup age | Synchronous multi-zone storage, asynchronous cross-region replication, point-in-time recovery, immutable backups |
| Minimum service level in degraded mode | Defined degraded features and capacity | Feature flags, queues, read-only modes, manual fallback procedures |
Time to detect and time to decide are part of the disruption period. A design that fails over in ten minutes but takes an hour to notice and agree to fail over does not meet a 30 minute tolerance.
Patterns that work
- Zone resilience first. Run stateless services across at least three availability zones and use managed databases with multi-zone configuration. This absorbs most infrastructure failures with no human decision.
- Cross-region recovery where tolerance demands it. In Australia the usual pairs are Sydney and Melbourne on AWS, and Australia East and Australia Southeast on Azure. Replication, standby capacity and scripted promotion are chosen per operation.
- Immutable, isolated backups. Replication copies corruption and ransomware encryption. Keep locked backups in a separate account or subscription with separate administrators, and test restores.
- Infrastructure as code for the recovery environment. The recovery region is deployed from the same pipeline as production, so it does not drift.
- Control plane independence. Failover should not depend on a single identity provider or console. Hold break-glass access and runbooks offline.
- Dependency isolation. Use timeouts, circuit breakers and queues so a failing provider degrades one feature, not the whole operation.
Our CPS 230 reference architecture shows these pieces together, and the guide to backup and disaster recovery covers the recovery basics.
Concentration risk in cloud choices
The standard asks entities to assess geographic and concentration risk for material service providers. In cloud terms, concentration appears at several levels: many critical operations on one provider, one region, one account, one identity tenant, one network provider, or one software supplier that itself runs on that same cloud. Document the concentration, decide whether it is acceptable, and record the compensating controls such as a tested second region, portable data, or a second provider for the tightest tolerances. Multi-cloud is a tool, not a goal, and it adds operational complexity that must be justified by the tolerance. See our guide to due diligence and exit planning.
Test like the standard expects
CPS 230 expects a systematic testing program that covers all critical operations, uses severe but plausible scenarios, and includes an annual business continuity exercise. A practical program has layers:
- Component tests in the pipeline, such as restore from backup into an isolated environment and verify integrity.
- Fault injection and game days for zone loss, dependency latency or failure, credential expiry, DNS failure and bad deploys. AWS Fault Injection Service and Azure Chaos Studio provide controlled experiments with stop conditions.
- Regional failover exercises following the real runbook with the named decision-makers, timed against tolerance.
- Scenario exercises that include a provider failing, loss of the identity provider, a ransomware event, and loss of key staff.
- Annual whole-of-operation exercise that involves business operations, communications and service providers, not just the technology team.
Record for each test the scenario, start time, detection time, decision time, recovery time, data loss, issues found, owner and due date for each action. Re-test after the fix. This record is the evidence that makes a plan credible.
Monitor tolerance, not just servers
Measure each critical operation from the outside with synthetic transactions and service-level objectives, and alert on burn rate against tolerance. Track live RPO indicators such as replica lag and backup age. Feed breaches into the incident process so notification clocks start correctly. The compliance evidence automation architecture shows how to retain this as audit-ready evidence.
Common failures to avoid
- Designing for the technical RTO of one system while the operation depends on ten.
- Failover that depends on the thing that failed, such as the primary identity provider or the same pipeline.
- Backups in the same account as production.
- Testing in a quiet environment and never at production scale.
- Treating a cloud provider's published availability as proof of your own tolerance.
This article reflects common practice as at October 2026. Check provider documentation, APRA's CPG 230 guidance and your advisers before committing to a design.
Talk to an Adelaide team
If you want recovery capability that matches your tolerance levels and evidence that stands up to review, talk to us about a resilience design review or call 0402 401 584. See also our DevOps and cloud engineering service.