Amazon VPC IP Address Manager Best Practices

Internet Protocol (IP) address management is an essential network planning and management component, and creating a scalable addressing scheme allows your AWS and hybrid network to expand, accommodating the needs of your workloads. Careful consideration for how your IP address space is allocated minimizes the risk of overlapping Classless Inter-Domain Routing (CIDR) blocks, and of IP space exhaustion.

Additionally, planning how IP space is allocated helps you build your infrastructure environments to support optimal routing rules configuration, as well as consistent CIDR aggregation. Allocating non-overlapping IP space and tracking the already overlapping environments, planning for consistent IP assignment based on environment, organization or business unit, and monitoring utilization all become key parts of scaling a global network on AWS. Moreover, acquisitions and divestures impact how you manage IP addresses at an organization level, and having the right IP addressing plan can help speed up these processes.

In this post, we’ll focus on best practices and considerations that you can use when designing your IP addressing plan, with the help of Amazon Virtual Private Cloud IP Address Manager (VPC IPAM), an AWS service that simplifies planning, tracking, and monitoring IP addresses for your AWS workloads.

Prerequisites

We assume that you’re familiar with the fundamental AWS networking features and services. Our focus will be on the Amazon VPC IPAM best practices. Therefore, let’s review the most common IPAM constructs:

• Scope: A scope is the top-level construct within an IPAM, and it represents the IP addressing for a single network. When you create an IPAM, you get two default scopes: public-scope and private-scope. Public-scopes are used for all public workloads, and private-scopes are used for all private workloads.
• Pool: You can have multiple pools inside of each IPAM Scope. A pool contains one or more CIDR blocks.
• Allocation: An allocation is a static CIDR assignment to a specific resource. You can create an allocation for a specific VPC, or for all VPCs assigned to a specific department/function of your Enterprise. Additionally, you can use custom IPAM allocations for any workloads that are deployed outside of AWS.

The diagrams in the post use the RFC3849 IPv6 addressing range of 2001:db8::/32, for illustration purposes only. Amazon VPCs support IPv6 Global Unicast Addresses (GUA), so you must configure the appropriate IPv6 addresses in your environment. Let’s start then exploring some Amazon VPC IPAM best practices for AWS and hybrid networks.

1. Scaling IP address management with VPC IPAM and AWS Organizations

Different organizations can have different operational models which can drive VPC, network connectivity, and application infrastructure ownership. For example, the network team can own connectivity to AWS Transit Gateway, AWS Cloud WAN, or AWS Direct Connect, while application teams own their infrastructure, including the VPCs. Alternatively, the network team can own and maintain all of the network services, along with the VPCs. This reflects in the AWS Organization structure. Therefore, depending on your operational model, accounts can create VPCs using IPAM pools shared with them, or this task is managed centrally.

Amazon VPC IPAM can be integrated with your organization’s structure. For IP address allocation, it’s recommended that you enforce the separation of duties and permissions by creating an IPAM-administrator account for your Organization. Here are some considerations regarding this account:

• It must be a member of the Organization, and it can’t be the Organization Root account.
• It will administer creation of IPAM Scopes, Pools, and your internally-managed CIDR allocation/refill policies for IPAM pools.
• It can be your centralized infrastructure/network connectivity account, or a separate IPAM-admin account for a deeper separation of duties.

Amazon VPC IPAM and AWS Control Tower

You can use AWS Control Tower to set up and securely govern your Organization structure and account vending. With Control Tower, you must provide the central network-admin account, or infrastructure account, with the right AWS Identity and Access Management (IAM) permissions to create network infrastructure for your multi-account deployment. You must also grant the necessary IAM permissions to this account to perform VPC IPAM operations. For more details on the required VPC IPAM permissions, see the documentation. Additionally, this post provides further details on using IPAM with AWS Control Tower.

2. IP addressing and IPAM Pool design best practices

Hierarchical and summarize-able IP addressing scheme

A hierarchical IP addressing scheme allows you to follow an IP allocation policy that best fits your needs. For example, creating regional IP CIDRs and then dividing each regional CIDR into department-specific CIDRs. Therefore, you can easily summarize your CIDRs regionally, simplifying network management and better managing your services’ quotas. Additionally, a hierarchical and contiguous IP addressing scheme allows you to easily configure network segmentation constructs, for example, security groups (SGs), Network Access Control Lists (NACLs), and firewall rules.

