Networking, VPC Architecture, and Security in AWS

Introduction: The Virtual Network Perimeter

In traditional corporate IT environments, networking required physical routers, switches, patch panels, hardware firewalls, and leased lines. In AWS, the entire enterprise network is abstracted into software-defined infrastructure via Amazon Virtual Private Cloud (Amazon VPC). A VPC gives you complete control over your virtual networking environment, including resource placement, connectivity, security, and traffic routing.

Every enterprise architecture deployed in AWS rests within a VPC. Mastering CIDR IP block allocation, public versus private subnet segregation, internet routing via Internet Gateways and NAT Gateways, and multi-layered firewall filtering is the bedrock of secure cloud engineering. This module examines VPC architecture and defense-in-depth networking.

Core Concepts: Anatomy of an Amazon VPC

An Amazon VPC is a logically isolated virtual network dedicated to your AWS account within a single Region. The fundamental components of a production VPC include:

• CIDR Block (Classless Inter-Domain Routing): The private IPv4 address range assigned to the VPC (e.g., 10.0.0.0/16, providing 65,536 private IP addresses).
• Subnets: Logical subdivisions of the VPC’s IP block mapped to a specific Availability Zone. Subnets are partitioned into:
  • Public Subnets: Connected directly to the public internet via an Internet Gateway (IGW). Resources in public subnets (such as Application Load Balancers or Bastion Hosts) possess public IP addresses and can receive inbound internet traffic.
  • Private Subnets: Isolated from the public internet. Resources (such as database clusters, application servers, and microservices) receive only private IP addresses and are unreachable from the public internet.
• Route Tables: Sets of rules (routes) that dictate where network traffic from subnets is directed. A public subnet’s route table contains a default route (0.0.0.0/0) pointing to the Internet Gateway.

Deep Dive: Internet Egress for Private Subnets (NAT Gateway)

While database servers and backend microservices must remain hidden in private subnets, they frequently require outbound internet access to download software security updates, OS patches, or communicate with external third-party payment APIs. Directly attaching an Internet Gateway violates security boundaries.

The solution is an AWS Managed NAT Gateway:

1. The NAT Gateway is deployed inside a Public Subnet and assigned an immutable Elastic IP address.
2. The private subnet’s route table routes all external traffic (0.0.0.0/0) to the NAT Gateway.
3. The NAT Gateway translates the private source IP address into its public Elastic IP, forwards the request to the Internet Gateway, and routes the response back to the private instance. Inbound connection attempts originating from the internet are blocked.

Deep Dive: Network Defense-in-Depth (Security Groups vs. NACLs)

AWS provides two distinct firewall filtering mechanisms operating at different layers of the network stack:

Deep Dive: Transit Gateway and Hub-and-Spoke Enterprise Network Topologies

As organizations scale beyond a single AWS account, cloud network engineering evolves from simple single-VPC layouts into complex multi-account topologies. Connecting dozens of VPCs via standard VPC Peering requires a full mesh network where each connection is point-to-point ($N(N-1)/2$ connections), creating an unmanageable web of hundreds of peering links and route table rules.

To establish scalable enterprise network governance, AWS provides the AWS Transit Gateway (TGW):

• Hub-and-Spoke Architecture: The Transit Gateway acts as a central cloud router connecting thousands of VPCs, on-premises datacenters via AWS Direct Connect or AWS Site-to-Site VPN, and central egress inspection VPCs.
• Centralized Security Inspection: Organizations route all outbound internet traffic from member VPCs through a shared “Inspection VPC” hosting centralized Next-Generation Firewalls (NGFW) or AWS Network Firewall before egressing to the public internet via shared NAT Gateways.
• Route Domain Isolation: Utilizing multiple Transit Gateway route tables, engineers logically separate production, staging, and shared service environments, preventing unauthorized cross-environment lateral network movement.

Common Mistakes & Practical Pitfalls

• Directly Exposing Databases in Public Subnets: Placing relational databases (Amazon RDS) into public subnets with public IP addresses invites automated brute-force attacks and credential stuffing. Databases should always reside in isolated private subnets across multiple AZs.
• Overlooking Stateless NACL Ephemeral Ports: Because NACLs are stateless, creating an inbound allow rule for port 80/443 without creating an outbound allow rule for temporary ephemeral client ports (ports 1024–65535) prevents HTTP responses from returning to clients, causing connection timeouts.
• Overlapping CIDR Blocks in Peered VPCs: When interconnecting multiple VPCs via VPC Peering or AWS Transit Gateway, IP address ranges must not overlap. If VPC A and VPC B both use 10.0.0.0/16, routing between them is mathematically impossible.
• Single NAT Gateway in Multi-AZ Architectures: Routing traffic from private subnets across multiple AZs through a single NAT Gateway creates an inter-AZ dependency and a single point of failure. Highly resilient systems deploy one NAT Gateway per Availability Zone.

Exam Connection: Certification Blueprint Alignment

This module aligns directly with competencies evaluated on the AWS Cloud Practitioner Assessment:

• Contrasting stateful Security Groups with stateless Network Access Control Lists (NACLs).
• Understanding the functional purpose of Internet Gateways, NAT Gateways, and Route Tables.
• Differentiating between public and private cloud subnet designs.
• Evaluating perimeter threat protection services: AWS WAF (Layer 7 web exploits) and AWS Shield (Layer 3/4 DDoS protection).

Key Takeaways

• An Amazon VPC is a logically isolated virtual network defined by a private CIDR block within an AWS Region.
• Public subnets route 0.0.0.0/0 traffic to an Internet Gateway; private subnets use a NAT Gateway for outbound-only internet access.
• Security Groups operate at the instance level and are stateful; NACLs operate at the subnet boundary and are stateless.
• AWS Shield Standard provides automatic, zero-cost DDoS protection for all AWS customers.

Knowledge Check

1. If an EC2 instance in a private subnet must download operating system security updates from the internet without allowing inbound internet connections, which service must be deployed?
   Answer: An AWS Managed NAT Gateway deployed in a public subnet with a route pointing to an Internet Gateway.
2. You configure an inbound rule in a Security Group allowing TCP port 443. Do you need to create an outbound rule to allow the web server’s response to return to the client?
   Answer: No. Security Groups are stateful; return traffic is automatically permitted regardless of outbound rule configuration.
3. Which AWS security service specifically protects web applications against common web exploits such as SQL Injection and Cross-Site Scripting (XSS) at Layer 7?
   Answer: AWS WAF (Web Application Firewall).

Next Step in Curriculum

Congratulations! You have completed the AWS Cloud core curriculum. Test your overall cloud literacy in the AWS Cloud Practitioner Assessment.