AWS BYOASN lets providers attach per-Region ASNs to Direct Connect routes

AWS has published a walkthrough of a feature that lets network providers attach their own public Autonomous System Numbers (ASNs) to individual AWS Regions and have those ASNs appear in the BGP advertisements customers receive over Direct Connect. According to a dev.to write-up of the AWS Networking and Content Delivery blog post, published on 3 November 2026, the feature is called BYOASN, sits inside Amazon VPC IP Address Manager (IPAM), and is used together with Bring Your Own IP (BYOIP) and Direct Connect public virtual interfaces (VIFs).

What BYOASN does

A provider registers one of its own public ASNs with AWS and ties it to a particular Region. When the provider advertises its BYOIP prefixes from that Region, the AS_PATH attribute in the BGP UPDATE carries that Region-specific ASN as the origin. Each Region can carry a different ASN, which turns the question of where a route originated into something a router can match with one stable rule instead of a list of prefixes that shifts over time.

The sovereignty problem it targets

The AWS post, as relayed on dev.to, builds its case around a SaaS provider with an end customer in Zurich. The customer has circuits at two Direct Connect locations: ZUR1, associated with the Frankfurt Region (eu-central-1), and ZH5, associated with the Zurich Region (eu-central-2). Both circuits sit physically in Switzerland, yet the router at ZUR1 receives advertisements for prefixes that originate in Frankfurt, a different regulatory jurisdiction. Swiss data sovereignty requirements permit the customer to accept and route traffic only toward services running in Zurich.

Filtering on IP prefixes does not solve this. Per-Region prefix mappings remain internal to the provider, and every reallocation or expansion on the provider side becomes a coordinated change on the customer's routers. BYOASN shifts the identifier from the prefix, which moves, to the ASN, which stays put.

How it appears on the wire

On a public VIF, AWS prepends its own ASN 7224, so the path a customer sees reads 7224 followed by the provider's per-Region ASN. The customer writes an import policy that accepts the approved origin ASN and rejects everything else. The AWS post shows the configuration shape for Cisco IOS-XR, as an as-path-set matched through an ios-regex pattern, and for Juniper Junos, as an as-path pattern ending in the same number. Because the ASN survives prefix reallocations, splits and expansions, the customer's router configuration does not have to follow the provider's capacity planning.

Prerequisites, split between provider and customer

The provider side carries most of the setup: an IPAM instance with a public scope and regional pools, with operating Regions configured for every Region that will advertise prefixes (a designated IPAM administrator account in AWS Organizations); a BYOIP range that is publicly routable, at least an IPv4 /24 or an IPv6 /48, registered with ARIN, RIPE or APNIC, and not advertised from anywhere else during provisioning; and a public 2-byte or 4-byte ASN registered with a RIR, with the same X.509 certificate used for BYOIP uploaded to the ASN's RDAP record, plus an additional ROA for that ASN on top of the ROA that authorizes Amazon's ASNs. Each regional ASN is provisioned with the AWS CLI command aws ec2 provision-ipam-byoasn.

The customer owns the remaining steps: a Direct Connect connection with public VIFs, BGP peering established against ASN 7224, and a router capable of AS_PATH filtering. The dev.to post stresses that this last requirement, simple as it looks, decides whether the design works — a customer that never writes an import policy has effectively agreed to a boundary its routers do not check.

Operational limits to plan around

The post lists several constraints. Switching from the Amazon ASN to the provider's own is limited to once per hour, while switching back is possible at any time. A prefix that is already advertised does not need to be withdrawn to associate a new ASN, so the swap happens without downtime. The authorization message carries an expiry date and must be renewed before it lapses. And the ROAs at the RIR have to remain valid, because an invalid ROA can cause Amazon to stop advertising the prefix.

Why it matters

This feature moves data-residency enforcement from paperwork into routing. The end customer's router becomes the point where the residency boundary is applied, with no application-layer changes, and the routing table on the customer's own equipment becomes the record an auditor can verify with a single show command. Providers keep the freedom to move prefixes between Regions without dragging customers into change windows, and customers get a filter that stays correct as the provider's network evolves. For regulated sectors, the operational details — the hourly swap limit, the expiring authorization and ROA validity — belong on the runbook from day one.