AWS VPC Endpoint란 인터넷 게이트웨이(IGW)나 NAT 게이트웨이 장치 없이, VPC 내부에서 EC2, S3와 같은 AWS 서비스와 비공개적으로 통신할 수 있게 해주는 기능입니다. 예를 들어, 한 VPC 내의 EC2가 인터넷 연결 없이 S3 버킷에 Private Network 액세스가 가능합니다. 따라서 오늘은 VPC 엔드포인트의 종류와 상황에 따른 사용 방법에 대해 적어보려고 합니다.
목차
1. VPC Endpoint 개념 및 특성
2. NAT Gateway vs. Interface VPC Endpoint
3. 비용 최적화
4. 결론
#1 VPC Endpoint (Virtual Private Cloud Endpoint) 개념 및 특성
VPC Endpoint를 사용하는 이유는 무엇일까요? 핵심 이점은 트래픽이 공용 인터넷을 거치지 않고 AWS 네트워크 내부에서만 이동한다는 점과 특정 상황에서 NAT Gateway에서 사용되는 비용을 절감할 수 있다는 점입니다. 먼저 어떤 엔드포인트가 있는지 알아보겠습니다.
1. Gateway VPC Endpoint

Gateway VPC Endpoint란 S3, DynamoDB라는 데이터 클라우드 저장 서비스에 인터넷 없이 접근할 수 있게 해 줍니다. 한 예시로, AWS Glue로 만들어진 가공된 데이터를 AWS 내부 라우터에 보내고, 라우터는 Gateway VPC Endpoint를 거쳐서 S3나 DynamoDB로 보내줍니다. 퍼블릭 인터넷이 아닌 AWS 내부에서 이뤄지는 프로세스이므로 보안성이 매우 뛰어나며, 시간 당 비용과 트래픽 당 비용이 전부 무료이기 때문에, S3나 DynamoDB를 사용하는 경우에는 필수적으로 사용하는 것이 좋습니다.
Gateway VPC Endpoint 주의할 점
Gateway VPC Endpoint는 물리적인 IP 주소(ENI)가 존재하지 않으며 내부적인 소프트웨어 규칙이기 때문에 On-Premise에서는 라우팅이 불가합니다. 즉, On-Premise는 VPN이나 Direct Connect 방식을 써도 Gateway VPC Endpoint에 접근할 수 없습니다. 이 경우에는 ENI가 존재하는 Interface VPC Endpoint를 써서 라우팅을 가능하게 해야 합니다.
2. Interface VPC Endpoint

