Datacenter & Cloud - 04. 클라우드 네트워킹 기초

클라우드에서 나만의 가상 네트워크를 만드는 법 — 클라우드 네트워킹 기초

AWS에 가입하면 — 가장 먼저 해야 하는 일이 VPC(Virtual Private Cloud) 만들기다. VPC 없이는 — EC2 인스턴스를 만들 수 없다. VPC는 — 클라우드 안의 나만의 가상 데이터센터다. 이전 글에서 본 오버레이(VXLAN)가 — 그 VPC를 물리적으로 구현하는 기술이고, 이 글은 — 사용자가 다루는 VPC의 구조와 설정을 다룬다. 서브넷·보안 그룹·라우팅 테이블·인터넷 게이트웨이가 — 어떻게 함께 작동해 클라우드 네트워크를 만드는지.

VPC — 클라우드의 사설 네트워크

VPC(Virtual Private Cloud) 는 — 클라우드 안에서 격리된 사설 네트워크 공간이다. 비유하자면 — 거대한 아파트 단지(클라우드) 안의 나만의 호실(VPC)이다. 다른 고객의 네트워크와 완전히 격리되고 — 자기만의 IP 주소 범위(CIDR)·서브넷·라우팅 규칙을 갖는다.

flowchart TD
    VPC["VPC 10.0.0.0/16<br/>(나만의 가상 네트워크)"] --> SN_PUB["Public 서브넷<br/>10.0.1.0/24 (AZ-A)"]
    VPC --> SN_PRIV["Private 서브넷<br/>10.0.2.0/24 (AZ-A)"]
    VPC --> SN_PUB2["Public 서브넷<br/>10.0.3.0/24 (AZ-B)"]
    VPC --> SN_PRIV2["Private 서브넷<br/>10.0.4.0/24 (AZ-B)"]
    IGW["인터넷 게이트웨이<br/>(IGW)"] <--> VPC
    SN_PUB --> WEB["웹 서버<br/>(공인 IP 있음)"]
    SN_PRIV --> DB["DB 서버<br/>(공인 IP 없음)"]

VPC를 만들 때 가장 먼저 정하는 것 — CIDR 블록. 예: 10.0.0.0/16 (65,536개 주소). 이 범위 안의 IP 주소를 서브넷에 분배한다. foundations 04에서 본 사설 IP 대역(RFC 1918)을 쓴다 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

VPC 항목	AWS	GCP	Azure
이름	VPC	VPC 네트워크	VNet
CIDR	/16 ~ /28	글로벌(서브넷별 CIDR)	서브넷별 CIDR
서브넷 범위	AZ 단위	리전 단위	AZ 단위
기본 방화벽	보안 그룹 + NACL	방화벽 규칙	NSG
인터넷 연결	인터넷 게이트웨이	기본 제공(라우팅만)	부하 분산 장치

서브넷 — VPC를 쪼개는 단위

서브넷(subnet) 은 — VPC를 더 작은 네트워크로 나눈 것이다. foundations 04에서 본 서브네팅이 클라우드에 적용된 것. VPC 10.0.0.0/16을 — 10.0.1.0/24(256 주소), 10.0.2.0/24, 10.0.3.0/24...로 나눈다.

서브넷의 핵심 속성은 — AZ(Availability Zone)에 연결된다는 것. 각 서브넷은 하나의 AZ에 속한다. 10.0.1.0/24는 AZ-A, 10.0.3.0/24는 AZ-B. foundations 03에서 본 fault domain이 여기서 실천된다 — DB를 AZ-A와 AZ-B의 두 서브넷에 나눠 배치하면 — 한 AZ가 날아가도 다른 AZ가 살아있는다.

서브넷의 두 가지 유형:

• Public 서브넷 — 인터넷에서 직접 접근 가능. 인터넷 게이트웨이(IGW)로의 라우팅이 있다. 웹 서버·로드 밸런서가 여기.
• Private 서브넷 — 인터넷에서 직접 접근 불가. IGW로의 라우팅이 없다. DB·캐시·내부 서비스가 여기.

flowchart LR
INTERNET["인터넷"] --> IGW["인터넷 게이트웨이"]
IGW --> PUB["Public 서브넷<br/>(웹 서버, 공인 IP)"]
PUB -->|"라우팅 허용"| PRIV["Private 서브넷<br/>(DB, 사설 IP만)"]
PRIV --x|"인터넷에서 직접 접근 불가"| INTERNET

