기본개념 · 3장

VPC 네트워킹 기초

2장의 IAM이 "누가 무엇을 할 수 있는가"를 정했다면, VPC는 "어디서 어디로 갈 수 있는가"를 정합니다. 시험은 이 층에서 두 가지를 집요하게 묻습니다 — 퍼블릭과 프라이빗을 실제로 가르는 것이 무엇인가, 그리고 보안 그룹과 네트워크 ACL 중 무엇이 상태를 기억하는가입니다. 이름이나 느낌이 아니라 라우팅 테이블과 상태 저장 여부가 정답을 만듭니다.

이 장도 보안 아키텍처 설계(30%)의 중심이며, 과제 진술 1.2 "보안 워크로드·애플리케이션 설계"에 직접 대응합니다. NAT 게이트웨이의 이중화는 복원력 있는 아키텍처 설계(26%)에도 걸칩니다.

학습 목표

VPC와 서브넷의 CIDR 크기 제약을 설명하고, 서브넷마다 사용할 수 없는 주소가 다섯 개라는 점을 반영해 설계할 수 있습니다.
퍼블릭 서브넷과 프라이빗 서브넷을 가르는 것이 라우팅 테이블이라는 사실을 근거로 문항의 선택지를 소거할 수 있습니다.
인터넷 게이트웨이와 NAT 게이트웨이가 각각 어떤 트래픽을 처리하는지 구분할 수 있습니다.
NAT 게이트웨이를 가용 영역마다 두어야 하는 이유를 가용성과 비용 두 측면에서 설명할 수 있습니다.
보안 그룹과 네트워크 ACL의 적용 계층 · 규칙 종류 · 상태 저장 여부를 구분하고, 응답 트래픽이 막히는 지점을 짚을 수 있습니다.
VPC Flow Logs로 확인할 수 있는 것과 확인할 수 없는 것을 구분할 수 있습니다.

VPC와 CIDR 설계

Amazon VPC는 AWS 계정 안에 만드는 논리적으로 격리된 가상 네트워크입니다. VPC를 만들 때 IPv4 CIDR 블록을 지정하고, 그 안을 서브넷으로 잘라 씁니다. VPC의 주소 범위는 내부용 사설 범위로 취급되며 인터넷에 광고되지 않습니다. VPC 사용 설명서는 퍼블릭 라우팅이 가능한 CIDR을 쓰더라도 VPC CIDR에서 인터넷으로 직접 나가는 것은 지원하지 않는다고 명시합니다 — 인터넷 게이트웨이 · 가상 프라이빗 게이트웨이 · Site-to-Site VPN · Direct Connect 같은 게이트웨이를 반드시 거쳐야 합니다.

CIDR 분할과 예약 주소 — /16 VPC를 /24 서브넷으로 자르면 서브넷마다 256개 주소가 생기지만 실제로 쓸 수 있는 것은 251개입니다. 각 서브넷의 처음 네 개와 마지막 하나를 AWS가 예약하며, 서브넷 하나는 가용 영역 하나 안에만 존재합니다

크기 제약 — 확인된 값

VPC와 서브넷의 CIDR 크기 제약
항목	IPv4	IPv6
VPC 크기	`/16` ~ `/28` 범위의 CIDR을 최대 5개 (조정 가능한 할당량)	`/56` 고정, 최대 5개 (조정 불가)
서브넷 크기	`/16` ~ `/28`	`/64` 고정
기본 VPC	`172.31.0.0/16`, 가용 영역마다 `/20` 기본 서브넷	해당 없음
생성 후 변경	서브넷의 CIDR은 만든 뒤 바꿀 수 없다	동일

서브넷을 만든 뒤에는 CIDR을 바꿀 수 없습니다. 주소 소진은 설계 시점에만 막을 수 있는 문제라는 뜻입니다. 나중에 늘리려면 VPC에 CIDR 블록을 추가하고 새 서브넷을 만드는 수밖에 없습니다.

서브넷마다 사라지는 다섯 개 주소

VPC 사용 설명서는 각 서브넷 CIDR의 처음 네 개 주소와 마지막 한 개 주소를 사용할 수 없다고 명시합니다. 10.0.0.0/24 서브넷을 예로 들면 이렇습니다.

`10.0.0.0/24` 서브넷에서 예약되는 다섯 개 주소
주소	용도
`10.0.0.0`	네트워크 주소
`10.0.0.1`	VPC 라우터용으로 AWS가 예약
`10.0.0.2`	DNS 서버. VPC 네트워크 범위의 기준 주소에 2를 더한 값
`10.0.0.3`	향후 사용을 위해 AWS가 예약
`10.0.0.255`	브로드캐스트 주소. VPC는 브로드캐스트를 지원하지 않으므로 예약

