Application Gateway에 대한 질문과 대답입니다.

Azure Application Gateway는 애플리케이션 제공 컨트롤러를 서비스로 제공합니다. 애플리케이션에 다양한 레이어 7 부하 분산 기능을 제공합니다. 이 서비스는 Azure에서 관리하는 고가용성의 확장성 있는 완전 관리형 서비스입니다.

Application Gateway는 자동 스케일링, TLS 오프로딩, 엔드투엔드 TLS, WAF(웹 애플리케이션 방화벽), 쿠키 기반 세션 선호도, URL 경로 기반 라우팅, 다중 사이트 호스팅 및 기타 기능을 지원합니다. 지원되는 기능의 전체 목록은 Application Gateway 소개를 참조하세요.

Application Gateway는 웹 트래픽(HTTP, HTTPS, WebSocket 및 HTTP/2)에서만 작동하는 레이어 7 부하 분산 장치로써 TLS 종료, 쿠키 기반 세션 선호도, 트래픽 부하 분산을 위한 라운드 로빈 등의 기능을 지원합니다. Load Balancer는 레이어 4(TCP 또는 UDP)에서 트래픽 부하를 분산합니다.

Application Gateway는 HTTP, HTTPS, HTTP/2 및 WebSocket을 지원합니다.

HTTP/2 지원을 참조하세요.

지원되는 백 엔드 리소스를 참조하세요.

Application Gateway v1(표준 및 WAF)는 Azure 전체의 모든 지역에서 사용할 수 있습니다. 21Vianet이 운영하는 Microsoft Azure와 Azure Government에서도 사용할 수 있습니다.

Application Gateway v2(Standard_v2 및 WAF_v2) 가용성은 지원되는 Application Gateway v2 지역을 참조하세요.

Application Gateway는 가상 네트워크에서 전용 배포입니다.

리디렉션은 지원됩니다. Application Gateway 리디렉션 개요를 참조하세요.

수신기 처리 순서를 참조하세요.

공용 IP 주소를 엔드포인트로 사용하는 경우 공용 IP 주소 리소스에서 IP 및 DNS 정보를 찾습니다. 또는 Azure Portal의 애플리케이션 게이트웨이 개요 페이지에서 찾을 수 있습니다. 내부 IP 주소를 사용하는 경우 개요 페이지에서 정보를 확인하세요. v1 SKU의 경우 2023년 5월 1일 이후에 만든 게이트웨이에는 공용 IP 리소스와 자동으로 연결된 기본 DNS 이름이 없습니다. v2 SKU의 경우 공용 IP 리소스를 열고 구성을 선택합니다. DNS 이름 레이블(옵션) 필드를 사용하여 DNS 이름을 구성할 수 있습니다.

Keep-Alive 시간 제한은 클라이언트에서 영구 연결을 다시 사용하거나 닫기 전에 다른 HTTP 요청을 보낼 때까지 애플리케이션 게이트웨이에서 대기하는 시간을 제어합니다. TCP 유휴 시간 제한은 작업이 없을 때 TCP 연결을 계속 유지하는 시간을 제어합니다.

Application Gateway v1 SKU에서는 Keep-Alive 시간 제한이 120초이고 v2 SKU에서는 75초입니다. 개인 IP 주소의 경우 TCP 유휴 시간 제한이 5분인 값을 구성할 수 없습니다. TCP 유휴 시간 제한은 Application Gateway v1 및 v2 SKU의 프런트 엔드 VIP(가상 IP)에서 기본적으로 4분입니다. v1, v2 Application Gateway 인스턴스의 TCP 유휴 시간 제한 값은 4분에서 30분 사이로 구성할 수 있습니다. v1, v2 Application Gateway 인스턴스에서는 모두 애플리케이션 게이트웨이의 공용 IP로 이동하여 포털에 있는 공용 IP 구성 창에서 TCP 유휴 시간 제한을 변경해야 합니다. 다음 명령을 실행하여 PowerShell을 통해 공용 IP의 TCP 유휴 시간 제한 값을 설정할 수 있습니다.

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Application Gateway v2 SKU의 프런트 엔드 IP 주소에 HTTP/2를 연결하는 경우 유휴 시간 제한은 180초로 설정되며 구성할 수 없습니다.

예. Application Gateway는 백 엔드 서버와의 기존 TCP 연결을 다시 사용합니다.

아니요. Application Gateway 리소스의 이름은 바꿀 수 없습니다. 다른 이름으로 새 리소스를 만들어야 합니다.

아니요. 삭제 후 Application Gateway 리소스 또는 공용 IP를 복원할 수 있는 방법은 없습니다. 새 리소스를 만들어야 합니다.

