App Service 네트워킹 기능

여러 가지 방법으로 Azure App Service에 애플리케이션을 배포할 수 있습니다. 기본적으로 App Service에서 호스트된 앱은 인터넷을 통해 직접 액세스할 수 있으며 인터넷 호스트 엔드포인트만 연결할 수 있습니다. 그러나 많은 애플리케이션의 경우 인바운드 및 아웃바운드 네트워크 트래픽을 제어해 합니다. App Service에는 이러한 요구를 충족하는 데 도움이 되는 몇 가지 기능이 있습니다. 문제는 주어진 문제를 해결하는 데 사용할 기능을 아는 것입니다. 이 문서는 몇 가지 예제 사용 사례를 기반으로 사용할 기능을 결정하는 데 도움을 줍니다.

Azure App Service에는 두 가지 주요 배포 유형이 있습니다.

• 다중 테넌트 공용 서비스는 무료, 공유, 기본, 표준, 프리미엄, 프리미엄 V2 및 프리미엄 V3 가격 책정 SKU로 App Service 요금제를 호스트합니다.
• 단일 테넌트 ASE(App Service Environment)는 Azure 가상 네트워크에서 격리된 SKU App Service 요금제를 직접 호스트합니다.

사용하는 기능은 다중 테넌트 서비스인지 또는 ASE인지 여부에 따라 달라집니다.

참고 항목

Azure Arc에 배포된 앱에서는 네트워킹 기능을 사용할 수 없습니다.

다중 테넌트 App Service 네트워킹 기능

Azure App Service는 분산 시스템입니다. 들어오는 HTTP 또는 HTTPS 요청을 처리하는 역할을 프런트 엔드라고 합니다. 고객 워크로드를 호스트하는 역할을 작업자라고 합니다. App Service 배포의 모든 역할은 다중 테넌트 네트워크에 있습니다. 동일한 App Service 배율 단위에 여러 고객이 있으므로 App Service 네트워크를 사용자의 네트워크에 직접 연결할 수 없습니다.

네트워크를 연결하는 대신 애플리케이션 통신의 다양한 측면을 처리하는 기능이 필요합니다. 앱에 대한 요청을 처리하는 기능은 앱에서 호출하는 경우 문제를 해결하는 데 사용할 수 없습니다. 마찬가지로 앱에서의 호출에 대한 문제를 해결하는 기능은 앱에 대한 문제를 해결하는 데 사용할 수 없습니다.

인바운드 기능	아웃바운드 기능
앱 할당 주소	하이브리드 연결
액세스 제한	게이트웨이 필요 가상 네트워크 통합
서비스 엔드포인트	가상 네트워크 통합
프라이빗 엔드포인트

언급된 예외를 제외하고 이러한 모든 기능을 함께 사용할 수 있습니다. 기능을 조합하여 문제를 해결할 수 있습니다.

사용 사례 및 기능

주어진 사용 사례에 대해 몇 가지 방법으로 문제를 해결할 수 있습니다. 최상의 기능을 선택하면 때로는 사용 사례 자체를 넘어섭니다. 다음 인바운드 사용 사례는 App Service 네트워킹 기능을 사용하여 앱으로 이동하는 트래픽을 제어하는 문제를 해결하는 방법을 제안합니다.

인바운드 사용 사례	기능
앱에 대한 IP 기반 SSL 요구 사항 지원	앱 할당 주소
앱에 대한 공유되지 않은 전용 인바운드 주소 지원	앱 할당 주소
잘 정의된 주소 집합에서 앱으로의 액세스 제한	액세스 제한
가상 네트워크의 리소스에서 앱으로의 액세스 제한	서비스 엔드포인트 ILB(내부 Load Balancer) ASE 프라이빗 엔드포인트
가상 네트워크의 개인 IP에 앱 노출	ILB ASE 프라이빗 엔드포인트 서비스 엔드포인트가 포함된 Application Gateway 인스턴스의 인바운드 트래픽에 대한 개인 IP
WAF(웹 애플리케이션 방화벽)으로 앱 보호	Application Gateway 및 ILB ASE 프라이빗 엔드포인트가 있는 Application Gateway 서비스 엔드포인트가 있는 Application Gateway 액세스 제한 사항이 있는 Azure Front Door
다른 지역의 앱에 트래픽 부하 분산	액세스 제한이 있는 Azure Front Door
동일한 지역에서 트래픽 부하 분산	서비스 엔드포인트가 있는 Application Gateway

