Most customers do not care about the public IPs that are used to expose their solutions to the internet. There are cases where static IPs (Elastic IPs or EIPs) are important, for example when whitelisting IPs to third parties, but not the IP itself. There are some cases nevertheless, that the range of IPs is important.
IP reputation and whitelisting for large scale solutions that have been live for a long time could be a challenge to move away from when considering migrating the underlying infrastructure on AWS.
In this blog, we are not going to discuss the technical process of preparing, provisioning and advertizing IP ranges in AWS. Rather, I want to focus on important design considerations that one needs to make.
Limitations
Before we move on, I would like to consider some important limitations that we need to be aware of.
The most specific prefix ones can bring via Bring Your Own IP (BYOIP) is /24.
You can’t use the IP addresses that you bring to AWS for one AWS service with another service.
You cannot share your IP address range with other accounts using AWS Resource Access Manager (AWS RAM).
Looking at the above, and relating the limitations to actual solutions on AWS, the most specific prefix limitations mean that even if you only need a few EIPs for NAT Gateways, you still need to bring a complete /24.
Furthermore, if you need to use BYOIP with Amazon EC2 as well as with the AWS Global Accelerator, you need to bring a minimum of two /24 blocks, one for each service. After you bring an address range to AWS, it appears in the AWS account as an address pool. When you create an accelerator, you can assign one IP address from your range to it. Global Accelerator assigns a second static IP address from an Amazon IP address range. You need to bring two IP address ranges to AWS if you want both IPs to come from your ranges for your accelerator. This requirement is in place because Global Accelerator assigns each address range to a different network zone, for high availability. This means two /24 blocks are needed just for the AWS Global Accelerator for assigning 2 IPs from your range to it.
Last but not least, the limitation of sharing IP ranges with no other AWS accounts leads to some interesting design patterns for your multi-account AWS solution.
Design Considerations
As per the AWS Well-Architected Framework, account-level separation is strongly recommended for isolating production workloads from development or test workloads. The isolation could go one step forward, with requirements to isolate production workloads, for example due to compliance requirements. It is a good practice to set up multiple accounts as your workloads grow in size and complexity. For reference, a few of the benefits are:
Opportunity for rapid innovation;
Better insights on billing;
Flexibility defining your security controls;
Convenient adaptation to business processes and requirements.
Bellow, we are proposing a pattern that will help you design your solution around the aformentioned limitations.
In the above design you can see how you can deploy isolated VPCs in various accounts, with all internet traffic routed through a Transit Gateway in a centralized network account. The network account would be the account that holds all the provisioned BYOIP address ranges, with all the NAT gateways having EIPs from that pool.
Moreover, you can see how you can provision Application Load Balancers (ALBs) that leverage the AWS Global Accelerator. As you can see, two more BYOIP address ranges are needed for the Global Accelerator, reaching a total of three ranges required in this simplified example.
By sharing the private subnets using AWS RAM with the network account, it is then possible to create target groups for the ALBs that can have static routes to instances that live within the other accounts. Unfortunately this will not work for Auto Scaling Groups (ASGs) as instance registration to target groups across accounts is not possible. A custom solution using AWS Lambda could solve this limitation.
Conclusion
BYOIP would fit under more advanced network topics and is only part of a handful (relatively) of implementations on AWS. Scarcity of information on this topic requires that best practices are leveraged by implementations that require similar design choices. I hope the above will give you a head start when tackling the BYOIP topic for your projects for the first time.
