AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type

Combining security groups and NACLs to work around AWS capacity limitations


On Tuesday I blogged about advanced traffic filtering within Amazon Web Services (AWS) environments, and how it’s possible to use a combination of security groups and Network Access Control Lists (NACLs) to precisely control the traffic that is allowed – and denied – across your AWS infrastructure.  As we learned, the NACL is associated with a subnet. Each subnet can have multiple instances associated with it, and each instance can inherit rules from multiple security groups.

But while AWS security is very flexible and granular there are some limitations contained in the ‘small print’: The number of rules you can have in a single NACL is at most 20; the number of rules in a security group is at most 50; and the number of security groups that can be associated with a single instance is at most five.

So for a single instance, this gives a grand total of at most 270 rules (that is, 5 security groups, multiplied by 50 rules per group, plus 20 rules from the NACL) for both inbound and outbound traffic.

This is not a huge number. When you consider that a traditional firewall might contain several thousand security rules, especially if it has been in use for years, it might seem that securing an AWS environment is harder than you may have originally thought.

As such, if you’re going to use AWS for a large, heterogeneous estate, you need to carefully plan out how to utilise the various functionalities of security groups and NACLs so that you can bypass, where possible, those limitations.  Here’s how you can do that.

One useful tip here is to remember the differences between security groups and NACLs, which we explored in my previous blog.  The key difference is that while security groups only allow traffic, NACLs can also deny it.  You can, therefore, decide which types of filtering you want to perform with NACLs, and which types you want to manage with security groups.

Clearly,any traffic that you want to deny outright must be filtered through a NACL, whereas when it comes to traffic that you want to allow, you have a choice.  One option might be to have your NACLs do all your IP-based filtering, using sets of subnets that you want to allow and deny traffic from.  The NACLs, however you would configure them to implement port-based filtering; this instead should be done by the security groups. You can also utilize the fact that an instance can have rules from multiple security groups – so place rules affecting many instances in security groups that are associated broadly (say by operating system or by geography), and then have specialized security group per business function.

There are of course myriad different options as to how you actually arrange your NACLs and security groups – and indeed, this flexibility is one of the key benefits of AWS.  However, the crucial point is to start thinking about security and filtering policies in AWS’s security terms early on while your AWS environment is still relatively compact and simple.  This way, you will not be restricted as your AWS deployment grows to support your enterprise deployments.

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

Subscribe to Blog

Receive notifications of new posts by email.