Azure 가상 네트워크에 앱 통합

참고 항목

2024년 6월 1일부터, 새로 만들어진 모든 App Service 앱에는 명명 규칙 <app-name>-<random-hash>.<region>.azurewebsites.net을 사용하여 고유한 기본 호스트 이름을 생성할 수 있는 옵션이 제공됩니다. 기존 앱 이름은 변경되지 않은 상태로 유지됩니다.

예: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

자세한 내용은 App Service 리소스의 고유 기본 호스트 이름을 참조하세요.

이 문서에서는 Azure App Service 가상 네트워크 통합 기능 및 App Service에서 앱으로 통합을 설정하는 방법을 설명합니다. Azure 가상 네트워크를 사용하면 다양한 Azure 리소스를 인터넷이 아닌 라우팅 가능한 네트워크에 배치할 수 있습니다. App Service 가상 네트워크 통합 기능을 사용하면 앱이 가상 네트워크의 리소스에 또는 가상 네트워크를 통해 리소스에 액세스할 수 있습니다.

참고 항목

게이트웨이에 필요한 가상 네트워크 통합에 대한 정보가 새 위치로 이동되었습니다.

App Service에는 다음과 같은 두 가지 변형이 있습니다.

• 전용 컴퓨팅 가격 책정 계층 - 기본, 표준, 프리미엄, 프리미엄 v2 및 프리미엄 v3가 있습니다.
• App Service Environment - 전용 지원 인프라를 사용하여 가상 네트워크에 직접 배포하며, 격리된 v2 가격 책정 계층을 사용합니다.

가상 네트워크 통합 기능은 Azure App Service 전용 컴퓨팅 가격 책정 계층에서 사용됩니다. 앱이 App Service Environment에 있는 경우 이미 가상 네트워크와 통합되어 있으므로 동일한 가상 네트워크의 리소스에 도달하기 위해 가상 네트워크 통합 기능을 구성할 필요가 없습니다. 모든 네트워킹 기능에 대한 자세한 내용은 App Service 네트워킹 기능을 참조하세요.

가상 네트워크 통합은 가상 네트워크의 리소스에 대한 액세스 권한을 앱에 부여하지만, 가상 네트워크에서 앱에 액세스할 수 있는 인바운드 프라이빗 액세스 권한은 부여하지 않습니다. 프라이빗 사이트 액세스는 Azure 가상 네트워크 내에서와 같은 프라이빗 네트워크에서만 앱에 액세스할 수 있도록 합니다. 가상 네트워크 통합은 앱에서 가상 네트워크로의 아웃바운드 호출을 수행하는 데만 사용됩니다. 인바운드 프라이빗 액세스는 프라이빗 엔드포인트를 참조하세요.

가상 네트워크 통합 기능:

• 지원되는 기본 또는 표준, 프리미엄, 프리미엄 v2, 프리미엄 v3 또는 탄력적 프리미엄 App Service 가격 책정 계층이 필요합니다.
• TCP 및 UDP를 지원합니다.
• App Service 앱, 함수 앱 및 논리 앱과 함께 작동합니다.

가상 네트워크 통합에서 지원하지 않는 다음과 같은 몇 가지 항목이 있습니다.

• 드라이브 탑재
• Windows Server Active Directory 도메인 가입.
• NetBIOS.

가상 네트워크 통합은 동일한 지역의 가상 네트워크에 대한 연결을 지원합니다. 가상 네트워크 통합을 사용하면 앱에서 다음에 액세스할 수 있습니다.

• 통합된 가상 네트워크의 리소스
• 전역 피어링 연결을 포함하여 앱이 통합된 가상 네트워크에 피어링된 가상 네트워크의 리소스
• Azure ExpressRoute 연결의 리소스
• 서비스 엔드포인트 보안 서비스
• 프라이빗 엔드포인트 사용 서비스

가상 네트워크 통합을 사용하는 경우 다음 Azure 네트워킹 기능을 사용할 수 있습니다.

• NSG(네트워크 보안 그룹): 통합 서브넷에 사용하는 NSG를 사용하여 아웃바운드 트래픽을 차단할 수 있습니다. 인바운드 규칙은 적용되지 않습니다. 가상 네트워크 통합을 사용하여 앱에 대한 인바운드 액세스를 제공할 수 없기 때문입니다.
• 경로 테이블(UDR): 통합 서브넷에 경로 테이블을 배치하여 원하는 위치에 아웃바운드 트래픽을 보낼 수 있습니다.
• NAT Gateway: NAT Gateway를 사용하여 전용 발신 IP를 가져오고 SNAT 포트 소진을 완화할 수 있습니다.

가상 네트워크 통합을 사용하는 방법을 알아보세요.

가상 네트워크 통합 작동 방식

App Service의 앱은 작업자 역할에서 호스팅 됩니다. 가상 네트워크 통합은 위임된 서브넷의 주소를 사용하는 작업자 역할에 가상 인터페이스를 탑재하여 작동합니다. 사용되는 가상 인터페이스는 고객이 직접 액세스할 수 있는 리소스가 아닙니다. 보내는 주소는 가상 네트워크에 있으므로 가상 네트워크의 VM처럼 가상 네트워크에 있는 대부분의 항목에 액세스하거나 가상 네트워크를 통해 대부분의 항목에 액세스할 수 있습니다.

가상 네트워크 통합이 사용하도록 설정되면 앱이 가상 네트워크를 통해 발신 전화를 겁니다. 앱 속성 포털에 나열된 아웃바운드 주소는 앱에서 계속 사용하는 주소입니다. 그러나 통합 가상 네트워크 또는 피어링된 가상 네트워크의 가상 머신 또는 프라이빗 엔드포인트에 대한 아웃바운드 호출인 경우 아웃바운드 주소는 통합 서브넷의 주소가 됩니다. 인스턴스에 할당된 개인 IP는 환경 변수인 WEBSITE_PRIVATE_IP를 통해 노출됩니다.

모든 트래픽 라우팅을 사용하도록 설정하면 모든 아웃바운드 트래픽이 가상 네트워크로 전송됩니다. 모든 트래픽 라우팅이 사용하도록 설정되지 않은 경우 프라이빗 트래픽(RFC1918) 및 통합 서브넷에 구성된 서비스 엔드포인트만 가상 네트워크로 전송됩니다. 인터넷으로의 아웃바운드 트래픽은 앱에서 직접 라우팅됩니다.

가상 네트워크 통합 기능은 작업자당 2개의 가상 인터페이스를 지원합니다. 작업자당 두 개의 가상 인터페이스는 App Service 요금제당 두 개의 가상 네트워크 통합을 의미합니다. 즉, App Service 요금제에는 최대 2개의 서브넷/가상 네트워크와의 가상 네트워크 통합이 있을 수 있습니다. 동일한 App Service 요금제의 앱은 특정 서브넷에 대한 가상 네트워크 통합 중 하나만 사용할 수 있습니다. 즉, 앱은 지정된 시간에 단일 가상 네트워크 통합만 가질 수 있습니다.

서브넷 요구 사항

가상 네트워크 통합은 전용 서브넷에 따라 다릅니다. 서브넷을 만들 때 Azure 서브넷은 처음부터 5개의 IP를 사용합니다. 각 App Service 요금제에 대해 통합 서브넷에서 하나의 주소가 사용됩니다. 앱을 4개의 인스턴스로 스케일링하면 4개의 주소가 사용됩니다.

인스턴스 크기로 스케일 업/다운하면 크기 조정 작업이 완료되는 동안 App Service 요금제에서 사용하는 IP 주소의 양이 일시적으로 두 배로 증가합니다. 기존 인스턴스의 프로비전이 해제되기 전에 새 인스턴스가 완전히 작동해야 합니다. 크기 조정 작업은 지정된 서브넷 크기에 대해 지원되는 실제 사용 가능한 인스턴스에 영향을 미칩니다. 플랫폼 업그레이드에는 아웃바운드 트래픽을 중단하지 않고 업그레이드를 수행할 수 있도록 무료 IP 주소가 필요합니다. 마지막으로 스케일 업, 스케일 다운 또는 스케일 인 작업이 완료된 후 IP 주소가 해제되기까지 짧은 시간이 걸릴 수 있습니다. 드문 경우에서 이 작업은 최대 12시간이 될 수 있으며, 빠르게 스케일 인/아웃 또는 업/다운하는 경우 최대 규모보다 더 많은 IP가 필요합니다.

할당 후에는 서브넷 크기를 변경할 수 없으므로 앱이 도달할 수 있는 모든 규모를 수용할 수 있을 정도로 충분히 큰 서브넷을 사용합니다. 또한 플랫폼 업그레이드를 위해 IP 주소를 예약해야 합니다. 서브넷 용량 문제를 방지하려면 계획한 최대 규모의 두 배에 해당하는 IP를 할당하는 것이 좋습니다. 64개 주소의 /26은(는) 단일 다중 테넌트 앱 서비스 계획의 최대 규모를 지원합니다. 가상 네트워크와의 통합을 위해 Azure Portal에서 서브넷을 만들 때 필요한 최소 크기는 /27입니다. 포털을 통해 통합하기 전에 서브넷이 이미 있는 경우 /28 서브넷을 사용할 수 있습니다.

MPSJ(다중 계획 서브넷 조인)를 사용하면 여러 App Service 요금제를 동일한 서브넷에 조인할 수 있습니다. 모든 App Service 요금제는 동일한 구독에 있어야 하지만 가상 네트워크/서브넷은 다른 구독에 있을 수 있습니다. 각 App Service 요금제의 각 인스턴스에는 서브넷의 IP 주소가 필요하며 MPSJ를 사용하려면 최소 /26 서브넷 크기가 필요합니다. 많은 계획 및/또는 대규모 계획에 조인하려는 경우 더 큰 서브넷 범위를 계획해야 합니다.

Important

알려진 버그로 인해 여러 사이트를 만들고 동시에 가상 네트워크와 통합하려고 하면 MPSJ가 실패합니다. 수정 사항은 곧 배포될 예정입니다. 그 동안 다음 방법 중 하나를 사용하여 문제를 해결할 수 있습니다.

• 사이트를 수동으로 만드는 경우 사이트를 하나씩 만들고 통합합니다.
• Terraform 또는 ARM 템플릿을 사용하는 등 프로그래밍 방식으로 사이트를 만드는 경우 템플릿의 각 사이트에 dependsOn 요소를 추가하여 템플릿의 첫 번째 사이트를 제외한 모든 사이트에 대해 이전 사이트를 만드는 방법에 따라 달라집니다. 이렇게 하면 사이트 만들기와 각 사이트에 대한 가상 네트워크 통합 사이에 지연이 발생하므로 알려진 버그에 의해 차단되지 않습니다. 자세한 내용은 ARM 템플릿에서 리소스 배포 순서를 정의합니다.

Windows 컨테이너별 제한

Windows 컨테이너는 각 App Service 요금제 인스턴스에 대해 앱당 추가 IP 주소를 사용하므로 이에 따라 서브넷 크기를 조정해야 합니다. 예를 들어, 4개의 앱이 실행되는 10개의 Windows Container App Service 요금제 인스턴스가 있는 경우 수평(인/아웃) 규모를 지원하려면 50개의 IP 주소와 추가 주소가 필요합니다.

샘플 계산:

각 App Service 요금제 인스턴스에는 다음이 필요합니다. Windows Container Apps 4개 = IP 주소 4개 및 App Service 요금제 인스턴스당 IP 주소 1개, 따라서 4+1 = IP 주소 5개

인스턴스 10개에는 다음이 필요합니다. 5x 10 = App Service 요금제당 IP 주소 50개

App Service 요금제가 1개 있으므로 1 x 50 = 50개의 IP 주소가 됩니다.

또한 사용된 작업자 계층에서 사용 가능한 코어 수에 따라 제한됩니다. 각 코어는 세 개의 네트워킹 단위를 추가합니다. 작업자 자체는 하나의 단위를 사용하고 각 가상 네트워크 연결은 하나의 단위를 사용합니다. 나머지 유닛은 앱에 사용할 수 있습니다.

