[AWS] AWS VPC 이해하기 : 기본적인 네트워크 지식 정리 및 VPC 관련 정보 요약
2026년 3월에 필자는 AWS SAA-C03 자격증을 취득했다.
그런데 AWS를 사용하면서 가장 크게 이해해야 하는 것은 기본적인 네트워크 지식들과 VPC라고 생각했다.
참고로 필자는 유데미에서 Ultimate AWS Certified Solutions Architect Associate 2026강의를 참고했다.
물론 시험에 합격하고 나서도 듣지 않고 있다가... 중요한게 뭐가 있을까~ 싶어서 보니 VPC섹션이었고 해당 섹션을 다 들었다.
하지만 공식 문서를 읽어볼 것이며 이 그림을 이해하는 여정을 그럼 떠나볼 것이다.
AWS를 섹션으로 하니 AWS기준으로 제품 설명들을 읽을 것이고,
목표
1. AWS 에서 제공하는 vpc서비스들에 대해서 이해한다.
1. VPC란? AWS VPC란?
VPC(Virtual Private Cloud)는 퍼블릭 클라우드 내에 포함된 프라이빗 클라우드 컴퓨팅 환경이다.
Amazon VPC는 AWS에서 제공하는 VPC이다.
VPC가 근데 왜 필요하지?
이에 대해서는 Reddit 사이트에 잘 정리가 되어 있어서 이 글을 가져왔다. (원본글 여기 클릭!)
인터넷에 연결된 모든 장치는 네트워크 내에 있어야 합니다. 모든 컴퓨팅 장치를 거대한 라우터에 네트워크 케이블로 직접 연결하면, 장치 간 통신을 제어하기가 매우 어려운 거대한 개방형 네트워크가 만들어집니다.
만약 하나의 장치가 해킹당하면 다른 모든 장치도 해킹당할 수 있다면 결코 이상적인 환경이 아니겠죠? VPC(Virtual Platform)는 AWS 데이터 센터의 거대한 네트워크를 논리적으로 격리된 작은 네트워크로 분리하고, 네트워크 리소스 간의 통신을 허용하는 규칙을 설정할 수 있도록 해줍니다.
VPC 내의 장치는 명시적으로 허용하지 않는 한 VPC 외부 또는 다른 VPC 내의 장치와 네트워크를 통해 통신할 수 없습니다. 이것이 바로 VPC가 "기본적으로 안전하다"는 것을 의미합니다. VPC는 처음부터 인터넷과 완전히 격리되어 있으며, AWS 내부의 다른 모든 장치와도 격리되어 있습니다. 그런 다음, 네트워크에 적용할 최소한의 액세스 규칙과 라우팅 규칙을 구축하면 됩니다.
참고로, AWS 네트워킹을 이해하는 데 어려움을 겪는 대부분의 이유는 바로 이 "기본적으로 안전함" 때문입니다. 네트워킹이 작동하지 않는 경우 99% 확률로 보안 그룹 규칙이 누락되었거나 잘못 구성되었거나, 또는 VPC에서 명시적으로 허용하기 전까지 해당 네트워킹 연결을 허용하지 않는 네트워킹 경로가 누락되었기 때문입니다.
솔직히 필자는 EC2를 쓰면서 VPC는 뭔지를 몰랐다.
결과만 정리하면 VPC 내부에서 작동하는 서비스가 있고 외부에서 작동하는 서비스가 있다.
다음 그림을 보면 Instance 들은 VPC 안의 Subnet에 들어가 있다.
S3, Lambma, Route 53 등등 AWS 에서 제공하는 여러 서비스가 있는데 필자는 뭐가 VPC고 아닌지가 헷갈려서 이를 Gemini에게 정리해달라고 했다.
1. VPC 내부에서 작동하는 서비스 (VPC-bound Services)
사용자가 직접 정의한 가상 네트워크(VPC)의 서브넷 안에 배치되며, 사설 IP(Private IP)를 할당받아 작동하는 컴퓨팅 및 데이터베이스 자원들입니다.
- 구조적 특징: VPC라는 네트워크 울타리 안에 갇혀 있으므로, 라우팅 테이블, 보안 그룹(Security Group), 네트워크 ACL의 직접적인 통제와 보호를 받습니다. 리소스를 생성할 때 반드시 특정 VPC와 서브넷을 지정해야 합니다.
- 대표적인 서비스: * Amazon EC2 (컴퓨팅 인스턴스)
- Amazon RDS (관계형 데이터베이스)
- Amazon ElastiCache (Redis/Memcached 캐시)
- Application Load Balancer (ALB)
- Amazon EKS 워커 노드
2. VPC 외부에서 작동하는 서비스 (Public / Global Services)
VPC라는 특정 사용자의 네트워크 경계에 종속되지 않고, AWS가 직접 관리하는 거대한 공용 네트워크 영역이나 글로벌 엣지 인프라 위에서 구동되는 관리형 서비스들입니다.
- 구조적 특징: 서브넷이나 사설 IP를 할당받지 않으며, 고유한 엔드포인트(URL/DNS)를 통한 API 호출 방식으로 접근합니다. 네트워크 레벨의 접근 제어보다는 IAM 정책(Policy)이나 리소스 기반 정책(예: S3 Bucket Policy)을 통해 보안을 통제합니다.
- 대표적인 서비스:
- 리전(Region) 수준: Amazon S3, Amazon DynamoDB, SQS, SNS, API Gateway 등
- 글로벌(Global) 수준: AWS IAM, Amazon Route 53, Amazon CloudFront 등
3. 통신 원리와 아키텍처 최적화: VPC 엔드포인트(VPC Endpoint)
이러한 구조적 분리는 통신 관점에서 중요한 아키텍처 이슈를 발생시킵니다.
예를 들어, 프라이빗 서브넷에 위치한 백엔드 애플리케이션(EC2)이 이미지 파일을 S3에 업로드하거나 DynamoDB 데이터를 조회해야 한다고 가정해 보겠습니다. S3와 DynamoDB는 VPC 외부에 있으므로, 원칙적으로는 NAT 게이트웨이와 인터넷 게이트웨이(IGW)를 거쳐 퍼블릭 인터넷 망을 타고 통신해야 합니다.
하지만 내부 트래픽이 외부 인터넷을 경유하는 것은 네트워크 지연(Latency) 증가, NAT 데이터 처리 비용 발생, 그리고 보안 취약점 노출이라는 단점을 동반합니다. 이를 해결하기 위해 사용하는 AWS 네트워크 구조가 바로 **VPC 엔드포인트(VPC Endpoint)**입니다.
- 게이트웨이 엔드포인트 (Gateway Endpoint): 라우팅 테이블의 경로를 조작하여, 트래픽이 인터넷을 거치지 않고 AWS 내부의 프라이빗 백본망을 통해 S3나 DynamoDB와 직접 통신하도록 연결합니다.
- 인터페이스 엔드포인트 (Interface Endpoint / AWS PrivateLink): 프라이빗 서브넷 내부에 사설 IP를 가진 가상의 네트워크 인터페이스(ENI)를 생성합니다. 이를 통해 SQS, SNS 등 외부 API 서비스를 마치 VPC 내부에 존재하는 로컬 자원인 것처럼 안전하게 호출할 수 있습니다.
요약
안전하고 확장 가능한 클라우드 인프라를 구축하려면 애플리케이션의 뼈대가 되는 컴퓨팅 자원은 VPC 내부에 격리하여 강력한 네트워크 통제를 적용해야 합니다. 동시에 데이터 저장소나 메시징 큐와 같은 관리형 서비스는 VPC 외부의 자원을 활용하되, VPC 엔드포인트를 통해 내부 시스템과 퍼블릭 인터넷 망의 개입 없이 안전하게 연동하는 아키텍처로 설계해야 합니다.
생각을 해보면 EC2 생성시에 뭔가 VPC를 선택하라고 한다.
DemoVPC는 필자가 공부하면서 만든 VPC인데, Subnet 설정이 가능하다.
public subnet으로 쓸 것인지, private subnet으로 쓸것인지 VPC를 용도에 맞게 분리할 수 있는데, 네트워크 설정에서 그래서 어떤 VPC를 쓸 것인지 선택하는 것이다.
AWS에서는 어느것이 public subnet이고, 어느것이 private subnet이다! 하고 설정하는 건 아니다.
우리가 논리적으로 구분해서 말을 하는 것이다.
DefaultVPC는 무엇인가? 이에 대한 정보는 Default VPCs에서 확인할 수 있다.
DefaultVPC는 준비 과정 없이 빠르게 시작하여 블로그나 간단한 웹 사이트 같은 퍼블릭 인스턴스를 시작하는데 적합한 VPC!
EC2를 처음 만들어서 접속하게 되면 다들 여지없이 DefaultVpc를 사용했을 것이다.
2. Region과 Available Zone, subnet과 router, 게이트웨이, 라우팅 테이블
이 섹션에서는 필자가 맨날 헷갈려하는 지식을 정리하려고 한다.
2.1)Region과 Available Zone
한글로 번역한 것을 보면 리전 혹은 지역(region)과 가용영역(available zone)이다. (리전, 가용 영역 및 로컬 영역 공식문서)
각 리전 혹은 지역(Region)은 분리된 지리적 지역이다.
가용영역 (Available Zone)은 각 지역 내에 고립된 위치다.
이렇게 보면 어렵게 느껴지는데 region은 그냥 어디서 서비스 할 것인지 지역을 말한다.
더 설명을 보자면 각각의 리전은 다수의 독립적인 위치가 있다. 이것이 가용영역이라고 알려져 있다.
한 리전에서 가용영역들은 서로 저지연성(low-latency), 고대역폭(high-bandwidth), 고가용성 네트워크(highly-available networking)으로 연결된다.
Available Zone은 다음과 같이 Region안에 있다.
2.2) Subnet(서브넷) 과 Router(라우터)
서브넷? 뭔가 밑에 있는 net? 혹은 인터넷을 말하는건가? 싶었다.
cloudfare에서 이에 대해 설명해주고 있다.(what is a Subnet? - cloudfare)
라우터도 cloudfare에서 설명하고 있다.(What is a router? - cloudfare)
말 그대로 network 안에 network를 subnet이라고 한다.
이게 그럼 왜 필요할까?
subnet는 network를 더욱 효울적으로 만든다. 서브넷으로 만드는 작업, 즉 subnetting을 통해서 네트워크 트래픽이 목적지에 도달할 때 까지 불필요한 router를 거치지 않고 짦은 거리를 이동할 수 있다.
여기서 router란?
route 라는 단어에 대해 생각해보자. 길이다. 한국말로 구수~하게 발음해보면 루트다. 우리가 알고 있는 길!을 뜻한다. 새로운 루트를 개척했다! 하는 말 기억하는가? 여기서 루트에 er를 붙여서 라우터라고 해보자. 길을 만들어주는 사람 혹은 물건이다.
즉, 라우터(router)는 둘 이상의 패킷 전환 네트워크 또는 서브네트워크를 연결하는 장치이다. 길을 만들어주는 것이다. 두 개의 서브 네트워크사이에! 그런데 서브 네트워크가 뭔가? 네트워크 안의 네트워크를 subnet이라고 한다.
즉, router는 둘 이상의 subnet을 연결하는 장치라고 말 할 수도 있다.
어쨋든 subnet같에 연결을 해서 응답을 router를 통해서 주고받고 할 것인데, 그 수 많은 subnet중에서 정확히 어디로 갈 지는 subnet mask를 통해서 알 수 있다 CIDR 표기법도 존재한다. (CIDR 주소 범위 확인)
VPC내부에 이제 subnet을 생성해서 router를 통해서 특정 vpc내부의 서비스에 연결할 수 있도록 한다.
그러면서 vpc내부에 subnet mask를 설정해서 어디부터 어디까지를 특정 서비스를 위해서 할당할 것 인지 정할 수 있다.
2.3) Internal Gateway, Transite Gateway
Gateway를 해석하면 관문이다. 스타2를 한 분이라면 프로토스의 건물인 차원관문을 기억할 것이다.
영어로 하면 dimention gateway로, 아마 외계종족이 다른 차원을 넘어서 넘어와서 그렇게 이름을 붙인 것으로 혼자 생각한다.
그런데 말이다. 예를 들어서 ec2를 띄웠다고 해보자. 이 gateway가 왜 필요한건가?
우선은 위 가장 큰 청사진에서 볼 수 있는 Internal Gateway, Transit Gateway에 대한 설명은 다음과 같다.
순서대로 읽어보자. 우선Internal Gateway이다. (Internal Gateway 랑 Transit Gateway)
인터넷 게이트웨이는 VPC와 인터넷 간의 통신을 가능하게 하는 수평 확장, 이중화 및 고가용성을 갖춘 VPC 구성 요소입니다.
IPv4 및 IPv6 트래픽을 모두 지원하며, 네트워크 트래픽에 가용성 위험이나 대역폭 제약을 유발하지 않습니다. 인터넷 게이트웨이를 사용하면 공용 서브넷의 리소스(예: EC2 인스턴스)가 공용 IPv4 주소 또는 IPv6 주소를 가지고 있는 경우 인터넷에 연결할 수 있습니다.
마찬가지로 인터넷의 리소스도 공용 IPv4 주소 또는 IPv6 주소를 사용하여 서브넷의 리소스에 연결할 수 있습니다. 예를 들어, 인터넷 게이트웨이를 사용하면 로컬 컴퓨터를 사용하여 AWS의 EC2 인스턴스에 연결할 수 있습니다.
인터넷 게이트웨이는 인터넷으로 라우팅 가능한 트래픽에 대해 VPC 라우팅 테이블에 대상을 제공합니다. IPv4를 사용하는 통신의 경우 인터넷 게이트웨이는 NAT(네트워크 주소 변환)도 수행합니다. 자세한 내용은 IP 주소 및 NAT를 참조하십시오.
인터넷 게이트웨이는 VPC 구성 요소중 하나로 를 사용하면 로컬 컴퓨터를 사용하여 AWS의 EC2인스턴스에 연결 할 수 있다!
여기서 주목할 점은 VPC와 인터넷 간의 통신을 가능하게 하는 VPC구성 요소라는 점이다.
위에서 서브넷 관련해서 말을 했는데, subnet을 논리적으로 public한지 private 한지 구분할 수 있다.
다음은 Gemini에게 이에 대해 물어본 것이다.
필자:
private subnet, public subnet이거 설정은 없고 그냥 우리가 알아서 나누는거야? aws에서?
Gemini:
AWS 콘솔에서 서브넷을 생성할 때 "이 서브넷을 퍼블릭으로 할까요, 프라이빗으로 할까요?"라고 묻는 명시적인 체크박스나 토글 버튼은 **존재하지 않습니다.**
퍼블릭 서브넷과 프라이빗 서브넷은 AWS가 지정해 주는 고정된 타입이 아니라, **사용자가 '라우팅 테이블(Routing Table)'을 어떻게 구성하느냐에 따라 결정되는 네트워크 통신 구조의 결과물**입니다.
그 역할을 나누는 단 하나의 결정적인 기준은 '인터넷 게이트웨이(Internet Gateway, IGW)로 향하는 길이 뚫려 있는가'입니다. 작동 구조의 핵심 원리를 상세히 설명해 드립니다.
1. 퍼블릭과 프라이빗을 가르는 핵심
라우팅 테이블 VPC를 생성하고 논리적인 격리 공간인 서브넷을 만들면, 각 서브넷은 반드시 하나의 라우팅 테이블과 연결되어야 합니다. 라우팅 테이블은 해당 서브넷 안에서 발생하는 네트워크 패킷이 "어디로 가야 하는지" 알려주는 이정표 역할을 합니다.
퍼블릭 서브넷(Public Subnet)이 되는 조건
서브넷에 연결된 라우팅 테이블 규칙에 `0.0.0.0/0` (내부망을 제외한 모든 외부 인터넷 트래픽)의 목적지가 **인터넷 게이트웨이(IGW)**로 설정되어 있으면, 그 서브넷은 퍼블릭 서브넷으로 작동합니다. 외부 인터넷과 직접 통신할 수 있는 라우팅 경로가 열린 것입니다.
프라이빗 서브넷(Private Subnet)이 되는 조건
서브넷에 연결된 라우팅 테이블에 IGW로 향하는 경로가 없으면, 그 서브넷은 프라이빗 서브넷이 됩니다. 외부 인터넷에서 이 서브넷으로 들어올 수도 없고, 내부에서 밖으로 직접 나갈 수도 없는 완벽한 격리망이 구성됩니다.
(내부 인스턴스가 패키지 업데이트 등을 위해 외부로 나가야 할 때는 IGW 대신 내부망의 NAT Gateway를 거치도록 트래픽을 우회시킵니다.)
2. 아키텍처 설계 관점에서의 적용
결국 개발자가 시스템 아키텍처 원칙에 따라 "이 서브넷은 외부 통신이 필요하니 라우팅 테이블에 IGW를 연결해서 퍼블릭으로 쓰자", "이 서브넷은 DB가 들어갈 곳이니 IGW 연결을 끊어서 프라이빗으로 격리하자"라고 능동적으로 설계하는 것입니다. 대규모 트래픽을 처리해야 하는 숙박 관리 시스템(PMS)이나 결제 모듈과 같이 고가용성 및 보안이 중요한 아키텍처에 이를 적용하면 다음과 같은 구조로 나뉩니다.
Public Subnet 영역 배치
외부 사용자의 요청을 가장 먼저 받아 트래픽을 분산하는 ALB(Application Load Balancer)나, 외부망에서 프라이빗 망으로 안전하게 접근하기 위한 Bastion Host 등을 배치합니다. 라우팅 테이블을 통해 IGW와 연결하여 인터넷 클라이언트의 요청을 수용합니다.
Private Subnet 영역 배치
실제 핵심 비즈니스 로직을 처리하는 Spring Boot 기반의 WAS(EC2)나, 영속성 데이터가 저장되는 JPA 기반의 관계형 데이터베이스, 그리고 고속 캐싱을 담당하는 Redis 등을 배치합니다. 라우팅 테이블에 IGW를 연결하지 않아 외부망으로부터의 직접적인 접근을 원천 차단하고, 오직 Public Subnet에 위치한 ALB나 Bastion Host를 통해서만 내부 트래픽 유입을 허용합니다.
결론적으로 퍼블릭 서브넷과 프라이빗 서브넷은 AWS 시스템 상의 단순한 설정값이 아니라, 라우팅 테이블이라는 네트워크 제어 장치를 통해 직접 구성해 내는 논리적인 분리망을 지칭하는 용어입니다.
Internet Gateway를 사용하기 위해서는 VPC안에 붙여야만 하고, routing을 설정해야만 한다.
routing은 뭐야? 전체 그림을 보면 router가 그려져 있는 것을 볼 수있다.
다음 링크를 첨부하는데, AWS 에서 routing에 대해 아주 잘 설명해주고 있다.(라우팅이란 무엇입니까? - AWS)
여러 설명이 있지만, 한 줄로 설명하면 라우팅은 네트워크에서 경로를 선택하는 프로세스를 말한다.
2.2)에서 route는 길, router를 길을 찾아주는 놈이라고 하면 routing은 경로를 선택해주는 과정을 말한다.
또 중요한 점은 인터넷 게이트웨이는 인스턴스를 대신하여 논리적으로 1:1 NAT를 제공한다.
NAT는 Network Address Translation 의 약자로 해석하면 네트워크 주소 변환! 이다.
즉, Internet Gateway는 VPC와 인터넷 간의 통신을 가능하게 하는 수평 확장, 이중화 및 고가용성을 갖춘 VPC 구성 요소이며 1:1 NAT를 제공한다.
이를 좀 더 Gemini에게 설명해달라고 하니 다음과 같이 설명했다.
EC2 인스턴스는 자기 자신에게 공인 IP가 있다는 사실조차 모르며, 인터넷 게이트웨이(IGW)가 중간에서 완벽하게 주소를 치환(신분 세탁)해 준다
그런데 NAT는 왜 필요할까? 이에 대해서는 Gemini에게 질문을 했다. 다음 글을 궁금하면 읽어보자!
NAT(Network Address Translation, 네트워크 주소 변환)가 통신 아키텍처에서 근본적으로 필요한 이유는 크게 **'물리적 한계 극복'**과 '구조적 보안' 두 가지로 압축할 수 있습니다.
단순히 주소를 바꾸는 기능을 넘어, 현대 인터넷 인프라가 유지될 수 있게 만드는 핵심 원리입니다.
1. IPv4 주소 고갈 문제 해결 (가장 결정적인 이유)
초기 인터넷 설계자들은 32비트 체계인 IPv4를 만들 때, 약 43억 개($2^{32}$)의 IP 주소면 전 세계 기기를 덮고도 남을 것이라고 생각했습니다. 하지만 PC, 스마트폰, IoT 기기 등이 폭발적으로 증가하면서 공인 IP(Public IP) 주소는 빠르게 고갈되었습니다.
이 물리적 한계를 극복하기 위해 등장한 구조가 바로 사설 IP(Private IP)와 NAT의 조합입니다.
- 원리: 회사나 가정 내부에 거대한 사설 네트워크(예: 10.0.0.0/8, 192.168.0.0/16 대역)를 구축하여 내부 기기들에게 마음껏 사설 IP를 할당합니다. 이 기기들이 외부 인터넷으로 나갈 때만 라우터(NAT 장비)가 이 수많은 사설 IP들을 단 1개(혹은 소수)의 공인 IP로 변환(N:1 NAT 또는 PAT)하여 내보냅니다.
- 효과: 내부망에 1만 대의 서버가 있더라도, 외부 통신을 위해 필요한 공인 IP는 이론상 1개면 충분해집니다. NAT 덕분에 IPv4 주소 체계가 지금까지도 붕괴하지 않고 버틸 수 있는 것입니다.
2. 구조적 보안 및 내부망 은닉 (보안 방어벽 역할)
NAT는 태생적으로 의도하지 않았던 강력한 보안 이점을 제공합니다.
- 원리: 사설 IP 주소 대역은 글로벌 인터넷 라우터에서 아예 '라우팅 불가(Non-routable)' 주소로 규정되어 폐기됩니다. 외부 해커가 내부망의 특정 서버(예: 10.0.2.50)를 공격하고 싶어도, 그 주소로는 애초에 길(Route)을 찾을 수 없습니다.
- 효과: 해커의 눈에는 오직 겉포장지인 NAT 장비의 공인 IP만 보입니다. NAT가 마치 '매직미러(One-way mirror)'처럼 작동하여 내부에서 밖으로 나가는 트래픽은 허용하되, 외부에서 내부 특정 기기로 직접 치고 들어오는 트래픽은 원천적으로 차단하는 강력한 1차 방어벽 역할을 합니다.
3. 클라우드 아키텍처 (AWS) 관점에서의 NAT 적용
여태까지 정리하신 내용에 이 NAT의 원리를 대입하면, AWS VPC 구조에서 왜 NAT Gateway라는 장비가 별도로 필요한지 정확히 이해할 수 있습니다.
앞서 Private Subnet에 메인 DB와 WAS를 안전하게 격리했다고 가정했습니다. 그런데 이 서버들이 OS 보안 패치를 다운로드하거나 외부 결제 API를 호출하기 위해 인터넷으로 나가야(Outbound) 한다면 어떻게 해야 할까요?
- Private Subnet의 서버에는 외부와 통신할 공인 IP가 없습니다.
- 그렇다고 이 서버들에 공인 IP를 주고 IGW를 연결하면 외부에서 접근 가능해지므로 격리한 의미가 사라집니다.
이때 NAT Gateway를 Public Subnet에 배치합니다. Private Subnet의 서버들은 외부로 나갈 트래픽을 이 NAT Gateway로 보냅니다. NAT Gateway는 내부망의 수많은 프라이빗 IP 요청들을 자신의 공인 IP 1개로 변환(N:1 NAT)하여 인터넷으로 내보내고, 응답을 받아 다시 해당 내부 서버로 돌려줍니다.
결과적으로 NAT의 원리 덕분에 **"내부 서버는 철저히 숨긴 채로, 내부 서버가 원할 때만 외부 인터넷망과 통신하는 안전한 구조"**를 설계할 수 있게 됩니다.
오호... 그렇구나...
이제 Transit Gateway에 대한 설명을 읽어보자.
트랜짓 게이트웨이를 사용하면 가상 프라이빗 클라우드(VPC)와 온프레미스 네트워크를 연결할 수 있습니다.
트랜짓 게이트웨이는 중앙 허브 역할을 하여 VPC, VPN 연결 및 Direct Connect 연결 간의 트래픽을 라우팅합니다. 트랜짓 게이트웨이 사용의 주요 이점 중 하나는 VPC와 온프레미스 네트워크 간의 연결 관리를 중앙 집중화하고 간소화할 수 있다는 것입니다.
여러 개의 VPN 연결이나 Direct Connect 링크를 구성하는 대신, 트랜짓 게이트웨이를 단일 통합 지점으로 활용하여 네트워크 아키텍처의 전반적인 복잡성과 운영 오버헤드를 줄일 수 있습니다.
트랜짓 게이트웨이 사용 요금은 게이트웨이를 통해 전송되는 데이터 용량을 기준으로 합니다. 트랜짓 게이트웨이를 통해 송수신되는 데이터에 대한 GB당 요금과 트랜짓 게이트웨이 리소스 자체에 대한 시간당 요금이 별도로 부과됩니다. 구체적인 요금은 AWS 리전별로 다를 수 있으며 변경될 수 있으므로 최신 정보를 확인하려면 AWS 트랜짓 게이트웨이 요금 페이지를 참조하는 것이 중요합니다.
트랜짓 게이트웨이의 요금 모델을 이해하면 이 AWS 네트워킹 서비스와 관련된 지속적인 비용을 보다 효과적으로 계획하고 예산을 책정할 수 있습니다. 이러한 특징과 운영 효율성 및 연결성 이점을 고려할 때, 트랜짓 게이트웨이는 확장 가능하고 비용 효율적인 하이브리드 클라우드 솔루션을 구축하려는 조직에게 매력적인 선택지가 됩니다.
정리하자. Transit Gateway는 중앙 허브 역할을 하는 하는 Gateway로 VPC, VPN연결 및 Direct Connect 연결간 트래픽 라우팅을 통해서 네트워크 아키텍처의 전반적인 복잡성과 운영 오버헤드를 줄일 수 있다.
다음은 VPN과 DX(Direct Connect)에 대해 정리해 보았다.
| 구분 | Site-to-Site VPN | Direct Connect (DX) |
| 통신 매체 | 퍼블릭 인터넷 (공용망) | 물리적 전용선 (사설망) |
| 성능 및 지연시간 | 인터넷 상태에 따라 변동 가능 | 항상 일관되고 빠름 (보장됨) |
| 보안 방식 | IPsec 암호화 필수 | 물리적 격리 (필요시 암호화 추가 가능) |
| 구축 시간 / 비용 | 몇 분 / 저렴함 | 수 주 ~ 수개월 / 매우 비쌈 |
여기서 그런데 VPC Peering이랑 Site-to-Site VPN이 헷갈렸다. 솔직히 처음에는 같은건줄 알았는데 다르다!
| 구분 | VPC Peering | Site-to-Site VPN |
| 연결 대상 | AWS VPC <-> AWS VPC | AWS VPC <-> 온프레미스(외부 망) |
| 사용 네트워크 망 | AWS 프라이빗 백본 망 | 퍼블릭 인터넷 망(IPSec 터널링) |
| 암호화 여부 | 불필요 (인터넷 노출 없음) | 필수 (IPSec 암호화) |
| 주요 사용 목적 | 마이크로서비스 간 분리된 VPC 통신, DB 계정 분리 | 기존 사내 시스템(Lagacy)과 클라우드(AWS)간의 하이브리드 인프라 구축 |
| 대역폭 및 지연 | 매우 넓고 안정적 (인스턴스 스펙에 의존) | 제한적 (터널당 1.25 Gpbs), 인터넷 상태에 영향받음 |
- IPSec (VPN): 험난하고 위험한 국도(인터넷)를 지나가야 하니, 차량 자체를 무적 장갑차(암호화)로 개조해서 달리는 '논리적 보호' 기술.
- 프라이빗 백본망 (VPC Peering): 차량을 굳이 개조할 필요 없이, 처음부터 우리 회사 소유의 출입 통제된 지하 전용 고속도로를 뚫어서 달리는 '물리적 보호' 기술입니다.
2.4) 라우트 테이블(Route table)
다른 이야기이긴 한데, 라우트 테이블이라고 적고 왜 자꾸 라우팅 테이블(routing table) 을 적어놓은 글이 많은데, 도통 이해가 되질 않는다. 하여간...
라우트 테이블은 라우터 또는 장치에 저장된 데이터 구조로, 데이터 패킷이 올바른 목적지로 이동하도록 도와준다.
OSI 모델의 3계층(네트워크 계층)에서 작동하며 인터넷 프로토콜(IP)과 같은 주요 네트워킹 프로토콜과 함께 동작한다.
(참고 글 : what is a routing table)
3. NACL, VPC Endpoint & VPC Peering, VPN Gateway, Customer Gateway, NAT Gateway
3.1) NACL(Network Access Control List)
그림을 보면 VPC안에 Public Subnet과 Private Subnet으로 나뉘어 있다.
그 상단에 NACL이 있는데, NACL은 Network Access Control List의 약자로 subnet 레벨에서 특정 인바운드와 아웃바운드 트래픽을 허락하거나 막는다.
이게 왜 필요한지는 기존의 Security Group과 비교해서 NACL의 특징을 보면 이해가 될 것이다.
Characteristic - Security group VS Network ACL
| 특징 | Security Group | Network ACL |
| 규칙 타입 | 허용 규칙만 존재 | 허용 및 거부 규칙 모두 존재 |
| 규칙 평가 | 트래픽 허용 여부를 결정하기 전 모든 규칙을 평가함 | 트래픽과 일치하는 규칙을 찾을 때까지 오름차순으로 규칙을 평가함 |
| 반환 트래픽 | 자동으로 허용됨 - 상태 저장 | 명시적으로 허용해야 함 - 상태 비저장 |
| 동작 계 | 인스턴스 수준 | 서브넷 수준 |
| 범위 | 보안 그룹과 연결된 모든 인스턴스에 적용 | 연결된 서브넷 내의 모든 인스턴스에 적용 |
Security Group 에서만 보안 처리를 하기보다 subnet에서 보안을 적용하면 좀 더 안정적이고 신뢰할 수 있는 제품을 제공할 수 있다.
subnet 각각의 NACL을 통해서 인바운드와 아웃바운드를 통제해서 보안을 강력하게 할 수 있다.
3.2) VPC Endpoint & VPC Peering
현재 VPC에 대해 공부하고 있다. 여러 구성과 설정들이 뭐가 있는지 보고 잇는데 VPC Endpoint는 뭐야?
(Access an AWS Service using an interface VPC Endpoint)
AWS PrivateLink를 통해 제공되는 다양한 AWS 서비스를 연결하기 위한 VPC 엔드포인트 인터페이스를 생성할 수 있다.
'AWS PrivateLink'라는 기술 규격을 사용하여, 내 VPC 안에 실제로 생성한 접속점(Point of Presence)이 바로 'VPC Endpoint' 이다.
| 구분 | AWS PrivateLink | VPC Endpoint (Interface) |
| 성격 | 네트워크 전송 기술/규격 (How) | 내 VPC에 띄우는 실제 리소스 (What) |
| 역할 | 인터넷을 거치지 않는 보안 통로 제공 | 서비스로 접속하기 위한 사설 IP 입구 |
| 관계 | 기반 기술 | PrivateLink를 활용한 접속 지점 |
여기서 VPC Endpoint는 Interface Endpoint와 Gateway Endpoints로 나뉘어 있는데, 앞 부분에서 다음과 같이 gemini가 답변을 주었다.
- 게이트웨이 엔드포인트 (Gateway Endpoint): 라우팅 테이블의 경로를 조작하여, 트래픽이 인터넷을 거치지 않고 AWS 내부의 프라이빗 백본망을 통해 S3나 DynamoDB와 직접 통신하도록 연결합니다.
- 인터페이스 엔드포인트 (Interface Endpoint / AWS PrivateLink): 프라이빗 서브넷 내부에 사설 IP를 가진 가상의 네트워크 인터페이스(ENI)를 생성합니다. 이를 통해 SQS, SNS 등 외부 API 서비스를 마치 VPC 내부에 존재하는 로컬 자원인 것처럼 안전하게 호출할 수 있습니다.
VPC Peering(피어링)은 서로 다른 두 개의 VPC를 네트워크적으로 연결하여, 마치 하나의 동일한 네트워크에 있는 것처럼 사설 IP(Private IP)를 통해 서로 직접 통신할 수 있게 해주는 기술이다.
3.3 VPN Gateway 그리고 Customer Gateway
VPN Gateway를 AWS에서는 Virtual Private Gateway로 만들어냈다. 도대체 왜;; 뭘 VPN Gateway라고 하는거야?
이에 대해 필자는 이해를 못해서 Gemini에게 물어보았다. 답변이 궁금하면 열어서 읽어보자.
키메라 :
VPN Gateway랑 VPG랑 같은거라고? 어딜봐서? 이름자체가 다른데?
Gemini:
이름이 완전히 다르기 때문에 의문을 가지시는 것이 당연하고, 아주 날카로운 지적입니다.
결론부터 명확히 바로잡아 드리겠습니다. **'VPN Gateway'는 네트워크 업계에서 통용되는 일반 명사**이고, **'Virtual Private Gateway'는 AWS가 그 기능을 구현하여 제공하는 독자적인 고유 명사(리소스 이름)**이기 때문에 이름이 다릅니다.
이 두 가지가 아키텍처상 어떻게 같은 대상을 가리키게 되는지 세 가지 관점에서 뜯어보겠습니다.
### 1. 기능적 역할 (일반 명사 vs 고유 명사)
* **VPN Gateway (업계 표준 용어):** 시스코(Cisco), 주니퍼(Juniper) 같은 네트워크 장비나 타 클라우드(Azure, GCP 등)를 막론하고, 외부와 IPsec 암호화 터널을 맺어주는 문지기 장비를 통칭하는 범용적인 단어입니다.
* **Virtual Private Gateway (AWS 고유 명사):** AWS 인프라 환경에서 바로 그 'VPN 터널의 문지기' 역할을 수행하기 위해 VPC에 부착하는 리소스의 공식 명칭입니다.
즉, 회사의 인프라 회의에서 "우리 VPC 쪽에 VPN Gateway 하나 뚫읍시다"라고 결정이 나면, AWS 콘솔 화면에 접속해서 실제로 클릭하고 생성해야 하는 리소스 이름이 **Virtual Private Gateway**인 것입니다.
### 2. 약어의 정확한 규정: VPG가 아니라 VGW
질문하신 부분에서 또 하나 짚고 넘어가야 할 점이 약어입니다.
Virtual Private Gateway의 앞 글자만 따서 직관적으로 **VPG**라고 부르는 실무자들도 가끔 있지만, **AWS가 규정한 공식 아키텍처 약어는 VGW입니다.**
* Internet Gateway -> **IGW**
* Transit Gateway -> **TGW**
* Virtual Private Gateway -> **VGW**
### 3. 공식 문서의 정의 (어딜 봐서 같은가?)
AWS가 이 리소스를 어떻게 정의하고 있는지 공식 문서의 핵심 문장을 보면 의문이 완전히 해소됩니다.
* **AWS 문서 원문:** "Virtual private gateway – The VPN concentrator on the Amazon side of the Site-to-Site VPN connection."
* **해석:** "가상 프라이빗 게이트웨이(Virtual Private Gateway)는 Site-to-Site VPN 연결을 맺을 때 아마존(AWS) 측에 위치하는 VPN 집중기(VPN을 맺어주는 장비)입니다."
AWS 콘솔 화면을 열어 VPC 대시보드를 보셔도 직관적으로 알 수 있습니다. 왼쪽 메뉴 하단에 **[Virtual Private Network (VPN)]**이라는 큰 카테고리가 묶여 있고, 그 하위 메뉴로 **[Virtual Private Gateways]**와 **[Customer Gateways]**가 나란히 배치되어 있습니다.
**요약하자면:**
기능과 본질은 완벽하게 똑같지만, 범용적인 IT 기술 용어(VPN Gateway)를 AWS가 자신들의 입맛에 맞게 네이밍(Virtual Private Gateway, VGW)하면서 생긴 차이입니다. "이름이 다른데 왜 같다고 하느냐"는 의심은 클라우드 벤더 종속적인 용어와 범용 네트워크 지식을 분리해 내기 위해 엔지니어가 반드시 가져야 할 아주 건강한 시각입니다.
3.4 클라우드 아키텍처 (AWS) 관점에서의 NAT 적용 - NAT Gateway
NAT Gateway에 대해서 위에 접은 글에 있는걸 가져왔다.
여태까지 정리하신 내용에 이 NAT의 원리를 대입하면, AWS VPC 구조에서 왜 NAT Gateway라는 장비가 별도로 필요한지 정확히 이해할 수 있습니다.
앞서 Private Subnet에 메인 DB와 WAS를 안전하게 격리했다고 가정했습니다. 그런데 이 서버들이 OS 보안 패치를 다운로드하거나 외부 결제 API를 호출하기 위해 인터넷으로 나가야(Outbound) 한다면 어떻게 해야 할까요?
Private Subnet의 서버에는 외부와 통신할 공인 IP가 없습니다.
그렇다고 이 서버들에 공인 IP를 주고 IGW를 연결하면 외부에서 접근 가능해지므로 격리한 의미가 사라집니다.
이때 NAT Gateway를 Public Subnet에 배치합니다. Private Subnet의 서버들은 외부로 나갈 트래픽을 이 NAT Gateway로 보냅니다. NAT Gateway는 내부망의 수많은 프라이빗 IP 요청들을 자신의 공인 IP 1개로 변환(N:1 NAT)하여 인터넷으로 내보내고, 응답을 받아 다시 해당 내부 서버로 돌려줍니다.
결과적으로 NAT의 원리 덕분에 **"내부 서버는 철저히 숨긴 채로, 내부 서버가 원할 때만 외부 인터넷망과 통신하는 안전한 구조"**를 설계할 수 있게 됩니다.
Customer Gateway 는 온프레미스 네트워크의 고객 게이트웨이 디바이스를 나타내는 AWS 에서 생성하는 리소스다.
필자의 친구는 IT 관력 학과를 졸업해서 대학교 시절부터 인턴을 통해 웹 개발자로 진로를 틀었고 최근에는 외국에서 개발자 일을 하고 있다. 친구가 말하기로는 공부를 웬만하면 다 해서 재미가 없다고 한다. 물론 그 친구는 이 일을 한지 이제 6년이 넘었다.
햇수로만 따지면 필자도 만 4년이 넘어버렸는데 공부할 것이 적다는 생각은 잘 들지 않았다.
오히려 나의 무지에 대해 끊임없이 알게 되었고, 자꾸 무언가를 더 해야 한다는 생각만 든다.
VPC도 막상 해보니 별것이 아니다. 다만 나의 언어로 정리해서 이해를 하고 있는가는 큰 차이라 생각이 들기에 이 글을 적었다.
다만 여러분들은 공부하다가 깜빡하고 EC2내리는것을 잊지 마시라!
주말동안 깜빡하고 공부하다가 ec2 안내렷다고 이번달에 16달러 내란다... 진짜 양아치다 양아치...
그리고 몇일 지나니 다시 27달러가 되어 이는 것이다 (진짜 ... 이게 무슨일이야 ㅠㅠ....)
찾아보니 NAT Gateway를 지우지 않아서... 그렇다는데 아니 이딴것도 돈받냐 진짜? ;;;
출처:
Ultimate AWS Certified Solutions Architect Associate 2026
https://jumpcloud.com/it-index/what-is-a-routing-table
Access an AWS Service using an interface VPC Endpoint
Internal Gateway 랑 Transit Gateway