A security group is a stateful virtual firewall attached to cloud resources, such as virtual machines, database instances and load balancers, that defines which inbound and outbound traffic is allowed by protocol, port range and source or destination. Anything not explicitly allowed is denied, and return traffic for an allowed connection passes automatically.
In cloud networking, security groups are the primary instance-level control inside a VPC. AWS and several other providers use the name directly; Azure offers the comparable network security group, and Google Cloud implements the same idea through VPC firewall rules bound to tags or service accounts.
How a security group filters traffic
A security group is enforced by the virtualization layer of the host, not by the guest operating system. Each attached network interface receives the combined rules of every group associated with it, and the hypervisor or virtual switch evaluates packets before they reach the instance.
The group is stateful: the platform tracks each connection, so if an inbound rule allows a request on port 443, the response leaves without an outbound rule. In most implementations rules are allow-only, and multiple groups on one interface combine as a union of permissions rather than an ordered list.
The table shows the fields that every security group rule contains.
| Field | Example values | Meaning |
|---|---|---|
| Direction | Inbound or outbound | Which flow the rule evaluates |
| Protocol | TCP, UDP, ICMP or all | Transport protocol matched |
| Port range | 443, 5432, 1024-65535 | Destination ports allowed |
| Source or destination | CIDR block, prefix list or another group | Who may connect or be reached |
| Description | Allow HTTPS from load balancer | Human-readable purpose |
Referencing groups instead of addresses
A powerful feature is the security group reference: a rule can name another group as its source, meaning any interface that belongs to that group may connect. This creates identity-like segmentation that keeps working when autoscaling replaces instances and their IP addresses change.
A typical three-tier application uses one group per tier, chained by references, as the following table shows.
| Group | Inbound rule | Source |
|---|---|---|
| Load balancer group | TCP 443 | 0.0.0.0/0 and ::/0 |
| Application group | TCP 8080 | Load balancer group |
| Database group | TCP 5432 | Application group |
| Management group | TCP 22 | Bastion or VPN group only |
With this pattern, the database is unreachable from the internet even if someone accidentally gives it a public address, because no rule admits traffic from any source other than the application tier.
Security groups compared with network ACLs and firewalls
Security groups are one layer in a defense-in-depth design. Subnet-level network ACLs, centrally managed cloud firewalls and private endpoints each solve a different part of the problem.
| Control | Scope | State handling | Rule logic |
|---|---|---|---|
| Security group | Network interface | Stateful | Allow rules only, union |
| Network ACL | Subnet | Stateless | Numbered allow and deny, first match |
| Managed cloud firewall | VPC or traffic path | Stateful with inspection | Domain, IDS and application rules |
| Host firewall | Operating system | Stateful | Configured inside the guest |
Because network ACLs are stateless, they need explicit rules for ephemeral return ports, commonly 1024-65535. Security groups avoid this, which is why most teams do routine filtering in security groups and reserve ACLs for broad subnet-wide denials.
Designing and maintaining security groups
Good security group design follows least privilege and keeps rules understandable. Providers apply quotas, for example a limit on rules per group and groups per interface, so sprawling rule sets eventually hit hard limits as well as becoming unreadable.
Changes to a security group take effect within seconds on every attached interface, without restarting instances. That speed is useful during an incident, but it also means a careless edit to a shared group can cut off production traffic immediately, so rule changes deserve the same review discipline as code.
- Create one group per role or tier, not one group per instance.
- Prefer group references and prefix lists over long lists of individual IP addresses.
- Restrict the default outbound allow-all rule where data exfiltration is a concern.
- Manage rules through infrastructure as code so every change is reviewed and versioned.
- Enable flow logs to verify which rules actually carry traffic before removing them.
Common mistakes and their consequences
Most security group incidents come from overly broad rules added under time pressure and never removed. The table lists frequent problems and their remedies.
| Mistake | Consequence | Fix |
|---|---|---|
| SSH or RDP open to 0.0.0.0/0 | Constant brute-force attempts | Use a bastion, VPN or session manager |
| Database port open to the VPC CIDR | Any compromised host reaches data | Reference the application group only |
| Shared group on unrelated systems | Unintended lateral access | Split groups by role |
| Forgetting IPv6 rules | Service unreachable or exposed over IPv6 | Mirror intent for ::/0 deliberately |
| Relying on groups alone | No protection against application flaws | Add WAF, patching and authentication |
Explained without jargon
A security group is a guest list for a cloud server. It says exactly who may knock on which door, for example “web visitors may use the front entrance” or “only the application servers may talk to the database”. Everyone not on the list is turned away.
Once a guest is let in, the conversation can continue in both directions without asking again. This makes security groups simple to write and hard to bypass, as long as the list stays short and specific.
A typical use case
A healthcare startup runs a patient portal on a cloud platform. Its first deployment used a single security group that allowed ports 22, 443 and 5432 from anywhere, because the team wanted to move quickly. A routine review revealed that the PostgreSQL port was reachable from the internet, with thousands of failed login attempts in the database logs.
The engineers replaced it with four groups: the load balancer accepts HTTPS from the internet, the application servers accept port 8080 only from the load balancer group, the database accepts port 5432 only from the application group, and administrative access goes through a session manager with no inbound SSH at all. After the change, flow logs showed zero external connection attempts reaching the database, and the configuration passed the next compliance audit.