AWS Security Group – five basic rules

AWS Security Groups are instance level virtual firewalls. It enables flexible and logical security segmentation well suited for protecting apps in the cloud. While its basic concept is easy to understand, certain specifics can be confusing in practice, and I summarize the top five principles worth revisiting.

1.       Security Group rules aggregate

Security Group can have multiple rules, an instance can also have multiple Security Groups. What happens when multiple rules from one or more SGs are applied to the instance?

If rules have the same egress (towards the same target), ingress are effectively aggregated. If multiple rules are written to the same target, then the most permissive principle is applied. For example, if you have a rule that allows access to TCP port 80 from a subnet and another rule that allows access to TCP port 80 from everywhere, then everyone has access to TCP port 80.

2.       Rules to different targets don't mix

However, rules towards different targets never mix. For example, if an ingress rule allows everyone (0.0.0.0/0) to access ssh; another ingress rule allows from IP 10.1.1.1 to access everything (All Traffic), since the rules are towards different targets, they remain independent of each other. In other words, ingress don't mix if target of rules are different. It is basic but can get confusing when applying complex SGs.

3.       Intra-SG communication not allowed by default (except in default SG)

Initially, you may notice instances can already communicate with each other without you doing anything. Later when you add SGs, it may no longer be the case. When you define a SG and place instances in it. By default, they can't talk to each other unless you add rules allowing it.

The exception is default SG, which all instances are placed into unless specified. By design, instances in default SG can talk to each other without explicit allow. If you look at the system generated default SG, it already specifies itself as a source SG in its inbound rules. This is what allows instances associated with the default SG to communicate with other instances associated with the default SG.

4.       Security Group allows outbound by default

The following are the initial settings for a security group that you create:

• Allows no inbound traffic
• Allows all outbound traffic

5.       No need to allow “return” traffic

So you have given your instance outbound access, have you wondered how the return traffic get through even you haven’t defined ingress rules for it? SGs are stateful — responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa.