VPC(Virtual Private Cloud)클라우드 안에 네트워크 만드는 법!

VPC(Virtual Private Cloud) 완전 정복 클라우드 안에 내 전용 네트워크 만드는 법 3단계 참조이미지 — VPC(Virtual Private Cloud) 완전 정복

클라우드를 처음 접하면 가장 먼저 만나게 되는 개념 중 하나가 바로 VPC(Virtual Private Cloud)예요. 이름이 어렵지만, 한 마디로 설명하면 "클라우드 안에 내가 직접 만드는 나만의 가상 건물"이에요. 마치 거대한 아파트 단지(클라우드) 안에 내 집(VPC)을 짓고, 내 집 안에 방(서브넷)을 나누고, 문과 자물쇠(보안 그룹, 라우팅)를 다는 것과 같아요. 이 글에서는 AWS를 기준으로 VPC를 만드는 핵심 3단계를 쉽게 설명할게요.

1단계: VPC 생성 — 나만의 가상 건물 짓기

VPC를 만드는 첫 번째 단계는 "내 네트워크의 전체 범위를 정하는 것"이에요. 집을 짓기 전에 땅의 크기를 정하는 것과 같아요. 이때 사용하는 개념이 CIDR(Classless Inter-Domain Routing)입니다. 쉽게 말해, 내 네트워크에서 쓸 수 있는 IP 주소가 몇 개인지 범위를 정하는 거예요.

AWS 콘솔에서 VPC 만들기

AWS 콘솔 → VPC 서비스로 이동
왼쪽 메뉴에서 "Your VPCs" 클릭
"Create VPC" 버튼 클릭
이름 입력 (예: my-first-vpc)
IPv4 CIDR 블록 입력 (예: 10.0.0.0/16)
나머지 기본값 유지 후 "Create VPC" 클릭

AWS CLI로 VPC 만들기

# VPC 생성
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# 생성된 VPC에 이름 태그 추가
aws ec2 create-tags \
  --resources vpc-xxxxxxxxxxxxxxxxx \
  --tags Key=Name,Value=my-first-vpc

# VPC 목록 확인
aws ec2 describe-vpcs

CIDR 범위 이해하기

10.0.0.0/16 → 사용 가능한 IP 주소가 65,536개 (큰 회사용)
10.0.0.0/24 → 사용 가능한 IP 주소가 256개 (소규모 테스트용)
AWS에서는 /16 ~ /28 사이의 CIDR을 사용할 수 있어요.

VPC를 처음 만들 때 저는 CIDR 범위를 너무 작게 잡아서 나중에 서버를 더 추가하려다 IP가 부족해지는 상황을 경험했어요. 처음에 /24로 만들었는데, 개발·운영·테스트 환경을 나누다 보니 금방 IP가 모자라더라고요. 결국 VPC를 새로 만들고 기존 자원들을 이전하는 작업을 해야 했는데, 이게 정말 번거로운 작업이에요. 그래서 저는 처음부터 넉넉하게 /16으로 만드는 걸 강력히 권장해요. IP가 남는 건 문제가 안 되지만, 부족한 건 나중에 엄청난 작업을 유발하거든요. 또 VPC는 리전(Region, 지역)마다 따로 존재해요. 서울 리전에 만든 VPC는 도쿄 리전에는 없어요. 처음엔 이게 헷갈려서 엉뚱한 리전에서 VPC를 찾다가 시간을 낭비한 적도 있어요. 그리고 AWS는 기본 VPC(Default VPC)를 각 리전에 자동으로 만들어주는데, 이것에 의존해서 서비스를 올리는 건 보안상 좋지 않아요. 기본 VPC는 모든 설정이 열려 있는 상태라 공부용으로는 좋지만, 실제 서비스에서는 직접 만든 VPC를 쓰는 게 좋습니다. 클라우드 보안의 시작은 바로 이 VPC 설계에서 결정된다고 해도 과언이 아니에요.

2단계: 서브넷 생성과 라우팅 설정 — 방 나누고 통로 연결하기

VPC를 만들었다면 이제 그 안을 나눠야 해요. 이걸 서브넷(Subnet)이라고 해요. 큰 집 안에 방을 나누는 것처럼, VPC 안에 목적에 맞는 공간을 구분하는 거예요.

서브넷은 크게 두 종류예요.

퍼블릭 서브넷(Public Subnet) : 인터넷과 직접 연결되는 공간이에요. 웹서버처럼 외부에서 접근해야 하는 서버를 여기 둬요.
프라이빗 서브넷(Private Subnet) : 인터넷과 직접 연결되지 않는 내부 공간이에요. 데이터베이스처럼 외부에서 직접 접근하면 안 되는 서버를 여기 둬요.

서브넷 생성 (AWS CLI)