샘플 계산:

가상 네트워크 통합을 실행하고 사용하는 4개의 앱이 포함된 App Service 요금제 인스턴스입니다. 앱은 서로 다른 두 서브넷(가상 네트워크 연결)에 연결됩니다. 이 구성에는 7개의 네트워킹 단위(작업자 1개 + 연결 2개 + 앱 4개)가 필요합니다. 이 구성을 실행하기 위한 최소 크기는 I2v2(코어 4개 x 3개 = 12개 단위)입니다.

I1v2를 사용하면 동일한(1) 연결을 사용하여 최대 앱 4개를 실행하거나 연결 2개를 사용하여 앱 3개를 실행할 수 있습니다.

사용 권한

Azure Portal 또는 CLI를 통해 설정할 때 또는 virtualNetworkSubnetId 사이트 속성을 직접 설정할 때 가상 네트워크 통합을 구성하려면 서브넷 또는 더 높은 수준에서 다음 역할 기반 액세스 제어 권한이 있어야 합니다.

작업	설명
Microsoft.Network/virtualNetworks/read	가상 네트워크 정의를 읽습니다.
Microsoft.Network/virtualNetworks/subnets/read	가상 네트워크 서브넷 정의를 읽습니다.
Microsoft.Network/virtualNetworks/subnets/join/action	가상 네트워크를 연결합니다.

가상 네트워크가 앱과 다른 구독에 있는 경우 가상 네트워크가 있는 구독이 Microsoft.Web 리소스 공급자에 대해 등록되었는지 확인해야 합니다. 이 설명서에 따라 공급자를 명시적으로 등록할 수 있지만 구독에서 첫 번째 웹앱을 만들 때도 자동으로 등록됩니다.

경로

가상 네트워크 통합을 통과하는 트래픽을 제어할 수 있습니다. 가상 네트워크 통합을 구성할 때 고려해야 할 세 가지 형식의 라우팅이 있습니다. 애플리케이션 라우팅은 앱에서 가상 네트워크로 라우팅되는 트래픽을 정의합니다. 구성 라우팅은 앱 시작 전 또는 시작 중에 발생하는 작업에 영향을 줍니다. 컨테이너 이미지 끌어오기 및 Key Vault 참조가 있는 앱 설정을 예로 들 수 있습니다. 네트워크 라우팅은 앱 및 구성 트래픽이 가상 네트워크에서 라우팅되고 나가는 방법을 처리하는 기능입니다.

애플리케이션 라우팅 또는 구성 라우팅 옵션을 통해 가상 네트워크 통합을 통해 전송할 트래픽을 구성할 수 있습니다. 트래픽은 가상 네트워크 통합을 통해 전송되는 경우에만 네트워크 라우팅이 적용됩니다.

애플리케이션 라우팅

애플리케이션 라우팅은 앱이 시작된 후 앱에서 전송되는 트래픽에 적용됩니다. 시작 중 트래픽에 대한 내용은 구성 라우팅을 참조하세요. 모든 트래픽 또는 프라이빗 트래픽(RFC1918 트래픽이라고도 함)만 가상 네트워크로 라우팅하도록 애플리케이션 라우팅을 구성할 수 있습니다. 아웃바운드 인터넷 트래픽 설정을 통해 이 동작을 구성합니다. 아웃바운드 인터넷 트래픽 라우팅이 사용하지 않도록 설정된 경우 앱은 프라이빗 트래픽만 가상 네트워크로 라우팅합니다. 모든 아웃바운드 앱 트래픽을 가상 네트워크로 라우팅하려면 아웃바운드 인터넷 트래픽이 사용하도록 설정되어 있는지 확인합니다.

• 애플리케이션 또는 구성 라우팅에 구성된 트래픽에만 통합 서브넷에 적용되는 NSG 및 UDR이 적용됩니다.
• 아웃바운드 인터넷 트래픽 라우팅이 사용하도록 설정되면 앱의 아웃바운드 트래픽에 대한 원본 주소는 여전히 앱 속성에 나열된 IP 주소 중 하나입니다. 방화벽이나 NAT Gateway를 통해 트래픽을 라우팅하는 경우 원본 IP 주소는 이 서비스에서 시작됩니다.

