How-To
Strategies for Preventing EC2 Security Group Sprawl
Brien Posey shares best practices for keeping a handle on EC2 security groups -- essentially software firewalls -- to avoid confusion about which ones are actually needed.
As organizations create and remove EC2 virtual machine instances, they often find that they accumulate large numbers of security groups. In doing so, it can be difficult to figure out which security groups are currently in use, and which are no longer needed. As such, it is important to adopt a strategy to prevent your security groups from getting out of hand.
What Are Security Groups and Where Do They Come From?
For those who might not be familiar with EC2 security groups, a security group is essentially just a software firewall. When you create an EC2 virtual machine instance, AWS gives you the option of either creating a new security group or using an existing security group. The default option, which you can see in Figure 1, is to create a new security group.
[Click on image for larger view.]
Figure 1: When you create a new EC2 instance, AWS will create a new security group by default.
As you look at the figure above, you will notice that security group assignments happen in Step 6 of the instance creation process. Starting with Step 2, it is possible to click the Review and Launch button to complete the instance creation process using the default settings. The end result is that it is possible to end up with a separate security group for every virtual machine instance. While this isn't necessarily a problem, these security groups remain even after you have terminated the corresponding virtual machine instance. As such, you can end up with a large number of unused security groups mixed in with the security groups that you are still using.
Security Group Best Practices
There are several best practices that you can use to help keep your security group usage in check and to prevent security group sprawl. One of the more obvious (but important) best practices is to avoid creating security groups as a part of the virtual machine creation process. There are a number of reasons why I make this recommendation, and I will get into some of those reasons in a moment, but there is one main reason why I don't like creating security groups from within EC2.
If you look back at the previous figure, you will notice that when you create a security group through EC2, the console does not give you an option to apply tags to the security group that you are creating. You can specify the new security group's name and you can assign a description to the security group, but for whatever reason, Amazon chose not to expose tagging. Conversely, if you create a security group through the VPC console instead, you have the option of assigning tags to the security group. Tags are the single most effective tool for staying organized within AWS.
Another reason why I recommend creating security groups outside of EC2 is that doing so encourages security group reuse, which in turn helps to limit the number of security groups that are created. Remember, a security group is just a collection of firewall rules. In most cases, there is no need for every virtual machine instance to have its own unique collection of firewall rules. In most cases, organizations find that they are able to create a relatively modest collection of security groups, and use those security groups to service all of their virtual machine instances.
This raises the question of what types of security groups you should create. My advice is to create security groups based on the roles that your instances perform. For example, you will most likely need a general purpose security group for Windows instances and a general purpose security group for Linux instances. The security group for Windows instances will need to allow inbound RDP traffic (so that you can manage the instance remotely), while the security group for Linux instances will most likely need to allow inbound SSH traffic. Similarly, you might need to create a security group for Web server instances. Such a security group might allow management traffic (SSH or RDP) and HTTP (TCP Port 80) or HTTPS (TCP Port 443) traffic.
I mentioned earlier that when you create a security group you can assign a name and description. In my own organization, I use the Security Group Name option to reflect the instance role that the security group is intended to service (Web server, mail server, etc.). Similarly, I use the Description field to create a summary of what the rule does.
Some organizations inevitably require more security groups than others. While there is nothing wrong with creating a lot of security groups if you need them, it is best to avoid creating security groups unnecessarily. Otherwise, you could end up in a situation in which it becomes difficult to determine which security groups are actually needed.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.