[Network] VPC

do_it·2025년 9월 16일
네트워크

network

목록 보기
10/12

0. 등장 배경

  1. 클라우드 초기의 단순 네트워크 구조
  • 모든 인스턴스가 공유 네트워크에 배치되어 사용자가 세부 네트워크를 제어할 수 없었음
    (e.g. AWS EC2 Classic)
  • 보안 그룹만으로 트래픽 제어 가능, 기업 수준의 격리·보안 제공 어려움
  1. 기업 환경의 요구 증가
  • 네트워크 분리: 고객별로 독립적인 네트워크 필요
  • 보안 제어 강화: IP 대역, 라우팅, 방화벽처럼 세밀한 제어 필요
  • 온프레미스와 통합: VPN이나 전용 회선을 통해 기존 데이터 센터와 연결 필요
  • 규제 준수: 금융, 헬스케어와 같은 산업은 네트워크 격리가 필수적
  1. 가상화 네트워킹 기술의 발전 → VPC 도입 (AWS.2009)
  • 하이퍼바이저 기반의 가상화 기술이 발전하면서, 물리적 네트워크를 가상적으로 분리하는 기술이 등장
    (VLAN, VXLAN, Overlay Network 등)
  • 이것을 클라우드에 적용하면서, 고객별 논리적 전용 네트워크를 제공할 수 있게 함

1. VPC란?

구분구성 요소설명예시/역할
네트워크 단위VPC클라우드 내 논리적 격리 네트워크전체 CIDR: 10.0.0.0/16, 멀티 AZ 포함
서브넷VPC 내 IP 범위 단위퍼블릭: 10.0.1.0/24, 프라이빗: 10.0.2.0/24, 라우팅/보안 적용
인터넷 연결 옵션인터넷 게이트웨이 (IGW)퍼블릭 서브넷과 인터넷 연결웹 서버, 로드밸런서, 퍼블릭 IP 필요
NAT Gateway /
NAT Instance프라이빗 서브넷 아웃바운드 인터넷DB, 백엔드 서버, 외부 접근 필요 시 사용
라우팅 테이블트래픽 경로 지정퍼블릭: 0.0.0.0/0 → IGW, 프라이빗: 0.0.0.0/0 → NAT
보안보안 그룹(SG)인스턴스 수준 방화벽, 상태 저장웹 서버: HTTP/HTTPS 허용, DB: 내부 IP만 허용
네트워크 ACL(NACL)서브넷 수준 방화벽, 상태 비저장특정 IP 범위 차단/허용
컴퓨팅/서비스인스턴스(EC2 등)실제 서비스 실행웹 서버, DB 서버, 백엔드 서버, 서브넷 + 보안 그룹 적용

VPC (Virtual Private Cloud)

: 클라우드 환경에서 사용자가 정의한 논리적으로 격리된 가상 네트워크
’논리적으로 격리된 네트워크’ → 다른 사용자들과 네트워크가 섞이지 않고, 마치 개인 전용 네트워크처럼 동작

‘논리적’?
물리적인 장비/ 장치가 아닌, 소프트웨어/설정을 사용

  • 클라우드 서비스 제공자가 관리하는 큰 네트워크 안에서 특정 사용자가 원하는 방식으로 가상 네트워크를 쪼개고 구성할 수 있는 기능
  • 온프레미스 네트워크와 유사하게 토폴로지를 설계할 수 있음
    [토폴로지]
    네트워크에 참여하는 컴퓨터, 스위치, 라우터 등 노드와 링크들의 물리적 또는 논리적 배치 방식

2. 아키텍처

  • VPC = 네트워크 토폴로지의 기본 틀
  • 최소 VPC 동작 요건 = VPC + Subnet + Route Table + Security Group
  • 인터넷 통신 필요 → IGW 필요
  • 프라이빗 서브넷에서 아웃바운드만 필요 → NAT 필요
  • 트래픽 제어 강화 필요 → NACL, 커스텀 라우팅, 추가 게이트웨이
💡 VPC를 하나의 아파트 단지로 비유
  • VPC : 아파트 단지 // 도시 (클라우드) 안에서 독립적으로 운영됨
  • 서브넷:
    퍼블릭: 상가
    프라이빗: 각 동
  • 보안그룹, NACL: 경비실 // 출입 통제
  • Internet/NAT Gateway: 단지 출입구 // 이 출입구를 통해 외부와 연결

1) 서브넷(Subnet)

: VPC 안에서 리소스를 논리적으로 격리하고 관리하며, 트래픽과 보안을 제어할 수 있는 최소 단위 네트워크

→ VPC 를 더 세분화해 관리하기 쉽게 만든 논리적 구획!

[e.g]
VPC의 IP 범위가 10.0.0.0/16이라면, 이를 10.0.1.0/24, 10.0.2.0/24처럼 나눠서 각각 서브넷으로 사용

서브넷 CIDR (Classless Inter-Domain Routing)

💡 넷마스크 & 프리픽스

프리픽스넷마스크설명
/8255.0.0.0클래스 A
/16255.255.0.0클래스 B
/24255.255.255.0클래스 C
/25255.255.255.128절반씩 나눈 서브넷
/30255.255.255.2522개 호스트만 사용 가능
  1. 넷마스크(Netmask)?

  • IP 주소에서 네트워크와 호스트를 구분하는 역할을 하는 값

  • 보통 255.255.255.0 같은 형태로 표현

  • 1비트는 네트워크, 0비트는 호스트

  • IP: 192.168.1.0

  • 넷마스크: 255.255.255.0 → 상위 24비트가 네트워크, 하위 8비트가 호스트

  • 결과: 192.168.1.0/24 로도 표기 가능

  1. 프리픽스(Prefix)란?
  • CIDR에서 /숫자로 나타나는 값
  • /24, /16 등 → 상위 몇 비트가 네트워크용인지 나타냄
  • 넷마스크를 2진수로 풀어서 비트 수를 세면 프리픽스 값
  1. CIDR?
    : IP 주소를 효율적으로 나누기 위해 사용되는 표기법 → IP 범위 지정 방법!
  • 형식: IP주소/프리픽스 길이 [e.g.] 10.0.0.0/16
  • /16 → 넷마스크 길이 의미, 즉 IP 주소 중 상위 16비트는 네트워크 식별용, 나머지는 호스트 식별용
  • 10.0.0.0/16 → 2¹⁶ = 65,536개 IP 가능
  • 이 VPC를 /24 서브넷으로 나누면 → 2⁸ = 256개 IP/서브넷
    • 예: 10.0.1.0/24, 10.0.2.0/24 …

  1. VPC CIDR?
    : 전체 가용 IP 범위

  2. 서브넷 CIDR?
    : VPC CIDR 블록 안에서 IP범위를 잘라서 만드는 것

  • 서브넷의 CIDR은 VPC CIDR의 부분집합
  • VPC: 10.0.0.0/16
  • 퍼블릭 서브넷: 10.0.1.0/24
  • 프라이빗 서브넷: 10.0.2.0/24

서브넷 특징

  • 리소스 배치 단위 EC2, RDS, Lambda 등 클라우드 리소스는 반드시 서브넷에 속해야 함
    (EC2, RDS 같은 리소스는 반드시 서브넷에 배치됨)
  • 트래픽 분리 및 관리 퍼블릭 서브넷 → 인터넷 접속 가능 프라이빗 서브넷 → 내부 전용, 외부와 직접 통신 불가
  • 보안 및 정책 적용 단위 NACL이나 라우팅 테이블을 서브넷 단위로 적용 가능
  • 고가용성(AZ 단위 배치) 서로 다른 가용 영역(AZ, Availability Zone)에 서브넷을 배치하면 장애 시 서비스 중단 최소화

서브넷 종류

  1. 퍼블릭 서브넷(Public Subnet)
    • IGW(Internet Gateway) 라우팅이 되어 있어 인터넷과 통신 가능
    • e.g. 웹 서버, 로드밸런서
  2. 프라이빗 서브넷(Private Subnet)
    • 외부 인터넷 접근 불가 (필요 시 NAT 게이트웨이를 통해 아웃바운드 가능)
    • eg. DB 서버, 내부 서비스
  3. 하이브리드/리미티드 서브넷
    • 특정 서비스(e.g. S3, DynamoDB)와만 통신하도록 VPC 엔드포인트 연결
    • 인터넷 직접 접근은 불가