# 퍼블릭 서브넷 생성 (가용 영역: ap-northeast-2a)
aws ec2 create-subnet \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --cidr-block 10.0.1.0/24 \
  --availability-zone ap-northeast-2a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-1a}]'

# 프라이빗 서브넷 생성
aws ec2 create-subnet \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --cidr-block 10.0.2.0/24 \
  --availability-zone ap-northeast-2a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-1a}]'

인터넷 게이트웨이(IGW) 생성 및 연결 — 퍼블릭 서브넷의 대문 달기

# 인터넷 게이트웨이 생성
aws ec2 create-internet-gateway

# VPC에 연결
aws ec2 attach-internet-gateway \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --internet-gateway-id igw-xxxxxxxxxxxxxxxxx

라우팅 테이블 설정 — 어디로 가야 하는지 표지판 세우기

# 퍼블릭 서브넷용 라우팅 테이블 생성
aws ec2 create-route-table --vpc-id vpc-xxxxxxxxxxxxxxxxx

# 인터넷 게이트웨이로 가는 경로 추가 (0.0.0.0/0 = 인터넷 전체)
aws ec2 create-route \
  --route-table-id rtb-xxxxxxxxxxxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxxxxxxxxxxxxxxxx

# 퍼블릭 서브넷에 라우팅 테이블 연결
aws ec2 associate-route-table \
  --route-table-id rtb-xxxxxxxxxxxxxxxxx \
  --subnet-id subnet-xxxxxxxxxxxxxxxxx

서브넷 설계는 VPC 설계에서 가장 많이 고민되는 부분이에요. 저는 처음에 서브넷을 하나만 만들어서 모든 서버를 퍼블릭 서브넷에 올렸어요. 편리하긴 했지만, 나중에 보안 감사를 받을 때 "왜 DB 서버가 인터넷에 직접 노출되어 있냐"는 지적을 받았어요. 그때부터 퍼블릭과 프라이빗 서브넷을 제대로 나누기 시작했어요. 실제로 데이터베이스는 절대 퍼블릭 서브넷에 두면 안 돼요. 프라이빗 서브넷에 두고, 웹서버만 퍼블릭에 놓는 것이 기본 보안 구조예요. 또 가용 영역(AZ, Availability Zone)을 여러 개에 걸쳐 서브넷을 만들어야 한다는 것도 중요한 포인트예요. 서울 리전의 경우 ap-northeast-2a, 2b, 2c, 2d 네 개의 가용 영역이 있는데, 서버를 한 AZ에만 두면 그 AZ에 장애가 생겼을 때 서비스 전체가 다운돼요. 저도 이걸 무시하다가 특정 AZ 점검 시간에 서비스가 잠깐 중단된 경험이 있어요. 고가용성(HA)은 처음 설계할 때부터 고려해야 나중에 고생을 안 해요. 라우팅 테이블도 처음엔 너무 복잡해 보이지만, "어디서 온 패킷을 어디로 보낼까"를 결정하는 교통 신호등이라고 생각하면 이해가 쉬워요.

3단계: 보안 그룹과 NAT 게이트웨이 설정 — 자물쇠와 우편함 달기

네트워크를 만들었으면 이제 보안을 설정할 차례예요. 클라우드에서의 보안은 두 가지 핵심 요소로 구성돼요.

① 보안 그룹(Security Group) — 각 서버의 자물쇠

보안 그룹은 각 서버(인스턴스)에 적용되는 방화벽이에요. 어떤 포트로 어떤 IP가 접근할 수 있는지를 결정해요.

# 웹서버용 보안 그룹 생성
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Security group for web server" \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx

# HTTP(80번 포트) 허용 - 전 세계에서 접근 가능
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxxxxxxxxxx \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

# HTTPS(443번 포트) 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxxxxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# SSH(22번 포트)는 내 IP에서만 허용 (보안상 중요!)
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxxxxxxxxxx \
  --protocol tcp \
  --port 22 \
  --cidr 내.아이.피.주소/32

② NAT 게이트웨이 — 프라이빗 서브넷의 우편함

프라이빗 서브넷에 있는 서버는 인터넷과 직접 연결이 안 돼요. 그런데 서버도 소프트웨어 업데이트나 외부 API 호출을 위해 가끔 인터넷에 나가야 해요. 이때 사용하는 게 NAT 게이트웨이예요. 외부에서 내부 서버의 실제 IP는 모르면서, 내부 서버는 인터넷에 나갈 수 있게 해주는 일종의 우편 대행 서비스예요.

# Elastic IP(고정 IP) 할당 (NAT 게이트웨이에 필요)
aws ec2 allocate-address --domain vpc

