Simplify network routing and security administration with VPC Prefix Lists

The recently announced Amazon Virtual Private Cloud (VPC) Prefix Lists feature makes it easier to create consistent security postures and routing behaviors. A Prefix List is a collection of CIDR blocks that can be used to configure VPC security groups, VPC route tables, and AWS Transit Gateway route tables and can be shared with other AWS accounts using Resource Access Manager (RAM). As you scale your network, you can use Prefix Lists to simplify audits and administration of your security groups and route tables.

In this post, we’ll discuss a few ways that you can use Prefix Lists to simplify how you manage your environment using the example diagram depicted in Figure 1. Of note, AWS also maintains built-in Prefix Lists for Amazon S3 and Amazon DynamoDB that are primarily intended for use with VPC Gateway Endpoints, but this topic is out of scope and we won’t cover it here.

Figure 1: Example network diagram including a corporate office, two branch offices, a partner network, a production AWS account spanning two Regions connected via AWS Transit Gateway peering, and a management AWS account.

Make audits and administration easier

Security group rule consolidation

You can consolidate multiple security group rules with the same access policy into a single rule by using a Prefix List. This will make your audit simpler as you will be auditing a single item instead of multiple rules. In this first example, we’ll focus on just the Production account portion of the network diagram (Figure 2). In this scenario we have an intranet website hosted in VPC A which is accessed from VPC D, E, and F.  We have an existing security group with 6 rules that allow this traffic flow. We will optimize this security group permits HTTP and HTTPS connectivity to the three VPCs D, E, and F as shown in Figure 2 below.

Figure 2: The Production account section of the example network diagram with data flow from the us-east-1 VPCs to the us-east-2 intranet web servers in VPC A.

Figure 3: Screenshot of the “intranet web servers” security group with 6 rules permitting HTTP and HTTPS connectivity from the 3 VPC networks in us-east-1 prior to optimization through Prefix Lists

We can consolidate these rules by creating an IPv4 Prefix List in us‑east‑2, which we’ll name “us‑east‑1 vpc networks” and set a max entries value of 6 to accommodate for future growth as shown in Figure 4 below.

Figure 4: Screenshot of the “us‑east‑1 vpc networks” Prefix List created in us‑east‑2 with entries for the 3 VPC networks in us‑east‑1.

Important notes:

• Prefix Lists are regional objects, so create them in the Region where you intend to use them, which in this case is us‑east‑2.
• Each Prefix List can either contain IPv4 or IPv6 entries, but not both.
• Plan the scope of each Prefix List ahead of time, because when you create a Prefix List, you must specify the maximum number of entries that the Prefix List can support. You cannot modify the maximum number of entries later.
• Make the contents of your Prefix Lists to be intuitive so that they are reusable. For example, a list of web servers, public subnets, or as in this case, VPC networks in the us‑east‑1 Region.

We now use our new Prefix List to optimize our security group by consolidating 6 rules down to 2 (Figure 5).

Figure 5: Screenshot of the optimized “intranet web servers” security group, now with 2 rules permitting the same HTTP and HTTPS connectivity from the same 3 VPC networks in us-east-1 via Prefix Lists.

Our security group rules are now consolidated, and easier to read and manage. If a new VPC is provisioned in us‑east‑1 and you’re asked to permit similar connectivity for your intranet web servers, all you have to do is add an entry to the “us‑east‑1 vpc networks” Prefix List and the intranet web servers’ security group rules will be automatically updated (as well as any others that reference it).

This was a basic example, but can be easily expanded to accommodate more complex use cases. Imagine a scenario where you have a security group with 52 rules permitting HTTP and HTTPS connectivity from 6 VPC subnets and 20 individual client IP addresses. One way to approach this is to create one Prefix List for the subnets and one for the client IP addresses. If it wouldn’t make sense to reuse these groupings elsewhere, create one Prefix List for all of them. Either way, you consolidate the existing 52 rules down to 4 or 2 rules respectively, making this security group easier to audit and administer.

Simplified AWS Transit Gateway route tables for inter-region peering

AWS Transit Gateway supports inter‑region peering via static routing. This means that you add routes in the transit gateway route table for the remote Region’s VPC CIDR blocks with peering attachment as the next hop. This process is simplified by creating a Prefix List for the remote Region’s CIDR ranges and referencing the Prefix List in the route table. Any changes (addition or removal of CIDR blocks) to a Prefix List are automatically updated to the Transit Gateway route table. Prefix Lists are regional objects, therefore the Prefix List for a remote Region needs to be created and referenced in the local Region.

In the example diagram below, we have created a Prefix List in the us‑east‑2 Region named “pl‑us‑east‑1‑vpcs”, which contains the CIDR of the VPCs in the us‑east‑1 Region. We use this Prefix List in the TGW A route table with the peering attachment as the next hop. Similarly, a Prefix List is created in the us‑east‑1 Region to be used in the TGW B route table.

