![[AWS 자격증] Amazon VPC 기초 정리](/_next/image?url=%2Fimages%2Fthumbnail%2Fdva-badge.webp&w=3840&q=75){kind=icon}
[AWS 자격증] Amazon VPC 기초 정리
AWSVPC자격증
작성자 : 오예환 | 작성일 : 2026-01-08 | 수정일 : 2026-01-08
Amazon VPC 기초 정리
1. VPC 개요
VPC란?
- Virtual Private Cloud - AWS 리소스를 배포하기 위한 가상 프라이빗 네트워크
- 리전 레벨 리소스
쉽게 이해하기
VPC는 AWS 클라우드 안에 만드는 나만의 사설 네트워크입니다.
실제 회사 건물을 생각해보세요. 회사 건물 안에는 외부인이 마음대로 들어올 수 없고, 내부에서 자체 네트워크를 구성합니다. VPC도 마찬가지로 AWS라는 거대한 클라우드 안에 나만의 독립적인 공간을 만드는 것입니다.
- 인터넷 없이 VPC 내부 리소스끼리 통신 가능
- 내가 원하는 IP 대역을 설정 가능 (예: 10.0.0.0/16)
- 다른 AWS 계정의 VPC와 완전히 격리됨
알아야 할 핵심 개념
- VPC, Subnets, Internet Gateways & NAT Gateways
- Security Groups, Network ACL (NACL), VPC Flow Logs
- VPC Peering, VPC Endpoints
- Site to Site VPN & Direct Connect
2. VPC & 서브넷 (Subnets)
서브넷이란?
- VPC 내에서 네트워크를 분할하는 단위
- 가용 영역(AZ) 레벨 리소스
쉽게 이해하기
VPC가 회사 건물이라면, 서브넷은 건물 안의 **각 층(또는 구역)**입니다.
- 1층(Public Subnet): 로비, 안내데스크 → 외부 손님이 방문 가능
- 2층(Private Subnet): 사무실, 서버실 → 직원만 출입 가능
왜 나누는가?
- 보안: DB 서버는 인터넷에서 직접 접근하면 안 됨
- 관리: 용도별로 분리하면 관리가 쉬움
- 고가용성: 여러 AZ에 서브넷을 만들면 한 AZ가 죽어도 서비스 유지
서브넷 유형
| 유형 | 설명 |
|---|---|
| Public Subnet | 인터넷에서 접근 가능 |
| Private Subnet | 인터넷에서 접근 불가 |
Route Table
- 인터넷 및 서브넷 간 접근을 정의
쉽게 이해하기
Route Table은 **건물 안의 이정표(표지판)**입니다.
"이 목적지로 가려면 어디로 가세요"라고 알려주는 역할입니다.
10.0.0.0/16 → local: VPC 내부 트래픽은 그냥 내부에서 처리0.0.0.0/0 → igw-xxx: 그 외 모든 트래픽은 인터넷 게이트웨이로 보내기Public Subnet과 Private Subnet의 차이점은 Route Table입니다.
- Public Subnet:
0.0.0.0/0 → Internet Gateway라우팅이 있음- Private Subnet: 인터넷으로 가는 라우팅이 없음 (또는 NAT Gateway로 라우팅)
VPC 구조 예시
┌─────────────────── VPC (10.0.0.0/16) ───────────────────┐
│ │
│ ┌─── AZ 1 ───┐ ┌─── AZ 2 ───┐ │
│ │ │ │ │ │
│ │ Public │ │ Public │ │
│ │ Subnet │ │ Subnet │ ← 인터넷 접근 O
│ │ │ │ │ │
│ ├────────────┤ ├────────────┤ │
│ │ │ │ │ │
│ │ Private │ │ Private │ ← 인터넷 접근 X
│ │ Subnet │ │ Subnet │ │
│ │ │ │ │ │
│ └────────────┘ └────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘3. Internet Gateway & NAT Gateway
쉽게 이해하기
- Internet Gateway: 회사 건물의 정문 (양방향 출입 가능)
- NAT Gateway: 회사 건물의 후문 (직원만 나갈 수 있고, 외부인은 들어올 수 없음)
Internet Gateway (IGW)
| 항목 | 설명 |
|---|---|
| 역할 | VPC 인스턴스가 인터넷과 연결되도록 함 |
| 위치 | VPC 레벨 |
| 사용 | Public Subnet이 IGW로 라우팅됨 |
핵심 포인트
- VPC당 1개만 연결 가능
- IGW 자체는 수평 확장되어 대역폭 제한 없음
- Public Subnet의 EC2가 인터넷과 통신하려면 Public IP + IGW 라우팅 둘 다 필요
NAT Gateway vs NAT Instance
| 항목 | NAT Gateway | NAT Instance |
|---|---|---|
| 관리 | AWS 관리형 | 직접 관리 |
| 역할 | Private Subnet → 인터넷 접근 (아웃바운드만) | |
| 특징 | Private Subnet의 인스턴스가 인터넷에 접근하면서도 외부에서는 접근 불가 |
왜 NAT Gateway가 필요한가?
Private Subnet의 EC2는 인터넷에서 직접 접근하면 안 되지만, OS 업데이트나 외부 API 호출은 해야 합니다.
예를 들어 DB 서버가 Private Subnet에 있는데:
- ❌ 외부에서 DB에 직접 접근 → 보안 위험
- ✅ DB 서버에서 외부로 패치 다운로드 → 필요함
NAT Gateway는 Private 서브넷 → 인터넷 (아웃바운드)만 허용하고, 인터넷 → Private 서브넷 (인바운드)는 차단합니다.
트래픽 흐름
┌─────────┐
│ 인터넷 │
└────┬────┘
│
┌────▼────┐
│ IGW │ ← Internet Gateway
└────┬────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ │
│ Public │ │ NAT │ │
│ Subnet │ │ Gateway │ │
└─────────┘ └────┬────┘ │
│ │
┌────▼────┐ │
│ Private │ │
│ Subnet │──────────┘
└─────────┘4. Network ACL & Security Groups
쉽게 이해하기
둘 다 방화벽 역할을 하지만 위치와 동작 방식이 다릅니다.
- NACL: 건물(서브넷)의 출입문 경비원 - 들어오고 나가는 모든 사람을 검사
- Security Group: 각 사무실(EC2)의 도어락 - 해당 방에 들어올 수 있는 사람만 허용
비교 요약
| 항목 | Network ACL (NACL) | Security Groups |
|---|---|---|
| 레벨 | 서브넷 | 인스턴스 (ENI) |
| 규칙 | ALLOW + DENY | ALLOW만 |
| 상태 | Stateless | Stateful |
| 규칙 대상 | IP 주소만 | IP 주소 + 다른 Security Group |
| 역할 | 서브넷 출입 트래픽 제어 | EC2 인스턴스 트래픽 제어 |
Stateless vs Stateful
| 구분 | 설명 |
|---|---|
| Stateless (NACL) | 인바운드/아웃바운드 규칙을 각각 설정해야 함 |
| Stateful (SG) | 인바운드 허용 시 응답 아웃바운드 자동 허용 |
Stateless vs Stateful 쉽게 이해하기
Stateful (Security Group) - 기억력이 좋은 경비원
손님: "저 들어가도 되나요?" (인바운드 요청) 경비원: "네, 들어가세요" (인바운드 허용) (손님이 나올 때) 경비원: "아, 아까 들어갔던 분이시네요. 나가세요" (아웃바운드 자동 허용)Stateless (NACL) - 기억력이 없는 경비원
손님: "저 들어가도 되나요?" (인바운드 요청) 경비원: "명단 확인... 네, 들어가세요" (인바운드 규칙 확인) (손님이 나올 때) 경비원: "누구세요? 명단 확인해야 합니다" (아웃바운드 규칙 별도 확인)그래서 NACL은 인바운드/아웃바운드 규칙을 둘 다 설정해야 합니다.
보안 레이어 구조
┌─────────────── VPC ───────────────┐
│ │
│ ┌─────── Subnet ───────┐ │
│ │ │ │
│ │ ┌── NACL (1차 방화벽) ──┐ │
│ │ │ │ │
│ │ │ ┌── Security Group ─┐│ │
│ │ │ │ ││ │
│ │ │ │ EC2 Instance ││ │
│ │ │ │ ││ │
│ │ │ └───────────────────┘│ │
│ │ │ │ │
│ │ └──────────────────────┘ │
│ │ │ │
│ └──────────────────────┘ │
│ │
└────────────────────────────────────┘5. VPC Flow Logs
개요
- VPC 인터페이스를 통과하는 IP 트래픽 정보 캡처
- 연결 문제 모니터링 및 트러블슈팅에 활용
쉽게 이해하기
VPC Flow Logs는 건물의 CCTV 기록과 같습니다.
- 누가(Source IP) 언제 어디로(Destination IP) 갔는지 기록
- 허용됐는지 차단됐는지(ACCEPT/REJECT) 기록
- 문제가 생겼을 때 "왜 연결이 안 되지?" 를 추적하는 데 필수
실제 활용 예시:
- EC2가 인터넷에 연결이 안 될 때 → Flow Logs에서 REJECT 확인 → Security Group 또는 NACL 문제 파악
- 의심스러운 IP에서 접근 시도 확인
캡처 레벨
| 레벨 | 설명 |
|---|---|
| VPC Flow Logs | VPC 전체 |
| Subnet Flow Logs | 특정 서브넷 |
| ENI Flow Logs | 특정 네트워크 인터페이스 |
모니터링 가능 항목
- 서브넷 ↔ 인터넷
- 서브넷 ↔ 서브넷
- 인터넷 → 서브넷
캡처 대상
- EC2 인스턴스
- AWS 관리형 서비스: ELB, ElastiCache, RDS, Aurora 등
로그 저장 위치
- S3
- CloudWatch Logs
- Kinesis Data Firehose
6. VPC Peering
개요
- 두 VPC를 AWS 프라이빗 네트워크로 연결
- 같은 네트워크에 있는 것처럼 동작
쉽게 이해하기
VPC Peering은 두 회사 건물 사이에 전용 통로를 만드는 것입니다.
- 인터넷(공공도로)을 거치지 않고 전용 통로로 이동
- 보안상 안전하고 빠름
- 다른 AWS 계정의 VPC와도 연결 가능
사용 사례:
- 개발 VPC ↔ 운영 VPC 연결
- 본사 계정 VPC ↔ 자회사 계정 VPC 연결
주의사항
| 항목 | 설명 |
|---|---|
| CIDR 중복 | ❌ 불가 (IP 범위 겹치면 안 됨) |
| 전이성 (Transitive) | ❌ 없음 |
전이성 없음 예시
VPC A ←──피어링──→ VPC B ←──피어링──→ VPC C
결과: VPC A와 VPC C는 통신 불가!
→ A↔C 피어링을 별도로 설정해야 함7. VPC Endpoints
개요
- AWS 서비스에 프라이빗 네트워크로 연결
- 퍼블릭 인터넷을 거치지 않음
- VPC 내부에서만 사용
쉽게 이해하기
VPC Endpoint는 회사 건물 안에 있는 AWS 전용 창구입니다.
원래 S3에 접근하려면:
EC2 → NAT Gateway → Internet Gateway → 인터넷 → S3 (복잡하고, 인터넷 비용 발생, 보안 걱정)VPC Endpoint 사용 시:
EC2 → VPC Endpoint → S3 (간단하고, 무료(Gateway 타입), 프라이빗하게 안전)핵심: Private Subnet의 EC2가 NAT Gateway 없이 S3, DynamoDB에 접근 가능!
장점
- 보안 강화
- AWS 서비스 접근 시 지연시간 감소
- 비용 절감: NAT Gateway 비용 없이 AWS 서비스 접근 가능 (Gateway Endpoint는 무료)
엔드포인트 유형
| 유형 | 대상 서비스 | 특징 |
|---|---|---|
| Gateway Endpoint | S3, DynamoDB | 라우팅 테이블에 추가 |
| Interface Endpoint | 대부분의 서비스 (S3, DynamoDB 포함) | ENI 사용 |
구조
┌─────────────── VPC ───────────────┐
│ │
│ Private Subnet │
│ ┌──────────┐ │
│ │ EC2 │ │
│ └────┬─────┘ │
│ │ │
│ ┌────▼─────────────────┐ │
│ │ VPC Endpoint Gateway │──────────→ S3 / DynamoDB
│ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ │
│ │ VPC Endpoint Interface│─────────→ CloudWatch 등
│ │ (ENI) │ │
│ └──────────────────────┘ │
│ │
└────────────────────────────────────┘8. Site-to-Site VPN & Direct Connect
쉽게 이해하기
회사의 온프레미스 데이터센터와 AWS VPC를 연결하는 방법입니다.
- Site-to-Site VPN: 인터넷을 통한 암호화 터널 (빠르게 구축, 저렴)
- Direct Connect: 전용 광케이블 연결 (안정적, 빠름, 비쌈)
비유:
- VPN = 일반 도로를 이용하되, 방탄 차량으로 이동 (암호화)
- Direct Connect = 우리 회사 전용 고속도로 건설 (전용선)
비교
| 항목 | Site-to-Site VPN | Direct Connect (DX) |
|---|---|---|
| 연결 방식 | 퍼블릭 인터넷 경유 | 전용 물리적 연결 |
| 암호화 | 자동 암호화 ✅ | 기본 암호화 없음 (별도 설정 필요) |
| 속도 | 인터넷 속도에 의존 | 빠르고 안정적 |
| 보안 | 암호화로 보안 확보 | 프라이빗 네트워크로 보안 |
| 설정 시간 | 빠름 | 최소 1개월 소요 |
| 비용 | 상대적으로 저렴 | 높음 |
구조
┌──────────────┐ ┌─────────┐
│ On-premises │ │ VPC │
│ Data Center │ │ │
│ │ │ │
│ ┌──────┐ │ Site-to-Site VPN │ │
│ │ VPN │───┼──── (퍼블릭 인터넷) ────┼─────────│
│ └──────┘ │ 암호화 O │ │
│ │ │ │
│ ┌──────┐ │ Direct Connect │ │
│ │ DX │───┼──── (프라이빗 연결) ───┼─────────│
│ └──────┘ │ 전용선 │ │
│ │ │ │
└──────────────┘ └─────────┘9. VPC 핵심 요약
| 개념 | 설명 |
|---|---|
| VPC | Virtual Private Cloud - 가상 프라이빗 네트워크 |
| Subnets | AZ에 종속, VPC 네트워크 분할 |
| Internet Gateway | VPC 레벨, 인터넷 접근 제공 |
| NAT Gateway/Instance | Private Subnet에 인터넷 접근 제공 |
| NACL | Stateless, 서브넷 레벨 인/아웃바운드 규칙 |
| Security Groups | Stateful, EC2/ENI 레벨 |
| VPC Peering | 두 VPC 연결, IP 범위 중복 불가, 전이성 없음 |
| VPC Endpoints | VPC 내에서 AWS 서비스 프라이빗 접근 |
| VPC Flow Logs | 네트워크 트래픽 로그 |
| Site-to-Site VPN | 퍼블릭 인터넷 경유 VPN |
| Direct Connect | 전용 프라이빗 연결 (물리적) |
10. 3-Tier 아키텍처 예시
쉽게 이해하기
웹 서비스를 3개 층으로 분리하는 가장 일반적인 아키텍처입니다.
계층 역할 위치 이유 Web Tier 사용자 요청 받기 Public Subnet 인터넷에서 접근해야 함 App Tier 비즈니스 로직 처리 Private Subnet 직접 노출 불필요, 보안 Data Tier 데이터 저장 Private Subnet 절대 외부 노출 금지, 가장 보호해야 함 왜 이렇게 나누는가?
- 보안: DB가 해킹당하면 모든 데이터 유출 → Private에 숨김
- 확장성: 각 계층을 독립적으로 확장 가능
- 유지보수: 문제 발생 시 해당 계층만 수정
일반적인 3계층 구조
┌─────────────────────────────────────────────────────────┐
│ Route 53 │
└────────────────────────────┬────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────┐
│ PUBLIC SUBNETS │
│ ELB │
│ (Application Load Balancer) │
└────────────────────────────┬────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────┐
│ PRIVATE SUBNETS │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Auto Scaling Group │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ EC2 │ │ EC2 │ │ EC2 │ │ │
│ │ │ (AZ1) │ │ (AZ2) │ │ (AZ3) │ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ └─────────────────────────────────────────────┘ │
└────────────────────────────┬────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────┐
│ DATA SUBNETS │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Amazon RDS │ │ ElastiCache │ │
│ │ (Multi-AZ) │ │ (세션/캐시) │ │
│ └─────────────────┘ └─────────────────┘ │
└──────────────────────────────────────────────────────────┘각 계층 역할
| 계층 | 서브넷 | 구성 요소 | 역할 |
|---|---|---|---|
| Web Tier | Public | ELB | 트래픽 분산 |
| App Tier | Private | EC2 (Auto Scaling) | 애플리케이션 로직 |
| Data Tier | Private | RDS, ElastiCache | 데이터 저장/캐싱 |
11. LAMP Stack on EC2
구성 요소
| 약자 | 기술 | AWS 서비스 |
|---|---|---|
| L | Linux | EC2 OS |
| A | Apache | EC2에서 실행 (웹 서버) |
| M | MySQL | RDS |
| P | PHP | EC2에서 실행 (애플리케이션 로직) |
추가 구성
- 캐싱: ElastiCache (Redis/Memcached)
- 로컬 스토리지: EBS (root drive)
12. WordPress on AWS
기본 구성
┌─────────────────────────────────────┐
│ Multi-AZ │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ EC2 │ │ EC2 │ │
│ │ (AZ1) │ │ (AZ2) │ │
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
│ │ ┌───────┐ │ │
│ └────┤ EFS ├───┘ │
│ │ (ENI) │ │
│ └───────┘ │
│ │
│ 이미지/미디어 파일 공유 저장소 │
│ │
└─────────────────────────────────────┘EFS 사용 이유
- 여러 EC2 인스턴스에서 동일한 파일 시스템 공유
- WordPress 미디어 파일 저장에 적합
핵심 개념 한눈에 정리
┌─────────────────────────────────────────────────────────────┐
│ 인터넷 │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────▼──────┐
│ IGW │ ← VPC의 정문
└──────┬──────┘
│
┌──────────────────────────┼──────────────────────────────────┐
│ VPC │
│ │ │
│ ┌─────────────────────┼─────────────────────┐ │
│ │ Public Subnet │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ELB │ │ NAT │ │ │
│ │ └────┬────┘ └────┬────┘ │ │
│ └─────────┼──────────────────────┼──────────┘ │
│ │ │ │
│ ┌─────────┼──────────────────────┼──────────┐ │
│ │ │ Private Subnet │ │ │
│ │ ┌────▼────┐ ┌────┴────┐ │ │
│ │ │ EC2 │ │ EC2 │ │ │
│ │ └─────────┘ └────┬────┘ │ │
│ └────────────────────────────────┼──────────┘ │
│ │ │
│ ┌────────────────────────────────┼──────────┐ │
│ │ Data Subnet │ │ │
│ │ ┌─────▼─────┐ │ │
│ │ │ RDS │ │ │
│ │ └───────────┘ │ │
│ └───────────────────────────────────────────┘ │
│ │
│ Security Group = EC2별 방화벽 (Stateful) │
│ NACL = Subnet별 방화벽 (Stateless) │
│ VPC Endpoint = AWS 서비스 프라이빗 접근 │
│ VPC Peering = 다른 VPC와 연결 │
│ │
└──────────────────────────────────────────────────────────────┘