애플리케이션 라우팅을 구성하는 방법을 알아보세요.

참고 항목

아웃바운드 SMTP 연결(포트 25)은 SMTP 트래픽이 가상 네트워크 통합을 통해 라우팅될 때 App Service에 대해 지원됩니다. 지원 가능성은 가상 네트워크가 배포되는 구독의 설정에 따라 결정됩니다. 2022년 8월 1일 이전에 만들어진 가상 네트워크/서브넷의 경우 구독에서 동기화할 설정을 위해 가상 네트워크/서브넷에 대한 임시 구성 변경을 시작해야 합니다. 예를 들어 임시 서브넷을 추가하거나, NSG를 일시적으로 연결/분리하거나, 서비스 엔드포인트를 일시적으로 구성하는 것이 있습니다. 자세한 내용은 Azure에서 아웃바운드 SMTP 연결 문제 해결을 참조하세요.

구성 라우팅

가상 네트워크 통합을 사용하는 경우 구성 트래픽의 일부를 관리하는 방법을 구성할 수 있습니다. 기본적으로 구성 트래픽은 공용 경로를 통해 직접 이동하지만, 언급된 개별 구성 요소의 경우 가상 네트워크 통합을 통해 라우팅되도록 적극적으로 구성할 수 있습니다.

콘텐츠 공유

기본적으로 Azure Functions는 프리미엄 계획에서 함수 앱을 확장할 때 콘텐츠 공유를 배포 원본으로 사용합니다. 가상 네트워크 통합을 통해 트래픽이 이 콘텐츠 공유로 라우팅되도록 하려면 추가 설정을 구성해야 합니다. 자세한 내용은 콘텐츠 공유 라우팅 구성하는 방법을 참조하세요.

라우팅을 구성하는 것 외에도 서브넷의 트래픽에 구성된 방화벽 또는 네트워크 보안 그룹이 포트 443 및 445에 대한 트래픽을 허용하는지 확인해야 합니다.

컨테이너 이미지 끌어오기

사용자 지정 컨테이너를 사용하는 경우 가상 네트워크 통합을 통해 컨테이너를 끌어올 수 있습니다. 가상 네트워크 통합을 통해 컨테이너 끌어오기 트래픽을 라우팅하려면 라우팅 설정이 구성되어 있는지 확인해야 합니다. 이미지 끌어오기 라우팅을 구성하는 방법을 알아봅니다.

백업/복원

App Service에는 기본 제공 백업/복원이 있지만 고유의 스토리지 계정에 백업하려는 경우 사용자 지정 백업/복원 기능을 사용할 수 있습니다. 가상 네트워크 통합을 통해 스토리지 계정으로 트래픽을 라우팅하려면 경로 설정을 구성해야 합니다. 가상 네트워크 통합을 통한 데이터베이스 백업은 지원되지 않습니다.

Key Vault 참조를 사용하는 앱 설정

Key Vault 참조를 사용하는 앱 설정은 공용 경로를 통해 비밀을 가져오려고 시도합니다. Key Vault가 공용 트래픽을 차단하고 있으며 앱에서 가상 네트워크 통합을 사용하는 경우 가상 네트워크 통합을 통해 비밀을 가져오려는 시도가 수행됩니다.

참고 항목

• 프라이빗 Key Vault에서 SSL/TLS 인증서를 구성하는 기능은 현재 지원되지 않습니다.
• 프라이빗 스토리지 계정의 App Service 로그는 현재 지원되지 않습니다. 진단 로깅을 사용하고 스토리지 계정에 대해 신뢰할 수 있는 서비스를 허용하는 것이 좋습니다.

라우팅 앱 설정

