We analyzed 50k APIs. Here’s which cloud is actually winning

Everyone talks about which cloud is winning. AWS, Azure, Google Cloud – the usual suspects. But aggregate revenue numbers don’t tell you what’s actually happening at the API level, where the real backend decisions get made.

We analyzed over 50,000 API subdomains (api.*.com) across 5 million companies. For each one, we resolved the A records and matched the IPs against published IP ranges for 30+ cloud providers, supplemented by HTTP response header analysis.

The goal was simple: figure out which cloud is actually winning at the API layer, which types of companies gravitate toward which provider, and which types of companies are choosing bare-metal and self-managed infrastructure over the hyperscalers.

Note: Our full methodology with complete details is at the very end of this post, in case you want to do your due diligence 🙂

1. AWS hosts 39.7% of all APIs, followed by Azure, then Google Cloud

First off, what cloud platforms do most companies host their APIs on? Ignoring APIs that were behind a CDN like Cloudflare, Akamai, Fastly and Imperva, we mapped the IPs of each API to their hosting provider.

When we crunched the numbers, AWS led by a wide margin, hosting 39.7% of all APIs we analyzed. That’s nearly four times Azure’s share (9.9%) and close to five times Google Cloud’s (8.5%). AWS being the leader isn’t a major surprise, given it had such an early lead.

Azure at 9.9% feels about right given its enterprise stronghold, but Google Cloud at 8.5% is surprisingly close to Azure considering how much smaller GCP’s overall market share is. Google Cloud has clearly found a real foothold in the developer and startup market, even if it doesn’t get the same press as AWS.

The on-premise and self-managed cluster is equally notable. Hetzner, OVH, and DigitalOcean together account for 8.7% of API backends. These are companies that evaluated the hyperscalers and chose differently – usually for cost or control reasons. Add the roughly 20% of unattributed subdomains that resolved to ISPs, colocation facilities, and private data centers, and close to a third of all API backends are running outside the major cloud platforms entirely. That number is higher than we expected. The narrative that “everyone is on AWS” is clearly overstated.

The remaining 5.2% falls into what we’d call niche hosting – smaller platforms that didn’t make the chart individually. Think Railway, Render, and a long tail of regional and developer-focused clouds. Low individually, but collectively a signal that the alternatives to the big three are finding real traction at the API layer.

2. Cloudflare dominates API protection, accounting for 81% of all CDN-protected APIs

12.5% of all APIs we analyzed sit behind a CDN or WAF. Of those, Cloudflare accounts for 81% – a level of dominance that makes the other players look like rounding errors. Akamai comes in at 13%, and Fastly and Imperva are both under 3%.

Fastly’s number is the most surprising. Fastly has built a strong reputation as the developer-friendly CDN, the one that serious engineering teams choose for low latency and fine-grained control. You’d expect it to show up more at the API layer where those properties matter most. It hasn’t. Cloudflare has clearly won the “protect my API” market, and it isn’t close.

Akamai’s 13% likely reflects its enterprise legacy – large companies that standardized on Akamai years ago and haven’t moved. Imperva’s slice is almost entirely WAF-driven rather than CDN usage, showing up at companies with stricter security requirements.

Note: Since CloudFront is AWS’s own CDN, a CloudFront-fronted API is still an AWS-hosted API – we count it under AWS rather than as a separate CDN layer. The numbers here cover true third-party CDN/WAF providers sitting in front of an API regardless of where it’s hosted.

3. nginx powers more than a third of all APIs that expose their server software – but 40% hide it entirely

One thing worth noting: 40% of APIs we probed returned no server header at all. Stripping the server header is a standard security practice that prevents attackers from fingerprinting your stack, and it’s good to see 4 in 10 engineering teams doing it. The numbers below are based on the 60% that do expose it.

Among those, nginx leads at 35.1%. That’s not surprising – nginx has been the default reverse proxy for backend APIs for years, cheap to run, well understood, and performant enough for the vast majority of use cases.

Apache at 11.9% is higher than most people would guess. Apache has a reputation as legacy infrastructure, but it’s clearly still running a meaningful chunk of production APIs. These are likely older codebases that were built on LAMP stacks and never migrated.

IIS at 9.6% is the most surprising number. That’s a lot of Windows servers running production APIs. It points to a significant cohort of .NET shops – enterprise companies that standardized on Microsoft’s stack and are still running it. The Microsoft ecosystem is more alive at the API layer than the developer community narrative would suggest.

The Python story is interesting too. Uvicorn at 4.5% vs gunicorn at 1.3% tells you where Python API development has moved. Uvicorn is the ASGI server behind FastAPI and Starlette – the async Python frameworks that have taken over from Flask and Django REST Framework in recent years. That gap suggests the shift is well underway in production, not just in tutorials.

Istio-Envoy at 2.1% is a Kubernetes signal – companies running their API behind an Istio service mesh, which almost always means EKS or GKE. Small number but meaningful: these are mature engineering orgs that have gone all-in on Kubernetes-native infrastructure.

