Reliability
Part of Cloud infrastructure planning for businesses
Choosing cloud requirements from reliability and data needs
Define checkable cloud requirements from business availability, recovery targets, data sensitivity and handling needs.
Choose cloud requirements by naming the business action that must work, the interruption and data loss it can tolerate, and the information it handles. Use the statements to assess a proposed design. Make each requirement specific enough to check against a service configuration and, later, an observed result.
Turn reliability needs into testable statements
Name the action and the people who rely on it. Decide when it must be available and what counts as success. A system can answer a request yet fail the user's task, so define success at the application level.
Agree on recovery time objective (RTO), the maximum acceptable interruption after a defined incident, and recovery point objective (RPO), the maximum acceptable age of recovered data. Specify the failure considered: restoring an accidentally deleted record can need a different path from recovering after an application instance fails. Business owners state the tolerances; the technical team checks whether a proposed design can meet them.
Record dependencies that could block the action even if its main application is running. Include data, identity, external connections, and the people or tools needed to restore service. A provider's service agreement covers its stated service and conditions; it does not establish availability for the whole business action.
Recovery Time Objective (RTO) vs Recovery Point Objective (RPO) in Australian cloud environments
- RTO (Recovery Time Objective)
- Maximum acceptable downtime after an incident
- RPO (Recovery Point Objective)
- Maximum acceptable data loss (in time)
Describe the data before choosing its location
List the information the workload collects and produces. Apply the organisation's sensitivity categories, identify who may read or change it, and show where it moves. Include backups, logs, exports and test data if they hold the same information.
For an Australian organisation, record requirements for storage location, overseas access and retention.
If an APP entity discloses personal information to an overseas recipient, APP 8 generally requires reasonable steps to ensure the recipient does not breach the APPs (other than APP 1). The entity may be accountable for the recipient's acts or practices. Exceptions apply, and APP 6 also applies to such disclosures.
Assess how personal information is handled and whether it is disclosed to an overseas recipient. An Australian region alone does not establish where every copy is stored or who can access it.
Pros and cons of storing personal data in Australian versus overseas cloud regions
- Pros – Australian region storageComplies with APP 8 requirements; reduces cross-border disclosure risks; aligns with ATO guidance on data sovereignty
- Cons – Australian region storageMay limit service availability options; higher costs; fewer regional redundancy choices
- Pros – Overseas region storageGreater scalability; lower latency for global users; more advanced compliance certifications
- Cons – Overseas region storageRequires reasonable steps under APP 8 to ensure overseas recipient complies with APPs; potential accountability if breach occurs
Write requirements as checks
| Need | Example requirement form | Evidence to seek later |
|---|---|---|
| User action | Staff can complete a named action during agreed hours | Application-level observation |
| Recovery | The action returns within the agreed RTO after a defined failure | Timed recovery exercise |
| Data recovery | A restored copy is no older than the agreed RPO | Verified recovery point and application check |
| Access | Only approved roles can use or administer the data | Role design and access review |
| Location | Identified data and copies stay in approved locations | Service configuration, provider terms and data-flow review |
| Overseas handling | Overseas access follows the assessed arrangement | Contract and access-path review |
These are example forms, not targets or test results. Fill in the workload's actual tolerances and owners. State any acceptable reduced service, such as taking requests for later processing, and the data it would need.
Resolve conflicts before buying capacity
Requirements can pull in different directions. A short recovery target may require extra resources and operational work, and a location constraint may narrow available service configurations. Access restrictions can affect support and incident response. Record each trade-off and its decision owner.
Finish with a brief containing each critical action, its reliability and data requirements, the assumptions behind them, its decision owners and how it will be verified. Use the brief to assess candidate designs. Until representative recovery and access checks are performed, it describes intended capability rather than proven performance.
