You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/api-management/api-management-using-with-internal-vnet.md
+10-5Lines changed: 10 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,10 @@ With Azure Virtual Networks, Azure API Management can manage APIs not accessible
23
23
* External
24
24
* Internal
25
25
26
-
When API Management deploys in internal virtual network mode, all the service endpoints (gateway, the Developer portal, the Azure portal, direct management, and Git) are only visible inside a virtual network that you control the access to. None of the service endpoints are registered on the public DNS server.
26
+
When API Management deploys in internal virtual network mode, all the service endpoints (the proxy gateway, the Developer portal, direct management, and Git) are only visible within a virtual network that you control the access to. None of the service endpoints are registered on the public DNS server.
27
+
28
+
> [!NOTE]
29
+
> Because there are no DNS entries for the service endpoints, these endpoints will not be accessible until [DNS is configured](#apim-dns-configuration) for the virtual network.
27
30
28
31
Using API Management in internal mode, you can achieve the following scenarios:
29
32
@@ -113,10 +116,12 @@ If you use a custom DNS server in a virtual network, you can also create A DNS r
113
116
2. Then you can create records in your DNS server to access the endpoints that are only accessible from within your virtual network.
114
117
115
118
## <aname="routing"> </a> Routing
116
-
+ A load balanced private virtual IP address from the subnet range will be reserved and used to access the API Management service endpoints from within the vnet.
117
-
+ A load balanced public IP address (VIP) will also be reserved to provide access to the management service endpoint only over port 3443.
118
-
+ An IP address from a subnet IP range (DIP) will be used to access resources within the vnet and a public IP address (VIP) will be used to access resources outside the vnet.
119
-
+ Load balanced public and private IP addresses can be found on the Overview/Essentials blade in the Azure portal.
119
+
120
+
* A load balanced *private* virtual IP address from the subnet range will be reserved and used to access the API Management service endpoints from within the virtual network. This *private* IP address can be found on the Overview blade for the service in the Azure portal. This address must be registered with the DNS servers used by the virtual network.
121
+
* A load balanced *public* IP address (VIP) will also be reserved to provide access to the management service endpoint over port 3443. This *public* IP address can be found on the Overview blade for the service in the Azure portal. The *public* IP address is used only for control plane traffic to the `management` endpoint over port 3443 and can be locked down to the [ApiManagement][ServiceTags] servicetag.
122
+
* IP addresses from the subnet IP range (DIP) will be assigned to each VM in the service and will used to access resources within the virtual network. A public IP address (VIP) will be used to access resources outside the virtual network. If IP restriction lists are used to secure resources within the virtual network, the entire range for the subnet where the API Management service is deployed must specified to grant or restrict access from the service.
123
+
* The load balanced public and private IP addresses can be found on the Overview blade in the Azure portal.
124
+
* The IP addresses assigned for public and private access may change if the service is removed from and then added back into the virtual network. If this happens, it may be necessary to update DNS registrations, routing rules, and IP restriction lists within the virtual network.
0 commit comments