Application Gateway v1 SKU에서 애플리케이션 게이트웨이를 중지했다가 시작하면 VIP가 변경될 수 있습니다. 그러나 애플리케이션 게이트웨이와 연결된 DNS 이름은 게이트웨이 수명 주기 중에 변경되지 않습니다. DNS 이름은 변경되지 않으므로 CNAME 별칭을 사용하고 해당 별칭이 애플리케이션 게이트웨이의 DNS 주소를 가리키도록 설정해야 합니다. Application Gateway v2 SKU에서 IP 주소는 고정적이므로 애플리케이션 게이트웨이의 수명 중에 IP 주소와 DNS 이름이 변경되지 않습니다.

예. Application Gateway v2 SKU는 고정 공용 IP 주소와 고정 내부 IP를 지원합니다. v1 SKU는 고정 내부 IP를 지원합니다.

애플리케이션 게이트웨이는 IP 프로토콜당 하나의 공용 IP 주소만 지원합니다. 애플리케이션 게이트웨이가 DualStack으로 구성된 경우 두 개의 공용 IP(IPv4용 및 IPv6용)를 지원할 수 있습니다.

Application Gateway 서브넷 크기 고려 사항을 참조하세요.

예. 지정된 Application Gateway 배포의 여러 인스턴스 외에도, 다른 애플리케이션 게이트웨이 리소스를 포함하는 기존 서브넷에 다른 고유한 Application Gateway 리소스를 프로비저닝할 수 있습니다.

단일 서브넷은 v2 및 v1 Application Gateway SKU를 둘 다 지원할 수 없습니다.

예, 하지만 특정 시나리오에서만 지원합니다. 자세한 내용은 Application Gateway 인프라 구성을 참조하세요.

예. 요청 수정을 참조하세요.

새 Application Gateway v1 SKU 배포 시 프로비전하는 데 최대 20분이 걸릴 수 있습니다. 인스턴스 크기 또는 수를 변경해도 중단되지 않으며, 게이트웨이는 이 시간 동안 활성 상태를 유지합니다.

v2 SKU를 사용하는 대부분의 배포는 프로비저닝하는 데 약 6분이 소요됩니다. 그러나 배포 유형에 따라 프로세스가 더 오래 걸릴 수 있습니다. 예를 들어 인스턴스가 많이 있는 여러 가용성 영역에 배포하는 경우 6분 넘게 걸릴 수 있습니다.

Application Gateway에 대해 시작된 업데이트는 한 번에 하나의 업데이트 도메인에 적용됩니다. 각 업데이트 도메인의 인스턴스가 업데이트되면 다른 업데이트 도메인에 남아 있는 인스턴스에서 트래픽을 계속 제공합니다¹. 업데이트가 시작되기 전에 다른 업데이트 도메인의 인스턴스에 대한 연결을 설정하는 데 도움이 되도록 최대 5분 동안 업데이트되는 인스턴스에서 활성 연결이 정상적으로 드레이닝됩니다. 업데이트하는 동안 Application Gateway는 구성된 인스턴스 수에 따라 결정되는 감소된 최대 용량으로 일시적으로 실행됩니다. 현재 인스턴스 세트가 성공적으로 업그레이드된 경우에만 업데이트 프로세스가 다음 인스턴스 세트로 진행됩니다.

¹ 업데이트가 적용되는 동안 하나 이상의 인스턴스에서 트래픽을 제공할 수 있도록 Application Gateway v1 SKU 배포의 최소 인스턴스 수를 2로 구성하는 것이 좋습니다.

Application Gateway는 미리 보기의 계층 4 프록시 를 통해 TLS/TCP 프로토콜 프록시를 지원합니다.

HTTP(S) 프로토콜을 사용하는 애플리케이션 게이트웨이의 계층 7 프록시는 SMTP, IMAP 및 POP3와 같은 이메일 프로토콜을 지원하지 않습니다. 그러나 OWA(Outlook Web Access), ActiveSync 및 HTTP(S) 프로토콜을 사용하는 자동 검색 트래픽과 같은 일부 지원 전자 메일 서비스의 경우 계층 7 프록시를 사용할 수 있으며 해당 트래픽은 통과해야 합니다. (참고: WAF SKU를 사용하는 경우 WAF 규칙의 제외가 필요할 수 있습니다).

예. 자세한 내용은 Azure Application Gateway 및 웹 애플리케이션 방화벽을 v1에서 v2로 마이그레이션을 참조하세요.

예. Application Gateway v1 SKU는 계속 지원됩니다. 해당 SKU의 기능 업데이트를 활용하려면 v2로 이동하는 것이 좋습니다. v1 기능과 v2 기능의 차이점에 대한 자세한 내용은 자동 크기 조정 및 영역 중복 Application Gateway v2를 참조하세요. v1-v2 마이그레이션 설명서에 따라 Application Gateway v1 SKU 배포를 v2로 수동 마이그레이션할 수 있습니다.

아니요. Application Gateway v2는 NTLM 또는 Kerberos 인증을 사용한 프록시 요청을 지원하지 않습니다.

