Cloud Network Controls — Explain network controls in cloud (security groups, NACLs) conceptually

Traditional data centers relied on physical firewalls, routers with access control lists, and demilitarized zones (DMZs) to segment and protect network traffic. These devices sat at well-defined perimeter boundaries, inspecting packets and enforcing policy through hardware appliances that administrators could physically rack, cable, and configure. When organizations began migrating workloads to cloud computing platforms in the late 2000s, the familiar perimeter dissolved: compute instances spun up in minutes, IP addresses were ephemeral, and the underlying physical network was entirely abstracted away. The question that confronted security engineers was straightforward yet profound — how do you enforce network segmentation and access control when you no longer own, or even see, the physical infrastructure?

The central challenge this lesson addresses is: how do cloud providers virtualize the packet-filtering functions of traditional firewalls, and what conceptual distinctions between stateful and stateless controls shape the way you design secure cloud networks? Understanding these controls is essential for anyone deploying or securing infrastructure in AWS, Azure, or GCP.

Cloud network controls rest on a small set of foundational ideas that mirror classical network security but adapt them to virtualized, software-defined environments. Before diving into implementation details, it is critical to internalize these principles because they govern every rule you write, every troubleshooting session you face, and every compliance audit you navigate.

The diagram above illustrates the layered evaluation model. When a packet arrives from the internet destined for an EC2 instance in a public subnet, it first encounters the subnet's NACL. The NACL evaluates its rules in ascending numeric order and either allows or denies the packet — this evaluation is entirely stateless, meaning the NACL has no memory of prior packets in the same TCP connection. If the NACL permits the packet, it next reaches the security group associated with the instance's Elastic Network Interface (ENI). The security group evaluates all its rules collectively — if any rule matches, the packet is allowed through. Crucially, because the security group is stateful, the return traffic for this connection is automatically permitted without requiring an explicit outbound rule. This two-layer architecture provides defense in depth: even if a security group rule is overly permissive, a restrictive NACL can act as a coarse-grained safety net.

Security Group Rule Evaluation

A security group acts as a virtual firewall for an individual instance (more precisely, for an Elastic Network Interface). It maintains a connection tracking table so that once a flow is established, return packets are allowed implicitly. Rules specify the protocol (TCP, UDP, ICMP, or All), the port range, and the source or destination — which can be a CIDR block or another security group ID. The evaluation model is aggregate allow: the engine considers all inbound rules together, and if the packet matches any one rule, it is permitted. There is no concept of rule ordering or explicit deny rules. If no rule matches, the implicit deny drops the packet. This design simplifies configuration but means that security groups cannot be used to block a specific IP while allowing a broader range — you must sculpt the CIDR blocks in your allow rules carefully.

NACL Rule Evaluation

A Network Access Control List (NACL) operates at the subnet boundary and is stateless — every packet is evaluated independently against the rule table, regardless of whether it belongs to an established connection. Each rule has a numeric priority (e.g., 100, 200, 300), and the engine processes rules from lowest number to highest, stopping at the first matching rule. This first-match semantics makes NACLs more expressive than security groups because you can insert a low-numbered deny rule (e.g., Rule 50: Deny 198.51.100.0/24) that takes precedence over a higher-numbered allow rule (e.g., Rule 100: Allow 0.0.0.0/0). The catch is complexity: because NACLs are stateless, you must define explicit outbound rules allowing return traffic, typically on ephemeral port ranges (1024–65535 for most operating systems).

While both security groups and NACLs filter traffic, they differ along several important dimensions. The table below provides a comprehensive feature-by-feature comparison that every cloud security practitioner should internalize. These distinctions directly affect how you troubleshoot connectivity issues, how you satisfy compliance requirements, and how you architect multi-tier applications.

One of the most powerful features of security groups is the ability to reference another security group as a traffic source. For example, you can create a rule that says "allow TCP 3306 from sg-web-tier," which automatically permits database access from any instance associated with the web-tier security group, regardless of that instance's IP address. This abstraction decouples policy from ephemeral addressing and is a cornerstone of cloud-native microsegmentation. NACLs, by contrast, can only reference CIDR blocks, making them more suitable for broad, network-range policies like blocking an entire suspicious IP range.

Consider a classic three-tier architecture deployed in AWS: a web tier in a public subnet, an application tier in a private subnet, and a database tier in another private subnet. The goal is to configure security groups and NACLs so that internet users can reach the web servers on HTTPS (port 443), the web servers can reach the application servers on port 8080, and the application servers can reach the database on port 5432 (PostgreSQL). No other traffic should be permitted.

No single network control is a silver bullet. Security groups and NACLs each have distinct strengths and limitations that influence architectural decisions. Understanding these trade-offs allows you to choose the right tool — or combination of tools — for each layer of your cloud infrastructure.

Cross-Provider Analogues

Security groups and NACLs represent the foundational layer of cloud network security, but modern architectures extend well beyond these basic controls. As you advance in cloud security, you will encounter constructs that build on top of — or complement — these primitives to provide deeper inspection, broader policy expression, and stronger identity-awareness.

The concept of microsegmentation represents the logical evolution of security group policies. Instead of broadly segmenting by subnet (a "zone-based" approach), microsegmentation assigns unique policies to every individual workload, often combining security group rules with service mesh policies and identity-aware proxies. In a zero-trust architecture, the network is assumed hostile, and every communication must be authenticated, authorized, and encrypted — regardless of whether it originates from inside or outside the VPC. Security groups and NACLs remain the bedrock on which these advanced architectures are built, enforcing coarse network reachability while higher-layer controls handle identity and application-level authorization.