4. Amazon API Gateway dominates, but a surprising number of companies run their own

We detected API gateways by analyzing HTTP response headers and response bodies – each gateway leaves distinctive fingerprints. Amazon API Gateway returns apigw-* headers. Kong sets x-kong-* headers or a via: kong/ header. Apigee leaves a specific error string in the response body. Azure API Management returns a characteristic 404 response body on Azure IPs. These are reliable signals, not guesses.

Amazon API Gateway leads with 74.6% of all detected API gateways. If you’re on AWS and need a gateway, you use Amazon’s own product. Nearly three quarters of companies do.

Azure API Management at 15.4% is roughly proportional to Azure’s overall share at the API layer – Microsoft shops use Microsoft’s gateway. No surprises there.

Kong at 8.3% is the most interesting number. Kong is self-hosted and cloud-agnostic, which means those companies made a deliberate decision to run their own gateway rather than use whatever their cloud provider offered. That’s an engineering team with strong opinions about vendor lock-in and control over their API layer.

Apigee at 1.7% is surprisingly low for a Google product with over a decade of enterprise runway. It never gained real traction outside a narrow segment of large enterprises, and Google Cloud’s overall position at the API layer hasn’t been enough to pull companies toward it.

5. Which types of companies use which cloud

Using significant terms analysis across 12 million companies, we looked at which sectors, company sizes, and countries are statistically over-represented for each cloud. These aren’t the most common sectors on each cloud – they’re the ones that appear more than you’d expect given their share of the overall dataset.

AWS and Azure are nearly identical in profile. Both index heavily toward mid-market companies (51-200 and 1,001-5,000 employees) in software development and financial services. If you’re trying to understand the difference between an AWS shop and an Azure shop purely from sector and size data, you can’t – they look the same. The differentiation shows up in geography (AWS skews Nordic, Azure slightly more global) and in the Microsoft ecosystem pull that Azure has on enterprise Windows shops.

Google Cloud skews meaningfully smaller. The 2-10 and 11-50 employee ranges are its strongest signal, alongside advertising and media sectors that don’t show up as strongly on AWS or Azure. Google Cloud appears to be winning among startups and digital-native companies – the ones that grew up on Google Workspace and stayed in the ecosystem.

Oracle Cloud is the most distinctive profile of all. Its strongest size signal by far is 10,001+ employees – large enterprises are massively over-represented relative to any other cloud. And it skews heavily toward Brazil and Saudi Arabia, two markets where Oracle has historically invested in local infrastructure and relationships. Companies using Oracle Cloud made a deliberate enterprise procurement decision.

DigitalOcean is the most surprising. Its top over-represented sectors include Construction and Real Estate – industries you wouldn’t expect to show up on a developer-focused cloud. That suggests DigitalOcean has become a default simple hosting option for non-technical companies that just need something to run on. It also has the strongest India and Brazil signal of any provider, pointing to strong adoption in emerging markets where hyperscaler pricing is harder to justify.

Hetzner and OVH tell a clear geographic story. Hetzner is a German and Eastern European phenomenon – Germany, Ukraine, Austria, Estonia dominate its country signal. OVH is even more concentrated: France’s significance score is 6.3, the next country is at 0.18. It’s essentially a French national cloud that happens to be available elsewhere. Both skew toward small technical companies that want bare metal at reasonable prices without hyperscaler complexity.

6. Cloudflare is the universal co-pilot – and true multi-cloud is rare

Zooming out from API subdomains to our broader dataset of 12 million companies across all infrastructure signals, we looked at which cloud providers tend to appear together. The results say a lot about how companies actually architect their infrastructure.

The most striking number is AWS + Cloudflare at 57.8%. More than half of all AWS companies also use Cloudflare. This is the dominant modern infrastructure pattern – AWS handles the compute, Cloudflare sits in front for DDoS protection, WAF, and CDN. It’s so common it’s almost become the default architecture for any serious web product on AWS.

Every other cloud has a Cloudflare co-existence rate between 13% and 25% – meaningful but nowhere near AWS’s level. Part of that gap is that AWS companies tend to be more technically sophisticated and deliberate about their infrastructure stack. Part of it is that Cloudflare and AWS have become so synonymous with “serious web infrastructure” that they’re often adopted together.

True multi-cloud – running workloads across two hyperscalers simultaneously – is rare. AWS + Azure co-exist at just 3.3%, AWS + Google Cloud at 5.1%, Azure + Google Cloud at 1.2%. The narrative that enterprises are embracing multi-cloud strategies is not reflected in what we can actually observe. Companies pick one hyperscaler and stay there.

Hetzner + AWS at 3.2% is an interesting edge case. These are likely the migration-in-progress companies – running the bulk of their infrastructure on Hetzner but with one foot already on AWS. For vendors selling to that segment, that co-existence signal is a leading indicator of a company about to make a bigger commitment to the hyperscaler.

7. Common cloud migration patterns

We detect migrations when a subdomain that previously resolved to one cloud provider starts resolving to another. We only recently started tracking migration events so sample sizes are small – treat these as early directional signals rather than definitive conclusions.