설계 포인트

  • CIDR 블록 설계: 서브넷 IP 범위를 너무 작게 잡으면 인스턴스 확장 시 부족 → 너무 크게 잡으면 IP 낭비
  • AZ 배치 고려: 가용 영역별로 서브넷을 나눠 고가용성 구성
  • 라우팅 테이블과 연동: 퍼블릭/프라이빗 여부에 따라 IGW/NAT 라우팅 설정

2) 라우팅 테이블(Route Table)

: 목적지 IP 주소를 기준으로 트래픽 경로(Route)를 정의한 규칙 집합
→ 네트워크 트래픽이 어디로 가야하는지를 결정하는 지도 역할! (트래픽 흐름 결정)

  • VPC 생성 시 기본 라우팅 테이블(Default Route Table) 생성
  • 서브넷이 트래픽을 어디로 보내야 하는지 결정하는 핵심 요소
  • 모든 서브넷은 기본 테이블에 연결 가능
  • 서브넷에는 라우팅 테이블 하나 이상이 연결됨
  • 필요 시 커스텀 라우팅 테이블(Custom Route Table) 생성 → 서브넷 단위로 연결

구성 요소

  1. Destination (목적지)
    • 트래픽이 가야 하는 IP 범위
    • 예: 0.0.0.0/0 → 모든 인터넷 주소, 10.0.2.0/24 → 특정 서브넷
  2. Target (대상)
    - 트래픽을 전달할 대상
    - 예:
    - Internet Gateway(IGW) → 퍼블릭 인터넷
    - NAT Gateway → 프라이빗 서브넷에서 아웃바운드 인터넷
    - VPC Peering → 다른 VPC
    - Local → VPC 내부 통신

퍼블릭 & 프라이빗 서브넷 예시

  1. 퍼블릭 서브넷
    • 라우팅 테이블에 0.0.0.0/0 → IGW 추가
    • 외부 인터넷과 양방향 통신 가능
  2. 프라이빗 서브넷
    • 라우팅 테이블에 0.0.0.0/0 → NAT Gateway 추가
    • 내부 서버는 인터넷에 나갈 수 있지만, 외부에서 직접 접근 불가

3) 인터넷 게이트웨이(IGW)

: VPC 내부 리소스가 인터넷과 양방향 통신을 할 수 있도록 연결해주는 논리적 장치

  • 물리적 장치가 아니라 클라우드에서 제공하는 관리형 네트워크 리소스
  • 퍼블릭 서브넷 정의 기준이 됨
  • NAT와 함께 사용하면 프라이빗 서브넷도 안전하게 아웃바운드 인터넷 접근 가

IGW의 역할

  1. 아웃바운드 트래픽
    • VPC 내부 리소스가 인터넷으로 나가는 트래픽을 전달
  2. 인바운드 트래픽
    • 인터넷에서 퍼블릭 IP를 가진 리소스로 들어오는 트래픽 수용
  3. 퍼블릭 서브넷 정의 기준
    - VPC 안의 서브넷이 IGW 라우트를 갖고 있으면 퍼블릭 서브넷으로 분류

IGW의 특징

  1. 상태 저장 (stateful)
    인바운드 요청에 대한 응답 트래픽 자동 허용
  2. 고가용성
    VPC 단위로 제공, 여러 AZ에서도 사용 가능
  3. 공유가능
    하나의 IGW를 VPC 전체에서 공유 가능ㅇ
  4. IPv4 / IPv6 지원

사용 조건

퍼블릭 서브넷 - IGW 라우트 → 인터넷

프라이빗 서브넷 - NAT Gateway - 퍼블릭서브넷 - IGW → 인터넷

  1. 퍼블릭 IP / Elastic IP가 있는 리소스여야 인터넷 접근 가능
  2. 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW 라우트가 있어야 가능
  3. IGW 없이 퍼블릭 인터넷 접근 불가

4) NAT 게이트웨이/인스턴스

정의

NAT(Network Address Translation)
: 내부(private) 네트워크 IP를 외부(public) IP로 변환하여 프라이빗 서브넷에서 인터넷으로 나가는 트래픽을 가능하게 하는 장치
→ 프라이빗 서브넷에서 아운바운드 전용 출입구!

  • 프라이빗 서브넷에서 외부(예: OS 업데이트, 패키지 다운로드)로 나가야 할 때만 필요
  • 외부에서 프라이빗 서브넷으로의 직접 접근은 막음 (보안 유지)
