What Is an ASN? The Number Behind Every BYOIP Announcement

Technical snapshot: 20 August 2026. Provider ASNs and registry delegations change; confirm the numbers against the linked official documentation before you create a ROA.

Most AWS BYOIP guides reach a sentence like this within the first page: create ROAs authorizing ASNs 16509 and 14618 to originate your prefix. If autonomous system numbers are not part of your working vocabulary, that instruction cannot be sanity-checked. You either copy the right numbers or you do not, and the difference can surface as a request stuck in validation or a range that fails to route as expected.

Autonomous system numbers are one of the more approachable ideas in inter-domain routing. Once the concept is clear, the sequence of BYOIP paperwork stops looking arbitrary.

An autonomous system, in one paragraph

An autonomous system (AS) is a collection of IP prefixes operated under a single routing policy by one organization. Internally, an AS can run whatever it likes: OSPF, IS-IS, EIGRP, static routes. Externally it presents one consistent statement to everyone else: here are the prefixes I can reach, and here is how I will accept traffic for them.

An Autonomous System Number (ASN) is the globally unique integer that identifies one of those systems. It is the name a network answers to in BGP. RFC 1930 sets out the original guidelines for creating and using them.

If IP addresses identify buildings, ASNs identify the delivery networks that carry things between them. BGP is how those networks tell each other what they can reach.

Where ASNs come from

ASNs follow the same delegation hierarchy as IP addresses. IANA holds the top-level pools and delegates blocks to the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), which assign individual numbers to organizations under regional policy.

That shared hierarchy is the reason RPKI can cover prefixes and ASNs under one trust model. The registry that records who holds a /24 is the same registry that records who holds an ASN. The registration side of this is covered in Who Actually Owns an IP Address?.

16-bit, 32-bit and the ranges worth recognizing

ASNs began as 16-bit numbers, which allowed 65,536 of them. That was comfortable in 1995 and tight by 2007, so RFC 6793 widened the field to 32 bits, or roughly 4.29 billion.

The space is not split into one public block and one private block. IANA maintains a short registry of numbers reserved for specific technical purposes, and everything outside that registry is delegated in blocks to the RIRs as they need it. The special-purpose reservations are the ones worth memorizing:

AS number	Reason for reservation	Reference
0	Must not be used as an origin AS or appear in an AS_PATH	RFC 7607
112	Used by the AS112 project to sink misdirected reverse-DNS queries	RFC 7534
23456	AS_TRANS, substituted by a 16-bit-only speaker that cannot represent a 32-bit ASN	RFC 6793
64,496-64,511	Documentation and sample code	RFC 5398
64,512-65,534	Private use. Internal only, never announced to the public internet	RFC 6996
65,535	Reserved (last 16-bit number)	RFC 7300
65,536-65,551	Documentation and sample code	RFC 5398
4,200,000,000-4,294,967,294	Private use in the 32-bit range	RFC 6996
4,294,967,295	Reserved (last 32-bit number)	RFC 7300

Two of those reservations, AS 112 and AS 23456, sit inside the low 16-bit range, which is why it is misleading to describe 1 to 64,495 as one uniformly assignable block. The rest of that low range has been delegated to the RIRs in full.

The 32-bit range above 65,551 is more interesting, because most of it has never been handed to anyone. IANA delegates it to the RIRs in blocks, and the gaps between those blocks are genuinely unallocated rather than reserved or assignable:

Range	Status in the IANA registry
65,552-131,071	Reserved by IANA, not delegated to any registry
131,072-155,961	Delegated to APNIC
155,962-196,607	Unallocated
196,608-219,547	Delegated to RIPE NCC
219,548-262,143	Unallocated
262,144-275,868	Delegated to LACNIC
275,869-327,679	Unallocated
327,680-330,751	Delegated to AFRINIC
330,752-393,215	Unallocated
393,216-404,380	Delegated to ARIN
404,381-4,199,999,999	Unallocated

The highest number IANA has delegated to any registry is 404,380. Adding the 16-bit and 32-bit delegations together gives roughly 140,000 AS numbers in registry hands, about 0.003 percent of the 32-bit space. Exhaustion is not a live concern.

Two practical notes follow from the tables. First, private ASNs belong inside your own network: a data centre fabric, a firewall pair, a lab bench. They should be removed before routes reach the public internet, and well-run transit networks filter them. Second, 32-bit ASNs are written two ways: asplain (4200000000) and asdot (64086.59904). Asplain is the modern default, and a vendor CLI that insists on asdot is showing you a notation preference, not a different number.

How BGP actually uses ASNs

Three jobs, all load-bearing.

Identity. Every BGP speaker announces itself with its ASN. Peering sessions are configured against the neighbour’s ASN, and a mismatch means the session never establishes.

Path recording. As an announcement propagates, each AS prepends its ASN to the AS_PATH. A route arriving at your border carrying AS7922 AS3356 AS2516 tells you which networks it crossed to get there. Shorter paths win in the BGP decision process when other attributes are equal, which is why operators sometimes prepend their own ASN several times deliberately, making a path look artificially long to push traffic onto a different link. The average path length in the global IPv4 table on 1 August 2026 was 4.7 hops; the most enthusiastic prepend seen that week was 61 repetitions by a single AS.

Loop prevention. A BGP speaker that finds its own ASN already in the AS_PATH discards the announcement. That one rule is what stops inter-domain routing from feeding on itself.

The rightmost ASN in the conventional AS_PATH display, the AS that injected the prefix in the first place, is the origin AS. That term is worth holding on to, because every part of BYOIP validation is built around it.

The internet, by the numbers

Some scale, taken from the Weekly Global IPv4 Routing Table Report of 1 August 2026, which measures the table as seen from APNIC’s router in Japan:

Measure	Value
BGP routing table entries (IPv4)	1,065,956
Total ASes present in the routing table	78,975
Average prefixes per ASN	13.50
Origin-only ASes (they announce, they do not carry transit)	67,847
Transit ASes	11,128
Origin ASes announcing exactly one prefix	27,685
Average AS path length	4.7
32-bit ASNs allocated by the RIRs	50,656
32-bit ASNs actually visible in the table	41,235
IPv4 prefixes with a valid ROA	718,950
IPv4 prefixes with an invalid ROA	1,697
IPv4 prefixes with no ROA at all	345,309

Two patterns are worth pulling out. The first is that most autonomous systems are leaf networks: 67,847 of 78,975 provide transit to nobody. They exist to announce their own address space and connect it to a couple of upstreams, and more than a third of them announce a single prefix. Anyone considering their own ASN would be joining a very large club of small participants.

The second is that roughly a third of the IPv4 table still has no ROA at all. Route origin validation is now normal practice rather than universal practice, which matters when you are deciding how carefully to treat your own authorizations.

Do you need your own ASN for BYOIP?

Usually not, which tends to surprise people.

In hyperscaler BYOIP, the cloud provider announces your prefix from its ASN. You keep the addresses and they do the announcing, so your job is to authorize their ASN to originate your prefix. That authorization is exactly what a ROA is. Which number goes into it depends on the provider, and increasingly on which flavour of that provider you are onboarding to:

Provider and scope	Origin ASN(s) to authorize	Notes
AWS, commercial Regions	16509 and 14618	Authorize both. Either may originate the range depending on Region and path
AWS GovCloud (US)	8987 only	AWS documents this as the only ASN to authorize for GovCloud; the commercial numbers do not apply
AWS European Sovereign Cloud	16509 and 214101	214101 is a RIPE NCC 32-bit ASN, so a ROA that only names the commercial pair is incomplete here
Google Cloud, Premium Tier	396982	The default tier for a public advertised prefix
Google Cloud, Standard Tier (Preview)	19527	Google recommends separate ROAs for the advertised prefix and each top-level delegated prefix, or one ROA with a maximum length of /24
Microsoft Azure, public cloud	8075	Advertised from the Azure region first, then globally by Microsoft’s wide area network
Microsoft Azure, US Gov Cloud	8070	Applies only when the range is onboarded to the US Gov Cloud

All three providers also advise keeping an authorization for your own ASN if it currently announces the range. AWS asks you to create the ROA for your existing ASN before adding Amazon’s, Microsoft recommends the same to avoid problems during migration, and Google suggests a parallel ROA naming your ASN so that validating networks do not treat the prefix as invalid while both origins exist. The overlap window is where migrations break.

Getting the number wrong produces an unhelpfully quiet failure. Provisioning stalls, or the range provisions and never routes, because RPKI-validating networks see an announcement nobody authorized and drop it. The differences between the three platforms go well beyond the ASN, and are covered in BYOIP on AWS, Google Cloud and Azure.

When you do want your own ASN

Skip the paperwork if you are only bringing space into one cloud. Start it if any of the following apply:

• You are multihoming. Two or more upstream transit providers with your own policy across them. In most regions this is the canonical justification an RIR expects.
• You operate your own edge. Physical routers, IX peering, colocation presence, a network you control end to end.
• You run hybrid or on-premises alongside cloud. You announce some space yourself, hand some to a provider, and want consistent policy across both.
• You want announcement portability. Announcing from your own AS turns a move between providers into a routing change rather than a re-onboarding project.
• Traffic engineering matters to you. Communities, prepending and selective announcement are not available to you when someone else owns the origin AS.

