Azure Private Endpoint란 무엇인가: PaaS를 VNet 내부 IP로 안전하게 연결하기

Azure Private Endpoint란 무엇인가: PaaS를 VNet 내부 IP로 안전하게 연결하기

2026. 5. 30. 09:03ㆍ카테고리 없음

Private Endpoint는 Azure PaaS 서비스(Storage, SQL Database 등)에 VNet 내부 사설 IP로 접근하게 해주는 네트워크 인터페이스입니다. 트래픽이 공용 인터넷을 경유하지 않으므로 데이터 노출 위험을 줄일 수 있습니다.

핵심 요약

Private Endpoint는 Azure PaaS 서비스를 VNet 내부의 사설 IP 주소로 매핑하는 네트워크 인터페이스(NIC)입니다.
트래픽은 Azure 백본 네트워크 안의 Private Link를 통해 전달되며, 공용 인터넷을 경유하지 않습니다.
Service Endpoint와 달리, PaaS 서비스에 VNet 내부 사설 IP가 부여되고 온프레미스에서도 접근할 수 있습니다.
정상 동작을 위해서는 Private DNS 연동이 핵심입니다. DNS 설정을 빠뜨리면 여전히 공용 IP로 연결됩니다.
Private Endpoint는 시간당 + 데이터 처리량당 과금되므로, 접근 대상과 트래픽 규모를 고려해 설계합니다.

1. 왜 Private Endpoint가 필요한가

Azure Storage 계정이나 Azure SQL Database를 만들면 기본적으로 공용 엔드포인트(public endpoint)가 생성됩니다. 예를 들어 Storage는 mystorage.blob.core.windows.net 같은 공용 FQDN을 가지며, 이 주소는 공용 IP로 해석됩니다.

이 상태에서는 다음 문제가 생길 수 있습니다.

VNet 안의 VM이 Storage에 접근할 때도 트래픽이 공용 엔드포인트를 향합니다.
방화벽 규칙으로 IP를 제한하더라도, 서비스 자체는 인터넷에 노출된 표면(attack surface)을 가집니다.
규제 산업(금융, 의료)에서는 "PaaS 트래픽이 공용 인터넷을 경유하지 않을 것"을 요구하는 경우가 있습니다.

방화벽(Storage firewall)이나 Service Endpoint로 어느 정도 통제할 수 있지만, 서비스의 공용 FQDN과 공용 IP 자체는 그대로 남습니다. Private Endpoint는 이 PaaS 서비스를 아예 VNet 내부의 사설 IP로 끌어와서, 접근 경로를 사설 네트워크로 바꾸는 방식입니다.

2. Private Endpoint란 무엇인가

Private Endpoint는 Azure Private Link 기술을 사용해 PaaS 서비스를 VNet의 Subnet 안에 사설 IP를 가진 네트워크 인터페이스(NIC)로 노출시키는 리소스입니다.

핵심 특성:

특성	설명
형태	VNet Subnet 안에 생성되는 NIC. 사설 IP 1개 이상을 점유
연결 대상	Storage, SQL Database, Key Vault, Cosmos DB 등 Private Link 지원 PaaS
트래픽 경로	Azure 백본 내 Private Link. 공용 인터넷 미경유
접근 범위	같은 VNet, Peered VNet, VPN/ExpressRoute로 연결된 온프레미스
방향	인바운드 전용(서비스로의 접근). 아웃바운드는 제공하지 않음

여기서 헷갈리기 쉬운 용어를 먼저 구분합니다.

Private Link: PaaS를 사설로 연결하는 기술/플랫폼 전체를 가리키는 개념입니다.
Private Endpoint: 그 기술을 소비하는 쪽에서 만드는 실제 리소스(NIC)입니다.
Private Link Service: 직접 만든 서비스(Standard Load Balancer 뒤)를 다른 테넌트에 사설로 제공할 때 사용하는, 공급자 쪽 리소스입니다.

이 글에서는 대부분의 실무에서 사용하는 "PaaS를 소비하는 쪽의 Private Endpoint"를 중심으로 설명합니다.

3. 핵심 구성 요소

Private Endpoint를 구성하는 요소는 다음과 같습니다.

구성 요소	역할
Private Endpoint (NIC)	Subnet 안에서 사설 IP를 점유하는 네트워크 인터페이스
Private Link	Endpoint와 PaaS 서비스를 Azure 백본에서 연결하는 경로
연결 대상 리소스 (sub-resource)	어떤 서비스의 어떤 부분에 연결할지 지정 (예: Storage의 blob, file)
Private DNS Zone	공용 FQDN을 사설 IP로 해석하도록 매핑하는 DNS 영역
연결 승인 상태	같은 구독은 자동 승인, 다른 구독/테넌트는 수동 승인 필요

여기서 sub-resource(연결 대상) 개념이 중요합니다. 하나의 Storage 계정에도 blob, file, queue, table, dfs 등 여러 서비스가 있습니다. Private Endpoint는 이 중 무엇에 연결할지 지정해야 하며, blob과 file을 모두 사설로 쓰려면 각각 Private Endpoint를 만들어야 합니다.

Tip
Private Endpoint는 Subnet의 사설 IP를 소비합니다. 여러 PaaS 서비스를 사설로 연결하는 환경에서는 IP가 빠르게 소진될 수 있으므로, Private Endpoint 전용 Subnet을 충분한 크기로 분리하는 설계를 검토할 수 있습니다.

4. 동작 원리: DNS가 핵심이다

Private Endpoint에서 가장 자주 발생하는 문제는 "Endpoint는 만들었는데 여전히 공용 IP로 연결되는" 상황입니다. 원인은 거의 대부분 DNS입니다.

4.1 CNAME 체인 이해하기

Private Endpoint를 만들면 서비스의 공용 FQDN에 CNAME이 추가됩니다. Storage(blob)를 예로 들면 해석 과정은 다음과 같습니다.

mystorage.blob.core.windows.net
   └─(CNAME)→ mystorage.privatelink.blob.core.windows.net
                 └─(A 레코드)→ 10.0.1.4   (Private Endpoint 사설 IP)

애플리케이션은 코드 변경 없이 기존 FQDN(mystorage.blob.core.windows.net)을 그대로 사용합니다. 다만 privatelink.* 영역의 A 레코드가 사설 IP로 해석되어야 사설 경로로 연결됩니다.

4.2 Private DNS Zone 연동

이 A 레코드 해석을 위해 Private DNS Zone이 필요합니다. 서비스마다 정해진 영역 이름을 사용합니다.

서비스	Private DNS Zone 이름
Blob Storage	privatelink.blob.core.windows.net
File Storage	privatelink.file.core.windows.net
Azure SQL Database	privatelink.database.windows.net
Key Vault	privatelink.vaultcore.azure.net
Cosmos DB (SQL API)	privatelink.documents.azure.com

연동 과정은 다음과 같습니다.

해당 이름의 Private DNS Zone을 생성합니다.
이 Zone을 VNet에 Virtual Network Link로 연결합니다.
Private Endpoint 생성 시 "Private DNS와 통합" 옵션을 켜면 A 레코드가 자동 등록됩니다.

주의
VNet에 Private DNS Zone을 연결하지 않으면, VNet 내부에서도 공용 FQDN이 공용 IP로 해석됩니다. Endpoint는 정상이지만 트래픽은 사설 경로를 타지 않습니다. 온프레미스에서 접근하는 경우에는 DNS Forwarder나 Azure DNS Private Resolver를 통해 Azure DNS로 질의를 전달하는 추가 설계가 필요합니다.

4.3 연결 승인

Private Endpoint가 같은 구독의 리소스를 향하면 연결이 자동 승인됩니다. 다른 구독이나 다른 테넌트의 서비스에 연결할 때는 리소스 소유자가 수동으로 승인해야 활성화됩니다. 이 승인 흐름 덕분에 서비스 제공자가 누가 사설로 접근하는지 통제할 수 있습니다.

5. Private Endpoint vs Service Endpoint

Azure에서 PaaS 트래픽을 사설 경로로 보내는 방법은 Private Endpoint 외에 Service Endpoint도 있습니다. 둘은 목적이 비슷해 보이지만 동작 방식이 다릅니다.

azure-private-endpoint-vs-service-endpoint

기준	Private Endpoint	Service Endpoint
접근 방식	PaaS에 VNet 내부 사설 IP 부여	VNet의 신원으로 PaaS 공용 엔드포인트 접근
트래픽 경로	Azure 백본 내 Private Link	Azure 백본(공용 IP는 유지)
대상 IP	사설 IP (예: 10.0.1.4)	서비스의 공용 IP
온프레미스 접근	VPN/ExpressRoute로 가능	불가능 (VNet 리소스만)
데이터 유출 방지	서비스 단위로 세밀하게 제한	Subnet 단위 허용
비용	Endpoint 시간당 + 데이터 처리 과금	추가 비용 없음
DNS 변경	필요 (Private DNS 연동)	불필요

핵심 차이는 "공용 IP가 남는가"입니다. Service Endpoint는 트래픽 경로를 최적화하지만 서비스의 공용 엔드포인트는 그대로 존재합니다. 반면 Private Endpoint는 사설 IP를 부여해 공용 노출 자체를 제거할 수 있습니다.

선택 기준을 정리하면 다음과 같습니다.

온프레미스에서 PaaS에 사설로 접근해야 한다면 Private Endpoint를 검토합니다.
공용 엔드포인트를 완전히 비활성화해야 하는 규제 요건이 있다면 Private Endpoint가 적합합니다.
비용을 최소화하면서 VNet 내부 트래픽만 최적화하면 되는 경우라면 Service Endpoint로 충분할 수 있습니다.

Security Note
Private Endpoint를 만들어도 PaaS 서비스의 공용 엔드포인트가 자동으로 닫히지는 않습니다. 사설 접근만 허용하려면 서비스 방화벽에서 "공용 네트워크 접근 거부(Public network access: Disabled)"를 별도로 설정해야 합니다. 이 설정을 빠뜨리면 사설 경로와 공용 경로가 동시에 열려 있게 됩니다.

6. 실무 사용 사례

사례 1: 3-Tier 웹 서비스에서 DB와 Storage 격리

가장 흔한 구성입니다. App 계층의 VM 또는 App Service가 Azure SQL Database와 Blob Storage에 접근하는 구조입니다.

app-subnet: 애플리케이션 워크로드
pe-subnet: Private Endpoint 전용 Subnet (SQL용, Blob용 각각 생성)
SQL과 Storage 모두 공용 네트워크 접근을 비활성화

이 구조를 선택하는 이유:

DB와 Storage가 사설 IP만 가지므로, 인터넷에서 직접 접근할 수 있는 표면이 사라집니다.
App 계층은 코드 변경 없이 기존 FQDN을 그대로 사용합니다. DNS만 사설로 해석됩니다.
NSG를 Private Endpoint Subnet에 적용해 어떤 워크로드가 DB에 접근하는지 추가로 통제할 수 있습니다.

사례 2: 온프레미스에서 Azure Storage로 사설 접근

하이브리드 환경에서 온프레미스 백업 서버가 Azure Blob Storage에 데이터를 올려야 한다고 가정합니다.

ExpressRoute 또는 Site-to-Site VPN으로 VNet과 온프레미스를 연결합니다.
Blob용 Private Endpoint를 VNet에 생성합니다.
온프레미스 DNS가 privatelink.blob.core.windows.net 질의를 Azure DNS(또는 DNS Private Resolver)로 포워딩하도록 설정합니다.

이 경우 온프레미스 → ExpressRoute → Private Endpoint 사설 IP 경로로 트래픽이 흐르고, 공용 인터넷을 거치지 않습니다. Service Endpoint로는 불가능한 구성입니다.

사례 3: Hub-Spoke에서 Private DNS 중앙 관리

여러 Spoke VNet이 같은 PaaS에 접근하는 대규모 환경입니다. Private DNS Zone을 Spoke마다 만들면 관리가 어렵습니다.

Private DNS Zone을 Hub에 1개만 생성하고, 모든 Spoke VNet을 이 Zone에 Virtual Network Link로 연결합니다.
Private Endpoint는 워크로드에 가까운 Spoke 또는 Hub에 배치합니다.
이렇게 하면 DNS 레코드를 중앙에서 일괄 관리할 수 있습니다.