/24는 256개가 아니라 251개를 씁니다. /28이면 16개 중 11개만 남습니다. 컨테이너나 Lambda처럼 ENI를 많이 만드는 워크로드를 작은 서브넷에 넣으면 여기서 주소가 먼저 마릅니다.

서브넷과 라우팅 테이블 — 퍼블릭과 프라이빗의 실체 SAA 빈출

"퍼블릭 서브넷"은 AWS의 설정 항목이 아닙니다. 서브넷에 public이라는 스위치가 있는 것도 아니고, 이름을 그렇게 지어서 되는 것도 아닙니다. VPC 사용 설명서의 정의는 명확합니다 — 퍼블릭 서브넷은 인터넷 게이트웨이로 가는 직접 경로가 라우팅 테이블에 있는 서브넷이고, 프라이빗 서브넷은 그 경로가 없는 서브넷입니다.

두 가용 영역에 걸친 퍼블릭·프라이빗 서브넷과 각 서브넷의 라우팅 테이블 — 퍼블릭 서브넷의 라우팅 테이블에는 0.0.0.0/0이 인터넷 게이트웨이를 가리키는 항목이 있고, 프라이빗 서브넷의 라우팅 테이블에는 그 자리에 NAT 게이트웨이가 들어갑니다. 서브넷을 퍼블릭으로 만드는 것은 이름이 아니라 이 한 줄입니다

서브넷은 가용 영역 하나에 속한다

VPC 사용 설명서는 "각 서브넷은 가용 영역 하나 안에 완전히 존재해야 하며 여러 영역에 걸칠 수 없다"고 규정합니다. 이 제약이 다중 가용 영역 설계의 출발점입니다 — 가용 영역을 두 개 쓰겠다는 결정은 곧 같은 역할의 서브넷을 두 개 만들겠다는 뜻입니다. ALB, RDS 서브넷 그룹, ASG가 모두 "가용 영역이 다른 서브넷 두 개 이상"을 요구하는 이유도 여기에 있습니다.

라우팅 테이블의 규칙

라우팅 테이블 동작 규칙
규칙	내용
기본 라우팅 테이블	VPC를 만들면 자동으로 생긴다. 다른 라우팅 테이블에 명시적으로 연결되지 않은 모든 서브넷의 라우팅을 담당하며 삭제할 수 없다
로컬 경로	VPC 내부 통신을 위한 경로로 모든 라우팅 테이블에 기본으로 들어간다. VPC에 CIDR이 여러 개면 CIDR마다 하나씩 생긴다
연결 관계	서브넷 하나는 한 번에 하나의 라우팅 테이블에만 연결된다. 반대로 라우팅 테이블 하나에는 여러 서브넷을 연결할 수 있다
일치 우선순위	경로가 여럿이면 가장 구체적인 경로(최장 접두사 일치)를 쓴다
권장 구성	기본 라우팅 테이블은 원래 상태로 두고, 새 서브넷은 전부 사용자 정의 라우팅 테이블에 명시적으로 연결한다. 새 서브넷이 실수로 인터넷에 열리는 것을 막는다

퍼블릭 · 프라이빗 · VPN 전용

라우팅에 따른 서브넷 유형
유형	라우팅	인터넷 접근
퍼블릭 서브넷	인터넷 게이트웨이로 가는 직접 경로가 있다	가능 — 단 리소스에 퍼블릭 IPv4 또는 IPv6 주소가 있어야 한다
프라이빗 서브넷	인터넷 게이트웨이로 가는 직접 경로가 없다	아웃바운드는 NAT 장치를 거쳐야 하고, 인바운드는 시작할 수 없다
VPN 전용 서브넷	가상 프라이빗 게이트웨이를 통해 Site-to-Site VPN으로 가는 경로가 있다	인터넷 게이트웨이 경로가 없다

VPC 사용 설명서는 이 구분을 못 박는 문장을 하나 더 둡니다 — 프라이빗 서브넷의 인스턴스는 퍼블릭 IP 주소를 가지고 있어도 인터넷 게이트웨이를 통해 인터넷과 통신할 수 없습니다. 경로가 없기 때문입니다. "퍼블릭 IP를 붙였는데 왜 안 되나"의 답이 여기 있습니다.

describe-route-tables.sh — 서브넷이 어느 라우팅 테이블을 쓰는지 확인 (리소스 ID는 예시입니다)

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId,NatGatewayId]' \
  --output table

# 결과에서 0.0.0.0/0 의 대상이 igw- 로 시작하면 퍼블릭 서브넷입니다.

인터넷 게이트웨이와 NAT 게이트웨이

