AWS Looks Terrible on Abuse Lists. It Shouldn't. Ranking 13 Cloud Providers by Density, Not Volume.

Every "most malicious hosting providers" list I have ever read is really a list of who sells the most servers.

We rank abuse by raw counts, publish it, and then act surprised that the leaderboard looks exactly like the cloud market-share chart. AWS shows up near the top. Of course it does. AWS announces 103 million IPv4 addresses. If one address in a million goes bad, that is still a hundred bad addresses.

So we normalised it. Below is the same corpus ranked by abuse density — flagged addresses per million addresses the provider actually announces to the internet — over 84,983 sampled IPs from our threat corpus.

The ordering changes completely.

Volume vs. density

Ranked by raw count, the top five are DigitalOcean, OVH, GCP, Azure, AWS. That is close enough to a market-share ranking to be useless.

Ranked by density, out of the 13 providers with enough observations to rank:

#	Provider	Flagged in sample	Announced IPv4	Density index (AWS = 1.0)
1	DigitalOcean	4,375	3,139,072	104.5x
2	OVH	2,269	4,866,048	35.0x
3	Leaseweb	1,058	2,458,368	32.3x
4	M247	476	1,914,624	18.6x
5	Linode	297	1,370,926	16.2x
6	Hetzner	601	3,898,624	11.6x
7	Cloudflare	218	1,524,736	10.7x
8	GCP	2,065	19,100,576	8.1x
9	Vultr	176	1,741,824	7.6x
10	Huawei	237	2,872,832	6.2x
11	Oracle	312	4,320,266	5.4x
12	Azure	1,664	53,919,133	2.3x
13	AWS	1,385	103,826,882	1.0x

AWS is fifth by volume and last by density. Azure is fourth by volume and twelfth by density. GCP is third by volume and eighth by density. The three biggest clouds are the three cleanest per address in this dataset, and every volume-ranked list on the internet says the opposite.

DigitalOcean is first on both — that one is not an artefact of scale.

What the ordering actually tracks

It is not "which company has worse security". Read down the list and it tracks something much more boring: how much friction stands between a stranger with a stolen card and a running box.

The top of the table is instant-provisioning, low-cost, card-only VPS. Minutes to a shell, a few dollars a month, minimal identity checks. The bottom is the hyperscalers, where the free tier is quota-limited, the account opening is heavier, the fraud teams are enormous, and the economics of abuse are worse because a burned account costs the attacker more to replace.

Abuse density is a pricing-and-onboarding metric wearing a security costume. That is also why it is stable enough to be useful: the providers at the top are not going to fix it by buying a better firewall, because the thing driving it is the product.

The caveats, because they change how you can use this

I would rather publish the caveats than have someone quote the table without them.

This is a 10% sample, so treat the index as relative, not absolute. The counts come from a TABLESAMPLE SYSTEM(10) over feed hit rows; the denominators are full announced address space. The per-provider ratios are what the sample supports. Absolute "flagged per million" figures computed this way understate true density by roughly the sampling factor, so I have deliberately published the index rather than a headline rate that would be wrong by an order of magnitude the moment someone cites it.

Seven providers are missing on purpose. fly.io, Scaleway, UpCloud, Alibaba, Fastly, Akamai and IBM each had fewer than 100 flagged addresses in the sample. Their confidence intervals are enormous — fly.io's density interval spans 60 to 233, Alibaba's spans 6 to 55. A leaderboard position built on six observations is not a finding, it is a coin flip with a logo next to it. They are excluded rather than ranked.

Announced is not the same as allocated, and allocated is not the same as in use. A provider sitting on address space it has not deployed will look cleaner than it is. This is the biggest structural weakness in any density metric of this shape and I do not have a clean correction for it.

Cloudflare's row means something different from the others. Most Cloudflare-announced addresses are reverse-proxy edge, so a listing there frequently reflects a customer origin behind the proxy rather than a box rented on Cloudflare. Read row 7 as "abuse arriving through" rather than "abuse hosted at".

A feed listing is an accusation, not a conviction. These are abuse, malicious, bot and open-proxy family feeds. VPN-provider ranges are excluded entirely — those are allocations, not incidents, and mixing them in is how you end up with a list that just rediscovers where the VPNs are.

How to actually use this

Not as a blocklist. The failure mode of a density table is someone reading row 1 and dropping DigitalOcean at the edge — which also drops a large amount of ordinary traffic, including a good share of the indie SaaS ecosystem.

What density is genuinely good for is a prior. If you already score requests, provider density is a cheap feature that is stable over months and costs one lookup:

• Same behavioural signal, DigitalOcean origin vs AWS origin — the first deserves a lower threshold for stepping up to a challenge, not an automatic block.
• Signup abuse and card testing concentrate in exactly this top-of-table band, because those attacks need cheap disposable egress.
• If your product genuinely serves developers, expect legitimate traffic from rows 1–6 and design for the challenge path rather than the deny path.

The important habit is normalising before ranking. It applies well beyond hosting: any time you rank sources of anything by raw count, you are mostly ranking their size, and the interesting signal is whatever survives dividing that out.

Method

Feed hit rows joined to hosting CIDR ranges by containment, restricted to abuse, malicious, bot and open-proxy feed families, aggregated per provider, and divided by announced IPv4 address count. Providers under 65,536 announced addresses are out of scope; providers under 100 flagged addresses in the sample are unranked. Aggregates only — no individual addresses in the published table.

If you want this signal at request time rather than as a table, that is roughly what our API does: it returns hosting/VPN/proxy/Tor classification plus abuse-feed presence, and you can try a lookup here without an account.

Happy to share the per-provider numbers with anyone who wants to check the arithmetic — the caveats above are the interesting part, not the ranking.