보안 그룹 — 상태 저장 방화벽

보안 그룹(Security Group) 은 — 인스턴스(VM) 수준의 방화벽이다. 상태 저장(stateful) — 들어온 요청의 응답은 자동으로 허용. "들어오는 443 포트를 허용"하면 — 응답으로 나가는 패킷은 별도 규칙 없이 통과.

보안 그룹의 규칙:

• 인바운드(Inbound) — 어떤 IP·포트에서 들어오는 것을 허용할 것인가. 기본: 모두 거부.
• 아웃바운드(Outbound) — 어디로 나가는 것을 허용할 것인가. 기본: 모두 허용(AWS).

예: 웹 서버의 보안 그룹 — 인바운드 443(HTTPS) 허용, 22(SSH)는 특정 IP에서만. 나머지 인바운드는 거부. 아웃바운드는 모두 허용(앱이 외부 API를 호출해야 하니까).

특성	보안 그룹 (Security Group)	NACL (Network ACL)
적용 단위	인스턴스(VM)	서브넷
상태	상태 저장(stateful)	상태 비저장(stateless)
규칙 평가	모두 평가(허용 우선)	번호순(첫 매칭 적용)
허용 규칙	허용만 가능(거부 불가)	허용·거부 모두 가능
기본 정책	인바운드 모두 거부	인바운드 모두 허용(기본 NACL)
적용 방식	인스턴스에 연결	서브넷에 자동 적용

라우팅 테이블 — 서브넷의 길잡이

각 서브넷은 하나의 라우팅 테이블(route table) 에 연결된다. 라우팅 테이블이 — "이 목적지로 가는 패킷은 어디로?"를 결정한다. foundations 04에서 본 라우팅 테이블의 클라우드 버전이다.

# Public 서브넷의 라우팅 테이블 예시
목적지          타겟
10.0.0.0/16    local              # 같은 VPC는 직접
0.0.0.0/0      igw-xxx            # 나머지는 인터넷 게이트웨이로

# Private 서브넷의 라우팅 테이블 예시
목적지          타겟
10.0.0.0/16    local              # 같은 VPC는 직접
# 인터넷으로의 경로 없음          # 인터넷에서 접근 불가

0.0.0.0/0 → igw-xxx가 있으면 — 그 서브넷은 public. 없으면 — private. 이 라우팅 규칙 하나가 public/private를 결정한다.

인터넷 게이트웨이 — VPC와 인터넷의 경계

인터넷 게이트웨이(IGW, Internet Gateway) 는 — VPC와 인터넷을 잇는 문이다. VPC 안의 서버가 인터넷으로 나가려면(또는 인터넷에서 들어오려면) — IGW를 거쳐야 한다. IGW는 — NAT(1:1)를 수행한다 — VPC의 사설 IP를 공인 IP로 변환.

IGW는 VPC당 하나만 연결된다. 모든 public 서브넷의 트래픽은 이 IGW를 통해 인터넷으로 나간다.

실습 — 클라우드 네트워킹 확인

1. VPC와 서브넷 확인 (AWS CLI)

# VPC 목록
aws ec2 describe-vpcs --query 'Vpcs[*].[VpcId,CidrBlock]' --output table 2>/dev/null
# 서브넷 목록
aws ec2 describe-subnets --query 'Subnets[*].[SubnetId,VpcId,CidrBlock,AvailabilityZone]' --output table 2>/dev/null

확인할 것: VPC의 CIDR 블록. 서브넷이 여러 AZ에 걸쳐 있는지(fault domain 분산).

2. 보안 그룹 규칙 확인

# 보안 그룹 규칙
aws ec2 describe-security-groups --query 'SecurityGroups[*].[GroupName,IpPermissions[*].[IpProtocol,FromPort,ToPort]]' --output table 2>/dev/null

확인할 것: 허용된 인바운드 포트. 22(SSH)가 0.0.0.0/0에 열려 있으면 — 보안 위험(특정 IP만 허용해야).

3. 라우팅 테이블 확인

# 라우팅 테이블
aws ec2 describe-route-tables --query 'RouteTables[*].Routes[*].[DestinationCidrBlock,GatewayId]' --output table 2>/dev/null

확인할 것: 0.0.0.0/0이 igw-xxx를 가리키면 — public 서브넷. 없으면 — private 서브넷.

미검증: AWS CLI는 자격증명이 설정된 환경에서만 동작. GCP는 gcloud compute networks list, Azure는 az network vnet list로 동일 정보 확인.

클라우드 네트워킹은 "코드로 만드는 네트워크"다

VPC를 이해하면 — "클라우드에서 네트워크를 만든다"는 게 — 물리 케이블을 까는 게 아니라 코드(API·Terraform)로 논리 구조를 정의하는 일이라는 게 보인다. VPC·서브넷·보안 그룹·라우팅 테이블 — 이 네 가지가 — 클라우드 네트워킹의 기본 빌딩 블록이다. 다음 글에서는 이 기본 위에 얹히는 서비스를 다룬다 — NAT 게이트웨이·VPC 피어링·Transit Gateway가 여러 VPC와 인터넷을 어떻게 잇는지.

VPC 피어링 — VPC 간 연결

VPC 피어링(VPC Peering) 은 — 두 개의 VPC를 — 인터넷을 거치지 않고 직접 연결하는 기술. 서로 다른 AWS 계정의 VPC, 또는 다른 리전의 VPC를 연결할 수 있다. 트래픽은 AWS 내부망을 통해 전달되니 — 빠르고 안전하다.

하지만 VPC 피어링은 — VPC가 늘어나면 조합 폭발이 일어난다. VPC 10개를 전부 서로 연결하려면 — 45개의 피어링 연결(10 x 9 / 2)이 필요하다. 100개면 4,950개. 이 문제를 해결하는 것이 Transit Gateway(다음 글에서 다룸)다.

VPC 연결 방식	연결 수	복잡도	전형 사례
VPC 피어링	N*(N-1)/2	VPC 수 증가 시 폭발	소수 VPC 연결
Transit Gateway	N (hub-and-spoke)	선형 증가	대규모 VPC 연결
VPN/Direct Connect	인터넷/전용선	인터넷 지연	온프레미스 연결

클라우드 네트워킹과 foundations의 연결

VPC의 모든 개념은 — foundations에서 다룬 어휘의 클라우드 실천이다. 서브넷은 foundations 04의 서브네팅, 보안 그룹은 foundations 03의 fault domain 격리, 라우팅 테이블은 foundations 04의 라우팅, 멀티 AZ 배치는 foundations 04의 redundancy. 클라우드 네트워킹은 — 이 모든 것을 API 버튼 하나로 만들어 주는 것이다.

GCP VPC의 차이 — 글로벌 VPC

AWS VPC가 하나의 리전에 묶이는 반면 — GCP VPC는 글로벌이다. 하나의 VPC가 여러 리전에 걸쳐 서브넷을 가질 수 있다. 서울 리전의 서브넷과 도쿄 리전의 서브넷이 — 같은 VPC 안에 있고 — VPC 피어링 없이 직접 통신할 수 있다. 이게 가능한 이유는 — Google의 내부 네트워크가 글로벌 사설망(B4)으로 모든 리전을 묶고 있기 때문이다. AWS는 리전마다 VPC를 만들고 — 리전 간 통신에는 VPC 피어링이나 Transit Gateway가 필요하다.

네트워크 설계 원칙 — 최소 권한 네트워크

클라우드 네트워킹 설계의 핵심 원칙은 — 최소 권한(least privilege) 이다. 모든 서브넷·보안 그룹·라우팅 규칙이 — "필요한 것만 허용, 나머지는 거부"로 설계돼야 한다. Public 서브넷에 DB를 두지 않고, 보안 그룹에서 22번 포트를 0.0.0.0/0에 열지 않고, private 서브넷에 인터넷 경로를 만들지 않는 것. foundations 03에서 본 defense in depth가 — 네트워크 설계에서 실천되는 것이다.

보안 그룹 설계 원칙

보안 그룹은 — 화이트리스트(whitelist) 방식이다. 기본이 "모두 거부"이고, 필요한 것만 허용 규칙을 추가한다. 이게 — 전통적 방화벽의 "블랙리스트(blacklist, 기본 허용 + 위험한 것만 거부)"와 반대다. 화이트리스트가 보안상 더 강하다 — 새로운 위협이 나타나도 — 허용 목록에 없으면 자동으로 차단되니까.

보안 그룹의 좋은 설계 원칙:

