> [!abstract] Introduction > 보안이 중요한 환경에서는 VPC 내부의 리소스가 인터넷을 경유하지 않고 AWS 서비스에 접근해야 합니다. 인터넷을 거치면 [[VPC Routing & Gateway#NAT Gateway|NAT Gateway]] 비용이 발생하고, 트래픽이 공개 네트워크를 지나는 보안 위험도 수반됩니다. VPC 엔드포인트는 이 두 문제를 동시에 해결합니다. 이 글에서는 게이트웨이 엔드포인트(Gateway Endpoint)와 인터페이스 엔드포인트(Interface Endpoint(PrivateLink))의 동작 원리, 사용 사례, 그리고 비용 구조를 살펴봅니다. # VPC Endpoint의 필요성 VPC 내 프라이빗 서브넷의 인스턴스가 S3에 데이터를 업로드하는 시나리오를 생각해 보자. VPC 엔드포인트가 없다면 트래픽은 다음 경로를 따른다. ``` EC2 → NAT Gateway → IGW → 인터넷 → S3 퍼블릭 엔드포인트 ``` 이 경로의 문제점은 두 가지다. 첫째, NAT Gateway의 데이터 처리 비용($0.045/GB)이 발생한다. 월 10TB를 전송하면 NAT 비용만 $450이다. 둘째, 트래픽이 인터넷을 경유하므로, 보안 감사 시 이 경로가 컴플라이언스 위반으로 지적될 수 있다. VPC 엔드포인트를 사용하면 트래픽 경로가 다음과 같이 바뀐다. ``` EC2 → VPC Endpoint → AWS 백본 네트워크 → S3 ``` 인터넷을 전혀 거치지 않고, AWS 내부 네트워크만 통과한다. NAT 게이트웨이도 경유하지 않으므로 데이터 처리 비용이 제거되거나 크게 줄어든다. # Gateway Endpoint ## 지원 서비스와 동작 원리 게이트웨이 엔드포인트(Gateway Endpoint)는 Amazon S3와 DynamoDB 두 서비스에 대해서만 지원된다. [[VPC Routing & Gateway#라우팅 테이블|라우팅 테이블]]에 해당 서비스의 프리픽스 목록*prefix list*을 타겟으로 하는 경로를 추가하는 방식으로 동작한다. 게이트웨이 엔드포인트를 생성하면 지정한 서브넷의 라우팅 테이블에 다음과 같은 경로가 자동으로 추가된다. | 목적지 | 타겟 | | :--- | :--- | | `pl-xxxxxxxx` (S3 프리픽스 목록) | `vpce-xxxxxxxx` (Gateway Endpoint) | 프리픽스 목록[^prefix-list-definition]은 해당 AWS 서비스가 사용하는 IP 주소 범위의 집합이다. S3의 경우 리전별로 수십 개의 IP 대역이 포함되어 있으며, AWS가 IP를 추가하거나 변경하면 프리픽스 목록이 자동으로 업데이트된다. [^prefix-list-definition]: 프리픽스 목록(Prefix List) — 하나 이상의 CIDR 블록을 그룹화한 논리적 객체다. AWS 관리형 프리픽스 목록은 AWS 서비스의 IP 범위를 자동으로 관리하고, 사용자 관리형 프리픽스 목록은 자주 사용하는 IP 대역을 하나로 묶어 [[Security Group|보안 그룹]]이나 라우팅 테이블에서 참조할 수 있다. ```mermaid flowchart LR EC2["EC2 인스턴스<br/>(프라이빗 서브넷)"] -->|"라우팅 테이블:<br/>pl-s3 → vpce"| GW["Gateway Endpoint"] GW -->|"AWS 백본"| S3["Amazon S3"] EC2 -.->|"NAT 게이트웨이<br/>경유 불필요"| NAT["NAT Gateway"] ``` ## 비용과 제약 게이트웨이 엔드포인트의 가장 큰 장점은 완전 무료라는 것이다. 생성 비용, 시간당 요금, 데이터 처리 비용이 모두 없다. 따라서 S3나 DynamoDB를 사용하는 워크로드에서는 NAT 게이트웨이 대신 반드시 게이트웨이 엔드포인트를 사용해야 한다. 제약은 몇 가지 있다. 첫째, 동일 리전의 S3/DynamoDB에만 접근할 수 있다. 다른 리전의 S3 버킷에 접근하려면 여전히 인터넷 경로가 필요하다. 둘째, 온프레미스에서 VPN이나 Direct Connect를 통해 게이트웨이 엔드포인트를 사용할 수 없다. 온프레미스에서 VPC를 경유하여 S3에 프라이빗하게 접근해야 하는 경우에는 인터페이스 엔드포인트(Interface Endpoint)를 사용해야 한다. 셋째, VPC당 서비스별로 하나의 게이트웨이 엔드포인트만 생성할 수 있지만, 라우팅 테이블을 통해 여러 서브넷에서 공유할 수 있다. ## Endpoint 정책 게이트웨이 엔드포인트에는 IAM 정책과 유사한 형태의 엔드포인트 정책을 연결하여 접근 범위를 제한할 수 있다. ```json { "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::my-secure-bucket", "arn:aws:s3:::my-secure-bucket/*" ] } ] } ``` 이 정책은 VPC 엔드포인트를 통한 S3 접근을 `my-secure-bucket` 버킷으로만 제한한다. 이를 통해 프라이빗 서브넷의 인스턴스가 허용된 버킷에만 접근하도록 네트워크 수준에서 강제할 수 있다. # Interface Endpoint (PrivateLink) ## 지원 서비스와 동작 원리 인터페이스 엔드포인트(Interface Endpoint)는 S3, DynamoDB를 포함한 대부분의 AWS 서비스(EC2 API, SNS, SQS, Kinesis, SageMaker, CloudWatch 등)와 서드파티 SaaS 서비스를 지원한다. 게이트웨이 엔드포인트가 라우팅 테이블을 수정하는 방식인 반면, 인터페이스 엔드포인트는 VPC 내부에 프라이빗 IP를 가진 ENI를 생성하는 방식으로 동작한다. ```mermaid flowchart LR EC2["EC2 인스턴스"] -->|"프라이빗 IP"| ENI["Interface Endpoint<br/>(ENI: 10.0.2.50)"] ENI -->|"AWS PrivateLink"| SVC["AWS 서비스<br/>(예: SNS, SQS)"] EC2 -.->|"인터넷 경유 없음"| INET["인터넷"] ``` 인터페이스 엔드포인트를 생성하면 지정한 서브넷에 ENI가 생성되고, 프라이빗 DNS가 활성화된 경우 해당 서비스의 퍼블릭 DNS 이름(예: `sns.us-east-1.amazonaws.com`)이 이 ENI의 프라이빗 IP로 해석되도록 자동 설정된다. 따라서 애플리케이션 코드를 변경할 필요가 없다. 기존의 AWS SDK 호출이 그대로 프라이빗 경로를 통해 전달된다. ## PrivateLink의 핵심 가치 인터페이스 엔드포인트의 기반 기술인 AWS PrivateLink는 다음과 같은 특성을 갖는다. 1. 트래픽이 AWS 백본 네트워크 내에만 머문다. 퍼블릭 인터넷에 노출되지 않으므로 보안이 강화된다. 2. [[Security Group|보안 그룹]]을 적용하여 엔드포인트에 접근할 수 있는 소스를 정밀하게 제어할 수 있다. 예를 들어, 특정 애플리케이션 서버만 SNS 엔드포인트에 접근하도록 제한할 수 있다. 3. 다른 계정의 VPC나 온프레미스(VPN/Direct Connect 연결 시)에서도 이 엔드포인트를 통해 서비스에 접근할 수 있다. 이는 게이트웨이 엔드포인트에서는 불가능한 기능이다. 4. 자체 서비스를 PrivateLink로 노출할 수 있다. Network Load Balancer(NLB) 뒤에 서비스를 배치하고 VPC Endpoint Service로 등록하면, 다른 VPC나 계정에서 해당 서비스에 프라이빗하게 접근할 수 있다. 이는 SaaS 제공자가 고객에게 프라이빗 연결을 제공하는 핵심 메커니즘이다. ## 비용 인터페이스 엔드포인트는 게이트웨이 엔드포인트와 달리 유료다. | 항목 | 비용 (us-east-1 기준) | | :--- | :--- | | 시간당 요금 | $0.01/AZ/시간 (≈ $7.2/AZ/월) | | 데이터 처리 | $0.01/GB | 2개 AZ에 인터페이스 엔드포인트를 생성하고 월 100GB를 처리하면, 월 비용은 약 $15.4($14.4 시간 + $1.0 처리)이다. NAT Gateway($32.4 시간 + $4.5 처리 = $36.9)보다 저렴하므로, 특정 서비스로의 트래픽이 대부분인 경우 인터페이스 엔드포인트가 비용 면에서도 유리하다. # Gateway Endpoint vs Interface Endpoint | 항목 | Gateway Endpoint | Interface Endpoint | | :--- | :--- | :--- | | 지원 서비스 | S3, DynamoDB만 | 대부분의 AWS 서비스 + SaaS | | 동작 방식 | 라우팅 테이블에 경로 추가 | 서브넷에 ENI 생성 | | 비용 | **무료** | 시간 요금 + 데이터 처리 | | Security Group | 적용 불가 | 적용 가능 | | 온프레미스 접근 | 불가 | 가능 (VPN/DX 경유) | | DNS | 변경 없음 | 프라이빗 DNS 자동 설정 | | 사용 사례 | S3/DynamoDB 대량 트래픽 | 다양한 AWS 서비스 프라이빗 접근 | S3의 경우 게이트웨이 엔드포인트와 인터페이스 엔드포인트를 모두 사용할 수 있다. 대량의 데이터 전송에는 무료인 게이트웨이 엔드포인트가 유리하고, 온프레미스에서의 프라이빗한 접근이나 보안 그룹 적용이 필요한 경우에는 인터페이스 엔드포인트를 선택한다. # 비용 최적화 패턴 많은 조직이 모든 아웃바운드 트래픽을 NAT 게이트웨이로 보내는 실수를 범한다. 트래픽의 목적지를 분석하고 적절한 엔드포인트를 배치하면 비용을 크게 절감할 수 있다. 예를 들어, 프라이빗 서브넷에서 월 5TB를 S3로, 500GB를 SNS/SQS로, 500GB를 인터넷으로 전송하는 서비스를 운영하는 데 들어가는 비용은 매월 아래와 같다. | 구성 | 월 비용 | | :--- | :--- | | 모든 트래픽 → NAT GW | $32.4(시간) + $270(6TB × $0.045) = **$302.4** | | S3 → GW Endpoint + 나머지 → NAT GW | $32.4(시간) + $45(1TB × $0.045) + $0(S3) = **$77.4** | | S3 → GW Endpoint + SNS/SQS → Interface Endpoint + 인터넷 → NAT GW | $32.4(NAT 시간) + $22.5(0.5TB NAT) + $14.4(Interface) + $5(0.5TB Interface) + $0(S3) = **$74.3** | 게이트웨이 엔드포인트만 추가해도 비용이 75% 절감된다. 트래픽 대부분이 S3로 향하는 데이터 파이프라인이나 로그 수집 워크로드에서 이 패턴은 필수적이다. --- ## 출처 - Amazon Web Services (2026) *Gateway endpoints.* Available at: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html - Amazon Web Services (2026) *Access an AWS service using an interface VPC endpoint.* Available at: https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html - Amazon Web Services (2026) *AWS PrivateLink pricing.* Available at: https://aws.amazon.com/privatelink/pricing/ - Digital Cloud Training (2025) *VPC Interface Endpoint vs Gateway Endpoint in AWS.* Available at: https://digitalcloud.training/vpc-interface-endpoint-vs-gateway-endpoint-in-aws/ - Amazon Web Services (2026) *Centralized access to VPC private endpoints.* Available at: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html