가상 네트워크에 대한 Azure Firewall 및 Application Gateway

Azure 애플리케이션 워크로드를 보호하려면 애플리케이션 자체에서 인증 및 암호화와 같은 보호 조치를 사용합니다. 애플리케이션을 호스트하는 가상 네트워크에 보안 계층을 추가할 수 있습니다. 이러한 보안 계층은 의도하지 않은 사용으로부터 애플리케이션의 인바운드 흐름을 보호하는 데 도움이 됩니다. 또한 인터넷에 대한 아웃바운드 흐름을 애플리케이션에 필요한 엔드포인트로만 제한합니다. 이 문서에서는 Azure DDoS Protection, Azure Firewall 및 Azure Application Gateway와 같은 Azure Virtual Network 보안 서비스에 대해 설명합니다. 또한 각 서비스와 이를 결합하는 네트워크 디자인 옵션을 사용해야 하는 경우를 설명합니다.

• DDoS Protection은 애플리케이션 디자인 모범 사례와 결합되어 DDoS 공격에 대한 방어를 향상시키는 향상된 DDoS 완화 기능을 제공합니다. 모든 경계 가상 네트워크에서 DDoS Protection을 사용하도록 설정해야 합니다.

• Azure Firewall 은 NAT(네트워크 주소 변환) 기능을 제공하는 관리형 차세대 방화벽입니다. Azure Firewall은 IP 주소 및 TCP(Transmission Control Protocol) 또는 UDP(사용자 데이터그램 프로토콜) 포트를 기반으로 패킷을 필터링합니다. HTTP(S) 및 SQL과 같은 애플리케이션 기반 특성을 사용하여 트래픽을 필터링할 수 있습니다. 또한 Azure Firewall은 악의적인 IP 주소를 식별하는 데 도움이 되는 Microsoft 위협 인텔리전스를 적용합니다. 자세한 내용은 Azure Firewall 설명서를 참조하세요.

• Azure Firewall Premium 에는 TLS(전송 계층 보안) 검사 및 IDPS(침입 감지 및 방지 시스템)와 같은 기능 외에도 Azure Firewall Standard의 모든 기능이 포함되어 있습니다.

• Application Gateway 는 SSL(Secure Socket Layer) 암호화 및 암호 해독을 수행할 수 있는 관리되는 웹 트래픽 부하 분산 장치 및 HTTP(S) 전체 역방향 프록시입니다. Application Gateway는 HTTP 헤더에 X-Forwarded-For 원래 클라이언트 IP 주소를 유지합니다. 또한 Application Gateway는 Azure Web Application Firewall을 사용하여 웹 트래픽을 검사하고 HTTP 계층에서 공격을 검색합니다. 자세한 내용은 Application Gateway 설명서를 참조하세요.

• 웹 애플리케이션 방화벽 은 Application Gateway에 대한 선택적 추가 사항입니다. HTTP 요청을 검사하고 SQL 삽입 및 사이트 간 스크립팅과 같은 웹 계층 공격을 방지합니다. 자세한 내용은 웹 애플리케이션 방화벽 설명서를 참조하세요.

이러한 Azure 서비스는 서로를 보완합니다. 필요에 따라 하나의 서비스를 사용하면 워크로드에 더 적합할 수 있습니다. 그러나 이러한 서비스를 함께 사용하여 네트워크 및 애플리케이션 계층 모두에서 최적의 보호를 제공할 수 있습니다. 다음 의사 결정 트리와 이 문서의 예제를 사용하여 애플리케이션의 가상 네트워크에 가장 적합한 보안 옵션을 선택합니다.

Azure Firewall 및 Application Gateway는 다양한 유형의 데이터 흐름을 보호하는 데 도움이 되는 다양한 기술을 사용합니다.

애플리케이션 흐름	Azure Firewall을 통해 필터링할 수 있습니다.	Application Gateway의 웹 애플리케이션 방화벽으로 필터링할 수 있습니다.
온-프레미스 또는 인터넷에서 Azure로의 HTTP(S) 트래픽(인바운드)	예	예
Azure에서 온-프레미스 또는 인터넷(아웃바운드)으로의 HTTP(S) 트래픽	예	아니요
비 HTTP(S) 트래픽(인바운드 또는 아웃바운드)	예	아니요

디자인은 필요한 네트워크 흐름에 따라 각 애플리케이션에 따라 달라질 수 있습니다. 다음 다이어그램에서는 애플리케이션에 권장되는 방법을 선택하는 데 도움이 되는 간소화된 의사 결정 트리를 제공합니다. 이 선택은 애플리케이션이 HTTP(S)를 통해 게시되는지 또는 다른 프로토콜을 통해 게시되는지에 따라 달라집니다.

이 문서에서는 흐름도에 표시된 널리 권장되는 디자인과 덜 일반적인 시나리오에 적합한 디자인에 대해 설명합니다.

• Azure Firewall만 해당: 가상 네트워크에 웹 애플리케이션이 없는 경우 이 디자인을 사용합니다. 애플리케이션에 대한 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어합니다.

• Application Gateway 전용: 웹 애플리케이션만 가상 네트워크에 있고 NSG(네트워크 보안 그룹) 가 충분한 출력 필터링을 제공하는 경우 이 디자인을 사용합니다. Azure Firewall은 데이터 반출 및 IDPS와 같은 여러 공격 시나리오를 방지하는 데 도움이 되는 기능을 제공합니다. 따라서 Application Gateway 전용 디자인은 일반적으로 권장되지 않으므로 이전 흐름도에 포함되지 않습니다.

• Azure Firewall 및 Application Gateway를 병렬로 사용합니다. Application Gateway가 웹 공격 및 Azure Firewall로부터 HTTP(S) 애플리케이션을 보호하여 다른 모든 워크로드를 보호하고 아웃바운드 트래픽을 필터링하려는 경우 이 디자인을 사용합니다. Azure Firewall 및 Application Gateway를 병렬로 설계하는 것이 일반적입니다.

• Azure Firewall 앞의 Application Gateway: Azure Firewall이 모든 트래픽을 검사하고 웹 트래픽을 보호하는 웹 애플리케이션 방화벽 및 애플리케이션이 클라이언트의 원본 IP 주소를 식별하도록 하려면 이 디자인을 사용합니다. Azure Firewall 프리미엄 및 TLS 검사를 통해 이 디자인은 엔드투엔드 SSL 시나리오도 지원합니다.