요청 헤더 이름에는 영숫자와 하이픈이 포함될 수 있습니다. 다른 문자가 포함된 요청 헤더 이름은 요청을 백 엔드 대상으로 보낼 때 삭제됩니다. 헤더 이름은 RFC 7230에 정의된 대로 영숫자 문자와 특정 기호를 포함할 수 있습니다.

예. Chromium 브라우저v80 업데이트에서는 SameSite 특성이 없는 HTTP 쿠키를 SameSite=Lax로 처리해 달라는 요구를 수락했습니다. 즉, 타사 컨텍스트에서는 브라우저가 Application Gateway 선호도 쿠키를 보내지 않습니다.

이 시나리오를 지원하기 위해 Application Gateway는 기존 ApplicationGatewayAffinity 쿠키 외에 ApplicationGatewayAffinityCORS라는 또 다른 쿠키를 삽입합니다. 이러한 쿠키는 유사하지만, ApplicationGatewayAffinityCORS 쿠키에 SameSite=None 및 Secure의 두 가지 특성이 추가되었습니다. 이러한 특성은 원본 간 요청에서도 고정 세션을 유지합니다. 자세한 내용은 쿠키 기반 선호도 섹션을 참조하세요.

활성 수신기는 규칙에 연결되고 트래픽을 백 엔드 풀로 전송하는 수신기입니다. 트래픽을 리디렉션만 하는 수신기는 활성 수신기가 아닙니다. 리디렉션 규칙과 연결된 수신기는 활성으로 간주되지 않습니다. 리디렉션 규칙이 경로 기반 규칙인 경우 해당 리디렉션 규칙의 모든 경로는 트래픽을 리디렉션해야 합니다. 그렇지 않으면 수신기가 활성 상태로 간주됩니다. 개별 구성 요소 제한에 대한 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

인스턴스를 2개 이상 배포한 경우 Application Gateway v1 SKU는 고가용성 시나리오를 지원합니다. 모든 인스턴스가 동시에 실패하는 일이 없도록, Azure는 이러한 인스턴스를 업데이트 및 장애 도메인에 배포합니다. v1 SKU는 로드를 공유하기 위해 동일한 게이트웨이의 여러 인스턴스를 추가하여 확장성을 지원합니다.

v2 SKU의 경우에는 여러 장애 도메인과 업데이트 도메인에 새 인스턴스가 자동으로 분산됩니다. 영역 중복을 선택하면 영역 장애 시의 복원력을 제공하기 위해 최신 인스턴스도 여러 가용성 영역에 분산됩니다.

Azure Traffic Manager를 사용하여 다양한 데이터 센터에 있는 여러 애플리케이션 게이트웨이에 트래픽을 분산할 수 있습니다.

예. 중지 없이 백 엔드 풀 내에서 멤버를 변경하도록 연결 드레이닝을 설정할 수 있습니다. 자세한 내용은 Application Gateway 연결 드레이닝 섹션을 참조하세요.

예. Application Gateway v2 SKU는 자동 크기 조정을 지원합니다. 자세한 내용은 자동 크기 조정 및 영역 중복 Application Gateway를 참조하세요.

아니요. 인스턴스가 업그레이드 도메인 및 장애 도메인 간에 배포됩니다.

예.

예.

예. Application Gateway는 항상 가상 네트워크 서브넷에 배포됩니다. 이 서브넷은 애플리케이션 게이트웨이만 포함할 수 있습니다. 자세한 내용은 가상 네트워크 및 서브넷 요구 사항을 참조하세요.

IP 연결이 설정되어 있으면 Application Gateway가 현재 속한 가상 네트워크의 외부에 있는 인스턴스와 통신할 수 있습니다. 또한 Application Gateway는 현재 속한 구독 외부의 인스턴스와 통신할 수 있습니다. 백 엔드 풀 멤버로 내부 IP를 사용할 계획이면 가상 네트워크 피어링 또는 Azure VPN Gateway가 필요합니다.

DNS 확인자와 마찬가지로 Application Gateway 리소스는 백 엔드 서버의 DNS 레코드 중 TTL(Time to Live) 값을 적용합니다. TTL이 만료되면 게이트웨이에서 조회를 수행하여 해당 DNS 정보를 업데이트합니다. 이 조회 과정에서 애플리케이션 게이트웨이가 응답을 받는 데 문제가 발생(하거나 DNS 레코드를 찾을 수 없음)하는 경우 게이트웨이는 마지막으로 알려진 정상 DNS 값을 사용하여 트래픽을 처리합니다. 자세한 내용은 애플리케이션 게이트웨이의 작동 원리를 참조하세요.

애플리케이션 게이트웨이의 인스턴스는 이름 확인을 위해 가상 네트워크의 DNS 구성을 사용합니다. DNS 서버 구성이 변경되면 새 DNS 서버가 할당되도록 애플리케이션 게이트웨이를 다시 시작(중지 및 시작)해야 합니다. 그때까지는 아웃바운드 연결에 대한 FQDN 기반 이름 확인이 실패할 수 있습니다.

