AWS Private Link 를 사용하여 시크릿한 통신하기

AI 생성 썸네일

최근 많은 기업들이 보안 정책상 외부 인터넷 접근이 제한된 폐쇄망(Private Network) 환경을 운영하고 있습니다. 하지만 Public 클라우드에서 제공되는 멀티 테넌트 SaaS 서비스를 활용해야 하는 상황도 늘어나고 있죠. 이러한 외부망과 통신하지 않는 요구사항을 해결하기 위한 방법 중 하나가 바로 AWS PrivateLink입니다.

이 글에서는 Public 망에 배포된 SaaS 애플리케이션을 Private 망만 사용하는 고객과 안전하게 연결하는 방법과, 실무에서 반드시 챙겨야 할 포인트들을 다룹니다.

AWS PrivateLink란?

AWS PrivateLink는 VPC 간 또는 온프레미스와 AWS 서비스 간에 프라이빗 연결을 제공하는 기술입니다. 인터넷 게이트웨이, NAT, VPN, Direct Connect 없이도 서비스에 안전하게 접근할 수 있습니다.

주요 구성 요소

VPC Endpoint Service (Service Provider): 서비스를 제공하는 측에서 생성
VPC Endpoint (Client): 서비스를 사용하는 측에서 생성
Network Load Balancer: VPC Endpoint Service와 연결되어 트래픽을 분산

네트워크 로드밸런서뿐만 아니라 GW (Gateway) 로드밸런서도 Private Link에 사용할 수 있습니다. 각각은 L4, L3 계층에서 로드밸런싱을 해주는 서비스이며, 각각의 사용 사례가 다르기 때문에 사용 사례에 맞춰 선택할 수 있습니다.

vpc endpoint 로 연결하는 client 측에서 보는 흐름은 아래와 같습니다

[고객 VPC - Private Subnet]
         ↓
  VPC Endpoint (ENI)
         ↓
[SaaS Provider AWS Account]
         ↓
  VPC Endpoint Service
         ↓
 Network Load Balancer
         ↓
   K8s Service → Pods

VPCN Endpoint 를 생성한 클라이언트 측의 VPC에서 VPC Endpoint Service를 생성한 Provider 방향으로 단방향 트래픽이 허용됩니다.

PrivateLink의 핵심 기술: AWS Hyperplane

PrivateLink의 동작 원리를 이해하기 위해서는 AWS Hyperplane에 대해 알아야 합니다. Hyperplane은 AWS의 내부 네트워크 가상화 플랫폼으로, PrivateLink, NLB, NAT Gateway 등의 기반이 되는 기술입니다.

Hyperplane의 역할

Hyperplane은 분산 상태 저장(stateful) 네트워크 처리 플랫폼입니다. 기존의 인스턴스 기반 로드밸런서와 달리, Hyperplane은 AWS의 네트워크 인프라 자체에 내장되어 있습니다.

VPC Endpoint를 생성하면 다음과 같은 과정이 진행됩니다:

Client VPC의 서브넷에 ENI(Elastic Network Interface)가 생성됩니다.
이 ENI는 Hyperplane fleet에 연결됩니다.
Hyperplane이 ENI로 들어오는 트래픽을 받아서 Service Provider 측 NLB로 전달합니다.

이 과정에서 중요한 점은 모든 트래픽이 AWS 내부 백본 네트워크를 통해 전달된다는 것입니다. 서로 다른 AWS 계정이더라도 인터넷을 거치지 않고 통신할 수 있습니다.

실제 트래픽 흐름

Client VPC에서 Provider VPC로 트래픽이 전달되는 구체적인 흐름은 다음과 같습니다.

1. Client VPC의 EC2 인스턴스 (10.0.2.50)
   └─> api.yourdomain.com 으로 HTTPS 요청

2. VPC Route 53 Resolver (10.0.0.2)
   └─> DNS 조회: api.yourdomain.com = 10.0.1.100 (VPC Endpoint ENI)

3. VPC Routing Table
   └─> 10.0.1.100으로 트래픽 라우팅

4. VPC Endpoint ENI (10.0.1.100)
   └─> Security Group 검사
   └─> Hyperplane으로 전달

5. AWS Hyperplane (내부 네트워크)
   └─> VPC Endpoint Service 식별
   └─> service Provider 계정의 NLB로 전달

6. Provider VPC의 NLB
   └─> Target Health Check
   └─> 가용한 Target으로 로드밸런싱
   └─> Target Security Group 검사

7. Kubernetes Node → Pod
   └─> 실제 애플리케이션 처리

