description: AWS reference architectures for landing your isp6 IPv6 PA allocation in production: a multi-AZ single-Region pattern with VPC IPAM, Application Load Balancer, and Egress-only In

Reference Architectures: AWS

Audience: isp6 members and AWS architects who have completed (or are about to complete) the AWS BYOIP onboarding and want a production-grade topology to land their /48 or /44 on. This article assumes the sizing decision from Sizing: /44 vs /48 has been made.

Last updated: May 2026

1. What's in this article

Two AWS reference architectures, both built around a real isp6 BYOIP /48 or /44:

• Architecture A: a single-Region production deployment for one workload. Two Availability Zones, three subnet tiers (public / application / data), Application Load Balancer, Internet Gateway and Egress-only Internet Gateway, RDS Multi-AZ. Right-sized for a single product team in one Region.
• Architecture B: a multi-Region, multi-account deployment. VPC IPAM in a network account holds the top-level /44; regional /48 pools are RAM-shared into workload accounts; each Region runs a Transit Gateway with an inspection VPC and spoke workload VPCs; Regions are connected by TGW peering.

Each architecture is the IPv6 / BYOIP plane of the design only. The rest of the Well-Architected Framework (identity, observability, FinOps, resilience patterns beyond multi-AZ / multi-Region) is unchanged by IPv6 and is out of scope here.

For BYOIP mechanics (ROAs, ownership verification, provision-byoip-cidr, advertise-byoip-cidr, AWS account limits) read Bring Your Own IPv6 to AWS.

2. Architecture A: single-Region production

When to choose this: one Region serves your traffic, one workload (or a small set of related workloads), one AWS account, and you've decided that the blast radius of a regional outage is acceptable or covered by application-layer resilience elsewhere.

2.1 What each component carries

2.2 IPv6 addressing inside the /48

A /48 gives you 65,536 /64 subnets, more than enough. A pragmatic convention that works at every scale:

/48 → /56 (per VPC)    e.g. 2001:db8:1000::/56
       /64 (per subnet) e.g. 2001:db8:1000:0::/64   AZ-a · public
                             2001:db8:1000:1::/64   AZ-a · app
                             2001:db8:1000:2::/64   AZ-a · data
                             2001:db8:1000:10::/64  AZ-b · public
                             2001:db8:1000:11::/64  AZ-b · app
                             2001:db8:1000:12::/64  AZ-b · data

The low nibble of the third hextet identifies the AZ; the next nibble identifies the tier. The same convention scales unchanged into the multi-Region case below, where each Region gets its own /48 and the same /56 / /64 carving repeats within. For the deeper internal carving discussion, see Planning Your isp6 Allocation.

2.3 What changes from "two-AZ /48" in the sizing article

This is the production version of the sizing-article example. The two extensions that matter:

• A dedicated data tier. The sizing article showed public + private; production almost always separates data into its own subnet, with no route to the IGW or EOIGW. RDS sits there.
• The ALB spans AZs. A single dual-stack ALB with subnets in both AZs is the default fronting pattern: clients see one DNS name and one AAAA record, and AZ failover is handled transparently.

3. Architecture B: multi-Region with VPC IPAM and Transit Gateway

