-
Notifications
You must be signed in to change notification settings - Fork 0
KR_AWS_Architecture
IGW·NAT Gateway·CloudFront·ALB·RDS 등 주요 리소스가 아키텍처상 어디에 위치하는지(Global/Edge · Region · VPC · AZ · Subnet)와 Public/Private Zone을 왜 나누는지를, 면접에서 풀어 말하기 좋은 Q&A로 정리.
한 줄 답: 리소스마다 종속되는 범위(Scope)가 달라 Global/Edge → Region → VPC → AZ → Subnet 순으로 좁아지며, 어느 계층에 속하는지를 알면 장애 도메인과 HA 설계가 명확해진다.
바깥쪽일수록 넓은 범위를 담당하고, 안쪽으로 갈수록 단일 장애 도메인에 가까워진다.
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: 리전 외부, 전 세계 엣지에서 동작 — 특정 AZ·리전 장애와 무관
- Region: 하나의 리전 단위 — VPC가 여기에 속함
- VPC: 리전 내 격리된 가상 네트워크 — 여러 AZ에 걸쳐 있음
- Availability Zone (AZ): 물리적으로 분리된 데이터센터 묶음 — 서브넷·NAT GW가 종속
- Subnet: AZ 내 IP 대역 — EC2·RDS 등 실제 리소스가 배치
한 줄 답: AZ는 독립된 전원·냉각·네트워크를 가진 물리적으로 분리된 데이터센터 묶음이라, 한 AZ의 장애가 다른 AZ로 번지지 않는 단일 장애 도메인이다. 서브넷은 정확히 한 AZ에 속하므로 Multi-AZ = 서로 다른 AZ의 서브넷에 리소스를 분산하는 것이다.
- AZ는 하나의 리전 안에 물리적으로 분리된 1개 이상의 데이터센터 묶음이다. 각 AZ는 독립된 전원·냉각·물리 네트워크를 가진다.
- 같은 리전의 서로 다른 AZ는 물리적으로 떨어져 있어 한 AZ의 정전·화재·네트워크 장애가 다른 AZ로 번지지 않는다. 즉 AZ = 하나의 장애 도메인(Fault Domain) 이다.
- 동시에 AZ끼리는 저지연 전용 백본으로 연결되어 있어, 여러 AZ에 걸친 동기 복제(예: RDS Multi-AZ)가 실용적인 지연 시간 안에서 동작한다.
- 서브넷은 정확히 하나의 AZ에 속한다. 따라서 리소스를 여러 AZ에 분산하려면 AZ마다 서브넷을 따로 만들어야 한다. "Multi-AZ로 배포한다"는 말은 결국 서로 다른 AZ의 서브넷에 리소스를 나눠 배치한다는 뜻이다.
- 설계 원칙: 데이터센터 단위 장애를 견디려면 최소 2개 AZ(권장 3개) 에 워크로드를 분산한다.
한 줄 답: AWS에 "퍼블릭/프라이빗 서브넷"이라는 리소스 타입은 없다.
0.0.0.0/0 → IGW경로가 있으면 Public, 없으면 Private — 라우트 테이블로 우리가 부여하는 논리적 구분이다. 나누는 이유는 공격 표면 최소화·심층 방어·아웃바운드 통제·규정 준수다.
-
Public Subnet: 라우트 테이블에
0.0.0.0/0 → IGW경로가 있는 서브넷. 인터넷과 직접 양방향 통신이 가능하다. -
Private Subnet: 인터넷으로 직접 나가는 경로가 없는 서브넷. 아웃바운드가 필요하면
0.0.0.0/0 → NAT Gateway경로를 둔다. - 즉 IGW로 향하는 경로가 있으면 Public, 없으면 Private이다. 서브넷 자체의 속성이 아니라 우리가 어떤 경로를 넣느냐로 결정된다.
왜 굳이 나눌까? (구분의 의미)
- 공격 표면 최소화: DB·내부 워크로드를 인터넷에서 직접 도달할 수 없게 만든다. 외부에 노출되는 것은 진입점(Internet-facing ALB, Bastion)뿐이다.
- 심층 방어(Defense in Depth): 외부 진입점만 Public Zone에 두고, 실제 데이터·연산은 Private Zone에 격리한다. 진입점이 뚫려도 내부 자원까지 한 번에 노출되지 않는다.
- 아웃바운드 통제: Private 리소스의 외부 통신을 NAT Gateway 한 곳으로 모아, egress 경로·로그·고정 IP를 한 지점에서 통제한다.
- 규정 준수: "DB는 공인 IP 없이 운영" 같은 보안 기준을 구조적으로 강제할 수 있다.
그래서 NAT Gateway는 Public Zone에 산다. 사설 서브넷의 트래픽을 대신 인터넷으로 내보내는 역할이라, 자신은 IGW로 나가는 경로가 있는 Public Subnet에 위치해야 한다. 반대로 그 NAT를 사용하는 EC2·RDS는 Private Zone에 둔다.
Public Zone에는 무엇이 위치하는가 — 기준은 "인터넷에서 직접 도달해야 하거나, 사설 자원을 대신 인터넷으로 내보내는 역할" 이면 Public Zone이다.
- Internet-facing ALB / NLB: 외부 사용자의 요청을 가장 먼저 받는 진입점. 공인 IP로 노출되어야 하므로 Public에 둔다. 단, 실제 백엔드(EC2/EKS)는 Private에 두고 ALB만 앞단에 노출한다.
- NAT Gateway: 사설 서브넷의 아웃바운드를 대신 처리한다. 자신이 IGW로 나가는 경로를 가져야 하므로 Public에 위치한다.
- Bastion / Jump Host: 운영자가 SSH로 접속한 뒤 사설 자원으로 들어가기 위한 점프 호스트. 외부에서 접속 가능해야 하므로 Public에 둔다.
- (선택) 프록시 / VPN 엔드포인트 등: 외부와 직접 핸드셰이크가 필요한 게이트웨이성 리소스.
Private Zone에는 무엇이 위치하는가 — 기준은 "인터넷에서 직접 도달될 필요가 없는 실제 데이터·연산" 이면 Private Zone이다.
- EC2 / EKS Worker Node: 애플리케이션 워크로드. 외부 요청은 ALB를 통해서만 받고, 직접 노출하지 않는다.
- RDS / Aurora: 데이터베이스. 공인 IP로 절대 노출하지 않는 대표적 Private 리소스.
- ElastiCache (Redis/Memcached): 캐시 계층. VPC 내부에서만 접근.
- Internal ALB: VPC 내부 서비스 간(마이크로서비스) 통신용 진입점. 외부 노출이 없으므로 Private.
- Lambda(VPC 연결) · EFS · ENI 등: 내부 자원에 붙는 컴퓨팅·스토리지·네트워크 인터페이스.
한 줄 요약: "밖에서 들어와야 하는 것"과 "밖으로 내보내 주는 것"만 Public, 나머지 실제 알맹이는 전부 Private.
한 줄 답: Global(Route 53·CloudFront) → Region(VPC·S3·ACM) → VPC(IGW·Route Table) → AZ(Subnet·NAT GW) → Subnet(EC2·RDS) 순으로 종속되며, 진입점·NAT만 Public Subnet, 실제 워크로드·DB는 Private Subnet에 둔다.
범위가 넓은 것(Global)부터 좁은 것(Subnet) 순으로 정리한다.
| 리소스 | 적용 범위 | 위치(Zone) | 비고 |
|---|---|---|---|
| Route 53 | Global | 리전 외부 | DNS, 헬스체크·라우팅 정책 |
| CloudFront | Global (Edge) | 엣지 로케이션 | CDN, 오리진(S3/ALB) 앞단 캐싱·TLS 종료 |
| WAF | Global / Regional | CloudFront 또는 ALB에 연결 | L7 웹 방화벽 |
| ACM | Regional | 인증서 저장소 | ALB·CloudFront에 TLS 인증서 제공 |
| S3 | Regional | VPC 외부 | Gateway Endpoint로 사설 접근 가능 |
| ECR | Regional | VPC 외부 | Interface Endpoint로 사설 접근 |
| Secrets Manager / SSM | Regional | VPC 외부 | Interface Endpoint로 사설 접근 |
| EKS Control Plane | Regional (AWS 관리) | VPC 외부 (관리형) | API 서버 엔드포인트 제공 |
| VPC | Regional | 단일 리전, 여러 AZ에 걸침 | 격리된 가상 네트워크 |
| Internet Gateway (IGW) | VPC (Region) | VPC에 1개 연결 | AZ 종속 없음, 수평 확장·고가용성 |
| Transit Gateway | Regional | VPC 외부 (라우팅 허브) | 다중 VPC·온프레미스 연결 |
| VPN GW / Direct Connect | VPC / Region | VPC 경계 | 온프레미스 ↔ VPC 연결 |
| Route Table | VPC | 서브넷에 연결 | 트래픽 목적지(Next Hop) 결정 |
| VPC Gateway Endpoint | VPC (Route Table) | 라우트 테이블에 경로 추가 | S3·DynamoDB 사설 접근 |
| Subnet | AZ | 하나의 AZ에 종속 | Public / Private은 라우팅으로 결정 |
| NAT Gateway | AZ | Public Subnet | 사설 서브넷의 아웃바운드 전용 |
| Internet-facing ALB | 다중 AZ | Public Subnet | 외부 노출 진입점 (scheme=internet-facing) |
| Bastion Host | AZ | Public Subnet | 공인 IP 보유, 점프 호스트 |
| Internal ALB | 다중 AZ | Private Subnet | VPC 내부 진입점 (scheme=internal) |
| EC2 / EKS Node | AZ | Private Subnet | 워크로드 실행, 사설 IP |
| Auto Scaling Group | 다중 AZ | Private Subnet 분산 | AZ 간 인스턴스 균등 분산 |
| RDS | AZ | Private Subnet | Multi-AZ 시 Primary/Standby AZ 분리 |
| ElastiCache | AZ | Private Subnet | 캐시 계층 |
| EFS Mount Target | AZ | 각 AZ의 Subnet | AZ별 ENI 생성 |
| Lambda (VPC 연결) | AZ | Private Subnet | ENI 통해 VPC 리소스 접근 |
| VPC Interface Endpoint | AZ | Subnet (ENI) | PrivateLink, AWS 서비스 사설 접근 |
한 줄 답: IGW는 VPC 단위 양방향 게이트웨이(AZ 비종속·무료·인바운드 개시 허용), NAT Gateway는 Public Subnet에 위치한 사설 서브넷 아웃바운드 전용(AZ 종속·유료·EIP 필요)이다.
둘 다 인터넷과의 통신에 쓰이지만 방향과 위치가 다르다.
| 항목 | Internet Gateway (IGW) | NAT Gateway |
|---|---|---|
| 목적 | 인터넷 양방향(인바운드 + 아웃바운드) | 사설 서브넷의 아웃바운드 전용 |
| 위치 | VPC에 연결 (AZ 비종속) | Public Subnet 내부 (AZ 종속) |
| 인바운드 개시 | 허용 (공인 IP 대상) | 불가 (응답 트래픽만 통과) |
| 고가용성 | 자체적으로 다중 AZ·수평 확장 | AZ별로 직접 배치해야 HA 확보 |
| 비용 | 무료 | 시간당 + 데이터 처리 요금 |
| IP | 별도 IP 없음 | 고정 EIP 필요 |
인바운드 (외부 → 앱)
User → Route 53 (DNS) → CloudFront (엣지 캐싱·TLS) → IGW
→ Internet-facing ALB (Public Subnet) → Target (EC2/EKS, Private Subnet)
아웃바운드 (사설 앱 → 외부)
EC2/EKS (Private Subnet) → Route Table (0.0.0.0/0 → NAT)
→ NAT Gateway (Public Subnet) → IGW → Internet
한 줄 답: AZ 종속 리소스(Subnet·NAT GW·RDS)는 AZ마다 중복 배치하고, ALB는 다중 AZ 서브넷에 등록해 교차 AZ 분산을, RDS는 Multi-AZ로 자동 Failover를 구성한다. IGW·CloudFront·Route 53은 리전/Global 고가용성이라 AZ별 중복이 불필요하다.
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
위 그림에서 존(Zone) 구분은 색이나 리소스 타입이 아니라 라우팅으로 정해진다. Public Subnet은 IGW로 나가는 경로가 있어 ALB·NAT GW가 위치하고, Private Subnet은 그 경로가 없어 EC2·RDS가 NAT GW를 거쳐서만 밖으로 나간다.
설계 포인트
- Subnet · NAT Gateway는 AZ 종속 → 각 AZ에 Public/Private 서브넷과 NAT Gateway를 각각 배치해 단일 AZ 장애에 대비한다.
- ALB는 다중 AZ 서브넷에 등록하면 자동으로 교차 AZ 부하 분산이 이루어진다.
- RDS는 Multi-AZ로 Primary/Standby를 서로 다른 AZ에 두어 자동 장애 조치(Failover)를 구성한다.
- IGW는 리전 단위 고가용성이라 AZ별 중복 배치가 필요 없다.
- CloudFront · Route 53은 Global 서비스라 특정 리전·AZ 장애와 무관하게 동작한다.