가상 네트워크에 Azure API Management 인스턴스 배포 - 내부 모드
적용 대상: 개발자 | 프리미엄
Azure API Management는 Azure VNet(가상 네트워크) 내부에 배포(삽입)하여 네트워크 내의 백 엔드 서비스에 액세스할 수 있습니다. VNet 연결 옵션, 요구 사항 및 고려 사항은 다음을 참조하세요.
이 문서에서는 내부 모드에서 API Management 인스턴스에 대한 VNet 연결을 설정하는 방법에 대해 설명합니다. 이 모드에서는 액세스가 제어되는 VNet 내에서 다음과 같은 API Management 엔드포인트에만 액세스할 수 있습니다.
- API 게이트웨이
- 개발자 포털
- 직접 관리
- Git
참고 항목
내부 모드에서 API Management를 사용하여 다음을 수행합니다.
- Azure VPN 연결 또는 Azure ExpressRoute를 사용하여 타사의 외부에서 프라이빗 데이터 센터에 호스팅된 API에 안전하게 액세스할 수 있게 합니다.
- 공통 게이트웨이를 통해 클라우드 기반 API와 온-프레미스 API를 공개함으로써 하이브리드 클라우드 시나리오를 사용하도록 설정합니다.
- 단일 게이트웨이 엔드포인트를 사용하여 여러 지리적 위치에서 호스팅되는 API를 관리합니다.
공용 인터넷에서 API Management 엔드포인트에 액세스할 수 있고 백 엔드 서비스가 네트워크에 있는 ‘외부’ 모드와 관련된 구성은 가상 네트워크에 Azure API Management 인스턴스 배포 - 내부 모드를 참조하세요.
참고 항목
Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.
필수 조건
시작하기 전에 가상 네트워크에 API Management를 주입하기 위한 네트워크 리소스 요구 사항을 검토합니다.
일부 필수 조건은 API Management 인스턴스를 호스팅하는 컴퓨팅 플랫폼의 버전(stv2 또는 stv1)에 따라 다릅니다.
팁
포털을 사용하여 기존 API Management 인스턴스의 네트워크 연결을 만들거나 업데이트할 때 인스턴스는 stv2 컴퓨팅 플랫폼에서 호스팅됩니다.
- API Management 인스턴스. 자세한 내용은 Azure API Management 인스턴스 만들기를 참조하세요.
API Management 인스턴스와 동일한 지역 및 구독에 있는 가상 네트워크 및 서브넷.
- API Management 인스턴스에 연결하는 데 사용되는 서브넷에는 다른 Azure 리소스 종류가 포함될 수 있습니다.
- 서브넷에는 위임을 사용하도록 설정하면 안 됩니다. 서브넷에 대한 서비스에 서브넷 위임 설정을 없음으로 설정해야 합니다.
위의 서브넷에 연결된 네트워크 보안 그룹. API Management에서 내부적으로 사용하는 부하 분산 장치는 기본적으로 안전하고 모든 인바운드 트래픽을 거부하기 때문에 인바운드 연결을 명시적으로 허용하려면 NSG(네트워크 보안 그룹)가 필요합니다. 특정 구성은 이 문서 뒷부분의 NSG 규칙 구성을 참조하세요.
특정 시나리오의 경우 서브넷의 서비스 엔드포인트를 Azure Storage 또는 Azure SQL과 같은 종속 서비스에 사용하도록 설정합니다. 자세한 내용은 이 문서의 뒷부분에 있는 ExpressRoute 또는 네트워크 가상 어플라이언스를 사용하여 온-프레미스 방화벽에 트래픽 터널링 강제 적용을 참조하세요.
(선택 사항) 표준 SKU 공용 IPv4 주소.
Important
- 2024년 5월부터 내부 모드의 VNet에 API Management 인스턴스를 배포(삽입)하거나 내부 VNet 구성을 새 서브넷으로 마이그레이션할 때 공용 IP 주소 리소스가 더 이상 필요하지 않습니다. 외부 VNet 모드에서 공용 IP 주소 지정은 선택 사항입니다. 제공하지 않으면 Azure 관리 공용 IP 주소가 자동으로 구성되고 런타임 API 트래픽에 사용됩니다. 인터넷으로의 인바운드 또는 아웃바운드 통신에 사용되는 공용 IP 주소를 소유하고 제어하려는 경우에만 공용 IP 주소를 제공합니다.
제공된 경우 IP 주소는 API Management 인스턴스 및 가상 네트워크와 동일한 지역 및 구독에 있어야 합니다.
공용 IP 주소 리소스를 만들 때 리소스에 DNS 이름 레이블을 할당해야 합니다. 일반적으로 API Management 인스턴스와 동일한 DNS 이름을 사용해야 합니다. 변경하는 경우 새 DNS 레이블이 적용되도록 인스턴스를 다시 배포합니다.
최상의 네트워크 성능을 위해 기본 라우팅 기본 설정인 Microsoft 네트워크를 사용하는 것이 좋습니다.
API Management 인스턴스에 대해 영역 중복을 사용하도록 설정하려는 지역에서 공용 IP 주소를 만들 때 영역 중복 설정을 구성합니다.
IP 주소의 값은 해당 지역에 API Management 인스턴스의 가상 공용 IPv4 주소로 할당됩니다.
다중 지역 API Management 배포의 경우 각 위치에 대해 개별적으로 가상 네트워크 리소스를 구성합니다.
VNet 연결 사용
Azure Portal(stv2 플랫폼)을 사용하여 VNet 연결 사용
Azure Portal로 이동하여 API Management 인스턴스를 찾습니다. API Management 서비스를 검색하고 선택합니다.
API Management 인스턴스를 선택합니다.
네트워크>가상 네트워크를 선택합니다.
내부 액세스 형식을 선택합니다.
API Management 서비스가 프로비저닝된 위치(지역) 목록에서:
- 위치를 선택합니다.
- 가상 네트워크 및 서브넷을 선택합니다.
- VNet 목록은 사용자가 구성하고 있는 하위 지역에 설정된 Azure 구독에서 사용할 수 있는 Resource Manager VNet으로 채워집니다.
적용을 선택합니다. API Management 인스턴스의 가상 네트워크 페이지가 새 VNet 및 선택한 서브넷 항목으로 업데이트됩니다.
API Management 인스턴스의 나머지 위치에 대한 VNet 설정을 계속 구성합니다.
상단 탐색 모음에서 저장을 선택합니다.
API Management 인스턴스를 업데이트하는 데 15~45분이 걸릴 수 있습니다. 개발자 계층은 프로세스 중에 가동 중지 시간이 있습니다. 기본 및 상위 SKU에는 프로세스 중에 가동 중지 시간이 없습니다.
배포에 성공하면, 개요 블레이드에 API Management 서비스의 개인 가상 IP 주소와 공용 가상 IP 주소가 표시됩니다. IP 주소에 대한 자세한 내용은 이 문서의 라우팅을 참조하세요.
참고 항목
Azure Portal에서 사용할 수 있는 테스트 콘솔의 경우, 해당 게이트웨이 URL이 공용 DNS에 등록되어 있지 않으므로 내부 VNet 배포 서비스에서 작동하지 않습니다. 대신, 개발자 포털에 제공된 테스트 콘솔을 사용해야 합니다.
Resource Manager 템플릿(stv2 플랫폼)을 사용하여 연결 사용
Azure Resource Manager 템플릿(API 버전 2021-08-01)
Azure PowerShell cmdlet을 사용하여 연결 사용하도록 설정(stv1 플랫폼)
VNet에서 API Management 인스턴스를 만들거나 업데이트합니다.
NSG 규칙 구성
API Management 서브넷에서 사용자 지정 네트워크 규칙을 구성하여 API Management 인스턴스에서 들어오고 나가는 트래픽을 필터링합니다. 인스턴스에 대한 적절한 작동 및 액세스를 보장하기 위해 다음과 같은 최소 NSG 규칙을 권장합니다. 환경을 신중하게 검토하여 추가 규칙이 필요할 수 있는지 판단하세요.
Important
캐싱 및 기타 기능 사용에 따라 다음 표의 최소 규칙 외에 추가 NSG 규칙을 구성해야 할 수 있습니다. 자세한 설정은 가상 네트워크 구성 참조를 참조하세요.
- 대부분의 시나리오에서 서비스 IP 주소 대신 표시된 서비스 태그를 사용하여 네트워크 원본 및 대상을 지정합니다.
- 이러한 규칙의 우선 순위를 기본 규칙보다 높게 설정합니다.
| 소스/대상 포트 | Direction | 전송 프로토콜 | 서비스 태그 원본 / 대상 |
목적 | VNet 유형 |
|---|---|---|---|---|---|
| * / [80], 443 | 인바운드 | TCP | 인터넷 / VirtualNetwork | API Management에 대한 클라이언트 통신 | 외부만 |
| * / 3443 | 인바운드 | TCP | ApiManagement / VirtualNetwork | Azure Portal 및 PowerShell용 관리 엔드포인트 | 외부 및 내부 |
| * / 6390 | 인바운드 | TCP | AzureLoadBalancer / VirtualNetwork | Azure 인프라 부하 분산 장치 | 외부 및 내부 |
| * / 443 | 인바운드 | TCP | AzureTrafficManager / VirtualNetwork | 다중 지역 배포를 위한 Azure Traffic Manager 라우팅 | 외부만 |
| * / 443 | 아웃바운드 | TCP | VirtualNetwork / 스토리지 | 핵심 서비스 기능에 대한 Azure Storage 종속성 | 외부 및 내부 |
| * / 1433 | 아웃바운드 | TCP | VirtualNetwork / SQL | 핵심 서비스 기능에 대한 Azure SQL 엔드포인트 액세스 | 외부 및 내부 |
| * / 443 | 아웃바운드 | TCP | VirtualNetwork / AzureKeyVault | 핵심 서비스 기능에 대한 Azure Key Vault 액세스 | 외부 및 내부 |
| * / 1886, 443 | 아웃바운드 | TCP | VirtualNetwork / AzureMonitor | 진단 로그 및 메트릭, Resource Health 및 Application Insights 게시 | 외부 및 내부 |
DNS 구성
내부 VNet 모드에서는 사용자 고유의 DNS를 관리하여 API Management 엔드포인트에 대한 인바운드 액세스를 사용하도록 설정해야 합니다.
다음이 권장됩니다.
- Azure DNS 프라이빗 영역을 구성합니다.
- Azure DNS 프라이빗 영역을 API Management 서비스를 배포한 VNet에 연결합니다.
Azure DNS에서 프라이빗 영역을 설정하는 방법을 알아봅니다.
참고 항목
API Management 서비스는 해당 IP 주소에 대한 요청을 수신하지 않습니다. 해당 엔드포인트에 구성된 호스트 이름에 대한 요청에만 응답합니다. 이 엔드포인트에는 다음이 필요합니다.
- API 게이트웨이
- Azure Portal
- 개발자 포털
- 엔드포인트 직접 관리
- Git
기본 호스트 이름에 대한 액세스
API Management 서비스(예: contosointernalvnet)를 만들면 기본적으로 다음과 같은 엔드포인트가 구성됩니다.
| 엔드포인트 | 엔드포인트 구성 |
|---|---|
| API Gateway | contosointernalvnet.azure-api.net |
| 개발자 포털 | contosointernalvnet.portal.azure-api.net |
| 새 개발자 포털 | contosointernalvnet.developer.azure-api.net |
| 엔드포인트 직접 관리 | contosointernalvnet.management.azure-api.net |
| Git | contosointernalvnet.scm.azure-api.net |
사용자 지정 도메인 이름에 대한 액세스
기본 호스트 이름으로 API Management 서비스에 액세스하지 않으려면 다음 이미지에 표시된 대로 모든 엔드포인트에 대해 사용자 지정 도메인 이름을 설정합니다.
DNS 레코드 구성
DNS 서버에 레코드를 생성하여 VNet 내에서 액세스할 수 있는 엔드포인트에 액세스합니다. 엔드포인트 레코드를 서비스의 프라이빗 가상 IP 주소에 매핑합니다.
테스트를 위해 API Management가 배포된 VNet에 연결된 서브넷의 가상 머신에서 호스트 파일을 업데이트할 수 있습니다. 서비스의 프라이빗 가상 IP 주소가 10.1.0.5라고 가정하면 다음과 같이 호스트 파일을 매핑할 수 있습니다. 호스트 매핑 파일은 %SystemDrive%\drivers\etc\hosts(Windows) 또는 /etc/hosts(Linux, macOS)에 있습니다.
| 내부 가상 IP 주소 | 엔드포인트 구성 |
|---|---|
| 10.1.0.5 | contosointernalvnet.azure-api.net |
| 10.1.0.5 | contosointernalvnet.portal.azure-api.net |
| 10.1.0.5 | contosointernalvnet.developer.azure-api.net |
| 10.1.0.5 | contosointernalvnet.management.azure-api.net |
| 10.1.0.5 | contosointernalvnet.scm.azure-api.net |
그러면 만든 가상 머신에서 모든 API Management 엔드포인트에 액세스할 수 있습니다.
라우팅
다음 가상 IP 주소는 내부 가상 네트워크의 API Management 인스턴스에 대해 구성됩니다.
| 가상 IP 주소 | 설명 |
|---|---|
| 개인 가상 IP 주소 | API Management 인스턴스의 서브넷 범위 내에서 부하 분산된 IP 주소(DIP)에서는 API 게이트웨이, 개발자 포털, 관리 및 Git 엔드포인트에 액세스할 수 있습니다. VNet에서 사용하는 DNS 서버에 이 주소를 등록합니다. |
| 공용 가상 IP 주소 | 포트 3443을 통해 관리 엔드포인트에 대한 컨트롤 플레인 트래픽 전용으로 사용됩니다. ApiManagement 서비스 태그로 잠글 수 있습니다. |
부하 분산된 공용 및 개인 IP 주소는 Azure Portal의 개요 블레이드에서 확인할 수 있습니다.
자세한 내용 및 고려 사항은 Azure API Management의 IP 주소를 참조하세요.
VIP 및 DIP 주소
DIP(동적 IP) 주소는 서비스의 각 기본 가상 머신에 할당되고 VNet 및 피어링된 VNet의 엔드포인트와 리소스에 액세스하는 데 사용됩니다. API Management 서비스의 공용 VIP(가상 IP) 주소는 공용 리소스에 액세스하는 데 사용됩니다.
IP 제한에서 VNet 또는 피어링된 VNet 내의 보안 리소스를 나열하는 경우 API Management 서비스가 배포되는 서브넷의 전체 범위를 지정하여 서비스에서 액세스 권한을 부여하거나 제한하는 것이 좋습니다.
권장 서브넷 크기에 대해 자세히 알아봅니다.
예시
내부 VNet의 프리미엄 계층에 API Management의 1개 용량 단위를 배포하는 경우 3개의 IP 주소가 사용됩니다. 하나는 개인 VIP용이고 나머지는 각각 두 VM에 대한 DIP용입니다. 4개 단위로 스케일 아웃하면 서브넷의 추가 DIP에 더 많은 IP가 사용됩니다.
대상 엔드포인트가 고정된 DIP 집합만 허용 목록에 있는 경우 나중에 새 장치를 추가하면 연결 실패가 발생합니다. 이러한 이유로 서브넷은 완전히 제어할 수 있으므로 백 엔드에서 전체 서브넷을 허용 목록에 추가하는 것이 좋습니다.
ExpressRoute 또는 네트워크 가상 어플라이언스를 사용하여 온-프레미스 방화벽에 트래픽 터널링 강제 적용
강제 터널링을 사용하면 검사 및 감사를 위해 모든 인터넷 바인딩 트래픽을 서브넷에서 온-프레미스로 리디렉션하거나 "강제 적용"할 수 있습니다. 일반적으로 사용자 고유의 기본 경로(0.0.0.0/0)를 구성하고 정의하여 강제로 API Management 서브넷의 모든 트래픽이 온-프레미스 방화벽 또는 네트워크 가상 어플라이언스를 통해 흐르도록 강제합니다. 아웃바운드 트래픽이 온-프레미스에서 차단되거나 다양한 Azure 엔드포인트에서 더 이상 작동하지 않는 인식 불가능한 주소 세트로 NAT되므로 이 트래픽 흐름은 API Management와의 연결을 끊습니다. 이 문제는 다음 방법을 통해 해결할 수 있습니다.
API Management 서비스가 배포된 서브넷에서 서비스 엔드포인트를 사용하도록 설정합니다.
- Azure SQL(API Management 서비스가 여러 지역에 배포된 경우에만 주 지역에 필요)
- Azure Storage
- Azure Event Hubs
- Azure Key Vault(API Management가
stv2플랫폼에 배포되는 경우 필요)
API Management 서브넷에서 이러한 서비스로 직접 엔드포인트를 활성화하여 서비스 트래픽에 대한 최적의 라우팅을 제공하는 Microsoft Azure 백본 네트워크를 사용할 수 있습니다. 강제 터널링된 API Management에서 서비스 엔드포인트를 사용하는 경우 이전 Azure 서비스에 대한 트래픽은 강제 터널링되지 않습니다. 그러나 다른 API Management 서비스 종속성 트래픽은 강제 터널링된 상태로 유지됩니다. 방화벽 또는 가상 어플라이언스에서 이 트래픽을 차단하지 않는지 확인합니다. 그렇지 않으면 API Management 서비스가 제대로 작동하지 않을 수 있습니다.
참고 항목
지원되는 Azure SQL 및 Azure Storage와 같은 종속 서비스에 대한 API Management 서브넷에서 직접 서비스 엔드포인트를 사용하도록 설정하는 것이 좋습니다. 그러나 API Management 서브넷의 모든 트래픽을 강제로 터널링해야 하는 조직이 있을 수 있습니다. 이 경우 이 트래픽을 허용하도록 방화벽 또는 가상 어플라이언스를 구성해야 합니다. 각 종속 서비스의 전체 IP 주소 범위를 허용하고 Azure 인프라가 변경될 때 이 구성을 최신 상태로 유지해야 합니다. 또한 이 네트워크 트래픽의 강제 터널링으로 인해 API Management 서비스에 대기 시간 또는 예기치 않은 시간 초과가 발생할 수 있습니다.
인터넷에서 API Management 서비스의 관리 엔드포인트로의 모든 컨트롤 플레인 트래픽은 API Management에서 호스트하는 특정 인바운드 IP 세트를 통해 라우팅되며 ApiManagement 서비스 태그에 포함됩니다. 트래픽이 강제 터널링되면 응답이 이러한 인바운드 원본 IP에 대칭적으로 다시 매핑되지 않고 관리 엔드포인트에 대한 연결이 손실됩니다. 이 제한을 해결하려면 다음 홉 유형이 "인터넷"으로 설정된 ApiManagement 서비스 태그에 대해 UDR(사용자 정의 경로)을 구성하여 트래픽을 Azure로 돌려보냅니다.
참고 항목
API Management 관리 트래픽에서 온-프레미스 방화벽 또는 네트워크 가상 어플라이언스를 무시하도록 허용하는 것은 심각한 보안 위험으로 간주되지 않습니다. API Management 서브넷에 권장되는 구성은 3443 포트에서만 ApiManagement 서비스 태그에 포함된 Azure IP 주소 세트로부터의 인바운드 관리 트래픽을 허용합니다. 권장되는 UDR 구성은 이 Azure 트래픽의 반환 경로에만 적용됩니다.
(외부 VNet 모드) 강제 터널링을 통해 도입된 비대칭 라우팅으로 인해 인터넷에서 API Management 게이트웨이 및 개발자 포털에 도달하려고 하는 클라이언트에 대한 데이터 평면 트래픽도 기본적으로 삭제됩니다. 액세스가 필요한 각 클라이언트에 대해 방화벽 또는 가상 네트워크 어플라이언스를 무시하도록 다음 홉 형식이 "인터넷"인 명시적 UDR을 구성합니다.
강제로 터널링되는 다른 API Management 서비스 종속성의 경우 호스트 이름을 확인하고 엔드포인트에 도달합니다. 여기에는 다음이 포함됩니다.
- 메트릭 및 상태 모니터링
- Azure Portal 진단
- SMTP 릴레이
- 개발자 포털 CAPTCHA
- Azure KMS 서버
자세한 내용은 가상 네트워크 구성 참조를 참조하세요.
일반적인 네트워크 구성 문제
이 섹션이 이동되었습니다. 가상 네트워크 구성 참조를 참조하세요.
문제 해결
서브넷에 대한 API Management 서비스 초기 배포 실패
- 같은 서브넷에 가상 머신을 배포합니다.
- 가상 머신에 연결하고 Azure 구독에서 다음 리소스 중 하나에 대한 연결의 유효성을 검사합니다.
- Azure Storage Blob
- Azure SQL Database
- Azure Storage 테이블
- Azure Key Vault(
stv2플랫폼에서 호스팅되는 API Management 인스턴스용)
Important
연결의 유효성을 검사한 후 서브넷에 API Management를 배포하기 전에 서브넷의 모든 리소스를 제거합니다(API Management가 stv1 플랫폼에서 호스팅되는 경우 필요).
네트워크 상태 확인
서브넷에 API Management를 배포한 후 포털을 사용하여 Azure Storage와 같은 종속성에 대한 인스턴스의 연결을 확인합니다.
포털의 왼쪽 메뉴에 있는 배포 및 인프라에서 네트워크>네트워크 상태를 선택합니다.
| 필터 | 설명 |
|---|---|
| 필수 | API Management에 대해 필요한 Azure 서비스 연결을 검토하려면 선택합니다. 오류는 인스턴스가 API를 관리하기 위한 핵심 작업을 수행할 수 없음을 나타냅니다. |
| 선택 사항 | 선택적 서비스 연결을 검토하려면 선택합니다. 오류는 특정 기능(예: SMTP)이 작동하지 않음을 나타냅니다. 오류가 발생하면 API Management 인스턴스를 사용 및 모니터링하고 커밋된 SLA를 제공하는 기능이 저하될 수 있습니다. |
연결 문제를 해결하려면 다음을 선택합니다.
메트릭 - 네트워크 연결 상태 메트릭을 검토합니다.
진단 - 지정된 기간 동안 가상 네트워크 검증 도구를 실행합니다.
연결 문제를 해결하려면 네트워크 구성 설정을 검토하고 필요한 네트워크 설정을 수정합니다.
증분 업데이트
네트워크를 변경할 때 NetworkStatus API를 참조하여 API Management 서비스에서 중요한 리소스에 대한 액세스를 손실하지 않았는지 확인합니다. 연결 상태는 15분마다 업데이트되어야 합니다.
포털을 사용하여 API Management 인스턴스에 네트워크 구성 변경 내용을 적용하려면:
- 인스턴스의 왼쪽 메뉴에 있는 배포 및 인프라에서 네트워크>가상 네트워크를 선택합니다.
- 네트워크 구성 적용을 선택합니다.
리소스 탐색 링크
stv1 컴퓨팅 플랫폼에서 호스트되는 API Management 인스턴스는 Resource Manager VNET 서브넷에 배포될 때 리소스 탐색 링크를 만들어 서브넷을 예약합니다. 서브넷에 니미 다른 공급자의 리소스가 포함된 경우에는 배포가 실패합니다. 마찬가지로 API Management 서비스를 삭제하거나 다른 서브넷으로 이동하면 리소스 탐색 링크가 제거됩니다.
API Management 인스턴스를 이전 서브넷에 다시 할당할 때 발생하는 문제
- VNet 잠금 - API Management 인스턴스를 원래 서브넷으로 다시 이동하는 경우 제거하는 데 최대 1시간이 걸리는 VNet 잠금으로 인해 즉각적인 다시 할당이 불가능할 수 있습니다. 원래 서브넷에 다른
stv1플랫폼 기반 API Management 서비스(클라우드 서비스 기반)가 있는 경우 동일한 서브넷에stv2플랫폼 기반 서비스를 배포하려면 삭제 후 기다려야 합니다. - 리소스 그룹 잠금 - 고려해야 할 또 다른 시나리오는 리소스 그룹 수준 이상에서 범위 잠금이 존재하여 리소스 탐색 링크 삭제 프로세스를 방해하는 것입니다. 이 문제를 해결하려면 범위 잠금을 제거하고, API Management 서비스가 잠금 제거 전의 원래 서브넷에서 연결을 해제하는 데 약 4~6시간의 지연을 허용하여 원하는 서브넷에 배포할 수 있도록 합니다.
VNet 내에서 Microsoft Graph에 대한 연결 문제 해결
Microsoft Entra ID 공급자를 사용하여 개발자 포털에 대한 사용자 로그인을 비롯한 기능을 사용하려면 Microsoft Graph에 대한 네트워크 연결이 필요합니다.
VNet 내에서 Microsoft Graph에 대한 연결 문제를 해결하려면 다음을 수행합니다.
API Management 인스턴스에서 Microsoft Graph로 아웃바운드 연결을 위해 NSG 및 기타 네트워크 규칙이 구성되어 있는지 확인합니다(AzureActiveDirectory 서비스 태그 사용).
VNet 내에서
graph.microsoft.com에 대한 DNS 확인 및 네트워크 액세스를 확인합니다. 예를 들어 VNet 내에 새 VM을 프로비전하고, 연결하고, 브라우저에서 또는 cURL, PowerShell 또는 기타 도구를 사용하여GET https://graph.microsoft.com/v1.0/$metadata를 시도합니다.
다음 단계
자세히 알아보기: