Mastering AWS Security Groups for the AWS SAA exam

AWS Security Groups are virtual firewalls that control inbound and outbound traffic to resources within your Amazon Virtual Private Cloud (VPC). They act as a first line of defense, allowing or denying traffic based on specified rules. When you launch an EC2 instance or configure other AWS services, you associate them with one or more security groups, effectively setting the rules for what type of traffic can interact with those resources.

In the AWS Certified Solutions Architect – Associate (SAA) exam, understanding Security Groups is critical as you'll find them mentioned in questions related to network security, EC2 instance management, and overall VPC configuration.

Why Are They Important?

1. They define what traffic is allowed to and from resources, ensuring only authorized users and systems can interact with your applications.
2. Security Groups help reduce the attack surface by blocking unauthorized traffic at the network level.
3. They streamline the management of network security policies with reusable rules and flexible association options

For the SAA exam, expect scenarios where you’ll need to decide between Security Groups and other mechanisms like Network ACLs, and justify why Security Groups are better suited for certain use cases.

Overview of Security Groups

Default Security Group vs. Custom Security Groups

• When a VPC is created, a default security group is automatically created. This group allows all inbound traffic from resources within the same group and allows all outbound traffic by default.
• Custom security groups are user-defined and tailored to specific needs, such as restricting access to certain IPs or ports.

Stateful Nature of Security Groups

• Security Groups are stateful, meaning that if an inbound rule allows traffic, the return traffic is automatically allowed without explicitly specifying an outbound rule.
• For example, if you allow inbound traffic on port 22 (SSH), the outbound response to that traffic is automatically permitted.

The stateful nature of Security Groups is an important differentiator with Network ACLs, which are stateless and require explicit rules for both inbound and outbound traffic.

Comparison with Network ACLs

• Security Groups
  • Applied at the instance level.
  • Stateful.
  • Rules are "allow" only.
• Network ACLs
  • Applied at the subnet level.
  • Stateless.
  • Rules can be "allow" or "deny."

Components

Rules (Inbound and Outbound)

• Inbound rules specify what traffic can enter the resource.
• Outbound rules define what traffic can leave the resource.
• You can define rules based on:
  • Protocols (e.g., TCP, UDP).
  • Port ranges (e.g., 80 for HTTP, 443 for HTTPS).
  • CIDR blocks or specific IPs.

Protocols

• Supported protocols include TCP, UDP, ICMP, and others.
• For example, use TCP for most application traffic and ICMP for ping requests.

Ports

• Examples of commonly used ports:
  • 22 (SSH): Secure shell access to servers.
  • 80 (HTTP): Web traffic.
  • 443 (HTTPS): Secure web traffic.
  • 3306 (MySQL): Database access.
• You can also define custom port ranges.

CIDR Ranges or IP Addresses

• Specify the range of IPs that can connect to your resource.
• Example: Allow traffic only from 192.168.1.0/24 or a specific IP like 203.0.113.1/32.

Creating a Security Group

It's quite easy to create a security group on the AWS Management Console. Once logged in, search for the EC2 service. A confusion I used to have was thinking that security groups is an service but it's actually a feature of other services. You can create and configure security groups on other services such as RDS, ELB or EKS.

Once on the EC2 interface, you'll find Security Groups on the Network and Security section on the side panel. Click on the 'Create Security Group' button and you should see an interface like the one below:

I'll create a security group to manage traffic for a web application. So in the inbound traffic section, I will allow http and https traffic. I'll also allow ssh traffic to allow remote connection to my EC2 intance via ssh.

The ports are automatically filled in for these protocols and I chose the CIDR blocks to allow traffic from.

You can optionally add a tag. Click the orange 'Create Security Group' button and that just about it!

Remember that Security Groups are stateful so they will allow outbound traffic for whatever inbound traffic we allowed.

Use Cases

Restricting Access to Specific IPs

• Use security groups to allow database access (e.g., RDS or ElastiCache) only from specific IP addresses or subnets, such as application servers within your VPC. For example, allow inbound traffic on port 3306 (MySQL) or 5432 (PostgreSQL) from a trusted IP range.
• Restrict SSH (port 22) or RDP (port 3389) access to specific admin IP addresses to minimize exposure to unauthorized users.

Multi-Tier Architectures

• Configure distinct security groups for each layer of your application (web, application, and database layers).
  • Web Tier - Allow inbound traffic from the internet on ports 80 (HTTP) and 443 (HTTPS).
  • Application Tier - Restrict traffic to only accept requests from the web tier's security group.
  • Database Tier - Allow inbound traffic only from the application tier on the database port, such as 3306 (MySQL).