아니요. 그러나 서브넷에 다른 애플리케이션 게이트웨이를 배포할 수 있습니다.

동일한 가상 네트워크 내의 서브넷에서만 애플리케이션 게이트웨이를 이동할 수 있습니다. 퍼블릭/프라이빗 프런트 엔드(동적 할당)가 있는 v1과 퍼블릭 프런트 엔드만 있는 v2에서 지원됩니다. 프라이빗 프런트 엔드 IP 구성이 정적으로 할당된 경우 애플리케이션 게이트웨이를 다른 서브넷으로 이동할 수 없습니다. 이 작업을 수행하려면 애플리케이션 게이트웨이가 중지됨 상태여야 합니다. v1을 중지하거나 시작하면 공용 IP가 변경됩니다. 이 작업은 다음 명령을 실행하여 Azure PowerShell 및 Azure CLI를 통해서만 수행할 수 있습니다.

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

자세한 내용은 Set-AzApplicationGatewayIPConfiguration을 참조하세요.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Application Gateway 서브넷의 네트워크 보안 그룹을 참조하세요.

Application Gateway 서브넷에서 지원되는 사용자 정의 경로를 참조하세요.

아니요. 스토리지 계정에 대한 서비스 엔드포인트 정책은 Application Gateway 서브넷에서 지원되지 않으며, 이를 구성하면 Azure 인프라 트래픽이 차단됩니다.

Application Gateway 제한을 참조하세요.

예. Application Gateway는 애플리케이션 게이트웨이마다 내부 IP 하나와 외부 IP 하나를 지원합니다.

예. 가상 네트워크 피어링은 다른 가상 네트워크의 트래픽 부하를 분산하는 데 도움이 됩니다.

예, 트래픽이 허용되기만 한다면 가능합니다.

마이크로서비스 아키텍처가 지원됩니다. 다양한 포트에서 검색하려면 여러 백 엔드 설정을 구성해야 합니다.

아니요.

처리 규칙 순서를 참조하세요.

호스트 필드는 Application Gateway에서 다중 사이트를 구성한 경우 프로브를 보낼 이름을 지정합니다. 지정하지 않으면 127.0.0.1이 사용됩니다. 이 값은 가상 머신 호스트 이름과 다릅니다. 형식은 <프로토콜>://<호스트>:<포트><경로>입니다.

예. 특정 원본 IP로 액세스 제한을 참조하세요.

예, 포트 번호가 동일한 퍼블릭 연결 수신기와 프라이빗 연결 수신기를 사용하여 퍼블릭 클라이언트와 프라이빗 클라이언트를 동시에 지원할 수 있습니다. NSG(네트워크 보안 그룹)가 애플리케이션 게이트웨이의 서브넷과 연결되는 경우 해당 구성에 따라 특정 인바운드 규칙이 필요할 수도 있습니다. 자세히 알아보기

Application Gateway v2는 IPv4 및 IPv6 프런트 엔드를 지원합니다. 현재 IPv6 지원 기능은 새 애플리케이션 게이트웨이에서만 사용할 수 있습니다. IPv6를 지원하려면 가상 네트워크가 이중 스택이어야 합니다. Application Gateway v1은 이중 스택 가상 네트워크를 지원하지 않습니다.

Application Gateway v1 SKU는 일반적으로 "FIPS 모드"라고 하는 FIPS 140-2 승인 작업 모드에서 실행할 수 있습니다. FIPS 모드는 FIPS 140-2 유효성이 검사된 암호화 모듈을 호출하여 암호화, 해싱 및 서명에 대한 FIPS 규격 알고리즘을 사용하도록 설정할 때 이러한 알고리즘을 보장합니다. FIPS 모드를 사용하도록 하려면 FIPSmode 구성을 사용하도록 구독을 등록한 후 PowerShell, Azure Resource Manager template 또는 REST API를 통해 FIPSMode 설정을 구성해야 합니다.

Application Gateway v2는 현재 공개 미리 보기를 통해 프라이빗 IP 프런트 엔드 구성만 지원합니다(공용 IP 지원 안 함). 자세한 내용은 프라이빗 Application Gateway 배포(미리 보기)를 참조하세요.

현재 일반 공급을 지원하기 위해 Application Gateway v2에서 지원하는 조합은 다음과 같습니다.

• 개인 IP 및 공용 IP
• 공용 IP 전용

현재 기능이 포함된 개인 IP 주소로만 트래픽을 제한하려면 다음 프로세스를 따릅니다.

1. 퍼블릭/프라이빗 프런트 엔드 IP 주소를 모두 사용하는 애플리케이션 게이트웨이를 만듭니다.

2. 공용 프런트 엔드 IP 주소용 수신기를 만들지 않습니다. Application Gateway는 수신기가 만들어지지 않은 경우 공용 IP 주소에서 트래픽을 수신 대기하지 않습니다.

