Private Application Gateway - 네트워크 격리로 보안/운영성 끌어올리기
해당 글은 Private Application Gateway - 네트워크 격리로 보안/운영성 끌어올리기에 등록된 글입니다.
Private Application Gateway - 네트워크 격리로 보안/운영성 끌어올리기
1. 기존 v2 아키텍처의 한계
Azure의 Application Gateway는 L7(애플리케이션 계층)에서 동작하는 로드 밸런서로, HTTP, HTTPS, HTTP/2, WebSocket 등 다양한 프로토콜을 지원합니다. 이를 통해 URL 기반 라우팅, 리다이렉션, URL rewrite, TLS termination, 세션/쿠키 기반 고정 등 웹 애플리케이션 운영에 필요한 다양한 고급 기능을 제공합니다.
이 Application Gateway는 반드시 특정 리전(Region)과 구독(Subscription) 내에 존재하는 가상 네트워크(VNET)의 전용 서브넷에 배포되어야 합니다. 즉, 하나의 VNET 내에서만 동작하며, 이로 인해 네트워크 경계와 보안이 자연스럽게 강화됩니다.
하지만 기존 v2 아키텍처에서는 몇 가지 구조적인 한계가 있었습니다.
가장 큰 특징은 관리(제어 평면-Control plane) 트래픽과 사용자(데이터 평면 - Data plane) 트래픽이 동일한 퍼블릭 엔드포인트(퍼블릭 IP 주소)를 통해 인입된다는 점입니다. 즉, Azure 관리 시스템(예: ARM, Gateway Manager)에서 설정 변경이나 관리 작업을 할 때도, 실제 사용자가 웹 서비스를 이용할 때도 모두 같은 퍼블릭 IP를 사용하게 됩니다.
이로 인해 다음과 같은 제약이 발생합니다.
- 퍼블릭 IP가 반드시 필요합니다. 프라이빗 IP만으로는 운영이 불가능합니다.
- Azure의 Gateway Manager 등 관리 트래픽을 인바운드로 허용해야 하므로, 네트워크 보안 그룹(NSG)에서 예외 규칙을 추가해야 합니다.
- 관리 트래픽이 퍼블릭 경로를 통해 들어오므로, 인터넷 아웃바운드 트래픽을 완전히 차단할 수 없습니다.
- 기본 라우트(0.0.0.0/0)를 임의로 변경할 수 없습니다. 모든 트래픽이 퍼블릭 경로를 거쳐야 하므로, 네트워크 라우팅 정책에 제약이 생깁니다.
- Azure DNS(168.63.129.16) 사용이 강제됩니다. 별도의 DNS 서버를 지정하거나 커스텀 DNS를 적용하는 데 한계가 있습니다.
이러한 이유로, 기존 v2 아키텍처에서는 보안과 네트워크 정책을 유연하게 적용하는 데 어려움이 있었습니다.
이런 한계를 극복하기 위해 최근에는 네트워크 격리(Network Isolation) 기반의 새로운 아키텍처가 나오게 되었습니다.
2. 새로운 네트워크 격리 아키텍처
새롭게 도입된 네트워크 격리(Network Isolation) 기반의 Application Gateway 아키텍처는 기존과 달리 여러 가지 중요한 변화와 장점을 제공합니다.
가장 큰 변화는 제어 평면 트래픽(관리 트래픽)과 데이터 평면 트래픽(사용자 트래픽)이 완전히 분리된다는 점입니다. 즉, 관리 작업을 위한 트래픽과 실제 서비스 이용을 위한 트래픽이 서로 다른 경로로 처리되기 때문에, 보안과 운영 측면에서 훨씬 더 안전하고 유연한 구성이 가능합니다.
이제는 퍼블릭 IP를 반드시 만들 필요가 없고, 프라이빗 IP만으로도 Application Gateway를 운영할 수 있습니다. 즉, 외부 인터넷에 노출하지 않고도 내부 네트워크에서만 안전하게 서비스를 제공할 수 있습니다.
또한, 네트워크 보안 그룹(NSG)이나 사용자 정의 라우트(UDR) 정책을 활용해 인터넷 아웃바운드 트래픽을 완전히 차단할 수 있습니다. 기존에는 관리 트래픽 때문에 인터넷 차단이 불가능했지만, 이제는 기업의 보안 정책에 맞춰 아웃바운드 트래픽을 자유롭게 제어할 수 있습니다.
기본 라우트(0.0.0.0/0) 역시 자유롭게 변경할 수 있어, 모든 트래픽을 방화벽이나 네트워크 가상 어플라이언스(NVA)로 우회시키는 등 다양한 네트워크 설계가 가능합니다.
DNS 설정도 유연해졌습니다. 기존에는 Azure에서 제공하는 기본 DNS(168.63.129.16)만 사용할 수 있었지만, 이제는 VNET에 지정한 DNS 서버를 사용할 수 있어, 사내 DNS 정책이나 커스텀 네임 해석 환경을 그대로 적용할 수 있습니다.
이러한 네트워크 격리 기능은 현재 GA(General Availability) 상태로, 누구나 사용할 수 있습니다. 다만, 이 기능을 사용하려면 구독 단위로 기능 플래그를 활성화해야 하며, 기능 플래그를 켠 이후에 새로 생성하는 Application Gateway 인스턴스부터 적용됩니다. 이미 만들어진 기존 인스턴스에는 영향을 주지 않으니, 기존 환경을 변경할 필요는 없습니다.
3. 기능 플래그 등록 방법
Azure Application Gateway의 네트워크 격리 기능을 사용하려면, 먼저 Azure Portal에서 기능 플래그를 등록해야 합니다.
등록 방법은 다음과 같습니다.
먼저, Azure Portal에 접속한 후,
- 구독(Subscriptions) 메뉴로 이동합니다.
- 상단의 Preview Features(미리 보기 기능) 탭을 선택합니다.
- 검색창에
"EnableApplicationGatewayNetworkIsolation"을 입력해 해당 기능을 찾습니다.
- 검색 결과에서 해당 항목을 선택한 뒤, Register(등록) 버튼을 클릭하면 기능이 활성화됩니다.
이렇게 기능 플래그를 등록하면, 이후 새롭게 생성하는 Application Gateway 인스턴스부터 네트워크 격리 아키텍처를 적용할 수 있습니다.
즉, 이 플래그는 기존에 만들어진 인스턴스에는 영향을 주지 않고, 오직 새로 만드는 게이트웨이의 아키텍처 결정에만 사용됩니다.
4. 현재 제한 사항 (첨부 기준)
현재 네트워크 격리 아키텍처에서는 Private Endpoint(Private Link) 기능이 아직 지원되지 않습니다. 즉, Application Gateway를 Private Link와 연동해서 사용해야 하는 경우에는, 네트워크 격리 기능 플래그를 활성화하지 않고 기존 아키텍처 방식으로 게이트웨이를 생성해야 합니다.
이 기능은 앞으로 지원이 추가될 예정이며, 만약 Private Link 지원이 공식적으로 제공되면, 별도의 플래그 없이도 네트워크 격리와 Private Link를 함께 사용할 수 있을 것으로 예상됩니다.
따라서 Private Link가 꼭 필요한 환경이라면, 현재로서는 기존 방식으로 배포해야 하며, 향후 업데이트를 주기적으로 확인하시기 바랍니다.
5. 설계 관점 핵심 정리
Application Gateway는 반드시 특정 리전(Region)과 가상 네트워크(VNET) 내의 전용 서브넷에 배치해야 하며, 이때 다른 리소스와 혼합하지 않는 독립 서브넷 구성이 권장됩니다. 이렇게 하면 네트워크 관리와 보안 측면에서 더욱 효율적이고 안전하게 운영할 수 있습니다.
또한, Application Gateway는 동일 VNET뿐만 아니라 피어링된 VNET, VPN, ExpressRoute와 연동된 다양한 네트워크 환경에서도 트래픽을 프록시할 수 있어, 온프레미스와 클라우드, 다양한 네트워크 간의 연결이 가능합니다.
보안 측면에서는 퍼블릭 IP를 제거함으로써 외부에 노출되는 위험을 최소화할 수 있습니다. 외부 인터넷과의 연결을 차단하고, 오직 내부 네트워크에서만 접근하도록 설정할 수 있기 때문에, 기업의 보안 정책을 더욱 강력하게 적용할 수 있습니다.
또한, 네트워크 보안 그룹(NSG)에서 아웃바운드 트래픽을 기본적으로 모두 차단(DenyAll)하고, 사용자 정의 라우트(UDR)를 통해 기본 경로(0.0.0.0/0)를 원하는 대로 재정의함으로써, 데이터가 어떤 경로로 이동하는지 완전히 통제할 수 있습니다.
마지막으로, VNET에 지정한 DNS를 사용할 수 있기 때문에, 이름 풀이(이름→IP 변환) 환경을 조직의 표준에 맞게 일관성 있게 운영할 수 있습니다.
이러한 설계는 보안, 운영 효율성, 네트워크 관리의 모든 측면에서 큰 장점을 제공합니다.
6. 아키텍처 개념도
(A) 기존 v2 (공유 퍼블릭 엔드포인트)
1
2
[사용자] ──(Internet/공용)──▶ [App GW (Public IP)] ─▶ [백엔드]
[Azure 관리(ARM/Gateway Manager)] ───(동일 Public IP)──▶ [App GW]
기존 v2 아키텍처에서는 Application Gateway가 퍼블릭 IP를 반드시 사용해야 했습니다.
이 구조에서는 실제 웹 서비스를 이용하는 사용자 트래픽과 Azure 관리 시스템(예: ARM, Gateway Manager)에서 들어오는 관리 트래픽이 모두 동일한 퍼블릭 엔드포인트(퍼블릭 IP 주소)를 통해 게이트웨이에 접근하게 됩니다.
즉,
- 일반 사용자는 인터넷이나 공용 네트워크를 통해 퍼블릭 IP로 접근하고,
- Azure의 관리 트래픽 역시 같은 퍼블릭 IP를 통해 설정 변경이나 관리 작업을 수행합니다.
이처럼 관리 트래픽과 사용자 트래픽이 동일한 네트워크 경로(퍼블릭 IP)를 공유하기 때문에,
- 퍼블릭 IP를 반드시 생성해야 하고,
- 인터넷 아웃바운드 트래픽을 완전히 차단하는 것이 사실상 불가능합니다.
결과적으로, 보안 정책을 엄격하게 적용하거나 네트워크를 완전히 내부로만 제한하고 싶은 환경에서는 한계가 있었습니다.
이러한 구조적 제약을 해결하기 위해 최근에는 네트워크 격리 기반의 새로운 아키텍처가 도입되고 있습니다.
(B) 네트워크 격리(Private-only 가능)
1
2
[사용자(내부/VPN/ER/피어링)] ──(Private)──▶ [App GW (Private-only)]
└──▶ [백엔드: VM/VMSS/App Service/FQDN...]
네트워크 격리(Private-only) 아키텍처에서는 Application Gateway가 퍼블릭 IP 없이 오직 프라이빗 IP만으로도 배포 및 운영이 가능합니다.
이 구조에서는 내부 사용자, VPN, ExpressRoute(ER), 또는 피어링된 VNET에서만 Application Gateway에 접근할 수 있습니다. 즉, 외부 인터넷에서 직접 접근하는 것이 불가능하며, 오직 조직 내부 네트워크를 통해서만 트래픽이 흐르게 됩니다.
이 아키텍처의 가장 큰 특징은 제어 평면 트래픽(관리 트래픽)과 데이터 평면 트래픽(사용자 트래픽)이 완전히 분리된다는 점입니다.
관리 작업과 실제 서비스 트래픽이 서로 다른 경로로 처리되기 때문에, 보안과 네트워크 정책을 더욱 엄격하게 적용할 수 있습니다.
특히,
- 퍼블릭 IP를 선택적으로 사용할 수 있고,
- 네트워크 보안 그룹(NSG)에서 아웃바운드 트래픽을 모두 차단(DenyAll)할 수 있으며,
- 기본 라우트(0.0.0.0/0)도 자유롭게 재정의할 수 있습니다.
이러한 구조 덕분에, 기업은 데이터 유출 위험을 최소화하고, 네트워크 경로를 완전히 통제할 수 있으며, 보안 및 컴플라이언스 요구사항을 더욱 쉽게 충족할 수 있습니다.
즉, 네트워크 격리 아키텍처는 보안과 운영 효율성을 모두 강화하는 현대적인 인프라 설계 방식입니다.
7. 도입 체크리스트
네트워크 격리 기반의 Application Gateway를 도입하려면 몇 가지 중요한 사항들을 준비해야 합니다.
먼저, 구독(Subscription) 단위로 기능 플래그를 등록해야 합니다. Azure Portal에서 ‘Enable application gateway network isolation’ 기능을 찾아 등록(Registered 상태)하면, 이후부터 네트워크 격리 아키텍처를 사용할 수 있습니다.
다음으로, 서브넷 계획이 필요합니다. Application Gateway는 반드시 전용 서브넷에 배치해야 하며, 다른 리소스와 혼합해서 사용하는 것은 권장되지 않습니다. 이렇게 하면 네트워크 관리와 보안 측면에서 더욱 효율적이고 안전하게 운영할 수 있습니다.
또한, NSG(네트워크 보안 그룹)와 UDR(사용자 정의 라우트) 정책을 수립해야 합니다. 네트워크 보안 그룹에서는 아웃바운드 트래픽을 기본적으로 모두 차단(DenyAll)하고, 사용자 정의 라우트를 통해 기본 경로(0.0.0.0/0)를 방화벽이나 네트워크 가상 어플라이언스(NVA)로 우회시키는 등, 조직의 보안 정책에 맞게 네트워크 경로를 설계할 수 있습니다.
DNS 전략도 중요합니다. VNET에 지정한 DNS를 사용하면, 내부 네임 해석 환경을 조직의 표준에 맞게 일관성 있게 운영할 수 있습니다. 그리고, 제한 사항도 반드시 확인해야 합니다. 첨부 기준으로는 Private Link(Private Endpoint) 기능이 아직 지원되지 않으므로, 이 기능이 꼭 필요한 경우에는 기존 아키텍처를 사용해야 합니다.
마지막으로, 이 기능 플래그는 새롭게 생성하는 Application Gateway 인스턴스에만 적용되며, 기존에 이미 만들어진 인스턴스에는 영향을 주지 않습니다. 따라서 기존 환경을 변경할 필요는 없고, 새 인스턴스 배포 시에만 적용된다는 점을 기억해야 합니다.
8. Use case & 기대효과
내부 업무 포털이나 LOB(Line of Business) 시스템과 같은 경우에는, 외부 인터넷에 노출하지 않고 오직 사내 네트워크나 하이브리드 환경(VPN, ExpressRoute 등)에서만 접근할 수 있도록 구성하는 것이 중요합니다. 이러한 환경에서는 보안과 컴플라이언스 요구사항이 높기 때문에, 네트워크 격리 기반의 Application Gateway가 매우 적합합니다.
또한, 하이브리드 트래픽 중재가 필요한 경우에도 효과적입니다. 예를 들어, 온프레미스와 클라우드 간에 VPN이나 ExpressRoute를 통해 트래픽이 오갈 때, Application Gateway를 통해 L7(애플리케이션 계층) 정책을 적용하여 트래픽을 세밀하게 제어할 수 있습니다. 이를 통해 URI 기반 라우팅, TLS termination, redirection 등 다양한 보안 및 운영 정책을 구현할 수 있습니다.
마지막으로, 데이터 유출 통제 측면에서도 큰 장점이 있습니다. 네트워크 보안 그룹(NSG)과 사용자 정의 라우트(UDR)를 활용해 아웃바운드 트래픽을 기본적으로 모두 차단(DenyAll)하고, 꼭 필요한 경로에만 예외적으로 트래픽을 허용함으로써, 데이터가 외부로 유출되는 위험을 최소화할 수 있습니다.
이처럼 네트워크 격리 기반의 Application Gateway는 내부 시스템 보호, 하이브리드 환경의 트래픽 관리, 데이터 유출 방지 등 다양한 기업 요구사항을 효과적으로 충족시킬 수 있습니다.
9. 마이그레이션 관점
마이그레이션(이전) 관점에서 보면, 네트워크 격리 기능 플래그는 새롭게 생성하는 Application Gateway 인스턴스에만 적용됩니다.
즉, 이미 기존에 만들어져 운영 중인 Application Gateway에는 이 기능이 자동으로 적용되지 않으므로, 기존 인스턴스의 동작에는 아무런 영향이 없습니다.
만약 기존 워크로드를 네트워크 격리 아키텍처로 전환하고 싶다면, 기존 인스턴스를 그대로 변경하는 것이 아니라,
- 새로운 Application Gateway 인스턴스를 생성해서
- 기존 워크로드를 점진적으로 이전하거나
- 이중화(Active-Active) 구조로 전환한 뒤
- 충분히 검증 후 기존 인스턴스를 제거하는 방식으로 마이그레이션을 진행해야 합니다.
이렇게 하면 서비스 중단 없이 안전하게 새로운 아키텍처로 이전할 수 있습니다.
즉, 네트워크 격리 기능은 기존 환경을 건드리지 않고, 새롭게 설계·배포하는 인프라에만 적용된다는 점을 꼭 기억해야 합니다.
10. 핵심 요약
기존의 Application Gateway v2 아키텍처에서는 반드시 퍼블릭 IP를 사용해야 했고, 관리 트래픽과 사용자 트래픽이 모두 퍼블릭 엔드포인트를 통해 들어왔기 때문에 인터넷 아웃바운드 트래픽을 완전히 차단할 수 없었습니다. 또한, DNS 역시 Azure에서 제공하는 기본 DNS(168.63.129.16)만 사용할 수 있어 네임 해석 환경을 자유롭게 구성하기 어려웠습니다.
반면, 네트워크 격리(Network Isolation) 기반의 새로운 아키텍처에서는 퍼블릭 IP를 선택적으로 사용할 수 있고, 필요하다면 프라이빗 IP만으로도 운영이 가능합니다. 이로 인해 아웃바운드 트래픽을 완전히 차단할 수 있으며, 기본 라우트(0.0.0.0/0)도 자유롭게 변경할 수 있습니다. 또한, VNET에 지정한 DNS를 사용할 수 있어 조직의 네임 해석 정책을 그대로 적용할 수 있습니다.
이 네트워크 격리 기능은 현재 GA 상태로, 구독 단위로 기능 플래그를 등록한 후 새롭게 생성하는 Application Gateway 인스턴스부터 적용됩니다. 기존에 이미 만들어진 인스턴스에는 영향을 주지 않습니다.
단, 첨부 기준으로는 Private Endpoint(Private Link) 기능이 아직 지원되지 않으므로, 이 기능이 꼭 필요한 경우에는 기존 아키텍처 방식을 사용해야 합니다.
이처럼 네트워크 격리 기반의 Application Gateway는 보안, 네트워크 설계, 운영 효율성 측면에서 기존 방식보다 훨씬 더 유연하고 강력한 인프라 환경을 제공합니다.
11. 참고 문서
- 2025년 9월 12일 작성 함. (by JYSEONG(MSFT) / GitHub)