Prefix Lists for Common Third Party Services

Constructing prefix lists for common third party services within EC2

Table Of Contents

Today I Explained

When developing a service within Amazon Web Services (AWS), it isn’t always intended to be consumed by any machine in the world wide web. It may only be responsible for communicating with a single third party service, or an internal service hosted in a different part of the company’s cloud. For these kind of services, they often have a declared set of CIDR ranges (IPs) that you can expect to receive & interact with for network traffic.

Some of the more common examples are:

• GitHub
• GitLab
• AWS VPCs & Transit Gateways
• Azure
• Office365

Sometimes this can even be from Virtual Private Network (VPN) services, or organizationally owned machines, like self-hosted machines in the office. For these cases, it can be very beneficial to declare a set of managed lists that contains all of these IP ranges, allowing for limiting potential network traffic.

For these cases, one of the approaches adopted is the implementation of a dedicated networking AWS Account, and making use of AWS Resource Share Manager (RAM) to share them into other AWS Accounts in the organization.

These lists, known as EC2 Prefix Lists, are specific to a single AWS Region but have a limited management overhead. This makes it viable to provision them ahead of time in as many AWS Regions as appropriate, using the networking account which is outside the standard workloads.

     ┌─────────┬───────OU Root────────┬────────────┐
     │         │          │           │            │
     ▼         ▼          ▼           ▼            ▼
 Networking  Audit   Workloads   Infrastructure   ...
[.., .., ..]

One of the challenges with anything IPs, is that the set provided by third parties (or even within the organization) is subject to change. When these IP lists change, it can mean that the prefix list can increase in the total number of ip allow rules are in place.

For smaller sets, this can be fine, but as the list becomes larger, it becomes necessary to take into consideration that AWS EC2 Security Groups have constraints on the number rules per security group, which cannot exceed ~300 rules per security group.

This is a hard limit, as exceeding this limits has the potential to negatively impact performance of the underlying load balancing mechanisms within AWS.