ეს ბრაუზერი აღარ არის მხარდაჭერილი.
გადადით Microsoft Edge-ზე, რათა ისარგებლოთ უახლესი ფუნქციებით, უსაფრთხოების განახლებებითა და ტექნიკური მხარდაჭერით.
APPLIES TO: Developer | Premium
Azure API Management can be deployed (injected) inside an Azure virtual network (VNet) to access backend services within the network. For VNet connectivity options, requirements, and considerations, see:
This article explains how to set up VNet connectivity for your API Management instance in the internal mode. In this mode, you can only access the following API Management endpoints within a VNet whose access you control.
Note
Use API Management in internal mode to:
For configurations specific to the external mode, where the API Management endpoints are accessible from the public internet, and backend services are located in the network, see Deploy your Azure API Management instance to a virtual network - external mode.
Note
We recommend that you use the Azure Az PowerShell module to interact with Azure. To get started, see Install Azure PowerShell. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Review the network resource requirements for API Management injection into a virtual network before you begin.
Some prerequisites differ depending on the version (stv2 or stv1) of the compute platform hosting your API Management instance.
რჩევა
When you use the portal to create or update the network connection of an existing API Management instance, the instance is hosted on the stv2 compute platform.
A virtual network and subnet in the same region and subscription as your API Management instance.
A network security group attached to the subnet above. A network security group (NSG) is required to explicitly allow inbound connectivity, because the load balancer used internally by API Management is secure by default and rejects all inbound traffic. For specific configuration, see Configure NSG rules, later in this article.
For certain scenarios, enable service endpoints in the subnet to dependent services such as Azure Storage or Azure SQL. For more information, see Force tunnel traffic to on-premises firewall using ExpressRoute or network virtual appliance, later in this article.
(Optional) A Standard SKU public IPv4 address.
მნიშვნელოვანი
If provided, the IP address must be in the same region and subscription as the API Management instance and the virtual network.
When creating a public IP address resource, ensure you assign a DNS name label to it. In general, you should use the same DNS name as your API Management instance. If you change it, redeploy your instance so that the new DNS label is applied.
For best network performance, it's recommended to use the default Routing preference: Microsoft network.
When creating a public IP address in a region where you plan to enable zone redundancy for your API Management instance, configure the Zone-redundant setting.
The value of the IP address is assigned as the virtual public IPv4 address of the API Management instance in that region.
For multi-region API Management deployments, configure virtual network resources separately for each location.
Go to the Azure portal to find your API management instance. Search for and select API Management services.
Choose your API Management instance.
Select Network > Virtual network.
Select the Internal access type.
In the list of locations (regions) where your API Management service is provisioned:
Select Apply. The Virtual network page of your API Management instance is updated with your new VNet and subnet choices.
Continue configuring VNet settings for the remaining locations of your API Management instance.
In the top navigation bar, select Save.
It can take 15 to 45 minutes to update the API Management instance. The Developer tier has downtime during the process. The Basic and higher SKUs don't have downtime during the process.
After successful deployment, you should see your API Management service's private virtual IP address and public virtual IP address on the Overview blade. For more information about the IP addresses, see Routing in this article.
Note
Since the gateway URL is not registered on the public DNS, the test console available on the Azure portal will not work for an internal VNet deployed service. Instead, use the test console provided on the developer portal.
Azure Resource Manager template (API version 2021-08-01 )
Create or update an API Management instance in a VNet.
Configure custom network rules in the API Management subnet to filter traffic to and from your API Management instance. We recommend the following minimum NSG rules to ensure proper operation and access to your instance. Review your environment carefully to determine more rules that might be needed.
მნიშვნელოვანი
Depending on your use of caching and other features, you may need to configure additional NSG rules beyond the minimum rules in the following table. For detailed settings, see Virtual network configuration reference.
| Direction | Source service tag | Source port ranges | Destination service tag | Destination port ranges | Protocol | Action | Purpose | VNet type |
|---|---|---|---|---|---|---|---|---|
| Inbound | Internet | * | VirtualNetwork | [80], 443 | TCP | Allow | Client communication to API Management | External only |
| Inbound | ApiManagement | * | VirtualNetwork | 3443 | TCP | Allow | Management endpoint for Azure portal and PowerShell | External & Internal |
| Inbound | AzureLoadBalancer | * | VirtualNetwork | 6390 | TCP | Allow | Azure Infrastructure Load Balancer | External & Internal |
| Inbound | AzureTrafficManager | * | VirtualNetwork | 443 | TCP | Allow | Azure Traffic Manager routing for multi-region deployment | External only |
| Outbound | VirtualNetwork | * | Storage | 443 | TCP | Allow | Dependency on Azure Storage for core service functionality | External & Internal |
| Outbound | VirtualNetwork | * | SQL | 1433 | TCP | Allow | Access to Azure SQL endpoints for core service functionality | External & Internal |
| Outbound | VirtualNetwork | * | AzureKeyVault | 443 | TCP | Allow | Access to Azure Key Vault for core service functionality | External & Internal |
| Outbound | VirtualNetwork | * | AzureMonitor | 1886, 443 | TCP | Allow | Publish Diagnostics Logs and Metrics, Resource Health, and Application Insights | External & Internal |
In internal VNet mode, you have to manage your own DNS to enable inbound access to your API Management endpoints.
We recommend:
Learn how to set up a private zone in Azure DNS.
Note
The API Management service does not listen to requests on its IP addresses. It only responds to requests to the hostname configured on its endpoints. These endpoints include:
When you create an API Management service (contosointernalvnet, for example), the following endpoints are configured by default:
| Endpoint | Endpoint configuration |
|---|---|
| API Gateway | contosointernalvnet.azure-api.net |
| Developer portal | contosointernalvnet.portal.azure-api.net |
| The new developer portal | contosointernalvnet.developer.azure-api.net |
| Direct management endpoint | contosointernalvnet.management.azure-api.net |
| Git | contosointernalvnet.scm.azure-api.net |
If you don't want to access the API Management service with the default host names, set up custom domain names for all your endpoints, as shown in the following image:
Create records in your DNS server to access the endpoints accessible from within your VNet. Map the endpoint records to the private virtual IP address for your service.
For testing purposes, you might update the hosts file on a virtual machine in a subnet connected to the VNet in which API Management is deployed. Assuming the private virtual IP address for your service is 10.1.0.5, you can map the hosts file as follows. The hosts mapping file is at %SystemDrive%\drivers\etc\hosts (Windows) or /etc/hosts (Linux, macOS).
| Internal virtual IP address | Endpoint configuration |
|---|---|
| 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 |
You can then access all the API Management endpoints from the virtual machine you created.
The following virtual IP addresses are configured for an API Management instance in an internal virtual network.
| Virtual IP address | Description |
|---|---|
| Private virtual IP address | A load balanced IP address from within the API Management instance's subnet range (DIP), over which you can access the API gateway, developer portal, management, and Git endpoints. Register this address with the DNS servers used by the VNet. |
| Public virtual IP address | Used only for control plane traffic to the management endpoint over port 3443. Can be locked down to the ApiManagement service tag. |
The load-balanced public and private IP addresses can be found on the Overview blade in the Azure portal.
For more information and considerations, see IP addresses of Azure API Management.
Dynamic IP (DIP) addresses will be assigned to each underlying virtual machine in the service and used to access endpoints and resources in the VNet and in peered VNets. The API Management service's public virtual IP (VIP) address will be used to access public-facing resources.
If IP restriction lists secure resources within the VNet or peered VNets, we recommend specifying the entire subnet range where the API Management service is deployed to grant or restrict access from the service.
Learn more about the recommended subnet size.
If you deploy 1 capacity unit of API Management in the Premium tier in an internal VNet, 3 IP addresses will be used: 1 for the private VIP and one each for the DIPs for two VMs. If you scale out to 4 units, more IPs will be consumed for additional DIPs from the subnet.
If the destination endpoint has allow-listed only a fixed set of DIPs, connection failures will result if you add new units in the future. For this reason and since the subnet is entirely in your control, we recommend allow-listing the entire subnet in the backend.
Forced tunneling lets you redirect or "force" all internet-bound traffic from your subnet back to on-premises for inspection and auditing. Commonly, you configure and define your own default route (0.0.0.0/0), forcing all traffic from the API Management subnet to flow through an on-premises firewall or to a network virtual appliance. This traffic flow breaks connectivity with API Management, since outbound traffic is either blocked on-premises, or NAT'd to an unrecognizable set of addresses that no longer work with various Azure endpoints. You can solve this issue via the following methods:
Enable service endpoints on the subnet in which the API Management service is deployed for:
stv2 platform)By enabling endpoints directly from the API Management subnet to these services, you can use the Microsoft Azure backbone network, providing optimal routing for service traffic. If you use service endpoints with a force tunneled API Management, traffic for the preceding Azure services isn't force tunneled. However, the other API Management service dependency traffic remains force tunneled. Ensure that your firewall or virtual appliance doesn't block this traffic, or the API Management service may not function properly.
Note
We strongly recommend enabling service endpoints directly from the API Management subnet to dependent services such as Azure SQL and Azure Storage that support them. However, some organizations may have requirements to force tunnel all traffic from the API Management subnet. In this case, ensure that you configure your firewall or virtual appliance to allow this traffic. You will need to allow the complete IP address range of each dependent service, and keep this configuration up to date when the Azure infrastructure changes. Your API Management service may also experience latency or unexpected timeouts because of the force tunneling of this network traffic.
All the control plane traffic from the internet to the management endpoint of your API Management service is routed through a specific set of inbound IPs, hosted by API Management, encompassed by the ApiManagement service tag. When the traffic is force tunneled, the responses won't symmetrically map back to these inbound source IPs and connectivity to the management endpoint is lost. To overcome this limitation, configure a user-defined route (UDR) for the ApiManagement service tag with next hop type set to "Internet", to steer traffic back to Azure.
Note
Allowing API Management management traffic to bypass an on-premises firewall or network virtual appliance isn't considered a significant security risk. The recommended configuration for your API Management subnet allows inbound management traffic on port 3443 only from the set of Azure IP addresses encompassed by the ApiManagement service tag. The recommended UDR configuration is only for the return path of this Azure traffic.
(External VNet mode) Data plane traffic for clients attempting to reach the API Management gateway and developer portal from the internet will also be dropped by default because of asymmetric routing introduced by forced tunneling. For each client that requires access, configure an explicit UDR with next hop type "Internet" to bypass the firewall or virtual network appliance.
For other force tunneled API Management service dependencies, resolve the hostname and reach out to the endpoint. These include:
For more information, see Virtual network configuration reference.
This section has moved. See Virtual network configuration reference.
stv2 platform)მნიშვნელოვანი
After validating the connectivity, remove all the resources in the subnet before deploying API Management into the subnet (required when API Management is hosted on the stv1 platform).
After deploying API Management into the subnet, use the portal to check the connectivity of your instance to dependencies, such as Azure Storage.
In the portal, in the left-hand menu, under Deployment and infrastructure, select Network > Network status.
| Filter | Description |
|---|---|
| Required | Select to review the required Azure services connectivity for API Management. Failure indicates that the instance is unable to perform core operations to manage APIs. |
| Optional | Select to review the optional services connectivity. Failure indicates only that the specific functionality won't work (for example, SMTP). Failure may lead to degradation in using and monitoring the API Management instance and providing the committed SLA. |
To help troubleshoot connectivity issues, select:
Metrics - to review network connectivity status metrics
Diagnose - to run a virtual network verifier over a specified time period
To address connectivity issues, review network configuration settings and fix required network settings.
When making changes to your network, refer to NetworkStatus API to verify that the API Management service hasn't lost access to critical resources. The connectivity status should be updated every 15 minutes.
To apply a network configuration change to the API Management instance using the portal:
An API Management instance hosted on the stv1 compute platform, when deployed into a Resource Manager VNet subnet, reserves the subnet by creating a resource navigation link. If the subnet already contains a resource from a different provider, deployment will fail. Similarly, when you delete an API Management service, or move it to a different subnet, the resource navigation link will be removed.
stv1 platform-based API Management services (cloud service-based), deleting them and waiting is necessary for deploying an stv2 platform-based service in the same subnet.Network connectivity to Microsoft Graph is needed for features including user sign-in to the developer portal using the Microsoft Entra identity provider.
To troubleshoot connectivity to Microsoft Graph from inside a VNet:
Ensure that NSG and other network rules are configured for outbound connectivity from your API Management instance to Microsoft Graph (using the AzureActiveDirectory service tag).
Ensure DNS resolution and network access to graph.microsoft.com from within the VNet. For example, provision a new VM inside the VNet, connect to it, and try to GET https://graph.microsoft.com/v1.0/$metadata from a browser or using cURL, PowerShell, or other tools.
Learn more about:
ღონისძიებები
შექმენით ინტელექტუალური პროგრამები
Mar 17, 9 PM - Mar 21, 10 AM
შემოუერთდით Meetup სერიას, რათა შექმნათ მასშტაბური AI გადაწყვეტილებები რეალურ სამყაროში გამოყენების შემთხვევებზე დაყრდნობით თანამემამულე დეველოპერებთან და ექსპერტებთან.
დარეგისტრირდით ახლავეტრენინგი
მოდული
Implement and manage networking for Azure Virtual Desktop - Training
Implement and manage networking for Azure Virtual Desktop
სერტიფიკაცია
Microsoft Certified: Azure Network Engineer Associate - Certifications
Demonstrate the design, implementation, and maintenance of Azure networking infrastructure, load balancing traffic, network routing, and more.
დოკუმენტაცია
Deploy Azure API Management instance to external VNet
Learn how to deploy (inject) your Azure API instance to a virtual network in external mode and access API backends through it.
Azure API Management virtual network injection - network resources
Learn about requirements for network resources when you deploy (inject) your API Management Developer or Premium tier instance in an Azure virtual network.
Reference for network configuration settings when deploying Azure API Management to a virtual network