• 역할별 그룹 — 웹 서버용 보안 그룹, DB용 보안 그룹을 분리. "웹 서버는 443 수신, DB는 웹 서버에서만 5432 수신."
• 참조 그룹 — AWS에서 보안 그룹이 다른 보안 그룹을 참조할 수 있다. "DB 보안 그룹은 웹 서버 보안 그룹에서만 5432 포트 접근 허용." IP가 아니라 보안 그룹을 참조하니 — 서버가 추가돼도 자동으로 허용.
• 최소 권한 — 0.0.0.0/0(전체 인터넷)을 여는 건 443(HTTPS)과 80(HTTP)만. 22(SSH)는 특정 IP(bastion host)에서만.

NACL — 서브넷 수준의 추가 방어

NACL(Network ACL) 은 — 서브넷 수준의 방화벽이다. 보안 그룹이 인스턴스별이라면 — NACL은 서브넷 전체에 적용된다. 상태 비저장(stateless) — 들어온 요청의 응답도 별도 규칙이 없으면 차단된다. 인바운드·아웃바운드 규칙을 모두 명시해야 한다.

NACL은 보안 그룹의 보조 방어선이다. 보안 그룹이 실수로 너무 넓게 열렸을 때 — NACL이 서브넷 수준에서 추가로 차단한다. foundations 03에서 본 "defense in depth"가 — 클라우드 네트워킹에서 실천되는 것이다. 다만 — 대부분의 일상적 사용에서는 — 보안 그룹만으로 충분하고, NACL은 기본값(모두 허용)으로 두는 경우가 많다. 특정 IP를 서브넷 수준에서 차단해야 할 때(DDoS 방어·악성 IP 차단) NACL을 쓴다.

인터넷 게이트웨이와 NAT의 차이

인터넷 게이트웨이(IGW) 와 NAT 게이트웨이는 — 둘 다 VPC와 인터넷을 잇지만, 방향이 다르다.

• IGW — 양방향. 인터넷에서 VPC로 들어올 수도 있고, VPC에서 인터넷으로 나갈 수도 있다. public 서브넷에 연결.
• NAT 게이트웨이 — 단방향(나가는 것만). private 서브넷의 서버가 인터넷으로 나갈 수 있지만 — 인터넷에서는 들어올 수 없다. DB 서버가 패키지 업데이트를 다운로드해야 하지만 — 인터넷에서 직접 접근은 막아야 할 때 쓴다.

이 둘의 조합이 — typical 클라우드 네트워크를 만든다. public 서브넷(IGW)에 로드 밸런서·bastion을 두고 — private 서브넷(NAT)에 DB·앱 서버를 둔다. 인터넷에서는 public 서브넷을 통해서만 접근하고 — private 서브넷은 인터넷에 노출되지 않는다.

VPC 엔드포인트 — 인터넷을 거치지 않고 AWS 서비스에 접근

private 서브넷의 서버가 S3나 DynamoDB에 접근하려면 — 원래는 NAT 게이트웨이를 통해 인터넷으로 나가서 AWS 서비스에 접속했다. 이건 — 비용(NAT 데이터 처리 요금)도 들고 보안상(인터넷 경유)으로도 이상하다 — 같은 AWS 안에 있는데 왜 인터넷을 거쳐야 하나?

VPC 엔드포인트(VPC Endpoint, PrivateLink) 는 — AWS 서비스를 VPC 안으로 프라이빗하게 연결한다. S3·DynamoDB·SQS 같은 서비스를 — 인터넷을 거치지 않고 VPC 내부망으로 직접 접근. 비용이 절감되고 보안이 강화된다. 엔드포인트는 — 다음 글(cloud network services)에서 깊이 다룬다.

클라우드 네트워킹의 핵심 — "코드로 만드는 네트워크"

VPC를 이해하면 — "클라우드에서 네트워크를 만든다"는 게 — 물리 케이블을 까는 게 아니라 코드로 논리 구조를 정의하는 일이라는 게 보인다. VPC·서브넷·보안 그룹·라우팅 테이블 — 이 네 가지가 클라우드 네트워킹의 기본 빌딩 블록이다. foundations 06의 IaC 철학이 — 네트워크에 적용된 것이다.

실제 VPC 설계 패턴 — 3계층 아키텍처

가장 흔한 클라우드 네트워크 설계 패턴은 — 3계층(3-tier) VPC다. public·private·data 서브넷으로 나누고, 각 층의 접근 권한을 단계적으로 제한한다.