Obtaining one is procedural rather than difficult: apply to your RIR directly or through an LIR, meet the regional justification criteria, and pay the annual fee. The work that follows is the part people underestimate, and it includes peering relationships, IRR objects, RPKI configuration, a PeeringDB record and somebody watching the announcements.

ASNs and ROAs: the part that actually matters

A Route Origin Authorization binds three things: a prefix, a maximum prefix length and an ASN authorized to originate it. The ASN in that ROA is the origin AS, and nothing else. Three consequences are worth internalizing.

A prefix can be covered by several authorizations. This is how AWS BYOIP works in practice: 16509 and 14618 are both authorized for the same prefix, as separate authorizations, because either may originate it.

Maximum length has teeth. Set it to the most-specific route you intend to announce, and no longer. A /24 announced only as a /24 gets a maximum length of 24, which closes off more-specific authorization. Set it loosely, say 32 on a /24, and you have pre-authorized every more-specific announcement from that ASN. AWS VPC IPAM is a deliberate exception for larger parents: AWS asks for /24 so the space can be split across Regions.

Transit ASNs do not belong in the ROA. Only the AS that originates the announcement goes in. Upstreams appear in the AS_PATH, not in the authorization. This is the most common conceptual error in first-time ROA creation, and it is explored further in What Is RPKI? ROAs, Origin Validation and Your BYOIP Prefix.

Looking ASNs up

Useful when validating a BYOIP setup or working out who is announcing what:

• RDAP or WHOIS at the relevant RIR for the holder, contacts and status of an ASN.
• RIPEstat and bgp.tools for live announcements, AS_PATH data, prefix counts and RPKI state.
• PeeringDB for peering policy, IX presence and facility footprint.
• Team Cymru IP to ASN mapping for quick prefix-to-ASN lookups from the command line.

When an announcement is not behaving, work through it in order: is the prefix in the global table at all, what origin AS is it arriving from, does that match the ASN in the ROA, and is the RPKI state valid. Wiring those checks into an automated preflight is covered in Automating BYOIP.

Five ways ASNs bite people

1. The wrong cloud ASN in the ROA. GovCloud instead of commercial AWS, Standard Tier instead of Premium, or a European Sovereign Cloud onboarding that only names the commercial pair. The failure is silent and costs hours.
2. A private ASN leaking outbound. A lab configuration escapes into production and gets filtered by an upstream.
3. Stale IRR objects. The route object still names the ASN from a previous provider. Some upstreams still filter on IRR data, so this breaks things quietly and RPKI cannot fix it.
4. Assuming an ASN implies address space. It does not. ASNs and prefixes are separate resources with separate registrations, and an AS holding no prefixes is perfectly legitimate.
5. Confusing asdot with asplain. The same number in a different notation. Usually a short embarrassment rather than an outage.

FAQ

Where to go next

The origin AS is the second of three gates in a BYOIP onboarding. The first is proving you hold the space, and the third is the cryptographic authorization that ties the two together.

• Who Actually Owns an IP Address? (And Why It Matters for BYOIP)
• What Is RPKI? ROAs, Origin Validation and Your BYOIP Prefix
• What Is BYOIP? A Practical Guide to Bringing Your Own IP Addresses
• BYOIP on AWS, Google Cloud and Azure: What Actually Differs?
• Compare BYOIP supporters, including which ASN each one announces from

References

• IANA - Autonomous System (AS) Numbers registry
• IANA - Special-Purpose Autonomous System (AS) Numbers
• RFC 1930 - Guidelines for creation, selection and registration of an Autonomous System
• RFC 6793 - BGP support for four-octet AS number space
• RFC 6996 - Autonomous System reservation for private use
• RFC 7607 - Codification of AS 0 processing
• RFC 7300 - Reservation of last Autonomous System numbers
• Weekly Global IPv4 Routing Table Report, 1 August 2026 (NANOG)
• AWS - Prerequisites for BYOIP in Amazon EC2 (ASNs 16509, 14618, 8987, 214101)
• AWS - Bring your own IP addresses (BYOIP) to Amazon EC2
• Google Cloud - Create a public advertised prefix (ASNs 396982 and 19527)
• Microsoft Azure - Create a custom IPv4 address prefix (ASNs 8075 and 8070)
• Microsoft Azure - Custom IP address prefix (BYOIP)