클라우드 네트워크 기초: VPC/Subnet/보안그룹

이 글에서 얻는 것

• VPC/CIDR를 “아무 숫자”가 아니라, 확장/피어링/온프렘 연결까지 고려해 설계할 수 있습니다.
• 퍼블릭/프라이빗 서브넷이 라우팅으로 결정된다는 걸 이해하고, 트래픽 흐름(IGW/NAT/Route Table)을 그릴 수 있습니다.
• Security Group과 NACL의 차이를 운영 관점(디버깅/실수 포인트)으로 설명하고, 최소 권한 규칙을 세울 수 있습니다.
• “접속 안 됨/타임아웃” 같은 네트워크 이슈를 계층적으로(라우트→방화벽→DNS→앱) 점검하는 루틴이 생깁니다.

0) 백엔드가 네트워크를 알아야 하는 이유

운영에서 마주치는 문제는 대개 네트워크 증상으로 시작합니다.

• timeout / connection refused
• 5xx(특히 502/504) 증가
• 특정 AZ/특정 경로에서만 느려짐

트래픽이 어디로 어떻게 흐르는지(라우팅/방화벽/로드밸런서)를 그릴 수 있으면 문제 범위를 빠르게 좁힐 수 있습니다.

1) VPC와 CIDR: 주소 계획이 설계를 결정한다

VPC는 “격리된 가상 네트워크”이고, CIDR은 그 네트워크의 주소 공간입니다.

• /16 → 65,536개 IP
• /20 → 4,096개 IP
• /24 → 256개 IP(클라우드에 따라 일부는 예약되어 실제 사용 가능 IP가 더 적습니다)

처음에 CIDR를 대충 잡으면 나중에 다음이 매우 어려워집니다.

• VPC 피어링/Transit Gateway/VPN으로 다른 네트워크와 연결
• 환경(DEV/PROD) 분리, 멀티 리전 확장
• Kubernetes 같은 IP 소비가 큰 워크로드 수용(노드/파드가 IP를 많이 씁니다)

실무 감각:

• “지금 필요한 만큼”이 아니라 “2~3년 뒤 예상”을 포함해 잡는 편이 안전합니다.
• 온프렘/다른 VPC와 겹치지 않게(주소 중복) 계획해야 연결이 쉬워집니다.

2) Subnet: 퍼블릭/프라이빗은 ‘이름’이 아니라 라우팅이다

퍼블릭/프라이빗은 “어디에 두었다”가 아니라 라우팅 테이블이 어떻게 되어 있느냐로 결정됩니다.

• 퍼블릭 서브넷: 0.0.0.0/0이 Internet Gateway(IGW)로 향한다
• 프라이빗 서브넷: 인터넷으로 나가는 기본 경로가 없거나, NAT로만 나간다

그리고 보통 AZ(가용영역) 단위로 서브넷을 쪼갭니다.

• AZ-a 퍼블릭 / AZ-b 퍼블릭
• AZ-a 프라이빗(앱) / AZ-b 프라이빗(앱)
• AZ-a 프라이빗(DB) / AZ-b 프라이빗(DB)

멀티 AZ는 “가용성”뿐 아니라 “운영 중 장애가 특정 AZ에 국한되는지”를 판단하는 데도 도움 됩니다.

3) 라우팅 구성요소: IGW, NAT, Route Table, VPC Endpoint

3-1) IGW(Internet Gateway)

VPC가 인터넷과 통신하려면 IGW가 필요합니다.

• 퍼블릭 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW가 있어야 합니다.
• 로드밸런서(ALB/NLB)가 보통 퍼블릭 서브넷에 위치합니다.

3-2) NAT Gateway(프라이빗 서브넷의 아웃바운드)

프라이빗 서브넷의 인스턴스가 외부로 나가야 할 때(패키지 다운로드, 외부 API 호출 등) NAT를 사용합니다.

• NAT는 보통 퍼블릭 서브넷에 둡니다(Elastic IP를 붙임).
• 프라이빗 서브넷 라우팅 테이블에 0.0.0.0/0 → NAT를 둡니다.

운영 팁:

• NAT는 “시간당 + 전송량당” 비용이 붙는 경우가 많습니다. 트래픽이 커지면 비용이 눈에 띄게 증가합니다.
• 멀티 AZ에서 “각 AZ에 NAT를 둔다 vs 하나로 공유한다”는 비용/가용성/교차 AZ 트래픽을 함께 보고 결정합니다.

3-3) VPC Endpoint(가능하면 인터넷/자연스러운 egress를 줄인다)

클라우드 서비스(S3/ECR/Secrets 등)를 자주 쓰는 경우, VPC Endpoint를 쓰면 “인터넷을 거치지 않고” 사설 네트워크로 접근할 수 있습니다.

