자료 출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html
AWS VPC 개념 정리
오늘은 AWS에서 VPC (Virtual Private Cloud)에 대해 정리해보려한다.
이번에 TechCamp 웨비나 들으면서 실습도 같이 해봤는데, 막상 손으로 구성해보니까 개념들이 좀 더 명확하게 정리되는 느낌이다.
1. VPC 개념
사용자가 정의한, 논리적으로 격리된 가상의 프라이빗 네트워크 환경
VPC는 AWS 상에서 내가 원하는 대로 설계할 수 있는 가상의 네트워크 공간이다.
온프레미스(On-premise) 데이터센터를 AWS 안에 옮겨서 운영한다고 생각하면 감이 온다.
간단한 구성만으로도 AWS의 확장 가능한 인프라를 기존 데이터센터 환경과 유사하게 사용할 수 있다.
내가 직접 IP 대역도 정하고, 서브넷도 나누고, 라우팅 경로도 만들고, 보안 설정도 할 수 있다.
즉, AWS 인프라 위에 내가 설계한 네트워크를 만든다고 보면 된다.
2. Amazon VPC 구성
그림으로 보면 이렇다.
하나씩 개념을 살펴보면,
3. AWS VPC 구성 요소: IP 대역, 서브넷, 라우팅 테이블
AWS에서 VPC를 구성할 때 꼭 알아야 하는 기본 개념 3가지가 있다.
바로 IP 대역(CIDR), 서브넷, 라우팅 테이블(Route Table)이다.
1) IP 대역 (CIDR: Classless Inter-Domain Routing)
VPC를 만들 때 가장 먼저 하는 건 내 네트워크에서 쓸 IP 범위를 정하는 것이다.
이걸 CIDR 표기법으로 입력하는데, 예를 들어 10.0.0.0/16 이런 식이다.
내가 이해한 방식:
10.0.0.0→ 네트워크의 시작 주소/16→ 앞 16비트는 네트워크 주소로 고정, 나머지는 호스트 IP로 사용/16이면 약 65,000개의 IP를 쓸 수 있음
📌 사설 IP 대역 권장 목록 (RFC1918):
| 대역 | 사용 예시 |
|---|---|
10.0.0.0/8 | AWS에서 많이 씀 |
172.16.0.0/12 | 일반 사내망 등 |
192.168.0.0/16 | 가정용 라우터 등에서 흔함 |
실습에서는 보통 10.0.0.0/16이나 172.31.0.0/16을 썼다.
2) 서브넷 (Subnet)
서브넷은 VPC 안에서 네트워크를 논리적으로 더 잘게 나눈 것이다.
✅ 특징 요약:
-
하나의 서브넷은 하나의 가용 영역(AZ)에만 속할 수 있다.
-
퍼블릭/프라이빗 서브넷으로 나눠서 보안 구분을 할 수 있다.
-
각 서브넷에 CIDR 범위를 나눠준다. 예를 들어:
10.0.1.0/24→ 퍼블릭 서브넷10.0.2.0/24→ 프라이빗 서브넷
직접 나눈 예시:
VPC: 10.0.0.0/16
└─ 퍼블릭 서브넷: 10.0.1.0/24 → EC2 웹서버
└─ 프라이빗 서브넷: 10.0.2.0/24 → RDS 데이터베이스3) 라우팅 테이블 (Route Table)
라우팅 테이블은 트래픽이 어디로 가야 할지를 정하는 경로표다.
내가 기억하기 쉽게 정리한 방식:
-
서브넷마다 하나씩 연결된다.
-
"이 IP로 가는 트래픽은 어디로 보내라" 라는 식으로 지정함
-
예시:
Destination Target 10.0.0.0/16 local 0.0.0.0/0 igw-abc12310.0.0.0/16 → local: 같은 VPC 안에서는 다 통신 가능0.0.0.0/0 → IGW: 인터넷으로 나가는 건 IGW(인터넷 게이트웨이) 통해서
퍼블릭 서브넷 만들 때 필수!
퍼블릭 서브넷이 되려면:
- IGW가 연결돼 있어야 하고
- 라우팅 테이블에
0.0.0.0/0 → IGW경로가 있어야 한다
구조 요약
VPC: 10.0.0.0/16
│
├── Subnet: 10.0.1.0/24 (퍼블릭)
│ └─ Route: 0.0.0.0/0 → IGW
│ └─ EC2 웹서버
│
├── Subnet: 10.0.2.0/24 (프라이빗)
└─ Route: local 통신만
└─ RDS 데이터베이스4. 추가 개념
4-1) CIDR 블록
VPC를 만들 때 제일 먼저 설정하는 게 IP 범위다.
예를 들어 10.0.0.0/16 이렇게 적으면 65,536개의 IP 주소를 가진 네트워크가 만들어진다.
IP 주소 범위 설정은
이렇게 가능하다.
사설 IP 대역으로는 10.x.x.x, 172.16.x.x, 192.168.x.x를 많이 쓴다고 한다.
4-2) 서브넷 (Subnet)
각 가용영역에는 1개 이상의 서브넷을 설정 가능한데, VPC CIDR 범위의 하위 집합으로 할당한다.
VPC 내부를 더 잘게 쪼갠 개념으로 각 서브넷은 하나의 가용 영역(AZ) 안에만 존재할 수 있고, 실제로 실습할 땐 보통 이렇게 나눈다:
- 퍼블릭 서브넷: EC2 같은 웹서버 올림
- 프라이빗 서브넷: RDS 같은 DB 서버 올림
4-3) Internet Gateway (IGW)
퍼블릭 서브넷에서 외부 인터넷과 통신하려면 꼭 있어야 하는 녀석.
라우팅 테이블에서 0.0.0.0/0 → IGW로 연결해주면 외부랑 소통 가능.
4-4) Route Table
각 서브넷에 연결해서 "이쪽 IP 대역의 요청은 어디로 보내라" 식으로 경로를 설정해주는 테이블이다.
VPC를 생성하면 기본 라우팅 테이블이 생기고, VPC 대역 내 라우팅이 생긴다. 게이트웨이 등 외부와의 연결은 서브넷 라우팅 테이블을 만들어 연결 후 사용해야 한다.
기본적으로는 VPC 내부에서의 통신만 허용돼 있어서, 외부랑 연결하려면 라우팅 테이블을 따로 수정해야 한다.
인터넷과 통신하는 방법
4-5) 보안 그룹 vs NACL
이 둘이 헷갈렸는데 정리해보면:
| 항목 | 적용 대상 | 상태 유지? | 설정 방식 |
|---|---|---|---|
| 보안 그룹 | EC2 인스턴스 등 | ✅ 상태 저장 (Stateful) | Allow만 가능 |
| NACL | 서브넷 단위 | ❌ 상태 비저장 (Stateless) | Allow & Deny 둘 다 가능 |
보안 그룹은 "이 포트는 어디서 오는 것만 허용" 식으로,
NACL은 "이 IP는 막자/허용하자" 식으로 서브넷 전체에 영향을 준다.
4-6) 서브넷의 방화벽:Network Access Control List
NACL (Network Access Control List) — 서브넷 단위 방화벽
💡 개념 요약
- 서브넷 단위에서 작동하는 방화벽 역할
- Stateless: 인바운드가 허용돼도, 아웃바운드가 따로 설정되지 않으면 응답 불가
- 기본값: 모든 트래픽 허용
- 규칙에는 Allow와 Deny 둘 다 설정 가능
🔧 예시 흐름
- 퍼블릭 서브넷에 있는 웹 서버는 외부로부터
TCP 443(HTTPS)허용 - 프라이빗 서브넷에 있는 DB는
TCP 3306(MySQL)만 허용 - 그 외 IP나 포트 → 명시적으로 차단(Deny)
✅ 사용할 때 주의할 점
- 양방향 규칙을 모두 명시해야 정상 작동
- 예:
인바운드: 443 허용,아웃바운드: 443 허용→ 둘 다 필요
4-7) Security Group — 인스턴스 단위 방화벽
💡 개념 요약
- EC2, RDS 같은 리소스 단위로 붙는 보안 규칙
- Stateful: 요청이 허용되면 응답은 자동으로 허용됨
- 기본값: 모든 트래픽 차단
- Allow만 가능 (Deny는 불가능)
🔧 예시 흐름
-
ELB(Security Group: Web ELB) → EC2(Security Group: Web Tier) → RDS(Security Group: DB Tier)
-
각 보안 그룹에서 서로의 그룹을 Source로 명시해 허용함
- Web Tier 보안 그룹은 DB Tier 그룹에서 허용되어야 DB 접속 가능
✅ 사용할 때 주의할 점
- 인스턴스는 최소 1개의 보안 그룹과 연결되어야 함
- 보안 그룹은 트래픽을 정밀하게 제어할 수 있음 (ex. 특정 포트, 특정 IP 범위 등)
NACL vs Security Group 한눈에 비교
| 항목 | NACL | Security Group |
|---|---|---|
| 적용 범위 | 서브넷 단위 | 인스턴스 (ENI) 단위 |
| 상태 저장 여부 | Stateless (상태 비저장) | Stateful (상태 저장) |
| 규칙 종류 | Allow, Deny 모두 설정 가능 | Allow만 설정 가능 |
| 기본 동작 | 모든 트래픽 허용 | 모든 트래픽 차단 |
| 인바운드/아웃바운드 | 각각 별도 설정 필요 | 인바운드만 설정하면 응답은 자동 허용 |
이 두 보안 계층을 적절히 조합하면 VPC 안에서 서비스끼리의 흐름은 허용하면서, 외부로부터의 공격은 막을 수 있는 강력한 방화벽을 구성할 수 있다고 한다.
5. 직접 구성해본 간단한 예시
퍼블릭 서브넷과 프라이빗 서브넷으로 나누어 구성할 수 있다.
VPC (10.0.0.0/16)
├─ 퍼블릭 서브넷 (10.0.1.0/24)
│ └─ EC2 (웹서버)
│ └─ 인터넷 게이트웨이 연결
│
└─ 프라이빗 서브넷 (10.0.2.0/24)
└─ RDS (DB서버)퍼블릭 쪽은 IGW랑 연결하고 라우팅 테이블에 인터넷 경로 넣어줬고,
프라이빗 쪽은 EC2에서만 접근할 수 있게 보안 그룹 설정함.
6. 정리하며
VPC를 직접 구성해보니 AWS 안에서의 네트워크 흐름이 훨씬 잘 보인다.
단순히 인스턴스 띄우는 것보다, 실제 서비스 운영을 고려해서 퍼블릭/프라이빗 분리하고 보안 고려하는 게 재밌었다.
다음엔 ELB랑 오토스케일링 쪽도 정리해봐야겠다.
