Cloud Services Comparison
AWS vs Azure vs GCP comparison: services, pricing, performance, and selection criteria.
What is a cloud services comparison?
A cloud services comparison is a constraint-driven evaluation of where a workload should run and which managed service should own each infrastructure task. It compares service contracts, regional availability, operating effort, failure behavior, portability, and total cost. It is not a contest to find one provider that is best for every system.
AWS, Microsoft Azure, and Google Cloud all offer compute, storage, networking, databases, identity, and observability. Their products with similar labels can still differ in limits, failure semantics, regional coverage, and operational tooling. Begin with the workload and the team's constraints, then validate the exact service in the exact region.
The core invariant is: a provider or service is eligible only when it satisfies every hard requirement and the team can operate its failure modes. A lower estimate or familiar brand cannot compensate for missing residency, recovery, security, or capacity requirements.
Select a service shape before selecting a logo
Most conventional applications can run on all three major providers. The useful first decision is how much infrastructure the team wants to manage. A function runtime, managed container platform, Kubernetes service, and virtual machine expose progressively more control and operational work.
1 Eligibility
Write hard gates
List required regions, data residency, compliance evidence, recovery objectives, private connectivity, and service limits. One failed gate removes a candidate.
2 Operating model
Choose a service role
Decide whether the workload needs functions, managed containers, Kubernetes, virtual machines, object storage, or a managed database before comparing product names.
3 Evidence
Benchmark the path
Measure representative latency, throughput, deployment time, recovery behavior, and three-year cost in the required region.
4 Reversibility
Record the exit cost
Name proprietary APIs, identity bindings, data formats, transfer volume, and the tested recovery or migration procedure.
Change the workload, dominant constraint, team shape, and provider posture below. The model ranks service families, but deliberately refuses to declare a brand winner without regional and contractual evidence.
Map equivalent roles, not equivalent promises
The names below are starting points for a benchmark. They identify a similar role; they do not prove identical features, limits, availability, pricing, or failure behavior.
For each shortlisted service, compare the details that reach the application:
- Runtime contract: supported runtimes, maximum request duration, concurrency behavior, startup delay, local storage, and deployment unit.
- Data contract: consistency, transaction scope, backup ownership, point-in-time recovery, replication lag, and export format.
- Network contract: ingress and egress charging boundaries, private connectivity, load-balancer behavior, address limits, and cross-region paths.
- Failure contract: zonal and regional dependencies, retry semantics, maintenance behavior, quotas, and what the provider SLA actually excludes.
- Operating contract: identity model, audit evidence, observability, support response, upgrade work, and the skills needed during an incident.
Do not treat matching product categories as drop-in compatibility. A migration can preserve the service role while still requiring application, identity, network, and data changes.
Use shared responsibility to expose the work that remains
Cloud services move tasks between the provider and the customer; they do not remove accountability. The exact boundary depends on the service contract. A virtual machine leaves more work with the customer than a managed database, while the customer still owns data, access, application behavior, and recovery objectives in both cases.
Platform boundary
Provider responsibilities
The provider operates physical facilities, hardware, foundational networking, and the managed-service control plane described by the contract.
Workload boundary
Customer responsibilities
The customer owns data classification, identity grants, application correctness, configuration, retention, observability, and acceptance of recovery results.
Verify ownership
Shared mechanisms
Encryption, backups, patching, logging, failover, and support often split across both parties. Name who configures, tests, monitors, and responds for each mechanism.
Example: a managed relational database
- The provider may patch the database engine and replace failed infrastructure.
- The customer still chooses network exposure, identities, retention, indexes, capacity, replicas, maintenance windows, and application retry behavior.
- Automated backups are not proof of recovery. The customer must restore one, measure recovery time, validate data, and rehearse the application cutover.
Write a responsibility matrix with four verbs: configure, operate, monitor, and recover. A control with no named owner is a future incident handoff.
Estimate architecture and cost from traffic paths
Provider calculators are useful only after the workload model is explicit. Start with monthly demand, peak capacity, stored data, changed data, replicas, and every network boundary that bytes cross.
730 h
Average month
Use for continuously running capacity estimates
1,000 GB
Planning TB
Keep decimal and binary units consistent with the quote
N+1
Failure capacity
The surviving domains must still meet the target
3 years
Decision horizon
Include engineering and migration work, not only invoices
For a simple API that needs 12 instances at peak and 25% failure headroom, plan ceil(12 x 1.25) = 15 instances before reserving capacity for a zonal or regional loss. If each of two active regions normally carries half the load, losing one region doubles traffic on the survivor. Each region therefore needs enough tested headroom to carry the full target, not merely a second deployment.
Trace the bill through the architecture instead of multiplying one compute rate:
A request path with charge and failure boundaries
Every arrow can introduce transfer cost, latency, and a dependency. Replication protects data only when promotion, routing, and capacity are also tested.
Internet transfer
Users and partners
Compute and database
Primary region
Stored and retrieved bytes
Object storage
Replication and standby
Recovery region
The model below uses transparent planning rates rather than provider quotes. Adjust transfer and replication, then inject a regional failure. The result shows why the cheapest normal-state topology may not satisfy the recovery target.
Design regional failure as an operating procedure
A second region is not resilience by itself. The system also needs independent dependencies, replicated state, spare capacity, a routing decision, and a procedure that operators can execute under pressure.
Failure questions to answer before launch
- Detection: Which signal distinguishes a regional failure from an application deployment, dependency timeout, or network partition?
- Authority: Who can declare failover, and what prevents two regions from accepting conflicting writes?
- Data: What is the maximum replication lag, and which acknowledged writes could be missing after promotion?
- Capacity: Can the survivor handle peak traffic plus retries, queue replay, and cache warm-up?
- Routing: How quickly do DNS, global load balancing, clients, and long-lived connections move to the healthy path?
- Recovery: How is the original region reconciled and returned without overwriting newer state?
Retry storms can turn a partial regional problem into a global outage. Bound retries with deadlines, exponential backoff, jitter, idempotency, and load shedding before testing failover.
Test at least a zonal loss, a full regional loss, delayed replication, loss of the identity or key-management dependency, and failure during a deployment. Record recovery time, recovery point, survivor saturation, customer-visible errors, and any manual step that exceeded its time budget.
Buy portability only where it protects a real decision
Portability is the ability to move or run a workload elsewhere with bounded change. It is not achieved merely by putting an application in a container. Identity, networking, databases, queues, observability, and operational procedures can remain provider-specific.
Keep business rules, APIs, tests, and data contracts independent from cloud SDKs where that boundary is stable and useful. Standard containers, SQL, OpenTelemetry, and declarative infrastructure can reduce some migration work, but each still has implementation-specific behavior to test.
A managed queue, database, analytics engine, or identity integration can reduce operating work or accelerate delivery. Accept that coupling when the benefit is concrete, the failure contract is understood, and the exit plan names data export, replacement behavior, and migration time.
Duplicating every service across clouds can create the least-tested path, inconsistent security controls, fragmented observability, and slower incidents. Multi-cloud is justified only when a named requirement exceeds the ongoing engineering and operational cost.
A practical portability ledger
For each dependency, record:
- The provider-specific API, identity, data, or operational behavior being used.
- The measurable benefit, such as fewer operator hours, lower latency, or a required compliance control.
- The export format and volume, replacement service, code changes, and estimated migration duration.
- The last date the backup, restore, or replacement path was tested.
This ledger makes lock-in a priced architectural choice rather than a surprise.
Operate the decision with evidence
Revisit the selection when usage, regions, team skills, service contracts, or business recovery requirements change. Use comparable signals across candidates:
- Reliability: availability by user journey, zonal and regional error rates, replication lag, recovery time, and recovery point.
- Performance: p50, p95, and p99 latency by region; saturation; queue depth; cold starts; and throttling.
- Cost: cost per request or tenant, idle capacity, internet egress, cross-region transfer, storage growth, support, and engineering hours.
- Security: excessive grants, public exposure, key age, audit coverage, patch status, and time to revoke access.
- Delivery: lead time, failed deployments, rollback duration, quota incidents, and manual production steps.
- Portability: provider-specific dependencies, export duration, restore-test age, and migration estimate.
Run a quarterly architecture review and a scheduled recovery exercise. Use current contracts and quotes from the required region; service names, limits, prices, and availability change over time.
For foundational infrastructure concepts, review Infrastructure. For distributing traffic across healthy capacity, continue with Load Balancing.