Introducing Bring Your Own IP (BYOIP) for Amazon VPC

A public IP address is a big part of what is used to identify you on the public internet. In cases such as migration, whitelisting, or even IP address reputation, it can be important to you as the application owner, that your application’s IP address remains the same, or in the case of a migration, that your IP address moves with your application. In the past, publicly routable IP addresses on Amazon Web Services, in the form of Amazon Elastic IP addresses, have been provided from the Amazon public IP address ranges. While this works great for the majority of AWS customers, there are some who would like to use their own public IP addresses as Elastic IPs as they move to the AWS Cloud.

Bring Your Own IP for Amazon Virtual Private Cloud (VPC) is a highly requested networking feature, enabling customers with an existing IPv4 address range to use that same address range on AWS.

VPC overview

To describe where an Amazon Elastic IP address can be used on AWS, let’s look at some of the foundational components that make up Amazon VPC.

These components are shown in the following figure, and the following table explains them.

#

Component

Description

1

Amazon EC2 instance

An Amazon EC2 instance is privately addressed from the CIDR address range allocated to the Amazon VPC. For public access, the instance would need both a route to the internet gateway (IGW), and a public IP address (an Amazon Elastic IP address).

2

Amazon Elastic IP addresses

For each Instance that needs to connect to the internet, an Amazon Elastic IP address can be used to identify the instance on the public internet. The Amazon Elastic IP address is a static 1:1 NAT on the IGW from the instance’s private IP address to the Amazon-allocated public IP address.

3

Amazon internet gateway (IGW)

An IGW allows for the connectivity to the public internet and public AWS services. A 0.0.0.0/0 or default route within the VPC will point to the internet gateway.

4

Public AWS services

Some Amazon services sit in the public AWS realm. With the use of AWS PrivateLink, some of these can be connected to through VPC endpoints. However, traditionally an EC2 instance would need a public IP address to connect to, for example, Amazon S3.

5

The public internet

The Amazon IGW, along with connectivity to public AWS services, also provides connectivity to the public internet, through the use of Amazon Elastic IP addresses.

Access to public AWS services or the public internet can be enabled through using an IGW and the association of Amazon Elastic IP addresses.

BYOIP overview

With Amazon BYOIP you can bring part or all of your public IPv4 address range from your on-premises deployment to your AWS account. You continue to own the address range, but AWS advertises it on the internet on your behalf.

After you bring your address range to AWS, it will appear in your account as an address pool, from which you can then create Elastic IP addresses and use these with your AWS resources, such as EC2 instances, NAT gateways, and Network Load Balancers.

When using Amazon BYOIP there are several steps involved in bringing your IP address range to AWS, including preparing your range, provisioning, advertising, and allocating Elastic IP addresses.

As Amazon is advertising your address range out to the public internet on your behalf, you have the ability to stop advertisement, and even deprovision your IP address range, if you wanted to move your IP addresses to a different AWS Region or to migrate back to your on-premises deployment.

Preparing your IP address range

To bring your own IP address range to AWS, you will need a /24 IPv4 prefix or larger, registered to your business or institutional entity with either the American Registry for internet Numbers (ARIN) or Réseaux IP Européens Network Coordination Centre (RIPE NCC). You also need to ensure that you are bringing IP address ranges with a clean history. We might investigate the reputation of the IP address ranges you provide and reserve the right to reject an IP address range if it contains one or more IP addresses that have a poor reputation or have been associated with malicious behavior.

With BYOIP, your security is a top priority for us. To guarantee that you and only you can bring your IP address space, we ask you to do two things: First, give Amazon authorization to advertise the IP address range you’re bringing to AWS. Second, provide authentication that the account you’re bringing that range to is actually an account owned by you. To give us the authorization to advertise your IP address range, we ask you to create a Route Origin Authorization (ROA) for AWS ASNs 16509 and 14618.

You can create a ROA through your Regional internet Registry (RIR). A ROA tells the world who is allowed to advertise your IP address range. Your RIR, such as ARIN or RIPE NCC, makes your ROA publicly available to everyone. You can think of it as declaring your intention to use your IP address range on AWS. A ROA contains an IP CIDR, an AS number that is allowed to advertise that CIDR, and an expiration date. Only you, after authenticating with your RIR, can create a ROA for your IP addresses. A ROA that authorizes Amazon to advertise your space tells us that it is truly you who are trying to bring that space to AWS.

The ROA needs to be specific for the IP address range you want to bring to AWS. If you want to bring a /24, you can create the ROA for the specific /24. If you have a /22 and want to bring only a /24 from that range to AWS, you can create a ROA specifically for the /24, while keeping the /22 intact. You don’t need to break down the /22 into /24s. And if you have a /22 and you want to bring the 4 x /24s to AWS, for example in different accounts or Regions, you can create a ROA for the /22 and set max length to /24. This way you don’t have to create ROAs individually for the /24s. The ROAs need to be valid for the period you are using the IP range on AWS. For more information on creating a ROA request, you can find more information from ARIN here, and from RIPE here.