프라이빗 서브넷 - NAT Gateway - 퍼블릭서브넷 - IGW → 인터넷
  • 2가지 유형이 있음
    NAT Gateway (관리형 서비스)
    NAT Instance (사용자 관리 EC2)

역할

  1. 아웃바운드 인터넷
    프라이빗 서브넷 내부 리소스가 인터넷에 나갈 수 있도록 변환
  2. 인바운드 차단
    외부에서 프라이빗 서브넷으로 직접 접근 불가
  3. ip 변환
    사설 IP → 퍼블릭 IP로 변환 (NAT)

사용 시나리오

  1. 프라이빗 서브넷에서 인터넷으로 나가는 경우
    : OS 업데이트, 패키지 다운로드, API 호출…
  2. 외부에서 직접 접근은 차단하고 싶은 경우
    : DB 서버, 내부 API 서버…

NAT Gateway & NAT Instance

항목NAT GatewayNAT Instance
유형AWS 관리형 서비스EC2 인스턴스
관리자동 관리,
고가용성(HA) 제공사용자 직접 관리, 장애 처리 필요
성능고성능, 자동 확장인스턴스 스펙에 따라 제한
비용비교적 비쌈인스턴스 타입에 따라 비용 조절 가능
설정 편리성매우 쉬움라우팅, 보안 그룹 직접 설정 필요
사용 추천생산 환경, 고가용성 필요테스트/저렴한 환경, 유연한 설정 필요

NAT Gateway

  • AWS 관리형 서비스
  • 특징:
    • 고가용성(HA) 제공, 자동 확장
    • 퍼블릭 서브넷에 배치
    • 유지보수 필요 없음(AWS에서 자동 관리)
    • 성능이 높고, 트래픽 처리량이 많음
    • 비용: 사용량 기준 과금, 인스턴스보다 다소 비쌈
  • 사용 시나리오:
    - 프라이빗 서브넷의 서버가 인터넷에서 패키지 다운로드 필요할 때
    - DB, 백엔드 서버는 외부에서 접근 불가하면서 업데이트 필요

NAT Instance

  • 사용자가 직접 만든 EC2 인스턴스
  • 특징:
    • 직접 구성, 관리, 모니터링 필요
    • HA, 확장성은 직접 설계해야 함
    • 비용은 EC2 인스턴스 타입에 따라 조절 가능
    • 커스텀 설정 가능 → 트래픽 로깅, 방화벽 추가 등
    • 성능은 인스턴스 스펙에 따라 제한
  • 사용 시나리오:
    • 테스트 환경에서 비용 절약용
    • 특정 커스텀 NAT 기능 필요 시
    • 고성능/HA가 필요 없는 소규모 환경

5) 보안 그룹(Security Group)

인스턴스 : 클라우드 상의 가상 서버

: VPC 안에서 인스턴스의 가상 방화벽 역할
→ 인스턴스 수준 방화벽! : 어떤 트래픽을 허용하고 차단할 것인가를 결정

특징

  • 인바운드 & 아웃바운드 트래픽을 허용 / 차단할 수 있음
  • 트래픽 허용 중식 (allow-only) 방식
    : 생성 시 기본적으로 인바운드는 차단, 아웃바운드는 허용
    규칙으로 명시한 트래픽만 허
  • 상태 저장(Stateful) 특징
    인바운드 허용 트래픽이 있으면, 응답 아웃바운드 트래픽은 자동허용
  • CIDR / IP, 포트 기반
    트래픽을 IP범위, 포트, 프로토콜로 세밀하게 제어
  • 다중 보안 그룹 적용 가능
    하나의 인스턴스에 여러 보안 그룹 연결 가능
특징설명
적용 단위인스턴스 수준
상태 저장인바운드 요청에 대한 응답은 자동 허용
기본 규칙생성 시 기본 아웃바운드는 허용, 인바운드는 차단
CIDR/IP, 포트 기반트래픽을 IP 범위, 포트, 프로토콜로 세밀하게 제어
여러 보안 그룹 연결 가능하나의 인스턴스에 다수 보안 그룹 적용 가능

### 적용 방식
  • 규칙 기반 필터링
  1. IP / CIDR 범위 : 어떤 주소에서 들어오거나 나갈지
  2. 포트 번호: 어떤 서비스 (http, ssh, DB..) 허용
  3. 프로토콜: TCP, UDP,ICMP…
  • 상태저장 → 단방향 규칙만 설정해도 요청 - 응답 양방향 통신 가능