This approach isolates each layer, reducing the attack surface.

Securing Applications Across AWS Regions

• Use security groups to define cross-region traffic rules for resources communicating between VPCs in different regions. For example, allow only specific IP ranges or security group IDs to ensure that only trusted traffic flows between the regions.

Best Practices

Principle of Least Privilege

• Avoid overly permissive rules like 0.0.0.0/0 for inbound traffic, especially for sensitive ports (e.g., SSH or database ports). Instead, restrict access to known IP ranges or security groups.

Regular Audits

• Periodically review your security group rules to identify and remove redundant or overly permissive rules. Use AWS Config and CloudTrail to monitor changes and ensure compliance with security policies.

Use Descriptive Naming

• Use meaningful names for your security groups to easily identify their purpose. For example:
  • web-tier-sg for web traffic.
  • db-access-sg for database rules.

Conclusion

AWS Security Groups are a simple yet powerful way to keep your cloud resources secure. They act as virtual firewalls, letting you control who and what can access your applications. Whether you're restricting access to specific IPs, securing a multi-tier architecture, or managing cross-region communication, Security Groups help you protect your workloads while staying flexible. By sticking to best practices like least privilege, regular audits, and clear naming, you can keep your setup secure and easy to manage. Mastering Security Groups is not just great for your projects—it's also key for acing the AWS Certified Solutions Architect – Associate exam.

Sample Questions

1. Question:
You are setting up a new EC2 instance to host a web application. The application needs to accept HTTP and HTTPS traffic from the internet, but SSH access should only be allowed from your corporate office's static IP (203.0.113.25). Which Security Group rules should you configure?

A. Allow inbound traffic on ports 80, 443, and 22 from 0.0.0.0/0.
B. Allow inbound traffic on ports 80 and 443 from 0.0.0.0/0, and port 22 from 203.0.113.25/32.
C. Allow inbound traffic on ports 80, 443, and 22 from 203.0.113.25/32.
D. Allow inbound traffic on ports 80 and 443 from 0.0.0.0/0, and block port 22.

Answer: B
HTTP (80) and HTTPS (443) traffic needs to be accessible to all (0.0.0.0/0), while SSH (22) should be restricted to the corporate IP address (203.0.113.25/32).

2. Question:
Your application is hosted in a three-tier architecture with separate Security Groups for the web, application, and database tiers. The database tier should only allow access from the application tier. How should you configure the database Security Group?

A. Allow inbound traffic on port 3306 from 0.0.0.0/0.
B. Allow inbound traffic on port 3306 from the web-tier Security Group.
C. Allow inbound traffic on port 3306 from the application-tier Security Group.
D. Deny all inbound traffic to the database Security Group.

Answer: C
For a secure multi-tier architecture, the database tier should only allow traffic from the application-tier Security Group, not the web tier or public IPs.

3. Question:
You need to set up a Lambda function in a VPC that communicates with an RDS instance. What Security Group configuration is required?

A. Attach the same Security Group to both the Lambda function and RDS instance.
B. Allow inbound traffic on port 3306 from the Lambda function's Security Group in the RDS Security Group.
C. Allow outbound traffic on port 3306 in the Lambda function's Security Group.
D. Allow inbound traffic on port 3306 from 0.0.0.0/0 in the RDS Security Group.

Answer: B
For Lambda to communicate with RDS in a VPC, the RDS Security Group must allow inbound traffic from the Lambda function's Security Group on the appropriate port (3306 for MySQL).

4. Question:
A new compliance requirement mandates that SSH access to all EC2 instances in your environment must be logged and restricted to a specific bastion host. What changes should you make to the Security Groups?

A. Allow SSH access from 0.0.0.0/0 for all instances.
B. Allow SSH access only from the bastion host's Security Group.
C. Block SSH access to all EC2 instances.
D. Allow SSH access from the bastion host's public IP.

Answer: B
The best approach is to allow SSH access only from the bastion host's Security Group. This ensures compliance and minimizes exposure.

5. Question:
You are troubleshooting a connectivity issue where an EC2 instance in one VPC cannot reach an RDS instance in another VPC. Both VPCs are peered, and the RDS Security Group allows traffic from the EC2 instance’s private IP. What is the likely cause?

A. The RDS Security Group needs a rule for the EC2 instance’s public IP.
B. The EC2 instance’s Security Group needs an outbound rule for the RDS port.
C. VPC peering does not support cross-VPC communication.
D. The RDS Security Group needs an inbound rule for the EC2 instance’s Security Group.

Answer: D
When VPC peering is in place, RDS Security Groups must allow traffic from the EC2 instance’s Security Group, not just its private IP, to enable communication.