Google's main ASN is AS15169. That's one Google ASN out of 21 that ARIN lists under three separate Google org IDs, and Amazon and Microsoft are built the same way: one famous number, then a long tail of ASNs split by customer type, legal entity, and acquisition.
So if you're grouping log traffic, writing a WAF rule, or deciding whether a request "came from Google," one number won't cover it, and lumping them all together is worse. This post skips the basics. For those (what an AS is, how BGP uses it, who hands them out), see this guide to autonomous system numbers.
TL;DR
- AS15169 is Google's primary ASN, but it is not a reliable
google-servicesclassifier by itself. AS396982 and AS19527 are explicitly associated with Google Cloud customer traffic, but security policy should still classify the individual prefix using Google's published service, Cloud, or crawler range files. - An AS is a routing policy, not a company. A company with five routing policies ends up with five ASNs.
- The AWS ASNs to know are AS16509 and AS14618, plus AS8987 for GovCloud (US) and AS214101 for the European Sovereign Cloud.
- Microsoft's AS8075 is the last number in a block of eight, AS8068 to AS8075, registered in 1997.
- Group twice: by parent company for reporting, by function for security policy. Then check who's behind the prefix, because the ASN doesn't always tell you. "Google" in a traffic report is at least three different things: Google's own services, strangers renting Google Cloud, and Google Fiber's home subscribers. They all roll up to the same parent. Treat them as one bucket on a dashboard if you like. Never treat them as one bucket in a firewall rule.
Google ASN list, sorted by job
Google LLC's primary ASN is AS15169, registered with ARIN in March 2000. It carries Google's own services, including the Googlebot crawler. It isn't the only one: Google's own PeeringDB record says Google manages seven ASNs, and ARIN's registry shows more than that. These are the ones you're most likely to meet in logs:
| ASN | Registry name | Registered to | What it's for |
|---|---|---|---|
| AS15169 | Google LLC (ARIN) | Google's primary network; use prefix-level lists to distinguish services, crawlers, Cloud ranges and third-party space | |
| AS396982 | GOOGLE-CLOUD-PLATFORM | Google LLC (ARIN, Cloud org ID) | Google Cloud customer workloads |
| AS19527 | GOOGLE-2 | Google LLC (ARIN, Cloud org ID) | Google Cloud customers |
| AS16550 | GOOGLE-PRIVATE-CLOUD | Google LLC (ARIN, Cloud org ID) | Private connectivity, 9 IPv4 routes |
| AS36040 | YOUTUBE | Google LLC (ARIN) | YouTube, registered in 2005 |
| AS43515 | YOUTUBE | Google Ireland Limited (RIPE) | Google's Irish legal entity |
| AS139070 | GOOGLE-AS-AP | Google Asia Pacific Pte. Ltd. (APNIC) | Google's Singapore legal entity |
| AS16591 | GOOGLE-FIBER | Google Fiber Inc. (ARIN) | Residential ISP |
Is Google Cloud on AS15169? Mostly not. The Google Cloud ASN you'll meet most is AS396982, and ARIN's record for it says so in plain words: "This ASN is used for Google Cloud Platform." That split between Google's own network and the network it rents out is the one that matters most, and the one ASN lookup pages tend to flatten into a single "Google" label.
Which list is right, PeeringDB's seven or ARIN's 21? Both. They answer different questions, which is the whole problem.
Why one company ends up with multiple ASNs
An AS is a routing policy, not a company
RFC 1930, the 1996 best-practice document for AS numbers, defines an AS as a group of prefixes with "a SINGLE and CLEARLY DEFINED routing policy." Section 4 even names the mistake of using an AS "as a convenient way of grouping together a set of prefixes which belong under the same administrative umbrella."
So the registry was never built to map ASNs to companies. A company gets another ASN whenever part of its network needs to behave differently on the internet, and a company the size of Google has a lot of parts that behave differently.
Customer traffic gets its own number
This is the reason I'd care about most if I ran a firewall. AS15169 sits under an ARIN org ID called GOGL. AS396982 and AS19527 sit under a different one, GOOGL-2, also named "Google LLC," and the AS19527 record carries a comment: "The IP addresses under this Org-ID are in use by Google Cloud customers." The comment then sends abuse complaints to Google Cloud's reporting form.
GOOGL-2 holds 11 ASNs, with names like GCP-ENTERPRISE-USER-TRAFFIC and G-CLOUD-AGENT-TRAFFIC. When someone's rented VM hammers your login page, the complaint path leads to the Cloud abuse desk, not to the people running Search.
My read, not Google's stated reason: it also keeps the reputation of Google's own address space apart from whatever tenants do with theirs. Either way, the line between "Google" and "someone on Google" is already drawn in the registry.
Legal entities live in different registries
ASNs belong to legal entities, and legal entities register with their regional registry. AS43515 is registered to Google Ireland Limited at RIPE. AS139070 belongs to Google Asia Pacific Pte. Ltd. at APNIC. Amazon's European Sovereign Cloud runs AS214101 under Amazon Data Services European Sovereign Cloud GmbH, also at RIPE. Three registries, a different spelling in each, one parent.
Regulated and private networks
Some networks exist to be kept apart. AWS's BYOIP documentation has customers check their route authorizations against AS16509 and AS14618, then against AS8987 for GovCloud (US), and AS16509 plus AS214101 for the European Sovereign Cloud. A government region on its own ASN is much easier to reason about than one hidden inside AS16509.
Other ASNs exist for private links. Microsoft runs ExpressRoute, its private-connection product, on AS12076, and its peering policy tells every peer not to accept routes from AS12076 "under any circumstances." Google's AS16550 is named GOOGLE-PRIVATE-CLOUD and announces just nine IPv4 routes.
Acquisitions keep their numbers, or get folded in
AS36040 is named YOUTUBE and was registered in August 2005, before Google bought YouTube. It now sits under Google LLC. Microsoft's main ARIN org ID, MSFT, holds 42 ASN records, and the names read like an M&A history: NUANCE-BURLINGTON, PHONEFACTOR-01, ASN-YAMMER, FAST-SEARCH-AND-TRANSFER-INC, MS-DANGER.
Not everything gets folded in. GitHub's AS36459 is still registered to GitHub, Inc., and LinkedIn's AS14413 to LinkedIn Corporation. It cuts the other way too: ARIN still files AS19425, named WAYMO, under Google LLC's GOGL org ID, even though Waymo runs as its own Alphabet company. Registry records lag the org chart, sometimes by years.
How Google, Amazon, and Microsoft lay it out
Google splits by who's on the other end
Put the registry records side by side and Google's layout jumps out. ARIN holds Google LLC under three org IDs: GOGL with 9 ASNs including AS15169, GOOGL-2 with the 11 Cloud ASNs, and GOOGL, spelled "Google, LLC" with a comma, holding AS36492 (GOOGLEWIFI). Add Google Ireland at RIPE, Google Asia Pacific at APNIC, and Google Fiber Inc., and one parent has six registrant records under five spellings.
GOOGL-2 is explicitly marked in ARIN as address space used by Google Cloud customers. GOGL is Google's older organization record, but an ASN under GOGL is not a service-level trust boundary. Prefix-level data is still needed before an address is treated as a Google-operated service.
Amazon runs one giant ASN and a few specialists
Amazon's main ASN is AS16509 (AMAZON-02), with AS14618 (AMAZON-AES) as the other big one. There's no single AWS ASN to allowlist. On October 29, 2026, AS16509 announced 19,751 IPv4 routes against 1,529 for AS14618, roughly 13 to 1 (route counts from ipgeolocation.io's ASN endpoint).
The two big ones sit under different ARIN org IDs, AMAZON-4 and AMAZO-4, both named "Amazon.com, Inc." AMAZO-4 also holds AS21664, named AMZN-BYOASN. GovCloud's AS8987 is registered to a third name, Amazon Technologies Inc., with aws.amazon.com as its domain. The oldest of the lot, AS7224 (AMAZON-AS), dates to October 1996 and announces 27 IPv4 routes.
Neither big number separates Amazon's own services from its customers' instances. An allowlist built on these Amazon ASN numbers admits anyone who can launch an EC2 instance.
Microsoft: one 1997 block and a long tail
The Microsoft ASN you'll see in logs and peering docs is AS8075, the one Microsoft names first in its peering policy. ARIN doesn't store it as a standalone record. AS8075 is the last number in one registration covering AS8068 through AS8075, dated March 31, 1997 and named MICROSOFT-CORP-MSN-AS-BLOCK.
The policy points to an IRR as-set, AS-MICROSOFT, for the full list of ASNs Microsoft manages, and says ASNs that customers bring through its BYOASN product get added to that set. The registry view sprawls further: those 42 MSFT records, plus GitHub and LinkedIn under their own names. One more line from the same policy matters later: prefixes that customers bring through BYOIP "are all properly registered as AS8075."
Same question, two sources per company:
| Company | What the operator publishes | What ARIN shows |
|---|---|---|
| 7 ASNs in its PeeringDB record | 21 ASN records under GOGL, GOOGL-2 and GOOGL, plus RIPE and APNIC entities | |
| Amazon | 4 ASNs in the BYOIP docs: 16509, 14618, 8987, 214101 | AMAZON-4 and AMAZO-4, plus Amazon Technologies Inc. |
| Microsoft | AS8075 and the AS-MICROSOFT as-set; AS12076 for ExpressRoute | 42 ASN records under MSFT |
Neither column is wrong. The operator lists what it routes and wants you to peer with. The registry lists everything the legal entity has ever registered and not returned.
How to group IP traffic by organization
Name matching breaks on the first comma
The obvious approach is to group on the ASN's organization string. It falls apart fast. ARIN has Google as both "Google LLC" and "Google, LLC". RIPE adds "Google Ireland Limited". Amazon shows up as "Amazon.com, Inc.", "Amazon Technologies Inc." and "Amazon Data Services European Sovereign Cloud GmbH", and the company record on one AWS address I looked up, 3.80.0.1, read "Amazon Data Services Northern Virginia."
Fuzzy matching catches some of these and quietly invents matches you didn't want. Pick a key that doesn't change spelling.
Pick a key that survives
The ASN's registered domain is the first thing I'd try. Seven of the eight Google ASNs in the table above came back with google.com as their domain; Google Fiber came back with gfiber.com. Amazon needs three: amazon.com, aws.amazon.com and aws.eu. A short alias map covers all three companies.
If you need coverage beyond the big three, use a curated AS-to-organization mapping. CAIDA's AS2Org dataset maps ASNs to organizations from quarterly WHOIS dumps of all five RIRs, with snapshots back to October 2009. The newer ASINT project adds PeeringDB, company websites and merger records, and groups 111,470 ASNs into 81,233 organization families. Both are research datasets, so check how fresh they are before a production job depends on them.
For the ASNs that actually show up in your logs, keep a short list you've checked against the registry by hand. That's what the script below does.
Group twice: parent for reporting, function for policy
Here's the position I'll defend: one "Google" row is fine for a monthly traffic report and wrong for anything that allows or blocks. Googlebot crawling your docs and a scraper on a rented Compute Engine VM both roll up to Google LLC. They should not share a rule.
The ASN type field won't split them for you. AS15169 and AS396982 both come back as HOSTING (that field is still useful for other jobs; I covered them in classifying ASNs by type). The function often has to come from the prefix rather than the ASN. Google publishes the required source data: subtract cloud.json from goog.json to derive the ranges used by Google's own APIs and services, and use Google's separate crawler files when crawler identity matters. Treat the ASN role map below as a fallback, not as a security allowlist.
Keep two columns, then. parent holds google, amazon or microsoft. role holds google-services, cloud-tenants, isp, aws or mixed. Report on the first. Write policy on the second.
Check who's behind the prefix
The ASN tells you who announces a prefix. It doesn't always tell you who uses it. 57.140.0.0/16 is an ARIN direct allocation to Menlo Security, Inc., and 57.140.216.0/24 is announced by AS15169. Look up 57.140.216.1 and the ASN says Google, while the company using the range is Menlo Security:
{
"ip": "57.140.216.1",
"asn": {
"as_number": "AS15169",
"organization": "Google LLC",
"country": "US",
"type": "HOSTING",
"domain": "google.com",
"date_allocated": "2000-03-30",
"rir": "ARIN"
},
"company": {
"name": "Menlo Security, Inc.",
"type": "BUSINESS",
"domain": "menlosecurity.com"
}
}
That's the /v3/ipgeo response with fields=asn,company. Drop the parameter and you also get location, network, time zone and currency for the same IP.
This is third-party address space announced through Google's ASN. It is consistent with BYOIP or another delegated routing arrangement, but the registry and BGP records alone do not prove the commercial mechanism. Microsoft and AWS explicitly document BYOIP under their ASNs, so the same separation between route origin and address holder matters there too. If your rule says "trust AS15169," you just trusted a security vendor's egress range as well.
The script below does both groupings and flags prefixes whose registered company differs from the mapped provider parent. Treat that as an external-prefix signal that may indicate BYOIP, not as proof by itself. I'm using ipgeolocation.io's bulk endpoint because each row carries the ASN registrant (asn) and the company using the prefix (company) side by side, which is exactly the pair the BYOIP check needs. ipinfo, MaxMind GeoIP2 and IP2Location expose ASN data too; whichever you use, make sure it keeps those two apart.
One trade-off up front: this bulk script requires a paid plan. The bulk endpoint, asn.domain, and company enrichment are paid features. A free single-IP /v3/ipgeo lookup still returns as_number, organization, and country, which is enough to build a basic ASN map, but it cannot run this bulk workflow or perform the external-prefix comparison.
import os
import sys
from collections import Counter
import requests
API_KEY = os.environ.get("IPGEOLOCATION_API_KEY")
BULK_URL = "https://api.ipgeolocation.io/v3/ipgeo-bulk"
BATCH_SIZE = 50_000 # documented per-request maximum
# ASNs whose job the registry or the operator states in writing.
# Checked against ARIN and PeeringDB on 2026-10-29. Re-check every quarter.
ASN_ROLE = {
"AS15169": ("google", "mixed"), # resolve service, Cloud and crawler roles by prefix
"AS36040": ("google", "google-services"), # registered as YOUTUBE
"AS396982": ("google", "cloud-tenants"), # ARIN: "used for Google Cloud Platform"
"AS19527": ("google", "cloud-tenants"), # ARIN: "in use by Google Cloud customers"
"AS16591": ("google", "isp"), # Google Fiber
"AS16509": ("amazon", "aws"),
"AS14618": ("amazon", "aws"),
"AS8075": ("microsoft", "mixed"), # BYOIP tenants are registered here too
}
# Registrant domains that roll up to one parent. Extend as you find more.
DOMAIN_PARENT = {
"google.com": "google", "gfiber.com": "google",
"amazon.com": "amazon", "aws.amazon.com": "amazon", "aws.eu": "amazon",
"microsoft.com": "microsoft", "github.com": "microsoft",
"linkedin.com": "microsoft",
}
def parent_of(domain):
return DOMAIN_PARENT.get(domain, domain)
ASN_ROLE is the hand-checked list from the previous section, and DOMAIN_PARENT is the alias map. I left AS8075 as mixed on purpose: Microsoft's own policy says BYOIP customers are registered there, so even before you ask what Microsoft runs on it, you know some of it isn't Microsoft.
def lookup(ips):
if not API_KEY:
sys.exit("Set IPGEOLOCATION_API_KEY first.")
try:
resp = requests.post(
BULK_URL,
params={"apiKey": API_KEY, "fields": "asn,company"},
json={"ips": ips},
timeout=(3, 30), # connect fast; big batches need read time
)
resp.raise_for_status()
return resp.json()
except requests.HTTPError as exc:
# Don't print exc itself: its message contains the URL, and the URL contains your key.
sys.exit(f"Bulk lookup failed: HTTP {exc.response.status_code}")
except (requests.RequestException, ValueError) as exc:
# A report built on half the data is worse than no report.
sys.exit(f"Bulk lookup failed: {type(exc).__name__}")
The error handler prints the status code and the exception type, never the exception itself. requests puts the full URL in its error messages, and this URL carries your API key, so a plain print(exc) ships the key straight into your logs. Exiting on failure is deliberate too: for a reporting job, a partial count is worse than no count.
def classify(row):
asn = row.get("asn") or {}
company = row.get("company") or {}
number = asn.get("as_number", "unknown")
asn_domain = asn.get("domain", "")
fallback_parent = parent_of(asn_domain) or asn.get("organization", "unknown")
parent, role = ASN_ROLE.get(number, (fallback_parent, "unclassified"))
# The prefix registrant differs from the mapped provider parent.
# This may be BYOIP or another delegated routing arrangement, so label
# the observable condition rather than claiming the contract behind it.
tenant = company.get("domain", "")
if number in ASN_ROLE and tenant and parent_of(tenant) != parent:
role = f"external-prefix:{company.get('name') or tenant}"
return parent, role, number
if __name__ == "__main__":
ips = [line.strip() for line in sys.stdin if line.strip()]
rows = []
for start in range(0, len(ips), BATCH_SIZE):
rows.extend(lookup(ips[start:start + BATCH_SIZE]))
by_parent, by_role = Counter(), Counter()
for row in rows:
if "message" in row: # bogon, private, or malformed input
print(f"skipped: {row['message']}", file=sys.stderr)
continue
parent, role, number = classify(row)
by_parent[parent] += 1
by_role[(parent, role, number)] += 1
print("By parent:", dict(by_parent))
for (parent, role, number), count in by_role.most_common():
print(f"{parent:<10} {role:<32} {number:<9} {count}")
A free-plan key cannot run this script because /v3/ipgeo-bulk is paid-only. If you adapt it to make individual /v3/ipgeo calls on the free plan, unmapped ASNs can fall back to the organization string, but asn.domain and company will be unavailable and the external-prefix check cannot run. The bulk endpoint returns a message object for bogon or malformed input instead of failing the batch, which is why the loop skips those rows rather than crashing.
Feed it a list of IPs on stdin:
printf '%s\n' 8.8.8.8 66.249.66.1 34.140.0.10 57.140.216.1 3.80.0.1 20.42.65.92 10.0.0.1 \
| python3 group_by_org.py
skipped: '10.0.0.1' is a bogon IP address.
By parent: {'google': 4, 'amazon': 1, 'microsoft': 1}
google mixed AS15169 2
google cloud-tenants AS396982 1
google external-prefix:Menlo Security, Inc. AS15169 1
amazon aws AS14618 1
microsoft mixed AS8075 1
Four of the six public IPs roll up to Google, and the role column splits them three ways. 34.140.0.10 sits in a range Google lists in cloud.json, and its company record still reads "Google LLC". The company field names whoever registered the range, not the Cloud tenant, which is why the role has to come from the ASN.
A few extra notes
Sibling ASNs set off false alarms. BGP monitors flag a route when the origin ASN doesn't match the prefix's ROA, and plenty of those turn out to be a company moving a prefix between its own ASNs. The ASINT team reviewed 17,282 BGP anomaly alerts from January 2023 to July 2024 and marked 1,621 of them, about 9.4%, as likely intra-organization. An org map cuts that noise.
Refresh the map at least quarterly, the cadence CAIDA uses for AS2Org. Registry records outlive the networks behind them: Twitch's AS46489 is still registered to Twitch Interactive Inc. and announced zero routes when I checked.
Don't verify Googlebot by ASN alone. An AS15169 match is a good hint, but Google's own method is a reverse DNS lookup plus a forward confirm, or a match against its published crawler ranges. 66.249.66.1 in the run above is the example address from that page.
If you need to see what a single ASN connects to rather than who owns it, routes and neighbors are a separate pivot. I walked through that in the post on routes, upstreams, and downstreams.
Start with the ASNs that actually show up in your logs, check each one against its registry record once, and write its role down next to it. Re-run that check every quarter. Google, Amazon and Microsoft will keep adding numbers, and not every new one will come with a comment as helpful as GOOGL-2's.
Top comments (0)