VPC 게이트웨이 엔드포인트는, S3랑 DynamoDB만 지원한다고? 이게 무슨 말일까?

Summary VPC 게이트웨이 엔드포인트는 S3와 DynamoDB에만 지원되며, 이는 AWS의 네트워킹 설계 결정에 기인한다. 이 엔드포인트는 EC2 인스턴스가 인터넷을 거치지 않고 AWS 서비스와 프라이빗하게 통신할 수 있도록 하며, 간단한 요청-응답 패턴과 보안 구조 덕분에 가능하다. 다른 AWS 서비스들은 더 복잡한 통신 패턴을 가지고 있어 인터페이스 엔드포인트를 사용해야 한다. 이 제한은 AWS가 고객의 문제를 해결하기 위한 점진적 접근 방식을 보여준다.

VPC 엔드포인트는 VPC 내부에 존재하는 EC2 인스턴스가 인터넷 게이트웨이를 거치지 않고, AWS 서비스와 프라이빗하게 통신할 수 있도록 하는 서비스야.

VPC 게이트웨이 엔드포인트가 S3와 DynamoDB만 지원하는 이유를 살펴보자. 이 제한은 단순한 기능 제약이 아닌, AWS 네트워킹의 중요한 설계 결정을 반영한다.

VPC는 격리된 가상 네트워크 공간으로, EC2 인스턴스와 같은 리소스를 보안 그룹으로 보호한다. 하지만 S3나 DynamoDB와 같은 퍼블릭 서비스에 접근할 때는 인터넷 게이트웨이나 NAT 게이트웨이를 거쳐야 했다.

이를 해결하기 위해 AWS는 VPC 엔드포인트를 도입했다. 게이트웨이 엔드포인트는 라우팅 테이블을 이용해 VPC에서 S3나 DynamoDB로 직접 연결되는 내부 경로를 제공한다.

게이트웨이 엔드포인트가 S3와 DynamoDB만 지원하는 이유:

• 통신 특성
  • HTTP/HTTPS 기반의 단순한 요청-응답 패턴
  • 일시적인 연결로 복잡한 상태 관리가 불필요
• 보안 구조
  • IAM으로 충분한 접근 제어 가능
  • 단순한 라우팅 규칙으로 트래픽 제어 가능 다른 AWS 서비스들은 더 복잡한 통신 패턴과 보안 요구사항을 가지고 있어, ENI 기반의 인터페이스 엔드포인트를 사용한다. 이는 AWS가 각 서비스의 특성에 맞춰 최적의 네트워킹 솔루션을 제공하고자 한 결과다.

“S3와 DynamoDB만 지원"이라는 문장에 숨겨진 AWS 네트워킹의 진화

“VPC 게이트웨이 엔드포인트는 S3와 DynamoDB만 지원한다.” AWS를 공부하다 보면 무심코 지나치기 쉬운 이 문장을 최근 다시 곱씹어 볼 기회가 있었다. 처음에는 단순한 기술적 제약 사항으로만 여겼지만, 그 이면을 깊이 파고들수록 이것이 AWS 네트워킹 철학과 서비스 발전의 맥락을 압축적으로 보여주는 중요한 단서임을 깨닫게 되었다. 이 문장은 한계가 아닌, 목적에 충실했던 첫걸음과 그 이후의 점진적 진화에 대한 이야기였다.

왜 이런 고민이 시작되었을까? 모든 것은 VPC라는 격리된 나만의 공간에서 출발했다. VPC는 클라우드 위에 구축한 안전한 사설 네트워크다. 그 안의 EC2 인스턴스 같은 리소스들은 외부의 위협으로부터 보호받아야 마땅하다. 하지만 현실적으로 S3에 데이터를 저장하거나 DynamoDB에서 데이터를 읽어오는 작업은 빈번하게 일어난다. 문제는 S3와 DynamoDB가 본질적으로 VPC 외부의 퍼블릭 서비스라는 점이다. 격리된 VPC 내부에서 퍼블릭 서비스와 통신하려면, 기본적으로 인터넷 게이트웨이나 NAT 게이트웨이를 통해 공용 인터넷망을 거쳐야만 했다. 마치 보안이 삼엄한 내 집에서 바로 옆집에 물건을 전해주기 위해, 굳이 동네 바깥의 대로로 나가 한 바퀴 돌아오는 비효율과 같았다. 이 방식은 잠재적인 보안 우려를 낳았고, NAT 게이트웨이 사용 시 불필요한 비용과 예측하기 어려운 성능 저하를 감수해야만 했다.

그래서 AWS는 어떻게 해결했을까? 이 명백한 비효율과 불안을 해결하기 위해 등장한 것이 바로 ‘VPC 엔드포인트’라는 개념, 즉 AWS 내부망을 이용하는 일종의 ‘비밀 통로’였다. 그중에서도 ‘게이트웨이 엔드포인트’는 초기 해결책으로서 매우 독창적인 방식을 택했다. 서브넷 안에 별도의 네트워크 인터페이스(ENI)나 프라이빗 IP를 생성하는 복잡한 과정 없이, 오직 VPC의 ‘라우팅 테이블’을 수정하는 것만으로 문제를 해결했다. 특정 서브넷에서 S3나 DynamoDB의 퍼블릭 IP 대역으로 향하는 트래픽이 발생하면, 라우팅 테이블이 이 트래픽을 인터넷 게이트웨이가 아닌, 새로 생성된 게이트웨이 엔드포인트로 보내도록 경로를 지정해주는 것이다. 트래픽의 ‘목적지 안내판’을 바꿔치기함으로써, 인터넷으로의 불필요한 외출을 막고 AWS 내부 백본망이라는 안전하고 빠른 전용 도로로 안내하는, 지극히 간결하고 우아한 방식이었다.

그렇다면 왜 S3와 DynamoDB에만 이 방식이 적용되었을까? 아마도 이 두 서비스의 통신 특성 때문이었을 것이다. S3와 DynamoDB는 주로 HTTP/HTTPS 기반의 요청-응답(Request-Response) 방식으로 통신한다. 이는 특정 IP 대역으로 향하는 트래픽을 라우팅 규칙만으로 선별하고 제어하기에 매우 용이하다. 또한, 이 두 서비스는 AWS 초기부터 가장 사용량이 많고 데이터 전송량이 막대했던 핵심 서비스였기에, 프라이빗 연결에 대한 고객의 요구가 가장 시급했다. 따라서 AWS는 가장 큰 문제였던 이 두 서비스에 대해 가장 효율적이고 빠르게 적용할 수 있는 ‘게이트웨이’ 방식을 우선적으로 제공했던 것으로 보인다. 반면, 다른 수많은 AWS 서비스들은 SSH, RDP, 혹은 각 데이터베이스의 고유 프로토콜처럼 훨씬 다양하고 복잡한 통신 패턴을 가진다. 지속적인 연결(Stateful Connection)이 중요하거나, 엔드포인트 자체에 세밀한 보안 규칙(보안 그룹) 적용이 필수적인 경우도 많다. 이런 복잡한 요구사항들을 단순한 라우팅 테이블 제어만으로 모두 만족시키기엔 무리가 있었을 것이다.

결론적으로 이 문장이 우리에게 말해주는 것은 무엇인가. “S3와 DynamoDB만 지원한다"는 말은 게이트웨이 엔드포인트의 기술적 한계라기보다는, AWS가 고객의 문제를 해결해 나가는 점진적이고 실용적인 접근 방식을 보여주는 역사적 기록이다. 가장 시급하고 명확한 문제(S3/DynamoDB의 프라이빗 통신)를 가장 단순하고 효과적인 방법(게이트웨이 방식)으로 먼저 해결하고, 이후 더 넓은 범위의 서비스와 복잡한 요구사항을 충족시키기 위해 ENI 기반의 더 유연하고 범용적인 ‘인터페이스 엔드포인트’를 추가로 개발하며 서비스를 확장해 나간 것이다. 결국 이 한 문장은, 하나의 기술이 탄생한 배경과 그것이 다른 기술의 발전을 이끌어낸 진화의 과정을 고스란히 담고 있었다. 기술 문서의 각주처럼 보이는 작은 문장 하나에 담긴 깊이를 이해하고 나니, AWS라는 거대한 시스템이 더욱 흥미롭게 다가온다.