map, pin, map of the world, countries, europe, orientation, to travel, germany, continents, vacations
Photo by beasternchen on Pixabay

Cloud Planning

Part of Cloud hosting and compute selection

Choosing a region from latency and operational requirements

Shortlist a cloud region using user latency, dependent services, service availability, data handling and operating capacity.

Choose a cloud region by checking whether it can serve the application’s users and dependencies within their requirements, then whether the team can operate the design there. Geographic closeness helps form a shortlist; it is not a latency measurement. A viable region also needs the required services, configuration and data handling arrangements.

Trace the important paths

Map each important action: user to application, application to database or another service, and any trip to an office or partner system. Note where each endpoint is. Moving the application closer to customers may improve one part of the path while leaving a heavily used dependency far away.

Define an acceptable response time for the complete action. Record network delay and completed application response separately. As a reference point between two Australian Azure regions, Microsoft publishes a median (P50) round-trip time of fifteen milliseconds from Australia East to Australia Southeast, measured over a 30-day window.

Provider figures cover traffic between regions, not from your users. For an existing application, collect measurements from representative user locations and busy periods. In Azure, Network Watcher's Connection monitor measures packet loss and network latency across TCP, ICMP and HTTP checks and shows changes in reachability and latency over time.

For a proposed deployment, plan comparable checks against shortlisted regions, for example from each office and from a test host in each candidate region. A map or region name cannot establish either result for your users.

Check whether the region can run the design

AWS and Google Cloud list service locations described as Sydney and Melbourne; Azure lists Australia East and Australia Southeast. Those names do not establish feature or account availability.

For example, AWS lists its Asia Pacific (Melbourne) region as requiring opt-in, and Cloud Run’s built-in domain mapping has a narrower location list than Cloud Run services. Check the exact compute service, plan, supporting database, features, quotas and account access for each candidate.

Name the team that will deploy, monitor, investigate and restore the application. Check its support and maintenance arrangements against the hours users need the service. Operator coverage is a requirement to verify, not a property guaranteed by a region.

Provider support plans set the outside help available. Azure's Developer plan costs USD$29 per month and suits trial and non-production environments; Standard costs USD$100 per month and responds to critical business impact (Sev A) within one hour; Professional Direct costs USD$1,000 per month. Lower-severity cases are answered within business hours, which Microsoft defines for most countries and regions as 9:00 AM to 5:00 PM local time, Monday through Friday, excluding holidays.

Review data and copies together

Record the intended locations of primary data, backups, logs, exports and temporary copies. Check the location controls and terms of each service. If Australian privacy obligations apply to the organisation, assess the actual handling arrangement, including access from overseas. Hosting the primary application in Australia does not establish where every copy is held or who can access it.

Where a copy or support access would disclose personal information to an overseas recipient, APP 8 requires the entity to take such steps as are reasonable in the circumstances to ensure the recipient does not breach the Australian Privacy Principles (other than APP 1). Record which copies leave Australia and why.

If a second region is proposed for recovery, check the whole application path there. Record which data would be available, what must be rebuilt and how traffic would reach it. A region’s existence alone does not establish a recovery capability or target.

Considerations for Cross-Border Data Handling Under APP 8

Pros
Ensures compliance with Australian Privacy Principles when disclosing personal information overseas
Cons
Requires ongoing monitoring and documentation of data flows and recipient obligations

Use a decision sheet

Candidate-region check / Evidence to collect

User experience
Measurements from representative locations for the complete action
Dependency path
Locations of databases, offices and external systems; relevant cross-region traffic
Service fit
Exact service, plan, features, quota and account access
Data handling
Configured locations of primary data and copies; reviewed access arrangement
Operations
Named owner, support path and maintenance window
Cost
Current rates for the intended configuration and relevant data movement

Mark each check pass, fail or unknown. Verify unknowns before selection. Keep the chosen region, rejected alternatives and reasons to revisit the choice in the application’s decision record.

More from Cloud Planning

Cloud Planning

Cloud deployment workflows

Plan a cloud deployment workflow with release stages, environment checks, a controlled rollout and a response to failure.