기준: CLF-C02 시험 가이드오류 제보
서버(EC2)와 스토리지(S3·EBS)를 봤으니, 이제 이것들이 사는 "동네"를 볼 차례다. 클라우드 안에서 내 자원들이 모여 사는 사설 네트워크 공간이 바로 VPC다. CLF-C02는 네트워킹을 깊게 파지 않지만, "VPC가 뭐고 서브넷·보안 그룹·인터넷 게이트웨이가 어떻게 맞물리는가"라는 기본 골격은 반드시 묻는다.
오늘은 집을 짓는 비유로 네트워킹의 네 부품 — VPC(땅), 서브넷(방), 인터넷 게이트웨이(대문), 보안 그룹(문지기) — 을 입문 수준에서 정리한다.
VPC를 이해하는 가장 빠른 길은 회사 사무실의 네트워크를 떠올리는 것이다.
한 회사가 건물 한 층을 쓴다고 가정한다. 인터넷 회선이 하나 들어오고, 거기서 나온 랜선이 각 자리의 PC와 서버실로 뻗는다. 회사 안의 기기끼리는 자유롭게 통신하지만 바깥에서는 이 안이 보이지 않는다. 그리고 층 안에서도 구역을 나눈다 — 손님이 드나드는 로비, 직원만 들어가는 사무 공간, 아무나 못 들어가는 서버실.
클라우드로 옮겨 오면 이 그림이 그대로 이름만 바뀐다.
| 사무실 | AWS |
|---|---|
| 우리 회사가 쓰는 층 전체 | VPC |
| 로비 / 서버실 같은 구역 | 서브넷(퍼블릭 / 프라이빗) |
| 건물 밖으로 나가는 정문 | 인터넷 게이트웨이 |
| 각 방문 앞의 출입 통제 | 보안 그룹 |
| "어디로 가려면 어느 복도로" 안내판 | 라우팅 테이블 |
클라우드 이전에는 이 모든 것이 물리 장비였다. 스위치를 사고, 랜선을 꽂고, 방화벽 장비를 설치하고, 구역을 나누려면 배선을 다시 해야 했다. VPC의 본질은 이 네트워크 구성을 물리 작업 없이 소프트웨어 설정만으로 만들고 바꿀 수 있게 한 것이다. 새 구역을 만드는 데 며칠이 아니라 몇 초가 걸린다.
VPC(Virtual Private Cloud)는 AWS 클라우드 안에 내가 가진 논리적으로 격리된 전용 네트워크다. 다른 사람의 자원과 섞이지 않는, 나만의 사설 공간이다. EC2를 만들면 어딘가의 VPC 안에 들어가서 켜진다.
비유하자면 VPC는 내가 분양받은 땅이다. 이 땅 위에 건물(서버)을 짓고, 구역을 나누고(서브넷), 대문을 달고(인터넷 게이트웨이), 경비를 세운다(보안 그룹).
VPC는 리전(Region) 단위로 만들어지고, 그 안에서 여러 가용 영역(AZ)에 걸쳐 자원을 배치할 수 있다. VPC를 만들 때 IP 주소 범위(CIDR 블록, 예: 10.0.0.0/16)를 정하는데, 이는 "이 땅에서 쓸 수 있는 주소의 범위"를 정하는 일이다. 입문 수준에서는 "VPC = 내 사설 IP 주소 공간"이라고 이해하면 충분하다.
10.0.0.0/16 같은 표기를 처음 보면 암호처럼 보인다. 하지만 CLF-C02가 요구하는 이해는 "주소 범위를 적는 방식"이라는 것 하나뿐이고, 마스크를 계산하는 문제는 나오지 않는다. 슬래시 뒤 숫자는 "앞에서 몇 자리를 고정하는가"이고, 숫자가 클수록 범위가 좁아진다.
10.0.0.0/16 → 앞 두 칸(10.0)이 고정 → 넓은 범위 → VPC 전체에 쓰기 좋음
10.0.1.0/24 → 앞 세 칸(10.0.1)이 고정 → 좁은 범위 → 서브넷 하나에 쓰기 좋음
0.0.0.0/0 → 아무것도 고정하지 않음 → 모든 주소 → "어디서든/어디로든"이라는 뜻
마지막 줄을 특히 기억한다. 보안 그룹 규칙에서 소스가 0.0.0.0/0이면 "누구나 접속 가능", 라우팅 목적지가 0.0.0.0/0이면 "그 밖의 모든 목적지"라는 뜻이다.
⚠️ 함정:
0.0.0.0/0을 SSH(22번 포트) 인바운드에 열어 두는 것은 대표적인 보안 실수다. 웹(80·443)은 누구나 접속해야 하니 자연스럽지만, 관리자 접속 포트는 회사 IP처럼 특정 범위로 좁혀야 한다. "SSH를 전 세계에 열어 둔다"는 보기는 오답이다.
VPC라는 땅을 통째로 쓰기보다, 보통 용도별로 서브넷(Subnet)이라는 작은 구역으로 나눈다. 서브넷은 VPC 안의 IP 주소 범위를 잘게 쪼갠 단위다. 가장 흔한 구분은 다음 두 가지다.
| 서브넷 종류 | 특징 | 두는 자원 예시 |
|---|---|---|
| 퍼블릭 서브넷(Public Subnet) | 인터넷과 직접 통신 가능 | 웹 서버, 로드 밸런서 |
| 프라이빗 서브넷(Private Subnet) | 인터넷에서 직접 접근 불가 | 데이터베이스, 내부 서버 |
핵심은 "인터넷에 노출돼야 하는 것과 숨겨야 하는 것을 분리"하는 것이다. 웹 서버는 외부 요청을 받아야 하니 퍼블릭 서브넷에, 민감한 데이터를 가진 DB는 외부에서 직접 닿지 못하게 프라이빗 서브넷에 둔다.
각 서브넷은 하나의 가용 영역(AZ) 안에 존재한다. 그래서 고가용성을 위해 보통 "AZ-a의 퍼블릭/프라이빗 서브넷, AZ-b의 퍼블릭/프라이빗 서브넷"처럼 여러 AZ에 서브넷을 분산 배치한다. 한 AZ가 장애가 나도 다른 AZ에서 서비스가 계속되도록 하기 위함이다.
⚠️ 함정: 서브넷이 "퍼블릭"이 되는 이유는 단순히 이름 때문이 아니라, 라우팅 테이블이 인터넷 게이트웨이로 가는 경로를 가지고 있기 때문이다. 같은 설정이라도 인터넷 게이트웨이로 가는 경로가 없으면 그 서브넷은 프라이빗이다.
라우팅 테이블(Route Table)은 서브넷마다 붙는 안내판이다. "이 목적지로 가려면 저쪽 문으로"라는 규칙 목록이며, 트래픽은 이 안내판을 보고 다음 행선지를 정한다.
| 목적지 | 대상 | 뜻 |
|---|---|---|
10.0.0.0/16 | local | VPC 안의 주소로 가는 건 내부에서 처리 |
0.0.0.0/0 | 인터넷 게이트웨이 | 그 밖의 모든 곳은 정문으로 내보냄 |
위 두 줄을 가진 서브넷이 퍼블릭 서브넷이다. 둘째 줄이 없으면 VPC 안끼리만 통신할 수 있으니 프라이빗 서브넷이 된다. 딱 한 줄의 차이다.
모든 라우팅 테이블에는 local 경로가 자동으로 들어 있고 지울 수 없다. 그래서 같은 VPC 안의 자원끼리는 별도 설정 없이도 서로 통신할 수 있다(보안 그룹이 허용한다면). "프라이빗 서브넷의 DB에 웹 서버가 접근한다"는 구성이 자연스러운 이유다.
실무에서 가장 흔한 VPC 구성을 그림으로 익혀 두면 문항이 훨씬 빨리 읽힌다.
[ VPC 10.0.0.0/16 ]
── 가용 영역 A ────────── ── 가용 영역 B ──────────
퍼블릭 서브넷 10.0.1.0/24 퍼블릭 서브넷 10.0.2.0/24
· 웹 서버 / 로드 밸런서 · 웹 서버 / 로드 밸런서
· 라우팅: 0.0.0.0/0 → IGW · 라우팅: 0.0.0.0/0 → IGW
프라이빗 서브넷 10.0.11.0/24 프라이빗 서브넷 10.0.12.0/24
· 애플리케이션 / DB · 애플리케이션 / DB
· 라우팅: IGW 경로 없음 · 라우팅: IGW 경로 없음
구조는 두 축으로 잡는다. 위아래로는 퍼블릭·프라이빗을 나눠 노출을 통제하고, 좌우로는 둘 이상의 AZ에 같은 구조를 복제해 한 AZ가 죽어도 서비스가 계속되게 한다. "고가용성(High Availability)을 어떻게 확보하는가"의 가장 기본적인 답이 이 좌우 복제다.
VPC 안의 자원이 인터넷과 통신하려면 인터넷 게이트웨이(Internet Gateway, IGW)가 필요하다. VPC에 달린 대문이라고 보면 된다. 이 대문이 없으면 VPC 안의 어떤 서버도 인터넷으로 나가거나 인터넷에서 들어올 수 없다.
퍼블릭 서브넷의 서버가 인터넷과 통신하는 조건은 두 가지가 맞아야 한다:
프라이빗 서브넷의 서버가 "인터넷에서 들어오는 건 막되, 밖으로 나가는 건(예: 소프트웨어 업데이트) 허용"하고 싶을 때는 NAT 게이트웨이(NAT Gateway)를 쓴다. 입문 수준에서는 "IGW = 양방향 인터넷 통로, NAT = 프라이빗 자원의 단방향(밖으로만) 통로"라는 정도만 구분하면 된다.
프라이빗 서브넷의 DB 서버를 생각해 본다. 외부에서 들어오는 접속은 절대 허용하면 안 된다. 그런데 이 서버도 가끔 밖으로 나갈 일은 있다 — 보안 패치를 내려받고 OS 업데이트를 확인한다. 인터넷 게이트웨이로 가는 경로를 열면 나갈 수는 있지만 동시에 들어오는 문도 열려 버린다.
NAT 게이트웨이가 이 딜레마를 푼다. 프라이빗 서브넷의 트래픽은 퍼블릭 서브넷에 놓인 NAT 게이트웨이를 거쳐 인터넷으로 나가고 응답은 되돌아오지만, 인터넷 쪽에서 먼저 말을 걸 수는 없다. 회사로 치면 "직원은 나가서 물건을 사 올 수 있지만 외부인이 그 통로로 들어올 수는 없는" 후문이다.
[ 프라이빗 서브넷 ] [ 퍼블릭 서브넷 ]
DB 서버 ──────────► NAT 게이트웨이 ──► IGW ──► 인터넷
✗ 인터넷에서 DB 서버로 먼저 접속 시도 → 불가능
함정: NAT 게이트웨이는 퍼블릭 서브넷에 놓여야 한다. 자기 자신이 인터넷으로 나갈 수 있어야 남을 내보내 줄 수 있기 때문이다. "NAT 게이트웨이를 프라이빗 서브넷에 둔다"는 보기는 틀렸다.
자원(특히 EC2)으로 들어오고 나가는 트래픽을 통제하는 것이 보안 그룹(Security Group)이다. 각 EC2 앞에 선 문지기라고 생각하면 된다. "어떤 포트로, 어디서 오는 트래픽을 허용할지"를 규칙으로 정한다.
보안 그룹의 중요한 성질 두 가지:
| 예시 규칙 | 의미 |
|---|---|
| 인바운드 HTTP(80) 허용, 소스 0.0.0.0/0 | 누구나 웹(80포트)으로 접속 가능 |
| 인바운드 SSH(22) 허용, 소스 내 IP만 | 나만 SSH로 서버 접속 가능 |
| (규칙에 없는 모든 인바운드) | 자동 차단 |
보안 그룹과 비슷하지만 다른 것이 네트워크 ACL(NACL)이다. 보안 그룹은 "자원(EC2) 단위"의 문지기이고 상태를 기억하지만(Stateful), NACL은 "서브넷 단위"의 문지기이며 상태를 기억하지 않고(Stateless) 허용·차단 규칙을 모두 쓸 수 있다. 입문 수준에서는 "보안 그룹 = 인스턴스 방화벽(Stateful), NACL = 서브넷 방화벽(Stateless)"으로 구분하면 충분하다.
이 둘의 구분은 CLF-C02 범위에 드는 항목이다. 표로 못 박아 둔다.
| 비교 항목 | 보안 그룹(Security Group) | 네트워크 ACL(NACL) |
|---|---|---|
| 적용 대상 | 인스턴스(정확히는 네트워크 인터페이스) | 서브넷 전체 |
| 규칙 종류 | 허용(Allow)만 | 허용 + 거부(Deny) 모두 |
| 상태 기억 | 상태 저장(Stateful) — 응답 자동 허용 | 상태 비저장(Stateless) — 인·아웃 각각 규칙 필요 |
| 기본 동작 | 명시 허용 외 전부 차단 | 기본 NACL은 모두 허용 |
| 위치 비유 | 각 방문 앞의 경비원 | 층 입구의 검문소 |
상태 저장이라는 말이 특히 헷갈린다. 보안 그룹은 "누가 들어왔는지 기억하는 경비원"이라 방문객이 나갈 때는 따로 묻지 않는다. 반면 NACL은 "아무것도 기억하지 못하는 검문소"라 들어올 때 한 번, 나갈 때 또 한 번 각각 통과 규칙이 있어야 한다.
함정: 상태 비저장의 결과가 그대로 시험에 나온다. NACL에서 인바운드 HTTP(80)만 허용하고 아웃바운드를 열지 않으면 요청은 들어오는데 응답이 나가지 못해 통신이 실패한다. 보안 그룹이라면 이런 일이 없다. "인바운드만 열었는데 왜 안 되는가"가 나오면 NACL을 의심한다.
실무에서는 보통 보안 그룹을 주력으로 쓰고 NACL은 기본값으로 둔다. NACL이 유용해지는 대표 상황은 "특정 IP 대역을 서브넷 전체에서 통째로 막고 싶을 때"다. 보안 그룹은 허용 규칙만 쓸 수 있어 "이 IP만 막기"가 불가능하지만, NACL은 거부(Deny) 규칙으로 한 줄에 차단한다. "특정 IP를 차단해야 한다" = NACL은 그대로 시험 키워드다.
지금까지의 네 부품을 한 장의 집 그림으로 합쳐 본다.
[ VPC = 내 사설 네트워크(땅) ] CIDR 10.0.0.0/16
┌──────────────── Internet Gateway(대문) ────────────────┐
│ │
[ 퍼블릭 서브넷 ] [ 프라이빗 서브넷 ]
라우팅: → IGW 라우팅: IGW 경로 없음
┌───────────────┐ ┌───────────────┐
│ 웹 서버(EC2) │ │ DB 서버(EC2) │
│ ↑ 보안 그룹 │ ──── 내부 통신 ───► │ ↑ 보안 그룹 │
│ (문지기) │ │ (문지기) │
└───────────────┘ └───────────────┘
80 포트 외부 허용 3306 포트 웹서버만 허용
흐름을 따라가 보면: 사용자가 인터넷에서 들어오면 → 인터넷 게이트웨이(대문)를 지나 → 퍼블릭 서브넷의 웹 서버에 닿고 → 웹 서버 앞 보안 그룹(문지기)이 80포트를 허용했기에 통과한다. 웹 서버는 다시 프라이빗 서브넷의 DB에 내부 통신으로 접근하는데, DB의 보안 그룹은 "웹 서버에서 오는 것만" 허용한다. DB는 인터넷 게이트웨이로 가는 경로가 없으니 외부에서 직접 닿을 수 없다.
🎯 시나리오: "웹 서버는 인터넷에서 접근 가능해야 하지만, 데이터베이스는 외부에서 절대 직접 접근하면 안 된다." → 웹 서버는 퍼블릭 서브넷에, DB는 프라이빗 서브넷에 둔다. DB의 보안 그룹은 웹 서버의 보안 그룹에서 오는 트래픽만 허용하도록 설정한다. 이것이 가장 기본적이고 안전한 2계층 구성이다.
인터넷 게이트웨이만이 VPC의 유일한 출입구는 아니다. CLF-C02는 각각을 깊이 다루지 않고 "어떤 상황에 무엇을 쓰는가"만 묻는다.
| 통로 | 연결 대상 | 어떤 상황에서 쓰나 |
|---|---|---|
| 인터넷 게이트웨이(IGW) | 인터넷 | VPC 자원이 인터넷과 양방향 통신 |
| NAT 게이트웨이 | 인터넷(나가는 방향만) | 프라이빗 자원이 업데이트를 받아야 할 때 |
| VPC 엔드포인트(Endpoint) | S3·DynamoDB 등 AWS 서비스 | 인터넷을 거치지 않고 AWS 서비스에 접근 |
| Site-to-Site VPN | 회사 데이터센터 | 기존 인터넷 회선 위에 암호화 터널을 빠르게 구성 |
| AWS Direct Connect | 회사 데이터센터 | 전용 물리 회선으로 안정적·고대역폭 연결 |
| VPC 피어링(Peering) | 다른 VPC | 두 VPC를 1:1로 사설 연결 |
두 가지만 짚어 둔다.
VPC 엔드포인트는 "AWS 서비스에 가는데 왜 인터넷을 나갔다 와야 하지?"라는 물음을 푼다. 엔드포인트를 만들면 프라이빗 서브넷의 EC2가 S3에 접근할 때 트래픽이 AWS 내부망을 통해 곧장 간다. 보안과 비용 양쪽에서 이득이다.
VPN과 Direct Connect는 둘 다 "회사 데이터센터와 AWS를 잇는" 통로지만 성격이 다르다. VPN은 기존 인터넷 회선 위에 암호화 터널을 얹어 빠르게 구성되지만 인터넷 상황에 성능이 좌우된다. Direct Connect는 전용 회선을 물리적으로 까는 방식이라 준비에 시간이 걸리는 대신 일관된 성능과 대역폭을 얻는다.
🎯 시나리오: "본사 데이터센터와 AWS 사이에 대용량 데이터가 매일 오가고 성능이 예측 가능해야 한다." → Direct Connect. "빠르고 저렴하게 우선 연결부터"라면 Site-to-Site VPN이다. 문항에 "전용", "일관된 성능"이 보이면 Direct Connect, "빠른 구성", "인터넷을 통한 암호화"가 보이면 VPN이다.
네트워킹 문항도 결국 키워드 싸움이다. 아래 짝을 눈에 익혀 둔다.
| 문항에 보이는 표현 | 정답 후보 |
|---|---|
| 논리적으로 격리된 나만의 가상 네트워크 | VPC |
| 인터넷에서 직접 접근 가능해야 함 | 퍼블릭 서브넷 |
| 인터넷에서 직접 접근되면 안 됨(DB 등) | 프라이빗 서브넷 |
| VPC가 인터넷과 양방향 통신 | 인터넷 게이트웨이 |
| 프라이빗 자원이 밖으로만 나가야 함(패치 등) | NAT 게이트웨이 |
| 인스턴스 단위 방화벽, 응답 자동 허용 | 보안 그룹(Stateful) |
| 서브넷 단위 방화벽, 인·아웃 각각 규칙 | 네트워크 ACL(Stateless) |
| 특정 IP를 명시적으로 차단해야 함 | 네트워크 ACL(Deny 규칙) |
| 어느 트래픽을 어디로 보낼지 정하는 규칙 | 라우팅 테이블 |
| 인터넷을 거치지 않고 S3에 접근 | VPC 엔드포인트 |
| 데이터센터와 AWS를 전용 회선으로 | Direct Connect |
| 데이터센터와 AWS를 인터넷 위 암호화 터널로 | Site-to-Site VPN |
| 한 AZ 장애에도 서비스 지속 | 여러 AZ에 서브넷 분산 |
함정: "보안을 강화하려면?"류 문항의 그럴듯한 오답이 "모든 포트를 열고 애플리케이션에서 검사한다"다. AWS의 기본 원칙은 최소 권한이며, 보기 중 범위를 좁히는 쪽이 정답 후보다.
오늘은 집 짓기 비유로 네트워킹을 봤다. VPC는 내 전용 땅(사설 네트워크), 서브넷은 용도별 구역(인터넷에 노출하는 퍼블릭 vs 숨기는 프라이빗), 인터넷 게이트웨이는 VPC의 대문, 보안 그룹은 각 자원 앞의 문지기(허용 규칙만, 상태 저장)다. 퍼블릭/프라이빗을 가르는 진짜 기준은 이름이 아니라 "라우팅 테이블이 인터넷 게이트웨이로 가는 경로를 가졌는가"라는 점을 기억한다.
여기에 오늘 더한 것들을 얹어 두면, 라우팅 테이블은 안내판이고 NAT 게이트웨이는 나가기만 하는 후문이며, 보안 그룹(인스턴스·Stateful·허용만)과 NACL(서브넷·Stateless·거부 가능)의 대비가 시험에서 가장 자주 확인하는 짝이다. 그리고 고가용성의 기본형은 언제나 둘 이상의 AZ에 같은 구조를 복제하는 것이다.
정리하면 네트워킹 문항은 결국 두 질문으로 환원된다 — "이 트래픽이 어디로 갈 수 있는가(라우팅)"와 "거기서 통과가 허용되는가(보안 그룹·NACL)". 이 둘을 분리해서 생각하는 습관이 붙으면 복잡해 보이는 시나리오도 금방 풀린다.
내일은 이 네트워크 바깥에서 사용자에게 콘텐츠를 더 빠르게 전달하는 엣지 서비스 — CloudFront와 Route 53으로 넘어간다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
AWS 클라우드 안에서 사용자가 갖는, 논리적으로 격리된 전용 가상 네트워크를 가리키는 것은?
문제 2
데이터베이스 서버를 인터넷에서 직접 접근할 수 없도록 보호하려고 한다. 가장 적절한 배치는?
문제 3
보안 그룹(Security Group)에 대한 설명으로 옳은 것은?
문제 4
어떤 서브넷이 "퍼블릭 서브넷"으로 동작하게 되는 직접적인 조건은?
문제 5
VPC 안의 자원이 인터넷과 양방향으로 통신할 수 있게 하는, VPC에 부착되는 구성 요소는?