두 가지 아웃바운드 경로 — 퍼블릭 서브넷의 인스턴스는 퍼블릭 IP를 달고 인터넷 게이트웨이로 직접 나가고, 프라이빗 서브넷의 인스턴스는 자기 가용 영역의 NAT 게이트웨이를 거쳐 인터넷 게이트웨이로 나갑니다. NAT 게이트웨이는 지정한 서브넷의 가용 영역 안에서만 동작하므로, 가용 영역 하나에만 두면 그 영역이 멈출 때 다른 영역의 인터넷 접근까지 함께 끊깁니다

인터넷 게이트웨이 — 이중화를 걱정하지 않아도 되는 것

인터넷 게이트웨이는 VPC 사용 설명서의 표현으로 "수평 확장되고, 이중화되어 있으며, 고가용성인 VPC 구성 요소"이고 "가용성 위험이나 대역폭 제약을 만들지 않습니다." VPC마다 하나를 연결하면 되고, 가용 영역마다 만들 필요가 없습니다. 이 성질이 NAT 게이트웨이와 정반대라는 점이 이 절의 핵심입니다.

인터넷 게이트웨이는 IPv4 통신에 대해 일대일 네트워크 주소 변환(NAT)도 수행합니다. 인스턴스는 자기 사설 IP만 알고 있고, 트래픽이 나갈 때 인터넷 게이트웨이가 응답 주소를 퍼블릭 IP나 탄력적 IP로 바꿔 줍니다. IPv6 주소는 그 자체가 퍼블릭이므로 NAT가 필요 없습니다.

인터넷 게이트웨이로 통신하려면 두 가지가 동시에 필요합니다 — 라우팅 테이블에 경로가 있어야 하고, 리소스에 퍼블릭 IPv4 주소나 IPv6 주소가 있어야 합니다. 하나만 있으면 통신이 되지 않습니다.

NAT 게이트웨이 — 나가기만 하는 문

프라이빗 서브넷의 인스턴스도 패치를 받거나 외부 API를 호출해야 합니다. NAT 게이트웨이는 아웃바운드 연결은 허용하되 인터넷에서 시작하는 인바운드 연결은 받지 않는 장치입니다.

퍼블릭 NAT 게이트웨이와 프라이빗 NAT 게이트웨이
유형	배치와 동작	탄력적 IP
퍼블릭 (기본값)	퍼블릭 서브넷에 만들고, 라우팅 테이블에서 인터넷 게이트웨이로 트래픽을 보낸다. 프라이빗 서브넷의 인스턴스가 인터넷에 나갈 수 있게 한다	생성 시 반드시 연결한다
프라이빗	다른 VPC나 온프레미스로 나가는 통신을 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 처리한다. 인터넷으로는 나가지 않는다	연결할 수 없다

프라이빗 NAT 게이트웨이가 있는 VPC에 인터넷 게이트웨이를 붙일 수는 있지만, 프라이빗 NAT 게이트웨이의 트래픽을 인터넷 게이트웨이로 보내면 인터넷 게이트웨이가 그 트래픽을 버립니다.

가용 영역마다 하나 — 단일 장애점을 만들지 않는 법

여기가 이 절에서 가장 자주 출제되는 지점입니다. VPC 사용 설명서의 서술을 그대로 옮기면 이렇습니다 — "각 NAT 게이트웨이는 특정 가용 영역에 만들어지고 그 영역 안에서 이중화되어 구현됩니다." 영역 안에서는 이중화되지만 영역 사이에서는 이중화되지 않습니다.

이어지는 문장이 결론입니다 — "여러 가용 영역에 리소스가 있고 그것들이 NAT 게이트웨이 하나를 공유하는데 그 NAT 게이트웨이의 가용 영역이 다운되면, 다른 가용 영역의 리소스도 인터넷 접근을 잃습니다. 가용 영역에 독립적인 아키텍처를 만들려면 가용 영역마다 NAT 게이트웨이를 만들고 리소스가 자기 가용 영역의 NAT 게이트웨이를 쓰도록 라우팅을 구성하십시오."

이유가 하나 더 있습니다. 비용입니다. 같은 문서는 "가용 영역 사이로 상당한 양의 트래픽을 주고받는다면 리소스를 NAT 게이트웨이와 같은 가용 영역에 두거나, 리소스와 같은 가용 영역에 NAT 게이트웨이를 만들라"고 권고합니다. NAT 게이트웨이 하나로 몰면 가용성이 떨어지는 동시에 가용 영역 간 데이터 전송 요금까지 붙습니다.

가용 영역 두 곳에 프라이빗 서브넷을 만들고, NAT 게이트웨이는 한 곳에만 둡니다. 두 프라이빗 라우팅 테이블이 같은 NAT 게이트웨이를 가리킵니다. 그 가용 영역이 멈추면 양쪽 모두 인터넷 접근을 잃고, 평상시에도 가용 영역을 넘는 트래픽에 요금이 붙습니다.

