Cloud Firewalls and Security Groups Explained

Where an unwanted packet actually stops

Every cloud platform ships some form of packet filter, and every platform gives it a different name. AWS calls the instance level filter a security group. Azure calls it a network security group. Google Cloud calls it a VPC firewall rule. DigitalOcean, Hetzner and Vultr simply say cloud firewall.

Underneath the branding they answer one question: for a packet arriving at this network interface, is there a rule that permits it? If the answer is no, the packet is dropped before your operating system ever sees it. That last detail is the reason these filters matter so much. Traffic blocked at the platform edge consumes none of your instance's CPU and appears in none of its logs.

This article separates the concepts that get conflated: where filtering happens, what stateful means, how the major platforms model rules, and how to write a rule set that stays understandable a year later.

Four places you can filter, and what each one is good at

The platform firewall

Attached to the instance or to a group of instances, enforced by the provider's network fabric. This is the outer gate and the one that should carry your default deny posture.

The subnet or network level filter

AWS network ACLs and equivalent constructs sit at the subnet boundary. They are coarser, they are usually stateless, and they are most useful for broad guard rails such as blocking a range outright.

The host firewall

nftables, ufw or firewalld running inside the machine. Slower than the platform filter because the packet already arrived, but it travels with the server when you move platforms and it can express things the provider filter cannot, such as per process rules.

The application layer

A reverse proxy, a web application firewall or the application's own authentication. This is where you filter on things a packet filter cannot see, such as a request path or a login attempt. The OWASP community documents those risks in the OWASP Top Ten.

Use at least the first and third. A platform firewall alone leaves you exposed the moment a rule is loosened for a test and forgotten.

Stateful rules and why the return traffic works

New users often ask why a web server with a single inbound rule on port 443 can still fetch package updates and reply to browsers. The answer is connection tracking. A stateful firewall remembers outbound connections it allowed and automatically permits the matching return packets, so you do not write a mirror rule for every ephemeral port.

Security groups on AWS, network security groups on Azure, Google Cloud VPC firewall rules and the cloud firewalls on DigitalOcean and Hetzner are all stateful in this sense. Network ACLs on AWS are the notable exception: they evaluate each direction independently, which is exactly why people find them confusing and why a missing outbound range breaks connections in ways that look random.

The practical rule is simple. On stateful filters, write inbound rules for what the world may reach and outbound rules only when you genuinely want to restrict where the machine can talk to. On stateless filters, expect to write both directions and to think about the ephemeral port range. AWS documents the distinction clearly in its security groups guide.

How the platforms model the same idea

The shared lesson is in the right hand column. Every mature implementation offers a way to say which servers a rule applies to without listing IP addresses. Use it. Rules bound to tags, labels or groups keep working as instances are replaced, and replacing instances is the normal state of affairs in the cloud. DigitalOcean describes its model in the cloud firewalls documentation.

How much rule expressiveness you need is a real selection criterion. Teams running a handful of servers usually find a tag driven cloud firewall sufficient, while anything with tiered network policy tends to want the richer model. The AWS versus Hetzner comparison sets the two approaches side by side, and the DigitalOcean account listings describe what the tag based firewall covers on that platform.

Writing a rule set that ages well

Start from deny. Every inbound port should be closed until a specific need opens it, and that need should be written down in the rule description field. Most platforms provide one, and most teams leave it blank, which is why nobody can explain rule seventeen six months later.

Group by role rather than by machine. A web tier group allows 80 and 443 from anywhere. An application tier group allows its port only from the web tier group. A data tier group allows the database port only from the application tier. Expressed as group references rather than addresses, this survives scaling events untouched.

Keep administrative access narrow. SSH and remote desktop should be reachable from a known office range, a VPN, or a bastion host, not from the whole internet. Where that is impractical, an identity aware access service or a session manager style tool gives you a logged, credential free path in.

Finally, manage the rules as code. A firewall defined in Terraform is reviewable, diffable and restorable, which matters most during an incident. Our introduction to infrastructure as code covers the tooling, and VPC networking basics explains the subnet structure the rules sit inside.

Patterns that quietly undo the work

• A temporary rule opening a database port to the world for a client demo, never removed.
• Duplicate rule sets copied between environments, so a fix applied to production never reaches staging.
• Relying on the platform firewall only, with no host firewall, so a single console mistake removes all filtering at once.
• Allowing a management port from a dynamic home address and widening the range each time it changes.
• Assuming private network traffic is filtered by default. On several platforms the private interface is not covered by the public firewall, which the private networking guide unpacks.
• Blocking all outbound traffic without a plan for package repositories, time servers and certificate revocation checks, then spending an afternoon on a mystery failure.

Frequently asked