AWS, Google Cloud or Microsoft Azure: How to choose a platform
Your developer recommends AWS, your administrator prefers Azure and your analyst already uses Google Cloud. Each may have a sound reason. The business needs to know where its application will meet requirements and who can operate it. Start with shared requirements, comparable costs and a small pilot.
01Describe the application before choosing the cloud
For a typical business application, a provider ranking is the wrong starting point. Prepare a page of requirements: who uses the system, where they connect from, what data it processes, normal and peak demand, and who responds to a failure. You can then compare AWS, Google Cloud and Microsoft Azure against the same needs.
Separate essential conditions from preferences. A database feature, data location or connection to an existing network may rule out a candidate. A friendlier console or temporary credit should not outweigh that limitation. If an existing software service or simpler managed hosting meets the same need, include that option too.
The outcome should be a set of services you can operate, not a logo on a slide. The AWS Well-Architected Framework likewise examines decisions within a specific architecture. A provider’s size does not establish whether you can restore your database or understand your monthly bill.
Use our web app scalability guide to make growth and peak-load requirements more concrete.
02Compare the same job and level of management
A virtual server, managed database and container platform hand different amounts of work to the provider. A container packages an application with its required environment. Who manages the servers underneath affects both the budget and the skills your team needs.
For a comparable web application pilot, possible candidates include Amazon ECS with AWS Fargate, Google Cloud Run and Azure Container Apps. These are examples of managed container execution, not interchangeable products with identical limits.
| Candidate | When to shortlist it | What the pilot should demonstrate |
|---|---|---|
| AWS | You already run important services here or have a team experienced in operating them | Deployment, application permissions, network dependencies and data recovery |
| Google Cloud | Your data or application environment already relies on Google Cloud services | Data flows, peak behaviour and the cost of associated services |
| Microsoft Azure | You already have identity management, infrastructure or an operations team here | Sign-in, access control, compatibility and operational handover |
This is a recommended way to shortlist candidates based on your circumstances. It does not imply that any provider is unsuitable for other uses. Using Microsoft or Google office applications alone does not establish where a new system belongs. Actual dependencies and demonstrated savings in work matter more.
03Choose a region for the complete system
A region is a geographical area in which selected resources run. Check that every required service and feature is available there. Microsoft’s region selection guidance considers service availability, latency, cost and data location requirements.
Do not compare distance from the office alone. Measure the journey from the user through the application to its database and connected systems. If opening every order waits for an accounting server in another location, a fast application server will not remove that delay. Document network dependencies alongside your integrations and API design.
Break a requirement such as “data in Europe” into the main database, backups, logs and supporting services. Check configuration options and applicable terms for each. Selecting a European region is not, by itself, a legal assessment of the whole solution. Record the actual locations and the process for any subsequent move.
04Calculate the complete cost under several scenarios
Compare a quiet month, expected usage and peak demand. Keep the application’s work, data volume, availability requirement and retention periods equivalent. Build current estimates in the AWS, Google Cloud and Azure calculators. Save the date, region and assumptions. A calculation is an estimate, not a guaranteed price.
- Application execution: Processing capacity, memory, runtime and reserved capacity.
- Data: Databases, storage, operations, backups and retention.
- Transfers: Communication between services and outbound data under the applicable tariff.
- Operations: Logs, monitoring, support and test environments.
- People: Implementation, maintenance, on-call cover and future changes.
Also express cost against a useful unit of work: a processed order, active account or document batch. Show commitment discounts and introductory credits separately. Include the cost after those benefits end. Use consistent currency and tax treatment so the comparison does not mix different bases.
05Reliability and security need an owner
Ask the business to specify acceptable downtime and how much recent data it could tolerate losing. These become a recovery time objective and a recovery point objective. An internal document library may need different targets from order processing. Use them to choose redundancy, backups and recovery procedures.
The AWS shared responsibility model distinguishes provider and customer duties according to the service used. Managed infrastructure does not remove responsibility for your data and permissions. Assign named people to approving access, checking backups and responding to incidents.
The Google Cloud Well-Architected Framework considers security, reliability, cost and operations alongside performance. A useful selection question follows: can your team operate the complete system over time? Cheaper infrastructure with unclear responsibility can produce a more expensive service overall.
06The pilot should include failure and recovery
Do more than deploy a welcome page. Choose a small representative flow, such as signing in, recording an order, adding an attachment, sending it to another system and finding a fault. Use test data that reflects realistic volumes and measure both response time and resource consumption.
- Deploy the same application version using a repeatable procedure.
- Test expected peaks and limits in connected services.
- Restore a backup and check the recovered contents.
- Roll a faulty application release back to a working version.
- Hand diagnostics and access to a second person.
Record results, unresolved problems and the work needed to fix them. Validate operating costs with the people who will take responsibility. If you need external application maintenance and support, include it from the start, with an agreed scope for incident response.
If you are moving a running system, plan the cutover using our guide to cloud migration without downtime.
07Accept dependencies deliberately and record the decision
A provider-specific service can save considerable development work. In return, switching providers may require rewriting part of the application. Record why that dependency is worthwhile, how data can be exported and the approximate scope of a future move. Containers alone do not transfer identities, database features or operating procedures.
Use several clouds for a specific reason and with a budget for managing them. A second provider is not an automatic backup for a small team: data restoration, configuration and traffic switching must all work. Testing export and recovery into a clean environment is often a useful first step.
Finish with a short decision record: selected services, reasons, expected costs, operations owner, accepted limitations and triggers for reassessment. These might include a substantial increase in data volume, entry into another market or a requirement the original design cannot support.
08Frequently asked questions
Which cloud is cheapest?
There is no defensible answer without a specific system and workload. Compare equivalent work, availability and total costs, including people. A virtual server’s price alone is insufficient.
Should a company using Microsoft 365 automatically choose Azure?
No. It is a reason to investigate identity and management integration, not a conclusion. The application requirements and pilot should demonstrate the benefit.
Do we need Kubernetes immediately?
Only if it addresses a concrete operational need and someone can manage it. For a smaller application, assess simpler managed execution first.
Do we need multiple clouds to preserve an exit option?
No. Data exports, documented dependencies, automated deployment and tested recovery can support a practical exit. Running several clouds simultaneously is a separate decision.
09Prepare the evidence for a useful comparison
Send us your application description, existing systems, demand peaks and recovery requirements. Discuss cloud platform selection with us and define a pilot that helps you assess technology, cost and ongoing management.