Cloud Planning
Cloud infrastructure planning for businesses
Plan cloud infrastructure around workloads, data, reliability and operating responsibilities before choosing a deployment approach.
Cloud infrastructure planning starts with the work the business must keep running. For each important workload, identify its users, data and the consequences of an interruption. Use those requirements to decide where it runs, how it recovers, who operates it and what it may cost.
Key Steps in Cloud Infrastructure Planning for Australian Businesses
- Start with a business outcomeDefine what each workload does, who owns it, and what successful user action looks like.
- Build a workload inventoryList all applications, data stores, infrastructure and external services by workload, including dev/test environments.
- Set requirements before selecting servicesDefine RTO, RPO, SLO, SLI, access controls, data storage locations, and operating responsibilities.
- Choose a deployment shapeDecide whether to use public cloud, private infrastructure, or a combined setup based on risk, compliance and performance needs.
- Coordinate portfolio directionAlign business, IT, finance and security leaders on priorities, accountability and ongoing strategy review.
- Make a decision recordDocument design choices, assumptions, responsibilities, cost estimates and acceptance checks.
Start with a business outcome
Write a short statement for each workload: what it does, who owns it and what a successful user action looks like. An online ordering system, for example, might depend on a catalogue, identity service, payment connection and database. Planning only for its web servers would miss much of the service customers use.
Separate current measurements from forecasts. Record busy periods, storage growth and existing performance where they are known. Label estimates for a new service as assumptions to check after launch. Ask the business owner which functions must continue during a fault and which can wait.
Build a workload inventory
List applications, data stores, infrastructure and external services by workload. Include development and testing environments as well as production. For each workload, record:
- A business and technical owner.
- The users and important actions it supports.
- Data types, sensitivity and known handling requirements.
- Main integrations and shared services.
- Current capacity, demand patterns and known constraints.
- An initial decision to move, modernise, replace, retain or retire it.
This is a planning inventory, not a migration schedule. Record unknown dependencies as questions. A diagram of important data and service flows can expose a shared component before an architecture is chosen.
For organisations with existing systems outside the cloud, automated discovery can help establish what is present before portfolio decisions are made. Azure Migrate provides free discovery capabilities for on-premises and cloud environments.
Set requirements before selecting services
Agree on the operating hours that matter and the acceptable recovery time and data loss for each critical action. Recovery time objective (RTO) is the maximum acceptable interruption after a defined incident. Recovery point objective (RPO) is the maximum acceptable age of recovered data. These are targets to design and test against, not results supplied by a product name.
Record who may access the data and where it and its copies may be stored. Record who needs to review overseas handling.
Assign operating responsibilities, including who approves changes, responds to alerts, restores data and pays for the workload. Cloud security responsibilities vary by service. Check the provider's responsibility documents for the specific service and assign the remaining tasks to named owners.
Turn stakeholder expectations into measurable reliability targets as well as recovery targets. A service-level objective (SLO) sets a specific performance or reliability goal for a customer interaction; a service-level indicator (SLI) is the quantitative measure used to assess it. Derive targets with business stakeholders, then refine them using monitoring and testing.
Where an organisation is an APP entity, the OAIC's guidance says it must take reasonable steps before disclosing personal information to an overseas recipient. It must do so to ensure the recipient does not breach the Australian Privacy Principles (APPs), subject to exceptions.
The entity can remain accountable for the recipient's relevant acts or practices. APP 6 also limits disclosure to the primary purpose unless consent or an exception applies.
Considerations for Cross-Border Data Disclosure under APPs
- ProsAccess to global cloud providers may offer better scalability, lower costs, and advanced features.
- ConsMust take reasonable steps to ensure overseas recipients comply with APPs; remains accountable even if breach occurs.
Critical Cloud Planning Metrics for Australian Organisations
- Recovery Time Objective (RTO)Maximum acceptable interruption after an incident – e.g., 4 hours for critical systems.
- Service-Level Indicator (SLI)Measurable performance metric – e.g., request success rate or latency.
Choose a deployment shape
| Option | A reasonable starting case | Planning constraint |
|---|---|---|
| Public cloud | The workload can use available services under acceptable controls | Check the exact service, configuration, locations and customer responsibilities |
| Private infrastructure | Dedicated capacity supports a particular workload or constraint | Account for capacity, maintenance, recovery and the agreed operator duties |
| Combined setup | Components have different placement needs | Specify the connections, data movement and owners between environments |
A private server estate is not automatically a private cloud. Connecting an office to a public cloud also does not, by itself, establish application or data portability. Describe where each component runs and how it connects; the label can follow.
Public Cloud vs Private Infrastructure vs Combined Setup: Deployment Shape Options
- Public CloudWorkload uses available services under acceptable controls; ideal for scalable, standardised workloads with minimal on-premises dependency.
- Private InfrastructureDedicated capacity supports specific workloads or constraints; suitable for strict compliance, data sovereignty, or legacy system needs.
- Combined SetupComponents placed in different environments based on needs; requires clear ownership and secure data movement between environments.
Coordinate portfolio direction
Translate business objectives into measurable outcomes and use them to prioritise cloud investment. That makes trade-offs between initiatives explicit and directs spending towards business value, financial efficiency and agility rather than uncoordinated adoption.
Set direction jointly across business, IT, finance and security. Identify the leaders and stakeholders accountable for decisions and execution, secure executive sponsorship, and check whether the operating model is suited to cloud adoption.
Treat the strategy as a recurring portfolio decision, not a one-off plan. Revisit priorities and guardrails as business conditions, regulatory requirements and the cloud footprint change. This helps address cost overruns, siloed operations and value that has not been realised.
Make a decision record
For each candidate design, note the requirements it meets, assumptions still to verify, operating responsibilities and a cost estimate based on expected use. Include capacity, storage, data movement, support and recovery resources where relevant.
Choose acceptance checks before committing: can an intended user complete the important action, can the team detect a failure, and can it restore service and data within the agreed targets? These remain proposed checks until performed and recorded.
Revisit the record when demand, data handling, integrations or business priorities change. The result is a workload design and a list of open decisions to inform service selection and migration work.
In this guide
- Public cloud, private infrastructure and hybrid setups comparedCompare public cloud, private infrastructure and combined setups by operating work, workload fit, data placement and recovery needs.
- Mapping business workloads before a cloud migrationMap business actions, components, data and owners before migration so placement decisions rest on a usable workload inventory.
- Choosing cloud requirements from reliability and data needsDefine checkable cloud requirements from business availability, recovery targets, data sensitivity and handling needs.
