Bring Your Own IPv6 to AWS: A Guide for isp6 Members

Audience: isp6 members, cloud architects, and network engineers bringing their isp6-allocated IPv6 PA space to AWS using BYOIP.

Last updated: April 2026

Table of Contents

1. Introduction
2. Why Bring Your isp6 Allocation to AWS
3. What isp6 Handles vs. What You Do on AWS
4. How isp6 Manages the Lifecycle of Your Allocation
5. Solution Options: IPAM vs. Manual EC2 Provisioning
6. Cost Implications
7. Reference Architecture
8. Prerequisites for AWS BYOIP
9. Implementation Overview
10. Monitoring & Security
11. Rollback & Deprovisioning
12. Recommendations
13. Further Reading

1. Introduction

As an isp6 member, you already own a portable IPv6 allocation — a /48 or /44 block of Provider Assigned (PA) address space, registered in the RIPE Database and managed through your isp6 subnet dashboard. This guide walks you through how to bring that allocation to AWS using BYOIP (Bring Your Own IP), so you can use your own addresses across your cloud infrastructure while retaining full portability.

isp6 is a RIPE NCC accredited Local Internet Registry (LIR). Your allocation is drawn from isp6's RIPE address pool and is yours to announce from any network — AWS, another cloud provider, a colocation facility, or all three simultaneously. BYOIP on AWS is one of the most common use cases for isp6 members, and this guide covers everything you need to make it work.

2. Why Bring Your isp6 Allocation to AWS

2.1 Cost Elimination, Not Just Cost Reduction

AWS's public IPv4 pricing change (effective February 2024) charges $0.005/hour per public IPv4 address — attached or idle. A modest estate of 500 public IPv4 addresses costs roughly $21,900/year before a single byte of data leaves the VPC.