• Application Gateway 앞의 Azure Firewall: Azure Firewall이 Application Gateway에 도달하기 전에 트래픽을 검사하고 필터링하도록 하려면 이 디자인을 사용합니다. Azure Firewall은 HTTPS 트래픽의 암호를 해독하지 않으므로 Application Gateway에 추가된 기능이 제한됩니다. 이 시나리오는 이전 흐름도에 설명되어 있지 않습니다.

이러한 기본 디자인의 변형은 이 문서의 뒷부분에 설명되어 있으며 다음을 포함합니다.

• 온-프레미스 애플리케이션 클라이언트.
• 허브 및 스포크 네트워크.
• AKS(Azure Kubernetes Service) 구현을 .

Azure API Management 게이트웨이 또는 Azure Front Door와 같은 다른 역방향 프록시 서비스를 추가할 수 있습니다. 또는 Azure 리소스를 타사 NVA(네트워크 가상 어플라이언스)로 바꿀 수 있습니다.

Azure Firewall 전용 디자인

가상 네트워크에 웹 애플리케이션 방화벽의 이점을 얻을 수 있는 웹 기반 워크로드가 없는 경우 Azure Firewall 전용 디자인을 사용할 수 있습니다. 이 예제의 디자인은 간단하지만 패킷 흐름을 검토하여 더 복잡한 디자인을 더 잘 이해할 수 있습니다. 이 디자인에서 모든 인바운드 트래픽은 온-프레미스 또는 다른 Azure 가상 네트워크의 연결을 위해 UDR(사용자 정의 경로)을 통해 Azure Firewall로 전송됩니다. 다음 다이어그램과 같이 공용 인터넷에서 연결하기 위해 Azure Firewall 공용 IP 주소로 주소가 지정됩니다. UDR은 다음 대화 상자와 같이 Azure 가상 네트워크에서 Azure Firewall로 아웃바운드 트래픽을 전달합니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

흐름	Application Gateway/웹 애플리케이션 방화벽을 통과합니다.	Azure Firewall을 통과합니다.
인터넷 또는 온-프레미스에서 Azure로의 HTTP(S) 트래픽	해당(N/A)	예
Azure에서 인터넷 또는 온-프레미스로의 HTTP(S) 트래픽	해당(N/A)	예
인터넷 또는 온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	해당(N/A)	예
Azure에서 인터넷 또는 온-프레미스로의 비 HTTP(S) 트래픽	해당(N/A)	예

Azure Firewall은 인바운드 HTTP(S) 트래픽을 검사하지 않습니다. 그러나 계층 3 및 계층 4 규칙과 FQDN(정규화된 도메인 이름) 기반 애플리케이션 규칙을 적용할 수 있습니다. Azure Firewall은 Azure Firewall 계층 및 TLS 검사를 구성하는지 여부에 따라 아웃바운드 HTTP(S) 트래픽을 검사합니다.

• Azure Firewall 표준은 네트워크 규칙의 패킷 계층 3 및 계층 4 특성과 애플리케이션 규칙의 호스트 HTTP 헤더만 검사합니다.

• Azure Firewall Premium은 다른 HTTP 헤더(예: 사용자 에이전트)를 검사하고 더 심층적인 패킷 분석을 위해 TLS 검사를 사용하도록 설정하는 등의 기능을 추가합니다. 그러나 Azure Firewall은 웹 애플리케이션 방화벽과 동일하지 않습니다. 가상 네트워크에 웹 워크로드가 있는 경우 웹 애플리케이션 방화벽을 사용하는 것이 좋습니다.

다음 패킷 워크 예제에서는 클라이언트가 공용 인터넷에서 VM 호스팅 애플리케이션에 액세스하는 방법을 보여줍니다. 다이어그램에는 단순성을 위해 하나의 VM만 포함됩니다. 고가용성 및 확장성을 위해 부하 분산 장치 뒤에 여러 애플리케이션 인스턴스가 있습니다. 이 디자인에서 Azure Firewall은 UDR을 사용하여 공용 인터넷에서 들어오는 연결과 애플리케이션 서브넷 VM의 아웃바운드 연결을 검사합니다.

• 이 예제에서 Azure Firewall은 프런트 엔드 IP 주소와 범위 192.168.100.4내의 내부 주소를 192.168.100.0/26 사용하여 여러 인스턴스를 자동으로 배포합니다. 일반적으로 이러한 인스턴스는 Azure 관리자에게 표시되지 않습니다. 그러나 이를 인식하는 것은 네트워크 문제를 해결하는 데 도움이 될 수 있습니다.

• 트래픽이 인터넷 대신 온-프레미스 VPN(가상 사설망) 또는 Azure ExpressRoute 게이트웨이에서 오는 경우 클라이언트는 VM의 IP 주소에 대한 연결을 시작합니다. 방화벽의 IP 주소에 대한 연결을 시작하지 않으며 방화벽은 기본적으로 원본 NAT를 수행하지 않습니다.

건축학

다음 다이어그램에서는 트래픽 흐름을 보여 줍니다. 인스턴스 IP 주소는 다음과 같습니다 192.168.100.7.

워크플로

1. 클라이언트는 Azure Firewall의 공용 IP 주소에 대한 연결을 시작합니다.

   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AzFwPIP

2. Azure Firewall 공용 IP 주소에 대한 요청은 이 예제에 있는 방화벽의 백 엔드 인스턴스에 배포됩니다 192.168.100.7 . Azure Firewall DNAT(대상 네트워크 주소 변환) 규칙은 대상 IP 주소를 가상 네트워크 내의 애플리케이션 IP 주소로 변환합니다. 또한 Azure Firewall은 DNAT를 사용하는 경우 패킷에 SNAT(원본 네트워크 주소 변환) 를 구현합니다. 자세한 내용은알려진 Azure Firewall 문제 참조하세요. VM은 들어오는 패킷에 다음과 같은 IP 주소를 표시합니다.

   • 원본 IP 주소: 192.168.100.7
   • 대상 IP 주소: 192.168.1.4

3. VM은 원본 및 대상 IP 주소를 모두 반대로 하는 애플리케이션 요청에 응답합니다. 원본 IP는 Azure Firewall IP 주소이므로 인바운드 흐름에 UDR이 필요하지 않습니다. 다이어그램의 UDR은 퍼블릭 인터넷에 대한 0.0.0.0/0 패킷이 Azure Firewall을 통과하도록 아웃바운드 연결을 위한 것입니다.

   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.100.7

4. Azure Firewall은 SNAT 및 DNAT 작업을 실행 취소하고 클라이언트에 응답을 제공합니다.

   • 원본 IP 주소: AzFwPIP
   • 대상 IP 주소: ClientPIP

Application Gateway 전용 디자인

이 디자인은 가상 네트워크에 웹 애플리케이션만 존재하는 시나리오를 설명하고 NSG를 사용하여 아웃바운드 트래픽을 검사하면 인터넷으로의 아웃바운드 흐름을 보호하기에 충분합니다.

이전 Azure Firewall 전용 디자인과의 주요 차이점은 Application Gateway가 NAT를 사용하는 라우팅 디바이스로 작동하지 않는다는 점입니다. 대신 전체 역방향 애플리케이션 프록시로 작동합니다. 이 방법은 Application Gateway가 클라이언트에서 웹 세션을 중지하고 백 엔드 서버 중 하나를 사용하여 별도의 세션을 설정한다는 것을 의미합니다. 인터넷의 인바운드 HTTP(S) 연결은 Application Gateway의 공용 IP 주소로 전송되고 Azure 또는 온-프레미스의 연결은 게이트웨이의 개인 IP 주소를 사용합니다. Azure VM에서 트래픽을 반환하는 것은 Application Gateway로 다시 라우팅되는 표준 가상 네트워크 라우팅을 따릅니다. 자세한 내용은 이 문서의 뒷부분에 있는 패킷 워크를 참조하세요. Azure VM에서 아웃바운드 인터넷 흐름은 인터넷으로 직접 이동합니다.

다음 표에서는 트래픽 흐름을 요약합니다.

흐름	Application Gateway/웹 애플리케이션 방화벽을 통과합니다.	Azure Firewall을 통과합니다.
인터넷 또는 온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	해당(N/A)
Azure에서 인터넷 또는 온-프레미스로의 HTTP(S) 트래픽	아니요	해당(N/A)
인터넷 또는 온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	아니요	해당(N/A)
Azure에서 인터넷 또는 온-프레미스로의 비 HTTP(S) 트래픽	아니요	해당(N/A)

건축학

다음 패킷 워크 예제에서는 클라이언트가 공용 인터넷에서 VM 호스팅 애플리케이션에 액세스하는 방법을 보여줍니다.

워크플로

1. 클라이언트는 Application Gateway의 공용 IP 주소에 대한 연결을 시작합니다.

   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AppGwPIP

2. Application Gateway 공용 IP 주소에 대한 요청은 이 예제에 있는 게이트웨이의 백 엔드 인스턴스에 배포됩니다 192.168.200.7 . 요청을 수신하는 Application Gateway 인스턴스는 클라이언트에서 연결을 중지하고 백 엔드 중 하나를 사용하여 새 연결을 설정합니다. 백 엔드는 Application Gateway 인스턴스를 원본 IP 주소로 봅니다. Application Gateway는 원래 클라이언트의 IP 주소를 사용하여 X-Forwarded-For HTTP 헤더를 삽입합니다.

   • Application Gateway 인스턴스의 개인 IP 주소인 원본 IP 주소: 192.168.200.7
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-For 머리글: ClientPIP

3. VM은 애플리케이션 요청에 응답하고 원본 및 대상 IP 주소를 모두 반대로 바뀝니다. VM은 Application Gateway에 연결할 수 있으므로 UDR이 필요하지 않습니다.

   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7

4. Application Gateway 인스턴스가 클라이언트에 응답합니다.

   • 원본 IP 주소: AppGwPIP
   • 대상 IP 주소: ClientPIP

Application Gateway는 원본 클라이언트의 IP 주소를 포함하는 헤더와 같은 X-Forwarded-For 패킷 HTTP 헤더에 메타데이터를 추가합니다. 일부 애플리케이션 서버는 지리적 위치별 콘텐츠를 제공하거나 로깅을 위해 원본 클라이언트 IP 주소가 필요합니다. 자세한 내용은 애플리케이션 게이트웨이가작동하는 방법을 참조하세요.

• 이 예제에서 IP 주소 192.168.200.7 는 Application Gateway 서비스에서 자동으로 배포하는 인스턴스 중 하나입니다. 내부 프라이빗 프런트 엔드 IP 주소 192.168.200.4가 있습니다. 이러한 개별 인스턴스는 일반적으로 Azure 관리자에게 표시되지 않습니다. 그러나 네트워크 문제를 해결할 때와 같이 차이점을 알아차리는 것이 유용할 수 있습니다.

• 클라이언트가 VPN 또는 ExpressRoute 게이트웨이를 통해 온-프레미스 네트워크에서 온 경우 흐름은 비슷합니다. 차이점은 클라이언트가 공용 IP 주소 대신 Application Gateway의 개인 IP 주소에 액세스하는 것입니다.

병렬 디자인의 Azure Firewall 및 Application Gateway

단순성과 유연성 때문에 Application Gateway 및 Azure Firewall을 병렬로 실행하는 것이 가장 좋습니다.

가상 네트워크에 웹 워크로드와 비 웹 워크로드가 모두 있는 경우 이 디자인을 구현합니다. Application Gateway의 웹 애플리케이션 방화벽은 웹 워크로드에 대한 인바운드 트래픽을 보호하는 데 도움이 됩니다. Azure Firewall은 다른 애플리케이션에 대한 인바운드 트래픽을 검사합니다. Azure Firewall은 두 워크로드 유형의 아웃바운드 흐름을 다룹니다.

인터넷에서 인바운드 HTTP(S) 연결을 Application Gateway의 공용 IP 주소로 보내야 합니다. Azure 또는 온-프레미스에서 HTTP(S) 연결을 해당 개인 IP 주소로 보내야 합니다. 표준 가상 네트워크 라우팅은 Application Gateway에서 대상 VM으로, 대상 VM에서 Application Gateway로 패킷을 다시 보냅니다. 자세한 내용은 이 문서의 뒷부분에 있는 패킷 워크를 참조하세요.

