여러 VPC에서 하나의 VPC Endpoint 공유하기: 아키텍처 및 구축 완전 가이드

🗺️ 핵심 토폴로지

                         AWS SERVICES
                               ▲
                               │
                         PrivateLink
                               │
             ┌──────────────────────────┐
             │ NETWORK ACCOUNT          │
             │ Central Endpoint VPC     │
             │                          │
             │ AZ-A             AZ-C    │
             │ VPCE ENI         VPCE ENI│
             │                          │
             │ SSM / KMS / STS / ECR    │
             │ Secrets / CloudWatch     │
             │ SNS / SQS / EC2 API      │
             │ Route 53 Profile         │
             └────────────┬─────────────┘
                          │
                    Transit Gateway
               ┌──────────┼───────────┐
               │          │           │
             PROD        DEV         TEST
               │          │           │
            VPC-A       VPC-B       VPC-C
               │          │           │
        S3 Gateway   S3 Gateway   S3 Gateway
        DDB Gateway  DDB Gateway  DDB Gateway

🧰 네 가지 핵심 서비스

• AWS PrivateLink / Interface VPC Endpoint: Application VPC에서 리전 AWS 서비스까지 사설 연결을 제공합니다.
• AWS Transit Gateway: Endpoint VPC와 여러 VPC를 연결하고 TGW Route Table로 도달 범위를 제어합니다.
• Route 53 Profiles: Interface Endpoint Private DNS를 중앙 관리하여 여러 VPC에 연결합니다.
• AWS RAM: Transit Gateway와 Route 53 Profile을 여러 AWS 계정에 공유합니다.

🏢 온프레미스 데이터 센터가 있는 경우

온프레미스가 VPN 또는 Direct Connect로 AWS에 연결된다면 Route 53 Resolver Inbound Endpoint를 추가합니다. 사내 DNS는 AWS 서비스 도메인을 이 Resolver로 전달할 수 있습니다. VPC의 “CIDR + 2” Resolver 주소에 직접 질의하는 방식은 피합니다.

1️⃣ 전용 Endpoint VPC 생성

• Network 또는 Shared Services 계정에 Endpoint-VPC를 생성합니다. 예시 CIDR은 10.100.0.0/16입니다.
• 운영 환경은 최소 2개 AZ를 사용합니다. 예를 들어 AZ-a에 10.100.10.0/24, AZ-c에 10.100.20.0/24를 두고 각 AZ에 Endpoint Subnet을 만듭니다.
• Interface Endpoint는 선택한 Endpoint Subnet마다 ENI를 생성합니다. 2개 AZ 배포는 단일 AZ 장애 영향을 줄입니다.
• 공유 Endpoint를 임의의 Application VPC에 넣으면 네트워크 소유권, 권한 경계, 장애 대응이 특정 워크로드에 종속되므로 피해야 합니다.

2️⃣ Transit Gateway 또는 VPC Peering 연결

• 중앙 Transit Gateway를 생성하고 Endpoint VPC, VPC-A, VPC-B, VPC-C의 VPC Attachment를 연결합니다.
• 멀티 계정 환경은 AWS RAM으로 TGW를 공유하고 각 Application 계정이 Attachment를 생성하거나 수락합니다.
• Application VPC가 2~3개뿐이라면 각 VPC를 Endpoint VPC와 직접 Peering하여 네트워크 계층과 TGW 비용을 줄일 수 있습니다.
• Peering은 전이적이지 않습니다. 규모가 커지면 연결과 라우팅 관리가 급증하므로 TGW Hub-and-Spoke 방식이 효율적입니다.

3️⃣ Application VPC Route Table

Endpoint를 사용하는 각 Application Subnet은 Endpoint VPC CIDR을 TGW로 보내야 합니다. VPC-A 예시:

Destination       Target
10.1.0.0/16       local
10.100.0.0/16     tgw-xxxx

VPC-B와 VPC-C도 10.100.0.0/16을 같은 TGW로 보냅니다. Peering을 사용한다면 Target을 해당 Peering Connection으로 지정합니다.

4️⃣ Endpoint VPC 반환 경로

Endpoint Subnet에 연결된 Route Table은 모든 Application VPC로 돌아갈 수 있어야 합니다.

10.100.0.0/16      local
10.1.0.0/16        tgw-xxxx
10.2.0.0/16        tgw-xxxx
10.3.0.0/16        tgw-xxxx

왕복 경로가 모두 필요합니다. 반환 경로가 없으면 TCP SYN은 전송되지만 SYN/ACK이 돌아오지 않아 연결 시간이 초과됩니다.

5️⃣ TGW Route Table

• Application VPC 관련 라우트는 10.100.0.0/16을 Endpoint VPC Attachment로 보냅니다.
• Endpoint VPC 쪽에서 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16은 각각의 VPC Attachment로 향해야 합니다.
• Route Propagation 또는 Static Route를 사용할 수 있습니다. 엄격한 분리가 필요하면 여러 TGW Route Table로 전파 관계를 명시적으로 제어합니다.

