AWS Puts the Region Inside the AS Path on Direct Connect

TL;DR

• AWS BYOASN is a feature of Amazon VPC IP Address Manager that lets a provider bring its own public Autonomous System Number to AWS and attach a different one to each Region.
• AWS published the walkthrough on 3 November 2026, combining BYOIP, VPC IPAM and BYOASN on Direct Connect public virtual interfaces.
• The problem it answers is identifying the regional origin of routes at a Direct Connect location: a Zurich circuit associated with the Frankfurt Region advertises prefixes from a different regulatory jurisdiction.
• Filtering by IP prefix fails on two counts, because providers keep per-Region prefix mappings internal and reallocation forces coordinated edits on the customer's routers.
• BYOASN puts the Region in the origin AS of the BGP path, so the customer writes one import policy scoped to the approved origin ASN.
• Four prerequisites have to exist first: an IPAM with public scope, a BYOIP range registered at a RIR, a public ASN with the BYOIP certificate on its RIR record plus a ROA, and a public VIF peering with ASN 7224.
• The operational edges are concrete: the swap from the Amazon ASN to your own is limited to once per hour, the authorization message carries an expiry date, and an invalid ROA can stop the prefix from being advertised.
• The routing table then becomes the artefact an auditor can read, with the enforcement point inside the customer's router policy.

A Direct Connect location carries routes from its associated AWS Region

The post opens with a case that is easy to picture and hard to fix. A SaaS provider has an end customer based in Zurich with circuits at two Direct Connect locations. ZUR1 is associated with the Frankfurt Region, eu-central-1. ZH5 is associated with the Zurich Region, eu-central-2. Swiss data sovereignty requirements allow that customer to accept and route traffic only toward services running in the Zurich Region.

Geography places both circuits physically in Switzerland. The routing table exposes the regional origin of the advertised prefixes. The customer's router at ZUR1 receives BGP advertisements for prefixes that originate in Frankfurt, which sits in a different regulatory jurisdiction. At ZUR1, a dedicated private path in Zurich carries traffic to a service running in Frankfurt.

Two conventional answers fail. Filtering by IP prefix and accepting only the CIDR blocks tied to Zurich requires the provider's per-Region prefix mapping, which remains internal while the provider moves capacity between Regions as it manages demand. Maintaining a prefix list turns every reallocation or expansion on the provider side into a coordinated change on the customer's routers. Both approaches turn a commercial relationship into a permanent synchronisation project.

The region becomes the origin AS in the path

The mechanism is old and unglamorous, which is the point. BYOASN is a feature of Amazon VPC IP Address Manager. A provider brings its own ASNs to AWS and associates a distinct ASN with each Region. When the provider advertises its BYOIP prefixes, the AS_PATH attribute in the BGP UPDATE carries the Region-specific ASN as the origin AS.

On a public VIF, AWS prepends 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 Zurich origin and rejects everything else. The post shows the shape for Cisco IOS-XR, as an as-path-set matching the trailing ASN through an ios-regex pattern, and for Juniper Junos, as an as-path pattern ending in the same number.

The design uses the ASN as its identifier. The ASN remains stable across prefix reallocations, splits and expansions, leaving the customer-side router configuration unchanged. The provider keeps its operational freedom, and the customer keeps a rule that does not rot.

Four prerequisites, and two of them belong to the customer

The prerequisites and implementation sections are worth reading before promising anything to a client; the provider provisions each regional ASN with the AWS CLI command aws ec2 provision-ipam-byoasn. Each step has an owner.

The provider needs an IPAM instance, with operating Regions configured for every Region where prefixes will be advertised, a public scope and regional pools. In an AWS Organizations setup that means a designated IPAM administrator account. The provider also needs the address range published through BYOIP: a publicly routable IPv4 /24 minimum or an IPv6 /48 minimum for an advertisable range, registered with ARIN, RIPE or APNIC, and not advertised from any other location when it is provisioned. Then comes the ASN itself, a public 2-byte or 4-byte number registered with a RIR, with the same X.509 certificate used for BYOIP uploaded to the ASN's RDAP record, and an additional ROA created for that ASN on top of the ROA authorizing Amazon's ASNs.