Interface VPC Endpoint란 EC2, CloudWatch, SNS, SQS 로드밸런서 등 대부분의 AWS의 모든 서비스에 인터넷 없이 접근할 수 있게 해 줍니다. ENI가 존재하여 On-Premise 방식에서도 접근이 가능하며, 퍼블릭 인터넷을 거치지 않고 AWS의 Private Link로 접근하기 때문에 보안성이 우수합니다. 그러나 Gateway VPC Endpoint와는 다르게 시간 당 비용과 데이터 처리 비용이 발생합니다. (엔드포인트 1개당 $0.01/hr, $0.01/GB)
Interface VPC Endpoint 주의할 점
Interface VPC Endpoint는 가용 영역에 종속적이며, 엔드포인트가 생성된 가용 영역에 장애가 발생하면 치명적인 피해가 발생합니다. 이러한 문제를 예방하기 위해 여러 가용 영역에 엔드포인트를 생성하여 가용성을 높여야 하는데, 개수만큼 시간당 요금이 부과되므로 트래픽과 중요도를 고려해서 EC2 인스턴스가 작동 중인 가용 영역에 생성하는 것이 좋습니다.
#2 NAT Gateway vs. Interface VPC Endpoint
NAT Gateway는 Outbound 경로를 열어 외부에 트래픽을 전송할 수 있게 해 주며, SSM, CloudWatch 등 AWS 서비스에도 접근이 가능합니다. Interface VPC Endpoint보다 비용이 훨씬 더 많이 발생하며, NAT Gateway와 Interface VPC Endpoint를 동시에 써서 보안성이나 운영 안정성을 챙기는 것이 가장 이상적인 방법이지만, 소규모 웹 서비스에서 두 가지 방식을 모두 사용할 필요가 없는 경우를 가정하여 두 기능을 비교해 보겠습니다.
1. NAT Gateway만 사용하는 것으로 전환하는 경우
사실 NAT 게이트웨이만을 사용하는 경우는 관리 편의성을 중시할 때 사용됩니다. Interface VPC Endpoint의 경우에는 하나씩 AWS 서비스마다 구성을 해줘야 하는 것에 비해 NAT 장치는 한 개만 설치해도 통신이 가능하며, 프라이빗 서브넷과 쉽게 통신할 수 있습니다. 그러나, 모든 트래픽이 외부망을 경유하기 때문에 보안적으로 취약하며, 비용을 아끼기 위해 단일 가용영역에 생성했을 때 장애가 발생하면 NAT 디바이스에 영향을 끼쳐 모든 기능에 피해가 발생합니다. 예를 들어, 퍼블릭 IP도 없고 SSM 접속이나 AWS API 접근을 NAT 장치로 하게 되는데, 장애가 발생하면 이도저도 못하는 고립 상태가 됩니다. 이 때는 EC2 인스턴스를 종료하고 퍼블릭 IP를 할당하고 SSH 접속으로 해결해야 하는 복잡한 상황이 됩니다. Interface VPC Endpoint에 비해 비용도 크기 때문에 비용 효율성과 장애 격리 측면에서 불리할 수 있습니다.
2. Interface VPC Endpoint만 사용하는 것으로 전환하는 경우
NAT 게이트웨이가 없으면 프라이빗 서브넷에서는 아웃바운드 경로가 열리지 않아 외부에 트래픽을 전송할 수가 없게 됩니다. 즉, 프라이빗 서브넷 내에서는 AWS 내부 서비스들끼리 로컬 통신을 하는 것입니다. OS 패치, 패키지 매니저 호출, API 호출, 외부 데이터 수집하는 등의 일이 없는 경우에 자주 사용이 되고는 합니다. 인터넷 연결을 완전히 차단하고, 오직 허용된 AWS 내부 서비스와만 Private 하게 통신하는 방식이기 때문에 보안성이 우수하고, 데이터 전송 비용이 NAT보다 저렴하다는 장점이 있습니다. 그러나, AWS 서비스 당 하나의 인터페이스 엔드포인트를 생성해야 한다는 단점과 그 수에 따른 비용이 기하급수적으로 늘어날 수 있다는 단점도 존재하기 때문에, 연결해야 할 AWS 서비스가 적은 경우에만 사용하는 것이 비용 효율성 측면에서 우수합니다.
#3 비용 최적화
실제 스타트업/중소규모 웹 서비스 환경을 가정하고 NAT 장치와, Interface VPC Endpoint를 조합하여 비용을 분석해보려고 합니다. S3로 전송하는 데이터는 Gateway Endpoint로 통신, Region은 AWS 서울 리전(ap-northeast-2), 2개의 가용 영역을 사용하고 월간 데이터 트래픽이 100GB, 24시간을 운영한다고 가정해 보겠습니다.
1. NAT Gateway만을 사용했을 때
먼저 2개의 가용영역 중 한 곳에 NAT을 생성하여 비용 절약을 중시했을 때의 경우를 가정해 보겠습니다.
- 고정 비용 : $0.045/hr
- 데이터 처리 비용 : $0.045/GB
한 달 동안 NAT 장치 사용 비용이 $32.85, 데이터 처리 비용은 $4.50으로, 총 $37.35가 부과됩니다.
2개의 가용영역에 모두 NAT을 생성했을 경우에는 고정 비용이 두 배로 부가되어 총 $70.20가 부과됩니다.
2. Interface VPC Endpoint만을 사용했을 때
컨테이너 환경에서 필수 서비스인 ECR, CloudWatch Logs, SSM을 사용했을 때의 경우를 가정해 보겠습니다.
- 필요한 엔드포인트 수 : 서비스 3개 x 가용영역 2개 = 6개
- 고정 비용 : $0.01/hr x 엔드포인트 수
- 데이터 처리 비용 : $0.01/GB
한 달 동안 엔드포인트 비용은 $43.80, 데이터 처리 비용은 $1.00으로, 총 $44.80가 부과됩니다.
여기서 알 수 있는 것은 다음과 같습니다.
| 연결해야 할 AWS 서비스가 많거나 외부 인터넷 사용이 잦은 경우에는 NAT Gateway가 유리 |
| 월 트래픽이 TB 단위로 넘어가면, 데이터 처리 단가가 싼 Interface VPC Endpoint가 유리 |
#4 결론
관리 편의성과 범용적인 아웃바운드 통신이 필요하다면 NAT Gateway를, 보안이 최우선인 폐쇄망 환경이라면 Interface VPC Endpoint를 선택하는 것이 좋습니다. 초기 비용 절감을 위해 단일 NAT를 사용하더라도, 서비스가 성장하면 반드시 다중 가용영역 구성으로 전환하여 가용 영역 장애에 대비해야 합니다. 무엇보다 어떤 구성을 택하든, S3용 Gateway Endpoint를 함께 사용하여 성능과 비용 효율을 모두 챙기는 것도 중요합니다.
이미지 출처 : https://docs.aws.amazon.com/
'Computer Science' 카테고리의 다른 글
| Route53 가중치 라우팅으로 안전하게 카나리아 배포하기 (0) | 2026.01.19 |
|---|---|
| MSA 환경에서 SNS + SQS, Apache Kafka를 활용하여 시스템 결합도 낮추기 (0) | 2025.12.28 |
| 데이터 불균형 문제 해소를 위한 SMOTE와 SMOTEENN 샘플링 기법 (0) | 2025.08.26 |
| B+트리를 활용하여 DB 인덱싱하기 (0) | 2024.07.23 |
| 대규모 데이터베이스 성능 향상을 위한 샤딩 알고리즘 (0) | 2024.07.14 |