다음 아웃바운드 사용 사례는 App Service 네트워킹 기능을 사용하여 앱에 대한 아웃바운드 액세스 요구를 해결하는 방법을 제안합니다.

인바운드 사용 사례	기능
동일한 지역에서 Azure 가상 네트워크의 리소스에 액세스	가상 네트워크 통합 ASE
다른 지역에서 Azure 가상 네트워크의 리소스에 액세스	가상 네트워크 통합 및 가상 네트워크 피어링 게이트웨이 필수 가상 네트워크 통합 ASE 및 가상 네트워크 피어링
서비스 엔드포인트로 보안이 설정된 리소스에 액세스	가상 네트워크 통합 ASE
Azure에 연결되지 않은 프라이빗 네트워크의 리소스에 액세스	하이브리드 연결
Azure ExpressRoute 회로 전반의 리소스에 액세스	가상 네트워크 통합 ASE
웹 앱에서의 아웃바운드 트래픽 보호	가상 네트워크 통합 및 네트워크 보안 그룹 ASE
웹 앱에서의 아웃바운드 트래픽 라우팅	가상 네트워크 통합 및 경로 테이블 ASE

기본 네트워킹 동작

Azure App Service 배율 단위는 각 배포에서 많은 고객을 지원합니다. 무료 및 공유 SKU 플랜은 다중 테넌트 작업자의 고객 워크로드를 호스트합니다. 기본 이상의 요금제는 단 하나의 App Service 요금제만 적용되는 고객 워크로드를 호스트합니다. 표준 App Service 요금제인 경우 해당 요금제의 모든 앱이 동일한 작업자에서 실행됩니다. 작업자를 확장하는 경우 해당 App Service 요금제의 모든 앱은 App Service 요금제의 각 인스턴스에 대해 새 작업자에서 복제됩니다.

아웃바운드 주소

작업자 VM은 App Service 요금제로 크게 구분됩니다. 무료, 공유, 기본, 표준 및 프리미엄 요금제는 모두 동일한 작업자 VM 유형을 사용합니다. 프리미엄V2 요금제는 다른 VM 유형을 사용합니다. PremiumV3도 다른 VM 유형을 사용합니다. VM 제품군을 변경하면 다른 아웃바운드 주소 집합을 얻습니다. 표준에서 프리미엄V2로 크기 조정하면 아웃바운드 주소가 변경됩니다. 프리미엄V2에서 프리미엄V3로 크기를 조정하면 아웃바운드 주소가 변경됩니다. 일부 이전 배율 단위에서는 표준에서 프리미엄V2로 조정하면 인바운드 및 아웃바운드 주소가 모두 변경됩니다.

아웃바운드 호출에 사용되는 주소는 여러 가지입니다. 아웃바운드 호출을 수행하기 위해 앱에서 사용하는 아웃바운드 주소는 앱의 속성에 나열됩니다. 이러한 주소는 App Service 배포의 동일한 작업자 VM 제품군에서 실행되는 모든 앱에서 공유됩니다. 앱이 배율 단위에서 사용할 수 있는 모든 주소를 확인하려는 경우 해당 주소를 나열하는 possibleOutboundAddresses(이)라는 속성이 있습니다.

App Service에는 서비스 관리에 사용되는 여러 엔드포인트가 있습니다. 이러한 주소는 별도 문서에 게시되며 AppServiceManagement IP 서비스 태그에도 있습니다. AppServiceManagement 태그는 이러한 트래픽을 허용해야 하는 App Service Environment에서만 사용됩니다. App Service 인바운드 주소는 AppService IP 서비스 태그에서 추적됩니다. App Service에서 사용하는 아웃바운드 주소를 포함하는 IP 서비스 태그는 없습니다.

앱 할당 주소

앱 할당 주소 기능은 IP 기반 SSL 기능의 한 갈래입니다. 앱에서 SSL을 설정하여 액세스합니다. IP 기반 SSL 호출에 이 기능을 사용할 수 있습니다. 이 기능을 사용하여 앱에 고유한 주소를 앱에 제공할 수도 있습니다.

앱 할당 주소를 사용하는 경우 트래픽은 들어오는 모든 트래픽을 App Service 배율 단위로 처리하는 동일한 프런트 엔드 역할을 계속 통과합니다. 하지만 앱에 할당된 주소는 앱만 사용합니다. 이 기능에 대한 사용 사례:

• 앱에 대한 IP 기반 SSL 요구 사항 지원.
• 공유되지 않는 앱에 대한 전용 주소 설정.

앱에서 주소를 설정하는 방법을 알아보려면 Azure App Service에서 TLS/SSL 인증서 추가를 참조하세요.

액세스 제한

액세스 제한을 통해 인바운드 요청을 필터링할 수 있습니다. 필터링 작업은 앱이 실행되는 작업자 역할에서의 업스트림인 프런트 엔드 역할에서 이루어집니다. 프런트 엔드 역할은 작업자에서의 업스트림이므로 액세스 제한을 앱에 대한 네트워크 수준 보호로 생각할 수 있습니다. 액세스 제한에 대한 자세한 내용은 액세스 제한 개요를 참조하세요.

이 기능을 사용하여 우선 순위에 따라 평가되는 허용 및 거부 규칙 목록을 작성할 수 있습니다. Azure 네트워킹의 NSG(네트워크 보안 그룹) 기능과 유사합니다. ASE 또는 다중 테넌트 서비스에서 이 기능을 사용할 수 있습니다. ILB ASE에서 사용하는 경우 프라이빗 주소 블록에서의 액세스를 제한할 수 있습니다. 이 기능을 사용하도록 설정하는 방법에 대한 자세한 내용은 액세스 제한 구성을 참조하세요.

참고 항목

앱당 최대 512개의 액세스 제한 규칙을 구성할 수 있습니다.

프라이빗 엔드포인트

프라이빗 엔드포인트는 Azure Private Link로 웹앱에 비공개로 안전하게 연결하는 네트워크 인터페이스입니다. 프라이빗 엔드포인트는 가상 네트워크의 개인 IP 주소를 사용하여 웹앱을 가상 네트워크에 효과적으로 제공합니다. 이 기능은 웹 앱에 대한 인바운드 흐름에만 해당됩니다. 자세한 내용은 Azure 웹앱용 프라이빗 엔드포인트 사용을 참조하세요.

이 기능에 대한 몇 가지 사용 사례:

• 가상 네트워크의 리소스에서 앱으로의 액세스 제한.
• 가상 네트워크의 개인 IP에 앱 노출.
• WAF를 사용하여 앱 보호.

프라이빗 엔드포인트 전체에서 연결할 수 있는 대상은 프라이빗 엔드포인트가 구성된 앱뿐이므로 프라이빗 엔드포인트는 데이터 반출을 방지합니다.

하이브리드 연결

App Service 하이브리드 연결을 사용하면 앱에서 지정된 TCP 엔드포인트에 대한 아웃바운드 호출을 수행할 수 있습니다. 엔드포인트는 온-프레미스, 가상 네트워크 또는 포트 443에서 Azure로의 아웃바운드 트래픽을 허용하는 모든 위치일 수 있습니다. 이 기능을 사용하려면 Windows Server 2012 이상 호스트에 하이브리드 연결 관리자라는 릴레이 에이전트를 설치해야 합니다. 하이브리드 연결 관리자는 포트 443에서 Azure Relay에 연결할 수 있어야 합니다. 포털의 App Service 하이브리드 연결 UI에서 하이브리드 연결 관리자를 다운로드할 수 있습니다.

App Service 하이브리드 연결은 Azure Relay 하이브리드 연결 기능을 기반으로 합니다. App Service는 앱에서 TCP 호스트 및 포트로의 아웃바운드 호출만 지원하는 특수화된 형식의 기능을 사용합니다. 이 호스트 및 포트는 하이브리드 연결 관리자가 설치된 호스트에서만 확인해야 합니다.

App Service에서 앱이 하이브리드 연결에 정의된 호스트 및 포트에서 DNS 조회를 수행하는 경우 트래픽은 자동으로 리디렉션되어 하이브리드 연결을 통과하여 하이브리드 연결 관리자 외부로 이동합니다. 자세한 내용은 Azure App Service 하이브리드 연결을 참조하세요.

이 기능은 다음과 같은 경우에 일반적으로 사용됩니다.

• VPN 또는 ExpressRoute를 사용하여 Azure에 연결되지 않은 프라이빗 네트워크의 리소스에 액세스합니다.
• 지원 데이터베이스를 이동할 필요 없이 온-프레미스 앱을 App Service로 마이그레이션할 수 있습니다.
• 하이브리드 연결당 단일 호스트 및 포트에 대한 향상된 보안 기능을 포함하는 액세스를 제공합니다. 대부분의 네트워킹 기능은 네트워크에 대한 액세스를 엽니다. 하이브리드 연결을 사용하면 단일 호스트 및 포트에만 연결할 수 있습니다.
• 다른 아웃바운드 연결 방법에서 다루지 않는 시나리오를 다룹니다.
• 앱이 온-프레미스 리소스를 쉽게 사용할 수 있도록 App Service에서 개발을 수행합니다.

이 기능은 인바운드 방화벽 허점 없이 온-프레미스 리소스에 대한 액세스를 허용하므로 개발자들 사이에서 널리 사용됩니다. 다른 아웃바운드 App Service 네트워킹 기능은 Azure Virtual Network와 관련됩니다. 하이브리드 연결은 가상 네트워크 통과에 따라 다르지 않습니다. 더 광범위한 네트워킹 요구 사항에 사용할 수 있습니다.

App Service 하이브리드 연결은 연결 외에 수행하고 있는 작업을 인식하지 못합니다. 따라서 이를 사용하여 데이터베이스, 웹 서비스 또는 메인프레임의 임의의 TCP 소켓에 액세스할 수 있습니다. 이 기능은 기본적으로 TCP 패킷을 터널링합니다.

하이브리드 연결은 개발에 널리 사용되지만 프로덕션 애플리케이션에서도 사용됩니다. 웹 서비스 또는 데이터베이스에 액세스하는 것이 좋지만 많은 연결을 만드는 상황에는 적합하지 않습니다.

가상 네트워크 통합

App Service 가상 네트워크 통합을 사용하면 앱에서 Azure Virtual Network로 아웃바운드 요청을 할 수 있습니다.

가상 네트워크 통합 기능을 사용하면 Resource Manager 가상 네트워크의 서브넷에 앱의 백 엔드를 배치할 수 있습니다. 가상 네트워크는 앱과 동일한 지역에 있어야 합니다. 이 기능은 이미 가상 네트워크에 있는 App Service Environment에서 사용할 수 없습니다. 이 기능에 대한 사용 사례:

• 동일한 지역에 있는 Resource Manager 가상 네트워크의 리소스에 액세스.
• 지역 간 연결을 포함하여 피어링된 가상 네트워크의 리소스에 액세스합니다.
• 서비스 엔드포인트로 보안이 설정된 리소스에 액세스.
• ExpressRoute 또는 VPN 연결을 통해 액세스할 수 있는 리소스에 액세스.
• Virtual Network 게이트웨이의 요구 사항과 비용 없이 프라이빗 네트워크의 리소스에 액세스합니다.
• 모든 아웃바운드 트래픽을 보호하도록 도움.
• 모든 아웃바운드 트래픽을 강제로 터널링.

자세한 내용은 App Service 가상 네트워크 통합을 참조하세요.

게이트웨이 필요 가상 네트워크 통합

게이트웨이 필수 가상 네트워크 통합은 App Service의 가상 네트워크 통합의 첫 번째 버전이었습니다. 이 기능은 지점 및 사이트 간 VPN을 사용하여 앱이 실행되는 호스트를 가상 네트워크의 가상 네트워크 게이트웨이에 연결하는 방식으로 작동합니다. 이 기능을 구성할 때 앱은 각 인스턴스에 할당된 지점 및 사이트 간 할당 주소 중 하나를 가져옵니다.

게이트웨이 필수 통합을 사용하면 피어링 없이 다른 지역의 가상 네트워크에 직접 연결하고 클래식 가상 네트워크에 연결할 수 있습니다. 이 기능은 App Service Windows 계획으로 제한되며 ExpressRoute에 연결된 가상 네트워크에서는 작동하지 않습니다. 지역 가상 네트워크 통합을 사용하는 것이 좋습니다. 이 기능에 대한 자세한 내용은 App Service 가상 네트워크 통합을 참조하세요.

App Service 환경

ASE(App Service Environment)는 가상 네트워크에서 실행되는 Azure App Service의 단일 테넌트 배포입니다. 이 기능에 대한 몇 가지 사례는 다음과 같습니다.

• 가상 네트워크의 리소스에 액세스.
• ExpressRoute를 통해 리소스에 액세스.
• 가상 네트워크에서 개인 주소를 사용하여 앱 노출.
• 서비스 엔드포인트를 통해 리소스에 액세스.
• 프라이빗 엔드포인트를 통해 리소스에 액세스.

ASE를 사용하면 ASE가 이미 가상 네트워크에 있으므로 가상 네트워크 통합을 사용할 필요가 없습니다. 서비스 엔드포인트를 통해 SQL 또는 Azure Storage와 같은 리소스에 액세스하려면 ASE 서브넷에서 서비스 엔드포인트를 사용하도록 설정합니다. 가상 네트워크나 가상 네트워크의 프라이빗 엔드포인트에 있는 리소스에 액세스하려면 추가 구성을 수행할 필요가 없습니다. ExpressRoute를 통해 리소스에 액세스하려는 경우 가상 네트워크에 이미 있는 것이고 ASE 또는 그 안에 있는 앱에서 아무 것도 구성할 필요가 없습니다.

ILB ASE의 앱은 개인 IP 주소에 노출될 수 있으므로, 인터넷에 연결하려는 앱만 노출하고 나머지 보안을 유지하기 위해 WAF 디바이스를 쉽게 추가할 수 있습니다. 이 기능을 사용하면 다중 계층 애플리케이션을 보다 쉽게 개발할 수 있습니다.

일부 항목은 현재 다중 테넌트 서비스에서 가능하지 않지만 ASE에서는 가능합니다. 다음 몇 가지 예를 참조하세요.

• 단일 테넌트 서비스에서 앱을 호스팅합니다.
• 다중 테넌트 서비스에서 가능한 것보다 더 많은 인스턴스로 스케일 업합니다.
• 프라이빗 CA 보안 엔드포인트를 사용하여 앱에서 사용할 프라이빗 CA 클라이언트 인증서를 로드합니다.
• 앱 수준에서 사용하지 않게 하는 기능을 사용하지 않고도 시스템에서 호스트되는 모든 앱에서 TLS 1.2를 강제 적용합니다.

ASE는 격리된 전용 앱 호스팅에 대한 최상의 사례를 제공하지만 일부 관리 문제도 있습니다. 운영 ASE를 사용하기 전에 고려해야 하는 몇 가지 사항은 다음과 같습니다.

• ASE는 가상 네트워크 내에서 실행되지만 가상 네트워크 외부에 종속성이 있습니다. 그러한 종속성은 허용되어야 합니다. 자세한 내용은 App Service Environment에 대한 네트워킹 고려 사항을 참조하세요.
• ASE는 다중 테넌트 서비스와 마찬가지로 즉시 확장되지 않습니다. 대응적인 크기 조정보다는 크기 조정을 예상하는 것이 필요합니다.
• ASE는 선행 비용이 더 높습니다. ASE를 최대한 활용하려면 작은 활동에 사용하기보다 많은 워크로드를 하나의 ASE로 배치하도록 계획해야 합니다.
• ASE의 앱은 ASE의 일부 앱에 대한 액세스를 선택적으로 제한할 수 없습니다.
• ASE는 서브넷에 있고 모든 네트워킹 규칙은 해당 ASE로 들어오고 나가는 모든 트래픽에 적용됩니다. 하나의 앱에 대해서만 인바운드 트래픽 규칙을 할당하려면 액세스 제한을 사용합니다.

기능 결합

다중 테넌트 서비스에 대해 언급된 기능을 함께 사용하여 보다 정교한 사용 사례를 해결할 수 있습니다. 보다 일반적인 두 가지 사용 사례가 여기에 설명되어 있지만 이는 단지 예일 뿐입니다. 다양한 기능에 대해 이해하면 거의 모든 시스템 아키텍처 요구 사항을 충족할 수 있습니다.

가상 네트워크에 앱 배치

앱을 가상 네트워크에 배치하는 방법이 궁금할 수 있습니다. 앱을 가상 네트워크에 배치하는 경우 앱에 대한 인바운드 및 아웃바운드 엔드포인트는 가상 네트워크 내에 있습니다. ASE는 이 문제를 해결하는 가장 좋은 방법입니다. 하지만 기능을 결합하여 다중 테넌트 서비스 내에서 대부분의 요구 사항을 충족할 수 있습니다. 예를 들어 다음을 수행하여 프라이빗 인바운드 및 아웃바운드 주소로 인트라넷 전용 애플리케이션을 호스트할 수 있습니다.

• 프라이빗 인바운드 및 아웃바운드 주소를 사용하여 애플리케이션 게이트웨이 만들기
• 서비스 엔드포인트를 사용하여 앱에 대한 인바운드 트래픽 보안
• 앱의 백 엔드가 가상 네트워크에 있도록 가상 네트워크 통합 기능 사용

이 배포 스타일은 인터넷에 대한 아웃바운드 트래픽의 전용 주소 또는 앱에서 모든 아웃바운드 트래픽을 잠글 수 있는 기능을 제공하지 않습니다. 다른 방식으로 ASE를 사용하여 얻을 수 있는 많은 기능을 제공합니다.

다중 계층 애플리케이션 만들기

다중 계층 애플리케이션은 프런트 엔드 계층에서만 API 백 엔드 앱에 액세스할 수 있는 애플리케이션입니다. 다중 계층 애플리케이션을 만드는 방법에는 두 가지가 있습니다. 두 가지 방법 모두 가장 먼저 가상 네트워크 통합을 사용하여 프런트 엔드 웹앱을 가상 네트워크의 서브넷에 연결합니다. 이렇게 하면 웹 앱에서 가상 네트워크를 호출할 수 있습니다. 프런트 엔드 앱이 가상 네트워크에 연결된 후에는 API 애플리케이션에 대한 액세스를 잠그는 방법을 결정해야 합니다. 마케팅 목록의 구성원을 관리할 수 있습니다.

• 동일한 ILB ASE에서 프런트 엔드 및 API 앱을 모두 호스트하고 애플리케이션 게이트웨이를 사용하여 프런트 엔드 앱을 인터넷에 노출합니다.
• 다중 테넌트 서비스에서 프런트 엔드를 호스트하고 ILB ASE에서 백 엔드를 호스트합니다.
• 다중 테넌트 서비스에서 프런트 엔드 및 API 앱을 모두 호스트합니다.

다중 계층 애플리케이션의 프런트 엔드와 API 앱을 모두 호스트하면 다음을 수행할 수 있습니다.

• 가상 네트워크에서 프라이빗 엔드포인트를 사용하여 API 애플리케이션을 노출합니다.

  

• 서비스 엔드포인트를 사용하여 API 앱에 대한 인바운드 트래픽이 프런트 엔드 웹 앱에서 사용하는 서브넷에서만 들어오는지 확인합니다.

  

다음은 사용할 방법을 결정하는 데 도움이 되는 몇 가지 고려 사항입니다.

• 서비스 엔드포인트를 사용하는 경우 API 앱에서 통합 서브넷으로의 트래픽만 보호하면 됩니다. 서비스 엔드포인트를 사용하면 API 앱을 보호할 수 있지만 데이터가 프런트 엔드 앱에서 앱 서비스의 다른 앱으로 반출될 수 있습니다.
• 프라이빗 엔드포인트를 사용하는 경우 두 개의 서브넷을 사용하게 되어 복잡성이 증가합니다. 또한 프라이빗 엔드포인트는 최상위 리소스이며 관리 오버헤드를 추가합니다. 프라이빗 엔드포인트를 사용하는 이점은 데이터 반출 가능성이 없다는 것입니다.

두 방법은 여러 프런트 엔드에서 작동합니다. 작은 규모로는 프런트 엔드 통합 서브넷에서 API 앱에 대한 서비스 엔드포인트를 사용하도록 설정하면 되기 때문에 서비스 엔드포인트를 사용하는 것이 더 쉽습니다. 프런트 엔드 앱을 더 추가하면 통합 서브넷과 함께 서비스 엔드포인트가 포함되도록 모든 API 앱을 조정해야 합니다. 프라이빗 엔드포인트를 사용하는 경우 더 복잡하지만 프라이빗 엔드포인트를 설정한 후에는 API 앱에서 아무것도 변경할 필요가 없습니다.

LOB(기간 업무) 애플리케이션

LOB(기간 업무) 애플리케이션은 일반적으로 인터넷에서 액세스하는 데 노출되지 않는 내부 애플리케이션입니다. 이러한 애플리케이션은 액세스를 엄격하게 제어할 수 있는 회사 네트워크 내부에서 호출됩니다. ILB ASE를 사용하는 경우 기간 업무 애플리케이션을 쉽게 호스트할 수 있습니다. 다중 테넌트 서비스를 사용하는 경우 프라이빗 엔드포인트나 애플리케이션 게이트웨이와 결합된 서비스 엔드포인트를 사용할 수 있습니다. 프라이빗 엔드포인트를 사용하는 대신 애플리케이션 게이트웨이와 서비스 엔드포인트를 사용하는 이유는 다음 두 가지입니다.

• LOB 앱에 대한 WAF 보호가 필요합니다.
• LOB 앱의 여러 인스턴스에 부하를 분산하려고 합니다.

이러한 요구 사항에 해당하지 않는 경우 프라이빗 엔드포인트를 사용하는 것이 더 좋습니다. App Service에서 프라이빗 엔드포인트를 사용할 수 있으므로 가상 네트워크의 개인 주소에 앱을 노출할 수 있습니다. 가상 네트워크에 배치하는 프라이빗 엔드포인트는 ExpressRoute 및 VPN 연결을 통해 연결할 수 있습니다.

프라이빗 엔드포인트를 구성하면 개인 주소에 앱이 노출되지만 온-프레미스에서 해당 주소를 연결하도록 DNS를 구성해야 합니다. 이 구성이 작동하려면 프라이빗 엔드포인트를 포함하는 Azure DNS 프라이빗 영역을 온-프레미스 DNS 서버로 전달해야 합니다. Azure DNS Private Zones는 영역 전달을 지원하지 않지만 Azure DNS 프라이빗 해결 프로그램을 사용하여 영역 전달을 지원할 수 있습니다.

App Service 포트

App Service를 검색하는 경우 인바운드 연결을 위해 노출되는 여러 포트를 찾을 수 있습니다. 다중 테넌트 서비스에서 이러한 포트에 대한 액세스를 차단하거나 제어하는 방법은 없습니다. 다음은 노출되는 포트 목록입니다.

사용할 용어	포트
HTTP/HTTPS	80, 443
관리	454, 455
FTP/FTPS	21, 990, 10001~10300
Visual Studio 원격 디버깅	4020, 4022, 4024
웹 배포 서비스	8172
인프라 사용	7654, 1221