앱 서비스 환경의 네트워킹 고려 사항

Important

이 문서는 격리된 App Service 요금제와 함께 사용되는 App Service Environment v2에 대해 설명합니다. App Service Environment v2는 2024년 8월 31일에 사용 중지됩니다. 사용하기 더 쉽고 더 강력한 인프라에서 실행되는 새로운 버전의 App Service Environment가 있습니다. 새 버전에 대한 자세한 내용은 App Service Environment 소개를 참조하세요. 현재 App Service Environment v2를 사용 중인 경우 이 문서의 단계에 따라 새 버전으로 마이그레이션합니다.

2024년 1월 29일부터 ARM/Bicep 템플릿, Azure Portal, Azure CLI 또는 REST API를 포함하여 사용 가능한 방법을 사용하여 더 이상 새로운 App Service Environment v2 리소스를 만들 수 없습니다. 리소스 삭제 및 데이터 손실을 방지하려면 2024년 8월 31일 마이그레이션에 App Service Environment v3으로 마이그레이션해야 합니다.

App Service Environment는 Azure App Service를 고객 Azure 가상 네트워크의 서브넷에 배포됩니다. App Service Environment를 배포하는 두 가지 유형이 있습니다.

• 외부: 이 배포 유형은 인터넷에서 액세스할 수 있는 IP 주소를 사용하여 호스트된 앱을 노출합니다. 자세한 내용은 외부 App Service Environment 만들기를 참조하세요.
• 내부 부하 분산 장치: 이 배포 유형은 가상 네트워크 내부의 IP 주소에 호스트된 앱을 노출합니다. 내부 엔드포인트는 내부 부하 분산 장치입니다 자세한 내용은 내부 부하 분산 장치 App Service Environment 만들기 및 사용을 참조하세요.

참고 항목

이 문서는 격리된 App Service 요금제와 함께 사용되는 App Service Environment v2에 대해 설명합니다.

배포 유형에 관계없이 모든 App Service Environment에서 공용 VIP(가상 IP)를 사용합니다. 이 VIP는 App Service Environment에서 인터넷으로 호출할 때 인바운드 관리 트래픽 및 주소로 사용됩니다. 이러한 호출은 App Service Environment에 할당된 VIP를 통해 가상 네트워크를 떠납니다.

앱이 가상 네트워크 또는 VPN의 리소스를 호출하는 경우 원본 IP는 서브넷의 IP 중 하나입니다. App Service Environment는 가상 네트워크 내부에 있으므로 추가 구성 없이 가상 네트워크 내부의 리소스에 액세스할 수 있습니다. 가상 네트워크가 온-프레미스 네트워크에 연결되어 있으면 앱이 추가 구성 없이 해당 네트워크의 리소스에도 액세스할 수 있습니다.

 

외부 배포를 사용하는 App Service Environment가 있는 경우 공용 VIP는 앱이 다음을 확인하는 엔드포인트이기도 합니다.

• HTTP/S
• FTP/S
• 웹 배포
• 원격 디버깅

내부 부하 분산 장치 배포를 사용하는 App Service Environment가 있는 경우 내부 주소의 주소는 HTTP/S, FTP/S, 웹 배포 및 원격 디버깅에 대한 엔드포인트입니다.

서브넷 크기

App Service Environment가 배포된 후에는 호스트하는 데 사용되는 서브넷의 크기를 변경할 수 없습니다. App Service Environment는 격리된 각 App Service 계획 인스턴스뿐만 아니라 각 인프라 역할에 대한 주소를 사용합니다. 또한 Azure 네트워킹은 생성된 모든 서브넷에 5개 주소를 사용합니다.

App Service 요금제가 전혀 없는 App Service Environment는 앱을 만들기 전에 12개의 주소를 사용합니다. 내부 부하 분산 장치 배포를 사용하는 경우 앱을 만들기 전에 13개의 주소를 사용합니다. 스케일 아웃할 때, 인프라 역할은 App Service 요금제 인스턴스의 15 및 20배마다 추가됩니다.

Important

App Service Environment 이외에는 어떤 것도 서브넷에 포함하면 안 됩니다. 향후 확장이 가능한 주소 공간을 선택해야 합니다. 이 설정은 나중에 변경할 수 없습니다. 주소 256개를 포함할 수 있는 /24 크기를 사용하는 것이 좋습니다.