App Service에는 애플리케이션 및 구성 라우팅을 구성하는 기존 앱 설정이 있습니다. 사이트 속성은 둘 다 있는 경우 앱 설정을 재정의합니다. 사이트 속성은 Azure Policy를 사용하여 감사할 수 있고 구성 시 유효성을 검사할 수 있다는 장점이 있습니다. 사이트 속성을 사용하는 것이 좋습니다.

기존 WEBSITE_VNET_ROUTE_ALL 앱 설정을 사용해도 여전히 애플리케이션 라우팅을 구성할 수 있습니다.

일부 구성 라우팅 옵션에 대한 앱 설정도 있습니다. 이러한 앱 설정은 WEBSITE_CONTENTOVERVNET 및 WEBSITE_PULL_IMAGE_OVER_VNET이라고 합니다.

네트워크 라우팅

경로 테이블을 사용하여 제한 없이 앱의 아웃바운드 트래픽을 라우팅할 수 있습니다. 일반적인 대상에는 방화벽 디바이스나 게이트웨이가 포함될 수 있습니다. NSG(네트워크 보안 그룹)를 사용하여 가상 네트워크 또는 인터넷의 리소스에 대한 아웃바운드 트래픽을 차단할 수도 있습니다. 통합 서브넷에 적용하는 NSG는 통합 서브넷에 적용된 경로 테이블과 무관하게 적용됩니다.

경로 테이블 및 네트워크 보안 그룹은 가상 네트워크 통합을 통해 라우팅되는 트래픽에만 적용됩니다. 자세한 내용은 애플리케이션 라우팅 및 구성 라우팅을 참조하세요. 경로는 인바운드 앱 요청의 회신에 적용되지 않으며 NSG의 인바운드 규칙은 앱에 적용되지 않습니다. 가상 네트워크 통합은 앱의 아웃바운드 트래픽에만 영향을 미칩니다. 앱에 대한 인바운드 트래픽을 제어하려면 액세스 제한 기능 또는 프라이빗 엔드포인트를 사용합니다.

아웃바운드 트래픽에 적용되는 네트워크 보안 그룹 또는 경로 테이블을 구성할 때 애플리케이션 종속성을 고려해야 합니다. 애플리케이션 종속성에는 런타임 중에 앱에 필요한 엔드포인트가 포함됩니다. 앱이 호출하는 API 및 서비스 외에도 이러한 엔드포인트는 CRL(인증서 해지 목록) 확인 엔드포인트 및 ID/인증 엔드포인트(예: Microsoft Entra ID)와 같은 파생 엔드포인트일 수도 있습니다. App Service에서 지속적인 배포를 사용하는 경우 형식 및 언어에 따라 엔드포인트를 허용해야 할 수도 있습니다. 특히 Linux 지속적인 배포의 경우 oryx-cdn.microsoft.io:443을 허용해야 합니다. Python의 경우 추가로 files.pythonhosted.org, pypi.org를 허용해야 합니다.

Azure는 UDP 포트 30,000을 사용하여 네트워크 상태 검사를 수행합니다. 이 트래픽을 차단해도 앱에 직접적인 영향은 미치지 않지만, Azure 지원팀에서 네트워크 관련 문제를 검색하고 해결하는 것이 어려워질 수 있습니다.

모든 아웃바운드 트래픽을 온-프레미스로 라우팅하려면 경로 테이블을 사용하여 아웃바운드 트래픽을 Azure ExpressRoute 게이트웨이로 보내면 됩니다. 트래픽을 게이트웨이로 라우팅하는 경우에는 응답을 다시 보내도록 외부 네트워크의 경로를 설정해야 합니다. BGP(Border Gateway Protocol) 경로도 앱 트래픽에 영향을 줍니다. ExpressRoute 게이트웨이와 같은 항목의 BGP 경로가 있는 경우 앱 아웃바운드 트래픽이 영향을 받습니다. 사용자 정의 경로와 마찬가지로 BGP 경로는 라우팅 범위 설정에 따른 트래픽에 영향을 미칩니다.

서비스 엔드포인트

가상 네트워크 통합을 사용하면 서비스 엔드포인트로 보안이 유지되는 Azure 서비스에 연결할 수 있습니다. 서비스 엔드포인트 보안 서비스에 액세스하려면 다음 단계를 수행합니다.

