Nobody publishes this data. We measured it ourselves.
Cloud providers publish uptime SLAs. They publish pricing calculators. They publish feature comparison tables.
None of them publish how long it actually takes to provision infrastructure — or how often it fails.
So we built ProvisioningIQ to measure it continuously. Here’s what 7,600+ real provisioning tests across AWS, Azure, and GCP look like.
Methodology
Every test is a real API call — no simulations, no estimates.
- Provision a real resource (VM or serverless container)
- Measure time at each phase: API accepted → allocating → ready → reachable
- Record success/failure + failure category
- Immediately destroy the resource
- Running continuously since January 2026, 3x per day across 3 regions per cloud
Serverless Containers (Cloud Run / ECS / ACI)
| Cloud | Service | p50 Latency | p95 Latency | Success Rate |
|---|---|---|---|---|
| 🟢 GCP | Cloud Run | 6–8 seconds | ~20 seconds | 100% |
| 🟠 AWS | ECS | ~20 seconds | ~40 seconds | 100% |
| 🔵 Azure | ACI | ~40 seconds | ~60 seconds | 100% |
GCP Cloud Run provisions 10–20x faster than Azure ACI at p50.
That gap isn’t a fluke — it’s been consistent across every region we test. GCP’s architecture for Cloud Run means containers reach a ready state dramatically faster than the competition.
Virtual Machines
| Cloud | Service | p50 Latency | Success Rate |
|---|---|---|---|
| 🟠 AWS | EC2 | ~34 seconds | 99.8% |
| 🔵 Azure | VM | ~72–86 seconds | 99.7% |
| 🟢 GCP | GCE | ~100 seconds | 98.5% |
AWS wins on VMs — fastest p50 and highest reliability. GCP VMs are slower than their containers by a significant margin, making Cloud Run the clear GCP choice for latency-sensitive workloads.
Why p95 Matters More Than p50
Your infrastructure decisions are made looking at averages. Your on-call engineer deals with the p95.
AWS containers p95: ~40 seconds
Azure containers p95: ~60 seconds
GCP containers p95: ~20 seconds
Your SLA is written around the average. Your on-call engineer gets paged during the p95.
When auto-scaling fires at 2AM, that difference between a 20-second GCP recovery and a 60-second Azure recovery isn’t academic — it’s the difference between your system recovering before users notice and your users noticing before your system recovers.
Regional Variance Is Real
Same cloud, different region — provisioning times vary meaningfully. A region running elevated p95 the week of your incident is not something any cloud provider will warn you about. We’ve observed maintenance-window-related spikes that temporarily double provisioning times in specific regions.
Without continuous independent benchmarking, you have no visibility into this.
What This Means for Your Architecture
Containerized workloads with aggressive auto-scaling:
GCP Cloud Run’s 6-8 second p50 is a genuine architectural advantage. Scaling from zero is nearly instant compared to alternatives.
Need VM reliability above everything else:
AWS EC2 at 99.8% with tight p95 variance is the most predictable option across all three clouds.
Running on Azure:
ACI latency is consistent but higher than the competition. Build 40-60 second provisioning windows into your scaling policies — don’t assume AWS-like behavior.
Making a cloud selection decision:
Don’t rely on vendor benchmarks. The provisioning behavior of the cloud you choose affects your auto-scaling, DR, and CI/CD pipeline every single day.
Three Scenarios Where This Directly Hits Your Business
1. Auto-scaling under load
A 60-second provisioning gap is a 60-second window where your system is degraded, your queue is backing up, and your users experience latency you can’t explain in a postmortem because “the cloud was slow” isn’t on anyone’s dashboard.
2. Disaster recovery
Your RTO assumes 30-second provisioning. If your cloud is running at 90-second p95 that week, your actual RTO just tripled. Without independent benchmarking, you won’t know until it matters.
3. CI/CD pipeline velocity
40 seconds saved per deploy × 50 deploys/day × 260 working days = 144 hours of engineering time recovered annually. Per team.
The Transparency Gap in Cloud Procurement
When you sign a cloud agreement, you negotiate:
- Price per compute hour ✓
- Storage costs ✓
- Network egress ✓
- Uptime SLA ✓
You don’t negotiate provisioning latency. You don’t get a commitment on it. You don’t even get a number.
ProvisioningIQ exists to close that transparency gap.
What We’re Measuring Next
- Managed database provisioning — RDS PostgreSQL vs Cloud SQL vs Azure Database for PostgreSQL. Nobody has continuous benchmark data on this. We’re building it.
- Terraform-based step-level timing — breaking provisioning into discrete phases to pinpoint exactly where each cloud spends its time.
See the Live Data
Free daily benchmarks: provisioningiq.appswireless.com
Pro tier includes 90-day history, p50/p95 trends, per-region failure analysis, and daily email digest.
Questions about methodology, failure categorization, or how we handle cleanup? Drop them in the comments.