Phase 4: Security & Compliance

Network firewalls, security groups & micro-segmentation

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine your computer network, where all your apps and information live, is like a big school building. Inside this school, you have different classrooms, the library, the gym, and hallways connecting everything. Just like in a real school, you want to make sure only the right people (or information) can go to the right places. You wouldn't want someone who isn't a student wandering into a sensitive test, right? This is where special digital "gatekeepers" come in. They help keep your computer's information safe and organized.

At the main entrance to our school, there's a security desk. This desk has a big list of rules that decide who can come into the school building at all, and who can leave. For example, maybe only students with a valid ID can enter, or only certain delivery trucks are allowed on school grounds. This desk doesn't remember faces very well; every time someone wants to enter or leave, they have to check the list again. It’s like saying, "You can enter the 5th-grade hallway, but only if you're on this list." These rules protect entire parts of the school, like the whole 5th-grade wing, but they aren't very good at knowing what's happening inside each specific classroom.

Now, imagine that each classroom door has its own super-smart, friendly security guard, or even a digital lock. We call these "Security Groups." These classroom guards are much smarter than the one at the main entrance. If a student in Classroom A asks to go borrow a book from Classroom B (which is allowed), the Classroom A guard remembers that request. So, when the student comes back with the book, the guard just waves them in – no need to check the list all over again! This means you can set very specific rules for each individual classroom or even a group of desks within a room. Maybe only students from this specific science class can access the chemicals cupboard.

By having both the main school gate rules and the smart classroom door rules, you can make your computer's "school" incredibly safe and organized. This means you can ensure your important homework files are in a "room" that only you can enter, even if someone else is in the next "room" browsing funny cat videos. This way, you can build really complex computer systems, knowing that each part is protected exactly the way it needs to be, keeping your sensitive information tucked away safely.

Traditional network firewalls serve as the first line of defense, primarily controlling traffic at the perimeter between networks or subnets based on IP addresses, ports, and protocols. In a cloud context, while virtual firewall appliances continue to protect larger network segments or provide advanced features like IDS/IPS, the fundamental role of Network Access Control Lists (NACLs) often mirrors traditional firewall rules. NACLs are stateless, operating at the subnet level, evaluating traffic both inbound and outbound based on explicit allow or deny rules, and are crucial for segmenting traffic between different logical network zones within your Virtual Private Cloud (VPC).

Moving beyond the subnet, cloud environments introduce Security Groups (SGs) – stateful, instance-level virtual firewalls. Unlike NACLs, SGs operate at the Elastic Network Interface (ENI) level, meaning they protect individual compute instances, containers, or even database endpoints. Traffic permitted outbound by an SG is automatically allowed back in, and vice-versa, simplifying management compared to stateless NACLs. This allows you to define granular ingress and egress rules directly tied to the workloads, ensuring that only necessary traffic can reach or leave a specific application component, embodying the principle of "least privilege" at the resource level.

Micro-segmentation takes the concept of Security Groups to its logical extreme, providing granular isolation of individual workloads and applications within the same network segment. Instead of relying solely on subnet-level firewalls, micro-segmentation defines security policies down to the application tier or even individual process level. This strategy drastically reduces the "blast radius" in case of a breach, preventing an attacker from moving laterally between compromised systems even if they reside in the same subnet. Achieved through extensive use of Security Groups, Network Security Groups (in Azure), or Kubernetes Network Policies, micro-segmentation is a cornerstone of Zero Trust architectures in the cloud, ensuring East-West traffic is as rigorously controlled as North-South traffic.

Key Takeaways

  • Network Firewalls (NACLs, virtual appliances) primarily enforce perimeter and subnet-level security, often stateless.
  • Security Groups are stateful, instance-level firewalls, providing granular protection for individual cloud resources.
  • Micro-segmentation applies fine-grained, workload-centric security policies to prevent lateral movement and reduce blast radius.
  • Cloud security fundamentally shifts from a network perimeter focus to a workload-first, identity-driven approach.
  • Effective cloud architecture combines all three for defense-in-depth: NACLs for subnet boundaries, SGs for instance protection, and micro-segmentation for isolating individual workloads.

Code Example

terraform
resource "aws_security_group" "web_server_sg" {
  name        = "web_server_sg"
  description = "Allow HTTP and SSH inbound traffic"
  vpc_id      = aws_vpc.main.id # Assuming aws_vpc.main is defined

  ingress {
    description = "Allow HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow SSH from specific IP"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/32"] # Replace with your office IP
  }

  egress {
    description = "Allow all outbound traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1" # -1 means all protocols
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "WebServerSecurityGroup"
  }
}

How this code works

This code defines an AWS Security Group, acting as a virtual firewall for cloud resources. Its primary job is to establish precise inbound (ingress) and outbound (egress) network rules for a web server. This is a foundational step in micro-segmentation, ensuring only authorized traffic reaches specific application components.

The resource "aws_security_group" block creates this firewall. Within it, two ingress blocks specify allowed incoming connections: one permits HTTP traffic on port 80 from 0.0.0.0/0 (anywhere), essential for a public web server. The second ingress block demonstrates stricter control, allowing SSH on port 22 only from a specific IP address using a /32 CIDR block, limiting administrative access. A subtle but important detail for beginners is how the egress block operates: setting from_port = 0, to_port = 0, protocol = "-1", and cidr_blocks = ["0.0.0.0/0"] explicitly permits all outbound traffic. Without this explicit egress rule, AWS Security Groups would, by default, deny all outgoing connections, a key security behavior distinct from some traditional firewalls.

Related Articles

Hand-picked reads to go deeper on network security.

Back to Cloud Architect Roadmap