8. 응답은 역순으로 전달

이 흐름에서 5번 단계가 핵심입니다. Hyperplane이 VPC 경계를 넘어서 트래픽을 전달하며, 이 과정에서 VPC Peering, Transit Gateway, VPN, Direct Connect 등이 필요하지 않습니다.

ENI의 특수한 역할

VPC Endpoint를 생성할 때 각 서브넷에 ENI가 생성됩니다. 이 ENI는 일반 ENI와는 다르게 동작합니다:

Private IP 주소를 가지며 Client VPC의 라우팅 테이블에서 참조됩니다.
Security Group을 적용할 수 있어 트래픽을 제어할 수 있습니다.
실제로는 Hyperplane으로 연결되는 터널 역할을 합니다.

이 ENI가 Client VPC 내부의 트래픽 진입점이 되며, 이를 통해 들어온 모든 트래픽은 Hyperplane을 거쳐 Provider의 서비스로 전달됩니다.

NLB와 ALB: Layer 4 vs Layer 7

PrivateLink가 NLB(또는 GWLB - Layer3)만 지원하고 ALB는 지원하지 않는 이유는 OSI Layer와 관련이 있습니다:

Network Load Balancer (NLB)

Layer 4 (TCP/UDP)에서 동작합니다.
IP 주소와 포트 정보만으로 트래픽을 라우팅합니다.
패킷 레벨에서 처리하므로 지연 시간이 낮습니다.

Application Load Balancer (ALB)

Layer 7 (HTTP/HTTPS)에서 동작합니다.
HTTP 헤더, 경로, 호스트 등을 파싱하여 라우팅합니다.
콘텐츠 기반 라우팅이 가능하지만 처리 오버헤드가 있습니다.

Hyperplane은 Layer 3/4에서 동작하는 분산 시스템입니다. 패킷의 IP와 포트만 보고 라우팅하므로 NLB와 호환성이 좋습니다. ALB는 HTTP 프로토콜을 이해하고 처리해야 하는데, 이는 Hyperplane의 설계 범위를 벗어납니다.

따라서 PrivateLink는 NLB 또는 Gateway Load Balancer만 지원합니다.

구성 단계별 가이드

VPC Endpoint Service 생성 (Provider 측)

PrivateLink 구성의 첫 번째 단계는 서비스를 제공할 인프라를 준비하는 것입니다. Kubernetes 클러스터에서 서비스를 운영하고 있고, 이 서비스를 외부로 노출시키기 위해 Network Load Balancer를 사용할 수 있습니다.

AWS 콘솔에서 VPC > Endpoint Services로 이동해 “Create endpoint service”를 선택합니다.

먼저 로드 밸런서 유형은 Network를 선택합니다 (GWLB 도 가능합니다!). Application Load Balancer는 PrivateLink와 호환되지 않기 때문입니다. 그다음 앞서 생성한 NLB를 선택하는데, 만약 여러 서비스(예: API, Console, Admin)를 제공한다면 각각에 대해 별도의 Endpoint Service를 만드는 것을 권장합니다. 다만 NLB는 계정 다아 최대 50개의 제한이 있으니 제한 사항을 잘 확인하고 생성해야 합니다.

“수락 필수(Acceptance required)” 옵션을 활성화하면 연결 요청이 올 때 수동으로 승인할 수 있습니다. 보안을 위해 이 옵션을 켜두는 것을 권장합니다.

“프라이빗 DNS 이름을 서비스에 연결” 옵션을 활성화하고 DNS 이름(예: api.yourdomain.com)을 입력합니다. 이 설정이 있으면 고객이 코드 수정 없이 같은 도메인으로 PrivateLink를 통해 접속할 수 있습니다. Private DNS 이름에는 와일드카드(*. api.yourdomain.com)도 사용 가능합니다.

생성이 완료되면 Service 이름(예: com.amazonaws.vpce.ap-northeast-2.vpce-svc-xxxxx)이 생성되는데, 이를 고객에게 제공해야 합니다. “보안 주체 허용” 탭에서 고객사의 AWS 계정 ID를 추가해 해당 계정만 연결할 수 있도록 제한합니다.

Private DNS 도메인 검증 (Service Provider 측)

VPC Endpoint Service 생성 직후 도메인 확인 상태는 “Pending verification”입니다. 도메인 소유권을 증명하기 위해 Route 53에 TXT 레코드를 추가해야 합니다.

Endpoint Service 상세 페이지에서 “도메인 확인 값”을 복사한 뒤, Route 53 콘솔로 이동합니다. 해당 도메인의 호스팅 영역에서 “레코드 생성”을 선택하고 다음과 같이 설정합니다.

