Foundation · 가상 네트워크

Amazon VPC

데이터 센터 네트워크를 AWS 안에 그대로 설계합니다

AWS Networking Services · First Call2026-10-17

Agenda

아젠다

  1. 서비스 개요
  2. 고객 과제
  3. 주요 이점
  4. 동작 방식
  5. 주요 기능
  6. 비교와 선택 기준
  7. 사용 사례
  8. 레퍼런스 아키텍처
  9. 고객 사례
  10. 비용
  11. 최근 업데이트
  12. 시작하기
  13. 다음 단계

Customer challenges

고객이 겪는 문제

외부에 노출하면 안 되는 서버를 분리하기 어렵습니다

애플리케이션 서버와 데이터베이스는 인터넷에서 직접 접근할 수 없어야 하지만, 업데이트 다운로드 같은 아웃바운드 통신은 필요합니다. 계층별로 접근 경로를 나누지 않으면 보안 요구사항과 운영 요구사항을 함께 맞추기 어렵습니다.

IP 대역이 겹치면 나중에 연결할 수 없습니다

온프레미스나 다른 VPC와 IP 대역이 겹치면 VPC 간 연결이나 하이브리드 연결을 구성할 수 없습니다. 처음 정한 CIDR의 크기는 바꿀 수 없어서, 계획 없이 만든 네트워크는 확장할 때 다시 설계해야 합니다.

계정과 VPC가 늘수록 관리가 복잡해집니다

사업 단위, 환경, 리전이 늘면서 VPC가 수백 개로 늘어납니다. VPC 간 연결, 온프레미스 연결, 인터넷 출구와 보안 규칙을 VPC마다 따로 관리하면 운영 부담이 커집니다.

Overview

Amazon Virtual Private Cloud (Amazon VPC)

Amazon VPC는 사용자가 정의한 논리적으로 격리된 가상 네트워크입니다. 기존 데이터 센터에서 운영하던 네트워크와 비슷한 구조를 AWS 인프라 위에서 구성합니다. VPC 자체에는 추가 요금이 없고, NAT 게이트웨이 같은 일부 구성 요소에만 요금이 부과됩니다.

/16 ~ /28
VPC IPv4 CIDR 블록 크기 범위 (65,536개 ~ 16개 주소)
200
VPC당 기본 서브넷 수 (상향 가능)
5 → 50
VPC당 IPv4 CIDR 블록 수 (기본 5개, 최대 50개까지 상향)
60
보안 그룹당 기본 인바운드·아웃바운드 규칙 수 (각각 적용)

Benefits

왜 VPC부터 설계해야 하나요

Isolate

워크로드 단위로 네트워크를 분리합니다

워크로드나 조직 단위로 VPC를 나누어 인프라를 격리합니다. 하나의 VPC 안에서는 서브넷으로 웹, 애플리케이션, 데이터베이스 계층을 분리합니다.

Route

트래픽 경로를 직접 정합니다

라우팅 테이블이 서브넷과 게이트웨이에서 나가는 트래픽의 목적지를 결정합니다. 인터넷 게이트웨이, NAT 게이트웨이, VPC 엔드포인트, Transit Gateway 중 어디로 보낼지 경로 단위로 지정합니다.

Control

여러 계층에서 접근을 통제합니다

보안 그룹이 리소스 단위의 기본 통제 수단이고, 네트워크 ACL이 서브넷 단위의 보조 통제를 맡습니다. VPC Block Public Access로 계정 전체의 인터넷 접근을 한 번에 차단할 수도 있습니다.

How it works

동작 방식

  1. 1

    VPC와 CIDR

    VPC를 만들 때 IPv4 CIDR 블록을 지정하며, RFC 1918 사설 대역 사용을 권장합니다. 생성 후 보조 IPv4 CIDR와 IPv6 CIDR를 추가할 수 있지만 기존 CIDR의 크기는 바꿀 수 없습니다.

  2. 2

    서브넷과 가용 영역

    서브넷은 VPC의 IP 대역 일부이며 하나의 AZ 안에만 존재합니다. 리소스를 여러 AZ의 서브넷에 나누어 배치하면 단일 AZ 장애에 대비할 수 있습니다.

  3. 3

    라우팅 테이블이 서브넷 유형을 정합니다

    인터넷 게이트웨이로 가는 직접 경로가 있으면 퍼블릭 서브넷, 없으면 프라이빗 서브넷입니다. VPC 밖으로 가는 경로가 전혀 없으면 격리된 서브넷이 됩니다.

  4. 4

    게이트웨이와 엔드포인트로 외부와 연결합니다

    인터넷 게이트웨이는 인터넷과, NAT 게이트웨이는 프라이빗 서브넷의 아웃바운드 통신을 연결합니다. VPC 엔드포인트를 쓰면 인터넷 게이트웨이나 NAT 장치 없이 AWS 서비스에 프라이빗으로 접근합니다.

Key features · 1/2

주요 기능

Subnet (public / private / isolated)

서브넷은 IPv4 전용, 듀얼 스택, IPv6 전용으로 만들 수 있습니다. 라우팅 테이블 구성에 따라 퍼블릭, 프라이빗, VPN 전용, 격리된 서브넷으로 구분됩니다.

Security Group / Network ACL

보안 그룹은 상태 저장 방식의 리소스 단위 방화벽이고, 다른 보안 그룹을 규칙에서 참조할 수 있습니다. 네트워크 ACL은 서브넷 단위의 상태 비저장 규칙으로 특정 트래픽을 거부하는 보조 통제에 씁니다.

NAT gateway (public / private)

프라이빗 서브넷의 인스턴스가 VPC 밖으로 연결을 시작할 수 있게 하고, 외부에서 시작하는 연결은 받지 않습니다. 퍼블릭 NAT 게이트웨이는 탄력적 IP 주소로 인터넷에, 프라이빗 NAT 게이트웨이는 Transit Gateway나 가상 프라이빗 게이트웨이를 거쳐 다른 VPC나 온프레미스에 연결합니다.

Regional NAT gateway 2025-11

하나의 NAT 게이트웨이가 워크로드가 있는 AZ를 따라 자동으로 확장·축소됩니다. 퍼블릭 서브넷이 필요 없고, AZ가 늘어나도 라우팅 테이블을 고칠 필요가 없습니다. 프라이빗 NAT 용도에는 영역별 NAT 게이트웨이를 사용합니다.

Key features · 2/2

주요 기능

Gateway VPC endpoint

인터넷 게이트웨이나 NAT 장치 없이 Amazon S3와 DynamoDB에 접근합니다. 라우팅 테이블에 서비스의 접두사 목록을 목적지로 하는 경로가 추가되며, 추가 요금은 없습니다.

VPC Encryption Controls 2025-11

리전 내 VPC 안과 VPC 간 트래픽의 전송 중 암호화 상태를 모니터링하고 강제합니다. 모니터 모드에서 VPC Flow Logs의 encryption-status 필드로 평문 트래픽을 찾고, 정리한 뒤 적용 모드로 전환합니다.

IPAM (IP Address Manager)

AWS 워크로드의 IP 주소를 계획, 추적, 모니터링하는 VPC 기능입니다. 비즈니스 규칙에 따라 VPC에 CIDR를 자동 할당하고, 조직 전체의 IP 할당 이력을 확인합니다.

VPC sharing / VPC Flow Logs

VPC 공유는 VPC 소유 계정이 같은 AWS Organizations의 다른 계정에 서브넷을 공유하는 방식입니다. VPC Flow Logs는 네트워크 인터페이스를 오가는 IP 트래픽 정보를 CloudWatch Logs, S3, Data Firehose로 보내며 네트워크 성능에 영향을 주지 않습니다.

Compare

보안 그룹과 네트워크 ACL 비교

항목보안 그룹네트워크 ACL
적용 위치인스턴스(ENI) 단위서브넷 단위
적용 범위보안 그룹이 연결된 모든 인스턴스연결된 서브넷 안의 모든 인스턴스
규칙 유형허용 규칙만 지원허용과 거부 규칙 모두 지원
규칙 평가모든 규칙을 평가한 뒤 허용 여부를 결정번호가 낮은 규칙부터 순서대로 평가하고 처음 일치한 규칙을 적용
응답 트래픽자동 허용 (상태 저장)명시적으로 허용해야 함 (상태 비저장)
권장 용도기본 접근 통제 수단특정 트래픽 차단, 서브넷 단위 가드레일

Use cases

사용 사례

다중 계층 웹 애플리케이션 호스팅

웹 서버, 애플리케이션 서버, 데이터베이스를 서로 다른 서브넷에 두고 계층 간 연결과 제한을 정의합니다. 인터넷에서 들어오는 트래픽은 퍼블릭 서브넷에서만 받습니다.

AWS 제품 페이지에서 보기 ↗

온프레미스와 연결하는 하이브리드 네트워크

VPC를 Site-to-Site VPN이나 Direct Connect로 데이터 센터와 연결하고, VPC 피어링이나 Transit Gateway로 다른 VPC와 연결합니다. 클라우드 리소스와 기존 인프라를 하나의 네트워크처럼 사용합니다.

AWS 문서에서 보기 ↗

여러 계정이 함께 쓰는 중앙 관리형 VPC

네트워크 계정이 VPC를 소유하고 같은 AWS Organizations의 다른 계정에 서브넷을 공유합니다. 각 계정은 공유받은 서브넷에 자기 리소스만 만들고 관리하며, 관리할 VPC 수는 줄어듭니다.

AWS 문서에서 보기 ↗

Reference architecture

2개 AZ에 걸친 퍼블릭·프라이빗 서브넷 구성

2개 AZ의 public subnet에 ALB와 NAT gateway, private subnet에 Auto Scaling group 서버, S3 gateway endpoint가 있는 VPC
출처: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html
  1. VPC에 2개 AZ마다 퍼블릭 서브넷과 프라이빗 서브넷을 하나씩 둡니다.
  2. 사용자 요청은 인터넷 게이트웨이를 거쳐 퍼블릭 서브넷의 Application Load Balancer로 들어오고, 프라이빗 서브넷에서 Auto Scaling 그룹으로 실행되는 서버로 전달됩니다.
  3. 서버의 인터넷 아웃바운드 트래픽은 각 AZ의 NAT 게이트웨이로, S3 트래픽은 게이트웨이 VPC 엔드포인트로 나갑니다.

Reference architecture

리전별 NAT 게이트웨이로 단순화한 아웃바운드 구성

AZ별 zonal NAT gateway 구성(A)과 regional NAT gateway 하나로 단순화한 구성(B) 비교
왼쪽(A)은 AZ마다 영역별 NAT 게이트웨이를 두는 기존 구성, 오른쪽(B)은 리전별 NAT 게이트웨이 구성입니다.
출처: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateways-regional.html
  1. 각 AZ에 영역별 NAT 게이트웨이와 퍼블릭 서브넷을 두는 대신, VPC에 리전별 모드 NAT 게이트웨이 하나를 만듭니다.
  2. 모든 AZ의 프라이빗 서브넷 라우팅 테이블이 같은 NAT 게이트웨이 ID를 가리키고, NAT 게이트웨이는 자체 라우팅 테이블의 경로로 인터넷 게이트웨이에 트래픽을 보냅니다.
  3. 새 AZ에 리소스가 생기면 NAT 게이트웨이가 그 AZ로 자동 확장합니다.

Customer stories

고객 사례

Carrier Global

제조 (HVAC·냉장·화재 안전)

Amazon VPC로 팀별 네트워크 환경을 구성하고 Transit Gateway로 VPC를 허브 앤 스포크 방식으로 연결했습니다. 이후 Amazon VPC IPAM으로 새 계정에 표준 기준과 가드레일을 적용해 계정 생성 시간을 3일에서 몇 분으로 줄였습니다.

Q2

금융 소프트웨어 (디지털 뱅킹)

민감한 워크로드 리소스를 VPC의 프라이빗 서브넷에 배치해, 인바운드·아웃바운드 트래픽 검사 없이 인터넷으로 바로 나가는 경로를 두지 않았습니다. VPC 내부 동서 트래픽은 AWS Network Firewall 규칙으로 통제합니다.

Pricing · 1/2

비용 항목

VPC 자체 사용에는 추가 요금이 없습니다. NAT 게이트웨이, 퍼블릭 IPv4 주소, IPAM, Traffic Mirroring, Reachability Analyzer, Network Access Analyzer 같은 구성 요소에 요금이 부과됩니다.