가용 영역마다 퍼블릭 서브넷에 NAT 게이트웨이를 하나씩 두고, 각 가용 영역의 프라이빗 라우팅 테이블이 같은 가용 영역의 NAT 게이트웨이를 가리키게 합니다. 한쪽 가용 영역이 멈춰도 다른 쪽은 그대로 나가고, 가용 영역을 넘는 트래픽도 생기지 않습니다.

가용 영역별 프라이빗 라우팅 테이블 구성 (리소스 ID는 예시입니다)

aws ec2 create-route \
  --route-table-id rtb-0aaaaaaaaaaaaaaa1 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0111111111111111a

aws ec2 create-route \
  --route-table-id rtb-0bbbbbbbbbbbbbbb2 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0222222222222222b

NAT 게이트웨이와 NAT 인스턴스

NAT 게이트웨이와 NAT 인스턴스 비교
항목	NAT 게이트웨이	NAT 인스턴스
관리 주체	AWS 완전 관리형	사용자가 직접 운영하는 EC2 인스턴스
가용 영역 이중화	지정한 가용 영역 안에서만 이중화. 영역마다 만들어야 한다	사용자가 직접 구성해야 한다
보안 그룹	연결할 수 없다 — 통제는 인스턴스 쪽 보안 그룹과 서브넷 네트워크 ACL로 한다	연결할 수 있다
배스천 호스트 겸용	불가	가능
포트 포워딩	불가	가능

"NAT 게이트웨이에는 보안 그룹을 붙일 수 없다"가 시험에 자주 나오는 비대칭입니다. "NAT 게이트웨이의 보안 그룹을 수정한다"는 선택지가 보이면 그 자리에서 소거합니다.

보안 그룹과 네트워크 ACL SAA 빈출

VPC에는 트래픽을 통제하는 계층이 두 개 있습니다. 보안 그룹은 리소스(ENI) 앞에, 네트워크 ACL은 서브넷 경계에 놓입니다. 시험이 반복해서 묻는 것은 이 배치가 아니라 상태 저장 여부입니다.

요청 패킷과 응답 패킷이 지나는 네 구간 — 상태 저장인 보안 그룹은 요청을 허용하면 응답도 규칙 없이 통과시키지만, 상태 비저장인 네트워크 ACL은 응답 패킷을 별도의 아웃바운드 규칙으로 명시 허용해야 합니다. 임시 포트 범위를 열지 않으면 응답이 서브넷 경계에서 막힙니다

보안 그룹 — 허용만 있고 거부는 없다

VPC 사용 설명서가 나열하는 보안 그룹 규칙의 성질은 다음과 같습니다.

허용(allow) 규칙만 지정할 수 있고 거부(deny) 규칙은 지정할 수 없습니다.
새로 만든 보안 그룹에는 인바운드 규칙이 하나도 없습니다. 규칙을 추가하기 전까지 인바운드 트래픽은 전부 차단됩니다.
새로 만든 보안 그룹에는 모든 아웃바운드를 허용하는 규칙이 하나 들어 있습니다. 지울 수 있으며, 아웃바운드 규칙이 하나도 없으면 아웃바운드가 전부 막힙니다.
리소스에 보안 그룹을 여러 개 붙이면 모든 규칙이 합쳐져 하나의 규칙 집합으로 평가됩니다.
규칙을 바꾸면 그 보안 그룹이 붙은 모든 리소스에 자동으로 반영됩니다.

첫 번째 항목이 가장 중요합니다. "보안 그룹으로 특정 IP를 차단한다"는 선택지는 언제나 오답입니다. 차단은 네트워크 ACL이나 상위 계층(AWS WAF, AWS Network Firewall)의 일입니다.

보안 그룹 참조 — CIDR 대신 그룹 ID를 쓴다

규칙의 소스와 대상에는 IPv4/IPv6 주소나 CIDR 블록, 관리형 접두사 목록 ID, 그리고 다른 보안 그룹의 ID를 쓸 수 있습니다. 보안 그룹 ID를 소스로 쓰면 그 보안 그룹에 속한 모든 인스턴스가 사설 IP로 통신할 수 있게 됩니다.

보안 그룹 참조로 만드는 계층 방어 — 로드 밸런서 보안 그룹, 애플리케이션 보안 그룹, 데이터베이스 보안 그룹을 차례로 참조하면 각 계층은 바로 앞 계층에서 오는 트래픽만 받습니다. 소스가 CIDR이 아니라 보안 그룹 ID이므로 인스턴스가 늘거나 IP가 바뀌어도 규칙을 고치지 않습니다

tier-chaining.sh — 데이터베이스 계층이 애플리케이션 계층에서만 접근받게 한다 (리소스 ID는 예시입니다)

aws ec2 authorize-security-group-ingress \
  --group-id sg-0db0000000000000d \
  --protocol tcp \
  --port 5432 \
  --source-group sg-0app000000000000a

