Application Gateway 인프라 구성
Azure Application Gateway 인프라에는 가상 네트워크, 서브넷, NSG(네트워크 보안 그룹) 및 UDR(사용자 정의 경로)가 포함됩니다.
가상 네트워크 및 전용 서브넷
애플리케이션 게이트웨이는 가상 네트워크에서 전용 배포입니다. 가상 네트워크 내에는 애플리케이션 게이트웨이에 대한 전용 서브넷이 필요합니다. 특정 Application Gateway 배포의 인스턴스를 서브넷에 여러 개 포함할 수 있습니다. 또한 서브넷에 다른 애플리케이션 게이트웨이를 배포할 수도 있습니다. 그러나 Application Gateway 서브넷에 다른 리소스를 배포할 수 없습니다. 동일한 서브넷에서 v1 및 v2 Application Gateway SKU를 혼합할 수 없습니다.
참고 항목
가상 네트워크 서비스 엔드포인트 정책은 현재 Application Gateway 서브넷에서 지원되지 않습니다.
서브넷 크기
Application Gateway는 인스턴스당 하나의 개인 IP 주소를 사용하고 프라이빗 프런트 엔드 IP가 구성된 경우 또 다른 개인 IP 주소를 사용합니다.
Azure는 또한 내부용으로 각 서브넷에 5개의 IP 주소를 예약합니다. 처음 4개의 IP 주소와 마지막 IP 주소가 여기에 해당합니다. 예를 들어 프라이빗 프런트 엔드 IP가 없는 15개의 Application Gateway 인스턴스를 고려합니다. 이 서브넷에는 20개 이상의 IP 주소가 필요합니다. 내부용으로 5개, Application Gateway 인스턴스용으로 15개가 필요합니다.
27개의 Application Gateway 인스턴스와 프라이빗 프런트 엔드 IP에 대한 IP 주소가 있는 서브넷을 고려합니다. 이 경우 33개의 IP 주소가 필요합니다. Application Gateway 인스턴스용으로 27개, 프라이빗 프런트 엔드용으로 1개, 내부용으로 5개가 필요합니다.
Application Gateway(Standard 또는 WAF SKU)는 최대 32개의 인스턴스를 지원할 수 있습니다(32개의 인스턴스 IP 주소 + 1개의 프라이빗 프런트 엔드 IP 구성 + 5개의 예약된 Azure). 최소 서브넷 크기 /26을 사용하는 것이 좋습니다.
Application Gateway(Standard_v2 또는 WAF_v2 SKU)는 최대 125개의 인스턴스를 지원할 수 있습니다(125개의 인스턴스 IP 주소 + 1개의 프라이빗 프런트 엔드 IP 구성 + 5개의 예약된 Azure). 최소 서브넷 크기 /24를 사용하는 것이 좋습니다.
기존 Application Gateway가 프로비전된 서브넷의 사용 가능한 용량을 확인하려면 서브넷의 크기를 가져와서 플랫폼에서 예약한 서브넷의 예약된 IP 주소 5개를 뺍니다. 다음으로, 각 게이트웨이를 가져와서 최대 인스터스 수를 뺍니다. 프라이빗 프런트 엔드 IP 구성이 있는 각 게이트웨이에 대해 게이트웨이당 하나의 추가 IP 주소도 뺍니다.
예를 들어 크기가 다양한 세 개의 게이트웨이가 있는 서브넷에 사용할 수 있는 주소 지정을 계산하는 방법은 다음과 같습니다.
- 게이트웨이 1: 최대 10개의 인스턴스. 개인 프런트 엔드 IP 구성을 사용합니다.
- 게이트웨이 2: 최대 2개의 인스턴스. 개인 프런트 엔드 IP 구성이 없습니다.
- 게이트웨이 3: 최대 15개의 인스턴스. 개인 프런트 엔드 IP 구성을 사용합니다.
- 서브넷 크기: /24
- 서브넷 크기 /24 = 256개의 IP 주소 - 플랫폼에서 예약된 5개 = 251개의 사용 가능한 주소
- 251: 게이트웨이 1(10) - 1 개인 프런트 엔드 IP 구성 = 240
- 240: 게이트웨이 2(2) = 238
- 238: 게이트웨이 3(15) - 1 개인 프런트 엔드 IP 구성 = 222
Important
/24 서브넷은 Application Gateway v2 SKU 배포당 필요하지 않지만 매우 권장됩니다. /24 서브넷은 Application Gateway v2에 확장 및 유지 관리 업그레이드의 자동 스케일링을 위한 충분한 공간이 보장되도록 합니다.
Application Gateway v2 서브넷에 최대 예상 트래픽을 처리하는 데 필요한 인스턴스 수를 수용할 수 있는 충분한 주소 공간이 있는지 확인해야 합니다. 최대 인스턴스 수를 지정하는 경우 서브넷에 최소한 많은 주소에 대한 용량이 있어야 합니다. 인스턴스 수에 대한 용량 계획은 인스턴스 수 세부 정보를 참조하세요.
GatewaySubnet라는 서브넷은 VPN Gateway용으로 예약되어 있습니다. 제어 평면 오류 및 플랫폼 불일치를 방지하려면 GatewaySubnet 서브넷을 사용하는 Application Gateway v1 리소스를 다른 서브넷으로 이동하거나 2023년 9월 30일 이전에 v2 SKU로 마이그레이션해야 합니다. 기존 Application Gateway 인스턴스의 서브넷을 변경하는 방법에 대한 내용은 Application Gateway에 대한 질문과 대답을 참조하세요.
팁
IP 주소는 게이트웨이 인스턴스에 대해 정의된 서브넷 공간의 시작 부분에서 할당됩니다. 게이트웨이 생성 또는 이벤트 크기 조정으로 인해 인스턴스가 만들어지고 제거되므로 서브넷에서 사용 가능한 다음 주소가 무엇인지 파악하기 어려울 수 있습니다. 향후 게이트웨이에 사용할 다음 주소를 결정하고 프런트 엔드 IP에 대한 연속 주소 지정 테마를 갖도록 하려면 정의된 하위 집합 공간의 위쪽 절반에서 프런트 엔드 IP 주소를 할당하는 것이 좋습니다.
예를 들어 서브넷 주소 공간이 10.5.5.0/24인 경우 게이트웨이의 프라이빗 프런트 엔드 IP 구성을 10.5.5.254부터 시작하여 이후 게이트웨이에 대해 10.5.5.253, 10.5.5.252, 10.5.5.251 등으로 설정하는 것이 좋습니다.
동일한 가상 네트워크 내에서 기존 Application Gateway 인스턴스의 서브넷을 변경할 수 있습니다. 이 변경을 수행하려면 Azure PowerShell 또는 Azure CLI를 사용합니다. 자세한 내용은 Application Gateway를 참조하세요.
이름 확인을 위한 DNS 서버
가상 네트워크 리소스는 DNS 서버 구성을 지원하므로 Azure에서 제공하는 기본 또는 사용자 지정 DNS 서버 중에서 선택할 수 있습니다. 애플리케이션 게이트웨이의 인스턴스는 모든 이름 확인에 대해 이 DNS 구성도 따릅니다. 이 설정을 변경한 후 이러한 변경 내용을 인스턴스에 적용하려면 애플리케이션 게이트웨이를 다시 시작(중지 및 시작)해야 합니다.
Application Gateway의 인스턴스는 DNS 쿼리를 발급할 때 먼저 응답하는 서버의 값을 사용합니다.
참고 항목
Application Gateway 가상 네트워크에서 사용자 지정 DNS 서버를 사용하는 경우 DNS 서버는 공용 인터넷 이름을 확인할 수 있어야 합니다. Application Gateway에는 이 기능이 필요합니다.
가상 네트워크 권한
Application Gateway 리소스는 가상 네트워크 내부에 배포되므로 가상 네트워크 리소스에 대한 권한을 확인하기 위한 검사도 수행됩니다. 이 유효성 검사는 생성 및 관리 작업 중에 수행되며 Application Gateway용 수신 컨트롤러의 관리 ID에도 적용됩니다.
Azure 역할 기반 액세스 제어를 확인하여 애플리케이션 게이트웨이를 운영하는 사용자 및 서비스 주체가 가상 네트워크 또는 서브넷에서 다음 이상의 권한을 가지고 있는지 확인합니다.
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
이미 이 권한을 지원하는 네트워크 기여자와 같은 기본 제공 역할을 사용할 수 있습니다. 기본 제공 역할이 올바른 권한을 제공하지 않는 경우 사용자 지정 역할을 만들고 할당할 수 있습니다. 서브넷 권한 관리에 대해 자세히 알아봅니다.
참고 항목
역할 할당이 변경된 후 Azure Resource Manager 캐시 새로 고침을 위해 충분한 시간을 허용해야 할 수 있습니다.
구독에 대해 영향을 받는 사용자 또는 서비스 주체 식별
계정에 대한 Azure Advisor를 방문하여 구독에 권한이 부족한 사용자 또는 서비스 주체가 있는지 확인할 수 있습니다. 해당 권장 사항 내용은 다음과 같습니다.
제목: Application Gateway 사용자의 VNet 권한 업데이트
범주: 안정성
영향: 높음
임시 AFEC(Azure Feature Exposure Control) 플래그 사용
임시 확장으로 구독 수준 AFEC(Azure Feature Exposure Control)가 도입되었습니다. AFEC에 등록하고 모든 사용자 및/또는 서비스 주체에 대한 권한을 수정할 때까지 사용할 수 있습니다. Azure 구독에 대한 미리 보기 기능 등록과 동일한 단계를 수행하여 해당 기능에 등록합니다.
이름: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
설명: Application Gateway 서브넷 권한 검사 사용 안 함
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
참고 항목
올바른 권한을 할당할 때까지 AFEC 프로비전을 임시 완화로만 사용하는 것이 좋습니다. 적용 가능한 모든 사용자(및 서비스 주체)에 대한 사용 권한 수정의 우선 순위를 지정한 다음, 이 AFEC 플래그의 등록을 취소하여 가상 네트워크 리소스에 대한 권한 확인을 다시 도입해야 합니다. 나중에 제거될 예정이므로 이 AFEC 메서드를 영구적으로 사용하지 않는 것이 좋습니다.
Azure Virtual Network Manager
Azure Virtual Network Manager는 구독 전체에서 가상 네트워크를 전역적으로 그룹화, 구성, 배포 및 관리할 수 있는 관리 서비스입니다. Virtual Network Manager를 사용하면 가상 네트워크를 식별하고 논리적으로 분할하는 네트워크 그룹을 정의할 수 있습니다. 그런 다음, 원하는 연결 및 보안 구성을 결정하고 네트워크 그룹에서 선택한 모든 가상 네트워크에서 한 번에 적용할 수 있습니다.
Azure Virtual Network Manager의 보안 관리자 규칙 구성을 사용하면 대규모 보안 정책을 정의하고 한 번에 여러 가상 네트워크에 적용할 수 있습니다.
참고 항목
Azure Virtual Network Manager의 보안 관리자 규칙은 네트워크 격리를 사용하도록 설정한 애플리케이션 게이트웨이만 포함하는 Application Gateway 서브넷에 적용됩니다. 네트워크 격리를 사용하도록 설정하지 않은 애플리케이션 게이트웨이가 있는 서브넷에는 보안 관리자 규칙이 없습니다.
네트워크 보안 그룹
Application Gateway 서브넷에 NSG를 사용할 수 있지만 몇 가지 주요 사항 및 제한 사항에 유의해야 합니다.
Important
이러한 NSG 제한은 프라이빗 Application Gateway 배포(미리 보기)를 사용할 때 완화됩니다.
필요한 보안 규칙
애플리케이션 게이트웨이에서 NSG를 사용하려면 몇 가지 필수 보안 규칙을 만들거나 유지해야 합니다. 동일한 순서로 우선 순위를 설정할 수 있습니다.
인바운드 규칙
클라이언트 트래픽: 애플리케이션 게이트웨이의 전체 서브넷 IP 접두사 및 인바운드 액세스 포트 형태의 대상에 대해 예상 클라이언트(원본 IP 또는 IP 범위)에서 들어오는 트래픽을 허용합니다. 예를 들어 80 및 443 포트에 대해 구성된 수신기가 있는 경우 이러한 포트를 허용해야 합니다. 이 규칙을 Any로 설정할 수도 있습니다.
| 원본 | 원본 포트 | 대상 | 대상 포트 | 프로토콜 | Access |
|---|---|---|---|---|---|
<as per need> |
모두 | <Subnet IP Prefix> |
<listener ports> |
TCP | 허용 |
‘동일한 포트 번호’로 ‘활성 퍼블릭 및 프라이빗 수신기’(규칙 포함)를 구성한 후 애플리케이션 게이트웨이는 모든 인바운드 흐름의 대상을 게이트웨이의 프런트 엔드 IP로 변경합니다. 이 변경은 포트를 공유하지 않는 수신기에서도 발생합니다. 동일한 포트 구성을 사용하는 경우 게이트웨이의 프런트 엔드 공용 및 개인 IP 주소를 인바운드 규칙의 대상에 포함해야 합니다.
| 원본 | 원본 포트 | 대상 | 대상 포트 | 프로토콜 | Access |
|---|---|---|---|---|---|
<as per need> |
모두 | <Public and Private frontend IPs> |
<listener ports> |
TCP | 허용 |
인프라 포트: GatewayManager 서비스 태그 및 Any 대상 형식으로 원본에서 들어오는 요청을 허용합니다. 대상 포트 범위는 SKU에 따라 다르며 백 엔드의 상태를 전달하는 데 필요합니다. 이러한 포트는 Azure 인증서에 의해 보호 및 잠깁니다. 적절한 인증서가 없는 경우 외부 엔터티는 해당 엔드포인트에 대한 변경을 시작할 수 없습니다.
- V2: 포트 65200-65535
- V1: 포트 65503-65534
| 원본 | 원본 포트 | 대상 | 대상 포트 | 프로토콜 | Access |
|---|---|---|---|---|---|
| GatewayManager | 모두 | 모두 | <as per SKU given above> |
TCP | 허용 |
Azure Load Balancer 프로브: AzureLoadBalancer 서비스 태그 형식으로 원본에서 들어오는 트래픽을 허용합니다. 이 규칙은 기본적으로 NSG에 대해 만들어집니다. 애플리케이션 게이트웨이의 원활한 작업을 보장하기 위해 수동 거부 규칙으로 재정의해서는 안 됩니다.
| 원본 | 원본 포트 | 대상 | 대상 포트 | 프로토콜 | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | 모두 | 모두 | 모두 | 모두 | 허용 |
모두 거부 규칙을 사용하여 다른 모든 들어오는 트래픽을 차단할 수 있습니다.
아웃바운드 규칙
인터넷으로 아웃바운드: 모든 대상에 대해 인터넷으로의 아웃바운드 트래픽을 허용합니다. 이 규칙은 기본적으로 NSG에 대해 만들어집니다. 애플리케이션 게이트웨이의 원활한 작업을 보장하기 위해 수동 거부 규칙으로 재정의해서는 안 됩니다. 아웃바운드 연결을 거부하는 아웃바운드 NSG 규칙을 만들면 안 됩니다.
| 원본 | 원본 포트 | 대상 | 대상 포트 | 프로토콜 | Access |
|---|---|---|---|---|---|
| 모두 | 모두 | 인터넷 | 모두 | 모두 | 허용 |
참고 항목
네트워크 격리를 사용하지 않는 Application Gateway는 원격 가상 네트워크에 트래픽 허용이 비활성화되어 있는 경우 피어링된 VNet 간에 트래픽을 전송할 수 없습니다.
지원되는 사용자 정의 경로
경로 테이블 규칙을 통해 Application Gateway 서브넷에 대한 세밀한 제어가 공개 미리 보기에서 가능합니다. 자세한 내용은 프라이빗 Application Gateway 배포(미리 보기)를 참조하세요.
현재 기능에는 몇 가지 제한 사항이 있습니다.
Important
Application Gateway 서브넷에서 UDR을 사용하면 백 엔드 상태 보기의 상태가 알 수 없음으로 표시될 수 있습니다. 이로 인해 Application Gateway 로그 및 메트릭이 생성되지 않을 수도 있습니다. 백 엔드 상태, 로그 및 메트릭을 볼 수 있도록 Application Gateway 서브넷에서 UDR을 사용하지 않는 것이 좋습니다.
v1: v1 SKU의 경우 UDR은 엔드투엔드 요청/응답 통신을 변경하지 않는 경우 Application Gateway 서브넷에서 지원됩니다. 예를 들어 Application Gateway 서브넷에서 UDR을 설정하여 패킷 검사를 위한 방화벽 어플라이언스를 가리키도록 할 수 있습니다. 그러나 검사 후 패킷이 의도한 대상에 도달할 수 있는지 확인해야 합니다. 이렇게 하지 않으면 잘못된 상태 프로브 또는 트래픽 라우팅 동작을 초래할 수 있습니다. 여기에는 가상 네트워크에서 Azure ExpressRoute 또는 VPN 게이트웨이를 통해 전파된 학습한 경로 또는 기본 0.0.0.0/0 경로도 포함됩니다.
v2: v2 SKU의 경우 지원되는 시나리오와 지원되지 않는 시나리오는 다음과 같습니다.
v2 지원되는 시나리오
Warning
경로 테이블을 잘못 구성하면 Application Gateway v2에서 비대칭 라우팅이 발생할 수 있습니다. 모든 관리/컨트롤 플레인 트래픽이 가상 어플라이언스를 통하지 않고 인터넷으로 직접 전송되는지 확인합니다. 로깅, 메트릭 및 CRL 확인도 영향을 받을 수 있습니다.
시나리오 1: Application Gateway 서브넷에 대한 BGP(Border Gateway Protocol) 경로 전파를 사용하지 않도록 설정하는 UDR
경우에 따라 기본 게이트웨이 경로(0.0.0.0/0)가 Application Gateway 가상 네트워크와 연결된 ExpressRoute 또는 VPN 게이트웨이를 통해 보급됩니다. 이 동작은 인터넷에 직접 경로를 사용해야 하는 관리 평면 트래픽을 중단합니다. 이러한 시나리오에서는 UDR을 사용하여 BGP 경로 전파를 사용하지 않도록 설정할 수 있습니다.
BGP 경로 전파를 사용하지 않도록 설정하려면 다음을 수행합니다.
- Azure에서 경로 테이블 리소스를 만듭니다.
- 가상 네트워크 게이트웨이 경로 전파 매개 변수를 사용하지 않도록 설정합니다.
- 경로 테이블을 적절한 서브넷에 연결합니다.
이 시나리오에 UDR을 사용하도록 설정하면 기존 설정이 중단되지 않습니다.
시나리오 2: 인터넷에 0.0.0.0/0을 전달하는 UDR
UDR을 만들어 0.0.0.0/0 트래픽을 인터넷으로 직접 보낼 수 있습니다.
시나리오 3: kubenet을 사용하는 AKS(Azure Kubernetes Service)에 대한 UDR
AKS 및 Application Gateway 수신 컨트롤러와 함께 kubenet을 사용하는 경우 Application Gateway에서 Pod로 전송된 트래픽을 올바른 노드로 라우팅할 수 있도록 경로 테이블이 필요합니다. Azure Container Networking Interface를 사용하는 경우 경로 테이블을 사용할 필요가 없습니다.
kubenet이 작동할 수 있도록 경로 테이블을 사용하려면 다음을 수행합니다.
AKS에서 만든 리소스 그룹으로 이동합니다. 리소스 그룹의 이름은
MC_로 시작해야 합니다.해당 리소스 그룹에서 AKS에 의해 생성된 경로 테이블을 찾습니다. 경로 테이블은 다음 정보로 채워야 합니다.
- 주소 접두사는 AKS에서 연결하려는 Pod의 IP 범위여야 합니다.
- 다음 홉 형식은 가상 어플라이언스여야 합니다.
- 다음 홉 주소는 Pod를 호스트하는 노드의 IP 주소여야 합니다.
이 경로 테이블을 Application Gateway 서브넷에 연결합니다.
v2 지원되지 않는 시나리오
시나리오 1: 가상 어플라이언스에 대한 UDR
가상 어플라이언스, 허브/스포크 가상 네트워크 또는 온-프레미스(강제 터널링)를 통해 0.0.0.0/0을 리디렉션해야 하는 모든 시나리오는 v2에서 지원되지 않습니다.