The most striking AWS finding is how many companies migrate to on-premise or colocation at 41.1% – by far the highest of any cloud. These are likely larger, more technically mature teams that built on AWS, got hit with significant bills, and decided they could run it cheaper on their own hardware. The “cloud repatriation” trend shows up here in a way it doesn’t for Azure or GCP.

Among named cloud providers, Google Cloud is the most common destination for AWS defectors at 21.6%. Companies making that move appear to be making a deliberate platform choice – if cost were the driver you’d expect more movement toward Hetzner or OVH, which barely register.

When Azure companies leave, 41.7% go to AWS. Some companies that ended up on Azure eventually find their way to the larger ecosystem. On-premise and colo at 26.6% is also significant – lower than AWS but still meaningful. Hetzner at 16.7% is notable – Azure companies moving to bare metal German infrastructure is a clear cost optimization signal.

Google Cloud’s migration pattern is the most distinctive. 42.9% of GCP defectors go to Azure – not AWS. GCP is losing customers to Microsoft rather than to Amazon. That’s consistent with what we saw in the profile data: as Google Cloud’s startup customers grow and mature, they drift toward the Microsoft stack rather than doubling down on AWS.

One pattern that stands out by its absence across all three clouds: almost nobody migrates from a hyperscaler to Hetzner or OVH. Once a company commits to a hyperscaler, the decision is sticky. The abstractions become load-bearing and the migration cost becomes too high to justify moving to bare metal.

Methodology

Everything in this post is based on first-party data we collect by directly probing company infrastructure. No surveys, no self-reported data, no job postings. Here is exactly how it works.

The panel

We track infrastructure signals across 5 million companies sourced from LinkedIn by employee count. For our technographic database, we look at subdomains that indicate an infrastructure decision, such as api.domain.com, grafana.domain.com, gitlab.domain.com, app.domain.com, metabase.domain.com, sentry.domain.com, etc. For this post we focused specifically on api.* subdomains, analyzing over 50,000 API endpoints across that panel.

Subdomain discovery

We supplement this with Cisco Umbrella’s daily top 1 million DNS logs. Any api-related subdomain appearing in the Umbrella rankings gets added to our scan list. High Umbrella ranking means real DNS query volume, which means real traffic.

Cloud attribution

For each subdomain we resolve the A records and match the IPs against published IP range databases for 30+ cloud providers. We maintain feeds from AWS, Azure, Google Cloud, DigitalOcean, Hetzner, OVH, Scaleway, Vultr, Contabo, IONOS, Alibaba, Oracle Cloud, and many others. These feeds are refreshed regularly to stay current as providers add and retire IP ranges.

IP ranges alone don’t tell the full story. Many companies put Cloudflare, Akamai, or Fastly in front of their infrastructure, which masks the origin IP entirely. To handle this we also analyze HTTP response headers. Headers like x-amz-cf-id confirm AWS even when the A record points to CloudFront. x-ms-* headers confirm Azure. via: 1.1 google or server: Google Frontend confirm GCP. Between IP ranges and header analysis we can attribute the vast majority of subdomains to a specific provider.

Filtering noise

Several filters prevent false positives. First, wildcard detection: many companies set up *.company.com wildcard DNS records that catch any subdomain. We probe a random nonsense subdomain for every domain we scan – if the A records for api.company.com overlap with the nonsense probe, the subdomain is discarded. Zero overlap means someone explicitly configured that subdomain.

Second, apex domain filtering: if a subdomain resolves to the same IPs as the company’s homepage, we discard it. We don’t want to attribute a marketing site’s cloud provider as the company’s API infrastructure.

For the CDN analysis in finding #2, we excluded subdomains sitting behind Cloudflare, Akamai, Fastly, or Imperva from cloud attribution entirely. Those providers mask the origin server so attribution would be guesswork. They are counted separately as CDN/WAF usage.

Migration detection

The first time we observe a subdomain resolving to a cloud provider we record it as a baseline – no event. When a subsequent crawl shows the same subdomain resolving to a different provider, we record a migration event with the source and destination provider. We started tracking migration events recently so sample sizes are still small, but the methodology is sound and the dataset will grow over time.

API gateway detection

API gateways are detected by analyzing HTTP response headers and response bodies against known fingerprints. Amazon API Gateway returns apigw-* response headers. Kong sets x-kong-* headers or a via: kong/ header. Apigee returns a specific error string in the response body. Azure API Management returns a characteristic 404 response body on Azure IPs. Google Cloud API Gateway returns a distinctive error message. These are deterministic signals, not probabilistic guesses.

Limitations

Companies that route their API through a path on their main domain (company.com/api rather than api.company.com) are not captured in this analysis. This is common with Rails and Laravel applications that default to path-based routing.

GCP is likely somewhat undercounted. Many GCP workloads sit behind Cloudflare, which masks the origin IP. Our header analysis catches a portion of this but not all of it.

Infrastructure on private networks or internal-only subdomains is invisible to us by definition.