이 방식이 CIDR보다 나은 이유는 주소를 관리하지 않아도 되기 때문입니다. 오토스케일링으로 인스턴스가 늘어나도, 인스턴스가 교체되어 사설 IP가 바뀌어도 규칙은 그대로 유효합니다.

네트워크 ACL — 번호 순서대로, 상태를 기억하지 않고

네트워크 ACL은 서브넷 경계에서 동작합니다. 성질은 다음과 같습니다.

VPC에는 수정 가능한 기본 네트워크 ACL이 함께 만들어지며, 기본값은 모든 인바운드와 아웃바운드를 허용합니다.
서브넷 하나는 반드시 네트워크 ACL 하나에 연결됩니다. 명시적으로 연결하지 않으면 기본 네트워크 ACL에 자동으로 연결됩니다. 반대로 네트워크 ACL 하나는 여러 서브넷에 연결할 수 있습니다.
인바운드 규칙과 아웃바운드 규칙이 따로 있고, 각 규칙은 허용이나 거부가 될 수 있습니다.
규칙 번호는 1부터 32766까지이며, 가장 낮은 번호부터 순서대로 평가합니다. 트래픽이 어떤 규칙에 일치하면 그 규칙이 적용되고 더 이상의 규칙은 평가하지 않습니다.
모든 네트워크 ACL에는 규칙 번호가 별표(*)인 규칙이 있어서, 어떤 번호 규칙에도 일치하지 않은 패킷을 거부합니다. 이 규칙은 수정하거나 삭제할 수 없습니다.

규칙 번호는 100, 110, 120처럼 간격을 두고 매기는 것이 권장됩니다. 연속 번호로 매기면 나중에 규칙을 사이에 끼울 때 전부 다시 번호를 매겨야 합니다. 거부 규칙은 허용 규칙보다 앞 번호에 두어야 의미가 있습니다 — 뒤에 두면 이미 허용으로 판정이 끝나 있습니다.

상태 저장과 상태 비저장 — 응답 트래픽이 갈리는 지점

VPC 사용 설명서의 비교표에서 마지막 줄이 이 절의 결론입니다 — 보안 그룹은 상태 저장이라 규칙과 무관하게 반환 트래픽이 허용되고, 네트워크 ACL은 상태 비저장이라 반환 트래픽을 규칙으로 명시 허용해야 합니다.

구체적으로 무슨 일이 벌어지는지 보겠습니다. 서브넷의 웹 서버가 인터넷의 클라이언트에게 HTTP로 응답한다고 하면, 요청은 80번 포트로 들어오지만 응답은 클라이언트가 고른 임시 포트로 나갑니다. 보안 그룹은 이 응답을 자동으로 통과시키지만, 네트워크 ACL에서는 아웃바운드 규칙에 임시 포트 범위를 열어 두지 않으면 응답이 막힙니다.

VPC 사용 설명서의 예제 네트워크 ACL은 임시 포트 범위로 32768-65535를 씁니다. 다만 임시 포트 범위는 요청을 시작한 클라이언트의 운영체제가 정하므로 범위가 서로 다릅니다. 그래서 같은 문서는 공개 인스턴스를 향해 들어올 수 있는 여러 종류의 클라이언트를 모두 커버하려면 1024-65535를 열 수 있다고 안내하고, 그 범위 안의 악성 포트는 넓은 허용 규칙보다 앞 번호에 거부 규칙을 두어 막으라고 덧붙입니다.

보안 그룹과 네트워크 ACL 비교
항목	보안 그룹	네트워크 ACL
적용 계층	인스턴스 수준 (ENI)	서브넷 수준
적용 대상	연결된 리소스에만 적용된다	연결된 서브넷의 모든 리소스에 적용된다
규칙 종류	허용 규칙만	허용과 거부 모두
평가 방식	모든 규칙을 평가한 뒤 판단	가장 낮은 번호부터 순서대로, 일치하면 즉시 종료
상태	상태 저장(stateful) — 반환 트래픽 자동 허용	상태 비저장(stateless) — 반환 트래픽을 명시 허용해야 한다
소스·대상 지정	CIDR, 접두사 목록 ID, 다른 보안 그룹 ID	CIDR만
연결 관계	리소스 하나에 여러 개를 붙일 수 있다	서브넷 하나에 하나만 (ACL 하나는 여러 서브넷에 가능)
기본값	인바운드 없음, 아웃바운드 전체 허용	기본 네트워크 ACL은 인바운드·아웃바운드 전체 허용

어느 쪽으로 통제할지 헷갈릴 필요는 없습니다. 같은 문서가 정리해 둡니다 — 보안 그룹만으로도 리소스를 보호할 수 있고, 네트워크 ACL은 추가 방어 계층으로 얹는 것입니다. 전체 비교는 헷갈리는 쌍 비교에도 정리해 두었습니다.