When to choose this: two or more Regions serve your traffic, you have an AWS Organization with a dedicated network account, and you want centralised egress inspection (a firewall in front of every workload VPC's IPv6 egress).

3.1 The IPAM hierarchy

The point of the hierarchy is that the /48 is the unit advertised to the public internet (why) and the unit owned by a single Region, so there is a 1:1 correspondence. Carving deeper than /48 (into /56 per VPC) is purely an internal concern: it gives every workload account a clean, non-overlapping slice and leaves room to grow inside each Region without a renumber.

3.2 Per-Region anatomy

Every Region in the diagram repeats the same shape:

• A Transit Gateway in the network account, attached to every VPC in that Region. It's the IPv6 hub-and-spoke fabric for inter-VPC traffic, inter-account traffic, and (importantly) all egress to the internet pass through the TGW before reaching an IGW or EOIGW in the inspection VPC.
• An inspection VPC in the network account, holding the IGW, the EOIGW, and a Gateway Load Balancer in front of a stateful firewall fleet. Spoke VPCs route ::/0 to the TGW; the TGW routes to the inspection VPC; the inspection VPC routes through the firewall and out via the IGW or EOIGW.
• One (or more) workload VPCs in workload accounts, each with the three-tier layout from Architecture A, drawing its /56 from the regional /48 pool.

3.3 Inter-Region paths

Inter-Region traffic uses Transit Gateway peering. The eu-west-2 TGW and the us-east-1 TGW peer over the AWS backbone, and route tables on each side carry the peer Region's VPC /56 prefixes. This keeps east-west traffic off the public internet, but it does not change the fact that each Region's /48 is advertised separately, from its own BGP origin, to the public internet. There is no anycast across Regions on AWS; clients see one of the two Regions per session, and either DNS-based geo-routing (Route 53 latency-based or geolocation routing) or AWS Global Accelerator picks which one.

3.4 Why each Region has its own /48

This is the same constraint from the sizing article repeated in the production context: AWS BYOIP is per-Region, and the /48 is the longest globally-routable prefix. The same /48 cannot be provision-byoip-cidr'd in two Regions simultaneously. Each Region needs a distinct /48 from the same /44, advertised from that Region's edge. See Sizing §5.

4. AWS-specific design rules

A short list of AWS-specific gotchas that shape these architectures and that don't apply on Azure or GCP:

• IPv6 secondary CIDR on a VPC is immutable. Once you associate the BYOIP /48 with a VPC, you cannot disassociate it without recreating the VPC. Plan the VPC shape before associating.
• Subnet IPv6 CIDR is also immutable. Use the /56-per-VPC convention so you always have headroom inside a VPC to add subnets without re-architecting.
• EOIGW is IPv6-only. It does not carry IPv4 traffic; IPv4 egress for private subnets still goes through NAT Gateway. Don't be surprised when removing NAT Gateway breaks something IPv4-shaped.
• Security Groups need explicit IPv6 rules. A rule on 0.0.0.0/0 does not cover ::/0. Audit every Security Group when you turn on IPv6.
• RPKI ROAs must list 16509 and 14618. The second ASN is AWS Global Accelerator, and getting it wrong means the advertisement holds but Global Accelerator can't use the prefix. See BYOIP §8.2.
• Account limit: five BYOIP CIDRs per Region per account (combined IPv4 + IPv6). For Architecture B, the /48 lives in the network account, so workload accounts don't burn against the limit.

5. What's intentionally out of scope

The diagrams above are deliberately bounded to the IPv6 / BYOIP plane. The following are deferred to other sources:

The IPv6 layer slots underneath all of them without changing their conclusions, which is the point.

6. Further reading

Other reference architectures in this series

• Reference Architectures: An Overview: start here for the cross-provider terminology and the deployment-mode decision aid
• Reference Architectures: Azure
• Reference Architectures: Google Cloud
• Reference Architectures: On-Premises and Colocation

isp6 knowledge base

• Bring Your Own IPv6 to AWS: BYOIP mechanics, ownership verification, ROAs, costs
• Sizing: /44 vs /48: which size to order
• Planning Your isp6 Allocation: internal carving

AWS documentation

• Amazon VPC IP Address Manager (IPAM)
• IPv6 on AWS
• VPC IPv6 support: Amazon VPC User Guide
• Transit Gateway and IPv6
• Egress-only internet gateway
• AWS Well-Architected Framework

IETF

• RFC 6177: IPv6 Address Assignment to End Sites
• RFC 7454: BGP Operations and Security
• RFC 3849: IPv6 Address Prefix Reserved for Documentation

7. BYOIP rollout: quick checklist

If your VPC association is failing, your prefix isn't routable, or describe-ipv6-pools returns empty, walk through this in order. Each step gates the next: if step 2 didn't succeed, step

The commands below use the 2001:db8::/48 documentation prefix (RFC 3849) and eu-west-1 as the Region. Substitute your real isp6 /48 and target Region. AWS BYOIP CLI behaviour, return codes, and state-machine transitions are defined by AWS and may change, so treat the AWS references listed at the end of this section as authoritative.

Step 1: generate the signed authorisation in the isp6 console

In the subnet dashboard for the /48 you're bringing to AWS, the cloud panel produces two strings using the private key from your onboarding step 9:

• text_message: the AWS-format authorisation context plain text
• signed_message: the RSA signature over text_message

Both are required by provision-byoip-cidr. Re-generating is idempotent and safe, so produce fresh values whenever an older signature is rejected (signatures expire).

Step 2: provision the CIDR into AWS

aws ec2 provision-byoip-cidr \
  --cidr 2001:db8::/48 \
  --cidr-authorization-context Message="$text_message",Signature="$signed_message" \
  --region eu-west-1

This kicks off AWS's ownership verification (ROA + signature). Verification can take hours to days. The CIDR transitions through pending-provision → provisioned. Until it reaches provisioned, advertise-byoip-cidr will fail.

Step 3: flip the CIDR to advertised

aws ec2 advertise-byoip-cidr --cidr 2001:db8::/48 --region eu-west-1

This is the BGP-advertisement switch. Until it runs, traffic destined for your prefix won't reach AWS, even if the VPC association succeeds. State transitions provisioned → advertised. Reversible via withdraw-byoip-cidr.

Step 4: verify with the describe calls

aws ec2 describe-byoip-cidrs --max-results 10 --region eu-west-1
aws ec2 describe-ipv6-pools --region eu-west-1

Expected output on a healthy rollout:

• describe-byoip-cidrs returns your /48 with "State": "advertised". Anything else (pending-provision, provisioned, failed-provision, pending-advertise, failed-advertise, pending-withdraw) means a step is incomplete or AWS hasn't finished a verification.
• describe-ipv6-pools returns one Ipv6Pool per BYOIP CIDR in the account/Region, each with a PoolId of the form ipv6pool-ec2-…. This PoolId is the value you pass when associating the CIDR with a VPC (ipv6_pool on aws_vpc_ipv6_cidr_block_association in Terraform, --ipv6-pool on aws ec2 associate-vpc-cidr-block). Without it, AWS rejects the association.

Common failure modes

Authoritative references

AWS owns this lifecycle end-to-end. If anything in this checklist disagrees with AWS's documentation, AWS wins:

• Bring your own IP addresses (BYOIP) in Amazon EC2
• BYOIP for Amazon VPC
• provision-byoip-cidr: AWS CLI Reference
• advertise-byoip-cidr: AWS CLI Reference
• describe-byoip-cidrs: AWS CLI Reference
• describe-ipv6-pools: AWS CLI Reference

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.