3. 다음 구성을 우선 순위 순서대로 사용하여 Application Gateway 서브넷에 대한 네트워크 보안 그룹을 만들고 연결합니다.

   1. 원본의 트래픽을 GatewayManager 서비스 태그로, 대상을 모두로, 대상 포트를 65200-65535로 허용합니다. 이 포트 범위는 Azure 인프라 통신에 필요합니다. 이러한 포트는 인증서 인증을 통해 보호(잠금)됩니다. 게이트웨이 사용자 관리자를 비롯한 외부 엔터티에서는 적절한 인증서 없이 엔드포인트 변경 작업을 시작할 수 없습니다.

   2. 원본의 트래픽을 AzureLoadBalancer 서비스 태그로, 대상 포트를 모두로 허용합니다.

   3. 원본의 모든 인바운드 트래픽을 인터넷 서비스 태그로, 대상 포트를 모두로 거부합니다. 인바운드 규칙에서 이 규칙에 가장 낮은 우선 순위를 지정합니다.

   4. 개인 IP 주소에 대한 액세스가 차단되지 않도록 AllowVNetInBound 같은 기본 규칙을 유지합니다.

   5. 아웃바운드 인터넷 연결은 차단할 수 없습니다. 그렇지 않으면 로깅, 메트릭 관련 문제가 발생합니다.

개인 IP 전용 액세스를 위한 NSG 구성 샘플:

Azure PowerShell 또는 Azure CLI를 사용하여 Application Gateway를 중지했다가 시작하면 됩니다. Application Gateway를 중지하고 시작하면 청구도 중지되고 시작됩니다. 중지된 애플리케이션 게이트웨이에서 수행된 PUT 작업(예: 태그, 상태 프로브 또는 수신기 추가)은 시작을 트리거합니다. 구성을 업데이트한 후에는 애플리케이션 게이트웨이를 중지하는 것이 좋습니다.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway는 자체 서명된 인증서, CA(인증 기관) 인증서, EV(확장 유효성 검사) 인증서, 다중 도메인(SAN) 인증서 및 와일드 카드 인증서를 지원합니다.

Application Gateway는 다음과 같은 암호화 도구 모음을 지원합니다.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS 옵션을 사용자 지정하는 방법은 Application Gateway에서 TLS 정책 버전 및 암호 그룹 구성을 참조하세요.

예. Application Gateway는 TLS 오프로드와 백 엔드로의 트래픽을 다시 암호화하는 엔드투엔드 TLS를 지원합니다.

예. TLS1.0, TLS1.1 및 TLS1.2를 거부하도록 Application Gateway를 구성할 수 있습니다. SSL 2.0 및 3.0은 기본적으로 비활성화되며 구성할 수 없습니다.

예. Application Gateway에서는 암호 그룹을 구성할 수 있습니다. 사용자 지정 정책을 정의하려면 다음 암호화 도구 모음 중 하나 이상을 사용합니다.

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway는 백 엔드 관리에 SHA256을 사용합니다.

Application Gateway는 최대 100의 TLS/SSL 인증서를 지원합니다.

예, Application Gateway는 서버 인증서에 대해 OCSP 확장 및 OCSP 스테이플링을 사용하는 인증서를 지원합니다.

Application Gateway는 최대 100의 인증 인증서를 지원합니다.

예, Application Gateway v2 SKU는 Key Vault를 지원합니다. 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

다중 도메인 기반(호스트 기반) 라우팅의 경우 다중 사이트 수신기를 만들고, HTTPS를 프로토콜로 사용하는 수신기를 설정하고, 수신기를 회람 규칙과 연결할 수 있습니다. 자세한 내용은 Application Gateway를 사용하여 여러 사이트 호스팅을 참조하세요.

아니요. .pfx 파일 암호에는 영숫자 문자만 사용합니다.

CA/Browser 구성원은 CA 공급업체에서 발급하고, 최근 공개적으로 신뢰할 수 있는 CA 산업 표준을 준수하지 않는 고객, Microsoft 및 대규모 기술 커뮤니티에서 사용되는 여러 인증서에 대해 자세히 설명하는 보고서를 발표했습니다. 비규격 CA와 관련된 보고서는 다음 위치에서 찾아볼 수 있습니다.

• Bug 1649951
• Bug 1650910

업계 규정 준수 요구 사항에 따라 CA 공급업체는 비규격 CA를 해지하고 규격 CA를 발급하기 시작했습니다. 따라서 고객은 인증서를 재발급받아야 합니다. Microsoft는 Azure 서비스에 미치는 잠재적 영향을 최소화하기 위해 이러한 공급업체와 긴밀히 협력하고 있습니다. 그러나 BYOC(Bring Your Own Certificate) 시나리오에서 사용되는 자체 발급 인증서는 여전히 예기치 않게 해지될 위험이 있습니다.

