AWS VPC 엔드포인트 — Gateway vs Interface 동작 원리
*한마디
단순히 엔드포인트가 인터넷을 경유하지않고 다른서비스에 접근한다 로 끝나는게아닌 패킷의 이동경로와 그과정에서의 매커니즘을 상세하게 학습하기위한 과정에서 ai와 질문을 주고받은 내용들을 문서화 하여 ai를 통해 다시 정리한 내용입니다.
1. VPC 엔드포인트란?
VPC 엔드포인트는 인터넷 게이트웨이(IGW), NAT 게이트웨이, VPN 연결 등을 거치지 않고 AWS 내부 백본망을 통해 VPC와 지원 대상 AWS 서비스를 직접 연결해주는 기능입니다. 트래픽이 퍼블릭 인터넷을 한 번도 타지 않는다는 점이 핵심입니다.
VPC 엔드포인트는 크게 두 가지 타입으로 나뉩니다.
| 구분 | Gateway 타입 | Interface 타입 |
|---|---|---|
| 지원 서비스 | S3, DynamoDB | 대부분의 AWS 서비스 |
| 구현 방식 | 라우팅 테이블 | ENI(사설 IP) + PrivateLink |
| 동작 계층 | L3 | L4 ~ L7 |
| 보안 그룹 | 미지원 (엔드포인트 정책으로 제어) | 지원 |
| 온프레미스 연계 (DX/VPN) | 불가능 | 가능 |
| 비용 | 무료 | 시간당 요금 발생 |
2. Gateway 엔드포인트, 어떻게 동작하는가
Gateway 엔드포인트는 네트워크의 가상 스위치/라우터 레벨에서 패킷의 경로를 가로채는 방식으로 동작합니다. 순서로 보면 이렇습니다.
- Prefix List 생성 — 엔드포인트를 생성하면 AWS가 관리하는 S3/DynamoDB의 퍼블릭 IP 대역 목록이 정의됩니다.
- 라우트 테이블 수정 — 지정한 서브넷의 라우트 테이블에, 대상이 해당 엔드포인트 ID로 지정된 라우팅 규칙이 추가됩니다.
- 패킷 전달 — EC2 인스턴스가
s3.ap-northeast-2.amazonaws.com을 조회하면 여전히 퍼블릭 IP를 반환받습니다. 하지만 EC2가 그 퍼블릭 IP로 SYN 패킷을 보내는 순간, VPC 라우터는 라우트 테이블의 Prefix List 규칙을 확인하고 인터넷 게이트웨이 대신 엔드포인트(vpce-xxxx)를 통해 AWS 내부 전용 백본 네트워크로 패킷을 캡슐화해 전달합니다.
2-1. Prefix List란 정확히 무엇이고, 왜 필요한가?
Prefix List는 하나 이상의 CIDR 블록을 하나로 묶어놓은 그룹 세트입니다.
VPC 라우팅 테이블이나 보안 그룹 규칙을 설정할 때 보통 10.0.0.0/16 같은 IP 대역을 하나씩 입력합니다. 하지만 S3나 DynamoDB 같은 서비스는 단일 IP 대역이 아니라 수십 개가 넘는 퍼블릭 CIDR 블록을 사용합니다. 이 방대한 IP 목록을 라우팅 테이블에 일일이 적는 대신, pl-xxxxxx (com.amazonaws.ap-northeast-2.s3) 형태의 고유 ID 하나로 묶어둔 것이 바로 AWS 관리형 Prefix List입니다.
Prefix List를 사용하는 이유는 크게 세 가지입니다.
- 서비스의 방대한 퍼블릭 IP 대역을 한 번에 라우팅하기 위함
Gateway 엔드포인트는 EC2 내부에 사설 IP를 발급하는 방식이 아닙니다. EC2는 S3에 접속할 때도 여전히 DNS를 통해 S3의 퍼블릭 IP를 조회합니다. 이때 라우팅 테이블에 Prefix List가 없다면 해당 패킷은 기본 경로인 IGW나 NAT 게이트웨이로 빠져나갑니다. Prefix List가 라우팅 테이블에 등록되어 있으면, 라우터는 가장 구체적인 경로에 따라 인터넷 경로 대신 Gateway 엔드포인트를 선택해 AWS 내부 백본망으로 패킷을 전환합니다. - 수시로 바뀌는 AWS 서비스 IP를 자동으로 동기화하기 위함
AWS는 용량 확장, 장애 조치, 인프라 점검 등의 이유로 S3나 DynamoDB가 사용하는 퍼블릭 IP 대역을 수시로 추가하거나 변경합니다. Prefix List를 쓰면 이 변경 사항이 자동으로 반영됩니다. - 라우트 테이블 크기 한도를 보호하기 위함
라우트 테이블은 포워딩 속도를 유지하기 위해 등록 가능한 경로 수에 제한(기본 50개, 최대 100개)이 있습니다. 수십 개의 CIDR을 하나로 묶어두면 이 한도를 아낄 수 있습니다.
2-2. 패킷은 실제로 어떤 경로로 흐르는가
인스턴스가 퍼블릭 IP를 반환받아도 S3와의 통신 경로 자체는 IGW가 아니라 엔드포인트로 흐릅니다. 네트워크 관점에서 두 단계로 쪼개보면 다음과 같습니다.
- DNS 조회 단계 (퍼블릭 IP 획득)
EC2 내부의 애플리케이션이나 AWS CLI가s3.ap-northeast-2.amazonaws.com으로 요청을 보내기 위해 DNS 조회를 수행하면, 반환되는 IP는 여전히 S3의 퍼블릭 IP입니다. Gateway 엔드포인트는 Interface 엔드포인트와 달리 VPC 내부에 사설 IP를 만들지 않으므로, DNS 레코드 자체가 사설 IP로 바뀌지는 않습니다. - 패킷 전송 및 라우팅 단계 (경로 가로채기)
EC2는 방금 받은 퍼블릭 IP를 목적지로 설정해 TCP SYN 패킷을 서브넷 기본 게이트웨이로 보냅니다. 라우터는 라우팅 테이블을 검사해 가장 구체적인 CIDR 블록(Prefix List)이 걸린 규칙에 따라 패킷을 엔드포인트 쪽으로 보냅니다.
즉, DNS 응답은 그대로 퍼블릭 IP지만, 실제 전송 경로만 라우팅 테이블 수준에서 바뀌는 것입니다.
2-3. 왜 굳이 사설 IP(ENI)를 따로 만들지 않을까?
단순히 절차를 줄이려는 편의성 때문만은 아닙니다. 기술적인 한계와 네트워크 아키텍처상의 트레이드오프(대역폭 병목, 비용, 개발 역사) 때문입니다.
- 역사적 배경: Gateway 엔드포인트는 PrivateLink 기술이 존재하기 이전에 나온 구현 방식입니다.
- S3/DynamoDB의 특성 — 초고대역폭과 ENI 병목 문제: S3는 수 기가바이트 단위의 대용량 전송이나 테라바이트급 백업·빅데이터 처리가 빈번합니다.
- 사설 IP(ENI)를 쓸 경우: 서브넷 안에 가상 네트워크 카드(ENI)를 배치한다는 뜻이 되고, ENI는 물리적으로 네트워크 인터페이스이므로 대역폭 한계가 존재하며 추가적인 처리 지연이 발생할 수 있습니다.
- Gateway 엔드포인트 방식: ENI 같은 중간 매개체를 두지 않고, VPC의 가상 분산 라우터 소프트웨어 계층에서 곧바로 AWS 백본으로 패킷을 흘려보냅니다. 중간 프록시나 특정 ENI를 거치지 않으므로 대역폭 제한이 사실상 없고 처리 병목이 발생하지 않습니다.
2-4. 그래도 어딘가엔 ENI가 있는 거 아닌가? (병목 오해 풀기)
네트워크 통신이 가능하려면 결국 앞단이든 뒷단이든 ENI가 부착되어 있어야 하는 것 아닐까 하는 의문이 들 수 있습니다. 결론부터 말하면, S3 앞단이나 라우팅 경로 중간에는 우리가 흔히 생각하는 형태의 단일 ENI가 존재하지 않으며, 거대한 분산 패킷 프로세서(소프트웨어 정의 네트워크, SDN)가 트래픽을 처리하기 때문에 병목이 생기지 않습니다.
- 출발지 측: EC2의 ENI는 당연히 거칩니다. EC2 인스턴스 타입 자체에 걸려있는 기본 네트워크 대역폭은 여전히 적용됩니다. Gateway 엔드포인트가 해결하는 병목은 EC2 자체의 한계가 아니라 그 뒤 네트워크 경로에서 생기는 추가 병목입니다.
- 중간 경로 — Interface 방식과의 결정적 차이
- Interface 엔드포인트: 사용자의 서브넷 내부에 전용 VPC 엔드포인트 ENI를 하나 생성하고, 이 ENI가 사설 IP를 물고 배치되는 일종의 통신 중계 관문(프록시) 역할을 합니다. 모든 트래픽이 이 단일 ENI를 통과해야 하므로, 테라바이트급 데이터를 쏟아부을 때 트래픽 집중·추가 지연·기가바이트당 데이터 처리 비용이 발생할 수 있습니다.
- Gateway 엔드포인트: 서브넷 안에 아무런 가상 인터페이스(ENI)도 만들지 않습니다. 패킷이 EC2의 ENI를 빠져나오자마자 만나는 것은 특정 기기나 인터페이스가 아니라, AWS 하이퍼바이저와 물리 서버(Nitro 카드) 수준에서 동작하는 VPC 가상 분산 라우터(SDN) 계층입니다.
- 목적지 측: S3는 서버나 ENI 기반 서비스가 아닙니다. S3의 퍼블릭 IP 대역 뒤에는 단일 인터페이스가 아니라, 애니캐스트 및 분산 로드밸런싱 구조를 갖춘 수천~수만 대의 분산 웹 서버 플릿이 대기하고 있습니다.
이 모든 것이 가능한 근본적인 이유는 결국 AWS가 물리적으로 연결된 자체 네트워크망(백본망)을 보유하고 있기 때문입니다. 그리고 이것이 Gateway 엔드포인트 비용이 0원인 이유이기도 합니다. 공용 인터넷 망을 1비트도 타지 않고 자체 인프라 안에서만 패킷이 돌기 때문에, 외부 망 사용료가 나가지 않아 무료로 제공할 수 있는 것입니다.
3. Interface 엔드포인트, 어떻게 동작하는가
Interface 엔드포인트는 AWS PrivateLink 기술을 기반으로 동작하며, VPC 내부에 직접 사설 IP를 발급받는 방식입니다.
- ENI 생성 — 선택한 서브넷마다 전용 VPC 엔드포인트 ENI가 생성되고, 서브넷 대역 내의 사설 IP가 할당됩니다.
- 프라이빗 DNS 확인 — 기본 설정 시 AWS 관리형 Route 53 프라이빗 호스팅 영역이 백그라운드에 생성됩니다. 표준 서비스 도메인을 쿼리하면 퍼블릭 IP가 아닌 엔드포인트 ENI의 사설 IP가 반환됩니다. 따라서 기존 애플리케이션의 SDK 설정이나 엔드포인트 URL을 변경할 필요가 없습니다.
- 네트워크 가상화 및 연결 — ENI로 들어온 패킷은 AWS의 대규모 분산 네트워크 가상화 계층인 Hyperplane을 통해 서비스 공급자 측 계정 인프라로 안전하게 프록시 전달됩니다. 이때 VPC 간 IP가 중복되더라도 PrivateLink 수준에서 NAT 처리가 이루어지므로 충돌 없이 통신할 수 있습니다.
3-1. Gateway가 이렇게 좋은데, 왜 굳이 ENI를 쓰는 Interface 방식이 필요한가?
Gateway 방식은 VPC 내부라는 좁은 울타리를 벗어나는 순간 기술적으로 한계에 부딪힙니다.
- 온프레미스 연동 한계 — 라우팅 전파가 불가능하다
Gateway 엔드포인트는 해당 VPC의 가상 라우터 안에서만 유효합니다. 이 라우팅 규칙은 Direct Connect, VPN, Transit Gateway 너머로 전파되지 않습니다. 반면 Interface 방식은 VPC 서브넷 안에 실제 사설 IP를 가진 ENI가 박히기 때문에, 온프레미스 입장에서는 그냥 VPC 안에 있는 일반 가상 서버로 IP 패킷을 쏘는 것과 동일합니다. 그래서 VPN·DX를 타고 사내 전산망에서도 안전하게 AWS 서비스나 사설 API에 다이렉트로 접속할 수 있습니다. - 보안 그룹 미지원 — 포트/소스 IP 통제가 안 된다
Gateway 방식은 ENI가 없기 때문에 보안 그룹을 적용할 수 없고, 특정 IP를 차단하는 것도 불가능합니다. - 멀티 VPC 및 다른 계정과의 연결
Gateway 방식은 AWS 내부 관리형 서비스(S3, DynamoDB) 전용으로 하드코딩된 구조라 사용자가 만든 서비스에는 쓸 수 없습니다. 반면 Interface 방식은 내가 만든 서비스(NLB 뒷단)를 다른 계정의 VPC 안에 사설 ENI 형태로 꽂아줄 수 있습니다. 또한 IP 대역이 중복돼도 연결이 가능합니다. 예를 들어 고객사 VPC 대역이10.0.0.0/16이고 우리 회사 VPC 대역도10.0.0.0/16이라 VPC 피어링이 불가능한 상황이더라도, PrivateLink는 ENI를 통한 NAT 터널링 구조이므로 IP 충돌 없이 안전하게 B2B 서비스만 노출할 수 있습니다.
3-2. "내가 만든 서비스"란 정확히 무엇인가? (S3와의 차이)
클라우드에서 "내가 만든 서비스"와 "AWS 관리형 서비스"는 인프라의 소유권과 애플리케이션 코드의 주체가 누구냐에 따라 구분됩니다.
- S3 / DynamoDB / SQS 같은 AWS 관리형 서비스: 콘솔에서 버킷 생성을 눌렀다고 해서 사용자가 만든 서비스가 되는 것은 아닙니다. 코드를 짜고, 서버를 배포하고, 패치하고, 물리 디스크를 관리하는 주체는 100% AWS입니다. 사용자는 저장 공간 한 칸을 임대하는 것뿐입니다.
- 내가 만든 서비스: 사용자가 직접 작성한 백엔드 코드를 EC2나 EKS 컨테이너에 올리고, 그 앞단에 트래픽을 분산하기 위해 NLB를 붙여둔 것을 의미합니다. 이를 AWS PrivateLink를 통해 엔드포인트 서비스로 등록하면, 다른 회사나 다른 VPC에 내 서버 API를 안전하게 사설망 형태로 제공할 수 있습니다.
3-3. 단방향 통신과 IP 대역 중복 해결 원리
같은 IP 대역이면 왜 충돌할까?
동일한 대역(10.0.0.0/16)을 쓰는 두 VPC를 VPC 피어링으로 붙이려 하면, 고객사 라우터는 10.0.1.5로 가는 패킷을 만났을 때 그것이 우리 서브넷인지 고객사 서브넷인지 구분하지 못해 라우팅 테이블 등록 자체가 거부됩니다.
PrivateLink는 왜 충돌하지 않을까? — ENI 할당 주소와 단방향 구조
엔드포인트 ENI는 외부에서 억지로 가져와 꽂는 것이 아니라, 고객사(소비자 측)의 DHCP 서버(VPC IP 관리자)가 고객사 서브넷의 빈 IP를 정식으로 1개 꺼내어 발급해줍니다.
단방향 통신과 주소 변환 메커니즘
PrivateLink는 두 VPC 네트워크를 통째로 잇는 것이 아니라, 한 방향으로만 요청할 수 있는 파이프(프록시)를 뚫는 방식입니다.
- 연결 시작(TCP SYN)은 반드시 엔드포인트를 둔 쪽(소비자)에서 서비스 공급자 쪽으로만 가능합니다.
- 패킷이 Hyperplane(AWS 내부 전송망)을 넘어갈 때, 소스 IP와 목적지 IP가 완전히 캡슐화·변환됩니다.
- 따라서 두 VPC의 CIDR이 똑같이
10.0.0.0/16이어도 서로의 내부 IP 주소를 직접 볼 필요가 없으므로 충돌 없이 통신이 성립합니다.
3-4. 온프레미스·타 VPC 연결 범위는 어디까지인가
Gateway 엔드포인트는 다른 곳에서 건너올 수 없습니다. 통신 범위가 해당 라우팅 테이블을 직접 물고 있는 로컬 서브넷 안으로만 제한되기 때문에, 라우팅 홉을 한 번이라도 건너뛰어야 하는 곳에서는 접근이 불가능합니다.
Interface 엔드포인트는 서브넷에 실제 사설 IP(ENI)를 발급받는 방식이기 때문에, 온프레미스(VPN/DX 경유)든 피어링된 다른 VPC든 다른 계정의 VPC든 일반적인 사설 IP 통신이 가능한 범위라면 어디서든 접근할 수 있습니다. 다만 서비스를 외부에 노출하는 쪽(엔드포인트 서비스 제공자)에서 허용한 소비자만 연결할 수 있고, 통신은 앞서 설명한 것처럼 소비자 → 공급자 방향의 단방향 구조입니다.
4. Gateway vs Interface, 한눈에 비교
최종정리
- VPC 엔드포인트는 IGW/NAT/VPN을 거치지 않고 AWS 내부 백본망으로 VPC와 AWS 서비스를 직접 연결하는 기능이며, Gateway 타입과 Interface 타입 두 가지로 나뉜다.
- Gateway 엔드포인트(S3, DynamoDB 전용)는 ENI를 만들지 않고 라우트 테이블 + Prefix List 조합으로 동작한다. EC2는 여전히 퍼블릭 IP로 DNS를 조회하지만, 라우터가 가장 구체적인 경로(Prefix List)를 보고 트래픽을 AWS 백본으로 전환한다. ENI라는 중간 매개체가 없어 대역폭 병목이 없고, 퍼블릭 인터넷을 전혀 타지 않아 비용이 무료다. 대신 VPC 내부 로컬 라우팅 테이블 범위에서만 동작하므로 온프레미스나 타 VPC에서는 접근할 수 없고, 보안 그룹도 지원하지 않는다.
- Interface 엔드포인트(대부분의 AWS 서비스 및 사용자 정의 서비스)는 AWS PrivateLink 기반으로, 서브넷마다 사설 IP를 가진 ENI를 생성하고 Route 53 프라이빗 호스티드 존으로 DNS를 사설 IP에 매핑한다. 트래픽은 Hyperplane을 통해 단방향(소비자 → 공급자)으로 프록시되며, 이 과정에서 IP가 캡슐화·NAT 처리되기 때문에 양쪽 VPC의 CIDR이 겹쳐도 충돌 없이 통신할 수 있다. ENI 기반이라 보안 그룹 적용이 가능하고, 온프레미스(VPN/DX)나 다른 계정의 VPC에서도 접근할 수 있으며, 내가 만든 서비스(NLB 뒤의 애플리케이션)를 엔드포인트 서비스로 노출할 수도 있다. 대신 시간당 비용이 발생하고, 모든 트래픽이 단일 ENI를 통과하는 구조라 초고대역폭 워크로드에서는 Gateway 방식만큼 자유롭지 않다.
- 결국 선택 기준은 단순하다. S3/DynamoDB를 VPC 내부에서만 저비용·고대역폭으로 쓸 것이라면 Gateway, 온프레미스 연동·보안 그룹 통제·타 VPC/계정 연결·사용자 정의 서비스 노출이 필요하다면 Interface를 선택하면 된다.
