Private Endpoint vs Service Endpoint: 출발지를 바꾸느냐 목적지를 바꾸느냐

Azure Private Endpoint와 Service Endpoint 네트워크 보안 비교

Azure Storage나 SQL Database 같은 PaaS 서비스는 기본적으로 공용 인터넷 엔드포인트를 가집니다. 키만 있으면 어디서든 접근 가능하다는 뜻입니다. 이걸 막는 방법이 Service Endpoint와 Private Endpoint인데, 이름이 비슷해서 자주 혼동됩니다.

둘의 차이는 한 줄로 요약됩니다. Service Endpoint는 “누가 접근하는지”를 바꾸고, Private Endpoint는 “어디로 접근하는지”를 바꿉니다. 이 차이가 실무에서 어떤 결과를 만드는지 정리하겠습니다.

동작 방식의 근본적 차이

Service Endpoint — 출발지를 바꾼다

[ VM in Subnet A ]
     │  출발지 IP를 공인 IP가 아닌
     │  "VNet/서브넷 식별자"로 표시
     ▼
[ Azure 백본 네트워크 ]
     ▼
[ Storage 공용 엔드포인트 ]     ← 주소는 그대로 공용
  stprod.blob.core.windows.net
  (방화벽에서 "이 서브넷만 허용" 판단)

핵심은 대상의 주소가 바뀌지 않는다는 점입니다. 여전히 stprod.blob.core.windows.net이라는 공용 DNS 이름으로 접근하고, 공용 IP로 해석됩니다. 다만 트래픽이 Azure 백본을 타고 가며, 스토리지 방화벽이 “이 서브넷에서 온 것”임을 알아보고 허용합니다.

Private Endpoint — 사설 IP를 만든다

[ VM in Subnet A ]
     │
     ▼
[ Private Endpoint NIC ]        ← 내 VNet 안의 사설 IP
  10.10.1.5                        (예: 10.10.1.5)
     │  Private Link
     ▼
[ Storage 계정 ]                ← 공용 엔드포인트는 차단 가능

DNS:
  stprod.blob.core.windows.net
    → privatelink.blob.core.windows.net
      → 10.10.1.5  (사설 DNS 영역이 해석)

스토리지 계정이 내 VNet 안에 사설 IP로 존재하게 됩니다. 공용 엔드포인트를 완전히 차단해도 접근이 됩니다. 그리고 온프레미스에서 VPN·ExpressRoute를 타고 들어와도 같은 사설 IP로 접근할 수 있습니다.

비교표

	Service Endpoint	Private Endpoint
대상 주소	공용 IP 그대로	내 VNet의 사설 IP
공용 엔드포인트	열려 있음 (방화벽으로 제한)	완전 차단 가능
비용	무료	엔드포인트당 시간 요금 + 데이터
온프레미스에서 접근	불가	가능
피어링된 VNet에서	불가 (서브넷 단위)	가능
DNS 설정	불필요	사설 DNS 영역 필요
적용 단위	서브넷 → 서비스 종류	리소스 개별
데이터 유출 방지	약함	강함

마지막 행을 설명해야 합니다. Service Endpoint를 켜도 같은 서비스의 다른 계정으로는 나갈 수 있습니다. 즉 내부자가 데이터를 자기 개인 스토리지 계정으로 복사하는 걸 막지 못합니다. Private Endpoint는 지정한 리소스로만 사설 경로가 생기므로 이 시나리오를 차단합니다.

규제 산업에서 Private Endpoint를 요구하는 이유가 대개 여기에 있습니다.

Service Endpoint 구성 — 5분이면 끝난다

#!/usr/bin/env bash
set -euo pipefail
RG="rg-prod-network"; VNET="vnet-prod-krc-01"; SUBNET="snet-app"
ST="stprodkrc01"; STRG="rg-prod-data"

# 1) 서브넷에 서비스 엔드포인트 활성화
az network vnet subnet update \
  --name "$SUBNET" --vnet-name "$VNET" -g "$RG" \
  --service-endpoints Microsoft.Storage Microsoft.Sql

# 2) 스토리지 방화벽에서 해당 서브넷만 허용
SUBNET_ID=$(az network vnet subnet show \
  --name "$SUBNET" --vnet-name "$VNET" -g "$RG" --query id -o tsv)

az storage account network-rule add \
  --account-name "$ST" -g "$STRG" --subnet "$SUBNET_ID"

# 3) 기본 동작을 거부로 변경 (이걸 안 하면 의미 없음)
az storage account update \
  --name "$ST" -g "$STRG" --default-action Deny

3번을 빠뜨리는 실수가 흔합니다. 기본 동작이 Allow로 남아 있으면 규칙을 추가해도 여전히 전 세계에서 접근 가능합니다. 허용 규칙만 넣고 안심하는 경우가 많습니다.

Deny로 바꾸기 전에 내 IP도 추가해두세요. 안 그러면 포털에서 Blob 목록도 못 봅니다.

az storage account network-rule add \
  --account-name "$ST" -g "$STRG" --ip-address "$(curl -s ifconfig.me)"

Private Endpoint 구성 — DNS가 전부다

Private Endpoint에서 실패의 90%는 DNS 문제입니다. 엔드포인트 자체는 잘 만들어졌는데 이름이 여전히 공용 IP로 해석되어 접근이 안 되는 상황입니다.

# 1) 사설 엔드포인트 생성
ST_ID=$(az storage account show --name "$ST" -g "$STRG" --query id -o tsv)

az network private-endpoint create \
  --name pe-stprod-blob -g "$RG" \
  --vnet-name "$VNET" --subnet "snet-pe" \
  --private-connection-resource-id "$ST_ID" \
  --group-id blob \
  --connection-name "conn-stprod-blob"

# 2) 사설 DNS 영역 생성 (서비스마다 이름이 정해져 있음)
az network private-dns zone create \
  -g "$RG" --name "privatelink.blob.core.windows.net"

# 3) VNet에 연결 (자동 등록은 끔)
az network private-dns link vnet create \
  -g "$RG" --zone-name "privatelink.blob.core.windows.net" \
  --name link-vnet-prod --virtual-network "$VNET" \
  --registration-enabled false

# 4) 엔드포인트를 DNS 영역에 연결 - 이 단계가 핵심
az network private-endpoint dns-zone-group create \
  -g "$RG" --endpoint-name pe-stprod-blob \
  --name default \
  --private-dns-zone "privatelink.blob.core.windows.net" \
  --zone-name blob

4번을 빼먹으면 DNS 레코드가 자동 생성되지 않습니다. 사설 엔드포인트는 만들어졌지만 이름 해석이 안 되어, VM에서 접속하면 여전히 공용 IP로 갑니다. 그리고 공용 접근을 차단해뒀다면 그대로 연결 실패입니다.

서비스별 DNS 영역 이름은 정해져 있고, 틀리면 동작하지 않습니다. 자주 쓰는 것들입니다.

서비스	`group-id`	사설 DNS 영역
Blob Storage	`blob`	`privatelink.blob.core.windows.net`
File Storage	`file`	`privatelink.file.core.windows.net`
Azure SQL	`sqlServer`	`privatelink.database.windows.net`
Key Vault	`vault`	`privatelink.vaultcore.azure.net`
ACR	`registry`	`privatelink.azurecr.io`
Cosmos DB	`Sql`	`privatelink.documents.azure.com`

스토리지 계정은 하위 서비스마다 별도의 엔드포인트가 필요하다는 점도 주의하세요. Blob과 File을 둘 다 쓰면 엔드포인트를 두 개 만들어야 하고, 요금도 두 배입니다.

DNS 해석 검증

# VM 안에서 실행 - 사설 IP로 해석되어야 정상
nslookup stprodkrc01.blob.core.windows.net