VPC Flow Logs — 무엇을 볼 수 있고 무엇을 볼 수 없는가

VPC Flow Logs는 VPC 안의 네트워크 인터페이스를 드나드는 IP 트래픽 정보를 기록합니다. VPC · 서브넷 · 개별 네트워크 인터페이스 중 어느 수준에서나 만들 수 있고, 서브넷이나 VPC에 만들면 그 안의 모든 네트워크 인터페이스가 감시 대상이 됩니다.

Flow Logs가 잡는 경계 — 캡처 지점은 네트워크 인터페이스이고 레코드에는 출발지·목적지 주소와 포트, 프로토콜, 바이트 수, 그리고 ACCEPT와 REJECT 판정이 남지만 패킷의 페이로드는 남지 않습니다. 통신 내용 자체를 봐야 한다면 Flow Logs가 아니라 트래픽 미러링이 답입니다

기본 동작

VPC Flow Logs의 설정 항목과 확인된 값
항목	값	비고
대상 리소스	VPC · 서브넷 · 네트워크 인터페이스	Transit Gateway와 그 연결에도 만들 수 있다
캡처할 트래픽	`ACCEPT` · `REJECT` · `ALL`	거부된 트래픽만 따로 볼 수 있다
게시 대상	Amazon CloudWatch Logs · Amazon S3 · Amazon Data Firehose	S3에 쌓아 Amazon Athena로 조회하는 구성이 흔하다
집계 간격	10분(기본) 또는 1분	Nitro 기반 인스턴스의 ENI는 설정과 무관하게 1분 이하
성능 영향	없음	트래픽 경로 바깥에서 수집하므로 처리량과 지연에 영향을 주지 않는다
설정 변경	불가	만든 뒤에는 구성이나 레코드 형식을 바꿀 수 없다. 지우고 다시 만들어야 한다

각 레코드는 집계 간격 동안의 흐름 하나를 나타내며, 기본 형식은 네트워크 인터페이스 단위의 5-튜플(출발지 주소·포트, 목적지 주소·포트, 프로토콜)로 특징지어집니다.

기록되지 않는 트래픽

VPC 사용 설명서는 "Flow Logs가 모든 IP 트래픽을 잡지는 않는다"고 명시하고 다음 유형을 제외합니다.

인스턴스가 Amazon DNS 서버에 보내는 트래픽 (직접 운영하는 DNS 서버로 가는 트래픽은 기록된다)
Windows 인스턴스의 라이선스 활성화 트래픽
169.254.169.254로 오가는 인스턴스 메타데이터 트래픽
169.254.169.123으로 오가는 Amazon Time Sync Service 트래픽
DHCP 트래픽
미러링된 트래픽
기본 VPC 라우터의 예약 IP 주소로 가는 트래픽
엔드포인트 네트워크 인터페이스와 Network Load Balancer 네트워크 인터페이스 사이의 트래픽

여기에 하나를 더 기억합니다. Flow Logs는 실시간 로그 스트림이 아닙니다. 같은 문서가 "Flow Logs는 네트워크 인터페이스의 실시간 로그 스트림을 캡처하지 않는다"고 못 박습니다. 즉시 대응이 필요한 탐지에는 맞지 않습니다.

DHCP 옵션 세트

VPC 안의 인스턴스는 Amazon DHCP 서버에서 IP 주소 임대와 네트워크 구성 정보를 받습니다. DHCP 옵션 세트는 그 구성 정보를 우리가 지정하는 수단이며, VPC 사용 설명서의 표현으로는 "VPC 안 장치가 사용하는 DNS 서버 · 도메인 이름 · NTP 서버를 제어"하고 "VPC의 DNS 해석을 완전히 끌 수도" 있습니다.

DHCP 옵션 세트의 주요 옵션
옵션	내용
`domain-name-servers`	최대 4개의 DNS 서버 IP 주소 또는 `AmazonProvidedDNS`. 여러 개는 쉼표로 구분한다
`domain-name`	정규화되지 않은 호스트 이름을 완성할 때 붙는 도메인 이름. `AmazonProvidedDNS`를 쓰면 `us-east-1`은 `ec2.internal`, 그 밖의 리전은 `리전코드.compute.internal`
`ntp-servers`	NTP 서버 주소

DHCP 옵션 세트를 만들어 VPC에 연결하면 기존 인스턴스와 새로 시작하는 인스턴스가 모두 그 옵션을 사용합니다. 온프레미스의 Active Directory DNS를 VPC 인스턴스가 바라보게 만드는 하이브리드 구성에서 이 기능이 쓰입니다.

흔한 오해

시험 포인트 정리

이 장의 대부분은 보안 아키텍처 설계(30%)에 속하고, NAT 게이트웨이의 이중화만 복원력 있는 아키텍처 설계(26%)와 비용 최적화에 함께 걸칩니다.