What a ROA doesn’t tell us is what your AWS account is. Since ROAs are public, we need to authenticate that you really are you. We also need to authorize that you allowed that IP address range to be brought into your account. You will need to create and give us a cryptographically secure signature that includes both the CIDR you’re bringing and your AWS account ID. To do this, you’ll need to do the following:

Create a public X509 certificate from the key pair. The following command is an example, with the certificate expiring in 365 days in this case: openssl req -new -x509 -key private.key -days 365 | tr -d “\n” > publickey.cer

The x509 cert is only needed during provisioning, and can be deleted after provisioning succeeds.

Create a signed message. The format of the message is as follows, where the date is the expiration date of the message: 1|aws|account|cidr|YYYYMMDD|SHA256|RSAPSS

Last, update the RDAP record for your RIR with the X509 certificate. To view your certificate, you can run the following command:

cat publickey.cer

For ARIN, add the certificate in the Public Comments section for your address range.

For RIPE, add the certificate as a new desc field for your address range.

Note: When copying the certificate, be sure to copy the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– from the certificate.

Since only you can update RDAP information for your IP addresses, we are guaranteed that the public key we find there is actually yours, and we can use that public key to verify the signature you provided.

Others won’t have access to your private key, so they won’t be able to generate a signature that your public key can verify, which means no one but you will be able to bring your IP address space to AWS!

Detailed steps can be found in the AWS BYOIP Documentation.

Provisioning

After your address range has been successfully prepared, the next step in bringing your own IP addresses to AWS is provisioning. To provision your IP address range, you need to use the AWS CLI / API.

You can use the following provision-byoip-cidr command to provision the address range:

The output of a successful completion of this command looks similar to the following, showing both the description, the subnet, and the state, which will initially remain in “pending-provision” and then move to “Cidr successfully provisioned into Ipv4Pool <IP-Pool-ID>” once accepted and provisioned.

To monitor the provisioning of your CIDR, you can use the describe-byoip-cidrs command. Note that the output example here shows a successfully provisioned IP address range:

Once successfully provisioned, the describe-byoip-cidrs will return the IP address pool that has been created for your CIDR range.

Advertising

After your IP address range has been provisioned and the creation of a pool of addresses is complete, you can now advertise your IP address range or create Elastic IP addresses from the newly created pool. Here, let’s first advertise the IP address range, which can be done by using the advertise-byoip-cidr command:

The advertise-byoip-cidr will respond with a state of “advertised” if the CIDR range has been successfully advertised to the public internet by Amazon.

We recommend that you stop advertising the address range from other locations before you advertise it through AWS. We can’t reliably support the situation where you would advertise your IP address range from other locations. Specifically, we couldn’t guarantee that traffic to the address range will enter our network, and it would affect our ability to troubleshoot issues. To minimize down time, you can configure your AWS resources to use an address from your address pool before it is advertised, and then simultaneously stop advertising it from the current location and start advertising it through AWS.

If for any reason you wanted Amazon to stop advertising the CIDR address range, you can use the withdraw-byoip-cidr command to withdraw the prefix from advertisement to the public internet:

When withdrawing the advertisement of your BYOIP range, the state of the CIDR range will return from a state of “advertised” to a state of “provisioned”.

Creating Elastic IP addresses from your pool

During the provisioning stage of bringing your IP addresses to AWS, an AWS IP address pool was created, for example ipv4pool-ec2-0588c9b75a25d1a02. Upon successful creation of an IP address pool, you can use the allocate-address command to allocate an Amazon Elastic IP address. There are three ways to allocate an Amazon IP address:

Specifying the IP pool with the –public-ipv4-pool command. This will allocate a random address from the pool referenced.

Specifying a specific address with the –address <ip_address> command. This will allocate a specific address from the pool that the address resides in.

Leave out both the IP pool and the address, to randomly allocate an Amazon Elastic IP address from the Amazon address space.

Deprovisioning

If you no longer want to use your address range with AWS, you have the option of stopping the advertisement of the range, and then deprovisioning it. Note that you must release all of the Elastic IP addresses you have allocated from your address pool first.

After all of the Elastic IP addresses have been deallocated from the pool, you use the deprovision-byoip-cidr command:

If you want to move the IP address range from one AWS Region to another, you must fully deprovision the IP address range from the current Region and then provision the IP address range in the new Region. You need to go through the full workflow again.

Conclusion

If keeping your current IP address range to help with migrating to AWS or preserving your IP reputation is important to you or your application, BYOIP for AWS now offers one of the easiest IP preservation solutions on AWS.

With both the ability to bring your IP address range to AWS and use this range in the form of Amazon Elastic IPs, or even deprovision and migrate your IP address range back to your on-premises if needed, Amazon Bring Your Own IP greatly simplifies how you can use your CIDR address range on AWS.

We look forward to your feedback here, on social media, or in the AWS forums.