How to configure small AWS virtual private clouds

Remember that famous quote from the animated film Aladdin in which the genie (voiced by the late Robin Williams) compares his power to the size of the lamp he’s contained in: “Phenomenal cosmic power…itty-bitty living space”?

That’s exactly how you’ll feel when you have to architect AWS virtual private clouds (VPC) in which there is a requirement that all VPC IPv4 subnet addresses be available via VPN or Direct Connect to the client’s on-premises networks, and the client’s network is short on IPv4 RFC1918 private address space.

Doing this recently revealed a number of considerations that you might wish to keep in mind if and when you need to architect a small VPC for a client.

• Brush up on your binary math and review everything you knew about CIDR addressing. For example, shifting a single bit left in the network portion of a CIDR doubles the number of subnets available; shifting a bit right halves the number of available subnets. So, a /27 contains two /28s. Changing the number of available network address bits also affects number of available IPs in each subnet. So it’s important to find a balance between number of available subnets — which determines you high-availability strategy — and the number of available IPv4 addresses in that subnet. Reminder: AWS takes four addresses out of each subnet. In the case of a /28, that’s almost 20% of the available IPv4 addresses.
• Run, don’t walk to the best IP calculator I have used for figuring out how to “chop up” smallish client address spaces, like a /20, into smaller VPCs. ipcalc is also available as an installable package for macOS ( brew install ipcalc) and from apt-get on Ubuntu (and therefore on Windows via the Linux subsystem). ipcalc is unique among tools I found because it lets you quickly calculate the IPs for any given CIDR “moving into” a smaller network. The installed version even outputs HTML files you can use in you documentation. Here’s an example showing ipcalc output for a set of addresses going “from” a /27 “to” a /28

  

• Allocate the IPv4 allocation from the client asymmetrically. This may not be obvious and I wouldn’t recommend it unless you have to. But in some cases, it’s the only way to address the shortage of IPv4 address space. Ususally, the architect should create VPCs of the same size within a customer’s assigned address space. But doing so isn’t a AWS requirement for VPCs. So, you can have VPCs of varying size within an overall address space, allowing you to customize the VPCs to the environments you need. For example, development environments might need fewer IPs and can therefore be smaller. This will help fit the applications to the available address space. The following diagram shows how to chop up a smallish IPv4 private address range — a /22 — into three VPCs with two smaller ones comprising one of the two larger address spaces. Once again, ipcalc is invaluable in calculating these kinds of VPCs. And it clearly demonstrates the relationship between CIDR network address bit allocation and the number of available subnets. Note how the two /24s add up to one /23 and two /23s equal one /22. You can use ipcalc to experiment with all the possible calculations to arrive at the best VPC design based on whatever IPv4 space you client gives you.

  

I hope this helps you design better VPCs and makes it easier to figure out how to manage the need for subnets and high-availability for EC2 instances running in AWS.