Hello and welcome, Network Engineers!
In this blog post, I hope to explain the basic functionality of AWS's security groups, how they are applied in production, and draw some comparisons to networking features that we, as network engineers, already understand.
What are Security Groups (SGs) in AWS?
SGs are like a firewall or an ACL, if you may, that is applied directly to a networking interface. In AWS, these network interfaces are called "ENIs," therefore I'll refer to them by their proper naming convention going forward. SGs, like most network filtering constructs, allow you to define traffic allowed ingress or egress (there is an implicit deny for anything not explicitly granted an allow). They are also stateful, which means we are free from having to explicitly allow ephemeral (outbound) ports when a client initiates a conversation on a port we've allowed on the ingress. In simpler terms, this means that if we've allowed a client to initiate a conversation on port 443, the server can respond on an ephemeral port; we do not need to configure that functionality.
Where can we use SGs?
In AWS, there are many services that directly place an ENI in our VPC (Virtual Private Cloud). To name just a few services that you'll likely understand based on their naming convention:
- Amazon EC2 (Elastic Compute Cloud) Instances
- Amazon RDS (Relational Database Service) Instances
- Amazon Elastic Load Balancers (ELB)
- Amazon Elastic File System (EFS)
- Amazon EKS (Elastic Kubernetes Service)
There are many more, but these are just a few services that ultimately end up creating a network interface in a VPC that you, as a consumer, will directly interact with.
How do SGs work?
SGs are evaluated in a top-down manner, looking at the source, destination, and port to determine if an allow or a deny should occur. SGs operate like most rules-based traffic filtering mechanisms; there is little left to explain beyond this.
The only caveat to mention related to how SGs work because it's unique to them is that SGs can act as a source or destination for other SGs to reference. This cool feature means that you can do more "intent"-based traffic filtering and stop filtering solely based on IP. Take, for example, a fleet of EC2 (compute) instances acting as web servers, all using the same SG with a rule that allows ingress on port 443 (let's call the security group "webServerSecurityGroup-123"). Let's also say there is a group of database servers that should only ever allow the web servers to make SQL queries against them (let's call the database security group "databaseSecurityGroup-456"). Instead of creating unique SGs that have explicit IPs defined, we can simply refer to both in our source and destination declarations.
In the ASCII table below, notice the webserver security group allows inbound traffic on port 443. On the outbound, the only conversation that the web server can INITIATE is to the host with the database security group applied to it and only on port 3306. On the database security group, we only allow traffic from one source on port 3306, and that is from any host with the web server security group applied to it.
+--------------------------------------------------------------------------------------------+
| webServerSecurityGroup-123 |
|--------------------------------------------------------------------------------------------|
| Inbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Source |
|--------------------------------------------------------------------------------------------|
| 100 | HTTPS (443) | TCP | 443 | 0.0.0.0/0 |
|--------------------------------------------------------------------------------------------|
| Outbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Destination |
|--------------------------------------------------------------------------------------------|
| 100 | MySQL/Aurora | TCP | 3306 | databaseSecurityGroup-456 |
+--------------------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------------------+
| databaseSecurityGroup-456 |
|--------------------------------------------------------------------------------------------|
| Inbound Rules |
|--------------------------------------------------------------------------------------------|
| Rule # | Type | Protocol | Port Range | Source |
|--------------------------------------------------------------------------------------------|
| 100 | MySQL/Aurora | TCP | 3306 | webServerSecurityGroup-123 |
+--------------------------------------------------------------------------------------------+
Drawing comparisons between networking ACL's and SGs
As Network Engineers, more likely than not, you've dealt with ACL's. I'm going to draw some comparisons and point out where they differ because they do differ, however, I hope that if you still aren't clear how SGs work this will drive home the point.
As I stated earlier, SGs are applied to network interfaces; similarly, traditional ACL's can be applied to a physical or virtual interface to protect/filter traffic. In both instances, they are evaluated in a top-down approach, looking at each entry in the list looking for a matching source/destination/port and the action to take. One major difference is the stateful behavior of a traditional ACL vs. an SG, which is stateful by design.
If you're curious about how to further explore their functionality, please check out my GitHub repo for a few examples. You can pull the code down and deploy these examples in your environment to get hands-on with them.
https://github.com/friday963/networklabs/tree/main/security_groups
Top comments (0)