VPC (Virtual Private Cloud)

Its a isolated virtual network inside AWS(like a private datacenter LAN in the cloud)
VPC's can be created across AZ's
Every machine/resource is provided a IP address, subnets, routing tables, ACL, security groups can be created
Every AWS resource that handles traffic (eg: EC2, ECS, EKS, RDS, ELB) lives inside a VPC. If networking is wrong inside that VPC, ELB cannot reach your containers even though both exist in AWS.

How VPC maps to networking concepts

VPC component	Traditional networking analogy	Role
VPC	Private campus / datacenter network	Isolated address space, e.g. `10.0.0.0/16`
Subnet	VLAN / network segment	Slice of VPC IP range per Availability Zone (public or private)
Internet Gateway (IGW)	Datacenter border router to the internet	VPC attachment point for public internet traffic (see below)
Route table	Router routing table	Public subnet: `0.0.0.0/0 → IGW`; private: `→ NAT`
NAT Gateway	Outbound-only NAT	Private subnets reach internet without accepting inbound
Security group	Stateful host firewall	e.g. allow ALB → container on port 8080
Elastic IP / ENI	Static IP / NIC	IP address attached to an instance or load balancer node

What is the Internet Gateway (IGW)?

The Internet Gateway is not a global load balancer and not something the client connects to by name. It is an AWS-managed component attached to your VPC at the edge of that VPC inside an AWS region (yes — inside AWS’s network, at the border of your virtual network).

What it does: Allows traffic between the public internet and resources in your VPC that have public IPs (e.g. internet-facing ALB in a public subnet). Public subnet route tables send 0.0.0.0/0 to the IGW.

What it is not: Route 53, Global Accelerator, API Gateway, or ELB. Those are separate services. IGW is only the VPC front door for internet ↔ public subnet routing.

Where Route 53, global LB, API Gateway, and ELB sit

Service	Inside VPC?	Role in HTTP path
Route 53	No — global DNS	Resolves `api.example.com` to ALB, API Gateway, or Global Accelerator
Global Accelerator / CloudFront	No — global/edge	Optional; sends user to nearest healthy regional endpoint
API Gateway	No (regional AWS service); uses VPC Link ENIs to reach private VPC	Optional; before ALB when you need API keys, throttling, auth
Internet Gateway	Attached to VPC boundary (not in a subnet)	Path for internet traffic into/out of public subnets
ELB / ALB	Yes — ENIs in your public (or internal) subnets	Regional load balancer; distributes to targets in VPC
EKS pods / EC2	Yes — usually private subnets	Application containers

Load balancing vs API Gateway order:
• Web app (typical): Client → Route 53 → ALB → pods (no API Gateway).
• Managed public API: Client → Route 53 → API Gateway → ALB → pods.
API Gateway is before ALB when both are used. ELB is always inside the VPC; API Gateway sits outside and forwards in.

Example scenario — App Server in VPC

A company runs a containerized App Server on EKS in us-east-1
Create VPC 10.0.0.0/16 with two AZs for high availability.
Public subnets (10.0.1.0/24, 10.0.2.0/24) — ALB and NAT Gateway; route table points 0.0.0.0/0 to IGW.
Private subnets (10.0.10.0/24, 10.0.11.0/24) — EKS worker nodes and pods; route table points 0.0.0.0/0 to NAT (outbound only).
RDS in private subnets — reachable from app security group only, not from the internet.
Client → Route 53 → ALB (public subnet) → Ingress → pods (private subnet).
Without this layout, you either expose containers directly to the internet (unsafe) or have no path for the load balancer to forward traffic to private workloads.

Block diagram — client HTTP request into VPC

Outside → inside: client on the internet, optional global/regional services, then IGW as VPC border, then ALB and private workloads.

flowchart TB
    Client[Client on public internet]

    R53[Route 53 — global DNS]
    GA[Global Accelerator — optional global LB]
    APIGW[API Gateway — optional, before ALB]

    subgraph VPC["Your VPC (inside AWS region)"]
        IGW[Internet Gateway — VPC door to internet]
        ALB[ALB / ELB — regional LB in public subnet]
        Pod[Containers in private subnet]
    end

    Client -->|1 lookup| R53
    Client -->|2 HTTP request| GA
    GA --> APIGW
    APIGW -->|3a API path| ALB
    Client -->|2 alt web app| IGW
    GA -.->|skip API GW| IGW
    IGW -->|3b enters VPC| ALB
    ALB -->|4 forward| Pod

Read top to bottom:
1. Route 53 (global DNS) tells the client where to send the request.
2. Global Accelerator (optional) picks the nearest region.
3. API Gateway (optional) sits before ALB for API management.
4. Request crosses the public internet into the AWS region.
5. Internet Gateway is the VPC’s door — traffic enters public subnets.
6. ALB (inside VPC) load-balances to containers in private subnets.

Sequence diagram — same HTTP request step by step

sequenceDiagram
    participant Client as Client (internet)
    participant R53 as Route 53
    participant APIGW as API Gateway (optional)
    participant IGW as Internet Gateway (VPC border)
    participant ALB as ALB (VPC public subnet)
    participant Pod as Pod (VPC private subnet)

    Client->>R53: Resolve api.example.com
    R53-->>Client: ALB or API Gateway hostname

    alt Public API with API Gateway
        Client->>APIGW: HTTPS POST /orders
        APIGW->>APIGW: Auth, throttle, validate
        APIGW->>ALB: Forward to backend (VPC Link / HTTP)
    else Web app — direct to ALB
        Client->>IGW: HTTPS over internet toward ALB address
        Note over IGW: IGW routes into VPC
client does not connect to IGW by name
        IGW->>ALB: Deliver to ALB network interface
    end

    ALB->>ALB: Pick healthy target in target group
    ALB->>Pod: HTTP to private IP 10.0.10.5:8080
    Pod-->>ALB: 200 OK
    ALB-->>Client: 200 OK (via same path back)

Note: In the sequence, IGW appears only on the direct-to-ALB path — it is the routing point where internet traffic enters the VPC. API Gateway traffic also eventually reaches ALB inside the VPC (often via VPC Link ENIs in your subnets).