Please use the menu below to navigate the article sections:
In the world of Cloud Computing, Security is always job zero. This means that we design everything with Security in mind – at every single layer of our application! While you may have heard about AWS Security Groups – have you ever stopped to think about what a security group is, and what it actually does?
If for example, you are launching a Web Server to launch a brand new website hosted on AWS, you will have to prevent and allow certain protocols to initiate communication with your Web Server in order for users to interact with your website. On the other hand, if you give everyone access to your server using any protocol you may be leaving sensitive information easily reachable from anyone else on the internet, ruining your security posture.
The balance of allowing this kind of access is done using a specific technology in AWS, and today we are going to explore how Security Groups work, and what problems they help you solve.
What is a Security Group?
Security groups control traffic reaching and leaving the resources they are associated with according to the security group rules set by each group. After you associate a security group with an EC2 instance, it controls the instance’s inbound and outbound traffic.
Although VPCs come with a default security group when you create them, additional security groups can be created for any VPC within your account.
Security groups can only be associated with resources in the VPC for which they were created, and do not apply to resources in different VPCs.
Each security group has rules for controlling traffic based on protocols and ports. There are separate rules for inbound and outbound traffic.
Let’s have a look at what a security group looks like.
As stated earlier, Security Groups control inbound and outbound traffic in relation to resources placed in these security groups. Below are some example rules that you would see routinely when interacting with security groups for a Web Server.
|0.0.0.0/0||TCP||80||Allows inbound HTTP access from all IPv4 addresses|
|::/0||TCP||80||Allows inbound HTTP access from all IPv6 addresses|
|0.0.0.0/0||TCP||443||Allows inbound HTTPS access from all IPv4 addresses|
|::/0||TCP||443||Allows inbound HTTPS access from all IPv6 addresses|
|Your network’s public IPv4 address range||TCP||22||Allows inbound SSH access from IPv4 IP addresses in your network|
|Your network’s public IPv4 address range||TCP||3389||Allows inbound RDP access from IPv4 IP addresses in your network|
|The ID of the security group for your Microsoft SQL Server database servers||TCP||1433||Allow outbound Microsoft SQL Server access|
|The ID of the security group for your MySQL database servers||TCP||3306||Allow outbound MySQL access|
Security Groups can also be used for the Relational Database Service, and for Amazon Elasticache to control traffic in a similar way.
Security Group Quotas
There is a limit of Security Groups you can have within a Region, and a limit on the number of outbound and inbound rules you can have per security group.
For the number of Security Groups within a Region, you can have 2500 Security Groups per Region by default. This quota applies to individual AWS account VPCs and shared VPCs, and is adjustable through launching a support ticket with AWS Support.
Regarding the number of inbound and outbound rules per Security Group, you can have 60 inbound and 60 outbound rules per security group (making a total of 120 rules). An IPv4 quota is enforced separately from IPv6 quotas. For example, an IPv4 quota can have 60 inbound rules, while an IPv6 quota can have 60 inbound rules.
Both inbound and outbound rules can be changed with a quota change. Per network interface, this quota multiplied by the quota for security groups cannot exceed 1,000.
Best Practices with Security Groups
When we are inevitably using Security Groups as part of our infrastructure, we can use some best practices to ensure that we are aligning ourselves with the highest security standards possible.
- Ensure your Security Groups do not have a large range of ports open
When large port ranges are open, instances are vulnerable to unwanted attacks. Furthermore, they make it very difficult to trace vulnerabilities. Web servers may only require 80 and 443 ports to be open, and not any more.
- Create new security groups and restrict traffic appropriately
If you are using the default AWS Security group for your active resources you are going to unnecessarily open up your instances and your applications and cause a lessened security posture.
- Where possible, restrict access to required IP address(es) and by port, even internally within your organization
If you are allowing all access (0.0.0.0/0 or ::/0) to your resources, you are asking for trouble. Where possible, you can actually restrict access to your resources based on an individual IP address or range of addresses. This would prevent any bad actors accessing your instances and lessen your security posture.
- Chain Security Groups together
When Chaining Security Groups, the inbound and outbound rules are set up in a way that traffic can only flow from the top tier to the bottom tier and back up again. The security groups act as firewalls to prevent a security breach in one tier to automatically provide subnet-wide access of all resources to the compromised client.
Become an AWS expert with our value-packed training
AWS Training – Our popular AWS training will maximize your chances of passing your AWS certification the first time.
Membership – For unlimited access to our entire cloud training catalog, enroll in our monthly or annual membership program.
Challenge Labs – Build hands-on cloud skills in a secure sandbox environment. Learn, build, test and fail forward without risking unexpected cloud bills.