VPC(Virtual Private Cloud)는 AWS에서 나만의 가상 네트워크를 만드는 서비스입니다. 처음 들으면 어렵게 느껴지지만, 아파트 단지를 설계한다고 생각하면 쉽게 이해할 수 있습니다. 단지 전체가 VPC이고, 각 동이 서브넷이며, 정문이 Internet Gateway입니다.
VPC란 무엇인가?
인터넷에 서버를 올릴 때 그냥 올리면 안 됩니다. 내 서버가 어떤 IP를 사용할지, 누가 접근할 수 있는지, 서버들끼리 어떻게 통신할지를 먼저 설계해야 합니다. VPC는 이 모든 것을 내가 원하는 대로 설계할 수 있는 나만의 가상 네트워크 공간입니다.
예를 들어 온라인 쇼핑몰을 운영한다고 해봅시다. 웹 서버는 고객이 접근해야 하니 인터넷에 노출되어야 합니다. 하지만 주문 데이터베이스는 절대로 외부에서 직접 접근할 수 없어야 합니다. VPC를 사용하면 이런 구조를 정확히 설계할 수 있습니다.
CIDR 블록 — 주소 범위 배정
VPC를 만들 때 IP 주소 범위를 지정해야 합니다. 이를 CIDR 블록이라고 합니다.
아파트 단지에 배정되는 주소 범위라고 생각하면 됩니다. 예를 들어 "이 단지의 주소는 101호부터 9999호까지"라고 정하는 것과 같습니다.
10.0.0.0/16을 설정하면 65,536개의 IP 주소를 사용할 수 있습니다. 10.0.0.0/24를 설정하면 256개의 IP 주소를 사용할 수 있습니다. /뒤의 숫자가 클수록 사용 가능한 IP가 줄어듭니다.
서브넷 — 단지 안의 각 동
서브넷은 VPC를 더 작은 네트워크로 나눈 것입니다. 아파트 단지 안의 각 동처럼, 서로 다른 용도로 구분합니다.
중요한 점은 각 서브넷이 반드시 하나의 가용 영역(Availability Zone, AZ)에 위치한다는 것입니다. 하나의 데이터센터에만 의존하지 않도록 여러 AZ에 서브넷을 배치하는 것이 좋습니다.
서브넷은 두 종류로 나뉩니다. 퍼블릭 서브넷은 인터넷과 직접 통신할 수 있는 서브넷입니다. 웹 서버, 로드 밸런서처럼 외부에서 접근해야 하는 리소스를 여기에 배치합니다. 아파트 단지의 1층 상가처럼 누구나 들어올 수 있는 공간입니다.
프라이빗 서브넷은 인터넷에서 직접 접근할 수 없는 서브넷입니다. 데이터베이스, 내부 애플리케이션 서버처럼 외부에서 직접 접근하면 안 되는 리소스를 여기에 배치합니다. 아파트의 주거 공간처럼 외부인이 들어올 수 없습니다.
라우팅 테이블 — 교통 이정표
라우팅 테이블은 서브넷의 트래픽이 어디로 가야 하는지를 결정하는 규칙표입니다. 도로의 이정표와 같습니다.
퍼블릭 서브넷의 라우팅 테이블을 보면 이렇습니다. 목적지 10.0.0.0/16은 로컬(VPC 내부)로 보내고, 목적지 0.0.0.0/0(인터넷의 모든 곳)은 Internet Gateway로 보냅니다. Internet Gateway로 향하는 경로가 있기 때문에 이 서브넷이 퍼블릭 서브넷이 되는 것입니다.
프라이빗 서브넷의 라우팅 테이블은 다릅니다. 목적지 10.0.0.0/16은 로컬로 보내고, 목적지 0.0.0.0/0은 NAT Gateway로 보냅니다. Internet Gateway 대신 NAT Gateway로 가기 때문에 외부에서 직접 접근이 불가능합니다.
각 서브넷은 하나의 라우팅 테이블에만 연결됩니다.
Internet Gateway — 아파트 정문
Internet Gateway는 VPC와 인터넷 사이의 문입니다. 모든 인터넷 트래픽이 이 문을 통해 들어오고 나갑니다. VPC당 하나만 연결할 수 있습니다.
퍼블릭 서브넷이 인터넷과 통신하려면 두 가지가 필요합니다. 첫 번째는 Internet Gateway가 VPC에 연결되어 있어야 하고, 두 번째는 서브넷의 라우팅 테이블에 0.0.0.0/0 → Internet Gateway 규칙이 있어야 합니다.
Security Group vs Network ACL — 시험에서 가장 중요한 비교
이 두 가지의 차이점은 SOA-C03에서 매우 자주 출제됩니다. 확실히 이해해야 합니다.
| 구분 | Security Group | Network ACL | |------|---------------|-------------| | 적용 수준 | 인스턴스(ENI) 수준 | 서브넷 수준 | | 상태 | 상태 유지형 (Stateful) | 상태 비유지형 (Stateless) | | 규칙 종류 | 허용(Allow) 규칙만 | 허용(Allow) + 거부(Deny) 규칙 모두 | | 반환 트래픽 | 자동으로 허용 | 명시적으로 허용 필요 | | 기본 설정 | 모든 인바운드 거부, 모든 아웃바운드 허용 | 모든 트래픽 허용 | | 규칙 처리 | 모든 규칙 검토 후 허용 | 번호 순서대로 검토, 첫 매칭 규칙 적용 |
가장 헷갈리는 부분인 Stateful vs Stateless를 비유로 설명합니다.
Security Group(Stateful)은 현명한 경비원과 같습니다. 손님이 입장할 때 신원 확인을 합니다. 그 손님이 나갈 때는 "아, 아까 들어온 손님이네"라고 기억하고 자동으로 통과시킵니다. 즉, 인바운드 규칙을 통과한 트래픽에 대한 응답은 자동으로 허용됩니다.
Network ACL(Stateless)은 기억력 없는 경비원과 같습니다. 손님이 입장할 때 신원 확인을 합니다. 그 손님이 나갈 때도 "처음 보는 사람입니다"라며 다시 신원 확인을 합니다. 즉, 인바운드와 아웃바운드를 각각 따로 설정해야 합니다.
NACL에서 아웃바운드 규칙을 설정할 때 임시 포트(Ephemeral Ports, 1024-65535)를 열어야 합니다. 클라이언트가 서버에 요청할 때 응답을 받을 포트를 임시로 사용하기 때문입니다. 예를 들어 클라이언트가 서버의 443 포트로 요청하면, 응답은 클라이언트의 임의 포트(예: 52341)로 돌아옵니다. NACL은 이 반환 트래픽도 명시적으로 허용해야 합니다.
!보안 그룹(SG) vs 네트워크 ACL
NAT Gateway — 프라이빗 구역의 인터넷 창구
프라이빗 서브넷에 있는 EC2 인스턴스가 인터넷에 접근해야 하는 경우가 있습니다. 소프트웨어 업데이트, 외부 API 호출 등이 그 예입니다. 하지만 인터넷에서 이 인스턴스로 직접 접근은 허용하고 싶지 않습니다.
NAT Gateway는 이런 상황을 해결합니다. 프라이빗 서브넷의 인스턴스가 NAT Gateway를 통해 인터넷에 나가는 것은 허용하지만, 외부에서 들어오는 접근은 차단합니다.
아파트 비유로 설명하면 이렇습니다. 주민(프라이빗 인스턴스)이 택배를 주문하는 것은 됩니다(아웃바운드 허용). 하지만 외부 사람이 직접 집 문을 두드리는 것은 안 됩니다(인바운드 차단).
NAT Gateway 사용 시 주의사항입니다. 반드시 퍼블릭 서브넷에 배치해야 합니다. Elastic IP(고정 퍼블릭 IP)가 필요합니다. 고가용성을 위해 각 AZ마다 하나씩 배치하는 것이 좋습니다.
VPC Endpoints — 인터넷 없이 AWS 서비스 접근
프라이빗 서브넷의 인스턴스가 S3에 데이터를 저장해야 한다면 어떻게 할까요? 일반적으로는 NAT Gateway를 통해 인터넷으로 나가서 S3에 접근합니다. 하지만 이러면 데이터가 인터넷을 거치게 되어 보안상 좋지 않고 비용도 발생합니다.
VPC Endpoint를 사용하면 인터넷을 거치지 않고 AWS 내부 네트워크를 통해 AWS 서비스에 직접 접근할 수 있습니다.
| 유형 | 지원 서비스 | 동작 방식 | 비용 | |------|-----------|----------|------| | Gateway Endpoint | S3, DynamoDB만 | 라우팅 테이블에 경로 추가 | 무료 | | Interface Endpoint | 대부분의 AWS 서비스 | 서브넷에 ENI 생성 | 시간당 + 데이터 요금 |
S3나 DynamoDB에 접근할 때는 무료인 Gateway Endpoint를 사용하는 것이 좋습니다.
VPC Flow Logs — 네트워크 트래픽 기록
VPC Flow Logs는 VPC 내의 네트워크 인터페이스를 통해 들어오고 나가는 트래픽 정보를 기록하는 기능입니다. CloudWatch Logs 또는 S3에 저장할 수 있습니다.
기록되는 정보에는 출발지 IP와 포트, 목적지 IP와 포트, 프로토콜(TCP/UDP), 허용(ACCEPT) 또는 거부(REJECT) 여부, 전송된 바이트 수가 포함됩니다.
트러블슈팅 활용 예시입니다. "EC2에 SSH가 안 된다" → VPC Flow Logs 확인 → REJECT 로그 발견 → Security Group 또는 NACL 규칙 확인 → 포트 22 인바운드 규칙 추가.
보안 감사에도 활용됩니다. 어떤 외부 IP가 내 서버에 접근 시도했는지, 어떤 데이터가 외부로 나갔는지 기록이 남습니다.
프라이빗 인스턴스 접근 방법
프라이빗 서브넷에 있는 EC2 인스턴스에 접속하려면 어떻게 해야 할까요?
Bastion Host 방식은 전통적인 방법입니다. 퍼블릭 서브넷에 점프 서버(Bastion Host)를 두고, 이 서버를 경유하여 프라이빗 인스턴스에 SSH로 접속합니다. 단, SSH 키 관리가 필요하고 Bastion Host 자체도 보안 위험이 될 수 있습니다.
Session Manager 방식은 더 현대적이고 안전한 방법입니다. AWS Systems Manager의 기능으로, SSH 키 없이 웹 브라우저나 AWS CLI에서 바로 접속할 수 있습니다. 포트 22를 열 필요가 없어 보안이 강화되고, 모든 세션이 CloudTrail에 기록됩니다.
시험에서 "SSH 키 없이", "포트 22 열지 않고" 같은 문구가 나오면 Session Manager를 선택하세요.
Elastic IP — 고정 퍼블릭 IP