6️⃣ Endpoint VPC에 서비스 Endpoint 생성

• VPC → Endpoints → Create endpoint에서 리전 서비스를 선택합니다. 도쿄 리전 Systems Manager는 com.amazonaws.ap-northeast-1.ssm입니다.
• VPC는 Endpoint-VPC, Subnet은 endpoint-subnet-a와 endpoint-subnet-c를 선택합니다.
• Route 53 Profiles 구성에서는 Private DNS를 Enabled로 유지합니다. SDK와 CLI가 표준 서비스 이름을 사용해도 PrivateLink 사설 주소로 연결됩니다.
• 실제 워크로드에 필요한 Endpoint만 생성합니다. Interface Endpoint마다 AZ 시간 요금과 데이터 처리 요금이 추가됩니다.

📦 자주 중앙화하는 Endpoint

• Systems Manager: SSM, SSM Messages, EC2 Messages.
• 핵심 서비스: EC2 API, KMS, Secrets Manager, STS, Lambda, EventBridge.
• 모니터링 및 메시징: CloudWatch, CloudWatch Logs, SNS, SQS.
• 컨테이너 및 배포: ECR API, ECR DKR, ECS, CodeArtifact.
• 애플리케이션 접근: API Gateway execute-api 등 PrivateLink 지원 서비스.

7️⃣ Endpoint Security Group

• Endpoint ENI 전용으로 sg-vpce-central 같은 Security Group을 생성합니다.
• Inbound HTTPS TCP 443은 필요한 Application CIDR인 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 등에서만 허용합니다.
• 운영 환경에서 0.0.0.0/0을 허용하지 않습니다. 조직, 환경, 민감도 또는 전용 Endpoint에 따라 소스를 제한합니다.
• Security Group은 Stateful이지만 인스턴스 Egress 규칙, NACL, 중간 어플라이언스에서도 TCP 443과 반환 트래픽을 허용해야 합니다.

8️⃣ Endpoint Policy

• Endpoint Policy는 해당 진입점을 통해 어떤 Principal이 어떤 서비스 작업을 실행할 수 있는지 제어합니다. Full Access는 연결 테스트에는 유용하지만 운영 기본값으로는 적합하지 않습니다.
• KMS Endpoint는 승인된 계정, IAM Role, KMS Key로 제한할 수 있습니다. 다른 서비스도 지원되는 조건 키와 리소스 제한을 적용합니다.
• 최종 권한은 Endpoint Policy, IAM Policy, SCP, Resource Policy, Bucket Policy, Key Policy를 함께 평가해 결정됩니다.
• 공유 VPC가 늘수록 최소 권한 Policy가 복잡해지고 문서 크기 제한도 적용됩니다. 필요하면 환경이나 신뢰 경계별로 Endpoint를 나눕니다.

🧭 계정별 역할

AWS Organizations

Network Account
├ Endpoint VPC
├ Transit Gateway
└ Route 53 Profile

Production Account
├ VPC-A
└ VPC-B

Development Account
├ VPC-C
└ VPC-D

Security Account
└ VPC-E

• Network Account는 AWS RAM으로 같은 리전의 Production, Development, Security 계정에 Route 53 Profile을 공유합니다.
• 각 계정은 자신의 VPC를 공유 Profile에 연결하여 서비스와 VPC마다 Private Hosted Zone을 만들지 않고 중앙 DNS를 재사용합니다.
• AWS Organizations, Control Tower, Landing Zone에 맞는 역할 분리입니다. 네트워크 팀은 VPCE, DNS, TGW, 로그를 관리하고 애플리케이션 팀은 컴퓨팅과 워크로드 리소스를 관리합니다.

① DNS 해석

VPC-A의 10.1.10.50 EC2가 Secrets Manager를 호출하면 SDK가 secretsmanager.ap-northeast-1.amazonaws.com을 조회합니다. Route 53 Resolver와 연결된 Profile이 중앙 VPCE의 사설 주소를 반환합니다.

EC2 → Route 53 Resolver → Route 53 Profile
    → VPCE Private DNS → 10.100.10.25 / 10.100.20.25

② 네트워크 경로

10.1.10.50
    │ HTTPS 443
    ▼
VPC-A Route Table
    ▼
Transit Gateway
    ▼
Endpoint VPC
    ▼
VPCE ENI 10.100.10.25
    ▼
AWS PrivateLink
    ▼
Secrets Manager

AWS 서비스까지의 경로는 사설로 유지되며 NAT Gateway나 Internet Gateway가 필요 없습니다. 요청은 네트워크 제어와 자격 증명 권한을 모두 통과해야 합니다.

• ECS, EKS, EC2가 ECR 이미지를 Pull할 때는 보통 ecr.api뿐 아니라 ecr.dkr도 필요합니다.
• 컨테이너 이미지 Layer는 S3에 저장되므로 두 ECR Interface Endpoint가 있어도 Pull이 실패할 수 있습니다.
• 보통 ECR API와 ECR DKR은 중앙화하고 각 Application VPC에 S3 Gateway Endpoint를 만듭니다.
• 문제 해결 시 DNS, 두 ECR Endpoint, S3 Gateway Endpoint, 라우팅, Security Group, Task 또는 Instance IAM 권한을 확인합니다.

지금도 사용할 수 있는 방식

• 중앙 Interface Endpoint에서 Private DNS를 끕니다.
• ssm.ap-northeast-1.amazonaws.com처럼 AWS 서비스 이름과 같은 Route 53 Private Hosted Zone을 수동 생성합니다.
• VPCE를 가리키는 A Alias Record를 만들고 PHZ를 Endpoint VPC와 모든 Application VPC에 연결합니다.

신규 환경의 우선 선택이 아닌 이유

• Endpoint 30개와 VPC 100개가 있으면 수동 PHZ Association이 거대한 관리 행렬이 됩니다.
• Route 53 Profiles는 중앙 VPCE를 한 번 연결한 뒤 같은 구성을 여러 VPC에 적용하여 Hosted Zone, Record, Association 중복을 줄입니다.
• 기존 시스템이나 특수 DNS 요구에는 기존 방식도 유효하지만 신규 구축에서는 Profiles를 먼저 검토합니다.

중앙 집중형 비용 항목

• Transit Gateway Attachment 시간 요금.
• Transit Gateway 데이터 처리 요금.
• 배포된 각 AZ의 Interface Endpoint 시간 요금.
• PrivateLink 데이터 처리 및 AZ 간·리전 간 데이터 전송 요금.

비용 절감 가능성이 높은 경우

VPC와 필요한 Endpoint가 많고 VPC당 트래픽이 비교적 적은 환경일수록 중앙화 효과가 큽니다. VPC 50개, 서비스 20개, AZ 2개라면 분산형은 Endpoint ENI 2,000개, 중앙형은 약 40개지만 TGW 비용도 반드시 포함해야 합니다.

대용량 트래픽은 별도 계산

한 VPC에서 매일 수 TB의 S3 트래픽이 발생하면 TGW를 거쳐 S3 Interface Endpoint로 보내는 방식은 비효율적일 수 있습니다. 로컬 S3 Gateway Endpoint가 더 적합합니다. AWS 가격은 리전과 시기에 따라 달라지므로 최신 리전별 가격으로 예산을 만들고 모든 금액을 원화로 환산해 비교합니다.

VPC 1~3개

• 각 VPC에 Endpoint를 배치하는 방식이 가장 단순하고 격리 수준도 높습니다.
• 수를 줄여야 한다면 Peering + Route 53 Profile + 소규모 Central Endpoint VPC를 사용합니다.
• 몇 개 Endpoint 공유만을 위해 TGW를 도입할 필요는 대체로 없습니다.

VPC 5~20개

• Endpoint VPC + TGW + Route 53 Profiles를 본격적으로 검토합니다.
• 중복 고정비, TGW 비용, 실제 트래픽을 함께 비교합니다.
• 대용량 또는 강한 격리가 필요한 워크로드에는 전용 Endpoint를 남기는 혼합형도 좋습니다.

VPC 20개~수백 개

• Network Account에 TGW 또는 Cloud WAN, Endpoint VPC, Profiles, Resolver, Network Firewall, DNS Firewall을 모읍니다.
• IaC, 표준 태그, 로그, 모니터링, 변경 통제로 Endpoint와 계정 연결을 관리합니다.
• 모든 워크로드가 하나의 중앙 스택에 의존하지 않도록 리전, 환경, 신뢰 경계별로 분리합니다.

1. DNS: dig ssm.ap-northeast-1.amazonaws.com을 실행해 공인 IP가 아닌 10.100.x.x 같은 VPCE 사설 IP가 반환되는지 확인합니다.
2. Spoke VPC Route Table: Endpoint VPC CIDR이 TGW 또는 Peering을 향하는지 확인합니다.
3. TGW Route Table: Application VPC와 Endpoint VPC 사이의 왕복 경로를 확인합니다.
4. Endpoint VPC Route Table: Endpoint Subnet에서 모든 Application VPC로 반환 가능한지 확인합니다.
5. VPCE Security Group: Application CIDR에서 TCP 443을 허용하는지 확인합니다.
6. NACL: Inbound, Outbound, Ephemeral Port 범위를 확인합니다.
7. Endpoint Policy: Principal, Action, Resource가 거부되지 않았는지 확인합니다.
8. IAM / Resource Policy / SCP: 마지막으로 자격 증명, 리소스, 조직 수준 제어를 확인합니다.

“이름 해석 → 라우팅 → 네트워크 제어 → 권한” 순서로 확인하면 콘솔을 무작정 오가는 것보다 빠르게 원인을 찾을 수 있습니다.