What Are Security Groups, and How Do They Protect Cloud Servers

Security Groups are virtual access rules that determine which traffic is allowed to reach a cloud server at all — and which traffic that server itself is allowed to send outbound. The simplest way to think about them is as the first network filter in front of an instance: if the required port, protocol, or source is not allowed, the connection does not go through.

The main value of Security Groups is that they sharply reduce unnecessary network exposure. Instead of a server that is effectively “sticking out onto the Internet” with every port exposed, you leave open only the traffic paths that are actually needed: for example, HTTPS for a web service, SSH only from a trusted IP, and database access only from the application layer rather than from the whole world.

But Security Groups should not be treated as complete server protection. They do not fix vulnerable code, replace patching, IAM, WAF, or a sound access architecture. Their role is narrower and simpler: to keep unnecessary traffic away from places where it has no business going.

What Security Groups do well — and what they do not:

Security Groups are useful because they remove unnecessary network entry and exit paths before the traffic ever reaches the server. The next step is to look more closely at how they actually work, what exactly they filter, and where their limits begin.

How a Cloud Server Receives Only the Connections It Actually Needs

Above, we briefly covered the main idea: Security Groups determine which traffic is allowed to reach a cloud server at all and which traffic the server itself may send out. Now let us look more closely at how this works in practice and why this layer matters so much in a cloud network.

At its core, a Security Group is a virtual network filter placed in front of an instance. It contains rules for both inbound and outbound traffic, and those rules are defined through the source or destination, the protocol, and the port or port range. If a connection does not match those conditions, it simply never reaches the server.

One important note: always check your cloud provider’s documentation carefully. In most cases, Security Groups are configured according to the logic of “everything not explicitly allowed is denied,” which is the normal default-deny firewall model. But exceptions do exist, and some platforms may require explicit deny logic or have provider-specific behavior that needs to be understood before relying on the rules.

How This Works in a Clear Practical Example

Imagine a typical server running a web application. It does not need “the whole Internet” all at once. It needs only specific things: HTTPS for users, SSH for the administrator, and possibly access to a database — but not from just any address, only from the application itself.

That is exactly where this model becomes useful. It lets you describe the network logic not as “the server is open,” but as “this server is allowed to receive only this traffic, and only from these sources.” For example, the public part of the site may expose only port 443, administrative access may allow port 22 but only from one office IP, and the database may not be published externally at all.

A good example is a three-tier setup: load balancer → web → database. In this model, the web layer can accept HTTPS from users, while the database accepts connections only from the application layer, not from the Internet. If someone tries to connect directly to the database, the connection will not even reach the server or fail at the login stage — it will hit the network filter first, and that traffic will simply not be allowed through.

That is exactly why rules like these are useful not as some “extra security option,” but as a way to remove unnecessary network entry points in advance. This is especially important in the cloud, where a typical mistake often looks very simple: SSH is open to everyone, the database is exposed externally, or outbound traffic is allowed without restriction “just in case.”

What Exactly They Filter: IP, Port, Protocol, and Traffic Direction

In practice, the rules are built around a few simple elements: where the traffic comes from, where it is going, which protocol it uses, and which port it is trying to reach.

If you translate that into clear practical scenarios, it looks roughly like this:

• HTTPS for users — allow inbound TCP 443 from all addresses (and do not forget UDP as well if you are using QUIC)
• SSH for the administrator — allow TCP 22, but only from a specific IP
• The database — allow, for example, 5432 or 3306, but only from the application layer rather than from everyone
• Ping or other service traffic — either allow it explicitly or do not open it at all if it is not needed

So the filtering here is not built around some abstract idea of “dangerous traffic,” but around very specific network parameters. That is exactly what gives the server not a vague sense of protection, but a clearly defined list of what is actually permitted.

There are also two important technical characteristics that make this model especially practical.

First, the filtering is stateful: if an inbound connection is already allowed, the return traffic is permitted automatically. Put simply, if a user opens the site over HTTPS, the server does not need a separate rule just to send the page back in response.

Second, the rules do not have to be packed into one overloaded group. They can be split across multiple groups and attached to the same server, with the combined result forming the overall access model. For example, one group may govern administrative access, while another governs the traffic of the website itself.

That is exactly why Security Groups work so well as the first network filter in front of a server: they allow only what the application genuinely needs and block everything else before the connection is even attempted.

What Kinds of Mistakes and Threats Security Groups Actually Help Against

Security Groups are especially useful in situations where the problem does not begin with a sophisticated attack, but with unnecessary network exposure.

The most common case is services being exposed externally even though they have no reason to be there. For example, a server may need only HTTPS for users, but SSH, the database, or some internal service port also ends up reachable from outside. The more of these unnecessary entry points exist, the wider the attack surface becomes.

A second typical issue is overly broad source access. Not “SSH only for the administrator,” but SSH open to the entire Internet. Not “the database is reachable only by the application,” but the database responds to any IP. In a setup like that, the problem starts before any compromise even happens: access is already wider than it should be.

