Before approving a cloud recommendation, ask which business requirement makes it necessary and who will own the service after launch. Without those answers, a provider comparison is premature.
When choosing between AWS, Azure and Google Cloud Platform (GCP), start with one documented workload: the application, its data, its integrations and the business workflow it supports. Eliminate options that cannot meet its requirements, then compare the remaining options on cost and operational fit. The provider guidance discussed here supports specific checks, not a universal winner.
First, decide whether a direct cloud choice is needed
Test whether a suitable software-as-a-service (SaaS) product or managed application can meet the requirement. Ask the supplier to demonstrate the necessary workflow, integrations, controls and support arrangements. If that route is sufficient, do not commission a separate infrastructure selection exercise without a specific reason.
Confirm workflow fit, support, data access and exit.
Agree who selects hosting and who approves location, recovery and changes.
Identify the application, integration or control requirement it must satisfy.
Every route needs a named business owner and written support and exit expectations.
Choose the operating arrangement before choosing the infrastructure provider.Keep business accountability explicit when delegating infrastructure work. Require the business owner to approve recovery expectations, spending authority, supplier escalation and exit arrangements. Ask the provider or delivery partner to state what it will operate and what your organisation must still do.
Build a shortlist from mandatory requirements
Give every candidate the same requirements record. Separate mandatory conditions from preferences and require evidence for each mandatory answer. Keep an unresolved condition open rather than treating a supplier's assurance as a pass. Eliminate options that cannot meet a mandatory requirement before comparing estimated costs.
Will the application vendor support this configuration and its dependencies?
Who will maintain it and respond to incidents under an agreed scope?
Can required access, integrations and licence terms be satisfied?
Verify service availability and obtain approval for data locations and handling.
Define tolerable interruption and data loss, support coverage and restoration ownership.
Account for ongoing operations and the work needed to leave.
For each requirement, record evidence, an approver and any unresolved condition.
Apply the same acceptance questions to AWS, Azure and GCP.Treat existing Microsoft or Google use as a prompt for identity, integration and licensing checks, not as the deciding vote. For an Azure proposal, request the exact application dependencies and licence entitlements assumed. Apply equivalent scrutiny to AWS and GCP. Have the responsible licensing specialist validate any proposed saving before including it in the comparison.
Validate location and recovery at service level
Do not accept a published region or compliance certification as sufficient evidence of workload suitability or complete data-residency compliance. Ask technical, legal and risk advisers to validate the proposed services, data handling, backup locations and recovery arrangements. The provider-authored guidance below informs those checks; it is not an independent head-to-head evaluation.
AWS: establish eligible Regions before comparing regional prices. AWS's April 2023 Well-Architected guidance says resource prices can differ by Region and qualifies regional cost selection by latency, data-residency and data-sovereignty requirements. Ask the operator to verify current availability of every required service in each candidate Region. Reject a cheaper location if it cannot meet a mandatory requirement.
Azure: require approval of the particular deployment, not Azure in general. Microsoft identifies compliance, performance and resiliency as region-selection considerations, alongside availability, latency, cost and regulatory alignment. Ask the operator to show how the proposed Region and available services support the application's dependencies and recovery requirements.
GCP: verify each required service's availability, location and resource scope. Google documents that zonal outages can affect resources in the affected zone. Regional resources are redundantly deployed across multiple zones within a region, giving them higher availability relative to zonal resources. That resource-level distinction does not guarantee availability for the whole application.
If a GCP proposal relies on surviving a regional loss, request product-specific evidence. Google's geography guidance identifies certain multi-regional services as designed to function after losing one region, with product-specific trade-offs involving latency and the consistency model. Do not extend that statement to every service. Require the operator to explain those trade-offs in terms of acceptable business behaviour and demonstrate how the complete workflow would recover.
Compare the same workload and operating scope
Approve common assumptions for demand, operating hours, data volumes, retention and recovery before requesting estimates. Different architectures may be proposed, but require each to meet the same business requirements. Identify any reduction in service explicitly rather than presenting it as a saving.
- Compute and storage for the agreed workload.
- Backup, retention and recovery arrangements.
- Networking and data transfer under the same traffic assumptions.
- Monitoring, security, licensing and support.
- Internal operating effort and external operations fees.
- One-off migration, shown separately from recurring costs.
For AWS, request an estimate for each eligible Region with services, quantities, pricing assumptions and exclusions attached. AWS's regional pricing guidance justifies checking location-dependent costs; it does not establish that AWS is cheaper than another provider. Have the operator verify current inputs before approval.
For Azure, inspect the configuration, usage quantities and pricing plan behind the calculator total. Microsoft's documentation says the estimate depends on those inputs and that changing the pricing plan changes pricing. Record the plan used and validate assumed licence entitlements separately.
For GCP, configure the planned workload rather than accepting a generic total. Google describes its calculator as providing an idea of costs for hypothetical workloads. A billing account with a custom pricing contract can be linked to produce estimates that factor in contract prices. Record whether those prices were included.
Use calculator outputs as inputs to the operating budget, not as fixed invoices, service-level commitments or complete cost answers. Require the owner to reconcile exclusions and show the budget effect of changes in uncertain usage assumptions. Approve recovery commitments through the support agreement and technical design, not by inference from a price.
Prove the unresolved points and record ownership
Commission a small, bounded proof for uncertainties that could disqualify the preferred option. Set the question, acceptance criteria, owner, time limit and spending limit before work starts. Select tests from the unresolved requirements, whether application compatibility, a critical integration, recovery execution or data export. Do not accept successful deployment alone as proof of operational readiness.
Record the test, result and remaining uncertainty.
Name the provider, location, design and cost assumptions.
Name the business owner, operator, support escalation and recovery responsibilities.
Record accepted risks, review triggers and the feasible exit route.
Approve the operating arrangement, not just the provider name.
Turn the proof into a written decision that the operating team can use.Make exit assessable: identify who can export the data, in what usable form, who controls the necessary configuration, what notice is required and who would run the transition. Estimate the effort and cost, and record untested steps as risks. Contractual permission to terminate should not be your only acceptance criterion.
Retain the current arrangement as an option if it meets the agreed requirements. Do not add migration or multi-cloud without a specific unmet need. The approval should answer three questions clearly: why this workload belongs here, who is accountable for keeping it running, and what would justify changing course.
