2.5. Features

🔐 Security Groups Security Groups are virtual firewalls for your EC2 instances. They control inbound and outbound traffic based on defined rules.

Security Groups act as virtual firewalls that regulate the traffic coming in and out of your EC2 instances. They apply specific rules that determine what type of traffic can access your instances. For example, you can create rules to allow or block traffic based on IP addresses, protocols (like TCP), and port numbers.

Imagine your home as an EC2 instance. Your door (the Security Group) has a lock (the rules) that determines who can enter. You can choose to open the door to specific guests (approved IP addresses), while ensuring it remains locked to others.

🔧 Features: ● Stateful: Response traffic is automatically allowed. ● Applied to instances, not subnets. ● Allow only rules (no deny).

One of the key features of Security Groups is that they are stateful. This means that if you allow an incoming connection, the response traffic for that connection is allowed automatically, even if there's no explicit rule to allow it. Security Groups apply rules directly to individual EC2 instances instead of at the subnet level. Additionally, they only have 'allow' rules, meaning you can't set rules that explicitly deny traffic.

Think of statefulness like a conversation. Once you've allowed someone to start talking (incoming traffic), you don’t need to explicitly say they can respond (outgoing traffic) – it’s expected as part of a conversation.

🔢 Example Rule: ● Allow SSH (22): TCP, Port 22, Source: 203.0.113.0/24 ● Allow HTTP (80): TCP, Port 80, Source: 0.0.0.0/0

Here are examples of typical rules you might configure in a Security Group. The first rule allows SSH access (used for remote server management) from a specific range of IP addresses, while the second opens HTTP access (used for web traffic) to everyone. These rules help define who can interact with your instance and what protocols they can use.

These rules are like deciding who can visit your house and what they can do there. You might allow your family members (specific IPs) to come in and use the kitchen (SSH), but you also allow anyone to use the front door for deliveries (HTTP) as long as they follow the rules.

🛡 Network Access Control Lists (NACLs) NACLs offer stateless filtering at the subnet level, providing an additional layer of security.

Network Access Control Lists (NACLs) work alongside Security Groups but operate at the subnet level. NACLs provide an extra layer of security by applying rules that govern the traffic entering or leaving a whole subnet. Unlike Security Groups, NACLs are stateless, meaning you need to define rules for both incoming and outgoing traffic separately.

Think of NACLs as a security guard at the entrance of a neighborhood (the subnet) rather than at individual houses. The guard checks who can enter the neighborhood and who can leave, applying a set of rules for everyone, regardless of specific houses.

🔧 Features: ● Stateless: Rules must be defined for both directions. ● Supports both allow and deny rules. ● Evaluated in order based on rule numbers.

NACLs are stateless, so every rule must be explicitly defined for both incoming and outgoing directions. They can include both allow and deny rules, providing more flexibility compared to Security Groups. Additionally, NACLs process rules in the order they are listed by rule number, which means the first match is the one that is applied, regardless of any subsequent matches.

Imagine you receive mail (incoming traffic) and you also send mail (outgoing traffic). With NACLs, a letter needs to be addressed correctly to either be allowed in or out. If the rules are in a certain order, the first rule checked will determine whether the mail gets through, illustrating how rules are prioritized.

🔢 Example Rule: ● Inbound Rule #100: Deny TCP from 192.0.2.0/24 ● Inbound Rule #110: Allow all traffic from 0.0.0.0/0

This is an example of how rules can be set in a Network ACL. The first rule denies TCP traffic from a specific range of IPs, meaning that IPs within that range won’t be able to access any resource in the subnet. The second rule allows all traffic from everywhere, thereby creating an open access path, but it will be only applied if the deny rule doesn’t take precedence based on the order they are listed.

Consider these rules like a family policy. The rule is strict at home (Deny specific IPs), but there’s also a rule that allows guests in (Allow all traffic). However, if a guest has been banned (specific IPs), they won’t be allowed in no matter what.

✔ Best Practices: ● Layer Security: Use both Security Groups and NACLs. ● Least Privilege: Only allow necessary traffic. ● Audit Regularly: Remove stale or overly permissive rules.

To strengthen security, it’s recommended to use both Security Groups and NACLs together. This layered approach provides multiple lines of defense against potential threats. Additionally, following the principle of least privilege means only allowing the necessary traffic that is required for your applications to function. Regularly auditing your rules helps ensure that outdated or overly broad access permissions are revised or removed.

Think of your home security system (layered security) that involves both locks (Security Groups) and a guard who checks everyone entering the neighborhood (NACLs). You wouldn’t want to give everyone access to your house (least privilege), and it's essential to check and update your security measures regularly to stay safe.

--