AWS, Google Cloud, and Azure IP Ranges: Where They Live and How to Use Them

A surprising share of the internet now answers from inside three networks: Amazon Web Services, Google Cloud, and Microsoft Azure. The API you call, the SaaS app your company runs on, the website you're trying to trace: odds are good it lives on one of them. And unlike a single server with a fixed address, a cloud workload can move between machines, regions, and IP blocks as it scales. So how do you pin down which addresses belong to which cloud?

Each of the three publishes the answer. AWS, Google Cloud, and Azure all maintain machine-readable lists of the public IP ranges they use, updated as their networks change. Those lists are the reliable way to answer two very different questions: "is this address one of ours, and which service is it?" and "which addresses should my firewall trust?" This guide covers where each provider's list lives, how the three differ in shape and detail, and the one habit that keeps you out of trouble with all of them.

If you've read our companion piece on Cloudflare IP ranges, this is the same idea at a much larger scale. Cloudflare fronts its entire network from one ASN and a couple dozen blocks. The hyperscalers sprawl across thousands of prefixes, several autonomous systems each, and dozens of regions, which is exactly why a published list beats trying to eyeball it.

AWS: one file, tagged by service and region#

Amazon publishes everything in a single JSON document at https://ip-ranges.amazonaws.com/ip-ranges.json. No account and no API key: it's a plain public file you can open in a browser. At the top it carries a syncToken and a createDate. The token is just a timestamp that changes whenever the list is republished, so a script can compare it against the last value it saw and only do work when something actually moved.

The useful part is the prefixes array, with a matching ipv6_prefixes array for IPv6. Each entry pairs an ip_prefix in CIDR form with three labels: the region it belongs to, the service that uses it, and a network_border_group. That tagging is what makes the AWS list powerful. The service field reads AMAZON on every block, which is the catch-all covering the entire network, but many blocks also appear under a narrower value: EC2, S3, CLOUDFRONT, ROUTE53, and so on. So you can filter the file down to, say, just CloudFront's edge ranges, or just the address space in eu-west-1.

There are well over a thousand prefixes in the file, and that count grows over time. If you want to know how many addresses a single one of them covers, drop the CIDR into our CIDR calculator and it will expand the block into its network, broadcast, and host range. Amazon's own network, by the way, is announced primarily under AS16509 — one of several ASNs it operates, which is the first hint that an ASN lookup alone won't capture all of AWS.

Google Cloud: two files, and the difference matters#

Google splits the problem across two JSON files, and picking the wrong one is a common mistake. https://www.gstatic.com/ipranges/cloud.json lists the external IP ranges available to customer resources in Google Cloud, meaning the addresses your VMs, load balancers, and other Google Cloud services actually use. https://www.gstatic.com/ipranges/goog.json is broader: it lists all Google-owned prefixes, including the ones behind Google's own products such as Search, Gmail, and the global APIs.

The relationship between the two is the clever bit. Subtract the cloud.json ranges from the goog.json ranges and what's left is the address space used by Google's own services rather than by customer workloads. If you're building a firewall rule for traffic to or from Google Cloud, cloud.json is almost always the file you want.

Structurally, cloud.json looks a lot like the AWS file: a syncToken, a creationTime, and a prefixes array. Each prefix carries either an ipv4Prefix or an ipv6Prefix, a service (set to Google Cloud for the customer ranges), and a scope, which is a region name such as us-central1 or europe-west1, or the value global for ranges not tied to a single region. Google's network rides on AS15169, though once again that one number doesn't enumerate every range, which is why the files exist at all.

Azure: service tags instead of a raw list#

Microsoft takes a different and, in some ways, more integrated approach. Rather than pointing you at a file first, Azure organises its ranges into service tags — named groups of prefixes that Microsoft maintains and updates for you. The tag AzureCloud covers all of Azure's datacenter public IP addresses; Storage covers Azure Storage; and many tags have regional variants such as Storage.WestUS or AzureCloud.eastus that narrow the same service to one region.

The point of a service tag is that inside Azure you rarely touch the raw addresses at all. You write a network security group or firewall rule that references AzureCloud or Sql by name, and Microsoft keeps the underlying prefixes current automatically as they change. One caveat worth knowing: the AzureCloud tag does not include IPv6 ranges, so an IPv6-aware rule needs more than that single tag.

For firewalls that live outside Azure, such as an on-premises appliance, Microsoft publishes the same data two ways. There is a downloadable JSON file, refreshed and republished weekly, for each cloud environment (the public one is the largest). And there is a Service Tag Discovery API you can query from REST, PowerShell, or the Azure CLI. The two are not always in lockstep: Microsoft notes that a brand-new tag can take up to four weeks to appear in the API after it shows up in the JSON, so the downloadable file is the more complete source of the two.

Azure adds one genuinely helpful guarantee. When new IP addresses are added to a service tag, they are not actually used in Azure for at least a week afterward. That grace period is deliberate: it gives everyone tracking the list time to update their firewalls before any live traffic depends on the new range. The JSON also carries a changeNumber that ticks up each time the data changes, giving you the same "did anything move?" signal as the AWS sync token.

What all three have in common: the list moves#

The single most important habit with any of these lists is the same one that applies to Cloudflare: never hardcode a snapshot and forget it. All three providers add and retire ranges as their networks grow, and a firewall rule you set once will slowly drift out of date, quietly rejecting legitimate traffic or trusting addresses that have since been reassigned. Every one of the three hands you a change signal for exactly this reason: AWS's syncToken, Azure's changeNumber, and Google's frequently updated files. The right pattern is a small scheduled job that pulls the current list, checks whether it changed, and rebuilds your rules only when it did.

This is also why an ASN lookup, useful as it is, cannot fully replace the published lists. Cloudflare is unusual in running almost everything through one autonomous system. The hyperscalers announce their space from several ASNs each, and their per-service and per-region breakdowns simply are not visible in routing data. The ASN tells you who owns an address; the published list tells you which service and region it belongs to, and which blocks you should actually trust. If you want the background on that identifier, we wrote a full explainer on what an ASN is, and another on how the slash number in a CIDR block works.

Investigating a single address#

Most of the time you do not need the whole list. You have one IP and a question: is this AWS or Azure, and roughly what is it? For that, the fastest route is our IP lookup, which returns the owning organisation and ASN for any address. If it comes back as Amazon and AS16509, Google and AS15169, or Microsoft and AS8075, you are looking at cloud infrastructure rather than an end user's connection, and you can reach for the relevant provider's list to narrow down the exact service. To go the other way and see the full set of prefixes an ASN announces, the ASN Explorer does the reverse lookup.

The same instinct that makes a Cloudflare address confusing applies here. An IP that resolves to an AWS or Google Cloud data center tells you where something is hosted, not who the end user is. Behind that address could be anything from a personal blog to a corporate API, and the cloud's own list is how you turn a bare IP into "this is a CloudFront edge node" or "this is a Google Cloud load balancer in us-central1." It is the same reason finding a website's real server gets harder the moment it sits behind cloud infrastructure.