애플리케이션에 사용되는 인증서가 해지되었는지 확인하려면 DigiCert 발표 및 인증서 해지 추적기를 참조하세요. 인증서가 해지되었거나 해지될 예정인 경우, 애플리케이션에서 사용되는 새 인증서를 CA 공급업체에 요청해야 합니다. 인증서가 예기치 않게 해지되어 애플리케이션의 가용성이 중단되는 일이 발생하지 않도록 하거나 해지된 인증서를 업데이트하려면, Revocation of noncompliant Certificate Authorities potentially impacting customer's Azure services(고객의 Azure 서비스에 영향을 미칠 수 있는 비규격 인증 기관의 해지)를 참조하세요.

Application Gateway와 관련된 자세한 내용:

해지된 ICA 중 하나가 발급한 인증서를 사용하는 경우 애플리케이션의 가용성이 중단될 수 있습니다. 애플리케이션에 따라 다음을 포함하나 이에 국한되지 않는 다양한 오류 메시지가 표시될 수도 있습니다.

• 잘못된 인증서/해지된 인증서
• 연결 시간이 초과됨
• HTTP 502

이 문제로 인해 애플리케이션이 중단되는 일이 없도록 하거나 해지된 CA를 재발급하려면 다음 작업을 수행해야 합니다.

1. 인증서 다시 발급 방법을 인증서 공급자에게 문의합니다.
2. 재발급받았으면 전체 신뢰 체인(리프, 중간, 루트 인증서)을 사용하여 Azure Application Gateway/WAF에서 인증서를 업데이트합니다. 애플리케이션 게이트웨이의 수신기 또는 HTTP 설정에서 인증서를 사용하는 위치를 기준으로 하여 다음 단계에 따라 인증서를 업데이트합니다. 자세한 내용은 언급된 설명서 링크를 확인하세요.
3. 재발급된 인증서를 사용하려면 백 엔드 애플리케이션 서버를 업데이트합니다. 사용 중인 백 엔드 서버에 따라 인증서 업데이트 단계가 다를 수도 있습니다. 공급업체의 설명서를 확인합니다.

수신기에서 인증서를 업데이트하려면 다음을 수행합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서와 연결된 수신기 설정을 엽니다.
3. 선택한 인증서 갱신 또는 편집을 클릭합니다.
4. 암호를 사용하여 새 PFX 인증서를 업로드하고 저장을 선택합니다.
5. 웹 사이트에 액세스하여 사이트가 예상대로 작동하는지 확인합니다. 자세한 내용은 Application Gateway 인증서 갱신을 참조하세요.

Application Gateway 수신기에서 Key Vault의 인증서를 참조하는 경우 빠르게 변경하려면 다음 단계를 수행하는 것이 좋습니다.

1. Azure Portal에서 애플리케이션 게이트웨이와 연결된 Key Vault 설정으로 이동합니다.
2. 저장소에서 재발급된 인증서를 추가하거나 가져옵니다. 자세한 내용은 빠른 시작: Azure Portal을 사용하여 키 자격 증명 모음 만들기를 참조하세요.
3. 인증서를 가져왔으면 Application Gateway 수신기 설정으로 이동하여 Key Vault에서 인증서 선택에서 인증서 드롭다운을 선택하고 최근에 추가된 인증서를 선택합니다.
4. 저장을 선택합니다. Key Vault 인증서를 사용하는 Application Gateway의 TLS 종료에 대한 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

HTTP 설정에서 인증서를 업데이트하려면 다음을 수행합니다.

Application Gateway/WAF 서비스의 v1 SKU를 사용하는 경우 새 인증서를 백 엔드 인증 인증서로 업로드해야 합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서와 연결된 HTTP 설정을 엽니다.
3. 인증서 추가를 선택하고 재발급된 인증서를 업로드한 다음 저장을 선택합니다.
4. 나중에 이전 인증서 옆에 있는 ... 옵션 단추를 선택하여 이전 인증서를 제거할 수 있습니다. 삭제를 선택한 후 예를 선택합니다. 자세한 내용은 포털에서 Application Gateway를 사용하여 엔드투엔드 TLS 구성을 참조하세요.

Application Gateway/WAF 서비스의 V2 SKU를 사용하는 경우 V2 SKU는 "신뢰할 수 있는 루트 인증서"를 사용하므로 HTTP 설정에서 새 인증서를 업로드할 필요가 없으며 여기에서 작업을 수행할 필요가 없습니다.

예. 애플리케이션 게이트웨이를 통한 계층 7 및 계층 4 라우팅은 모두 동일한 프런트 엔드 IP 구성을 사용합니다. 이렇게 하면 모든 클라이언트를 단일 IP 주소(퍼블릭 또는 프라이빗)로 보낼 수 있으며, 동일한 게이트웨이 리소스는 구성된 수신기 프로토콜 및 포트에 따라 라우팅합니다.