flowchart TD
    INTERNET["인터넷"] --> ALB["로드 밸런서<br/>(public 서브넷, 다중 AZ)"]
    ALB --> APP1["앱 서버 1<br/>(private 서브넷, AZ-A)"]
    ALB --> APP2["앱 서버 2<br/>(private 서브넷, AZ-B)"]
    APP1 --> DB["DB<br/>(data 서브넷, AZ-A)"]
    APP2 --> DB
    DB --> REPL["DB 복제본<br/>(data 서브넷, AZ-B)"]
    NAT["NAT GW<br/>(private 서브넷<br/>인터넷 아웃바운드)"] --> INTERNET
    APP1 --> NAT
    APP2 --> NAT

이 구조의 보안 원칙:

• 인터넷 → public 서브넷(ALB)만 접근 가능. ALB는 443 포트만 열음.
• public → private: ALB만 앱 서버의 8080 포트에 접근. 인터넷에서 앱 서버 직접 접근 불가.
• private → data: 앱 서버만 DB의 5432 포트에 접근. public에서 DB 직접 접근 불가.
• private → 인터넷: NAT 게이트웨이를 통해서만. 인터넷에서 private 접근 불가.

각 층의 보안 그룹이 — "바로 아래 층에서만 접근 허용"으로 설정된다. 이 계단식 접근 제어가 — foundations 03의 defense in depth를 클라우드에서 실천하는 것이다.

VPC Flow Logs — 네트워크 트래픽 기록

VPC Flow Logs는 — VPC 내의 모든 네트워크 트래픽을 기록하는 기능이다. "누가, 언제, 어디로, 얼마나"의 통신 기록을 CloudWatch Logs나 S3에 저장한다. 보안 감사·장애 분석·비용 분석에 필수.

# Flow Log 예시 (요약)
2 123456789010 eni-abc123 10.0.1.5 10.0.2.10 443 49152 6 10 8080 1626789600 1626789700 ACCEPT OK

• 버전, 계정 ID, ENI, 출발지 IP, 목적지 IP, 목적지 포트, 출발지 포트, 프로토콜(6=TCP), 패킷 수, 바이트 수, 시작 시간, 종료 시간, 액션(ACCEPT/REJECT)

Flow Logs는 — "보안 그룹이 제대로 동작하는가?", "이상한 IP가 접근을 시도하는가?", "DB 서버가 예상치 못한 외부와 통신하는가?"를 확인하는 핵심 도구다.

클라우드 네트워킹 설계 체크리스트

• VPC CIDR이 충분히 큰가? (향정 확장 고려, 최소 /16)
• 서브넷이 최소 2개 AZ에 걸쳐 있는가? (HA)
• public 서브넷에 DB를 두지 않았는가? (최소 권한)
• 보안 그룹에서 22(SSH)를 0.0.0.0/0에 열지 않았는가?
• private 서브넷이 인터넷에 노출되지 않는가?
• NAT 게이트웨이가 다중 AZ에 있는가? (단일 AZ NAT는 SPOF)
• VPC Flow Logs가 켜져 있는가?
• 각 서브넷의 라우팅 테이블이 public/private 의도에 맞는가?

클라우드 네트워킹은 — VPC·서브넷·보안 그룹·라우팅 테이블
네 가지 빌딩 블록으로 만드는 논리적 네트워크다.
foudations 06의 IaC 철학이 네트워크에 적용된 것이다.

VPC의 네 가지 빌딩 블록 — VPC·서브넷·보안 그룹·라우팅 테이블.
이것만 이해하면 — 클라우드 네트워크의 80%를 다룰 수 있다.
나머지 20%는 — 다음 글에서 다루는 NAT·피어링·Transit Gateway다.

---

참고

• AWS, "Amazon VPC User Guide" — VPC 공식 문서. 접근 2026-07-21. URL: https://docs.aws.amazon.com/vpc/
• GCP, "VPC documentation" — GCP VPC. 접근 2026-07-21
• Azure, "Virtual Network documentation" — Azure VNet. 접근 2026-07-21
• AWS, "AWS Security Groups vs Network ACLs" — 보안 그룹·NACL 비교. 접근 2026-07-21
• Aditya, P. et al. "Will Serverless End the Dominance of Serverless Computing in the Cloud?" IEEE Cloud, 2019 — 클라우드 네트워킹 진화. 접근 2026-07-21