Use VPC IP Address Manager to manage subnet CIDRs

Amazon VPC IP Address Manager (IPAM) is a VPC feature that allows you to plan, track, and monitor IP addresses for your AWS workloads. Until now, VPC IPAM allowed you to allocate CIDR blocks and monitor them at the VPC level. With a recent feature enhancement in VPC IPAM, you can now manage CIDR allocations for your VPC’s subnets, and also monitor subnet IP address utilization using CloudWatch.

Using this feature, you can easily plan and organize your VPC’s IP address space for assignments to your VPC’s subnets in alignment with your organization’s connectivity needs. Specifically, if you are using shared VPCs where you create subnets for application teams, this feature is very useful as your developers can get automatic IP assignments for their subnets from the appropriate address space, at the time of subnet creation. For example, you can divide your VPC’s IP address space for different applications or based on type of workloads (e.g., databases, containers, etc.), and your developers can take allocations from the appropriate space depending on their requirements. You can even divide your VPC’s address space based on Availability Zones or in any other way depending on your business logic. Additionally, using this feature, you can closely monitor your subnet’s IP address utilization by configuring CloudWatch alarms. For example, you can configure CloudWatch to alert you when the IP address utilization for a subnet goes beyond the configured threshold, so you can take proactive action before the subnet runs out of IP addresses.

In this post, we will discuss the use cases for this feature, benefits, and the step-by-step instructions for using this feature.

Overview

To start planning your IP address space in IPAM, you need to create a top-level Pool that contains the CIDRs for your entire deployment. After that, you can allocate CIDRs from the top-level Pool, and create a hierarchical addressing plan. Figure-1 shows an example of a hierarchical addressing plan where the top-level Pool is split into AWS Region specific Pools, and the Regional Pools are further split into Pools for ‘Development’ and ‘Production’ workloads. Once the IPAM Pools are setup, you can use VPC IPAM to allocate CIDRs to VPCs. Refer to “Example IPAM Pool plans” for different ways you can create your IPAM pools.

Figure 1: An example of hierarchical addressing plan

With the newly launched subnet allocation feature, you can use VPC IPAM to manage the CIDR allocation for VPC’s subnets as well. The subnet allocation feature uses a new resource planning configuration on an IPAM Pool, which allows you to track the VPC’s CIDR space and allocate a CIDR to a subnet at the time of subnet creation. We will refer to these Pools as ‘Subnet Pools’ in this post. In case you have pre-existing subnets, you can ask VPC IPAM to backfill those subnets’ CIDRs into the Subnet Pool. This allows you to track the total usage of your VPC’s addressing space including pre-existing subnets. The relationship between a VPC, a subnet Pool and the VPC’s subnets is shown in Figure-2.

Figure 2: Relationship between a VPC, a Subnet Pool and the VPC’s subnets

The above VPC has only one CIDR block which is contained in a single Subnet Pool, but if your VPC has two or more CIDRs, you can choose to put them into different subnet Pools, or the same Subnet Pool depending on your use-case. The subnet allocation feature allows you to create subnets using IP space from the Subnet Pool and also specify constraints such as a network mask. Once you specify the network mask, VPC IPAM automatically allocates the next available CIDR to the subnet from the Subnet Pool. You can also provide constraints based on allocation tags which ensures that a CIDR is allocated only when the subnet requesting the CIDR has a matching tag.

Use cases for subnet allocation feature

1.   Allocating subnet CIDRs in a shared VPC

You can use VPC sharing to share subnets of a VPC with other AWS accounts within the same AWS Organization. Check out the VPC Sharing blog for the benefits and considerations for using VPC Sharing.

For managing the CIDRs of shared VPC’s subnets, the AWS Account that owns the IPAM must first create the Subnet Pool. The IPAM owner can further plan and organize the IP space under the Subnet Pool based on the subnets’ routing and security needs. A sample hierarchy is shown in Figure-3.

Figure 3: An example of Pool hierarchy for IP allocation to subnets

Such an addressing plan allows you to simplify your security operations by using the summary CIDRs provisioned in the Pools while configuring security related constructs like Security Groups or Network Access Control Lists, or allow-listing/block-listing configuration in your firewalls.

2. Allocating subnets CIDRs in a multi-VPC environment