HTTP(S) 트래픽도 L4 프록시 프로토콜을 통해 제공될 수 있지만 그렇게 하지 않는 것이 좋습니다. Application Gateway의 L7 프록시 솔루션은 재작성, 세션 선호도, 리디렉션, WebSockets, WAF 등의 고급 기능을 통해 HTTP(S) 프로토콜에 대한 제어 및 보안을 강화합니다.

계층 4 기능에 대한 리소스 속성은 계층 7 기능과 다릅니다. 따라서 REST API 또는 CLI를 사용하는 경우 다음 속성을 사용해야 합니다.

• REST API
• CLI

아니요. 계층 4 및 계층 7 속성을 교차 연결할 수 없습니다. 따라서 라우팅 규칙을 사용하면 계층 4 형식 수신기를 계층 4 형식 백 엔드 설정에만 연결할 수 있습니다.

L7(httpListeners) 및 L4(수신기)에는 동일한 이름을 사용할 수 없습니다. 백 엔드설정Collection 및 routingRules와 같은 다른 L4 속성에도 적용됩니다.

물론 그렇습니다. 계층 7 프록시와 마찬가지로 애플리케이션 게이트웨이의 백 엔드 풀에 프라이빗 엔드포인트를 추가할 수 있습니다. 이 프라이빗 엔드포인트는 애플리케이션 게이트웨이의 동일한 가상 네트워크의 인접한 서브넷에 배포되어야 합니다.

백 엔드 연결에는 Keepalive를 사용하지 않습니다. 프런트 엔드 수신기 연결에서 들어오는 각 요청에 대해 Application Gateway는 해당 요청을 수행하기 위해 새 백 엔드 연결을 시작합니다.

백 엔드 서버는 애플리케이션 게이트웨이의 IP 주소를 확인합니다. 현재는 백 엔드 애플리케이션이 원래 클라이언트의 IP 주소를 인식할 수 있는 "클라이언트 IP 유지"를 지원하지 않습니다.

동일한 SSL 정책 구성은 계층 7(HTTPS)과 TLS(계층 4) 모두에 적용됩니다. 현재 TLS 수신기에 대한 SSL 프로필(수신기별 SSL 정책 또는 상호 인증)은 지원되지 않습니다.

아니요. 클라이언트를 동일한 백 엔드 서버로 라우팅하는 것은 현재 지원되지 않습니다. 연결은 라운드 로빈 방식으로 백 엔드 풀의 서버에 배포됩니다.

예, 자동 크기 조정 기능은 TLS 또는 TCP 프로토콜의 트래픽 급증 및 감소에도 작동합니다.

WAF(웹 애플리케이션 방화벽) 기능은 계층 4 사용에서 작동하지 않습니다.

아니요. 현재 UDP 지원을 사용할 수 없습니다.

Kubernetes를 사용하면 deployment 및 service 리소스를 만들어서 클러스터 내부에서 Pod 그룹을 공개할 수 있습니다. 외부에서 동일한 서비스를 공개하기 위해 부하 분산, TLS 종료 및 이름 기반 가상 호스팅을 제공하는 Ingress 리소스가 정의됩니다. 이 Ingress 리소스를 충족하려면, Ingress 리소스의 변경 내용을 수신 대기하고 부하 분산 장치 정책을 구성하는 수신 컨트롤러가 필요합니다.

AGIC(Application Gateway Ingress Controller)를 사용하면 Azure Application Gateway를 AKS 클러스터라고도 하는 Azure Kubernetes Service의 수신으로 사용할 수 있습니다.

현재는 수신 컨트롤러 인스턴스 하나를 애플리케이션 게이트웨이 하나에만 연결할 수 있습니다.

AGIC에서 경로 테이블 리소스를 Application Gateway 서브넷에 자동으로 연결하려고 시도하지만, AGIC의 권한이 부족하여 이를 수행하지 못할 수도 있습니다. AGIC에서 경로 테이블을 Application Gateway 서브넷에 연결하지 못하면 AGIC 로그에 오류가 나타납니다. 이 경우 AKS 클러스터에서 만든 경로 테이블을 Application Gateway의 서브넷에 수동으로 연결해야 합니다. 자세한 내용은 지원되는 사용자 정의 경로를 참조하세요.

예, 가상 네트워크가 피어링되어 있고 주소 공간이 겹치지 않는 한 가능합니다. kubenet을 사용하는 AKS를 실행하는 경우, AKS에서 생성한 경로 테이블을 Application Gateway 서브넷에 연결해야 합니다.

Helm을 통해 배포된 AGIC와 AKS 추가 항목으로 배포된 AGIC 간의 차이점은 Helm 배포와 AKS 추가 항목 간의 차이점을 참조하세요.

