AWS SAA-C03 출제 비중이 가장 높은 네트워킹·DNS 영역을 회사 사옥 비유로 풀어쓴 스터디 노트 6편. VPC가 사설 망, 서브넷이 층, IGW가 정문이라는 비유부터 시작해서 NAT Gateway vs NAT Instance, SG vs NACL, VPC Peering·Transit Gateway·PrivateLink, VPN vs Direct Connect, Network Firewall, Route 53 라우팅 7종, CloudFront vs Global Accelerator, 비용 최적화까지 — 처음 보는 사람도 따라갈 수 있게 시험 함정 위주로 친절하게 정리.
이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 여섯 번째 편입니다. 네트워킹은 SAA에서 출제 비중이 가장 높은 영역 중 하나인데, 처음 들으면 정말 어렵습니다. VPC, CIDR, 서브넷, IGW, NAT, SG, NACL, VPC Peering, Transit Gateway, PrivateLink, Direct Connect… 단어가 끝없이 쏟아져요.
왜 어렵게 느껴질까요? 물리적 실체가 없는 가상 네트워크라서 머릿속에 그림이 잘 안 그려지고, 비슷해 보이는 서비스가 너무 많아서(SG와 NACL? VPC Peering과 Transit Gateway? CloudFront와 Global Accelerator?) 답을 고르기가 어렵기 때문이에요.
이 글은 그 그림을 회사 사옥 비유로 풀어 갑니다. VPC = 회사 사옥의 사설 망, 서브넷 = 사옥의 층, IGW = 정문, NAT Gateway = 직원 전용 외부 통화선, Bastion Host = 외부 손님 안내 데스크. 한 번 비유로 머리에 들어가면 시험 보기 4개에서 답이 보입니다. 한 번에 다 외우려 하지 말고 흐름과 비유만 머리에 새기시면 돼요.
VPC가 뭔가요 — 회사 사옥의 사설 망
VPC(Virtual Private Cloud) 는 AWS 안에 내가 빌려 만든 사설 네트워크입니다. 회사로 치면 우리 회사 전용 사옥의 사설 망이에요. 같은 건물(AWS) 안에 다른 회사도 있지만 우리 망은 우리만 씁니다. 더 깊게 파고 싶을 때는 VPC 공식 사용자 가이드가 가장 정리가 잘 돼 있어요.
여기서 가장 먼저 짚어둘 게 CIDR(Classless Inter-Domain Routing) 입니다. "이 사설 망에서 IP를 몇 개나 쓸 거냐" 를 정하는 표기법이에요.
/32= IP 1개,/24= 256개,/16= 65,536개,/0= 전체- VPC는 최소
/28(16 IP) ~ 최대/16(65,536 IP) 범위만 가능
서브넷 — 사옥의 층
서브넷(Subnet) 은 VPC 안을 쪼갠 단위로, 사옥의 층에 해당합니다. 두 종류로 갈려요.
- 퍼블릭 서브넷 — 정문(IGW)으로 인터넷과 직접 연결. 1층 로비
- 프라이빗 서브넷 — 인터넷 직접 연결 X. 내부 직원만 다니는 층
여기서 시험 함정 — AWS는 서브넷마다 5개 IP를 자동 예약합니다. /24(256개) 서브넷이어도 실제 사용 가능한 IP는 251개. 10.0.0.0/24라면 — .0(네트워크), .1(VPC 라우터), .2(DNS), .3(미래 예약), .255(브로드캐스트). "/24에서 사용 가능한 IP 개수?" 물으면 답은 무조건 251.
VPC의 IGW와 NAT — 정문과 외부 통화선
Internet Gateway(IGW) 는 VPC와 인터넷을 연결하는 정문입니다. VPC당 1개만 연결 가능(1:1), 관리형이라 HA·확장 자동. 퍼블릭 서브넷 라우팅 테이블에 0.0.0.0/0 → IGW 경로 추가하면 인터넷 양방향 통신.
프라이빗 서브넷은 IGW가 없는 대신 NAT를 거쳐 아웃바운드만 허용합니다. 내부 직원이 외부에 전화는 걸지만 외부에서 직접 못 들어오는 일방향 통화선이에요. NAT는 두 종류:
| 항목 | NAT Gateway | NAT Instance |
|---|---|---|
| 관리 주체 | AWS 완전 관리형 | 사용자 직접 관리 |
| 위치 | 퍼블릭 서브넷 | 퍼블릭 서브넷 |
| EIP | 필요 | 필요 |
| 보안 그룹 | 불필요 | 필요 |
| 대역폭 | 최대 100 Gbps (자동 확장) | 인스턴스 유형에 따라 제한 |
| HA | AZ 단위, 여러 AZ에 각각 배포 필요 | 직접 구성 필요 |
| 비용 | 시간당 + 데이터 처리 요금 | 인스턴스 비용 |
| Src/Dst Check | 해당 없음 | 반드시 비활성화 필요 |
| Bastion Host | 불가 | 가능 |
| IPv6 | 미지원 (IPv6는 EIGW 사용) | 지원 가능 |
여기서 시험 함정 두 개. 첫째, NAT Instance는 Src/Dst Check를 반드시 비활성화해야 합니다. EC2는 기본적으로 자기 IP 아닌 패킷을 떨어뜨리는데, NAT는 남의 패킷을 대신 전달해야 하니까요. 둘째, NAT Gateway는 AZ 단위라서 HA를 원하면 AZ별로 별도 배포 필요.
키워드 매칭 — "관리 오버헤드 최소화 + IPv4 아웃바운드" → NAT Gateway / "비용 절감 + Bastion 겸용" → NAT Instance.
Egress-Only Internet Gateway(EIGW) 는 IPv6 전용 NAT Gateway. NAT Gateway가 IPv6 미지원이라 IPv6 아웃바운드는 EIGW로 처리해요. 라우팅 테이블에 ::/0 → EIGW 추가, VPC 자체에 연결(특정 서브넷 배치 X).
VPC 라우팅 테이블과 Bastion Host
라우팅 테이블은 "이 IP로 가려면 이 출구로" 안내하는 표예요. 서브넷당 1개 연결, 메인 + 사용자 정의 가능. 가장 구체적인 경로(Longest Prefix Match) 우선 — 10.0.0.0/16과 10.0.1.0/24가 같이 있으면 /24가 이깁니다.
프라이빗 서브넷 EC2에 SSH 접근하려면 Bastion Host(점프 서버)를 거칩니다. 외부 손님 안내 데스크예요.
- 위치: 퍼블릭 서브넷
- Bastion SG: 신뢰 IP만 SSH(22) 허용
- 프라이빗 인스턴스 SG: Bastion SG를 소스로 참조
- NAT Instance는 Bastion 겸용 가능, NAT Gateway는 불가 (관리형이라 SSH 접속 X)
Security Group vs NACL — 시험 단골 비교
이 둘이 시험에서 정말 많이 헷갈려요. 비유부터 잡고 갑시다.
- Security Group(SG) — 인스턴스 경비원. 각 객실(EC2) 문 앞에 서서 누가 들어올지 본다
- NACL(Network ACL) — 층 출입문 검색대. 한 층(서브넷)에 들어오는 사람을 일괄 검사
| 항목 | Security Group (보안 그룹) | NACL |
|---|---|---|
| 적용 범위 | 인스턴스(ENI) 레벨 | 서브넷 레벨 |
| 상태 | Stateful (응답 자동 허용) | Stateless (인/아웃 각각 설정) |
| 규칙 유형 | 허용(Allow) 규칙만 | 허용 + 차단(Deny) 모두 가능 |
| 규칙 평가 | 모든 규칙 평가 | 번호 순서대로 (낮은 번호 우선) |
| 기본 동작 | 모든 인바운드 차단 / 아웃바운드 허용 | 기본 NACL은 전체 허용 |
| 임시 포트 | 자동 처리 | 아웃바운드에 Ephemeral Port 범위 설정 필요 (1024-65535) |
여기서 시험 함정이 정말 많아요. 압축해서 셋만 짚을게요.
첫째, "특정 IP 차단" 시나리오의 답은 무조건 NACL입니다. SG는 Allow 규칙만 있어요. Deny 규칙이 아예 없습니다. 회사 비유로 치면 — 객실 경비원은 "들여보내라"는 명단만 받지 "막아라"는 명단을 못 받아요. 누군가를 명시적으로 막으려면 층 출입문 검색대(NACL)에서 막아야 합니다.
둘째, Stateful vs Stateless의 차이가 결정적입니다. SG는 Stateful이라서 인바운드만 허용하면 그에 대한 응답은 자동으로 나갈 수 있어요. NACL은 Stateless라서 인바운드 허용해도 그 응답이 나가는 아웃바운드 규칙을 따로 만들어야 합니다. 임시 포트(Ephemeral Port, 1024-65535) 를 아웃바운드에 열어두지 않으면 응답이 못 나가서 통신이 끊겨요.
셋째, Flow Logs 트러블슈팅 함정이에요. 인바운드 ACCEPT인데 아웃바운드 REJECT가 보이면? NACL 아웃바운드 규칙 누락이 답입니다. SG는 Stateful이라 이런 패턴이 안 나와요. 이 패턴이 나오면 무조건 NACL 의심.
특정 IP 차단 시나리오는 무조건 NACL이 답. SG는 Deny 규칙 자체가 없어서 차단 못 함. Flow Logs에서 인바운드 ACCEPT + 아웃바운드 REJECT가 보이면 NACL 아웃바운드 규칙 누락이 정답입니다.
VPC 연결 — Peering·Transit Gateway·PrivateLink
회사가 커지면 VPC가 여러 개 생깁니다(개발 VPC, 프로덕션 VPC, 데이터 VPC…). 이걸 어떻게 연결하느냐 — 시험에 정말 자주 나오는 비교 문제예요.
세 가지 방식이 있는데, 회사 비유로 잡고 갑시다.
- VPC Peering — 두 사옥 사이에 개인 다리를 직접 놓는 것
- Transit Gateway — 중앙 환승역을 두고 모든 사옥이 거기로 모임
- PrivateLink — 한 회사가 다른 회사들에게 창구 서비스를 노출
| 서비스 | 전이적 라우팅 | CIDR 중복 허용 | 규모 | 주요 용도 |
|---|---|---|---|---|
| VPC Peering | ❌ | ❌ | 소규모 | 소수 VPC 간 직접 연결 |
| Transit Gateway | ✅ | ❌ | 대규모 | 중앙 집중식 VPC/VPN/DX 연결 |
| PrivateLink | N/A | ✅ | 대규모 | 서비스 노출 (1:N) |
VPC Peering — 두 사옥 사이 개인 다리
VPC Peering은 두 VPC를 AWS 프라이빗 네트워크로 직접 연결해요. 단순하지만 함정이 두 개 있습니다.
첫째, CIDR이 겹치면 못 만듭니다. 두 사옥의 호수 번호가 같으면 어느 사옥의 101호인지 모르니까요. 비겹침 CIDR이 필수.
둘째, 비전이적(Non-Transitive) 입니다. A-B를 연결하고 B-C를 연결해도, A-C는 자동으로 연결되지 않아요. A에서 C로 가려면 A-C 직접 피어링을 또 만들어야 합니다. 회사 비유로 — A↔B 다리와 B↔C 다리가 있어도, A에서 C로 직접 가는 다리가 없으면 못 가요. B를 통과해서 갈 수도 없습니다.
양방향 라우팅 테이블을 다 업데이트해야 하고, 동일 리전·다른 리전·다른 계정 모두 가능해요.
Transit Gateway — 중앙 환승역
VPC가 5개, 10개로 늘면 Peering으로는 감당이 안 됩니다(5개면 다리가 10개 필요해요). 그래서 중앙 환승역을 두는 게 Transit Gateway(TGW) 예요.
핵심 특징:
- 수많은 VPC, VPN, Direct Connect를 중앙 허브로 연결
- 전이적(Transitive) 라우팅 지원 ← VPC Peering과 차별점
- IP Multicast 지원하는 유일한 AWS 서비스 (시험 함정 단골)
- ECMP(Equal Cost Multi-path) — 여러 Site-to-Site VPN으로 대역폭 확장
- 리전 간 피어링 가능
- Route Table로 트래픽 격리 가능
여기서 시험 함정 두 개 — IP Multicast가 필요하면 답은 무조건 TGW(다른 데서 안 됨), 여러 VPN을 묶어 대역폭을 늘리려면(ECMP) TGW가 필수.
PrivateLink — 창구 서비스 노출
PrivateLink (VPC Endpoint Service) 는 자사 서비스를 다른 고객 VPC에 프라이빗하게 노출하는 방식이에요. 회사로 치면 — 우리 회사 서비스를 다른 회사들에게 창구 형태로 제공하되, 두 회사가 같은 사설 망 안에 있는 것처럼 안전하게 연결하는 거예요.
- NLB(제공자 측) + ENI(소비자 측) 구성
- IGW, NAT, VPC 피어링, 라우팅 테이블 변경 다 불필요
- CIDR 중복도 허용 ← VPC Peering과 차별점
- 수천 개의 VPC에 서비스 노출 시 최적 솔루션
키워드 — "수천 개 VPC에 서비스 노출", "CIDR이 겹치는 고객 VPC"가 보이면 답은 PrivateLink.
VPC Endpoints — Gateway vs Interface
이건 PrivateLink와 좀 달라요. VPC Endpoint는 AWS 서비스(S3·DynamoDB·SSM·ECR 등) 에 인터넷 없이 프라이빗 접근하는 게 목적입니다.
| 유형 | 지원 서비스 | 비용 | 특징 |
|---|---|---|---|
| Gateway Endpoint | S3, DynamoDB만 | 무료 | 라우팅 테이블에 경로 추가 방식 |
| Interface Endpoint | 대부분의 AWS 서비스 (SSM, ECR 등) | 시간당 + 데이터 요금 | ENI 생성, SG 연결 필요 |
여기서 외워둘 핵심 두 가지 — S3와 DynamoDB만 Gateway Endpoint를 지원하고, 그게 무료입니다. 다른 서비스는 다 Interface Endpoint(유료)예요.
시험에 "S3/DynamoDB + 프라이빗 접근 + 비용 절감" 키워드 조합이 보이면 답은 무조건 Gateway Endpoint. 무료라는 게 결정적인 이유예요. NAT Gateway 비용도 회피할 수 있고요.
VPC와 온프레미스 연결 — Site-to-Site VPN vs Direct Connect
기업이 자기 데이터센터를 AWS와 연결할 때 두 가지 방식이 있어요. 회사 비유로 잡고 갑시다.
- Site-to-Site VPN — 일반 도로(공용 인터넷)에 암호화 화물차를 띄움
- Direct Connect(DX) — 두 사옥을 잇는 전용 도로를 깖
| 항목 | Site-to-Site VPN | Direct Connect (DX) |
|---|---|---|
| 연결 방식 | 공용 인터넷 + IPSec 암호화 터널 | 전용 물리 회선 |
| 구성 요소 | VGW(AWS) + CGW(고객) | DX Location + VGW |
| 설정 시간 | 수 분 ~ 수 시간 | 1개월 이상 |
| 대역폭 | 제한적, 인터넷 품질 의존 | 1Gbps / 10Gbps / 100Gbps |
| 비용 | 상대적으로 저렴 | 비용 높음 |
| 암호화 | 기본 암호화(IPSec) | 기본 암호화 없음 |
| 안정성 | 인터넷 품질 의존 | 일관된 네트워크 성능 |
여기서 시험 단골 함정이 두 개 있어요.
첫째, "DX는 기본 암호화가 없다" — 전용 회선이라 도청 위험은 낮지만, 암호화는 별도예요. 암호화가 필요하면 DX 위에 VPN을 한 번 더 올립니다(DX + VPN 오버레이). 시험에 "전용선 + 암호화" 시나리오가 나오면 답은 이 조합.
둘째, DX는 설정에 1개월 이상 걸립니다. "빠르게 즉시 연결" 시나리오는 무조건 VPN. "안정적 대역폭 + 시간 여유" 시나리오는 DX.
Direct Connect Gateway(DXGW) 는 여러 리전의 VPC에 단일 DX로 연결할 수 있게 해주는 서비스예요. "여러 리전 + 단일 DX" 시나리오는 DXGW가 답입니다.
VPC Flow Logs와 Traffic Mirroring — 네트워크 가시성
VPC Flow Logs는 VPC/서브넷/ENI 레벨에서 IP 트래픽 정보를 캡처합니다. 회사로 치면 — 사옥 출입 기록을 남기는 거예요. 누가, 언제, 어디서 들어왔는지.
- 전송 대상: S3(Athena 분석), CloudWatch Logs, Kinesis Data Firehose
- 캡처하지 않는 트래픽: Amazon DNS, 메타데이터(169.254.x.x), DHCP, 라이선스 활성화
- 로그 필드: srcaddr, dstaddr, srcport, dstport, protocol, action(ACCEPT/REJECT)
Traffic Mirroring은 ENI 트래픽을 그대로 복사해서 보안 분석 도구로 보내는 서비스예요. Flow Logs와 결정적 차이는 — 실제 패킷 페이로드까지 캡처 가능하다는 점. 심층 패킷 검사(DPI)·위협 탐지에 활용합니다.
- 소스: ENI / 대상: ENI 또는 NLB
- 활용: DPI, 위협 탐지
키워드 — "메타데이터(IP·포트) 정도면 충분" → Flow Logs / "실제 패킷 내용 분석 필요" → Traffic Mirroring.
AWS Network Firewall — VPC 전체 방화벽
VPC 전체를 보호하는 관리형 방화벽 (L3 ~ L7). 회사로 치면 — 사옥 전체에 한 층 추가된 보안 통제실이에요.
핵심 기능:
- 모든 방향 트래픽 검사: VPC-to-VPC, 인바운드, 아웃바운드, VPN/DX
- 도메인 레벨 필터링 — 특정 도메인으로의 아웃바운드만 허용 (시험 단골)
- 프로토콜 기반 필터링 (SMB 비활성화 등), 정규식 패턴 매칭
- 침입 방지 시스템(IPS) 내장
- 내부적으로 Gateway Load Balancer(GWLB) 사용
- Firewall Manager와 통합해 다중 계정 중앙 관리
- 로그 전송: S3, CloudWatch Logs, Kinesis Data Firehose
시험 키워드 — "도메인 레벨 필터링 + VPC 전체 보호" → Network Firewall. "다중 계정 방화벽 중앙 관리" → Firewall Manager.
IPv6 & Dual-Stack — 짧게
- VPC에 IPv6 CIDR 추가 → Dual-Stack 모드
- 모든 IPv6 주소는 공인 IP (프라이빗 IPv6 없음)
- EC2에서 IPv6 비활성화: OS 레벨에서 설정
여기서 외워둘 게 — IPv6에는 프라이빗 개념이 없다는 점이에요. 그래서 NAT Gateway가 아니라 EIGW가 IPv6 아웃바운드 전용으로 따로 있는 거예요.
Route 53 — DNS 기본
Route 53은 AWS의 DNS 서비스예요. 회사 비유로 — 회사 전화번호부 같은 거예요. "marketing@company.com을 누르면 어느 자리 어느 사람으로 연결" 같은 매핑을 관리. 라우팅 정책별 동작이 헷갈릴 때는 Route 53 개발자 가이드 쪽이 그림과 예시가 풍부해서 도움이 됩니다.
핵심 사실 한 줄 — SLA 100% 가용성을 보장하는 유일한 AWS 서비스예요. 시험에 "100% SLA가 보장되는 AWS 서비스" 물으면 답은 Route 53.
DNS 쿼리 흐름은 이렇게 됩니다.
> Local DNS Cache → Recursive Resolver → Root NS → TLD NS → Authoritative NS
Route 53은 Authoritative DNS(도메인 소유자가 직접 레코드 업데이트 가능)예요.
DNS 레코드 타입
| 레코드 | 용도 | 특징 |
|---|---|---|
| A | 도메인 → IPv4 주소 | - |
| AAAA | 도메인 → IPv6 주소 | - |
| CNAME | 도메인 → 다른 도메인 | Zone Apex(루트 도메인) 불가 |
| Alias | 도메인 → AWS 리소스 | Zone Apex 가능, TTL 자동, 무료, EC2 DNS 불가 |
| NS | Name Server 레코드 | 호스팅 영역을 처리하는 DNS 서버 |
| SOA | Start of Authority | 도메인 관리 정보 |
| MX | 이메일 서버 | - |
| TXT | 텍스트 정보 | 도메인 소유 확인, SPF, DKIM |
| CAA | 인증서 발급 기관 제한 | - |
| SRV | 서비스 위치 | - |
여기서 시험 단골 함정 — CNAME과 Alias의 차이예요.
example.com 같은 Zone Apex(루트 도메인)에는 CNAME을 못 붙입니다 — 반드시 Alias 사용. Alias는 무료, CNAME은 DNS 쿼리 요금 발생. Alias 불가 대상은 EC2 인스턴스 DNS 이름 (ALB·NLB·CloudFront·S3 정적 사이트·API Gateway·Global Accelerator·VPC Interface Endpoint는 모두 Alias 가능).
Alias 지원 대상을 한 번 정리하면 — ALB, NLB, CloudFront, API Gateway, S3 웹사이트, Elastic Beanstalk, VPC Interface Endpoint, Global Accelerator, 동일 호스팅 영역의 Route 53 레코드. EC2 인스턴스 DNS만 Alias 불가예요.
TTL — 캐시 시간
TTL(Time To Live) 은 DNS 응답을 클라이언트가 캐시하는 시간(초 단위)이에요. 회사로 치면 — 누군가의 자리 번호를 알아냈을 때 그걸 며칠 동안 메모지에 적어두느냐 같은 거예요.
- 높은 TTL: DNS 쿼리 ↓ → 비용 절감 / 변경 전파 느림
- 낮은 TTL: 빠른 변경 전파 / DNS 쿼리 ↑
시험 단골 — 마이그레이션 전에는 TTL을 미리 낮춰두라. 그래야 도메인을 새 IP로 바꾸자마자 빠르게 전파돼요.
호스팅 영역
| 유형 | 설명 | 비용 |
|---|---|---|
| Public Hosted Zone | 인터넷에서 쿼리 가능 | 월 $0.50 |
| Private Hosted Zone | VPC 내부에서만 쿼리 가능 | 월 $0.50 |
Private Hosted Zone은 VPC와 연결이 필요하고, 그 VPC의 enableDnsHostnames와 enableDnsSupport가 둘 다 활성화돼 있어야 동작합니다. 시험 함정 — 둘 다 켜야 해요. 하나만 켜져 있으면 안 됨.
Route 53 라우팅 정책 7가지 — 시험 단골
여기가 Route 53에서 가장 자주 출제되는 부분이에요. 한 번 표로 정리하고, 키워드 매칭으로 외우면 빨라요.
| 정책 | 용도 | 특징 |
|---|---|---|
| Simple | 단일 리소스 | 헬스체크 없음, 다중 IP 반환 시 클라이언트가 랜덤 선택 |
| Weighted | A/B 테스트, 트래픽 분산 | 가중치 비율로 분배, 헬스체크 가능, 가중치 0=트래픽 중단 |
| Latency | 지연 시간 최소화 | 사용자와 AWS 리전 간 지연 시간 기준, 헬스체크 가능 |
| Failover | 능동-수동 DR | Primary 헬스체크 실패 시 Secondary로 자동 전환, 헬스체크 필수 |
| Geolocation | 사용자 지역 기반 | 국가/대륙/기본값 설정, 콘텐츠 지역화, 규정 준수 |
| Geoproximity | 지역 편향(Bias) 조정 | Traffic Flow 필요, Bias 값으로 트래픽 범위 확대/축소 |
| IP-based | 클라이언트 IP 기반 | CIDR 범위별 라우팅, ISP 최적화 |
| Multi-Value | 다중 리소스 + 헬스체크 | 최대 8개 레코드, 헬스체크 연동, ELB 대체 불가 |
키워드 매칭으로 외우면 빨라요.
- "A/B 테스트 / 점진적 배포" → Weighted
- "글로벌 최저 지연" → Latency
- "액티브-패시브 DR" → Failover (헬스체크 필수)
- "국가 단위 / 콘텐츠 지역화 / 규정 준수" → Geolocation
- "Bias 값으로 트래픽 범위 조정" → Geoproximity
- "ISP별 최적화 / IP 범위 라우팅" → IP-based
- "다중 리소스 + 헬스체크" → Multi-Value (단, ELB 대체는 아님)
여기서 시험 함정 — Multi-Value는 ELB 대체가 아닙니다. "ELB 없이 부하 분산하려면?" 같은 시나리오에 Multi-Value를 답으로 고르면 함정이에요. Multi-Value는 그냥 다중 IP 반환 + 헬스체크를 묶은 것뿐이고, ELB의 본격적인 부하 분산 기능을 대체하지 못합니다.
Health Checks — 헬스체크 세부
- 유형: HTTP/HTTPS/TCP 엔드포인트, CloudWatch Alarm, 다른 헬스체크(Calculated)
- 전 세계 15개 체커가 확인, 18% 이상 정상 판단 시 Healthy
- 확인 간격: 30초(기본) / 10초(빠른 체크, 추가 비용)
- HTTP 응답 코드 2xx/3xx = 정상, 처음 5,120 바이트 응답 텍스트 확인 가능
- 프라이빗 리소스 헬스체크: 직접 불가 → CloudWatch Metric → CloudWatch Alarm → 헬스체크 연동
마지막 줄이 시험 단골이에요. "프라이빗 리소스 헬스체크" 시나리오는 무조건 CloudWatch Alarm 연동 패턴이 답입니다.
Route 53 Resolver — 하이브리드 DNS
온프레미스와 AWS의 DNS를 통합할 때 쓰는 게 Route 53 Resolver예요.
- Inbound Endpoint — 온프레미스 → AWS DNS 쿼리
- Outbound Endpoint — AWS → 온프레미스 DNS 쿼리 (Forwarding Rules 설정)
키워드 — "하이브리드 환경 DNS 통합"이 보이면 Route 53 Resolver.
CloudFront — CDN
CloudFront는 AWS의 CDN(Content Delivery Network) 입니다. 전 세계 200+ 엣지 로케이션(PoP) 에서 콘텐츠를 캐싱해요. 회사로 치면 — 본사 자료를 전국 지점에 복사해 두고, 가까운 지점에서 가져가게 하는 거예요. 본사 부하도 줄고, 지점 직원이 자료 받는 시간도 단축되고요.
캐싱을 통해 오리진 부하 감소 + 사용자 지연 시간 단축. DDoS 방어(Shield), WAF 통합 가능.
오리진(Origin) 유형
- S3 버킷 — OAC(Origin Access Control) 로 CloudFront만 접근 허용
- OAC가 OAI(Origin Access Identity)를 대체 (최신 권장 방식)
- S3 Transfer Acceleration 대신 CloudFront 사용 권장
- Custom Origin — ALB, EC2, API Gateway, HTTP 서버 (ALB/NLB·EC2 모두 퍼블릭이어야 함)
- VPC Origin — 프라이빗 ALB/NLB/EC2에 직접 연결 (CloudFront가 VPC 내부로 접근)
여기서 시험 함정 — OAC vs OAI. OAC가 최신이고 SigV4 서명을 지원해서 권장. 시험 보기에서 OAI를 답으로 고르면 함정이에요. OAC가 정답.
캐시 무효화·지리적 제한·가격 등급
캐시 무효화는 /* 또는 특정 경로를 지정해요. 월 1,000건 무료, 이후 유료.
지리적 제한(Geo Restriction) — Allowlist(허용 국가) 또는 Blocklist(차단 국가). 국가 판별은 MaxMind GeoIP 데이터베이스 기반.
가격 등급(Price Classes):
| 등급 | 포함 지역 |
|---|---|
| Price Class All | 전 세계 모든 엣지 로케이션 (최고 성능, 최고 비용) |
| Price Class 200 | 북미, 유럽, 아시아, 중동, 아프리카 (남미/일부 제외) |
| Price Class 100 | 북미, 유럽만 (최저 비용) |
비용 최적화 시나리오 — Price Class 100 (북미·유럽만).
Signed URL vs Signed Cookie
| 항목 | Signed URL | Signed Cookie |
|---|---|---|
| 적용 범위 | 파일 1개 | 여러 파일 |
| 용도 | 특정 파일 접근 제어 | 프리미엄 콘텐츠 전체 접근 |
| RTMP 배포 | 가능 | 불가 |
키워드 — "파일 1개" → URL / "여러 파일" → Cookie.
Lambda@Edge vs CloudFront Functions
| 항목 | CloudFront Functions | Lambda@Edge |
|---|---|---|
| 언어 | JavaScript | Node.js, Python |
| 실행 위치 | 엣지 로케이션 | 리전 엣지 캐시 |
| 최대 실행 시간 | 1ms 미만 | 5초(Viewer), 30초(Origin) |
| 메모리 | 2MB | 128MB ~ 10GB |
| 네트워크 접근 | 불가 | 가능 |
| 파일시스템 접근 | 불가 | 가능 |
| 요청 수 | 수백만/초 | 수천/초 |
| 비용 | 저렴 | 상대적으로 비쌈 |
| 사용 사례 | 헤더 조작, URL 리다이렉트, JWT 검증 | A/B 테스트, 사용자 인증, 동적 오리진 선택 |
키워드 — "1ms 미만 + JS만 + 단순 헤더 조작" → CloudFront Functions / "복잡한 로직 + 네트워크/FS 접근 필요" → Lambda@Edge.
Global Accelerator — 글로벌 트래픽 라우팅
Global Accelerator는 CloudFront와 헷갈리는 단골이에요. 비유부터 잡고 갑니다.
- CloudFront — 가까운 지점에 자료를 복사해 두는 CDN
- Global Accelerator — 가까운 진입점에서 AWS 전용 고속도로로 본사까지 빠르게 이동
핵심 특징:
- 2개의 정적 Anycast IP로 전 세계 트래픽 수신
- 가까운 AWS 엣지 로케이션으로 진입 후 AWS 프라이빗 백본 네트워크로 전달
- 캐싱 없음, TCP/UDP 모두 지원
- 고정 IP라 방화벽 화이트리스트에 유리
- 내장 헬스체크 + 자동 장애 조치 (약 1분 이내)
- DDoS 방어 (AWS Shield 자동 통합)
- 엔드포인트: ALB, NLB, EC2, Elastic IP
CloudFront vs Global Accelerator — 시험 단골 비교
이 둘이 정말 헷갈려서 시험에 매번 나옵니다. 비교표로 한 번 정리하고, 키워드 매칭으로 외워둡시다.
| 항목 | CloudFront | Global Accelerator |
|---|---|---|
| 주요 목적 | 콘텐츠 캐싱 (CDN) | 글로벌 트래픽 라우팅 |
| 캐싱 | ✅ (엣지 로케이션) | ❌ |
| 프로토콜 | HTTP/HTTPS | TCP, UDP, HTTP |
| IP 주소 | 동적 (DNS 기반) | 정적 Anycast IP 2개 |
| 대상 | 정적/동적 웹 콘텐츠 | 게임, IoT, VoIP, HTTP |
| 헬스체크 | 오리진 기반 | 내장 헬스체크 |
| 장애 조치 | DNS TTL 의존 | ~1분 내 빠른 전환 |
| AWS 백본 | 부분 활용 | 전체 구간 활용 |
키워드 매칭:
- "정적 콘텐츠 + 캐싱 + 비용 절감" → CloudFront
- "게임 / IoT / VoIP / 비HTTP 트래픽" → Global Accelerator
- "정적 IP가 필요한 방화벽 화이트리스트" → Global Accelerator
- "1분 내 빠른 장애 조치" → Global Accelerator (DNS TTL에 안 묶임)
보안 계층 한 번에 — WAF·Shield·Network Firewall·NACL·SG
네트워크 보안에 등장하는 서비스들이 너무 많아서 한 번 표로 묶고 갑니다.
| 계층 | 서비스 | 범위 | 방식 | Deny 가능 |
|---|---|---|---|---|
| L7 (웹 애플리케이션) | AWS WAF | ALB/CloudFront/API GW | HTTP/HTTPS 필터링 | ✅ |
| L3-L7 (VPC) | Network Firewall | VPC 전체 | 도메인/IP/프로토콜/IPS | ✅ |
| 서브넷 | NACL | 서브넷 경계 | IP/포트, Stateless | ✅ |
| 인스턴스 | Security Group | ENI | IP/포트, Stateful | ❌ |
| DDoS | AWS Shield | 엣지/AWS 리소스 | 볼륨 공격 방어 | - |
| 다중 계정 | Firewall Manager | AWS Organizations | 중앙 정책 관리 | - |
키워드 매칭:
- "SQL Injection·XSS 같은 웹 해킹 방어" → WAF
- "DDoS 방어" → Shield
- "도메인 레벨 필터링 + VPC 전체" → Network Firewall
- "특정 IP 차단" → NACL (SG는 Deny 불가!)
- "다중 계정 방화벽 중앙 관리" → Firewall Manager
네트워크 비용 최적화
시험에 비용 시나리오가 자주 나와요. 요금 표를 한 번 박아두면 빠릅니다.
| 경로 | 요금 |
|---|---|
| 동일 AZ + 프라이빗 IP | 무료 |
| 다른 AZ + 프라이빗 IP | $0.01/GB |
| 다른 AZ + 퍼블릭/EIP | $0.02/GB (비추) |
| 다른 리전 | $0.02/GB |
| 인터넷 아웃바운드 (S3 등) | $0.09/GB |
비용 절감 패턴:
- 항상 프라이빗 IP 사용 (다른 AZ에서 퍼블릭 IP 쓰면 2배 비쌈)
- S3/DynamoDB는 Gateway Endpoint → NAT Gateway 비용 회피, 게다가 무료
- S3 → CloudFront 전송은 무료 → S3 Egress($0.09/GB) 회피 + 캐싱 효과로 요청 수 감소
- NAT Gateway 비용이 큼 → S3/DynamoDB는 무조건 Gateway Endpoint
- EIP 미사용 시 릴리스 필수 — NAT 삭제 후 EIP 미릴리스 시 요금 발생
- Route 53 Hosted Zone: 월 $0.50 (미사용 시에도 과금)
아키텍처 패턴 — 시험에 자주 등장하는 구성
패턴 1: 3-Tier VPC
인터넷 → IGW → 퍼블릭 서브넷(ALB/Bastion) → 프라이빗 서브넷(EC2 App) → 프라이빗 서브넷(RDS DB)
↑
NAT Gateway (프라이빗 서브넷의 아웃바운드용)각 계층은 서로 다른 AZ에 배포(고가용성), RDS는 Multi-AZ.
패턴 2: 다중 VPC 연결
- VPC 수가 적을 때 → VPC Peering (비용 저렴, 설정 단순)
- VPC 수가 많을 때 → Transit Gateway (중앙 집중식, 전이적 라우팅)
- 서비스 노출 → PrivateLink (소비자 VPC CIDR 중복 가능, 확장성 높음)
패턴 3: 하이브리드 연결
- 빠른 연결 필요 → Site-to-Site VPN (즉시 구성)
- 안정적 전용선 필요 → Direct Connect (1개월+ 설정)
- 보안 + 전용선 → DX + VPN 오버레이 (IPSec 암호화 추가)
- 여러 리전 연결 → Direct Connect Gateway
패턴 4: S3 프라이빗 접근
프라이빗 서브넷 EC2 → [NAT Gateway → 인터넷 → S3] (비용 높음)
프라이빗 서브넷 EC2 → [VPC Gateway Endpoint → S3] (무료, 보안 강화) ← 정답패턴 5: DR DNS
Route 53 Failover 라우팅 + 헬스체크. 액티브-패시브: Primary(메인 리전) + Secondary(DR 리전 S3/CloudFront). RTO 최소화: 헬스체크 실패 감지 즉시 Secondary 전환.
패턴 6: 글로벌 콘텐츠 배포
- 정적 콘텐츠 → S3 + CloudFront (캐싱으로 비용 절감 + 지연 감소)
- 동적 콘텐츠 / 게임 / IoT → Global Accelerator
- S3 → CloudFront 전송 무료(Egress 비용 절감)
서비스 선택 빠른 가이드
시험 직전에 한 번 더 훑어보면 좋은 시나리오↔서비스 매핑입니다.
| 시나리오 | 정답 |
|---|---|
| VPC 전체 L3-L7 방화벽 + IPS + 도메인 필터링 | AWS Network Firewall |
| 특정 IP 차단 | NACL |
| 웹 해킹 방어 (SQLi, XSS) | AWS WAF |
| DDoS 방어 | AWS Shield |
| 다중 계정 방화벽 중앙 관리 | AWS Firewall Manager |
| IPv4 프라이빗 서브넷 인터넷 아웃바운드 | NAT Gateway |
| IPv6 프라이빗 서브넷 인터넷 아웃바운드 | Egress-Only IGW |
| S3 프라이빗 접근 + 비용 절감 | VPC Gateway Endpoint |
| 수십 개 VPC 중앙 연결 + 전이적 라우팅 | Transit Gateway |
| 서비스 노출 (CIDR 중복 허용) | PrivateLink |
| 전용선 + 빠른 설정 | Site-to-Site VPN |
| 전용선 + 안정적 대역폭 | Direct Connect |
| DX + 암호화 | DX + VPN 오버레이 |
| 여러 리전 단일 DX | Direct Connect Gateway |
| Zone Apex DNS | Route 53 Alias |
| 글로벌 정적 콘텐츠 배포 + 비용 절감 | S3 + CloudFront |
| 글로벌 TCP/UDP 트래픽 + 정적 IP | Global Accelerator |
| DNS 기반 DR (액티브-패시브) | Route 53 Failover |
| DNS 기반 A/B 테스트 | Route 53 Weighted |
시험 직전 한 번 더 — 자주 헷갈리는 함정 모음
여기까지가 네트워킹 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 박아 둘게요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.
VPC·서브넷·NAT·NACL
- 서브넷 예약 IP 5개 —
.0(네트워크),.1(라우터),.2(DNS),.3(예약),.255(브로드캐스트) → /24는 251개 사용 가능 - NAT Instance — Src/Dst Check 비활성화 필수, Bastion 겸용 가능
- NAT Gateway — AZ 단위, HA 위해 AZ별로 별도 배포
- 특정 IP 차단 → NACL (SG는 Deny 불가)
- NACL은 Stateless — 임시 포트(1024-65535) 아웃바운드 허용 필요
- Flow Logs 인바운드 ACCEPT + 아웃바운드 REJECT → NACL 아웃바운드 누락
VPC 연결 — Peering·TGW·PrivateLink·Endpoint·DX
- VPC Peering — CIDR 중복 불가, 비전이적(A-B-C에서 A-C 직접 피어링 필요)
- Transit Gateway — 전이적 라우팅, IP Multicast 유일, ECMP, 리전 간 피어링
- PrivateLink — CIDR 중복 허용, 수천 VPC 노출 시 최적, NLB+ENI
- Gateway Endpoint — S3·DynamoDB만, 무료, 라우팅 테이블 항목 추가
- DX는 기본 암호화 없음 → 암호화 필요 시 DX + VPN 오버레이
- 여러 리전 단일 DX → Direct Connect Gateway
- IPv6 아웃바운드 전용 → Egress-Only IGW (
::/0) - 도메인 기반 필터링 + VPC 전체 → Network Firewall
- 다중 계정 방화벽 중앙 관리 → Firewall Manager
- Flow Logs vs Traffic Mirroring — 페이로드 캡처는 Mirroring만
Route 53 — DNS·라우팅·헬스체크
- Route 53 SLA 100% (AWS 유일)
- Zone Apex(루트 도메인) → Alias (CNAME 불가)
- Alias 무료, CNAME 유료, Alias 불가 = EC2 DNS만
- Multi-Value 라우팅 = ELB 대체 아님
- Private Hosted Zone — VPC
enableDnsHostnames+enableDnsSupport둘 다 활성화 - 헬스체크 — 15개 글로벌 체커, 18% 이상 정상, 5,120 바이트
- 프라이빗 리소스 헬스체크 → 직접 불가, CloudWatch Alarm 연동
- 마이그레이션 전 → TTL 미리 낮추기
CloudFront·Global Accelerator·비용
- CloudFront — OAC > OAI, S3→CloudFront 전송 무료
- VPC Origin — 프라이빗 ALB/NLB/EC2 직접 연결 가능
- Geo Restriction — MaxMind GeoIP, 국가 단위
- CloudFront Functions — JS, 1ms 미만 / Lambda@Edge — Node·Python, 5~30초, 네트워크/FS 접근 가능
- Global Accelerator — 정적 Anycast IP 2개, TCP/UDP, 캐싱 없음, ~1분 장애 조치
- CloudFront vs Global Accelerator — 캐싱 필요 = CloudFront / 정적 IP·게임·IoT·VoIP = Global Accelerator
- 동일 AZ + 프라이빗 IP = 무료, 인터넷 아웃바운드 $0.09/GB
- EIP 미사용 시 릴리스 필수
마무리 한 줄
여기까지가 SAA-C03 네트워킹·DNS 영역의 전부예요. 노트로 보면 단순해 보이지만, 시험 보기 4개에서 정답을 골라낼 때마다 "VPC Peering인지 Transit Gateway인지, NAT Gateway인지 Gateway Endpoint인지, CloudFront인지 Global Accelerator인지" 헷갈리기 쉬운 영역입니다. 한두 번 정독으로 끝내지 말고, 비교표를 직접 손으로 다시 그려보면서 머리에 새겨두면 시험장에서 훨씬 빠르게 풀려요.
다음 글(7편)에서는 SQS·SNS·Kinesis·EventBridge 같은 메시징·통합 서비스를 정리해요. 분산 시스템 아키텍처 시나리오에서 자주 등장하는 영역이고, 네트워킹과 함께 SAA에서 중요한 비중을 차지하는 단원입니다.
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.