AWS VPC 서브넷·보안그룹·NACL 차이 — 네트워킹 입문 정리
오늘 AWS Cloud Practitioner 네 번째 모듈, "네트워킹"을 끝냈다. 약 80분 걸렸다. 지난번 Module 3 글 마지막에 "리전과 가용 영역으로 위치를 정했으니, 다음은 그 안에서 어떻게 연결하는지 — 길을 깔 차례"라고 적었는데, 정확히 그 단원이었다.
그런데 오늘은 솔직히 한 번 크게 막혔다. 보안 그룹(Security Group)과 네트워크 ACL(NACL). 이름도 비슷하고 둘 다 '방화벽'이라는데, 뭐가 다른지가 한참 안 잡혔다. 그 얘기를 §3에 정리했다.
1. VPC — 내 전용 구역을 클라우드 안에 분양받는 것
VPC(Virtual Private Cloud)는 AWS 클라우드 안에 내가 격리해서 쓰는 전용 네트워크 구역이다. 큰 땅(리전) 안에 울타리를 쳐서 "여기는 내 구역"이라고 분양받는 느낌이었다. 그 구역 안을 다시 잘게 나눈 게 서브넷(Subnet)이다.
| 구분 | 무슨 뜻 |
|---|---|
| 퍼블릭 서브넷 | 인터넷에서 직접 닿을 수 있는 구역. 웹 서버처럼 외부에 보여야 하는 것 |
| 프라이빗 서브넷 | 인터넷에서 직접 못 닿는 구역. DB처럼 숨겨야 하는 것 |
2. 인터넷 게이트웨이와 라우팅 테이블 — 길과 이정표
구역을 나눴으면 길을 내야 한다. 여기서 두 가지가 나왔다.
- 인터넷 게이트웨이(IGW): VPC와 바깥 인터넷을 잇는 정문. 이게 있어야 외부와 통신이 된다.
- 라우팅 테이블(Route Table): "이 목적지로 가려면 어느 문으로 나가라"는 이정표. 퍼블릭 서브넷은 IGW를 가리키는 경로가 있고, 프라이빗 서브넷은 없다.
정리하니 단순했다. 퍼블릭 서브넷이 '퍼블릭'인 이유는 라우팅 테이블에 인터넷 게이트웨이로 가는 길이 적혀 있어서였다. 길이 없으면 같은 구조라도 프라이빗이 된다.
3. 오늘 한참 막힌 곳 — 보안 그룹 vs 네트워크 ACL
둘 다 트래픽을 막거나 허용하는 방화벽인데, 핵심 차이는 "상태를 기억하느냐"였다.
| 보안 그룹 (Security Group) | 네트워크 ACL (NACL) | |
|---|---|---|
| 적용 대상 | 인스턴스(EC2) 단위 | 서브넷 단위 |
| 상태 | 상태 저장(Stateful) | 상태 비저장(Stateless) |
| 규칙 | 허용(Allow)만 가능 | 허용 + 거부(Deny) 둘 다 |
| 비유 | 건물 입구 경비 — 들여보낸 손님은 나갈 때 안 물어봄 | 구역 출입 검문소 — 들어올 때·나갈 때 매번 검사 |
가장 헷갈렸던 게 '상태 저장'이라는 말이었다. 보안 그룹은 들어오는 걸 허용하면 그에 대한 응답(나가는 트래픽)은 자동으로 허용된다. 들여보낸 손님이 나갈 때 다시 안 물어본다. 반면 NACL은 들어올 때 규칙, 나갈 때 규칙을 따로 둬야 한다. 매번 검문한다. 이 한 줄로 겨우 정리됐다.
4. 오늘 막힌 것 (자가 점검)
- 퍼블릭/프라이빗 서브넷의 '진짜' 구분 기준 → 라우팅 테이블에 IGW 경로가 있느냐로 정리.
- 보안 그룹이 왜 '거부' 규칙이 없는지 → 기본이 전부 거부라서, 허용만 추가하면 되기 때문. 이건 처음엔 이해 안 갔다.
회사 다닐 때 사내망 안에서만 측정 장비에 접속했었는데, 그게 사실은 누군가 이런 서브넷과 방화벽 규칙을 다 깔아둔 위에서 가능했던 거였다. 10년 동안 그 밑단을 한 번도 안 들여다봤다…
마무리
전체 13개 모듈 중 네 번째, 약 31%까지 왔다. 위치(M3)를 정하고 길(M4)을 깔았으니, 다음은 그 위에 데이터를 쌓는 곳 — Module 5 스토리지와 데이터베이스 차례다. 집을 지을 땅과 도로가 생겼으니 이제 창고를 들일 차례인 셈이다.
댓글
댓글 쓰기