Figure 6: Diagram with Prefix Lists in respective Regions and utilized for AWS Transit Gateway peering.

This strategy helps you improve operational efficiency by committing changes centrally with confidence, knowing the change is consistent across all resources. It further simplifies the administration of CIDR ranges by having single place to update and manage network ranges.

Simplifying Edge VPC route tables

In a multi-VPC environment, customers often choose to centralize egress/ingress traffic via an edge VPC where all VPCs use one common VPC to access the Internet. In an edge VPC environment, the default route in the edge VPC route table points to the Internet Gateway (IGW) as the next hop, and more specific routes to other VPCs pointing to the Transit Gateway as the next hop. With the AWS Transit Gateway model, we recommend that spoke VPCs have a default route pointing to the Transit Gateway. But, the same does not hold good with edge VPC where the default route points to the IGW. Routes to other VPCs or other networks must be configured explicitly. Prefix Lists can simplify the edge VPC’s routing table which can be big and prone to misconfiguration on updates. The following image (Figure 7) shows a high‑level view of the Edge VPC with AWS Transit Gateway and spoke VPCs.

Figure 7: Example diagram showing Edge VPC with spoke VPCs without Prefix Lists.

The Edge VPC route table is simplified by creating a Prefix List, say pl‑edge‑vpc, containing CIDR ranges of VPCs, and other networks depending upon your architecture. The VPC route table uses the Prefix List as the destination with the transit gateway as the next hop. This greatly simplifies the VPC route table, and makes administering the network CIDR ranges of the Edge VPC (the one the traffic is meant for) easier by consolidating destination CIDR ranges in the Prefix List. If needed, the same Prefix List can be reused for configuring rules in the security group. The following example diagram (Figure 8) shows the Edge VPC route table with the Prefix List. This Prefix List contains VPC CIDRs for VPCs D, E, and F.

Figure 8: Diagram with Edge VPC Prefix List utilized for edge VPC route table.

When you need to update VPC route table with another network VPC CIDR block or any other network you can update the Prefix List and it gets applied automatically to edge VPC traffic.

Consistent network security postures

Homogeneity

All instances in a consistent network security posture that perform the same role, have identical access policies with minimal impact from human errors. Prefix Lists can help you achieve and maintain this. When you use a Prefix List with multiple CIDRs in a security group rule, each CIDR in the Prefix List has the same access to instances that use the security group. When you use a Prefix List in an AWS Transit Gateway route table, each destination in the Prefix List, has the same target next hop. Incorporating Prefix Lists into your network security policy can reduce the risk of incomplete and inconsistent connectivity changes and helps protect you from incidents and outages. For example, you do not need to update multiple rules in multiple security groups. You just update the Prefix List, ensuring the changes are applied to all security groups at once.

Error prevention

If a Prefix List ID that doesn’t exist in an account is entered into a security group rule, an error will be triggered, preventing configuration of improper connectivity, as shown in the following image, labeled Figure 9. This feature may not seem special, but it can help prevent you from spending hours troubleshooting connectivity issues. For example, tracking down a typo where someone entered a 25 instead of a 24 in the CIDR block’s prefix length in a security group rule. If the same user entered a ‘5’ instead of a ‘4’ in the Prefix List ID, the change won’t be permitted to be saved unless the Prefix List with the other ID also exists in the account, which is unlikely. Of course, the CIDR block still has to be entered correctly in the Prefix List, but you only have to do this once instead of multiple times consistently. Even if you use automation, such as configuration management tools or scripts, to ensure consistency across your network security policy, incorporating Prefix Lists will still help. You reduce risk and further improve operational efficiency because Prefix Lists are always consistent. They reduce the number of changes to your security group rules and static routes so there’s less risk of a change failing partway through, and your network security policy will be easier to read and manage.

Figure 9: Screenshot of what happens when attempting to add an invalid prefix ID to the “intranet web servers” security group, which has triggered an error and the change cannot be saved.

Centralized security posture across accounts

If you want to centralize certain aspects of your network security administration, such as for maintaining separation of duties, you can do so by sharing your Prefix Lists with external principals. These include AWS accounts, AWS Organizations, and/or organizational units (OUs) via AWS Resource Access Manager (RAM).

In this example, we’ll bring in the Management account, which has 3 bastion host instances provisioned in us-east-2, which is depicted in the image that follows, labeled Figure 10.

Figure 10: The Production and Management accounts, as well as the on-premises sections of the example network diagram. Data flows from the bastion hosts in the Management account to the instances secured with the “remote management” security group in VPCs A, B, and C in the Production Account.

If you want to centralize the network access management of the bastion host connectivity across accounts, you can create a new “bastion hosts” Prefix List in the Management account in us-east-2 with the 3 bastion host IP addresses, and then share it with the Production account via RAM. This is shown in the image that follows, labeled Figure 11.