A third issue is weak isolation between layers. If the web tier, the application tier, and the database can all see one another without strict restrictions, then a mistake in one component creates too many unnecessary paths inside the infrastructure.

A fourth is unrestricted outbound traffic. For example, if malware finds its way onto a server, outbound restrictions can prevent it from establishing a connection back to an attacker. That is why outbound traffic should also be restricted as tightly as practical, allowing only the integrations and destinations the service actually needs.

In practice, this helps prevent very concrete problems:

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure



Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans



Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus



Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster


• The database is not exposed to the Internet
• SSH is not open to everyone
• An internal service does not accept external traffic
• One component cannot connect to places it does not actually need to reach

Imagine an online store selling socks with capybaras, dinosaurs, and slices of pizza on them. The customer should see only the storefront. The site itself may talk to the application, and the application may talk to the order database. But the database should not be reachable by the customer — or by a random external scanner. If that restriction exists at the network level, some classes of mistakes simply never reach the server in the first place.

But the role of Security Groups does not end with theory — they also have very clear practical limits. The next logical step is to look at where they no longer help on their own and which other mechanisms they are most often confused with.

Where Security Groups Do Not Save You on Their Own — and What They Are Often Confused With

Why They Are Not a Substitute for Updates, IAM, or Application Security

If a server exposes only the traffic it actually needs, that is already a good start. But Security Groups do not fix vulnerable code, patch flaws in an outdated CMS, solve weak passwords, or replace access control. They do not inspect the contents of an HTTP request and cannot tell whether they are seeing an SQL injection attempt, exploitation of an application bug, or a stolen session. Their role is much narrower: either allow the connection based on the defined network rules, or block it.

Using the capybara-socks store as an example, this becomes very simple. You can lock the server down perfectly at the port level: leave only HTTPS open, restrict SSH, and hide the database from the Internet. But if the store’s admin panel is vulnerable, and the administrator account has no MFA and excessive privileges, Security Groups alone will not fix that. At that point, what you need are updates, a sound IAM model, and protection for the application itself.

That is why it is best to think of Security Groups not as “all of cloud security,” but as one specific barrier in front of a resource. They are very good at reducing network exposure, but they do not replace the other layers of defense.

How They Differ from Firewall Rules, NACLs, and Other Network Controls

At this point, it is important to clarify not the limitations of Security Groups, but their place in the broader network design. They are often grouped together with NACLs and host firewalls, even though these mechanisms operate at different layers and solve different problems.

The simplest way to think about it is this: Security Groups operate at the resource itself, NACLs at the subnet level, and the host firewall inside the operating system. They do not duplicate one another one-to-one, and they do not automatically replace one another.

It is useful to begin by comparing Security Groups and NACLs, because those two are the ones people most often confuse.

Security Groups and NACLs: what is the practical difference:

Returning to our example, the logic looks like this: Security Groups decide whether the web server can accept HTTPS and whether the database may respond only to the application. NACLs, by contrast, define a broader filter for the entire subnet in which those resources live.

But the confusion does not stop there. It is also important to distinguish Security Groups from the ordinary firewall running inside the server itself.

Where the boundary lies between Security Groups and the host firewall:

In other words, Security Groups, NACLs, and the host firewall are not three names for the same thing, but three different layers of network control. That is exactly why it makes more sense to treat them not as competitors, but as parts of one overall security model.

Conclusion

The core idea here is fairly simple: the less unnecessary access a server has, the fewer unnecessary problems it creates. That is exactly what these rules provide — they block traffic that does not belong there at the entry point and help avoid exposing a resource more broadly than the application actually requires.

But this is only one layer of protection. It does not fix vulnerable code, replace access control, or eliminate the other risks on its own.

FAQ

Is this the same thing as a cloud firewall?

Not exactly. It is one of the cloud mechanisms used to filter traffic, but it is not a universal name for all network protection in the cloud.

Do you still need rules like this if the server is not directly exposed to the Internet?

Yes. Even for an internal resource, it is better to define in advance exactly who is allowed to reach it and on which ports.

Can they protect a website from being hacked?

Not on their own. They reduce unnecessary network exposure, but they do not fix application vulnerabilities, weak passwords, or mistakes in access control.

Why is the rule 0.0.0.0/0 dangerous?

Because it opens access to any IP address. That may be justified for public HTTPS in some cases, but for SSH, a database, or administrative services, it is usually far too broad.

Can you rely only on these rules without a host firewall?

Sometimes yes, but that is not always the best approach. The network filter at the resource level and the firewall inside the operating system solve similar problems at different layers and can complement one another.

Which matters more: these rules or IAM?

They are not competitors. One layer restricts network access; the other governs permissions and actions inside the infrastructure. In a sound security model, both are usually needed.

Sources

1. AWS — Control traffic to your AWS resources using security groups

2. AWS — Security group rules

3. AWS — Amazon EC2 security group connection tracking

4. AWS — Control subnet traffic with network access control lists