When you create a VPC IPAM pool, you provision a CIDR for the pool. The pool assigns space within that CIDR for Allocations. You can create your own IPAM hierarchy, with multiple pools, by starting with a few standard segmentation models and then adapting them to your needs. The first pool will be the top-level pool. There you can provision a CIDR with a larger network mask and further segment it. For example, the top-level pool can be an enterprise-wide CIDR block, which you can segment based on regions, or various departments like dev and test, using additional pools:

• Top-level pool AWS Environment (10.0.0.0/8)
  • Regional pool in AWS Region us-west-1 (10.0.0.0/16)
    • Development pool (10.0.0.0/24)
    • Production pool (10.0.1.0/24)

The following figure shows a single region deployment example. The Level-1 pool is allocated to the us-west-1 region, with two sub-pools: one each for development and production environments:

Figure-1: An example of hierarchical configuration in VPC IPAM in one region

You could also perform segmentation by business lines, products, and others. The hierarchy you use is driven by your enterprise design and permissions model, and VPC IPAM doesn’t limit you to just one scenario. Therefore, you can use it to organize CIDRs in the best way for your Organization. You can create a VPC IPAM Pool hierarchy up to a depth of 10. To scale-out our example to a multi-region deployment, we must configure more regional and environment-dedicated pools. The following figure shows an example IPAM configuration for three regions.

Figure-2: An example of hierarchical and summarize-able configuration in VPC IPAM across three regions

Managing public IPv4 and IPv6 prefixes

With public IPv4 and IPv6 CIDRs, AWS advertises public IP addresses regionally. While planning your public-pool hierarchies, it’s recommended that your Regional-IPv4-Pools are /24 or bigger, and your Regional-IPv6-Pools are /48 or bigger. When creating the pool, its settings define if it can be used for the direct addressing of resources, and the region for which the pool is intended. When you create and share the Pools in the public VPC IPAM scope, accounts across your Organization can use them for Elastic IPv4 allocation to their resources, or IPv6 prefixes to their VPCs.

You can advertise or withdraw independently the prefixes associated with your public pool(s) in VPC IPAM. This allows you easily Bring Your Own IP (BYOIP) to AWS, as you can separately configure the VPC IPAM pool(s), provision the CIDR(s), and allocate IP addresses to resources, without disrupting existing prefix advertisements to the internet. More details on the BYOIP steps can be found in the VPC IPAM BYOIP tutorials.

Defining CIDR allocation rules

You can use VPC IPAM to define rules regarding the use of IPAM Pool CIDRs for VPCs in your environment. These are called allocation rules, and they determine whether resources are compliant or non-compliant.

It’s recommended that you create allocation rules that are in line with your business model. For example, you could set an allocation rule stating that only VPCs with the tag ‘prod’ can get CIDRs from the IPAM pool named Production. Furthermore, a rule can enforce that CIDRs allocated from a pool can be no larger than /24. In this case, a resource could still be created using a CIDR larger than /24 from this pool, if the space is available. However, doing so violates the allocation rule on the pool, and in turn IPAM flags this resource as noncompliant.

VPC-level IP address subnetting

Once you create VPC IPAM and the corresponding pools for your deployment, resources like VPCs can use VPC IPAM to get the right CIDRs allocated. The next step is to plan for allocating a VPC’s CIDR across multiple Availability Zones (AZs) and subnets. In IPv4, addressing is usually driven by the number of hosts or resources planned for a subnet. In IPv6, it’s recommended to utilize a sparse allocation method that lets you keep buffer of unused IPv6 prefixes between different AZs, types of subnets, etc. This lets you easily accommodate growth, while keeping the simple aggregation boundaries. An example of IPv6 prefix allocation at a VPC-level is presented in the following figure.

Figure-3: An example of IPv6 allocation at a VPC level

3. Integrating VPC IPAM with your existing AWS environment

When you create your pools, it’s recommended that you allow IPAM to automatically import any pre-existing resources into the respective IPAM pools. Resources discovered by IPAM are marked as managed if they’re contained in a CIDR of an IPAM pool, and are being monitored by IPAM for potential CIDR overlap and compliance with pool allocation rules. Otherwise, they default to unmanaged, and still monitored and IPAM for IP address overlap. The following figure shows an unmanaged VPC that was discovered by VPC IPAM:

Figure 4: IPAM discovery of unmanaged, non-overlapping VPC

Importing resources into IPAM doesn’t impact the state of workloads in VPCs, or connectivity, and gives you insights into the current state of your IP addressing landscape. If IPAM discovers resources with private IPv4 CIDRs, the resource CIDRs are imported into the default private scope and do not appear in any additional private scopes you create. Also, note that you cannot ignore resources in the public scope.

4. Using IPAM with multiple un-connected AWS networks

Grouping private IPv4 addresses in different IPAM scopes can help you control overlapping resources in your environment. When you create an IPAM instance, two default scopes (one private and one public) are created for you. You can create additional private scopes, to which you can map environments using overlapping CIDRs, such as acquisitions or business units. Connectivity with these environments must be thoroughly assessed, as the decision to continue using overlapping CIDRs can impact business requirements.

It’s recommended that you create separate private scopes for each of your unconnected environments. This will let you monitor the IP addressing plan for the various un-connected environments from VPC IPAM, without generating overlap conflicts and alarms in IPAM. When IPAM discovers resources with private IPv4 CIDRs, they’re imported into the default private scope and don’t appear in any additional private scopes you create. You can move CIDRs from the default private scope to another private scope to map your environment to the targeted scope design.

In an environment where there’s no need to create different private scopes, you can use a hierarchical pool structure to provide the necessary VPC IPAM segmentation. Let’s look at an example of the IPAM pools configuration for two overlapping scopes, for a company and an acquisition, in the following two figures:

AnyCompany IPAM private scope:

Figure-5: Configuration of multiple scopes in IPAM, AnyCompany scope

Acquired company IPAM private scope:

Figure-6: Configuration of multiple scopes in IPAM, acquired company scope

Creating separate private scopes gives you visibility into the IP addressing structure of the two companies’ IP addressing structure, even if this is overlapping. Then, you can use this information to create the right connectivity and routing model to connect these companies after the acquisition.

A VPC IPAM instance is created with a default public scope, and you can’t create additional ones. Public IPv4 and GUA IPv6 addresses are announced over the internet, and they can’t overlap. Therefore, there’s no need for multiple scopes. To segment your public IPv4 and IPv6 prefix allocation, you can manage hierarchical pools within a scope.

5. Amazon VPC IPAM and hybrid network design

To manage your hybrid network’s private IPv4 allocations, it’s recommended that you create custom IPAM allocations that can represent CIDRs present in your on-premises data centers. This makes sure that the CIDRs that are reserved for your non-AWS workloads aren’t accidentally assigned to any AWS resources, and avoids the risk of running into overlapping IP issues. The following figure shows an example where 172.16.16.0/20 represents on-premises CIDRs, and it’s reserved in the VPC IPAM Pool using a custom allocation.

Figure 7: An example of custom allocation, representing on-premises CIDRs

For public IPv4 and IPv6 centralized management of your hybrid network footprint, you can use the same custom allocation strategy within your IPAM’s public scope. Once the public CIDR provisioning is completed, you can create allocations to manually reserve space in your IPAM pool(s) to represent your internet facing hybrid networks. IPAM will manage the reservation and indicate if any CIDRs discovered in your AWS environment overlap with your on-premises IP space.

Things to know

• Amazon VPC IPAM can manage and monitor private IPv4 CIDRs and public IPv4/IPv6 CIDRs that you own. It can only monitor (not manage) Amazon owned public IP space.
• You can create a service control policy (SCP) in AWS Organizations that requires members in your organization to use IPAM when they create a VPC. Examples of SCPs can be found in the documentation.
• AWS Resource Access Manager (RAM) sharing is only available in the home AWS Region of your IPAM. You must create the share in the AWS Region that the IPAM is in, not in the Region of the IPAM pool. Details on using RAM to share VPC IPAM pools can be found in the documentation.

Conclusion

Amazon VPC IPAM provides you the tools needed to manage your global IP addressing footprint. In this post, we discussed the best practices for using VPC IPAM, and how you can utilize it to create scalable IP allocation plans, manage existing environments, overlapping IP space, and create a well-designed IP plan for your workloads’ growth on AWS. If you have questions about this post, then start a new thread on AWS re:Post , or contact AWS Support.

About the authors