Figure 11: Screenshot of a resource share in RAM, sharing the “bastion hosts” Prefix List from the Management account to the Production account (external account principal).

Once the resource share invitation has been sent and approved, create the security groups in us‑east‑2 in the Production account with rules that reference the “bastion hosts” Prefix List. In this case, we’ve created a security group named “remote management” in VPC A that permits SSH, RDP, and ICMP connectivity from the “bastion hosts” Prefix List. This is depicted in the following image, labeled Figure 12.

Figure 12: Screenshot of the “remote management” security group permitting connectivity from a set of bastion hosts defined in the administrative account.

Now the owners of the bastion hosts are able to update the connectivity to the resources in the production account without needing access to modify the corresponding security group rules in the production account. For example, if connectivity for one of the bastion hosts must be removed for whatever reason, all we have to do is remove the IP address entry in the Prefix List. This automatically updates all three security group rules in the “remote management” security group to no longer permit SSH, RDP, or ICMP connectivity to that bastion host’s IP address. Before doing so, we’ll review where this Prefix List is referenced first in the Associations tab shown in the following image, labeled Figure 13, to make sure that we fully understand the scope of the change first.

Figure 13: Screenshot of the Associations tab for the “bastion hosts” Prefix List, listing a reference in the “remote management” security group in the Production account.

Without Prefix Lists, the “remote management” security group required 9 rules to permit the same connectivity, and the desired change would have required removing 3 rules. Since we are using Prefix lists, this change was easy to plan using the Associations tab, which listed all of the resources where our Prefix List is referenced, and the desired change was executed with one simple update.

This is another basic example that could be expanded to accommodate more complex use cases. Imagine if these 3 bastion host IP addresses were referenced in thousands of security group rules across hundreds of security groups across multiple AWS accounts. With Prefix Lists, the desired change could be executed across all of these with the same single update.

Simplify network scaling

Growth in your environment, inside or outside AWS, is inevitable with evolving business or integration needs. When it happens, you want to scale in a simple and efficient manner in terms of security or routing needs. For example, you may start with isolated AWS environment and then have a need to connect or integrate with on-premises or non-AWS environments. The security or routing you setup should seamlessly scale with the addition of networks. Prefix Lists help you achieve those goals simply, and in a centralized manner.

Hybrid networking

So far, we’ve only discussed using Prefix Lists for AWS networking. When you want to reference external networks, such as your corporate office, branch office, on‑premises datacenter, or co‑location datacenter, you can do so with Prefix Lists, just like you can with AWS networks and IP addresses.

Let’s continue exploring our first example where we permitted connectivity from the three VPC networks in us‑east‑1 to the intranet web servers in VPC A. If you want to permit the same connectivity from your corporate and branch office networks to the same intranet web servers, one way to do so is to add these networks to the existing “us‑east‑1 vpc networks” Prefix List, as shown in the following image, labeled Figure 14.

Figure 14: Continuation of the example network diagram in Figure 2 with the corporate and branch offices, and data flow to the us-east-2 intranet web servers in VPC A.

If the corporate network and two branch office networks require similar connectivity, then it makes sense to use one Prefix List. For this example, the corporate office has different requirements than the two branch offices, so we’ll create two new Prefix Lists: “corporate networks” and “branch office networks”, and then reference them in the security groups to provide appropriate level of access. After that, any additional access to corporate or branch office networks is governed by a single update to the respective Prefix List.

Figure 15: Screenshot of the updated “intranet web servers” security group, now with 6 rules permitting HTTP and HTTPS connectivity from the VPC networks in us-east-1, as well as the corporate and branch office networks via Prefix Lists.

Let’s continue with our example of hybrid network growth and look at partner networks. Organizations often work with 3rd party vendors or partners for joint projects or business needs, and you may need to give them access to parts of your AWS environments. The level of access is usually different for partner networks than company owned networks. For example, your partner access may be scoped to specific ports, or IP addresses for certain applications, or environments, whereas company owned networks may have free open ping access to all your resources.

Figure 16: Continuation of the example network diagram with a partner network.

In an order to maintain access separation, a separate Prefix List is created for partner network CIDR blocks, say “My_Partner_Networks_PL” and access is granted based on that Prefix List. This makes it easier to roll out changes in the security groups. The following screenshot (Figure 17) shows a Prefix List with the partner’s network ranges included.

Figure 17: Screenshot of the partner networks Prefix List.

Conclusion

In this post, we covered how Amazon VPC Prefix Lists make reading and managing your security group rules and routes simpler, and discussed use cases where Prefix Lists help you simplify your network and security configuration. Prefix Lists are a great tool for simplifying your network and reducing operational overhead. To get started with Prefix Lists in your network, check out the links below.

Next steps to consider

• Create your first Prefix List in the AWS Console or via the AWS CLI
• Share your new Prefix List with another account via RAM
• Check out the documentation for more details on how to get started

Author bios