# NAT 게이트웨이 생성 (퍼블릭 서브넷에 위치해야 함)
aws ec2 create-nat-gateway \
  --subnet-id subnet-퍼블릭서브넷ID \
  --allocation-id eipalloc-xxxxxxxxxxxxxxxxx

# 프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이 경로 추가
aws ec2 create-route \
  --route-table-id rtb-프라이빗라우팅테이블ID \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-xxxxxxxxxxxxxxxxx

전체 3단계 구조 요약

인터넷
  ↓
[인터넷 게이트웨이 (IGW)]
  ↓
[VPC: 10.0.0.0/16]
  ├── [퍼블릭 서브넷: 10.0.1.0/24]
  │     └── 웹서버 (보안 그룹: 80, 443 허용)
  │           ↓ (내부 통신)
  └── [프라이빗 서브넷: 10.0.2.0/24]
        └── DB 서버 (보안 그룹: 3306 내부만 허용)
              ↓ (외부 접근 필요 시)
        [NAT 게이트웨이] → 인터넷

보안 그룹 설정에서 저는 초반에 SSH 포트(22번)를 0.0.0.0/0, 즉 전 세계에 열어놓은 채로 운영한 적이 있어요. 그때는 '어차피 비밀번호도 있고 괜찮겠지'라고 생각했는데, 서버 로그를 보니 하루에도 수천 번씩 로그인 시도가 들어오고 있더라고요. 그제야 SSH를 내 IP로만 제한하고, 키 페어 인증만 허용하도록 바꿨어요. NAT 게이트웨이는 처음엔 "굳이 필요한가?"라고 생각했는데, 프라이빗 서버에서 yum update 같은 패키지 업데이트를 할 때 없으면 얼마나 불편한지 금방 깨달았어요. 또 NAT 게이트웨이는 시간당 요금이 부과되기 때문에, 테스트 환경에서는 사용 후 꼭 삭제하는 습관이 필요해요. 저는 한 달 동안 삭제를 깜빡해서 예상치 못한 비용이 청구된 경험이 있어요. 클라우드는 편리하지만, 쓰지 않는 자원을 그냥 두면 비용이 계속 나간다는 점을 꼭 명심해야 해요. 전체 3단계를 마치고 나면 꽤 그럴듯한 네트워크 인프라가 완성되는데, 이게 실제 대기업들이 사용하는 VPC 기본 구조와 크게 다르지 않아요. 기초를 탄탄하게 익히면 나중에 복잡한 멀티 VPC, VPN 연결, Transit Gateway 같은 고급 개념도 자연스럽게 이해할 수 있게 됩니다.

참고 출처

AWS 공식 문서 - VPC 개요 : https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
AWS 공식 문서 - 서브넷 생성 : https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html
AWS 공식 문서 - 인터넷 게이트웨이 : https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
AWS 공식 문서 - NAT 게이트웨이 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
AWS 공식 문서 - 보안 그룹 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
AWS 공식 문서 - 라우팅 테이블 : https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html
AWS 공식 문서 - CIDR 표기법 : https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html
AWS CLI 레퍼런스 - ec2 create-vpc : https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc.html

저작자표시 비영리 동일조건 (새창열림)

'IT적응기' 카테고리의 다른 글

SDN 핵심 개념 4가지– 네트워크 자동화 현장 경험기 (0)	2026.04.17
SDN(소프트웨어 정의 네트워크)하드웨어 없이 네트워크를 바꾸는 기술 (0)	2026.04.16
기초 보안의 ACL(Access Control List)로 특정 IP 차단 설정법 (0)	2026.04.16
트래픽 병목 현상 LACP(Link Aggregation)로 대역폭을 확장방법 (0)	2026.04.15
패킷 캡처 - 와이어샤크(Wireshark)로 L2-L3 헤더가이드 (0)	2026.04.15

깜짝,황금이 아빠 IT적응기

VPC(Virtual Private Cloud)클라우드 안에 네트워크 만드는 법!

1단계: VPC 생성 — 나만의 가상 건물 짓기

2단계: 서브넷 생성과 라우팅 설정 — 방 나누고 통로 연결하기

3단계: 보안 그룹과 NAT 게이트웨이 설정 — 자물쇠와 우편함 달기

참고 출처

'IT적응기' 카테고리의 다른 글

티스토리툴바

티스토리툴바

VPC(Virtual Private Cloud)클라우드 안에 네트워크 만드는 법!

1단계: VPC 생성 — 나만의 가상 건물 짓기

2단계: 서브넷 생성과 라우팅 설정 — 방 나누고 통로 연결하기

3단계: 보안 그룹과 NAT 게이트웨이 설정 — 자물쇠와 우편함 달기

참고 출처

'IT적응기' 카테고리의 다른 글

관련글

티스토리툴바

티스토리툴바