3장 핵심 암기 항목과 함정
항목	사실	함정
퍼블릭 서브넷의 정의	라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는 서브넷	이름이나 퍼블릭 IP 자동 할당 설정으로 판단
인터넷 통신의 두 조건	경로 + 퍼블릭 IPv4 또는 IPv6 주소 둘 다 필요	퍼블릭 IP만 붙이고 통신이 될 것으로 기대
서브넷과 가용 영역	서브넷은 가용 영역 하나에만 존재하고 걸칠 수 없다	서브넷 하나로 다중 가용 영역을 만족시키려 함
서브넷 예약 주소	각 서브넷의 처음 4개 + 마지막 1개 = 5개를 쓸 수 없다	`/28`에 16대를 배치하려는 계산
CIDR 크기	VPC와 서브넷 모두 `/16` ~ `/28`. 서브넷 CIDR은 생성 후 변경 불가	나중에 늘리면 된다고 가정
기본 라우팅 테이블	명시적으로 연결되지 않은 서브넷을 담당하고 삭제할 수 없다	새 서브넷이 기본 라우팅 테이블을 상속한다는 사실을 놓쳐 의도치 않게 노출
경로 우선순위	가장 구체적인 경로(최장 접두사 일치)가 이긴다	`0.0.0.0/0`이 항상 적용된다고 가정
인터넷 게이트웨이	수평 확장·이중화·고가용성. VPC마다 하나면 충분하다	가용 영역마다 만들어야 한다고 생각
NAT 게이트웨이 이중화	지정한 가용 영역 안에서만 이중화. 가용 영역마다 만들어야 한다	관리형이니 자동으로 다중 가용 영역이라고 답함
NAT 게이트웨이와 보안 그룹	보안 그룹을 연결할 수 없다 (NAT 인스턴스는 가능)	"NAT 게이트웨이의 보안 그룹을 수정한다"는 선택지
NAT 게이트웨이의 방향	아웃바운드만. 인터넷에서 시작하는 인바운드는 받지 않는다	NAT 게이트웨이로 인바운드 서비스를 노출하려 함
프라이빗 NAT 게이트웨이	Transit Gateway나 가상 프라이빗 게이트웨이로만 나간다. 탄력적 IP를 붙일 수 없다	퍼블릭과 프라이빗을 구분하지 않고 답함
보안 그룹의 규칙	허용 규칙만 지원한다	"보안 그룹으로 특정 IP를 차단"이라는 선택지
보안 그룹 기본값	인바운드 없음, 아웃바운드 전체 허용	새 보안 그룹이 아무것도 막지 않는다고 가정
보안 그룹의 평가	모든 규칙을 평가하고, 여러 개를 붙이면 규칙이 합쳐진다	순서가 있다고 생각
보안 그룹 참조	소스에 다른 보안 그룹 ID를 쓸 수 있다. IP가 바뀌어도 규칙이 유효하다	계층 간 통신을 CIDR로 고정해 확장 때마다 규칙을 고침
네트워크 ACL의 상태	상태 비저장 — 반환 트래픽을 규칙으로 명시 허용해야 한다	인바운드만 열고 응답이 오지 않는 이유를 못 찾음
임시 포트	예제 범위는 `32768-65535`. 클라이언트 종류를 넓게 커버하려면 `1024-65535`	응답 포트를 80이나 443으로 열어 둠
네트워크 ACL의 평가	규칙 번호 1–32766, 낮은 번호부터 평가하고 일치하면 종료	거부 규칙을 허용 규칙보다 뒤 번호에 두어 효과가 없음
네트워크 ACL의 별표 규칙	어떤 규칙에도 맞지 않으면 거부. 수정·삭제 불가	기본 거부가 없다고 가정
연결 관계	서브넷 하나에 네트워크 ACL 하나, 리소스 하나에 보안 그룹 여러 개	서브넷에 네트워크 ACL을 여러 개 붙이려 함
Flow Logs가 남기는 것	5-튜플 · 바이트 수 · `ACCEPT`/`REJECT` 판정. 페이로드는 남지 않는다	"통신 내용 감사"에 Flow Logs를 답으로 고름 (트래픽 미러링이 맞다)
Flow Logs의 지연	실시간 스트림이 아니다. 집계 간격은 10분 기본, 1분 선택	즉시 탐지·차단 요구에 Flow Logs를 답으로 고름
DHCP 옵션 세트	DNS 서버 최대 4개, 도메인 이름, NTP 서버를 지정한다	온프레미스 DNS 연동에 다른 수단을 찾음

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

Amazon VPC 사용 설명서 — VPC와 서브넷의 IP 주소 지정 — VPC는 /16~/28 CIDR을 최대 5개, 서브넷은 /16~/28이라는 크기 제약, VPC CIDR에서 인터넷으로 직접 나갈 수 없고 게이트웨이를 거쳐야 한다는 서술
Amazon VPC 사용 설명서 — 서브넷 CIDR 블록 — 서브넷마다 처음 네 개와 마지막 한 개 주소가 예약된다는 사실과 각 주소의 용도
Amazon VPC 사용 설명서 — VPC의 서브넷 — 서브넷이 가용 영역 하나 안에만 존재한다는 제약, 퍼블릭·프라이빗·VPN 전용 서브넷의 정의
Amazon VPC 사용 설명서 — 기본 VPC — 기본 VPC의 172.31.0.0/16 CIDR과 가용 영역마다 만들어지는 /20 기본 서브넷
Amazon VPC 사용 설명서 — 라우팅 테이블 — 기본 라우팅 테이블을 삭제할 수 없다는 점, 로컬 경로가 모든 라우팅 테이블에 기본으로 들어간다는 점, 서브넷은 한 번에 라우팅 테이블 하나에만 연결된다는 점, 최장 접두사 일치 규칙
Amazon VPC 사용 설명서 — 인터넷 게이트웨이 — 수평 확장·이중화·고가용성이며 가용성 위험이나 대역폭 제약을 만들지 않는다는 서술, IPv4에 대한 일대일 NAT 수행, 프라이빗 서브넷의 인스턴스는 퍼블릭 IP가 있어도 인터넷 게이트웨이로 통신할 수 없다는 서술
Amazon VPC 사용 설명서 — NAT 게이트웨이 — 각 NAT 게이트웨이가 특정 가용 영역에 만들어져 그 영역 안에서만 이중화된다는 서술, 가용 영역마다 NAT 게이트웨이를 만들라는 권고, 가용 영역 간 트래픽에 대한 배치 권고, NAT 게이트웨이에 보안 그룹을 연결할 수 없다는 서술, 퍼블릭과 프라이빗 NAT 게이트웨이의 차이
Amazon VPC 사용 설명서 — VPC의 내부 트래픽 프라이버시 — 보안 그룹과 네트워크 ACL의 공식 비교표(적용 계층, 허용·거부 규칙, 평가 방식, 상태 저장 여부)
Amazon VPC 사용 설명서 — 보안 그룹 규칙 — 허용 규칙만 지원한다는 점, 새 보안 그룹의 기본 인바운드·아웃바운드 상태, 여러 보안 그룹의 규칙이 합쳐진다는 점, 소스·대상으로 CIDR·접두사 목록·보안 그룹 ID를 쓸 수 있다는 점
Amazon VPC 사용 설명서 — 네트워크 ACL — 기본 네트워크 ACL이 전체 허용이라는 점, 서브넷 하나는 네트워크 ACL 하나에만 연결된다는 점, 규칙 번호 1–32766과 낮은 번호부터의 평가, 별표 규칙을 수정·삭제할 수 없다는 점, 임시 포트 범위 32768-65535와 1024-65535에 대한 안내
Amazon VPC 사용 설명서 — VPC Flow Logs — VPC·서브넷·네트워크 인터페이스 수준의 생성, ACCEPT/REJECT/ALL 선택, CloudWatch Logs·S3·Firehose 게시, 실시간 스트림이 아니라는 서술, 트래픽 경로 밖에서 수집하므로 성능에 영향이 없다는 서술, 집계 간격과 Nitro 인스턴스 예외, 기록되지 않는 트래픽 목록
Amazon VPC 사용 설명서 — DHCP 옵션 세트 — DNS 서버·도메인 이름·NTP 서버를 제어하고 DNS 해석을 끌 수 있다는 서술
Amazon EC2 API 레퍼런스 — CreateSubnet — 허용되는 서브넷 크기와 예약 주소, 서브넷 생성 후 CIDR을 바꿀 수 없다는 서술
Amazon EC2 API 레퍼런스 — CreateNatGateway — 지정한 서브넷에 네트워크 인터페이스를 만든다는 동작과 퍼블릭·프라이빗 연결 유형
Amazon EC2 API 레퍼런스 — CreateNetworkAclEntry — 인바운드와 아웃바운드 규칙이 별도이고 번호 오름차순으로 처리된다는 서술, 규칙 번호에 간격을 두라는 권고
Amazon EC2 API 레퍼런스 — CreateFlowLogs — 집계 간격이 60초 또는 600초이고 기본값이 600초라는 점, 캡처 대상 트래픽 유형
Amazon EC2 API 레퍼런스 — CreateDhcpOptions — DNS 서버를 최대 4개까지 지정할 수 있다는 점과 domain-name의 리전별 기본값
Amazon EC2 API 레퍼런스 — CreateSecurityGroup — 기본 보안 그룹의 동작과 인스턴스 시작 시 보안 그룹을 지정하지 않았을 때의 처리