From the course: AWS: Networking

Understanding security groups - Amazon Web Services (AWS) Tutorial

From the course: AWS: Networking

Understanding security groups

- [Instructor] Security groups are the tool within AWS that lets you control inbound and outbound network traffic to the assets you have in AWS. Think of a security group as a virtual firewall. There are some key differences to understand about how security groups work when compared to firewalls you may have configured in the past. Let's explore some of the particulars about security groups. First off security groups are applied at the AWS component level. For example, access to AWS components including EC2 instances, Elastic Load Balancers and Relational Database Services are all controlled with security groups. Security groups are assigned to AWS components individually. For example, you may have five different EC2 instances running in a given sub-net. It's possible to configure each individual EC2 instance with its own security group. With any firewall, the more rules it has to process the greater the impact on performance. For this reason, AWS starts with default which can be adjusted upwards. Let's explore some of those defaults now. Each network interface has a default of five security groups. Each security group has a default of 60 inbound or outbound rules. This means that a single security group can have a total of 120 rules, 60 inbound and 60 outbound. Note that the number of security groups per network interface, as well as the number of rules assigned to a given security group are calculated independently for IPv4 and IPv6. By default, a VPC is limited to 2,500 security groups. Note that it is possible to adjust all of the above limits upwards by opening a support ticket with AWS. Talking about security group limits can be a bit abstract, so let's draw a picture to see what this looks like. For illustrative purposes, let's talk about a single EC2 instance. Any given network interface, be it for an EC2 or RDS instance has a default maximum of five security groups assigned to it. Each individual security group can contain up to 60 inbound rules. Additionally, each security group can have 60 outbound rules. Finally, each VPC has a default maximum of 2,500 security groups. You can imagine how complicated these rule sets can get. Unless you have a compelling need, it's best to keep things as simple as possible. Design and define security groups broadly enough so that you don't have to manage hundreds or thousands of them per VPC. It's important to understand how security groups behave. When a security group is created it abides by the principle of least privilege for inbound connections. When you create a security group, all inbound traffic on all ports is denied by default. In fact, you can only configure allow rules within a security group. Unless you explicitly create a rule allowing traffic of a specific type from a specific source, inbound traffic will be dropped. Conversely, all outbound traffic for a given security group is allowed by default. This means that an instance in a public sub-net can establish a connection to the internet even if no traffic can get to it. Similarly, an instance in a private sub-net would be able to reach the internet using whatever net implementation you've configured in a public sub-net. It is also important to understand that security groups are stateful. Responses to any outbound connection will always be allowed regardless of any rules limiting inbound traffic. For instance, suppose you had a server that needed to reach out to the internet to get data from a web service. You could attach a security group that allows no inbound traffic to the instance and it would still be able to retrieve data. Suppose you attach the same security group to a pair of EC2 instances that are being used as web servers. You've defined a rule that allows inbound traffic on port 443 and 80, all as well. Now suppose those EC2 instances need to communicate with each other. While a route for that traffic exists in the route table, the security group will drop that traffic by default. It's a little strange to get your head around, but it does make sense. Let's walk through it. In order to let that traffic flow, think from the perspective of the instance. Inbound traffic is originating from the security group. Unless that traffic is explicitly allowed, it will be dropped. Just like in any on premises work you may have done, the firewall has to allow the traffic, even if the network path exists. Once you add a new rule to the security group which allows traffic from the security group itself, the instances will be able to communicate with each other. That said there is an exception. The VPC is default security group has an inbound rule allowing traffic from the default security group.

Contents