7. 비용/운영 고려사항

주의
Private Endpoint는 생성 시점부터 시간당 과금되며, 통과하는 데이터에도 과금됩니다. 사용하지 않는 Endpoint를 방치하면 비용이 누적될 수 있습니다.

공식 Pricing 페이지 기준 과금 구조는 다음과 같습니다. (리전/통화에 따라 변동될 수 있으므로 최신 가격은 공식 페이지에서 확인하는 것을 권장합니다.)

항목	과금
Private Endpoint	시간당 약 $0.01
Inbound 데이터 처리	GB당 약 $0.01 (0~1 PB 구간)
Outbound 데이터 처리	GB당 약 $0.01 (0~1 PB 구간)
Private Link Service (공급자 측)	추가 비용 없음
Private DNS Zone	호스팅 + 질의량 기준 별도 과금

운영 관점:

Private Endpoint는 sub-resource 단위로 만들어야 하므로 개수가 빠르게 늘 수 있습니다. blob + file + SQL을 각각 사설로 쓰면 Endpoint 3개입니다.
DNS 설정 누락이 가장 흔한 장애 원인입니다. Endpoint 생성 시 Private DNS 통합 옵션을 함께 적용하는 것을 표준 절차로 두는 것이 좋습니다.
Private Endpoint NIC는 Subnet의 IP를 점유합니다. Endpoint가 많아질수록 IP 계획에 영향을 줍니다.
데이터 처리량이 매우 큰 워크로드라면 데이터 처리 과금이 누적되므로, 트래픽 규모를 사전에 추정하는 것이 좋습니다.

8. 자주 하는 실수

DNS 연동을 빠뜨리는 것: Endpoint만 만들고 Private DNS Zone을 VNet에 연결하지 않으면, 여전히 공용 IP로 해석됩니다. 가장 흔한 실수입니다.
공용 엔드포인트를 닫지 않는 것: Private Endpoint를 만들어도 서비스의 공용 접근은 기본적으로 열려 있습니다. 사설 전용으로 만들려면 서비스 방화벽에서 공용 접근을 명시적으로 비활성화해야 합니다.
하나의 Private DNS Zone을 서로 다른 서비스에 공유하는 것: 같은 Zone에 서로 다른 Endpoint의 A 레코드가 충돌하면 해석 오류가 발생할 수 있습니다. 서비스별 표준 Zone 이름을 사용해야 합니다.
sub-resource를 혼동하는 것: Storage의 blob에 연결하면 file에는 사설 접근이 적용되지 않습니다. 필요한 sub-resource마다 별도 Endpoint가 필요합니다.
온프레미스 DNS 포워딩을 고려하지 않는 것: 온프레미스에서 접근할 때 Azure Private DNS Zone은 온프레미스에서 직접 보이지 않습니다. DNS Forwarder 또는 Azure DNS Private Resolver를 통한 질의 전달이 필요합니다.
Private Endpoint Subnet에 과도한 정책을 거는 것: 일부 환경에서는 Private Endpoint가 위치한 Subnet의 네트워크 정책 설정을 함께 점검해야 트래픽이 정상적으로 흐릅니다. 설계 시 공식 문서 기준으로 확인하는 것이 좋습니다.

9. 정리

Private Endpoint는 PaaS 서비스를 VNet 내부 사설 IP로 끌어와 공용 인터넷 경유를 제거하는 방식입니다.
동작의 핵심은 DNS입니다. 공용 FQDN → privatelink.* CNAME → 사설 IP A 레코드 체인이 완성되어야 사설 경로로 연결됩니다.
Service Endpoint와 달리 사설 IP가 부여되고 온프레미스 접근이 가능하지만, 시간당/데이터 처리량당 비용이 발생합니다.
사설 전용으로 운영하려면 Private Endpoint 생성 + Private DNS 연동 + 공용 접근 비활성화를 함께 적용해야 합니다.
실무에서는 Private Endpoint 전용 Subnet 분리 + Hub 중앙 DNS 관리가 일반적인 설계 패턴입니다.

Azure VNet이란 무엇인가: Subnet, NSG, Route Table 개념 정리

wero90