Use Bring Your Own ASN (BYOASN) to enforce data sovereignty on AWS Direct Connect public VIFs

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:

1. 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.
2. 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

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

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:

# ASN 64500 for eu-central-1 (Frankfurt)
aws ec2 provision-ipam-byoasn \
    --ipam-id ipam-0123456789abcdef0 \
    --asn 64500 \
    --asn-authorization-context Message="$text_message_fra",Signature="$signed_message_fra"

# ASN 64501 for eu-central-2 (Zurich)
aws ec2 provision-ipam-byoasn \
    --ipam-id ipam-0123456789abcdef0 \
    --asn 64501 \
    --asn-authorization-context Message="$text_message_zrh",Signature="$signed_message_zrh"

Step 2: Associate and advertise the ASNs from the respective Regions

# Associate and advertise Frankfurt prefix with ASN 64500
aws ec2 associate-ipam-byoasn --asn 64500 --cidr 203.0.113.0/24
aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24 --asn 64500

# Associate and advertise Zurich prefix with ASN 64501
aws ec2 associate-ipam-byoasn --asn 64501 --cidr 198.51.100.0/24
aws ec2 advertise-byoip-cidr --cidr 198.51.100.0/24 --asn 64501

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):

as-path-set PROVIDER-ZURICH
  ios-regex '_64501$'
end-set

route-policy PROVIDER-ZURICH-ONLY
  if as-path in PROVIDER-ZURICH then
    pass
  else
    drop
  endif
end-policy

router bgp 65000
  neighbor 169.254.100.1
    address-family ipv4 unicast
      route-policy PROVIDER-ZURICH-ONLY in

Juniper Junos sample (any supported release, or 9.1+ if using 4-byte ASNs)

policy-options {
    as-path provider-zurich ".* 64501";
    policy-statement PROVIDER-ZURICH-ONLY {
        term accept-zurich {
            from as-path provider-zurich;
            then accept;
        }
        term reject-all {
            then reject;
        }
    }
}

protocols bgp {
    group DIRECT-CONNECT {
        neighbor 169.254.100.1 {
            import PROVIDER-ZURICH-ONLY;
        }
    }
}

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

About the authors