레코드 이름: Private DNS 이름 (예: api.yourdomain.com)
레코드 유형: TXT
값: 복사한 도메인 확인 값
TTL: 300

레코드 생성 후 VPC Endpoint Service 콘솔로 돌아와 “작업” > “프라이빗 DNS 이름에 대한 도메인 소유권 확인”을 실행합니다. DNS 전파에 몇 분이 소요되며, 완료되면 도메인 확인 상태가 “Verified”로 변경됩니다.

VPC Endpoint 생성 (Client 측)

고객에게 VPC Endpoint Service 이름과 필요한 보안 그룹 규칙을 제공하면, 고객은 자신의 AWS 계정에서 VPC Endpoint를 생성합니다.

AWS 콘솔의 VPC > Endpoints에서 “Create endpoint”를 선택하고, 서비스 카테고리에서 “다른 서비스 찾기”를 선택한 뒤 제공받은 Service 이름을 입력합니다.

Endpoint를 생성할 VPC와 ENI가 배치될 서브넷을 선택합니다. 폐쇄망 환경이므로 Private 서브넷을 선택해야 합니다. 가용 영역별로 하나씩 선택하면 고가용성을 확보할 수 있습니다.

보안 그룹은 내부 클라이언트에서 ENI로의 트래픽을 허용하도록 설정합니다. 일반적으로 VPC CIDR 전체에서 443 포트 접근을 허용하는 규칙을 만듭니다.

연결 수락 (Service Provider 측)

고객이 VPC Endpoint를 생성하면 Endpoint Service에 연결 요청이 들어옵니다. “엔드포인트 연결” 탭에서 Pending 상태의 요청을 확인할 수 있습니다.

요청한 AWS 계정 ID를 확인한 뒤, 해당 요청을 선택하고 “작업” > “엔드포인트 연결 요청 수락”을 클릭합니다. 상태가 “Available”로 변경되면 물리적 연결이 완료된 것입니다.

Private DNS 활성화 (Client 측)

연결이 수락되고 Available 상태가 되면, 고객 측에서 Private DNS를 활성화합니다. VPC Endpoint 상세 페이지에서 “작업” > “Modify private DNS name”을 선택하고 “Enable for this endpoint”를 체크합니다.

이 설정이 활성화되면 고객의 VPC 내에서 서비스 도메인을 조회할 때 Public IP가 아닌 VPC Endpoint의 Private IP로 해석됩니다. 애플리케이션 코드는 수정하지 않아도 자동으로 PrivateLink를 통해 통신하게 됩니다.

추가적으로 VPC의 다음 설정도 확인이 되어야 합니다.

실무에서 반드시 챙겨야 할 포인트

NLB 변경은 생각보다 복잡합니다

VPC Endpoint가 연결된 상태에서는 VPC Endpoint Service의 NLB를 변경할 수 없습니다. 변경이 필요하면 연결된 모든 Endpoint를 삭제하고, Service를 수정한 뒤, 다시 생성하는 과정을 거쳐야 합니다. 이는 VPC Endpoint service 뿐만 아니라 VPC Endpoint의 수정을 의미합니다.

프로덕션에 이미 여러 고객사가 연결된 상황이라면 각 고객사 담당자와 작업 시간을 조율해야 합니다. 처음 구축할 때 지속적으로 사용 가능할 수 있도록 구성을 유지하는 것이 중요합니다. 이런 문제를 방지하려면 초기 구성 시 NLB가 원하는 스펙으로 생성되도록 해야 합니다. 나중에 바꾸는 것보다 처음부터 제대로 만드는 게 중요합니다.

DNS 활성화는 연결 수락 이후에

VPC Endpoint 생성 시 Private DNS를 바로 활성화하면 DNS 확인이 실패합니다. Provider가 연결을 수락하고 상태가 “Available”이 된 후에 활성화해야 정상 작동합니다. 온보딩 가이드에 명시해도 놓치는 경우가 있어서, 체크리스트에 순서를 명확히 표시해 두는 것이 좋습니다.

보안 그룹은 양쪽 모두 확인

연결 문제의 대부분은 네트워크 설정입니다. Provider와 Consumer 양쪽 모두 확인이 필요합니다.

Client 측에서는 VPC Endpoint ENI의 보안 그룹이 내부 클라이언트의 트래픽을 받을 수 있어야 합니다. Provider 측에서는 NLB Target(Kubernetes Node 등)이 VPC Endpoint에서 오는 트래픽을 허용해야 합니다.