규모를 확장 또는 축소할 때 적절한 크기의 새 역할이 추가된 다음, 워크로드가 현재 크기에서 대상 크기로 마이그레이션됩니다. 원본 VM은 워크로드가 마이그레이션된 후에만 제거됩니다. 예를 들어 App Service 요금제 인스턴스가 100개인 App Service Environment가 있는 경우 VM 수를 두 배로 늘려야 하는 기간이 있습니다.

인바운드 및 아웃바운드 종속성

다음 섹션에서는 App Service Environment에 대해 알아야 하는 종속성을 다룹니다. 또 다른 섹션에서는 DNS 설정에 대해 설명합니다.

인바운드 종속성

App Service Environment가 작동하려면 다음 포트가 열려 있어야 합니다.

사용	From	수행할 작업
관리	App Service 관리 주소	App Service Environment 서브넷: 454, 455
App Service Environment 내부 통신	App Service Environment 서브넷: 모든 포트	App Service Environment 서브넷: 모든 포트
Azure Load Balancer 인바운드 허용	Azure Load Balancer	App Service Environment 서브넷: 16001

포트 7564 및 1221은 포트 검사에서 열린 것으로 표시될 수 있습니다. 두 포트는 IP 주소를 사용하여 회신하고, 그 외에는 아무 것도 하지 않습니다. 원한다면 두 포트를 차단할 수 있습니다.

인바운드 관리 트래픽은 시스템 모니터링 외에도 App Service Environment의 명령 및 제어를 제공합니다. 이 트래픽의 원본 주소 목록은 App Service Environment 관리 주소에 있습니다. 즉, 네트워크 보안 구성이 포트 454 및 455에서 App Service Environment 관리 주소로부터의 액세스를 허용해야 합니다. 해당 주소의 액세스를 차단하면 App Service Environment가 비정상화된 다음, 일시 중단됩니다. 포트 454 및 455에서 들어오는 TCP 트래픽은 동일한 VIP에서 되돌아 가야 합니다. 그렇지 않으면 비대칭 라우팅 문제가 발생합니다.

서브넷 내에는 내부 구성 요소 통신에 사용된 많은 포트가 있으며 변경할 수 있습니다. 이를 위해서는 서브넷에 있는 모든 포트를 서브넷에서 액세스할 수 있어야 합니다.

Azure Load Balancer 및 App Service Environment 서브넷 간의 통신을 위해서는 적어도 454, 455 및 16001 포트가 열려 있어야 합니다. 내부 부하 분산 장치 배포를 사용하는 경우 트래픽을 454, 455 및 16001 포트로 고정할 수 있습니다. 외부 배포를 사용하는 경우 정상적인 앱 액세스 포트를 고려해야 합니다. 특히 다음을 고려해야 합니다.

사용할 용어	Ports
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Visual Studio 원격 디버깅	4020, 4022, 4024
웹 배포 서비스	8172

애플리케이션 포트를 차단하는 경우 App Service Environment는 계속 작동하지만 앱이 작동하지 않을 수 있습니다. 앱에서 할당한 IP 주소를 외부 배포에 사용하는 경우 앱에 할당된 IP에서 서브넷으로의 트래픽을 허용해야 합니다. App Service Environment 포털에서 IP 주소로 이동하여 트래픽을 허용해야 하는 포트를 확인하세요.

아웃바운드 종속성

아웃바운드 액세스의 경우 App Service Environment는 여러 외부 시스템에 종속됩니다. 이러한 여러 시스템 종속성은 대부분 DNS 이름으로 정의되며 고정된 IP 주소 세트에 매핑되지 않습니다. 따라서 App Service Environment는 여러 포트를 통해 서브넷에서 모든 외부 IP에 아웃바운드로 액세스할 수 있어야 합니다.

App Service Environment는 다음 포트에서 인터넷에 액세스할 수 있는 주소를 전달합니다.

사용	Ports
DNS	53
NTP	123
CRL, Windows 업데이트, Linux 종속성, Azure 서비스	80/443
Azure SQL	1433
모니터링	12000

