When data sovereignty regulations require network-level enforcement, software as a service (SaaS) providers need more than the ability to advertise their own IP prefixes per AWS Region. They also need a way to programmatically manage those prefixes and tie each one to a specific AWS Region. In this post, we show how combining Bring Your Own IP (BYOIP), Amazon Virtual Private Cloud (Amazon VPC) IP Address Manager (IPAM), and Bring Your Own ASN (BYOASN) on AWS Direct Connect public virtual interfaces (VIFs) solves a common multi-Region routing challenge. IPAM provides the centralized control plane for provisioning and organizing your public BYOIP pools by Region. BYOASN gives you a Border Gateway Protocol (BGP) native mechanism to signal the originating Region to your end customers through unique per-Region Autonomous System Numbers (ASNs).
Many Independent Software Vendor (ISV) and SaaS providers deliver services to their end customers over public IP addresses. They use AWS Direct Connect with public VIFs for dedicated, low-latency connectivity. With BYOIP, you can advertise your own public prefixes over these public VIFs, giving your end customers a private path to your services without traversing the public internet. VPC IPAM brings those prefixes under a single management layer, where you can create per-Region pools, track allocations, and enforce compliance policies before the prefixes are ever advertised.
However, as data residency regulations tighten, particularly in Europe, providers face a new challenge. How do end customers distinguish which advertised prefixes belong to which AWS Region, especially when the provider doesn’t publish per-Region prefix mappings? This is where BYOASN closes the loop. By assigning a distinct ASN to each Region’s public VIF, you give end customers a standard AS_PATH policy hook they can use to steer traffic to the correct Region.
Overview
ISV and SaaS providers running multi-Region workloads on AWS commonly expose their services through public IP addresses. Enterprise end customers that require dedicated connectivity establish AWS Direct Connect circuits with public VIFs to reach the provider’s services directly, bypassing the public internet for better performance and security.
These providers use BYOIP to bring their public address space into AWS and advertise those prefixes over public VIFs. With this architecture, end customers can receive the provider’s routes directly on their Direct Connect circuits.
The challenge: Direct Connect location-to-Region association and data residency
Consider a SaaS provider with an end customer based in Zurich, Switzerland. The end customer has circuits at two Direct Connect (DX) locations:
- ZUR1 – Zurich DX location, associated with the eu-central-1 (Frankfurt) Region.
- ZH5 – Zurich DX location, associated with the eu-central-2 (Zurich) Region.
Swiss data sovereignty requirements allow the end customer to accept and route traffic only toward services running in the Zurich Region (eu-central-2). But because ZUR1 is associated with the Frankfurt Region, the customer’s router at ZUR1 receives BGP prefix advertisements that originate from eu-central-1, a different regulatory jurisdiction.
Figure 1: DX location ZUR1 advertises prefixes from the Frankfurt Region (eu-central-1), creating a data sovereignty conflict for the end customer
Why prefix-based filtering doesn’t work
The conventional approach would be for the end customer to filter BGP routes by IP prefix, accepting only specific Classless Inter-Domain Routing (CIDR) blocks associated with the Zurich Region. This approach fails for two reasons:
- The SaaS provider doesn’t publish per-Region prefix lists. Prefix-to-Region mappings are internal to the provider and change as the provider manages capacity across Regions.
- Prefix lists are operationally fragile. Any reallocation or expansion by the SaaS provider would require coordinated updates on the end customer’s routers.
The customer needs a routing-layer signal that reliably indicates the originating Region without requiring knowledge of the provider’s internal IP address management.
Solution: BYOASN with per-Region ASN assignment
With BYOASN, a feature of Amazon VPC IP Address Manager (IPAM), SaaS providers can bring their own ASNs to AWS and associate a distinct ASN with each Region. When the provider advertises its BYOIP prefixes, the AS_PATH attribute in the BGP UPDATE messages carries the Region-specific ASN as the origin AS.
Architecture
With BYOASN, each Region advertises prefixes with a distinct origin ASN. The end customer filters on AS_PATH
Why BYOASN is the right tool for this problem
| Requirement | How BYOASN addresses it |
| Identify BGP Prefix origin region | Each Region uses a distinct origin ASN visible in AS_PATH |
| No prefix list maintenance | ASN is the stable ID. Prefixes can change without impact |
| Standard filtering mechanism | AS_PATH filtering is a fundamental BGP operation supported by enterprise routers |
| Provider retains operational flexibility | The SaaS provider can reallocate, expand, or split BYOIP prefixes without coordinating with end customers |
| Compliance auditability | The AS_PATH in the routing table provides verifiable proof of prefix origin |
Prerequisites and requirements
Before implementing BYOASN for per-Region data sovereignty, the SaaS provider must complete the following prerequisites. The process builds on top of BYOIP, which itself requires IPAM.
1. Amazon VPC IP Address Manager (IPAM)
BYOASN is managed exclusively through Amazon VPC IPAM. You must have an IPAM instance configured in your account. You can follow our documentation to create an IPAM.
Requirements:
- Create an IPAM in your AWS account (or AWS Organizations management/delegated admin account).
- Configure IPAM operating Regions to include all Regions where you will advertise BYOIP prefixes (for example, eu-central-1 and eu-central-2).
- If using AWS Organizations, designate an IPAM administrator account.
- IPAM must have a public scope with regional pools configured per target Region.
2. Bring Your Own IP (BYOIP)
BYOASN requires that you have already brought your public IP address ranges to AWS using BYOIP and provisioned them to regional IPAM pools. You can follow our documentation to bring your own IP to IPAM.
Requirements:
- Own a publicly routable IPv4 (/24 minimum) or IPv6 (/48 minimum for advertisable) address range.
- The address range must be registered with a Regional Internet Registry (RIR): ARIN, RIPE, or APNIC.
- Address range must not be advertised from any other location at the time of provisioning.
3. Bring Your Own ASN (BYOASN)
After BYOIP is operational, you can provision your ASNs and associate them with specific Regions. You can follow our documentation to bring your ASN to IPAM.
Requirements:
- Own a public 2-byte or 4-byte ASN registered with a RIR (ARIN, RIPE, or APNIC).
- Upload the same X.509 certificate used for BYOIP to the Registration Data Access Protocol (RDAP) record for your ASN:
- ARIN: Add to “Public Comments” for the ASN using the “Modify ASN” option.
- RIPE: Add as a new “descr” field to the “aut-num” object.
- APNIC: Email helpdesk@apnic.net to add it to the “remarks” field for the ASN.
- Create an additional Route Origin Authorization (ROA) in your RIR with the ASN you are bringing to IPAM, in addition to the ROA authorizing Amazon ASNs.
4. AWS Direct Connect with public virtual interface
The end customer must have Direct Connect connectivity with public VIFs to receive the provider’s BGP advertisements. You can follow our documentation to create a Direct Connect public virtual interface.
Requirements:
- One or more AWS Direct Connect connections at the relevant DX locations.
- Public VIFs configured on those connections.
- BGP peering established (AWS-side ASN is 7224 on public VIFs).
- End customer router capable of AS_PATH filtering (standard BGP feature).
Summary of prerequisites
| Step | Component | Owner | Key requirement |
| 1 | IPAM | SaaS Provider | IPAM instance with operating Regions configured |
| 2 | BYOIP | SaaS Provider | Public IP range + RIR certificate + ROA for Amazon ASNs |
| 3 | BYOASN | SaaS Provider | Public ASN + RIR certificate on ASN record + ROA for own ASN |
| 4 | Direct Connect | End Customer | DX connection + public VIF + BGP peering |
| 5 | AS_PATH Filtering | End Customer | Route policy filtering on provider’s per-Region ASN |
Implementation steps
The following steps show how the SaaS provider provisions per-Region ASNs and how the end customer filters on them.
Step 1: Provision one ASN per Region
The SaaS provider provisions distinct ASNs for each Region:
Step 2: Associate and advertise the ASNs from the respective Regions
Step 3: End customer configures AS_PATH filtering
The end customer applies a BGP import policy to accept only routes originating from the Zurich ASN:
Cisco IOS-XR sample (any supported IOS-XR release):
Juniper Junos sample (any supported release, or 9.1+ if using 4-byte ASNs)
Operational considerations
- ASN swap frequency: You can switch from your own ASN back to the Amazon ASN at any time, but switching from Amazon ASN to your own ASN is limited to once per hour.
- No advertisement interruption: If your BYOIP CIDR is already advertised, you don’t need to withdraw it to associate a new ASN. The swap happens without downtime.
- ASN authorization expiry: The authorization message includes an expiry date. Renew before it expires to avoid service disruption.
- ROA maintenance: Make sure ROAs in your RIR remain valid and don’t expire. Invalid ROAs may cause Amazon to stop advertising your prefix.
- Public VIF BGP behavior: On a public VIF, AWS prepends ASN 7224 to the AS_PATH. With BYOASN, the path appears as
7224 <your-ASN>, with your ASN as the origin. - IPAM tiers: The Free IPAM tier has all the features needed for BYOIP/BYOASN to work within a single AWS account.
- BGP route security: Consider IPAM BGP route protection for prefix security through ROA monitoring and Resource Public Key Infrastructure (RPKI) delegation.
Conclusion
In this post, we showed how BYOASN solves a data sovereignty challenge that arises when DX location-to-Region associations create ambiguity, such as ZUR1 being associated with Frankfurt rather than Zurich. By assigning a distinct ASN per Region, ISV and SaaS providers give their end customers a stable, standards-based mechanism to enforce data residency requirements through AS_PATH policies. The end customer’s router becomes the enforcement point for data sovereignty, with no application-layer changes required.
To get started with BYOASN, open the Amazon VPC IPAM console and provision your first ASN. For more information, see:
Bring your own ASN in the Amazon VPC IPAM User Guide
Bring your own IP addresses (BYOIP) in the Amazon Elastic Compute Cloud (Amazon EC2) User Guide
AWS Direct Connect public virtual interfaces in the AWS Direct Connect User Guide