IPv6 changes the equation entirely: AWS does not charge for public IPv6 addresses — whether AWS-assigned or BYOIP. Combined with the Egress-Only Internet Gateway (no hourly or per-GB processing fee, unlike NAT Gateway's $0.045/GB), IPv6 removes two entire line items from your networking bill.

2.2 A Clean Reputation Slate

Your isp6 allocation is a fresh, never-before-used block from isp6's RIPE address pool. There is no prior owner, no inherited blocklist entries, no "noisy neighbour" effect. When you bring this allocation to AWS via BYOIP, you start with a pristine reputation — ideal for outbound email, API integrations, and any service where IP reputation affects deliverability or trust scoring.

Note: While your allocation starts clean, you are responsible for maintaining that reputation post-deployment. Misconfigured mail servers or abusive traffic originating from your range will degrade it over time.

2.3 True Portability

Because your allocation is registered through isp6's LIR under RIPE NCC, you can withdraw it from AWS and re-advertise it from another provider, a colocation facility, or a different cloud — all without changing a single allowlist entry or DNS record on the consumer side. Your addresses are never locked to a single cloud provider.

2.4 Address Planning at Scale

A /48 allocation gives you 65,536 /64 subnets — each containing a practically unlimited number of host addresses. A /44 gives you 16 times that. This removes subnet exhaustion as a design constraint and simplifies VPC CIDR planning across multi-account, multi-region architectures.

3. What isp6 Handles vs. What You Do on AWS

One of the advantages of ordering your IPv6 space through isp6's self-service portal is that many of the traditionally complex steps in the BYOIP process are already taken care of. Here is a clear breakdown.

isp6 handles

You handle on the AWS side

Key point: You do not need to apply to RIPE NCC, justify address need, or navigate RIR processes. Your isp6 membership and order give you a registered, RPKI-ready allocation that is ready for BYOIP from day one.

4. How isp6 Manages the Lifecycle of Your Allocation

When you bring your isp6 allocation to AWS, isp6 continues to manage the full RIPE lifecycle in the background. Understanding this lifecycle helps you see where AWS BYOIP fits within the broader picture.

4.1 Lifecycle Overview

flowchart LR
    Order["Order & Payment<br>(isp6 portal)"]
    Reserve["Reservation<br>Block assigned<br>to your account"]
    RIPE_A["RIPE Registration<br>inet6num created<br>(automatic)"]
    Activate["Activation<br>You submit your ASN<br>route6 + ROA created"]
    Active["Active Management<br>RPKI, rDNS, ROA<br>via isp6 dashboard"]
    AWS["AWS BYOIP<br>provision-byoip-cidr<br>(you provision)"]

    Order --> Reserve
    Reserve --> RIPE_A
    RIPE_A --> Activate
    Activate --> Active
    Active --> AWS

    style AWS fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5

4.2 What Happens at Each Stage

4.3 How This Relates to AWS

Your AWS BYOIP CIDR operates alongside isp6's RIPE lifecycle management, not instead of it. Specifically:

• ROAs — isp6 manages all ROAs for your allocation. Your network ASN and the AWS ASNs (16509, 14618) are both published through isp6's RIPE certification authority.
• route6 objects — isp6 manages the RIPE DB route6 for your origin ASN. AWS separately updates RADb when you advertise your BYOIP CIDR (you do not need to manage RADb entries).
• Reverse DNS — configured through your isp6 dashboard. AWS does not manage reverse DNS for BYOIP prefixes — the delegation configured in RIPE via isp6 is authoritative.
• Deprovisioning — if you deprovision from AWS, your isp6 allocation and all RIPE registrations remain intact. If your isp6 membership expires, the RIPE objects are cleaned up by isp6 — you should deprovision from AWS before that happens.

Important: Keep your isp6 membership active for as long as you are using the allocation on AWS. If the membership lapses, isp6 will deprovision the RIPE objects, which will invalidate the ROA and cause AWS to stop advertising your prefix.

5. Solution Options: IPAM vs. Manual EC2 Provisioning

There are two primary ways to onboard your IPv6 space into AWS. Choosing the right one depends on your organisational scale and operational maturity.

When to choose IPAM: You manage more than two accounts, operate in multiple regions, or need to integrate BYOIP with CloudFront Anycast Static IPs.

When CLI is sufficient: You are onboarding a single /48 in one account and one region, and your team is comfortable with CLI-based lifecycle management.

For full IPAM onboarding steps, see Bring your own IPv6 CIDR to IPAM.

isp6 /44 allocations and AWS BYOIP: AWS requires a minimum /48 for publicly advertisable BYOIP. If you hold a /44 from isp6, you can bring the entire /44 as a single BYOIP CIDR (AWS accepts any prefix up to /48 in length), or you can bring individual /48s carved from it — for example, one /48 per AWS account or region.

6. Cost Implications

6.1 Comparative Cost Model

The table below compares the annualised cost of three addressing strategies. All pricing is indicative — verify current rates at AWS VPC Pricing and IPAM Pricing.

^1^ IPv6 egress uses the Egress-Only Internet Gateway, which has no hourly or per-GB processing charge.

^2^ IPAM Advanced Tier: $0.00027/active IP/hour. Only required if you use IPAM for management. See IPAM Pricing.

Caveat: Pricing changes frequently. The figures above are based on publicly available rates as of early 2026. Always consult the AWS Pricing Calculator and the service-specific pricing pages linked above before making financial decisions.

6.2 What Doesn't Change

• Data transfer out (DTO) charges are identical regardless of whether you use AWS-assigned or BYOIP addresses, and regardless of IP version.
• Inter-AZ transfer remains $0.01/GB in each direction for both IPv4 and IPv6.

7. Reference Architecture

The following diagram illustrates how your isp6-allocated IPv6 range flows from RIPE through AWS's infrastructure to your workloads.

flowchart TD
    %% isp6 / RIPE Section
    subgraph ISP6_RIPE ["isp6 + RIPE NCC"]
        direction LR
        Alloc["Your IPv6 /48 or /44<br>PA Allocation (isp6)"]
        RIPE_DB["RIPE Database<br>inet6num + route6<br>(managed by isp6)"]
        ROA["ROAs via isp6<br>Your ASN + AWS ASNs<br>16509, 14618"]

        Alloc --> RIPE_DB
        Alloc --> ROA
    end

    %% Ownership verification and provisioning
    Verify["AWS Ownership Verification<br><br>X.509 cert on inet6num<br>or DNS TXT (IPAM)"]
    Provision["AWS BYOIP Provisioning<br><br>1. Verify ownership<br>2. Validate ROA via RPKI<br>3. pending-provision &rarr; provisioned"]
    BGP["AWS BGP Advertisement<br><br>advertise-byoip-cidr<br>Your prefix announced<br>from AWS edge routers"]

    ROA --> Verify
    RIPE_DB --> Verify
    Verify --> Provision
    Provision --> BGP

    %% AWS Region Section
    subgraph Region ["AWS Region"]
        subgraph VPC ["VPC (Dual-Stack)"]
            direction TB

            subgraph Subnets [" "]
                direction LR
                subgraph SubA ["Public Subnet (AZ-a)"]
                    ALB["ALB<br>(v6 EP)"]
                end
                subgraph SubB ["Private Subnet (AZ-b)"]
                    EC2B["EC2<br>(v6 addr)"]
                end
                subgraph SubC ["Private Subnet (AZ-c)"]
                    EC2C["EC2<br>(v6 addr)"]
                end
            end

            Gateways["Internet GW (inbound+outbound)<br>Egress-Only IGW (outbound-only for private)"]

            SubA --> Gateways
            SubB --> Gateways
            SubC --> Gateways
        end
    end

    BGP --> VPC

    %% Internet
    Internet(["Internet"])

    Gateways --> Internet

    %% Styling
    style ISP6_RIPE fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style Region fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style VPC fill:transparent,stroke:#333,stroke-width:2px
    style Subnets fill:transparent,stroke:none
    style SubA fill:transparent,stroke:#666,stroke-width:1px
    style SubB fill:transparent,stroke:#666,stroke-width:1px
    style SubC fill:transparent,stroke:#666,stroke-width:1px
    style Internet fill:#e4e4e4,stroke:#333,stroke-width:2px

Key Architectural Notes

• No EIP required. Unlike IPv4 BYOIP (which maps to Elastic IPs), IPv6 addresses from your BYOIP pool are assigned directly to ENIs — there is no intermediate EIP allocation step.
• Egress-Only Internet Gateway replaces NAT Gateway for IPv6 private subnets, providing outbound-only internet access with no processing fee.
• Dual-stack is the recommended deployment model. Associate your BYOIP IPv6 CIDR as a secondary CIDR on the VPC alongside your IPv4 CIDR.
• Your isp6 allocation remains portable. Even after onboarding to AWS, you retain full control through your isp6 dashboard. You can withdraw from AWS and re-announce from another provider at any time.

8. Prerequisites for AWS BYOIP

Because your IPv6 space is already allocated and registered through isp6, several of the traditional BYOIP prerequisites are already satisfied. This section covers what is already in place and what you still need to configure for AWS.

8.1 What isp6 Has Already Done

8.2 ROA for AWS ASNs

For AWS to announce your prefix via BGP, you need a ROA that authorises the AWS Autonomous System Numbers. This is managed through isp6's RPKI management — the same mechanism used for your own network's ROA.

Add the AWS ASNs using the cloud panel on your isp6 subnet dashboard — select your cloud provider and the ASNs are populated automatically. isp6 manages RPKI for your allocation — the ROA is published through isp6's RIPE certification authority, alongside your existing ROA for your own ASN.

ROA propagation via RPKI can take up to 24 hours. Do not proceed to AWS provisioning until the ROA is visible. Your isp6 subnet dashboard displays ROA propagation status, so you can track readiness without leaving the platform.

Important: If your prefix is currently announced from your own ASN (e.g., from on-premises infrastructure), ensure your existing ROA remains in place alongside the AWS ROA. Removing it prematurely will cause a routing disruption.

8.3 Ownership Verification

AWS needs to verify that you control the address space before allowing provisioning. isp6 has already completed the most complex part of this process during your onboarding.

What isp6 has already done:

During onboarding (step 9 — "Configure certificate"), the isp6 portal generates an RSA 2048-bit key pair in your browser using the Web Crypto API. The public key is automatically registered on the RIPE inet6num descr field for your allocation. You downloaded the corresponding private key at that time — isp6 never stores it.

What you do for AWS:

Use the private key from your isp6 onboarding to create the signed authorisation message that AWS requires during BYOIP provisioning. This message includes your AWS account ID, the prefix, and an expiry date. See the AWS BYOIP Onboarding documentation for the exact message format and openssl signing commands.

Lost your private key? You can regenerate a new key pair at any time from your isp6 dashboard (/member/certificate). Regenerating invalidates the previous key — isp6 will update the public key on the RIPE inet6num automatically.

Alternative — DNS TXT Record (IPAM only)

If you use VPC IPAM, you can verify ownership by placing a DNS TXT record instead of using the certificate-based method. See Tutorial: BYOIP to IPAM for details.

8.4 AWS Account Limits

9. Implementation Overview

This section outlines the provisioning lifecycle on the AWS side. For exact CLI syntax, signed message construction, and API parameters, refer to the AWS BYOIP Onboarding documentation.

9.1 Provisioning Lifecycle

flowchart LR
    Prepare["Prepare<br>(ROA for AWS + ownership verification)"]
    Provision["Provision CIDR<br>(pending-provision)"]
    Advertise["Advertise<br>(BGP announced)"]
    InUse["In Use<br>(Assign to VPC/ENIs)"]
    Withdraw["Withdraw<br>(stop BGP advert)"]
    Deprovision["Deprovision<br>(release from AWS)"]

    Prepare --> Provision
    Provision --> Advertise
    Advertise --> InUse
    InUse --> Withdraw
    Withdraw --> Deprovision

    Provision -->|"Typically < 2 hours<br>(can take up to 1 week)"| Deprovision

9.2 Step-by-Step Summary

Do not make manual changes to RADb or other Internet Routing Registries — AWS automatically updates RADb when you advertise or withdraw your prefix.

For the complete CLI walkthrough, including signed message construction, see:

• EC2 BYOIP Onboarding
• IPAM IPv6 BYOIP Tutorial (CLI)
• IPAM IPv6 BYOIP Tutorial (Console)

10. Monitoring & Security

10.1 Operational Monitoring

10.2 IAM Least-Privilege Guidance

Restrict BYOIP lifecycle operations to a dedicated infrastructure team. The key EC2 actions to control are:

Construct your IAM policies using the principle of least privilege. Use Condition keys to scope Advertise and Withdraw actions to specific CIDR ranges where possible. See the EC2 IAM Actions documentation for the full list of BYOIP-related actions and supported condition keys.

10.3 Security Considerations

• RPKI is non-negotiable. Your ROA is what prevents another AS from hijacking your prefix via BGP. isp6 manages your RPKI state and monitors ROA propagation status through your subnet dashboard — an expired or invalid ROA means AWS will cease advertising your range.
• Do not share the RSA private key used to sign the provisioning message. It is not needed after provisioning; store it securely or destroy it per your key management policy.
• SCPs for guardrails. In an AWS Organizations environment, use Service Control Policies to prevent non-infrastructure accounts from calling ProvisionByoipCidr or DeprovisionByoipCidr.
• ROA changes go through isp6. If you need to modify the ROA (e.g., to change the AWS ASN configuration or add a new provider's ASN), make the change through your isp6 subnet dashboard to avoid disrupting your BGP advertisements.

11. Rollback & Deprovisioning

If you need to revert — whether to move the range to another provider or to troubleshoot a routing issue — the AWS side is the reverse of provisioning. Your isp6 allocation and RIPE registrations remain intact throughout.

Your allocation stays yours. Deprovisioning from AWS does not affect your isp6 membership, your RIPE registration, or your ability to re-announce the prefix from another provider. This is the core portability benefit of owning your address space through isp6.

Warning: You must disassociate the CIDR from all VPCs and release all allocated addresses before you can deprovision. AWS will reject the deprovision call if the range is still in use.

Membership expiry warning: If your isp6 membership lapses, isp6 will deprovision the RIPE objects (ROA, route6, inet6num) following the standard lifecycle. This will invalidate the ROA that AWS depends on and cause your prefix to be withdrawn from BGP. Always deprovision from AWS before allowing your membership to expire.

12. Recommendations

1. Start with a /48. The minimum publicly advertisable IPv6 prefix for AWS BYOIP is /48. If you hold a /44 from isp6, decide whether to bring the full /44 or individual /48 slices based on your multi-account strategy.

2. Use IPAM for multi-account environments. If you manage more than 2-3 accounts or multiple regions, the centralised visibility of VPC IPAM prevents orphaned CIDR associations and provides audit trails that manual CLI management cannot.

3. Plan your subnet hierarchy. A /48 gives you 65,536 /64 subnets. Design a consistent allocation scheme (e.g., by environment, by service tier, by AZ) before you start assigning — retrofitting a numbering plan is painful.

4. Monitor RPKI via your isp6 dashboard. Your isp6 subnet dashboard shows RIPE registration state, ROA validity, and propagation status. Complement this with AWS-side monitoring (describe-byoip-cidrs) to catch issues early. An expired ROA means AWS will stop advertising your prefix.

5. Leverage the clean slate. Your fresh isp6 allocation has never been used. Protect that reputation by deploying proper SPF, DKIM, and DMARC records from day one if you use these addresses for outbound email, and by implementing egress filtering to prevent abuse originating from your range.

6. Deploy dual-stack, not IPv6-only (yet). While AWS services increasingly support IPv6-only VPCs, many third-party integrations and SaaS APIs still require IPv4. Run dual-stack with your isp6 BYOIP IPv6 as the primary addressing layer, falling back to IPv4 where necessary.

7. Evaluate CloudFront Anycast Static IPs. As of March 2026, CloudFront supports BYOIP IPv6 via IPAM for Anycast Static IP lists in dual-stack configuration — useful if you need deterministic, allowlistable IPs at the CDN edge. See the CloudFront BYOIP announcement.

13. Further Reading

AWS Documentation

• Bring your own IP addresses (BYOIP) to Amazon EC2
• Prerequisites for BYOIP
• Onboard your BYOIP address range
• VPC IPAM — What is IPAM?
• Tutorial: Bring your IPv6 CIDR to IPAM (CLI)
• Tutorial: Bring your IPv6 CIDR to IPAM (Console)
• IPAM Pricing
• AWS VPC Pricing
• Egress-Only Internet Gateway
• IPv6 on AWS — Whitepaper

RIPE NCC References

• RIPE — Managing ROAs
• RIPE — RPKI Validator
• RIPE Database — Query

AWS Blog Posts

• Introducing BYOIP for Amazon VPC
• Bring Your IPv6 Address Space to IPAM
• Understanding IPv6 Addressing on AWS
• CloudFront BYOIP for IPv6 via IPAM (March 2026)

Related isp6 knowledge base articles

• Designing the Next Internet: An Introduction to IPv6 — protocol primer for engineers new to IPv6; covers address anatomy, scopes, and SLAAC before you touch the cloud
• Planning Your isp6 Allocation — sizing and structuring your /48 or /44 before you announce it to AWS
• Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment — IPv4 reflexes to unlearn before configuring security groups and NACLs
• Building an IPv6 Integrated Project Team — cross-functional programme structure for a successful AWS rollout

isp6

• isp6 — Sign up
• isp6 — Digital Sovereignty

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.