Network Security Groups vs Security Lists

OCI gives you two mechanisms to decide which traffic is allowed in and out of your resources at the virtual network layer, and teams new to the platform often use them interchangeably, mix them in ways that fight each other, or never quite understand why a packet is being dropped. Network security groups and security lists do similar jobs in different ways, and choosing the right one for each situation makes your network rules far easier to reason about, which is exactly what you want when a misconfigured rule is the difference between secure and exposed.

Both are stateful firewalls applied at the virtual network level. Both work by allowing specific traffic while everything not allowed is denied. The difference is what they attach to and how you reason about them, and that difference is what determines which one keeps your rules clean and which one slowly turns into a tangle nobody wants to touch.

How each one works

A security list attaches to a subnet. Every resource in that subnet inherits the rules in the security list. If you want all the machines in a subnet to share the same traffic rules, a security list expresses that cleanly. The catch is that the rule applies to the whole subnet, so if resources in the same subnet need different rules, a security list forces you to either split them into separate subnets or write rules broad enough to cover everyone, which weakens the control.

A network security group attaches to individual resources rather than to a subnet. You define a group, write its rules, and then add the specific network interfaces that should follow those rules. Resources in the same subnet can belong to different groups with different rules, and a single resource can belong to more than one group. This decouples the security boundary from the subnet boundary, which is what makes network security groups so much more flexible.

The key difference in practice

The practical distinction is that a network security group lets you group resources by their function rather than by where they happen to live on the network. You can have a group for web servers, a group for application servers, and a group for databases, each with rules that fit its role, even when those resources share subnets. You can even write rules that reference another group as the source or destination, so a rule can say that database group members accept traffic from application group members, without naming addresses at all. That is far closer to how people actually think about which tier may talk to which.

Which to use

For most modern estates, network security groups are the primary tool because they match how you think about the estate and they keep rules tight without forcing your subnet design to bend around your security needs. The role based grouping and the ability to reference one group from another make rules readable and maintainable, which matters enormously because the rule nobody understands is the rule that quietly becomes too permissive.

Security lists still have a place for broad defaults that genuinely apply to every resource in a subnet, such as a baseline rule you want everywhere. The thing to avoid is using both heavily on the same resources without a clear reason, because when both a security list and a network security group apply, the allowed traffic is the combination of the two, and that overlap is a frequent source of confusing behaviour when you are trying to work out why a connection is or is not getting through.

Stateful rules and the egress trap

Both mechanisms are stateful, which means that when you allow a connection in, the return traffic for that connection is allowed back out automatically without a matching rule, and the same applies in reverse. This is convenient and it is how most people expect a firewall to behave, but it leads to a common oversight. Teams often write careful ingress rules to control what can reach a resource and then leave egress wide open, on the assumption that outbound traffic is harmless. It is not always harmless. An attacker who has compromised a resource relies on outbound connections to exfiltrate data or to reach a command channel, and an open egress policy is exactly what makes that easy. Tightening egress so a resource can only reach the destinations it genuinely needs is one of the higher value and most overlooked controls available to you.

The practical approach is to treat egress with the same care as ingress, especially for sensitive tiers like databases, which usually have no legitimate reason to initiate connections to the internet at all. A database that can only be reached by its application tier and that cannot itself reach outward is a far smaller prize than one with open egress, even if every other control is identical. Building that discipline into your network security groups from the start, rather than retrofitting it after an incident, is the kind of design decision that pays for itself quietly and is central to the zero trust thinking that runs through modern OCI security.

A note on debugging

When traffic is not flowing as expected, the cause is almost always a rule that is missing or a rule somewhere else that is also applying. Because the effect of security lists and network security groups is cumulative, the discipline is to know every control that touches a given resource before concluding a rule is wrong. Leaning on groups arranged by role reduces this surface, because you have fewer places to look and the rules read in terms of intent. This is the same clarity principle that runs through good network design and through secure access patterns like the bastion service.

Bringing it together

Both mechanisms are stateful virtual firewalls, but they differ in what they attach to. Security lists govern a whole subnet, which suits broad defaults. Network security groups govern individual resources by role, which suits the granular, readable rules most estates actually need, and they can reference each other so rules express which tier talks to which. Lean on groups as your primary tool, reserve security lists for genuine subnet wide defaults, tighten egress as well as ingress, and remember that where both apply the effect is cumulative. The wider security model is in our complete security guide, the network context is in our networking solution, and secure access patterns are in our bastion service guide.