인바운드 비 HTTP(S) 연결의 경우 트래픽은 공용 인터넷에서 제공되는 경우 Azure Firewall의 공용 IP 주소를 대상으로 해야 합니다. 트래픽은 다른 Azure 가상 네트워크 또는 온-프레미스 네트워크에서 오는 경우 UDR을 통해 Azure Firewall을 통해 전송되어야 합니다. Azure VM의 모든 아웃바운드 흐름은 UDR을 통해 Azure Firewall로 전달됩니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

흐름	Application Gateway/웹 애플리케이션 방화벽을 통과합니다.	Azure Firewall을 통과합니다.
인터넷 또는 온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	아니요
Azure에서 인터넷 또는 온-프레미스로의 HTTP(S) 트래픽	아니요	예
인터넷 또는 온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	아니요	예
Azure에서 인터넷 또는 온-프레미스로의 비 HTTP(S) 트래픽	아니요	예

이 디자인은 NSG만 사용하는 것보다 훨씬 더 세분화된 송신 필터링을 제공합니다. 예를 들어 애플리케이션이 특정 Azure Storage 계정에 연결해야 하는 경우 FQDN 기반 필터를 사용할 수 있습니다. FQDN 기반 필터를 사용하면 애플리케이션이 불량 스토리지 계정에 데이터를 보내지 않습니다. NSG만 사용하는 경우 이 시나리오를 방지할 수 없습니다. 이 디자인은 아웃바운드 트래픽에 FQDN 기반 필터링이 필요한 경우에 자주 사용됩니다. 한 가지 시나리오는 AKS 클러스터에서 송신 트래픽을 제한하는 경우입니다.

아키텍처

다음 다이어그램에서는 외부 클라이언트에서 인바운드 HTTP(S) 연결에 대한 트래픽 흐름을 보여 줍니다.

다음 다이어그램은 네트워크 VM에서 인터넷으로의 아웃바운드 연결에 대한 트래픽 흐름을 보여 줍니다. 한 가지 예는 백 엔드 시스템에 연결하거나 운영 체제 업데이트를 가져오는 것입니다.

각 서비스에 대한 패킷 흐름 단계는 이전 독립 실행형 디자인 옵션과 동일합니다.

Azure Firewall 디자인 앞의 Application Gateway

이 디자인은 Azure Firewall 및 Application Gateway를 사용하는 웹 애플리케이션에 대한 제로 트러스트 네트워크에서 자세히 설명합니다. 이 문서에서는 다른 디자인 옵션과의 비교에 중점을 둡니다. 이 토폴로지에서 인바운드 웹 트래픽은 Azure Firewall 및 웹 애플리케이션 방화벽을 모두 통과합니다. 웹 애플리케이션 방화벽은 웹 애플리케이션 계층에서 보호를 제공합니다. Azure Firewall은 중앙 로깅 및 제어 지점 역할을 하며 Application Gateway와 백 엔드 서버 간의 트래픽을 검사합니다. 이 디자인에서 Application Gateway와 Azure Firewall은 병렬로 배치되지 않고 다른 쪽 앞에 배치됩니다.

Azure Firewall Premium을 사용하여 이 디자인은 Azure Firewall이 TLS 검사를 적용하여 Application Gateway와 웹 백 엔드 간의 암호화된 트래픽에서 IDPS를 수행하는 엔드투엔드 시나리오를 지원할 수 있습니다.

이 디자인은 들어오는 클라이언트 원본 IP 주소를 식별해야 하는 애플리케이션에 적합합니다. 예를 들어 지리적 위치별 콘텐츠를 제공하거나 로깅에 사용할 수 있습니다. Azure Firewall 디자인 앞의 Application Gateway는 헤더에서 X-Forwarded-For 들어오는 패킷의 원본 IP 주소를 캡처하므로 웹 서버는 이 헤더에서 원래 IP 주소를 볼 수 있습니다. 자세한 내용은 애플리케이션 게이트웨이가작동하는 방법을 참조하세요.

인터넷에서 인바운드 HTTP(S) 연결을 Application Gateway의 공용 IP 주소로 보내야 합니다. Azure 또는 온-프레미스에서 HTTP(S) 연결을 해당 개인 IP 주소로 보내야 합니다. Application Gateway에서 UDR은 패킷이 Azure Firewall을 통해 라우팅되는지 확인합니다. 자세한 내용은 이 문서의 뒷부분에 있는 패킷 워크를 참조하세요.

인바운드 비 HTTP(S) 연결의 경우 트래픽은 공용 인터넷에서 제공되는 경우 Azure Firewall의 공용 IP 주소를 대상으로 해야 합니다. 트래픽은 다른 Azure 가상 네트워크 또는 온-프레미스 네트워크에서 오는 경우 UDR을 통해 Azure Firewall을 통해 전송되어야 합니다. Azure VM의 모든 아웃바운드 흐름은 UDR을 통해 Azure Firewall로 전달됩니다.

이 디자인의 중요한 측면은 Azure Firewall Premium이 Application Gateway 서브넷의 원본 IP 주소를 사용하여 트래픽을 볼 수 있다는 것입니다. 이 서브넷이 개인 IP 주소(인10.0.0.0/8, 192.168.0.0/16또는 172.16.0.0/12100.64.0.0/10) 로 구성된 경우 Azure Firewall Premium은 Application Gateway의 트래픽을 내부로 처리하고 인바운드 트래픽에 대한 IDPS 규칙을 적용하지 않습니다. 따라서 Azure Firewall 정책에서 IDPS 프라이빗 접두사를 수정하는 것이 좋습니다. 이렇게 수정하면 Application Gateway 서브넷이 내부 원본으로 간주되지 않으므로 인바운드 및 아웃바운드 IDPS 서명을 트래픽에 적용할 수 있습니다. Azure Firewall IDPS 규칙 지침 및 Azure Firewall IDPS 규칙에서 IDPS에 대한 개인 IP 접두사에 대한 자세한 정보를 찾을 수 있습니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

흐름	Application Gateway/웹 애플리케이션 방화벽을 통과합니다.	Azure Firewall을 통과합니다.
인터넷 또는 온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	예
Azure에서 인터넷 또는 온-프레미스로의 HTTP(S) 트래픽	아니요	예
인터넷 또는 온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	아니요	예
Azure에서 인터넷 또는 온-프레미스로의 비 HTTP(S) 트래픽	아니요	예

온-프레미스 또는 인터넷에서 Azure로의 웹 트래픽의 경우 Azure Firewall은 웹 애플리케이션 방화벽에서 허용하는 흐름을 검사합니다. Application Gateway가 Application Gateway에서 애플리케이션 서버로의 트래픽인 백 엔드 트래픽을 암호화하는지 여부에 따라 다양한 시나리오가 발생할 수 있습니다.

• Application Gateway는 엔드투엔드 TLS 암호화와 같은 제로 트러스트 원칙에 따라 트래픽을 암호화하고 Azure Firewall은 암호화된 트래픽을 수신합니다. Azure Firewall Standard는 TLS SNI(서버 이름 표시) 헤더를 사용하여 네트워크 규칙의 계층 3 및 계층 4 필터링 또는 애플리케이션 규칙의 FQDN 필터링과 같은 검사 규칙을 계속 적용할 수 있습니다. Azure Firewall Premium URL 기반 필터링과 같은 TLS 검사를 통해 보다 심층적인 가시성을 제공합니다.

• Application Gateway가 암호화되지 않은 트래픽을 애플리케이션 서버로 보내는 경우 Azure Firewall은 인바운드 트래픽을 일반 텍스트로 표시합니다. Azure Firewall에서는 TLS 검사가 필요하지 않습니다.

• Azure Firewall에서 IDPS를 사용하는 경우 HTTP 호스트 헤더가 대상 IP 주소와 일치하는지 확인합니다. 이 확인을 수행하려면 호스트 헤더에 지정된 FQDN의 이름 확인이 필요합니다. 이 이름 확인은 Azure DNS 프라이빗 영역 및 기본 Azure Firewall DNS 설정을 사용하여 수행할 수 있습니다. Azure Firewall 설정에서 구성해야 하는 사용자 지정 DNS 서버를 사용하여 수행할 수도 있습니다. Azure Firewall이 배포된 가상 네트워크에 대한 관리 액세스 권한이 없는 경우 후자의 방법이 유일한 옵션입니다. 한 가지 예는 Azure Virtual WAN 보안 허브에 배포된 Azure Firewall 인스턴스를 사용하는 것입니다.

건축학

인바운드 비 HTTP(S) 트래픽 및 아웃바운드 트래픽을 포함하는 나머지 흐름의 경우 Azure Firewall은 적절한 경우 IDPS 검사 및 TLS 검사를 제공합니다. 또한 DNS를 기반으로 네트워크 규칙에서 FQDN 기반 필터링을 제공합니다.

워크플로

공용 인터넷의 네트워크 트래픽은 다음 흐름을 따릅니다.

1. 클라이언트는 Application Gateway의 공용 IP 주소에 대한 연결을 시작합니다.

   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AppGwPIP

2. Application Gateway 공용 IP 주소에 대한 요청은 이 예제에 있는 게이트웨이의 백 엔드 인스턴스에 배포됩니다 192.168.200.7 . Application Gateway 인스턴스는 클라이언트에서 연결을 중지하고 백 엔드 중 하나를 사용하여 새 연결을 설정합니다. Application Gateway 서브넷의 UDR 192.168.1.0/24 은 패킷을 Azure Firewall로 전달하고 대상 IP 주소를 웹 애플리케이션에 유지합니다.

   • Application Gateway 인스턴스의 개인 IP 주소인 원본 IP 주소: 192.168.200.7
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-For 머리글: ClientPIP

3. 트래픽이 개인 IP 주소로 전달되므로 Azure Firewall은 트래픽에 SNAT를 적용하지 않습니다. 규칙이 허용하는 경우 애플리케이션 VM에 트래픽을 전달합니다. 자세한 내용은 Azure Firewall SNAT 개인 IP 주소 범위를 참조하세요. 그러나 트래픽이 방화벽의 애플리케이션 규칙에 도달하면 Azure Firewall이 연결을 프록시하기 때문에 패킷을 처리한 특정 방화벽 인스턴스의 원본 IP 주소가 워크로드에 표시됩니다.

   • 트래픽이 Azure Firewall 네트워크 규칙에서 허용되고 Application Gateway 인스턴스 중 하나의 개인 IP 주소인 경우 원본 IP 주소입니다. 192.168.200.7
   • 트래픽이 Azure Firewall 애플리케이션 규칙에서 허용되고 Azure Firewall 인스턴스 중 하나의 개인 IP 주소인 경우 원본 IP 주소입니다. 192.168.100.7
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-For 머리글: ClientPIP

4. VM은 원본 및 대상 IP 주소를 모두 반대로 하는 요청에 응답합니다. Application Gateway로 다시 전송된 패킷을 캡처하고 192.168.200.0/24 , Azure Firewall로 리디렉션하고, Application Gateway로 대상 IP 주소를 유지하는 UDR입니다.

   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7

5. 다시 말하지만, Azure Firewall은 개인 IP 주소로 이동하고 트래픽을 Application Gateway로 전달하기 때문에 트래픽에 SNAT를 적용하지 않습니다.

   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7

6. Application Gateway 인스턴스가 클라이언트에 응답합니다.

   • 원본 IP 주소: AppGwPIP
   • 대상 IP 주소: ClientPIP

VM에서 공용 인터넷으로의 아웃바운드 흐름은 UDR이 정의할 Azure Firewall을 0.0.0.0/0 통과합니다.

이 디자인의 변형으로, 애플리케이션 워크로드가 Azure Firewall 인스턴스의 IP 주소를 원본으로 보고 UDR이 필요하지 않도록 Azure Firewall에서 프라이빗 DNAT를 구성할 수 있습니다. 애플리케이션 클라이언트의 원본 IP 주소는 Application Gateway에 의해 HTTP 헤더에 X-Forwarded-For 이미 보존되어 있습니다. 따라서 Azure Firewall이 트래픽에 DNAT를 적용하면 정보가 손실되지 않습니다. 자세한 내용은 Azure Portal을 사용하여 Azure Firewall 정책 DNAT를 사용하여 인바운드 인터넷 또는 인트라넷 트래픽 필터링을 참조하세요.

Application Gateway 디자인 앞의 Azure Firewall

이 디자인을 통해 Azure Firewall은 Application Gateway에 도달하기 전에 악성 트래픽을 필터링하고 삭제할 수 있습니다. 예를 들어 위협 인텔리전스 기반 필터링과 같은 기능을 적용할 수 있습니다. 또 다른 이점은 애플리케이션이 프로토콜에 관계없이 인바운드 및 아웃바운드 트래픽 모두에 대해 동일한 공용 IP 주소를 얻는다는 것입니다. 이론적으로 Azure Firewall을 구성할 수 있는 세 가지 모드가 있습니다.

• DNAT 규칙이 있는 Azure Firewall: Azure Firewall은 IP 주소 계층에서만 IP 주소를 교환하지만 페이로드를 처리하지는 않습니다. 따라서 HTTP 헤더는 변경되지 않습니다.

• 애플리케이션 규칙 및 TLS 검사를 사용하지 않도록 설정된 Azure Firewall: Azure Firewall은 TLS에서 SNI 헤더를 볼 수 있지만 암호를 해독하지는 않습니다. 방화벽에서 다음 홉으로 새 TCP 연결이 만들어집니다. 이 예제에서는 Application Gateway입니다.

• 애플리케이션 규칙 및 TLS 검사를 사용하도록 설정된 Azure Firewall: Azure Firewall은 패킷 콘텐츠를 조사하고 암호를 해독합니다. HTTP 프록시 역할을 하며 IP 주소를 유지하도록 HTTP 헤더를 X-Forwarded-For 설정할 수 있습니다. 그러나 클라이언트에 자체 생성된 인증서를 제공합니다. 인터넷 기반 애플리케이션의 경우 자체 생성 인증서를 사용하는 것은 브라우저에서 애플리케이션 클라이언트로 보안 경고가 전송되기 때문에 옵션이 아닙니다.

인터넷 기반 애플리케이션에 대한 유일한 유효한 옵션인 처음 두 옵션에서 Azure Firewall은 헤더를 설정하지 않고 들어오는 트래픽에 SNAT를 X-Forwarded-For 적용합니다. 따라서 애플리케이션은 HTTP 요청의 원래 IP 주소를 볼 수 없습니다. 문제 해결과 같은 관리 작업의 경우 Azure Firewall의 SNAT 로그와 상관 관계를 지정하여 특정 연결에 대한 실제 클라이언트 IP 주소를 가져올 수 있습니다.

TLS 검사를 사용하고 자체 생성된 인증서를 클라이언트에 제시하지 않는 한 Azure Firewall은 Application Gateway로 가는 암호화된 트래픽만 볼 수 있으므로 이 시나리오의 이점은 제한적입니다. 이 시나리오는 일반적으로 내부 애플리케이션에 대해서만 가능합니다. 그러나 이 디자인이 선호되는 시나리오가 있을 수 있습니다. 한 가지 시나리오는 다른 웹 애플리케이션 방화벽이 네트워크 앞부분에 있는 경우(예: Azure Front Door 사용) HTTP 헤더에서 원래 원본 IP를 캡처할 수 있는 X-Forwarded-For 경우입니다. Application Gateway가 단일 IP 주소를 지원하기 때문에 많은 공용 IP 주소가 필요한 경우에도 이 디자인을 선호할 수 있습니다.

공용 인터넷의 HTTP(S) 인바운드 흐름은 Azure Firewall의 공용 IP 주소를 대상으로 해야 합니다. Azure Firewall은 Application Gateway의 개인 IP 주소로 패킷을 DNAT 및 SNAT합니다. 다른 Azure 가상 네트워크 또는 온-프레미스 네트워크에서 HTTP(S) 트래픽은 Application Gateway 개인 IP 주소로 전송되고 UDR을 사용하여 Azure Firewall을 통해 전달되어야 합니다. 표준 가상 네트워크 라우팅을 사용하면 DNAT 규칙이 사용된 경우 Azure VM의 반환 트래픽이 Application Gateway 및 Application Gateway에서 Azure Firewall로 돌아갑니다. 온-프레미스 또는 Azure의 트래픽의 경우 Application Gateway 서브넷에서 UDR을 사용합니다. 자세한 내용은 이 문서의 뒷부분에 있는 패킷 워크를 참조하세요. Azure VM에서 인터넷으로의 모든 아웃바운드 트래픽은 UDR을 통해 Azure Firewall을 통해 전송됩니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

흐름	Application Gateway/웹 애플리케이션 방화벽을 통과합니다.	Azure Firewall을 통과합니다.
인터넷 또는 온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	예
Azure에서 인터넷 또는 온-프레미스로의 HTTP(S) 트래픽	아니요	예
인터넷 또는 온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	아니요	예
Azure에서 인터넷 또는 온-프레미스로의 비 HTTP(S) 트래픽	아니요	예

인바운드 HTTP(S) 트래픽의 경우 Azure Firewall은 일반적으로 트래픽의 암호를 해독하지 않습니다. 대신 IP 주소 기반 필터링 또는 HTTP 헤더 사용과 같이 TLS 검사가 필요하지 않은 IDPS 정책을 적용합니다.

건축학

애플리케이션에서 웹 트래픽의 원래 원본 IP 주소를 볼 수 없습니다. Azure Firewall은 가상 네트워크에 들어오는 패킷에 SNAT를 적용합니다. 이 문제를 방지하려면 방화벽 앞에 Azure Front Door 사용합니다. Azure Front Door는 Azure 가상 네트워크에 들어가기 전에 클라이언트의 IP 주소를 HTTP 헤더로 삽입합니다.

Azure Firewall 이후의 Application Gateway를 보여 주는

워크플로

공용 인터넷의 네트워크 트래픽은 다음 흐름을 따릅니다.

1. 클라이언트는 Azure Firewall의 공용 IP 주소에 대한 연결을 시작합니다.

   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AzFWPIP

2. Azure Firewall 공용 IP 주소에 대한 요청은 이 예제에 있는 방화벽의 백 엔드 인스턴스에 배포됩니다 192.168.100.7 . Azure Firewall은 웹 포트(일반적으로 TCP 443)에 APPLICATION Gateway 인스턴스의 개인 IP 주소에 DNAT를 적용합니다. DNAT를 수행할 때 Azure Firewall도 SNAT를 적용합니다. 자세한 내용은알려진 Azure Firewall 문제 참조하세요.

   • Azure Firewall 인스턴스의 개인 IP 주소인 원본 IP 주소: 192.168.100.7
   • 대상 IP 주소: 192.168.200.4

3. Application Gateway는 연결을 처리하는 인스턴스와 백 엔드 서버 중 하나 간에 새 세션을 설정합니다. 클라이언트의 원래 IP 주소가 패킷에 없습니다.

   • Application Gateway 인스턴스의 개인 IP 주소인 원본 IP 주소: 192.168.200.7
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-For 머리글: 192.168.100.7

4. VM은 원본 및 대상 IP 주소를 모두 반대로 하는 Application Gateway에 응답합니다.

   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7

5. Application Gateway는 Azure Firewall 인스턴스의 SNAT 원본 IP 주소에 회신합니다. Azure Firewall은 애플리케이션 게이트웨이 .4의 내부 IP 주소를 원본 IP 주소로 확인하며, 연결이 같은 .7특정 Application Gateway 인스턴스에서 오는 경우에도 발생합니다.

   • 원본 IP 주소: 192.168.200.4
   • 대상 IP 주소: 192.168.100.7

6. Azure Firewall은 SNAT 및 DNAT를 실행 취소하고 클라이언트에 응답합니다.

   • 원본 IP 주소: AzFwPIP
   • 대상 IP 주소: ClientPIP

Application Gateway에는 애플리케이션에 대해 구성된 수신기가 없더라도 Microsoft에서 관리할 수 있도록 공용 IP 주소가 필요합니다.

온-프레미스 클라이언트

앞의 디자인은 모두 공용 인터넷에서 들어오는 애플리케이션 클라이언트를 표시합니다. 온-프레미스 네트워크도 애플리케이션에 액세스합니다. 대부분의 이전 정보 및 트래픽 흐름은 인터넷 클라이언트와 동일하지만 몇 가지 주목할 만한 차이점이 있습니다.

• VPN Gateway 또는 ExpressRoute 게이트웨이는 Azure Firewall 또는 Application Gateway 앞에 있습니다.

• 웹 애플리케이션 방화벽은 Application Gateway의 개인 IP 주소를 사용합니다.

• Azure Firewall은 개인 IP 주소에 대한 DNAT를 지원하지 않으므로 UDR을 사용하여 VPN 또는 ExpressRoute 게이트웨이에서 Azure Firewall로 인바운드 트래픽을 보내야 합니다.

• Application Gateway 및 Azure Firewall에 대한 강제 터널링과 관련된 주의 사항을 확인해야 합니다. 워크로드가 공용 인터넷에 대한 아웃바운드 연결이 필요하지 않더라도 제어 트래픽을 중단하기 때문에 온-프레미스 네트워크를 가리키는 Application Gateway와 같은 0.0.0.0/0 기본 경로를 삽입할 수 없습니다. Application Gateway의 경우 기본 경로는 공용 인터넷을 가리킵니다.

건축학

다음 다이어그램에서는 Application Gateway 및 Azure Firewall 병렬 디자인을 보여 줍니다. 애플리케이션 클라이언트는 VPN 또는 ExpressRoute를 통해 Azure에 연결된 온-프레미스 네트워크에서 제공됩니다.

VPN 또는 ExpressRoute 게이트웨이를 사용하는 하이브리드 디자인을 보여 주는

모든 클라이언트가 온-프레미스 또는 Azure에 있더라도 Application Gateway 및 Azure Firewall에는 공용 IP 주소가 있어야 합니다. 이러한 공용 IP 주소를 사용하면 Microsoft에서 서비스를 관리할 수 있습니다.

허브 및 스포크 토폴로지

이 문서의 디자인은 허브 및 스포크 토폴로지에 적용됩니다. 중앙 허브 가상 네트워크의 공유 리소스는 가상 네트워크 피어링을 통해 별도의 스포크 가상 네트워크의 애플리케이션에 연결됩니다.

건축학

• Azure Firewall은 중앙 허브 가상 네트워크에 배포됩니다. 이전 다이어그램에서는 허브에 Application Gateway를 배포하는 방법을 보여 줍니다. 애플리케이션 팀은 Application Gateway 또는 API Management 게이트웨이와 같은 구성 요소를 관리하는 경우가 많습니다. 이 시나리오에서는 이러한 구성 요소가 스포크 가상 네트워크에 배포됩니다.

• 스포크 네트워크의 UDR에 특히 주의하세요. 스포크에 있는 애플리케이션 서버가 이전 예제의 IP 주소와 같은 192.168.100.7 특정 Azure Firewall 인스턴스에서 트래픽을 수신하는 경우 반환 트래픽을 동일한 인스턴스로 다시 보내야 합니다. 스포크에서 UDR이 허브로 주소가 지정된 트래픽의 다음 홉을 Azure Firewall IP 주소(192.168.100.4 이전 다이어그램)로 설정하는 경우 반환 패킷은 다른 Azure Firewall 인스턴스에서 끝날 수 있습니다. 이 경우 비대칭 라우팅이 발생합니다. 스포크 가상 네트워크에 UDR이 있는 경우 Azure Firewall을 통해 허브의 공유 서비스에 트래픽을 보내야 합니다. 이러한 UDR은 Azure Firewall 서브넷의 접두사를 포함하지 않습니다.

• 이전 권장 사항은 Application Gateway 서브넷 및 허브 가상 네트워크에 배포될 수 있는 다른 NVA 또는 역방향 프록시에 동일하게 적용됩니다.

• 다음 홉 유형의 Virtual Network있는 정적 경로를 통해 Application Gateway 또는 Azure Firewall 서브넷에 대한 다음 홉을 설정할 수 없습니다. 이 다음 홉 유형은 가상 네트워크 피어링이 아닌 로컬 가상 네트워크에서만 유효합니다. UDR 및 다음 홉 유형에 대한 자세한 내용은 가상 네트워크 트래픽 라우팅을 참조하세요.

비대칭 라우팅

다음 다이어그램에서는 스포크에서 Azure Firewall의 Azure 부하 분산 장치로 SNAT 트래픽을 다시 보내는 방법을 보여 줍니다. 이 설정으로 인해 비대칭 라우팅이 발생합니다.

