Phase 2: Core Cloud Services

Security groups, NACLs & flow logs

Intermediate ~4 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building a super cool school filled with lots of special club rooms. Each room has a computer for different activities, like a coding club, an art club, or a science lab. To keep everything safe and organized, you need rules about who can go where. That's where "security groups," "NACLs," and "flow logs" come in – they're like your school's security team!

First, think about a "Security Group" like a friendly security guard, let's call her Ms. Guard, who stands right at the door of each individual club room. You tell Ms. Guard your rules, like "only members of the Coding Club can enter this room." If someone isn't on the list, she gently stops them. The cool thing about Ms. Guard is that she's super smart: if a Coding Club member comes into your room to ask a question, and you give them an answer, Ms. Guard automatically knows that answer is allowed to leave the room and go back to the club member. She remembers the conversation, so you don't need a separate rule for replies! This makes it easy to protect each computer specifically.

Now, imagine an "NACL" (which stands for Network Access Control List) as a stricter monitor, Mr. Monitor, who stands at the entrance to an entire hallway section of the school. This hallway might have many club rooms inside it. Mr. Monitor is different because he checks everyone trying to enter or leave that whole hallway section. He needs separate rules for "who can come into this hallway" AND "who can leave this hallway." He's not as smart as Ms. Guard; if a student leaves the hallway and then tries to come back in, he checks them all over again, even if they were just inside. He doesn't remember past conversations, so you have to be very clear about all the comings and goings for all the rooms in that whole hallway section.

Finally, to make sure your security guards and monitors are doing their job, you have "Flow Logs." These are like tiny security cameras that record every time someone tries to enter a club room or a hallway, and whether Ms. Guard or Mr. Monitor said yes or no. If a friend tells you they couldn't get into your coding club room, you can check the camera footage (the flow logs) to see exactly why they were stopped. This helps you figure out if your rules are working correctly or if you need to change something. So, when you're setting up your cloud "clubhouses" and hallways, you use these different types of guards and cameras to make sure everything is super safe and only the right people (or data!) can go where they're supposed to.

In VPC design, Security Groups (SGs) and Network Access Control Lists (NACLs) are your primary tools for network access control, complemented by VPC Flow Logs for visibility. Security Groups act as stateful virtual firewalls that control traffic at the instance level. They operate purely on allow rules; if traffic doesn't explicitly match an allow rule, it's implicitly denied. Being stateful, SGs automatically permit return traffic for any established connection originating from the instance. For example, if you allow inbound HTTP on port 80 to a web server, the SG automatically allows the web server's outbound HTTP responses back to the client. This makes SGs flexible for granular instance-level protection, often allowing all outbound traffic by default and restricting inbound access.

NACLs, on the other hand, are stateless virtual firewalls that operate at the subnet level. This means they apply to all instances within a specific subnet. Unlike SGs, NACLs require explicit rules for both inbound and outbound traffic, including return traffic. For instance, if you allow inbound HTTP on port 80, you must also explicitly allow outbound ephemeral ports (1024-65535) for the web server's responses. NACL rules are numbered and processed in order, with an implicit deny rule at the end, meaning any traffic not matched by a preceding allow or deny rule will be blocked. NACLs provide an additional, broader layer of security for entire subnets, typically used for coarse-grained control or as a safety net before traffic even reaches an instance's Security Group.

VPC Flow Logs capture detailed information about IP traffic going to and from network interfaces in your VPC. They record metadata like source/destination IP addresses, ports, protocols, the action taken (ACCEPT or REJECT), and the number of bytes and packets. These logs can be published to Amazon CloudWatch Logs or Amazon S3, providing invaluable data for troubleshooting connectivity issues, identifying unauthorized access attempts, monitoring network performance, and performing security audits. By analyzing flow logs, you can understand exactly which traffic was allowed or blocked by your SGs and NACLs, helping you refine your network access policies and diagnose complex network problems within your VPC.

Key Takeaways

  • Security Groups (SGs) are stateful, instance-level firewalls that only use allow rules.
  • Network Access Control Lists (NACLs) are stateless, subnet-level firewalls that process numbered allow/deny rules.
  • SGs implicitly allow return traffic; NACLs require explicit rules for both inbound and outbound (including return traffic).
  • VPC Flow Logs provide critical visibility into network traffic, aiding in troubleshooting, monitoring, and security auditing.
  • Implement both SGs and NACLs for a layered defense-in-depth security approach in your VPC.

Code Example

bash
# Create a Security Group for web servers in your VPC
aws ec2 create-security-group \
    --group-name WebServerSG \
    --description "Allow HTTP/S & SSH to web servers" \
    --vpc-id vpc-0123456789abcdef0

# NOTE: Replace 'sg-0abcdef1234567890' with the actual Security Group ID from the previous command's output
SG_ID=sg-0abcdef1234567890

# Allow inbound HTTP (port 80) from anywhere
aws ec2 authorize-security-group-ingress \
    --group-id $SG_ID \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0 \
    --description "Allow HTTP from the internet"

# Allow inbound HTTPS (port 443) from anywhere
aws ec2 authorize-security-group-ingress \
    --group-id $SG_ID \
    --protocol tcp \
    --port 443 \
    --cidr 0.0.0.0/0 \
    --description "Allow HTTPS from the internet"

# Allow inbound SSH (port 22) from a specific admin IP address
aws ec2 authorize-security-group-ingress \
    --group-id $SG_ID \
    --protocol tcp \
    --port 22 \
    --cidr 203.0.113.10/32 \
    --description "Allow SSH from admin workstation"

How this code works

This script automates the creation and configuration of an AWS Security Group, a crucial virtual firewall that controls inbound and outbound traffic for instances like web servers. It ensures that only necessary traffic can reach the servers, enhancing security within a VPC. The initial aws ec2 create-security-group command establishes the firewall, giving it a name (WebServerSG) and associating it with a specific vpc-id. This sets up the basic container for the network rules.

After creation, the script uses aws ec2 authorize-security-group-ingress multiple times to add specific inbound rules. It opens port 80 (HTTP) and port 443 (HTTPS) to 0.0.0.0/0, meaning traffic from any IP address can reach the web servers on these ports. A more restrictive rule is applied for port 22 (SSH), limiting access to a single administrative IP address (203.0.113.10/32). A subtle but critical point is that Security Groups, by default, allow all outbound traffic. This script only configures inbound rules, so servers within this group can still initiate connections to the internet or other resources without explicit outbound rules. Remember to replace the placeholder SG_ID with the actual ID returned by the create-security-group command.

Related Articles

Hand-picked reads to go deeper on vpc design & network architecture.

Back to Cloud Architect Roadmap