1. 통합을 위해 특정 서브넷에 연결하도록 웹앱과 가상 네트워크 통합을 구성합니다.
2. 대상 서비스로 이동하여 통합 서브넷에 대해 서비스 엔드포인트를 구성합니다.

프라이빗 엔드포인트

프라이빗 엔드포인트를 호출하려면 DNS 조회가 프라이빗 엔드포인트로 확인되어야 합니다. 이러한 동작은 다음 방법 중 하나로 적용할 수 있습니다.

• Azure DNS 프라이빗 영역과 통합합니다. 가상 네트워크에 사용자 지정 DNS 서버가 없는 경우 영역이 가상 네트워크에 연결될 때 자동으로 통합이 수행됩니다.
• 앱에서 사용하는 DNS 서버에서 프라이빗 엔드포인트를 관리합니다. 구성을 관리하려면 프라이빗 엔드포인트 IP 주소를 알고 있어야 합니다. 그런 다음, A 레코드를 사용하여 해당 주소에 도달하려는 엔드포인트를 가리킵니다.
• Azure DNS 프라이빗 영역으로 전달하도록 자체 DNS 서버를 구성합니다.

Azure DNS 프라이빗 영역

앱은 가상 네트워크와 통합되면 가상 네트워크에 구성된 것과 동일한 DNS 서버를 사용합니다. 사용자 지정 DNS가 지정되지 않은 경우 Azure 기본 DNS 및 가상 네트워크에 연결된 모든 프라이빗 영역을 사용합니다.

제한 사항

가상 네트워크 통합 사용에는 몇 가지 제한 사항이 있습니다.

• 이 기능은 프리미엄 v2 및 프리미엄 v3의 모든 App Service 배포에서 사용할 수 있습니다. 기본 및 표준 계층에서도 사용할 수 있지만 최신 App Service 배포에서만 사용할 수 있습니다. 이전 배포를 사용하는 경우 프리미엄 v2 App Service 요금제의 기능만 사용할 수 있습니다. 기본 또는 표준 App Service 요금제에서 이 기능을 사용할 수 있도록 하려면 프리미엄 v3 App Service 요금제에서 앱을 만듭니다. 이러한 요금제는 최신 배포에서만 지원됩니다. 원한다면 요금제를 만든 후 스케일 다운할 수 있습니다.
• App Service Environment의 격리 계획 앱에는 이 기능을 사용할 수 없습니다.
• 클래식 가상 네트워크를 사용하는 피어링 연결에서 리소스에 연결할 수 없습니다.
• 이 기능을 사용하려면 Azure Resource Manager 가상 네트워크에서 IPv4 /28 이상 블록인 사용하지 않는 서브넷이 필요합니다. MPSJ에는 /26 블록 이상이 필요합니다.
• 앱과 가상 네트워크는 동일한 지역에 있어야 합니다.
• 통합 가상 네트워크는 IPv6 주소 공간을 정의할 수 없습니다.
• 통합 서브넷에는 서비스 엔드포인트 정책을 사용할 수 없습니다.
• 앱이 통합된 가상 네트워크는 삭제할 수 없습니다. 가상 네트워크를 삭제하려면 통합을 먼저 제거해야 합니다.
• App Service 요금제당 두 개 이상의 가상 네트워크 통합을 가질 수 없습니다. 같은 App Service 요금제에 속한 여러 앱에서 동일한 가상 네트워크 통합을 사용할 수 있습니다.
• 가상 네트워크 통합을 사용하는 앱이 있는 동안에는 앱의 구독 또는 요금제를 변경할 수 없습니다.

온-프레미스 리소스에 액세스

가상 네트워크 통합 기능이 가상 네트워크를 통해 온-프레미스 리소스에 도달하기 위해 필요한 추가 구성은 없습니다. ExpressRoute 또는 사이트 간 VPN을 사용하여 가상 네트워크를 온-프레미스 리소스에 연결하기만 하면 됩니다.

피어링