The customer owns the last two steps: a Direct Connect connection with public VIFs, BGP peering established against ASN 7224, and a router capable of AS_PATH filtering. That last requirement reads trivial and decides whether the design works. A provider can advertise the cleanest signal in the world; a customer with no route policy on the import side has accepted a distinction it never enforces.

The customer's import policy is where the boundary is enforced

This is the sentence in the post that a procurement conversation should be built on. The end customer's router becomes the enforcement point for data sovereignty, with no application-layer changes required. The application remains unchanged. The customer's import policy enforces the residency boundary.

That placement has a consequence for how these projects get scoped. The provider delivers a signal, an ASN per Region and a documented mapping, and the customer delivers the policy that acts on it. The provider advertises a Region-specific origin ASN and documents its regional mapping. The customer's import policy determines which regional origin ASNs its router accepts.

There is a second-order benefit in the same design. Because the ASN is the identifier, an audit can verify regional origin directly from the routing table. The routing table on the customer's own equipment shows the path, and a show command performs the check directly on the router.

The operational edges: an hourly swap, an expiry date and a ROA

Four operational facts in the post decide whether a clean design survives its first quarter.

Switching from your own ASN back to the Amazon ASN works at any time. Switching the other way, from the Amazon ASN to your own, is limited to once per hour. A provider that plans a migration window should know that before the window opens. If a prefix is already advertised, it does not need to be withdrawn to associate a new ASN, and the swap happens without downtime.

The authorization message carries an expiry date, and it has to be renewed before it lapses. The ROAs in the RIR have to stay valid, because an invalid ROA may cause Amazon to stop advertising the prefix. Both of those are calendar items attached to a networking design, and both fail silently in the direction of a route that quietly disappears.

The post also notes that the Free IPAM tier carries the features needed for BYOIP and BYOASN within a single AWS account, and points at IPAM BGP route protection through ROA monitoring and RPKI delegation for prefix security. The last item is the one to put on the roadmap early: the same mechanism that carries residency is a routing announcement, and route announcements deserve the same protection as any other.

What the routing table proves in an audit

Consider how the same question gets answered in two organisations. One compliance team keeps a spreadsheet that maps three prefix ranges to the Zurich Region and updates it by hand after each capacity change. At another organisation, the customer's router holds an import policy tied to one origin ASN, allowing prefix reallocations under a stable identifier.

The organisation with the import policy can demonstrate the accepted advertised-route origin and its routing-policy boundary on demand. The spreadsheet-based process records its prefix-to-Region mapping in a manually maintained description. That difference is what a routing signal buys, and it is also the reason the prerequisite list matters more than the feature announcement: the mechanism only produces evidence when the customer's side of the relationship is configured to produce it.

For a company running a residency commitment on top of a hybrid network, the practical next step is smaller than a migration. Ask which circuits terminate in a location whose Region differs from the jurisdiction you are claiming, then ask what your import policy does with a path you did not expect. The answer is usually a policy that accepts everything, which is a good place to start the work, and the wider question of what a sovereign infrastructure and cloud exit plan has to prove belongs next to it.

Sources

• Use Bring Your Own ASN (BYOASN) to enforce data sovereignty on AWS Direct Connect public VIFs, AWS Networking & Content Delivery, aws.amazon.com, 2026-11-03
• Create a Direct Connect virtual interface, AWS Direct Connect User Guide, docs.aws.amazon.com

Source: the AWS Networking & Content Delivery post of 3 November 2026 by Gonzalo Escarrá and Juliano Forti, read in full the same day. The ZUR1 and ZH5 example, the eu-central-1 and eu-central-2 associations, the two reasons prefix filtering fails, the ASN 7224 prepend, the provisioning commands and ASN samples, the RDAP certificate steps per RIR, the ROA requirements, the once-per-hour swap limit, the authorization expiry and the note on the Free IPAM tier all come from that post. The audit reading, the two-organisation comparison and the opening import-policy question are Netics analysis.