Helm을 통해 배포된 AGIC와 AKS 추가 항목으로 배포된 AGIC 간의 차이점은 Helm 배포와 AKS 추가 항목 간의 차이점, 특히 AKS 추가 항목이 아닌 Helm을 통해 배포된 AGIC에서 지원하는 시나리오를 문서화한 표를 참조하세요. 일반적으로 Helm을 통해 배포하면 공식 릴리스 전에 베타 기능 및 릴리스 후보를 테스트할 수 있습니다.

아니요. AGIC 추가 항목은 관리되는 서비스입니다. 즉, Microsoft가 추가 항목을 최신 안정화 버전으로 자동 업데이트합니다.

상호 인증은 클라이언트와 서버 간의 양방향 인증입니다. 현재까지 Application Gateway에서는 상호 인증을 통해 게이트웨이가 클라이언트 인증인 요청을 전송하는 클라이언트를 확인할 수 있습니다. 일반적으로 클라이언트는 애플리케이션 게이트웨이를 인증하는 유일한 항목입니다. 이제는 Application Gateway도 클라이언트를 인증할 수 있기 때문에 Application Gateway와 클라이언트가 서로를 상호 인증하는 상호 인증이 되었습니다.

아니요, 상호 인증은 현재 프런트 엔드 클라이언트와 애플리케이션 게이트웨이 사이에서만 지원됩니다. 백 엔드 상호 인증은 현재 지원되지 않습니다.

Application Gateway는 다음 세 가지 로그를 제공합니다.

• ApplicationGatewayAccessLog: 이 액세스 로그에는 애플리케이션 게이트웨이 프런트 엔드에 제출된 각각의 요청이 포함되어 있습니다. 이 데이터에는 호출자의 IP, 요청된 URL, 응답 대기 시간, 반환 코드, 바이트 입출력이 포함되어 있습니다. 애플리케이션 게이트웨이마다 하나의 레코드가 포함됩니다.
• ApplicationGatewayPerformanceLog: 이 성능 로그는 각 애플리케이션 게이트웨이의 성능 정보를 캡처합니다. 이 정보에는 처리량(바이트), 처리된 총 요청 수, 실패한 요청 수, 정상 및 비정상 백 엔드 인스턴스 수가 포함됩니다.
• ApplicationGatewayFirewallLog: WAF를 사용하여 구성하는 애플리케이션 게이트웨이의 경우 방화벽 로그에 검색 모드 또는 방지 모드를 통해 기록된 요청이 포함됩니다.

모든 로그는 60초마다 수집됩니다. 자세한 내용은 Application Gateway에 대한 백 엔드 상태, 진단 로그 및 메트릭을 참조하세요.

PowerShell cmdlet Get-AzApplicationGatewayBackendHealth 또는 포털을 사용하여 상태를 확인할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

진단 로그는 고객의 스토리지 계정으로 전송됩니다. 고객은 원하는 대로 보존 정책을 설정할 수 있습니다. 진단 로그를 이벤트 허브 또는 Azure Monitor 로그에도 전송할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

포털의 애플리케이션 게이트웨이 메뉴 창에서 활동 로그를 선택하여 감사 로그에 액세스합니다.

예. Application Gateway에서 경고는 메트릭에 대해 구성됩니다. 자세한 내용은 Application Gateway 메트릭 및 경고 알림 받기를 참조하세요.

여러 가지 방법으로 액세스 로그를 살펴보고 분석할 수 있습니다. Azure Monitor 로그, Excel, Power BI 등을 사용합니다.

Application Gateway 액세스 로그에 널리 사용되는 GoAccess 로그 분석기를 설치하고 실행하는 Resource Manager 템플릿을 사용할 수도 있습니다. GoAccess는 고유 방문자, 요청한 파일, 호스트, 운영 체제, 브라우저, HTTP 상태 코드 등의 유용한 HTTP 트래픽 통계를 제공합니다. 자세한 내용은 GitHub에서 Resource Manager 템플릿 폴더의 Readme 파일을 참조하세요.

일반적으로 Application Gateway 서브넷에서 NSG, 사용자 지정 DNS 또는 사용자 정의 라우팅에 의해 백 엔드 액세스가 차단되는 경우 알 수 없는 상태가 표시됩니다. 자세한 내용은 Application Gateway에 대한 백 엔드 상태, 진단 로깅 및 메트릭을 참조하세요.

현재 플랫폼의 한계로 인해 NSG가 Application Gateway v2(Standard_v2, WAF_v2) 서브넷에 있고 여기에서 NSG 흐름 로그를 사용해 온 경우 비결정 동작이 표시됩니다. 이 시나리오는 현재 지원되지 않습니다.

Application Gateway는 배포된 지역 외부로 고객 데이터를 이동하거나 저장하지 않습니다.

다음 단계

• Application Gateway에 대한 자세한 내용은 Azure 애플리케이션 Gateway란?을 참조하세요.
• Application Gateway를 사용한 TLS 종료 및 엔드투엔드 TLS에 대해 알아보려면 Azure Application Gateway에서 엔드투엔드 TLS 사용을 참조하세요.