가상 네트워크 통합과 함께 피어링을 사용하는 경우 더 이상 구성을 수행할 필요가 없습니다.

가상 네트워크 통합 관리

앱 수준에서 가상 네트워크에 연결하거나 연결을 끊습니다. 여러 앱의 가상 네트워크 통합에 영향을 줄 수 있는 작업은 App Service 요금제 수준에서 이루어집니다. 앱 >네트워킹>VNet 통합 포털에서 가상 네트워크 관련 세부 정보를 볼 수 있습니다. App Service 요금제>네트워킹>VNet 통합 포털의 App Service 요금제 수준에서 유사한 정보를 볼 수 있습니다.

가상 네트워크 통합 인스턴스의 앱 보기에서 가상 네트워크에서 앱의 연결을 끊고 애플리케이션 라우팅을 구성할 수 있습니다. 가상 네트워크에서 앱의 연결을 끊으려면 연결 끊기를 선택합니다. 가상 네트워크와의 연결을 끊으면 앱이 다시 시작됩니다. 연결을 끊더라도 가상 네트워크는 변경되지 않습니다. 서브넷은 제거되지 않습니다. 그런 다음 가상 네트워크를 삭제하려면 먼저 가상 네트워크에서 앱의 연결을 끊습니다.

인스턴스에 할당된 개인 IP는 환경 변수인 WEBSITE_PRIVATE_IP를 통해 노출됩니다. 또한 Kudu 콘솔 UI에는 웹앱에 사용할 수 있는 환경 변수 목록이 표시됩니다. 이 IP는 통합된 서브넷의 주소 범위에서 할당됩니다. 이 IP는 웹앱에서 Azure Virtual Network를 통해 리소스에 연결하는 데 사용됩니다.

참고 항목

WEBSITE_PRIVATE_IP 값은 변경 내용에 바인딩됩니다. 그러나 통합 서브넷의 주소 범위 내의 IP이므로 전체 주소 범위에서 액세스를 허용해야 합니다.

가격 정보

가상 네트워크 통합 기능에는 App Service 요금제 가격 책정 계층별 요금 이외에는 추가 사용 요금이 부과되지 않습니다.

문제 해결

이 기능은 설정하기 쉽지만 문제가 없는 것은 아닙니다. 원하는 엔드포인트에 액세스하는 데 문제가 발생하면 관찰 중인 항목에 따라 취할 수 있는 다양한 단계가 있습니다. 자세한 내용은 가상 네트워크 통합 문제 해결 가이드를 참조하세요.

참고 항목

• App Service의 Docker Compose 시나리오에서는 가상 네트워크 통합이 지원되지 않습니다.
• 프라이빗 엔드포인트를 통해 들어오는 트래픽에는 액세스 제한이 적용되지 않습니다.

네트워크 통합 연결을 끊기 전에 App Service 요금제 또는 앱 삭제

먼저 가상 네트워크 통합 연결을 끊지 않고 앱 또는 App Service 요금제를 삭제한 경우 삭제된 리소스와의 통합에 사용된 가상 네트워크 또는 서브넷에서 업데이트/삭제 작업을 수행할 수 없습니다. 서브넷 위임 'Microsoft.Web/serverFarms'는 서브넷에 할당된 상태로 유지되며 업데이트 및 삭제 작업을 방지합니다.

서브넷 또는 가상 네트워크를 다시 업데이트/삭제하려면 가상 네트워크 통합을 다시 만든 다음 연결을 끊어야 합니다.

1. App Service 요금제 및 앱을 다시 만듭니다(이전과 정확히 동일한 웹앱 이름을 사용해야 함).
2. Azure Portal의 앱에서 네트워킹으로 이동하여 가상 네트워크 통합을 구성합니다.
3. 가상 네트워크 통합이 구성된 후 '연결 끊기' 단추를 선택합니다.
4. App Service 요금제 또는 앱을 삭제합니다.
5. 서브넷 또는 가상 네트워크를 업데이트/삭제합니다.

이러한 단계를 수행한 후에도 가상 네트워크 통합에 문제가 계속 발생하면 Microsoft 지원에 문의하세요.