VPCs, Subnets, Routing Tables, NACLS and Security Groups are important tools to secure your network infrastructure in AWS. But how exactly are Security Groups involved in this picture? In this article, we explore the what security groups are and how they work. Keep in mind this article is not meant to exhaustively discuss the details of security groups, but serves as a simple primer.
Security Groups, Explained Simply
You can think of a security group as a virtual firewall that allows you to control all inbound and outbound traffic to a particular entity. I specifically use the word entity here because security groups not only standard EC2 machines, but other things like load balancers, databases in RDS, and Docker based services hosted in ECS (Elastic Container Service). There are many more but this gives you the idea.
Security groups gets associated with network interfaces and changes are reflected immediately when you change the configuration. This is handy for quickly denying ingress traffic from potentially bad actors. Keep in mind though that with security groups, you do not have the ability to restrict traffic by specific IP addresses – this is a task much better suited to NACLs (to be discussed in another article).
A variety of different entities can all belong to the same security group, and in it, you can define Rules that specify the inbound and outbround traffic that can flow to any entity or instance that belongs to the security group.
For example, here’s an image of a custom security group I’ve created with a rule that allows for inbound traffic on port 80 (HTTP).
In this screenshot, we can see that we select HTTP as the type, with a protocol of TCP. We’re stating that the port we would like to allow traffic for is port 80, and that this traffic can originate from any IPv4 based instance over the internet.
Many other types of protocols are also supported, as seen in the following image seen during the ‘Create Rule’ process.
One thing to note is that when you add an inbound rule, you by default allow for outbound traffic, and vice versa. This means that security groups form bi-directional communication channels once a request is established. To restrict bi-directional communication, you would use NACLs (Network Access Control Lists) to restrict traffic further.
Its important to realize that Security Groups work off a pessimistic principle. What I mean by that is that they by default DENY all traffic unless a Rule exists that explicitly allows it. This is why using a security group is such an attractive option for developers; it forces them to explicitly define who what ports/protocols/sources are allowed to communicate, instead of the opposite.
One limitation of security groups is that they can only be applied to one VPC at a time, so pick your members wisely.
So why are Security Groups Important?
The thing with security groups is that by playing with ‘Source’ ips and port/protocols, it becomes much easier to lock down your instances in a predictable way. While Route Tables define the overall rules of traffic flow throughout your VPC, Security groups lock down your entities even further by allowing you to define explicit protocols to and from your resources.
Security Groups are part of the Security Layering strategy employed by AWS. There are many layers of security that as a sum, allow folks to introduce an element of redundancy that act to thwart attackers.
If you’re interested in learning more about security groups, I highly suggest you take at the this link from the AWS Developer Guide on Security Groups.