You can use the subnet allocation feature in a multi-VPC architecture to standardize on the IP sizing of subnets. For example, mandating a smaller CIDR size, like a /27, for public subnets, and a larger CIDR size, like a /24 for private subnets (Figure 4). You can implement this by using the allocation rules feature on the subnet pool.

Figure 4: An example of Public and Private subnets in multi VPC environments

3.   Subnet level monitoring for EKS clusters

As customers scale their Kubernetes or EKS clusters, each cluster can grow to have thousands of pods. Both Kubernetes and EKS require an IP address per pod, and hence these deployments are heavy consumers of IP addresses. When this new feature, you can also monitor the IP address usage at subnet level, which is especially useful for EKS clusters. So, if you have an EKS cluster in 2 subnets, you can use the SubnetIPAllocated CloudWatch metric to monitor the IP address utilization of the EKS cluster’s subnets, and create alarms based on a threshold. If the SubnetIPAllocated metric reaches the threshold, you can proactively take remediation actions like creating your workloads in a new subnet. Check out documentation for details on subnet sizing considerations for EKS.

Additionally, to alleviate the IP exhaustion issue with scaled EKS deployments, you can configure secondary CIDRs in the CGNAT space on the VPC along with Amazon provided CNI. Check out Optimize IP Address usage in EKS clusters blog for more details on the solution.

VPC IPAM’s subnet allocation feature works with the CGNAT space and VPC’s secondary CIDRs as well. For this use-case, you can create a VPC IPAM Pool that contains the VPC’s secondary CIDR. After that, you can create subnet Pools and create a hierarchy of the CGNAT space, and use the subnet Pool to allocate CGNAT CIDRs to EKS subnets. Figure-5 shows a sample Subnet Pool design for an EKS deployment that using the CGNAT space:

Figure 5: An example of Subnet Pool design for an EKS deployment that is using the CGNAT space

Having discussed the use-cases above, let us go into the details of how you can use this feature to plan your IP address space for allocation to subnets, and also how you can get automatic IP allocations when you create subnets.

Before you begin

We assume that you’re familiar with the fundamentals of AWS networking and with VPC IPAM basics. Check out AWS documentation and VPC IPAM best practices blog for learning more about VPC IPAM.

In this blog, we show IPv4 CIDRs in the console snapshots. However, similar concepts apply while using IPv6 CIDRs as well.

Using VPC IPAM’s subnet allocation feature

A Subnet Pool is required for managing CIDR allocations to VPCs’ subnets. However, the VPC associated with a Subnet Pool may or may not have its CIDRs managed by VPC IPAM.

Because of this, the following two scenarios are possible when it comes to VPC’s CIDR management and the VPC’s subnet’s CIDR management:

Scenario-1: When your VPC is managed by VPC IPAM

In this case, VPC IPAM manages and monitors the CIDR allocation for the VPC. This is true in either of the following two scenarios:

• VPC IPAM provided the VPC’s CIDR when the VPC was created, OR
• VPC IPAM did not provide the VPC’s CIDR when the VPC was created. However, you have enabled IPAM, have an IPAM Pool in the VPC’s locale, and the VPC’s CIDR is backfilled into the IPAM Pool

Since VPC IPAM already has a Pool that has an allocation for the VPC’s CIDR, the goal is to continue the hierarchy of that Pool. This is required because any IP allocations made in the Subnet Pool must be tracked in the IPAM Pool that is tracking the VPC’s CIDRs.

Subnet Pool creation steps: For the purpose of this example, let us assume that VPC IPAM provided the CIDR at the time of VPC creation, and also that VPC had no subnets from before.

Step-1: When creating the Subnet Pool, select the Pool’s “source type” as “Pool” and select the Pool that provided the CIDR for that VPC. In this case, the Regional Pool for ap-northeast-1 which has CIDR 10.4.0.0/16, provided CIDR 10.4.16.0/20 to the VPC. This is shown in Figure-6.

Figure 6: Create Pool workflow

Figure 6: Create Pool workflow

Step-2: Under “Resource Planning” section, select “Plan IP space within a VPC”, select your VPC from the drop-down menu, and select the VPC’s CIDRs that you want to provision in the Subnet Pool. In this example, the VPC’s CIDR is 10.4.16.0/20. This is shown in Figure-7. After this, click “Create Pool”.

Figure 7: Select “Plan IP space within a VPC” in the Create Pool workflow

Figure 7: Select “Plan IP space within a VPC” in the Create Pool workflow

