-
Notifications
You must be signed in to change notification settings - Fork 0
EN_AWS_Architecture
Where key resources — IGW, NAT Gateway, CloudFront, ALB, RDS — sit architecturally (Global/Edge · Region · VPC · AZ · Subnet), and why we split a VPC into Public and Private zones, written as interview-style Q&A.
One-line answer: Each resource is bound to a different scope, narrowing from Global/Edge → Region → VPC → AZ → Subnet. Knowing which layer a resource belongs to makes the fault domain and HA design clear.
The outer layers cover a broader scope; the inner layers get closer to a single fault domain.
flowchart TB
G["Global / Edge<br/>Route 53 · CloudFront · WAF"]
R["Region<br/>VPC · S3 · ACM"]
V["VPC<br/>Internet Gateway · Route Table"]
A["Availability Zone<br/>Subnet · NAT Gateway"]
S["Subnet<br/>EC2 · RDS · ENI"]
G --> R --> V --> A --> S
- Global / Edge: Outside the region, running at edge locations worldwide — unaffected by any single AZ/region failure
- Region: A single region — the VPC belongs here
- VPC: An isolated virtual network within a region — spans multiple AZs
- Availability Zone (AZ): A group of physically isolated data centers — subnets and NAT GWs are bound here
- Subnet: An IP range within an AZ — where actual resources like EC2 and RDS are placed
One-line answer: An AZ is a group of physically isolated data centers with independent power, cooling, and networking, so a failure in one AZ does not spread to another — it is a single fault domain. Since a subnet belongs to exactly one AZ, Multi-AZ means distributing resources across subnets in different AZs.
- An AZ is a group of one or more physically isolated data centers within a region. Each AZ has independent power, cooling, and physical networking.
- Different AZs in the same region are physically separated, so a power outage, fire, or network failure in one AZ does not spread to another. In other words, an AZ is a single fault domain.
- At the same time, AZs are connected by a low-latency dedicated backbone, so synchronous replication across AZs (e.g. RDS Multi-AZ) works within a practical latency budget.
- A subnet belongs to exactly one AZ. So to spread resources across multiple AZs, you must create a separate subnet per AZ. "Deploying Multi-AZ" ultimately means distributing resources across subnets in different AZs.
- Design principle: to survive a data-center-level failure, spread workloads across at least 2 AZs (3 recommended).
One-line answer: AWS has no "public/private subnet" resource type. A
0.0.0.0/0 → IGWroute makes it Public; the absence of one makes it Private — a logical split WE impose via the route table. We split it to minimize the attack surface, apply defense in depth, control outbound, and enforce compliance.
-
Public Subnet: A subnet whose route table has a
0.0.0.0/0 → IGWroute. It can communicate directly with the internet in both directions. -
Private Subnet: A subnet with no direct route out to the internet. If outbound is needed, you add a
0.0.0.0/0 → NAT Gatewayroute. - So a route toward the IGW makes it Public; the absence of one makes it Private. It is decided not by an intrinsic subnet property but by which route we add.
So why bother splitting? (the meaning of the split)
- Minimize the attack surface: Make databases and internal workloads unreachable directly from the internet. Only the entry points (internet-facing ALB, bastion) are exposed.
- Defense in depth: Keep only the entry points in the Public Zone, and isolate the actual data and compute in the Private Zone. Even if an entry point is breached, the internal resources are not exposed all at once.
- Outbound control: Funnel the private resources' outbound traffic through a single NAT Gateway, so the egress path, logs, and fixed IP are controlled at one point.
- Compliance: Structurally enforce security baselines like "run databases without a public IP."
That is why the NAT Gateway lives in the Public Zone. Its job is to send private subnets' traffic out to the internet on their behalf, so it must sit in a Public Subnet that has a route to the IGW. Conversely, the EC2/RDS that use that NAT go in the Private Zone.
What lives in the Public Zone? — The rule is simple: if a resource "must be reachable directly from the internet, or sends private resources' traffic out to the internet on their behalf," it belongs in the Public Zone.
- Internet-facing ALB / NLB: The entry point that first receives external user requests. It must be exposed via a public IP, so it goes in the Public Zone. The actual backends (EC2/EKS) stay Private — only the ALB is exposed in front.
- NAT Gateway: Handles private subnets' outbound traffic on their behalf. Because it must itself have a route out to the IGW, it sits in the Public Zone.
- Bastion / Jump Host: A jump host that operators SSH into before reaching private resources. It must be reachable externally, so it goes in the Public Zone.
- (Optional) Proxies / VPN endpoints, etc.: Gateway-type resources that need a direct handshake with the outside.
What lives in the Private Zone? — The rule: if a resource is "the actual data or compute that does not need to be reached directly from the internet," it belongs in the Private Zone.
- EC2 / EKS Worker Node: Application workloads. They receive external requests only through the ALB and are never exposed directly.
- RDS / Aurora: Databases — the canonical Private resource, never exposed via a public IP.
- ElastiCache (Redis/Memcached): The cache layer, accessed only from within the VPC.
- Internal ALB: The entry point for internal (microservice-to-microservice) communication within the VPC. With no external exposure, it is Private.
- Lambda (VPC-attached) · EFS · ENI, etc.: Compute/storage/network interfaces attached to internal resources.
One-line summary: only "what must come in" and "what sends things out" are Public; all the actual substance is Private.
One-line answer: Resources bind from Global (Route 53·CloudFront) → Region (VPC·S3·ACM) → VPC (IGW·Route Table) → AZ (Subnet·NAT GW) → Subnet (EC2·RDS); only entry points and NAT go in Public Subnets, while actual workloads and databases go in Private Subnets.
Ordered from the broadest scope (Global) down to the narrowest (Subnet).
| Resource | Scope | Location (Zone) | Notes |
|---|---|---|---|
| Route 53 | Global | Outside the region | DNS, health checks, routing policies |
| CloudFront | Global (Edge) | Edge location | CDN; caching and TLS termination in front of the origin (S3/ALB) |
| WAF | Global / Regional | Attached to CloudFront or ALB | L7 web firewall |
| ACM | Regional | Certificate store | Provides TLS certs to ALB/CloudFront |
| S3 | Regional | Outside the VPC | Private access via Gateway Endpoint |
| ECR | Regional | Outside the VPC | Private access via Interface Endpoint |
| Secrets Manager / SSM | Regional | Outside the VPC | Private access via Interface Endpoint |
| EKS Control Plane | Regional (AWS-managed) | Outside the VPC (managed) | Provides the API server endpoint |
| VPC | Regional | Single region, spans multiple AZs | Isolated virtual network |
| Internet Gateway (IGW) | VPC (Region) | One per VPC | No AZ binding; horizontally scaled and highly available |
| Transit Gateway | Regional | Outside the VPC (routing hub) | Connects multiple VPCs / on-premises |
| VPN GW / Direct Connect | VPC / Region | VPC boundary | Connects on-premises ↔ VPC |
| Route Table | VPC | Attached to subnets | Determines the traffic destination (next hop) |
| VPC Gateway Endpoint | VPC (Route Table) | Adds a route to the route table | Private access to S3/DynamoDB |
| Subnet | AZ | Bound to one AZ | Public/Private decided by routing |
| NAT Gateway | AZ | Public Subnet | Outbound-only for private subnets |
| Internet-facing ALB | Multi-AZ | Public Subnet | External-facing entry point (scheme=internet-facing) |
| Bastion Host | AZ | Public Subnet | Has a public IP; jump host |
| Internal ALB | Multi-AZ | Private Subnet | Internal VPC entry point (scheme=internal) |
| EC2 / EKS Node | AZ | Private Subnet | Runs workloads; private IP |
| Auto Scaling Group | Multi-AZ | Spread across Private Subnets | Balances instances evenly across AZs |
| RDS | AZ | Private Subnet | Multi-AZ splits Primary/Standby across AZs |
| ElastiCache | AZ | Private Subnet | Cache layer |
| EFS Mount Target | AZ | Subnet in each AZ | Creates an ENI per AZ |
| Lambda (VPC-attached) | AZ | Private Subnet | Accesses VPC resources via an ENI |
| VPC Interface Endpoint | AZ | Subnet (ENI) | PrivateLink; private access to AWS services |
One-line answer: The IGW is a VPC-level bidirectional gateway (no AZ binding, free, allows inbound initiation); the NAT Gateway is outbound-only for private subnets, sits in a Public Subnet (AZ-bound, paid, requires an EIP).
Both are used for internet communication, but their direction and location differ.
| Aspect | Internet Gateway (IGW) | NAT Gateway |
|---|---|---|
| Purpose | Bidirectional internet (inbound + outbound) | Outbound-only for private subnets |
| Location | Attached to the VPC (no AZ binding) | Inside a Public Subnet (AZ-bound) |
| Inbound initiation | Allowed (toward public IPs) | Not allowed (response traffic only) |
| High availability | Inherently multi-AZ / horizontally scaled | Must be placed per AZ for HA |
| Cost | Free | Hourly + data processing charges |
| IP | No separate IP | Requires a fixed EIP |
Inbound (external → app)
User → Route 53 (DNS) → CloudFront (edge caching/TLS) → IGW
→ Internet-facing ALB (Public Subnet) → Target (EC2/EKS, Private Subnet)
Outbound (private app → external)
EC2/EKS (Private Subnet) → Route Table (0.0.0.0/0 → NAT)
→ NAT Gateway (Public Subnet) → IGW → Internet
One-line answer: Duplicate AZ-bound resources (Subnet·NAT GW·RDS) in every AZ, register the ALB across multi-AZ subnets for cross-AZ balancing, and use RDS Multi-AZ for automatic failover. The IGW, CloudFront, and Route 53 are region/Global-level HA, so they need no per-AZ redundancy.
flowchart TB
User(["User / Internet"])
R53["Route 53<br/>(Global DNS)"]
CF["CloudFront<br/>(Edge Location)"]
User --> R53 --> CF
subgraph Region["Region (e.g. ap-northeast-2)"]
subgraph VPC ["VPC (10.0.0.0/16)"]
IGW((("Internet Gateway")))
CF --> IGW
subgraph AZ_A ["AZ-a"]
subgraph PubA ["Public Subnet (10.0.0.0/24)"]
ALBA["Internet-facing ALB"]
NATA["NAT Gateway"]
end
subgraph PrivA ["Private Subnet (10.0.10.0/24)"]
EC2A(["EC2 / EKS Node"])
RDSA[("RDS Primary")]
end
end
subgraph AZ_C ["AZ-c"]
subgraph PubC ["Public Subnet (10.0.1.0/24)"]
ALBC["Internet-facing ALB"]
NATC["NAT Gateway"]
end
subgraph PrivC ["Private Subnet (10.0.11.0/24)"]
EC2C(["EC2 / EKS Node"])
RDSC[("RDS Standby")]
end
end
IGW --> ALBA
IGW --> ALBC
ALBA --> EC2A
ALBC --> EC2C
EC2A -. outbound .-> NATA -.-> IGW
EC2C -. outbound .-> NATC -.-> IGW
RDSA <-. Multi-AZ replication .-> RDSC
end
end
In the diagram above, the zone distinction is defined by routing — not by color or resource type. The Public Subnet has a route out to the IGW, so the ALB and NAT GW sit there; the Private Subnet has no such route, so EC2 and RDS only reach the outside through the NAT GW.
Design points
- Subnets and NAT Gateways are AZ-bound → place a Public/Private subnet and a NAT Gateway in each AZ to withstand a single-AZ failure.
- Register the ALB across multi-AZ subnets and it automatically load-balances across AZs.
- Use RDS Multi-AZ to keep Primary/Standby in different AZs for automatic failover.
- The IGW is region-level highly available, so no per-AZ redundancy is needed.
- CloudFront and Route 53 are Global services, so they operate regardless of a specific region/AZ failure.