# 기대 결과:
#   stprodkrc01.blob.core.windows.net
#     canonical name = stprodkrc01.privatelink.blob.core.windows.net
#   Address: 10.10.2.4          ← 사설 IP면 정상
#
# 공인 IP(20.x.x.x 등)가 나오면 DNS 영역 연결이 안 된 것

# 실제 연결 확인
nc -zv stprodkrc01.blob.core.windows.net 443

온프레미스에서 접근해야 한다면 여기서 추가 작업이 필요합니다. 온프레미스 DNS 서버는 Azure 사설 DNS 영역을 모르기 때문에, DNS 전달자(forwarder)를 VNet 안에 두거나 Azure DNS Private Resolver를 구성해야 합니다. 이 부분을 간과하면 “Azure VM에서는 되는데 사무실에서는 안 되는” 상황이 됩니다.

무엇을 선택할 것인가

상황	선택
Azure VNet 안에서만 쓰고, 비용을 아끼고 싶다	Service Endpoint
온프레미스에서도 접근해야 한다	Private Endpoint
공용 엔드포인트를 완전히 차단해야 한다 (규정)	Private Endpoint
데이터 유출 경로까지 막아야 한다	Private Endpoint
피어링된 여러 VNet에서 공유한다	Private Endpoint
개발·테스트 환경	Service Endpoint (또는 IP 제한)

실무에서 흔한 접근은 Service Endpoint로 시작해서, 필요한 리소스만 Private Endpoint로 올리는 방식입니다. Service Endpoint는 무료이므로 켜두는 데 부담이 없고, 민감한 데이터가 있는 스토리지·DB만 Private Endpoint로 전환합니다.

비용 감각을 위해 덧붙이면, Private Endpoint는 엔드포인트 개수만큼 시간당 요금이 붙습니다. 스토리지 계정 10개에 Blob·File 각각 연결하면 엔드포인트가 20개입니다. 리소스가 많은 환경에서는 무시하기 어려운 금액이 됩니다. 비용 급증 원인 찾기에서 다룬 것처럼, 도입 후 Cost Analysis에서 확인해보시길 권합니다.

전환 시 순서 (서비스 중단 없이)

운영 중인 스토리지를 Private Endpoint로 바꿀 때는 순서가 중요합니다. 순서를 틀리면 서비스가 끊깁니다.

Private Endpoint를 먼저 만든다 (공용 접근은 아직 열어둔 채)
사설 DNS 영역 연결까지 완료하고 nslookup으로 사설 IP 해석 확인
애플리케이션에서 실제로 연결되는지 검증
온프레미스·CI 파이프라인 등 다른 접근 경로도 전부 확인
그 다음에 공용 접근 차단

# 5단계: 마지막에 공용 접근 차단
az storage account update \
  --name stprodkrc01 -g rg-prod-data \
  --public-network-access Disabled

4번을 특히 놓치기 쉽습니다. 배포 파이프라인이 스토리지에 아티팩트를 올리고 있었다면 공용 접근을 막는 순간 배포가 실패합니다. GitHub Actions의 호스팅 러너는 Azure VNet 밖에 있기 때문입니다. 이 경우 자체 호스팅 러너를 VNet 안에 두거나, 파이프라인 IP를 예외 처리해야 합니다.

정리

Service Endpoint는 출발지를, Private Endpoint는 목적지 주소를 바꾼다
Service Endpoint는 무료이므로 기본으로 켜둘 만하다
단, --default-action Deny까지 해야 실제로 막힌다
Private Endpoint는 DNS 영역 그룹 연결(4단계)이 빠지면 동작하지 않는다
온프레미스 접근이 필요하면 DNS 전달자를 별도로 구성한다
전환은 엔드포인트 먼저, 공용 차단은 마지막 순서로

네트워크 통제 전반은 NSG·Firewall·WAF 비교를, 관리 접근 경로는 Bastion으로 22번 포트 닫기를 함께 보시면 인바운드·아웃바운드·데이터 평면이 모두 정리됩니다.