Now the Subnet Pool is provisioned. Figure-8 shows the snapshot of the Pool’s details. Note that the Pool has one managed CIDR, which is the 10.4.16.0/20 CIDR that we specified at the time of creating the Pool, but there are no allocations within this Pool and all the IPs are available. This is because the associated VPC does not have any subnets.

Figure 8: Viewing Pool details

Figure 8: Viewing Pool details

Step-3: Create two subnets for the VPC using the “IPAM-allocated” option, each with a /25 netmask length using the create Subnet workflow. Check out documentation for details on creating subnets. Refer Figure 9 for snapshot of create subnet workflow.

Figure 9: Create subnet workflow

Figure 9: Create subnet workflow

Step-4 (Verification): Now the Subnet Pool will automatically create allocations for the VPC’s subnets. Figure-10 shows that the Subnet Pool now has 3 managed CIDRs, one for the VPC’s CIDR and two additional CIDRs for the newly created subnets.

Figure 10: Viewing CIDRs in the Subnet pool

The Subnet Pool will also automatically create allocations for the two subnets. Figure-11 shows the allocations.

Figure 11: Viewing allocations for the two subnets

Scenario-2: When your VPC’s CIDRs are not managed by VPC IPAM

This holds true in either of the following two cases:

• You have not enabled VPC IPAM in your environment already, OR
• You have enabled VPC IPAM but your VPC was not allocated a CIDR from VPC IPAM and there is no IPAM Pool that has been backfilled with the VPC’s CIDR.

Subnet Pool creation steps:

If you’d like to manage the subnet CIDRs of the unmanaged VPC through IPAM, there are 2 ways

1. First, you’ll need to create a VPC IPAM Pool for managing the VPC CIDR through IPAM. After the VPC is managed by VPC IPAM, you can follow the steps mentioned in Scenario-1 to create the Subnet Pools. When you manage your VPCs in VPC IPAM, you get the allocation and monitoring benefits of VPC IPAM at both the VPC and the subnet level.
2. If you’d like to only perform subnet’s IP address planning, and not manage the VPC’s CIDRs, you will have to create a Subnet Pool in the VPC IPAM’s Scope as a top-level Pool. This is because VPC IPAM would not already be tracking the VPC’s CIDRs. Steps for this approach are covered below.

Step-1: When creating the Subnet Pool, select “IPAM Scope” as the source, select “Plan IP Space within a VPC” under the “Resource Planning” section, and select your VPC. Figure-12 shows the corresponding console snapshot.

Figure 12: Create Pool workflow

Step-2 (Optional): Importing CIDRs of the unmanaged VPC’s existing subnets. You need this step if you’d like VPC IPAM to backfill any existing subnets into this Pool. Expand the “Allocation rule settings” section, and select “Allow automatic import”. Figure-13 shows the console snapshot.

Figure 13: Configuring the pool’s allocation rule settings

Step-3: Click “Create Pool”.

Step-4 (Verification): You can use the steps mentioned in Scenario-1’s verification section for looking at the Subnet Pool’s allocations and provisioned CIDRs.

That completes the steps required to use this new feature.

Things to know

• In an AWS Organization wide deployment, use VPC IPAM’s subnet allocation feature from the delegated admin account. At the time of creating subnets, application accounts can request CIDR allocation from VPC IPAM’s Subnet Pool. Check out documentation for details on how to integrate VPC IPAM with AWS Organizations.
• When you create a Subnet Pool for a VPC that already has subnets, VPC IPAM will backfills those subnets’ CIDRs only if you enable auto-import under the Subnet Pool’s allocation settings.
• VPC IPAM will release a subnet’s CIDR allocation back to the Subnet Pool if you delete the subnet.
• A VPC can have multiple CIDRs which can all be contained in a single subnet Pool or multiple subnet Pools but a subnet Pool can only have association with one VPC
• VPC IPAM’s subnet allocation feature is available with the advanced tier. Check out VPC IPAM pricing page for details.

Conclusion

VPC IPAM’s Subnet Allocation feature can help you plan, organize, and allocate CIDRs to your Amazon VPC’s subnets. This feature also allows you to track and monitor IP usage at subnet level. In this blog post, we discussed the use-cases for this feature and how to use this feature step-by-step. This feature is available today, so try it out and let us know if you have any questions about this post by starting a new thread on AWS re:Post or contact AWS Support.

About the authors