6) NACL

NACL (Network Access Control List)

: 서브넷 단위의 네트워크 트래픽 필터

→ 서브넷 전체에 적용되는 양방향 체크포인트!

  • 서브넷에 들어오고 나가는 트래픽을 허용 / 거부
  • 보안 그룹과는 달리 stateless(상태 비저장) 방식
  • 규칙 타입: 허용(Allow) / 거부(Deny) 가능
  • 순서 기반
    : 규칙 번호 순서대로 평가, 가장 낮은 번호 우선 적용
  • 기본 동작
    기본적으로 모든 트래픽을 허용함, 필요 시 수정 가능
  • VPC 생성 시 기본 NACL이 자동으로 적용됨
항목보안 그룹NACL
적용 단위인스턴스서브넷
상태 저장StatefulStateless
규칙허용(Allow)만허용(Allow)/거부(Deny) 가능
기본 동작인바운드 차단, 아웃바운드 허용기본: 모든 트래픽 허용
우선순위모든 규칙 적용낮은 번호 규칙 우선 적용

### 서브넷 & 인스턴스
  • 서브넷: VPC안에서 IP 범위를 나눈 논리적 네트워크 단위
    인스턴스: 서브넷 안에 배치되는 가상 서버
  • 서브넷 단위로 라우팅 테이블, NACL을 적용
    인스턴스 단위로 보안그룹 적용
VPC (전체 네트워크)
 ├─ 서브넷 A (퍼블릭 서브넷)
 │    ├─ 인스턴스 1 (웹 서버)
 │    └─ 인스턴스 2 (웹 서버)
 └─ 서브넷 B (프라이빗 서브넷)
      ├─ 인스턴스 3 (DB 서버)
      └─ 인스턴스 4 (백엔드 API 서버)

NACL & 보안 그룹

관계 = NACL로 서브넷 트래픽을 거르고, 보안 그룹으로 인스턴스 접근을 세밀하게 제어

  • 다층 보안 (Defense in Depth)
    NACL → 서브넷 단위로 기본적인 허용 / 거부 설정
    보안 그룹 → 인스턴스 단위로 세밀하게 허용 규칙 설정

[e.g.]

  • NACL: 서브넷 외부 IP 차단
  • 보안 그룹: 웹 서버만 HTTP/HTTPS 허용, DB 서버는 내부 IP만 허용

3. VPC Peering

VPC A (10.0.0.0/16)   <--- VPC Peering --->   VPC B (192.168.0.0/16)
   └─ EC2 인스턴스 A                          └─ EC2 인스턴스 B
   
   
// 라우팅 테이블에 서로의 CIDR 추가
// 보안 그룹에서 상대 IP 허용
// EC2 A <-> EC2 B가 프라이빗 IP로 직접 통신

: 서로 다른 두개의 VPC 간에 프라이빗 네트워크 연결을 설정하는 것

  • 마치 두 개의 VPC를 LAN 케이블로 직접 연결하는 것처럼 동작
  • 서로 다른 VPC 안의 인스턴스들이 프라이빗 IP주소로 직접 통신 가능

특징

  1. 프라이빗 통신
    인터넷 게이트웨이 필요없음
    트래픽은 AWS 내부 네트워크를 통해 전송(보안성↑, 속도↑)
  2. 일대일 연결
    VPC 간 1:1 연결
    A ↔ B, B ↔ C 연결했다고 해서 A ↔ C가 자동 연결되는 건 아님 (트랜싯 불가)
  3. 라우팅 필요
    연결 후에도 각 VPC 라우팅 테이블에 상대 VPC CODR 블록을 추가해야 통신 가능
  4. 보안 그룹과 NACL 적용
    VPC Peering이 있어도, 보안 그룹/NACL에서 상대 IP 범위를 허용하지 않으면 통신 불가

사용

  • 조직 내 여러 VPC간 통신 (운영 ↔ 로깅/ 모니터링_
  • 멀티 계정 환경
  • 리전 간 Peering (Inter-Region Peering)
profile
do_it
이전 포스트

[Network] 대칭키 & 비대칭키 암호화

다음 포스트

[Network] 로드밸런싱

0개의 댓글