아웃바운드 종속성은 App Service Environment 잠금에 나열되어 있습니다. App Service Environment가 해당 종속성에 액세스하지 못하는 경우 작동이 중지됩니다. 오랫동안 이 상태가 유지되면 App Service Environment가 일시 중단됩니다.

고객 DNS

가상 네트워크가 고객 정의 DNS 서버로 구성된 경우 테넌트 워크로드가 해당 서버를 사용합니다. App Service Environment는 관리 목적으로 Azure DNS를 사용합니다. 가상 네트워크가 고객이 선택한 DNS로 구성된 경우 서브넷에서 DNS 서버에 연결할 수 있어야 합니다.

참고 항목

App Service Environment v2의 스토리지 탑재 또는 컨테이너 이미지 끌어오기는 가상 네트워크에서 또는 WEBSITE_DNS_SERVER 앱 설정을 통해 고객 정의 DNS를 사용할 수 없습니다.

웹앱에서 DNS 확인을 테스트하기 위해 콘솔 명령 nameresolver를 사용할 수 있습니다. 앱에 대한 scm 사이트에서 디버그 창으로 이동하거나 포털의 앱으로 이동하고 콘솔을 선택합니다. 셸 프롬프트에서 조회하려는 DNS 이름과 함께 nameresolver 명령을 실행할 수 있습니다. 얻게 되는 결과는 동일한 조회를 수행하는 동안 앱이 얻는 결과와 동일합니다. nslookup을 사용하는 경우 Azure DNS를 대신 사용하여 조회가 수행됩니다.

App Service Environment가 있는 가상 네트워크의 DNS 설정을 변경하면 다시 부팅해야 합니다. 다시 부팅하지 않으려면 App Service Environment를 만들기 전에 가상 네트워크에 대한 DNS 설정을 구성하는 것이 좋습니다.

포털 종속성

이전 섹션에서 설명한 종속성 외에도 포털 환경과 관련된 몇 가지 추가 고려 사항을 알아 두어야 합니다. Azure Portal의 일부 기능은 SCM(서비스 제어 관리자) 사이트에 직접 액세스합니다. Azure App Service의 모든 앱에는 URL이 두 개 있습니다. 첫 번째 URL은 앱에 액세스하는 것입니다. 두 번째 URL은 Kudu 콘솔이라고도 하는 SCM 사이트에 액세스하는 것입니다. SCM 사이트를 사용하는 기능은 다음과 같습니다.

• 웹 작업
• 함수
• 스트리밍 로그
• Kudu
• 확장
• Process Explorer
• 콘솔

내부 부하 분산 장치를 사용하는 경우 가상 네트워크 외부에서 SCM 사이트에 액세스할 수 없습니다. 일부 기능은 앱의 SCM 사이트에 액세스해야 하기 때문에 앱 포털에서 작동하지 않습니다. 포털을 사용하는 대신 SCM 사이트에 직접 연결할 수 있습니다.

내부 부하 분산 장치의 도메인 이름이 contoso.appserviceenvironment.net이고 앱 이름이 testapp이면 앱이 testapp.contoso.appserviceenvironment.net에서 연결됩니다. 앱과 함께 제공되는 SCM 사이트는 testapp.scm.contoso.appserviceenvironment.net에서 연결됩니다.

IP 주소

App Service Environment에서 몇 개의 IP 주소를 알아 두어야 합니다. 화면은 다음과 같습니다.

• 공용 인바운드 IP 주소: 외부 배포의 앱 트래픽과 내부 및 외부 배포의 관리 트래픽에 사용됩니다.
• 아웃바운드 공용 IP: 가상 네트워크를 떠나는 아웃바운드 연결의 "원본" IP로 사용됩니다. 이러한 연결은 VPN을 통해 라우팅되지 않습니다.
• 내부 부하 분산 장치 IP 주소: 이 주소는 내부 배포에만 존재합니다.
• 앱 할당 IP 기반 TLS/SSL 주소: 이러한 주소는 외부 배포와 IP 기반 TLS/SSL 바인딩이 구성된 경우에만 사용 가능합니다.

이 모든 IP 주소는 App Service Environment UI의 Azure Portal에서 확인할 수 있습니다. 내부 배포가 있는 경우 내부 부하 분산 장치의 IP가 나열됩니다.

참고 항목

App Service Environment가 실행되는 한 이러한 IP 주소는 변경되지 않습니다. App Service Environment가 일시 중단되었다가 복원되면 사용되는 주소가 변경됩니다. 일반적으로 인바운드 관리 액세스를 차단하거나 종속성에 대한 액세스를 차단할 때 일시 중단됩니다.

앱에 할당된 IP 주소

외부 배포를 사용하면 IP 주소를 개별 앱에 할당할 수 있습니다. 내부 배포를 사용하면 불가능합니다. 고유한 IP 주소를 사용하도록 앱을 구성하는 방법에 대한 자세한 내용은 Azure App Service에서 TLS/SSL 바인딩을 사용하여 사용자 지정 DNS 이름 보호를 참조하세요.

앱에 고유한 IP 기반 SSL 주소가 있는 경우 App Service Environment는 해당 IP 주소에 매핑하도록 두 개의 포트를 예약합니다. 한 포트는 HTTP 트래픽용이고, 다른 포트는 HTTPS용입니다. 이러한 포트는 App Service Environment 포털의 IP 주소 섹션에 나열됩니다. 트래픽은 VIP에서 이러한 포트에 연결할 수 있어야 합니다. 그렇지 않으면 앱에 액세스할 수 없습니다. NSG(네트워크 보안 그룹)를 구성할 때는 이 요구 사항을 고려해야 합니다.

네트워크 보안 그룹

NSG는 가상 네트워크 내에서 네트워크 액세스를 제어하는 기능을 제공합니다. 포털을 사용할 때는 모든 항목을 거부하는 최저 우선 순위의 암시적 거부 규칙이 있습니다. 허용 규칙은 사용자가 직접 작성합니다.

App Service Environment 자체를 호스트하는 데 사용되는 VM에는 액세스할 수 없습니다. 이러한 VM은 Microsoft에서 관리하는 구독에 있습니다. 앱에 대한 액세스를 제한하려면 서브넷에 대해 NSG를 설정합니다. 이 과정에서 종속성에 유의하세요. 종속성을 차단하면 App Service Environment 작동이 중지됩니다.

NSG는 Azure Portal 또는 PowerShell을 통해 구성할 수 있습니다. 이 문서에서는 Azure Portal의 정보를 제공합니다. 네트워킹 아래에서 최상위 리소스로 포털에서 NSG를 만들고 관리합니다.

NSG에서 필요한 항목은 트래픽을 허용하는 것입니다.

인바운드

• 포트 454, 455의 IP 서비스 태그 AppServiceManagement에서 TCP
• 포트 16001의 부하 분산 장치에서 TCP
• App Service Environment 서브넷에서 모든 포트의 App Service Environment 서브넷으로

아웃바운드

• 포트 53의 모든 IP로 UDP
• 포트 123의 모든 IP로 UDP
• 포트 80, 443의 모든 IP로 TCP
• 포트 1433의 IP 서비스 태그 Sql로 TCP
• 포트 12000의 모든 IP로 TCP
• 모든 포트의 App Service Environment 서브넷으로

이러한 포트에는 앱을 성공적으로 사용하기 위해 필요한 포트가 포함되지 않습니다. 예를 들어 앱이 포트 3306에서 MySQL 서버를 호출해야 할 때가 있습니다. 포트 123의 NTP(Network Time Protocol)는 운영 체제에서 사용하는 시간 동기화 프로토콜입니다. NTP 엔드포인트는 App Service와 관련이 없고 운영 체제에 따라 다를 수 있으며, 잘 정의된 주소 목록에 포함되지 않습니다. 시간 동기화 문제를 방지하려면 포트 123의 모든 주소에 대한 UDP 트래픽을 허용해야 합니다. 포트 12000 트래픽에 대한 아웃바운드 TCP는 시스템 지원 및 분석을 위한 것입니다. 엔드포인트가 동적이며 잘 정의된 주소 집합에 없습니다.

기본 앱 액세스 포트는 다음과 같습니다.

사용할 용어	Ports
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Visual Studio 원격 디버깅	4020, 4022, 4024
웹 배포 서비스	8172

기본 규칙을 사용하면 가상 네트워크의 IP가 서브넷과 통신할 수 있습니다. 공용 VIP라고도 하는 부하 분산 장치가 App Service Environment와 통신할 수 있도록 하는 또 다른 기본 규칙도 있습니다. 기본 규칙을 확인하려면 추가 아이콘 옆에 있는 기본 규칙을 선택합니다.

기본 규칙 앞에 기타 모든 항목을 거부하는 규칙을 배치하면 VIP와 App Service Environment 간의 트래픽이 차단됩니다. 가상 네트워크 내에서 들어오는 트래픽을 차단하려면 인바운드를 허용하는 규칙을 직접 추가합니다. 이때 대상이 Any이고 포트 범위가 *인 AzureLoadBalancer와 같은 원본을 사용합니다. NSG 규칙은 서브넷에 적용되므로 대상을 구체적으로 지정할 필요는 없습니다.

앱에 IP 주소를 할당한 경우 포트를 열어 두어야 합니다. 포트를 확인하려면 App Service Environment>IP 주소를 선택합니다.  

NSG를 정의한 후에는 서브넷에 할당합니다. 가상 네트워크 또는 서브넷이 기억 나지 않는 경우 App Service Environment 포털에서 확인할 수 있습니다. 서브넷에 NSG를 할당하려면 서브넷 UI로 이동한 다음 NSG를 선택합니다.

경로

강제 터널링은 아웃바운드 트래픽이 인터넷으로 직접 이동하지 않도록 가상 네트워크에서 경로를 설정하는 것입니다. 그 대신 트래픽은 Azure ExpressRoute 게이트웨이 또는 가상 어플라이언스 같은 다른 곳으로 이동합니다. 이러한 방식으로 App Service Environment를 구성해야 하는 경우 강제 터널링을 사용하여 App Service Environment 구성을 참조하세요.

포털에서 App Service Environment를 만들 때 서브넷에 경로 테이블 세트가 자동으로 생성됩니다. 이러한 경로는 단순히 아웃바운드 트래픽을 인터넷에 직접 보내도록 합니다.

동일한 경로를 수동으로 만들려면 다음 단계를 수행합니다.

1. Azure Portal로 이동하여 네트워킹>경로 테이블을 선택합니다.

2. 가상 네트워크와 동일한 지역에 새 경로 테이블을 만듭니다.

3. 경로 테이블 UI 내에서 경로>추가를 선택합니다.

4. 다음 홉 형식을 인터넷으로, 주소 접두사를 0.0.0.0/0으로 설정합니다. 저장을 선택합니다.

   다음과 유사한 출력이 표시됩니다.

   

5. 새 경로 테이블을 만든 후에는 서브넷으로 이동합니다. Portal의 목록에서 경로 테이블을 선택합니다. 변경 내용을 저장하면 서브넷이 표시된 경로와 NSG를 확인할 수 있습니다.

   

서비스 엔드포인트

서비스 엔드포인트를 사용하면 Azure 가상 네트워크 및 서브넷 세트에 다중 테넌트 서비스에 대한 액세스를 제한할 수 있습니다. 자세한 내용은 가상 네트워크 서비스 엔드포인트를 참조하세요.

리소스에서 서비스 엔드포인트를 사용하는 경우 다른 모든 경로에 우선해 만든 경로가 있습니다. Azure 서비스에서 서비스 엔드포인트를 사용하고 강제 터널된 App Service Environment를 사용하는 경우 해당 서비스에 대한 트래픽은 강제 터널링되지 않습니다.

Azure SQL 인스턴스를 통해 서브넷에서 서비스 엔드포인트가 사용되는 경우 해당 서브넷에서 연결된 모든 Azure SQL 인스턴스는 서비스 엔드포인트를 사용할 수 있어야 합니다. 동일한 서브넷에서 여러 Azure SQL 인스턴스에 액세스하려는 경우 다른 Azure SQL 인스턴스가 아닌 한 Azure SQL 인스턴스에서 서비스 엔드포인트를 사용할 수 없습니다. 서비스 엔드포인트와 관련하여 Azure SQL과 같은 다른 Azure 서비스는 작동하지 않습니다. Azure Storage에서 서비스 엔드포인트를 사용하도록 설정하면 서브넷에서 해당 리소스에 대한 액세스가 고정됩니다. 서비스 엔드포인트를 사용하도록 설정하지 않은 경우에도 다른 Azure Storage 계정에 액세스할 수 있습니다.