AWS vs Azure vs GCP: picking a cloud for your app
An AWS vs Azure vs GCP comparison for US B2B teams: market share, real pricing, compliance, lock-in, and how to choose the right cloud for your app.
Most teams do not need the "best" cloud. They need the one that fits their app, their compliance requirements, and the skills they can actually hire for. AWS, Azure, and Google Cloud have converged on the same core primitives (compute, managed databases, object storage, Kubernetes, serverless), so the real decision comes down to your existing stack, your data-residency needs, and which trade-offs you can live with for the next five years. Here is how we weigh an AWS vs Azure vs GCP choice on real projects.
The big three at a glance
Market position is not just trivia, it shapes talent, tooling, and how long a service sticks around. In Q4 2024, AWS held about 30% of worldwide cloud infrastructure spend, Azure roughly 20%, and Google Cloud around 13%, with the three together controlling about 63% of the market. Developer usage tilts the same way. In the 2024 Stack Overflow Developer Survey, 48% of professional developers reported using AWS, 28% Azure, and 25% Google Cloud, which tells you how deep each hiring pool runs.
| Provider | Q4 2024 infra market share | 2024 developer usage |
|---|---|---|
| AWS | ~30% | 48% |
| Microsoft Azure | ~20% | 28% |
| Google Cloud | ~13% | 25% |
Sources: Synergy Research Group for infrastructure spend and the 2024 Stack Overflow Developer Survey for developer usage. Read the table as two different questions: how much money runs on each cloud, and how many engineers you can hire who already know it.
AWS is the oldest and broadest. It has the largest service catalog and the deepest pool of engineers who already know it, which matters more than people expect when you are staffing a team. Azure is Microsoft's cloud, and its gravity comes from enterprise agreements: if your company already runs Windows Server, Active Directory, Microsoft 365, and Dynamics, Azure removes friction you would otherwise pay for. Google Cloud is smaller but strong where Google is strong, namely data, analytics, and machine learning, with BigQuery as a genuine differentiator.
For a typical custom application (an API backend, a PostgreSQL database, some background jobs, and a React frontend), all three will run it well. The differences show up at the edges: identity, compliance paperwork, specialized services, and total cost as you scale.
One framing helps before you compare feature checklists: the cloud is a long-term relationship, not a purchase. You will run on it for years, hire people who know it, and build habits around its tools. Feature parity at the core is close enough that softer factors (your contracts, your team, your obligations) usually decide the outcome, and those are the factors that still matter three years from now.
Services and maturity
Compute, storage, and managed relational databases are close to a tie. Where the providers diverge:
- Managed Kubernetes: EKS, AKS, and GKE all work, but GKE is the most mature and has the best defaults. If Kubernetes is central to your architecture, that counts.
- Serverless: AWS Lambda has the widest ecosystem and event-source coverage. Azure Functions and Cloud Functions are solid but trail on integrations.
- Data and analytics: BigQuery on GCP is often the reason teams pick Google at all. It is fast, cheap to start, and low-maintenance.
- Enterprise identity: Azure Entra ID (formerly Azure AD) is a real advantage if your organization already lives in the Microsoft identity world.
Maturity also means documentation, community answers, and third-party tooling. AWS wins here by volume, which shortens debugging cycles for your engineers.
Pricing and cost management
List prices across the three are within a similar range for equivalent instances, and all offer commitment discounts (Reserved Instances and Savings Plans on AWS, Reserved VM Instances on Azure, Committed Use Discounts on GCP). The bill you actually get depends far more on architecture than on the sticker rate.
The costs that surprise teams are almost always the same ones: data egress, NAT gateways, cross-AZ traffic, and idle managed services nobody turned off. Egress is the classic trap. AWS gives you 100 GB of free outbound transfer per month, then charges $0.09/GB for the first 10 TB to the internet, and cross-region traffic runs around $0.02/GB. Move a few terabytes a month between regions or out to users and the "cheap" line item quietly becomes a real one. Google tends to have simpler, more predictable egress pricing. AWS has the most granular billing, which is powerful but easy to get wrong.
Whatever you choose, tag everything, set budget alerts on day one, and review spend monthly. We treat cloud cost as an engineering concern, not an afterthought, which is part of the broader picture in the hidden costs of custom software.
Be skeptical of pricing-calculator comparisons done in a spreadsheet before you build. They almost always understate real cost, because the meaningful spend is architectural: how much data moves, how many managed services you lean on, how well the system is tuned. A well-architected app on a slightly pricier provider routinely costs less to run than a wasteful one on the "cheapest" cloud. Optimize the design first, then negotiate committed-use discounts once your usage is stable and predictable.
Compliance and enterprise fit
All three hold the certifications US B2B buyers ask about: SOC 2, ISO 27001, HIPAA-eligible services, and FedRAMP authorizations for public-sector work. So compliance is rarely a reason to pick one over another on its own. What differs is fit with your existing agreements.
If procurement already has a Microsoft Enterprise Agreement, Azure spend may roll into a contract your company understands, and your security team may already have Azure baselines. If you handle protected health information, confirm the specific services you plan to use are HIPAA-eligible under a BAA, because not every service on any cloud is covered. Data residency is usually a non-issue for US-only workloads, since all three have multiple US regions, but pin your region choices explicitly rather than accepting defaults.
Lock-in and portability
Every managed service you adopt is a small bet on staying. Using plain compute, containers, and standard PostgreSQL keeps you portable. Leaning on proprietary services (DynamoDB, Cosmos DB, BigQuery, provider-specific queues and auth) trades portability for speed and lower operational load. That trade is often worth it, but make it on purpose. The one bright spot for switchers: since 2024, AWS and the other major clouds waive egress fees for customers moving their data off the platform entirely, so leaving is cheaper than it used to be, even if rebuilding around a different provider's services is not.
The pragmatic middle path we use: build on portable foundations (containers on Kubernetes, PostgreSQL, S3-compatible object storage, infrastructure defined in Terraform) and adopt proprietary services only where they deliver outsized value, like BigQuery for analytics. That keeps a future migration expensive but possible rather than impossible. Since our clients own 100% of their infrastructure code, credentials, and runbooks on delivery, portability is not just a technical stance, it is a matter of who controls the account.
Choosing the right cloud
A short decision guide that holds up in practice:
- Already a Microsoft shop (Entra ID, Windows, Dynamics, existing EA): default to Azure. The identity and licensing integration is worth real money.
- Data and analytics are the core of the product: lean toward GCP for BigQuery and its ML tooling.
- You want the widest talent pool, largest service catalog, and most third-party support: AWS is the safe default, and for most greenfield US apps it is where we land. The 48% developer-usage figure is not an accident.
- No strong pull in any direction: pick the cloud your team knows best. Operational familiarity beats a marginal feature advantage almost every time.
The choice matters less than how you use it. A well-architected system on any of the three will outperform a sloppy one on the "perfect" cloud. If you want help mapping your workload to a provider and a cost model, get a technical proposal or see what we build. For the broader vendor question, how to choose a software partner covers the criteria that outlast any single cloud decision.