Ensuring IPv4 Subnet Allocation Accounts for Expansion and Availability – SAP-C02 Study Guide

Ensuring IPv4 Subnet Allocation Accounts for Expansion and Availability

You need to plan for enough IPv4 addresses to be available, not only today but also for future use as well. That may sound obvious but the number of IP addresses needed can be easily overlooked. In the count, you must include all the resources that will be deployed in your VPCs, such as elastic load balancers, Amazon EC2 instances, Amazon RDS databases, Amazon Redshift clusters, and Amazon EMR clusters. You also have to be aware that the first four IP addresses and the last one of every subnet CIDR block are also reserved by AWS for internal use.

When defining your private address space plan, accommodate address space for multiple VPCs in a region, and within each VPC for multiple subnets spanning several Azs. Make sure to leave room for expansion in the future, by keeping unused CIDR block space.

As a general rule of thumb, it is better to size VPC and subnet CIDR blocks by excess rather than the other way around. That’s especially true if you plan to accommodate highly variable workloads that will need enough room to scale up. So, it is recommended to deploy large VPC CIDR blocks. Note that the largest IPv4 CIDR block you can create on AWS is a /16 block, providing 65536 IP addresses.

Using Hub-and-Spoke Topologies Instead of a Many-to-Many Mesh

Hub-and-spoke topology is highly recommended if you plan to either connect multiple VPCs to each other or multiple VPCs to an on-premises environment. The main reason is that when you connect multiple address spaces to each other, the number of connections grows with the power of the number of spaces to interconnect, which can rapidly become unmanageable when you expect tens, hundreds, or even thousands of different address spaces (including VPCs and on-premises environments). That’s precisely AWS TGW’s role, to provide a managed hub-and-spoke solution. It is highly available within a region across multiple AZs, so no need to deploy multiple TGWs, unless your organization requires a clear traffic split between some business entities or if you exhaust the resources a single TGW is able to sustain.

Enforcing Non-Overlapping Private IPv4 Address Ranges Where Private Networks Are Interconnected

It is best to plan for non-overlapping address spaces to avoid running into trouble when interconnecting multiple address spaces (VPCs and on-premises environments). Even if you carefully plan your networking address spaces, there’s no guarantee that you won’t run into a situation with overlapping IPv4 addresses tomorrow, for instance, as a result of a merger/acquisition. If the issue ever happens, you’ll still be able to interconnect the overlapping address spaces but it’ll make things somehow more complicated. In such a case, you’ll have to rely on NATing, or switching to IPv6, if that’s an option, or using VPC endpoints based on AWS PrivateLink or any other workaround to sort it out.

Thus, it is best to avoid running into the issue if you can and to plan accordingly. If that can help, you can find IP address management solutions on the AWS Marketplace to help plan and manage your IP address space.