Security group architecture for AWS: How to overcome security group limits

As with all cloud vendors, AWS users share responsibility for securing their infrastructure against risk. Amazon provides the tools you need to filter traffic, but configuring those tools is up to you.

Firewalls are one of the tools you’ll use to filter traffic and secure Virtual Private Cloud (VPC) instances. Instead of using traditional firewalls, Amazon provides users with AWS security groups, which are flexible, stateful firewalls capable of filtering inbound and outbound traffic.

However, there are limits to what you can do with AWS security groups. First, they only allow traffic – you can’t configure them to deny traffic. Second, the maximum number of rules you can set for a single group is 60.

This isn’t a big issue for an Amazon EC2 instance designed to address inbound traffic. You’ll either want your AWS EC2 to accept ingress from the entire internet or you’ll want to configure access for a few internal IP addresses.

But for outbound traffic, 60 rules simply isn’t enough. You’ll use a dozen of them just allowing access to GitHub’s API. Add in a few third-party partners and you’re already well past the limit.

Amazon VPC resource limits explained

Amazon sets clear limits on the AWS services and resources it makes available to users. In some cases, you can increase these limits by contacting AWS support. These limits are generally assessed on a per-Region basis.

Here are some of the limits Amazon places on AWS users:

Security group limits

• 2500 VPC security groups per Region
• 60 IPv4 rules per security group
• 60 IPv6 rules per security group
• 5 security groups per network interface

VPC and subnet limits

• 5 VPCs per Region
• 200 Subnets per VPC
• 5 IPv4 CIDR blocks per VPC
• 5 IPv6 CIDR blocks per VPC

Limits to elastic IP addresses and gateways

• 5 Elastic IP addresses per Region
• 2 Elastic IP Addresses per public NAT gateway
• 5 Egress-only internet gateways per Region
• 5 NAT gateways per Availability Zone
• One carrier gateway per VPC

Prefix list limits

• 100 prefix lists per Region
• 1000 versions per prefix list
• 5000 prefix list references per resource type

Network ACL limits

• 200 Network ACLs per VPC
• 20 Rules per Network ACL

How to manage AWS cloud security group limits effectively

Traditional firewalls may have thousands of security rules, including a complex combination of inbound rules and egress filters. Crucially, they can also enforce outbound rules that include denying traffic – something Amazon does not allow regular security groups to do.

While AWS offers powerful tools for securing cloud workflows, Amazon VPC users must find ways to overcome these limitations.

Fortunately, there are a few things you can do to achieve exactly that.

• Optimize your VPC security groups.

• Use Network Access Control Lists to secure assets at the subnet level.
• Use a domain name filtering system that reduces the number of IP addresses security group rules need to resolve.

Optimize your Amazon virtual private cloud configuration

Amazon VPC is a virtual network that contains many of the elements you’d expect from a traditional network. It has IP addresses, route tables, subnets, and internet gateways.

Unlike a traditional network, you can easily configure many of your VPC environment through a command line interface (CLI). You can establish VPC peering connections, implement identity and access management (IAM) protocols, and configure elastic network interfaces without manually handling any hardware.

But first, you need to set up and protect your VPC by setting up and configuring security groups. If you don’t specify a particular group, Amazon EC2 will use the default security group.

If you haven’t added new security groups since creating your AWS account, you may only have that one default security group. The first step to optimizing security is expanding the number of security groups you have available.

Here’s an example of the code you can use to create a new security group in the AWS console:

aws ec2 create-security-group –group-name web-pci-sg –description “allow SSL traffic” –vpc-id vpc-555666777

This creates a new group named web-pci-sg and describes it as a group designed to allow SSL traffic on the network. Remember that security groups don’t support deny rules.

Here is the code you would use to add a rule to that group:

aws ec2 authorize-security-group-ingress \ –group-name web-pci-sg \ –protocol https \–port 443 \ –cidr <IP Subnet/Netmask>

This rule specifically allows SSL traffic using the HTTPS protocol to use port 443, which is the standard port for HTTPS traffic. You can use the last argument to specify the cidr block the rule will direct traffic through. This gives you the ability to manage traffic through specific subnets, which is important for the next step.

This example focuses on just one type of rule in one context. To take full advantage of the security tools AWS makes available, you’ll want to create custom rules for endpoints, load balancers, nat gateways, and more. Although you’re limited to 60 rules per security group, creating many groups lets you assign hundreds of rules to any particular instance.

Security architecture and network ACLs

Network Access Control Lists provide AWS users with additional filtering capabilities. Network ACLs are similar to security groups in many ways, but come with a few key differences:

• Network ACLs can contain deny rules. You can write Network ACL rules to include explicit actions, like blocking particular IP addresses or routing VPN users in a specific way.
• Network ACLs are enforced at the subnet level. This means they apply to every instance in the subnet, in addition to whatever rules exist at the security group level.

As mentioned above, each Network ACL can contain up to 20 rules. However, you can have up to 200 Network ACLs per VPC, which gives you a total of 4000 potential rules. Along with instance-specific security group rules, this offers much more flexibility for setting up robust AWS security architecture.

Since Network ACLs can deny traffic, they are a useful tool for managing access to databases and other sensitive assets. For example, you may wish to exclude users who don’t have the appropriate permissions from your Amazon RDS instance. You may also want to filter SSH (Secure Shell) connections coming from unknown sources, or limit connections between different internal instance types.

To do this effectively, you need to group these assets under the same subnet and make sure that the appropriate rules are enabled for all of them. You can also write asset-specific rules at the security group level, ensuring every asset has its own optimal configuration.

The larger your AWS environment is, the more complex this process may become. Take care to avoid misconfigurations – it’s very easy to accidentally write security group rules and Network ACL rules that aren’t compatible, or that cause problems when you access the instance. To avoid this, try to condense your rules as much as possible.

Avoid limits by filtering domain names directly

Although you can create a large number of rules by creating additional security groups, you still may want to add more than 60 rules in a single group. There are many scenarios where this makes more sense than arbitrarily adding (and managing) new groups.

For example, you might have a production instance that needs updates from several third-party partners. You also need to periodically change and update the technologies this instance relies on, so you’d like to keep its rules in a single security group. This reduces misconfiguration risk by keeping all the relevant rules in one place – not spread out across multiple groups.

To overcome this limit, you need to reduce the number of IP addresses that the security group filters. You can do this by deploying a third-party solution that allows security rules to perform DNS resolution. This eliminates the need for AWS to resolve the domain name.

Since AWS security groups can’t compute domain names on their own, you’ll need to deploy a third-party NAT gateway on your public VPC to filter outbound traffic in this way.

Once you do this, you can write rules that filter outgoing connections based on their domain name. This effectively bypasses the 60 IP limit because you are not referring to specific IP addresses.

At the same time, it simplifies management and makes rules much easier to read and understand. Instead of looking up and adding all of Github’s API IP addresses, you can write rules that reference the domain “Github.com”. If Github decides to change its IP infrastructure, your security rules will automatically reference the new addresses – you won’t have to go back and update them.

The earlier you address AWS security group limits, the better

There is an unlimited number of ways you can arrange your security groups and Network ACLs. Even in a small environment, the prospect may seem daunting. However, the flexibility Amazon provides to its cloud users is a valuable security feature. Those who go the process enjoy clear security performance benefits.

If you start to planning for the architecture of your security and filtering policies early, you’ll be better equipped to scale those policies upwards as your organization grows. This will prevent security processes from becoming a growth bottleneck and maintain a high level of efficiency even as those policies become larger and more complex.

See me explain this issue in person in my new whiteboard video: