AWS BYOIP: bring your own IPv4 addresses to EC2

You prove you control the range with a certificate in its registry record and a ROA naming AWS's ASNs, provision it into an address pool, and allocate Elastic IP addresses from it as you would from AWS's own. Addresses you bring are not billed the hourly public IPv4 charge.

This guide covers EC2 through the AWS CLI. The same range can also go to AWS Global Accelerator, which has its own process, or through VPC IP Address Manager (IPAM), which adds a DNS-based way to prove control and the option to announce from your own ASN.

What AWS accepts

From AWS's documentation, on the day we checked:

• Size. The most specific IPv4 range you can bring is a /24.
• Registry. ARIN, the RIPE NCC or APNIC, and registered to a business or institution, never to a person.
• History. AWS may check the range's reputation and reject one with addresses that have a poor record (keeping a block clean).
• Legacy space is accepted but still needs a ROA.
• One Region at a time per range, and five ranges per Region by default; AWS Support can raise that.
• Where. Every commercial Region except the China Regions, and a list of Local Zones.
• Hands off the routing registry. AWS updates RADb itself, and a manual change that includes AWS's ASN makes provisioning fail.

Before you start

A ROA for AWS's ASNs. It must authorize AS16509 and AS14618, and any ASN announcing the range today, with the maximum length set to the size of the range you bring; through IPAM, set it to /24 so you can split the block. If you are moving the range from your own network, create the ROA for your current ASN first, so nothing that works now turns invalid (RPKI and ROAs). A ROA can take up to 24 hours to reach AWS.

A key pair and a certificate, made with OpenSSL 1.0.2 or later:

openssl genpkey -aes256 -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private-key.pem
openssl req -new -x509 -key private-key.pem -days 365 | tr -d "\n" > certificate.pem

The certificate in the registry record, on one line, including the BEGIN and END markers. Where it goes depends on the registry, and the field matters:

You can remove the certificate once provisioning has finished.

Step by step

01Sign the authorization message. The message names your account, the range and an expiry date:

text_message="1|aws|123456789012|203.0.113.0/24|20261231|SHA256|RSAPSS"
signed_message=$(echo -n $text_message | openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign private-key.pem -keyform PEM | openssl base64 | tr -- '+=/' '-_~' | tr -d "\n")

02Provision the range in the Region where you will use it:

aws ec2 provision-byoip-cidr --cidr 203.0.113.0/24 \
  --cidr-authorization-context Message="$text_message",Signature="$signed_message" \
  --region eu-central-1

03Wait for it. The status goes from pending-provision to provisioned. AWS says most ranges finish within two hours and some take up to a week; aws ec2 describe-byoip-cidrs --max-results 5 --region eu-central-1 shows where it stands.

04Prepare, then switch. To keep downtime short, allocate Elastic IP addresses from the new pool and attach them before the range is announced. aws ec2 describe-public-ipv4-pools gives the pool's ID, and aws ec2 allocate-address --public-ipv4-pool <pool-id> takes an address from it.

05Advertise. Stop announcing the range anywhere else, then:

aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24 --region eu-central-1

AWS recommends withdrawing the range from other locations first; while someone else announces it, AWS cannot promise that traffic for it reaches its network. You must advertise exactly the range you provisioned, never a part of it.

06Check it from outside. whois -r -h whois.ripe.net 203.0.113.0/24 | grep descr should show the certificate, and RIPEstat's validator should call the range valid for AS16509: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=16509&prefix=203.0.113.0/24".

Mistakes that cost a day

• The certificate in the wrong field. For the RIPE NCC, AWS reads descr and explicitly not remarks. Azure wants the opposite, so a block moved between the two clouds needs the record changed.
• A ROA with the wrong maximum length. AWS requires it to equal the size of the range you bring, or /24 through IPAM. A longer one invites hijacks, and AWS reserves the right to stop advertising a range whose ROAs do not follow its rules.
• Advertising part of the range. AWS advertises exactly what you provisioned. To use a smaller range, deprovision and provision again.
• Two networks announcing at once. Traffic splits between them, and AWS will not troubleshoot it.

Your own ASN

Through VPC IPAM, AWS can announce your range from your own ASN instead of its own. You add the same certificate to your ASN's registry record (for the RIPE NCC, as a descr line on the aut-num), create a second ROA naming your ASN, and AWS recommends an ASPA object that lists AS16509 and AS14618 as your providers; without them, the routes AWS passes on for you fail ASPA validation. You can switch the origin back to AWS's ASN at any time, and to yours at most once an hour.

If you lease the block

Leased space works, provided the registry shows it held by an organization. The holder does the registry side: the certificate in the inetnum record, which only the holder's maintainer can edit, and the ROA for AS16509 and AS14618. You do the rest from your AWS account.

Where RTM Networks fits

We lease /24s and larger from our own RIPE NCC address space, and sell blocks in the RIPE NCC, ARIN and APNIC regions. For space leased from us we add your AWS certificate to the registry record and create the ROA for AWS's ASNs, so provisioning is the only step left to you (lease IPv4). If you need fewer than 256 addresses on an EC2 instance, we can deliver them over a tunnel instead (GRE and WireGuard tunnels). How the hourly IPv4 charge adds up, and when bringing your own pays: the real cost of cloud IPv4. Other providers: BYOIP guides.