Security Groups: Stateful Firewalls for Your Cloud Resources

Why it exists

Cloud resources like virtual machines are just computers on a network. Without protection, they are exposed to any traffic on that network. Security groups solve this by providing a fundamental, resource-level firewall to enforce the principle of least privilege, ensuring only intended traffic can reach a resource.

The mental model

Think of a security group as a bouncer standing at the door of an exclusive club (your cloud instance). The bouncer has a specific guest list (the inbound rules). If you're on the list, like an HTTP request on port 80, you get in. If not, you're denied. It's also "stateful": if someone from inside the club initiates a conversation with the outside, the bouncer automatically lets the reply back in, even if the sender wasn't on the original guest list.

How it works

A security group is a set of allow-only rules applied to a cloud resource like a virtual machine. You cannot create "deny" rules; traffic is denied by default unless a rule explicitly allows it. Rules specify a protocol (TCP, UDP), a port range (e.g., 80, 443), and a source (for inbound rules) or destination (for outbound rules). The source can be an IP address range, a specific IP, or even another security group, which is useful for creating tiers (e.g., allow traffic from the "web-servers" group to the "databases" group).

When to use it

Use security groups as your first line of network defense for any cloud resource. They are essential for segmenting your application architecture. For example, create one group for web servers allowing ports 80/443 from the internet, another for application servers allowing traffic only from the web servers' security group, and a third for databases allowing traffic only from the application servers' group.

When not to use it

Security groups are not the tool for creating explicit "deny" rules; for that, you would use a Network Access Control List (NACL), which is stateless and operates at the subnet level. Security groups also don't filter certain internal cloud provider traffic like DNS resolution or instance metadata service requests. They are for controlling traffic to and from your application resources.

One canonical example

To allow an administrator to connect to a Linux virtual machine via SSH, you add an inbound rule to the instance's security group. The rule would specify Protocol: TCP, Port Range: 22, and Source: the administrator's specific office IP address (e.g., 203.0.113.5/32). The most common and dangerous mistake is setting the source to 0.0.0.0/0, which allows anyone on the internet to attempt to connect.