Security Groups (SGs) are the fundamental building blocks of security in AWS, acting as virtual firewalls for your Amazon EC2 instances to control incoming and outgoing traffic.
1Stateful Operations
Unlike Network ACLs which are stateless, Security Groups are stateful. This means if you allow an outbound request to the internet (e.g., your server downloading an update), the response from the internet is automatically allowed back in, even if there is no inbound rule explicitly permitting it.
2Default Rules & Best Practices
When you create a new Security Group, the default behavior is to deny all inbound traffic and allow all outbound traffic. A major best practice is to adhere to the principle of least privilege. For example, never open Port 22 (SSH) to 0.0.0.0/0 (the entire internet). Instead, restrict it strictly to your office or home IP address.
3Step-by-Step Breakdown
Welcome to AWS Security Groups. Think of a Security Group as a virtual firewall for your EC2 instances.
By default, a new Security Group blocks ALL inbound traffic. You must explicitly allow specific ports, like Port 80 for HTTP or Port 22 for SSH.
Checkpoint: What is the default behavior of a new Security Group regarding inbound traffic?
- →It allows all traffic by default
- →It denies all inbound traffic until explicitly allowed
Security Groups are stateful. This means if you send a request from your instance, the response traffic is automatically allowed to flow back in, regardless of inbound rules.
You can apply multiple Security Groups to a single EC2 instance, and you can apply one Security Group to multiple instances. They operate at the instance level.
Checkpoint: If a Security Group is 'stateful', what does that mean for outbound requests?
- →Return traffic is blocked unless an inbound rule exists
- →Return traffic for allowed outbound requests is automatically allowed
Great job! You now understand how to protect your instances at the network level using AWS Security Groups.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Security Configuration Dashboards Need Clear, Screen-Reader-Friendly Rule Summaries
A table of inbound/outbound rules with only color-coded allow/deny indicators excludes colorblind and screen reader users — always pair visual security state with explicit text ("Allow", "Deny") in any custom security dashboard.
2Document Why a Rule Exists, Not Just What It Allows
A security group rule allowing a specific port with no accompanying justification is a maintenance and accessibility hazard for whoever audits it later — clear naming and comments help every future reader, not just the original author.
SEO Implications
- 1
Overly Permissive Security Groups Are a Real Compliance and Trust Risk
A publicly-known security breach traced to a misconfigured security group (like open SSH to 0.0.0.0/0) can damage a business's reputation and search visibility indirectly through negative press and reduced user trust, beyond the direct security cost.
- 2
Security Groups Have No Direct SEO Weight of Their Own
Network-level firewall rules are entirely invisible to crawlers — their only indirect SEO relevance is ensuring the application actually stays available and isn't compromised in a way that leads to defaced or malicious content being served.
Best Practices
Never Open Port 22 (SSH) or Port 3389 (RDP) to 0.0.0.0/0
Restrict administrative access ports to your office, VPN, or a specific known IP range — leaving SSH open to the entire internet is one of the most common causes of compromised EC2 instances.
Use Security Group References Instead of Hardcoded IP Ranges Between Your Own Resources
Allowing traffic from another security group (e.g., "allow port 5432 from the app-server security group") rather than a specific IP range keeps rules valid even as instances are replaced or scaled, since the reference follows the group, not a static address.
Frequent Bugs
An EC2 instance is compromised via brute-force SSH attempts shortly after launch.
The security group almost certainly has port 22 open to `0.0.0.0/0`. Restrict the inbound SSH rule to a specific known IP range (your office or VPN), or use AWS Systems Manager Session Manager to avoid exposing port 22 at all.
A newly launched instance can't reach the internet to download updates, despite an outbound rule appearing to allow it.
Check whether the issue is actually the security group or the subnet's route table and NAT Gateway/Internet Gateway configuration — security groups control what traffic is allowed, but routing determines whether traffic can reach its destination at all.
Real-World Examples
Least-Privilege Security Group for a Web Server
A production web server's security group allows HTTP/HTTPS from anywhere (since it's a public site), but restricts SSH strictly to the engineering team's office IP range, following the principle of least privilege.
Inbound Rules:
ALLOW TCP 443 (HTTPS) from 0.0.0.0/0
ALLOW TCP 80 (HTTP) from 0.0.0.0/0
ALLOW TCP 22 (SSH) from 203.0.113.0/24 // office IP range only