이 문제를 해결하려면 Azure Firewall 서브넷이 없고 공유 서비스가 있는 서브넷만 사용하여 스포크에서 UDR을 정의합니다. 이전 다이어그램에서는 스포크에서 올바른 UDR만 포함 192.168.1.0/24해야 합니다. 빨간색으로 표시된 전체 범위를 192.168.0.0/16포함해서는 안 됩니다.

다른 Azure 제품과의 통합

Azure Firewall 및 Application Gateway를 다른 Azure 제품 및 서비스와 통합할 수 있습니다.

API Management 게이트웨이

API Management 게이트웨이와 같은 역방향 프록시 서비스를 이전 디자인에 통합하여 API 제한 또는 인증 프록시와 같은 기능을 제공합니다. API Management 게이트웨이 통합은 디자인에 큰 영향을 주지 않습니다. 주요 차이점은 단일 Application Gateway 역방향 프록시 대신 서로 뒤에 연결된 두 개의 역방향 프록시가 있다는 것입니다.

자세한 내용은 가상 네트워크에 API Management 및 Application Gateway를 통합하는 디자인 가이드와마이크로 서비스에 대한 애플리케이션 패턴 API 게이트웨이를 참조하세요.

AKS

AKS 클러스터에서 실행되는 워크로드의 경우 클러스터와 독립적으로 Application Gateway를 배포할 수 있습니다. 또는 Application Gateway 수신 컨트롤러를 사용하여 AKS 클러스터와 통합할 수 있습니다. 서비스 및 수신과 같은 Kubernetes 수준에서 특정 개체를 구성하면 추가 수동 단계 없이 Application Gateway가 자동으로 조정됩니다.

Azure Firewall은 AKS 클러스터 보안에서 중요한 역할을 합니다. IP 주소뿐만 아니라 FQDN을 기반으로 AKS 클러스터에서 송신 트래픽을 필터링하는 데 필요한 기능을 제공합니다. 자세한 내용은 AKS에서 Azure Firewall을 사용하여 네트워크 트래픽 제한을 참조하세요.

Application Gateway와 Azure Firewall을 결합하여 AKS 클러스터를 보호하는 경우 병렬 디자인 옵션을 사용하는 것이 가장 좋습니다. 웹 애플리케이션 방화벽을 사용하는 Application Gateway는 클러스터의 웹 애플리케이션에 대한 인바운드 연결 요청을 처리합니다. Azure Firewall은 명시적으로 허용된 아웃바운드 연결만 허용합니다. 병렬 디자인 옵션에 대한 자세한 내용은 AKS 클러스터에 대한 기준 아키텍처를 참조하세요.

Azure Front Door (Azure의 웹 트래픽 관리 서비스)

Azure Front Door 에는 여러 영역에서 Application Gateway와 겹치는 기능이 있습니다. 두 서비스 모두 웹 애플리케이션 방화벽, SSL 오프로드 및 URL 기반 라우팅을 제공합니다. 그러나 중요한 차이점은 Application Gateway가 가상 네트워크 내에서 작동하지만 Azure Front Door는 분산된 글로벌 서비스라는 점입니다.

Application Gateway를 분산된 Azure Front Door로 대체하여 가상 네트워크 디자인을 간소화할 수 있습니다. 이 문서에 설명된 대부분의 디자인은 Azure Front Door 앞에 Azure Firewall을 배치하는 옵션을 제외하고 여전히 적용됩니다.

한 가지 시나리오는 가상 네트워크의 Application Gateway 앞에서 Azure Firewall을 사용하는 것입니다. Application Gateway는 X-Forwarded-For 클라이언트의 IP 주소가 아닌 방화벽 인스턴스의 IP 주소로 헤더를 삽입합니다. 해결 방법은 트래픽이 가상 네트워크에 들어가 Azure Firewall에 도달하기 전에 방화벽 앞에 Azure Front Door를 사용하여 클라이언트의 IP 주소를 헤더로 X-Forwarded-For 삽입하는 것입니다. Azure Front Door Premium에서 Azure Private Link를 사용하여 원본을 보호할 수도 있습니다.

두 서비스 간의 차이점 또는 각 서비스 사용 시기에 대한 자세한 내용은 Azure Front Door에 대한 질문과 대답을 참조하세요.

기타 NVA

Microsoft 제품은 Azure에서 웹 애플리케이션 방화벽 또는 차세대 방화벽 기능을 구현하는 유일한 선택은 아닙니다. 다양한 Microsoft 파트너가 NVA를 제공합니다. 개념과 디자인은 기본적으로 이 문서와 동일하지만 몇 가지 중요한 고려 사항이 있습니다.

• 차세대 방화벽을 위한 파트너 NVA는 Azure Firewall에서 지원하지 않는 NAT 구성에 대해 더 많은 제어 및 유연성을 제공할 수 있습니다. 예를 들어 온-프레미스의 DNAT 또는 SNAT가 없는 인터넷의 DNAT가 있습니다.

• Application Gateway 및 Azure Firewall과 같은 Azure 관리 NVA는 사용자가 여러 어플라이언스에서 확장성 및 복원력을 처리해야 하는 NVA에 비해 복잡성을 줄입니다.

• Azure에서 NVA를 사용하는 경우 이러한 어플라이언스가 가상 네트워크에서 실행되는 애플리케이션에 대해 병목 상태가 되지 않도록 활성-활성 및 자동 크기 조정 설정을 사용합니다.

참여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

주 작성자:

• 호세 모레노 | 수석 고객 엔지니어

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

구성 요소 기술에 대해 자세히 알아보세요.

• Application Gateway란?
• Azure Firewall이란?
• Azure Front Door란?
• AKS
• Virtual Network란?
• 웹 애플리케이션 방화벽이란?
• AKS 클러스터를 위한 기본 아키텍처

관련 리소스

관련 아키텍처 살펴보기:

• 보안 하이브리드 네트워크 구현
• 안전하게 관리되는 웹 애플리케이션
• Azure의 다중 테넌트 소프트웨어 as a Service
• App Service Environment를 사용하여 엔터프라이즈 배포
• App Service Environment를 사용하여 고가용성 엔터프라이즈 배포