Networking & Connectivity

1. VPC Design (Subnets, Routing, NAT, IGW, TGW)

A scalable Virtual Private Cloud (VPC) design relies on a multi-AZ, segregated architecture that prioritizes high availability and strict traffic isolation.

Subnet Segmentation

• Public Subnets: Contain Internet Gateways (IGWs) and Elastic Load Balancers (ALBs) or NAT Gateways. Never place EC2 instances or databases here unless they absolutely require direct public IPs.

• Private App Subnets: House your application servers, containers, and internal microservices. They route out to the internet via NAT Gateways.

• Isolated Data Subnets: Dedicated to databases (RDS, DynamoDB endpoints) and cache layers (Elasticache). No routes to the internet or NAT Gateways are allowed here for maximum security.

Routing & Internet Egress

• Internet Gateway (IGW): Horizontally scaled, redundant VPC component that allows communication between instances in your VPC and the internet.

• NAT Gateway: Managed Network Address Translation service. For high availability, deploy one NAT Gateway per Availability Zone (AZ) in the public subnets. This prevents a cross-AZ dependency and reduces cross-AZ data transfer costs.

Transit Gateway (TGW)

As your footprint grows beyond a few VPCs, a hub-and-spoke model using AWS Transit Gateway is critical.

• Acts as a cloud router, connecting multiple VPCs, AWS accounts, and on-premises networks.

• Route Tables: Use separate TGW route tables for segregation (e.g., a Prod-TGW-RT, a NonProd-TGW-RT, and a Core-Services-RT) to control which VPCs can talk to one another.

2. Hybrid Connectivity (Direct Connect, VPN, SD-WAN)

Connecting your on-premises data centers or branch offices to AWS requires a mix of reliability, speed, and cost-efficiency.

Architectural Best Practice

For production, use Direct Connect as your primary path and an AWS Site-to-Site VPN as a cost-effective failover path. Both should terminate on your Transit Gateway (TGW) to scale connectivity across all spoke VPCs effortlessly.

3. Load Balancing (ALB, NLB, GWLB)

AWS provides specialized Elastic Load Balancers tailored to different layers of the OSI model.

                  [ Traffic Egress / Ingress ]
                               |
        -----------------------------------------------
       |                       |                       |
   [ Layer 7 ]            [ Layer 4 ]             [ Layer 3 ]
       ALB                    NLB                    GWLB
  (HTTP/HTTPS,           (TCP/UDP, Static IPs,   (Third-Party Firewalls,
  Path/Host Routing)      Ultra-low Latency)      Inline Inspection)

Application Load Balancer (ALB) — Layer 7

• Best for: HTTP and HTTPS traffic, microservices, and containerized applications.

• Key Features: Advanced routing rules (based on URL paths, hostnames, HTTP headers, and query parameters), AWS WAF integration, and SSL/TLS termination.

Network Load Balancer (NLB) — Layer 4

• Best for: TCP, UDP, and TLS traffic where ultra-high performance and low latency are required.

• Key Features: Ability to handle millions of requests per second, preserves client-side source IP, and provides static/Elastic IP addresses per AZ (crucial for IP whitelisting).

Gateway Load Balancer (GWLB) — Layer 3

• Best for: Deploying, scaling, and managing third-party virtual appliances (firewalls, IDS/IPS, deep packet inspection).

• Key Features: Acts as a single entry and exit point for all traffic, transparently routing packets to a fleet of firewalls before forwarding them to the destination.

4. PrivateLink and VPC Endpoints

To keep traffic off the public internet when consuming services, use AWS PrivateLink. This reduces data exposure and improves security posture.

• Gateway Endpoints: Used exclusively for Amazon S3 and DynamoDB. They are completely free and work by modifying your subnet route tables. Always implement these first.

• Interface Endpoints (AWS PrivateLink): Powered by NLBs, these place an Elastic Network Interface (ENI) with a private IP directly into your subnet. Used for almost all other AWS services (e.g., EC2 APIs, Systems Manager, Kinesis) and third-party SaaS applications.

• VPC Endpoint Policies: Don’t just open endpoints up. Attach IAM-like policies to your endpoints to restrict access (e.g., “Only allow access to S3 buckets owned by our AWS Organization”).

5. IPv6 Adoption Strategy

With IPv4 addresses becoming increasingly scarce and expensive, transition strategies to dual-stack or IPv6-only environments are becoming mandatory.

Phased Migration Strategy

1. Phase 1: Dual-Stack VPCs & Subnets: Modify existing VPCs to support both IPv4 and IPv6 CIDR blocks. This allows seamless communication with legacy systems while enabling IPv6 testing.

2. Phase 2: IPv6-Only Private Subnets: Spin up new microservices or container tasks (like Amazon EKS) in IPv6-only subnets to preserve precious private IPv4 space.

3. Phase 3: Egress-Only Internet Gateways: Replace NAT Gateways for IPv6 workloads. An Egress-Only IGW allows your private IPv6 instances to initiate outbound connections to the internet but prevents the internet from initiating connections back to them. Bonus: Egress-Only IGWs are entirely free.

6. Network Security Architecture

A defense-in-depth approach ensures that a breach at one layer doesn’t compromise your entire network infrastructure.

Layered Controls

• Edge Security: Deploy AWS WAF (Web Application Firewall) on your ALBs to block SQL injection and cross-site scripting (XSS). Use AWS Shield for managed DDoS protection.

• Network Access Control Lists (NACLs): Stateless firewalls acting at the subnet boundary. Use them as a blunt instrument for broad rules (e.g., blocking known malicious IP blocks).

• Security Groups: Stateful firewalls acting at the resource/instance interface level. Follow the principle of least privilege—never open 0.0.0.0/0 unless it is a public load balancer port.

• Centralized Inspection (East-West / North-South): Use AWS Transit Gateway paired with Gateway Load Balancers (GWLB) to funnel all traffic moving between VPCs (East-West) or going to/from the internet (North-South) through a central “Inspection VPC” packed with next-generation firewalls (NGFW).

Architectural Tip: Enable VPC Flow Logs across your entire organization and stream them to a centralized S3 bucket or CloudWatch Logs log group. You cannot protect what you cannot observe; flow logs are essential for post-incident forensics and anomaly detection.

Which specific pillar of this architecture are you planning to implement first, or are you looking to optimize an existing environment?