NAT gateway
게이트웨이별(리전별 NAT 게이트웨이는 AZ별) 시간당 요금과 처리한 데이터량(GB)에 대한 요금, 표준 데이터 전송 요금이 부과됩니다.
Public IPv4 주소
사용 중인 주소와 유휴 주소에 각각 시간당 요금이 부과되며, 초 단위(최소 60초)로 과금됩니다. 프라이빗 IPv4 주소는 과금되지 않습니다.
IPAM
Free Tier는 무료이고, Advanced Tier는 활성 IP 주소별 시간당 요금이 부과됩니다.
VPC Encryption Controls
모니터 또는 적용 모드로 동작하는 비어 있지 않은 VPC마다 시간당 고정 요금이 부과됩니다.

단가는 리전마다 다릅니다. https://aws.amazon.com/vpc/pricing/

Pricing · 2/2

비용 항목

Traffic Mirroring / 분석 도구
Traffic Mirroring은 활성화한 네트워크 인터페이스별 시간당, Reachability Analyzer는 분석 건당, Network Access Analyzer는 평가한 네트워크 인터페이스별로 과금됩니다.
데이터 전송 (VPC Peering 등)
리전 내 VPC 피어링은 AZ를 넘는 트래픽에 양방향 데이터 전송 요금이 부과됩니다. VPC Flow Logs는 CloudWatch vended logs 수집·보관 요금이 적용됩니다.

단가는 리전마다 다릅니다. https://aws.amazon.com/vpc/pricing/

What's new

최근 업데이트

Getting started

시작하기

  1. 1

    IP 대역을 계획합니다

    온프레미스와 다른 VPC와 겹치지 않는 RFC 1918 대역을 고릅니다. 기존 CIDR의 크기는 바꿀 수 없으므로 확장 여유를 두고, 여러 계정이라면 IPAM으로 할당을 관리합니다.

  2. 2

    AZ와 서브넷 계층을 나눕니다

    최소 2개 AZ에 서브넷을 만들고 웹, 애플리케이션, 데이터베이스 계층을 서브넷으로 분리합니다. 인터넷에서 직접 접근할 필요가 없는 리소스는 프라이빗 서브넷에 둡니다.

  3. 3

    라우팅과 외부 연결을 정합니다

    서브넷별 라우팅 테이블에 필요한 최소 경로만 넣습니다. 인터넷 아웃바운드는 NAT 게이트웨이로, S3·DynamoDB는 게이트웨이 엔드포인트로, 다른 VPC와 온프레미스는 Transit Gateway나 VPN·Direct Connect로 연결합니다.

  4. 4

    보안 통제를 계층별로 적용합니다

    보안 그룹을 기본 통제 수단으로 쓰고, 필요한 경우 네트워크 ACL을 보조로 둡니다. 인터넷 노출을 막아야 하는 계정에는 VPC Block Public Access를, 암호화 요구사항이 있으면 VPC Encryption Controls를 검토합니다.

  5. 5

    가시성을 확보합니다

    VPC Flow Logs로 트래픽을 기록하고, 연결 문제는 Reachability Analyzer로 라우팅 테이블과 보안 그룹 설정을 점검합니다.

Next steps

다음 단계

VPC 계획 가이드로 설계를 시작합니다

IP 대역, 가용 영역, 인터넷 연결 방식을 순서대로 정한 뒤 VPC를 만듭니다. 공식 문서의 Plan your VPC 절차를 따라 개발 환경에 먼저 구성해 봅니다.

다중 VPC 설계 모범 사례를 검토합니다

계정과 VPC가 늘어날 경우를 대비해 IP 주소 계획, VPC 간 연결, 중앙 집중 이그레스, DNS 설계 기준을 미리 확인합니다.

Pricing Calculator로 비용을 추정합니다

VPC 자체는 무료이므로 NAT 게이트웨이, 퍼블릭 IPv4 주소, 데이터 전송량처럼 과금되는 구성 요소를 중심으로 월 비용을 계산합니다.

아키텍처 리뷰와 PoC를 진행합니다

현재 온프레미스 IP 대역과 연결 요구사항을 공유해 주시면 VPC 구성안을 함께 검토합니다. 대표 워크로드 하나로 서브넷, 라우팅, 보안 통제를 검증하는 PoC를 제안합니다.

Resources

참고 자료

Q&A