• 보안: 외부 egress를 줄이고 정책을 더 명확히 할 수 있음
• 비용: NAT를 경유하는 트래픽을 줄여 비용이 크게 절감되는 경우가 있음

4) Security Group vs NACL: 어디에서 무엇을 막을 것인가

둘 다 “방화벽”이지만 성격이 다릅니다.

실무에서는 보통:

• SG로 “서비스 간 통신 규칙”을 만들고(서로 SG 참조),
• NACL은 크게 단순하게 두거나(기본 allow), 필요한 차단만 신중하게 추가합니다.

NACL을 복잡하게 만들면 “왜 안 되지?”가 아주 힘들어집니다(특히 응답 트래픽/임시 포트).

5) 자주 겪는 장애 패턴(디버깅 루틴)

네트워크 문제는 “한 번에” 보지 말고 층별로 확인합니다.

1. 경로: 클라이언트 → (DNS) → LB → Target
2. 라우트: Route Table에 경로가 있는가(IGW/NAT/Peering/Endpoint)
3. 방화벽: SG 인바운드/아웃바운드, NACL 인바운드/아웃바운드
4. DNS: 올바른 레코드/사설 DNS/리졸버인가
5. 애플리케이션: 프로세스가 포트를 리슨하는가, 헬스체크는 성공하는가

5-1) “외부에서 접속이 안 된다”

가장 흔한 원인:

• 퍼블릭 서브넷이 아닌데 외부에서 직접 붙으려 한다(구조 자체가 잘못됨)
• 로드밸런서 SG 인바운드가 닫혀 있다(443/80)
• 타깃 SG가 “로드밸런서 SG”를 허용하지 않는다(타깃 포트)
• 라우팅 테이블에 0.0.0.0/0 → IGW가 없다(퍼블릭 서브넷이 아님)

5-2) “아웃바운드만 타임아웃이다”

대개 프라이빗 서브넷에서 발생합니다.

• 프라이빗 서브넷 라우팅 테이블에 0.0.0.0/0 → NAT가 없다
• SG egress가 과하게 막혀 있다
• NACL outbound/return path가 막혀 있다
• 외부 호출이 사실상 “클라우드 내부 서비스”인데 NAT를 타고 있다(Endpoint로 개선 가능)

5-3) “같은 VPC인데 서비스 간 통신이 안 된다”

• SG에서 대상 포트가 허용되지 않았다(특히 타깃이 DB/캐시일 때)
• NACL을 쓰고 있다면 임시 포트(응답 트래픽)까지 고려했는지 확인
• 서로 다른 서브넷/라우팅 테이블이 예상과 다르다(특히 Peering/Transit 연결 시)

5-4) “IP가 부족하다”(서브넷 고갈)

Kubernetes/ECS 같은 환경에서는 IP 소비가 빠르게 늘 수 있습니다.

• 서브넷을 너무 작게(/24 등) 잡으면 노드/파드가 늘 때 고갈이 먼저 옵니다.
• “스케일이 안 된다”가 사실은 “IP가 없다”인 경우가 많습니다.

5-5) “NAT 비용이 너무 많이 나온다”

많이 보는 케이스:

• S3/ECR 같은 클라우드 서비스 접근이 전부 NAT를 탄다
• 크로스 AZ로 NAT를 타면서 데이터 전송 비용도 함께 오른다

대응 아이디어:

• VPC Endpoint 도입(S3/ECR/Secrets 등) 검토
• CDN/캐시로 외부 트래픽을 줄이기
• 아키텍처 상 egress가 큰 작업(대용량 파일 처리 등)을 별도로 분리해 비용을 통제

6) 최소 설계 템플릿(예시)

가장 흔한 “웹 서비스 기본형”은 아래 형태입니다.

Internet
  |
[ALB/NLB in public subnets]   (AZ-a, AZ-b)
  |
[App in private subnets]      (AZ-a, AZ-b)  -> NAT/Endpoint
  |
[DB/Cache in private subnets] (AZ-a, AZ-b)

핵심 포인트:

• 퍼블릭에는 “진입점(LB/NAT)”만 두고, 앱/DB는 프라이빗에 둔다
• SG는 “누가 누구에게 어떤 포트로 접근 가능한지”를 관계형으로 만든다(가능하면 SG 참조)
• 헬스체크/관측(로그/메트릭)이 가능한 최소 네트워크 경로를 확보한다

연습(추천)

• 내 서비스 트래픽 경로를 한 장으로 그려보기(사용자 → LB → 앱 → DB/캐시 → 외부 API)
• “프라이빗 서브넷에서 외부 호출이 안 되는” 상황을 가정하고, 라우팅/SG/NACL 순서로 원인을 좁혀보는 연습
• NAT 비용이 큰 워크로드를 하나 골라 “Endpoint/캐시/CDN” 중 무엇이 효과적인지 비교해보기