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
@@ -169,15 +168,18 @@ Backup is a long running operation that may take more than a minute to complete.
169
168
Note the following constraints when making a backup request:
170
169
171
170
-**Container** specified in the request body **must exist**.
172
-
- While backup is in progress, **avoid changes in service management** such as SKU upgrade or downgrade, change in domain name, and more.
171
+
- While backup is in progress, **avoid management changes in the service** such as SKU upgrade or downgrade, change in domain name, and more.
173
172
- Restore of a **backup is guaranteed only for 30 days** since the moment of its creation.
174
173
-**Usage data** used for creating analytics reports **isn't included** in the backup. Use [Azure API Management REST API][azure api management rest api] to periodically retrieve analytics reports for safekeeping.
175
174
- In addition, the following items are not part of the backup data: custom domain SSL certificates and any intermediate or root certificates uploaded by customer, developer portal content, and virtual network integration settings.
176
175
- The frequency with which you perform service backups affect your recovery point objective. To minimize it, we recommend implementing regular backups and performing on-demand backups after you make changes to your API Management service.
177
176
-**Changes** made to the service configuration, (for example, APIs, policies, and developer portal appearance) while backup operation is in process **might be excluded from the backup and will be lost**.
178
-
-**Allow** access from control plane to Azure Storage Account. Customer should open the following set of Inbound IPs on their Storage Account for Backup.
-**Allow** access from control plane to Azure Storage Account. Customer should open the set of [Azure API Management Control Plane IP Addresses][control-plane-ip-address] on their Storage Account for Backup.
178
+
179
+
> [!NOTE]
180
+
> If you have firewall enabled on the Storage Account and the are trying to do backup/restore from an API Management service in the same Region,
181
+
> then this will not work, as the requests to Azure Storage are not SNATed to public IP from Compute deployed in the same region.
182
+
181
183
### <aname="step2"> </a>Restore an API Management service
182
184
183
185
To restore an API Management service from a previously created backup, make the following HTTP request:
@@ -238,3 +240,4 @@ Check out the following resources for different walkthroughs of the backup/resto
| Azure Public | <ul><li>prod.warmpath.msftcloudes.com</li><li>shoebox2.metrics.nsatc.net</li><li>prod3.metrics.nsatc.net</li><li>prod3-black.prod3.metrics.nsatc.net</li><li>prod3-red.prod3.metrics.nsatc.net</li><li>prod.warm.ingestion.msftcloudes.com</li><li>`azure region`.warm.ingestion.msftcloudes.com where `East US 2` is eastus2.warm.ingestion.msftcloudes.com</li></ul> |
138
138
| Azure Government | <ul><li>fairfax.warmpath.usgovcloudapi.net</li><li>shoebox2.metrics.nsatc.net</li><li>prod3.metrics.nsatc.net</li></ul> |
139
-
| Azure China | <ul><li>mooncake.warmpath.chinacloudapi.cn</li><li>shoebox2.metrics.nsatc.net</li><li>prod3.metrics.nsatc.net</li></ul> |
139
+
| Azure China 21Vianet| <ul><li>mooncake.warmpath.chinacloudapi.cn</li><li>shoebox2.metrics.nsatc.net</li><li>prod3.metrics.nsatc.net</li></ul> |
140
140
141
141
+**SMTP Relay**: Outbound network connectivity for the SMTP Relay, which resolves under the host `smtpi-co1.msn.com`, `smtpi-ch1.msn.com`, `smtpi-db3.msn.com`, `smtpi-sin.msn.com` and `ies.global.microsoft.com`
142
142
@@ -148,13 +148,7 @@ When an API Management service instance is hosted in a VNET, the ports in the fo
148
148
149
149
* Enable service endpoints on the subnet in which the API Management service is deployed. [Service Endpoints][ServiceEndpoints] need to be enabled for Azure Sql, Azure Storage, Azure EventHub and Azure ServiceBus. Enabling endpoints directly from API Management delegated subnet to these services allows them to use the Microsoft Azure backbone network providing optimal routing for service traffic. If you use Service Endpoints with a forced tunneled Api Management, the above Azure services traffic isn't forced tunneled. The other API Management service dependency traffic is forced tunneled and can't be lost or the API Management service would not function properly.
150
150
151
-
* All the control plane traffic from Internet to the management endpoint of your API Management service are routed through a specific set of Inbound IPs hosted by API Management. When the traffic is force tunneled the responses will not symmetrically map back to these Inbound source IPs. To overcome the limitation, we need to add the following user-defined routes ([UDRs][UDRs]) to steer traffic back to Azure by setting the destination of these host routes to "Internet". The set of Inbound IPs for control Plane traffic is as follows:
| Azure Government | 52.127.42.160/32, 52.127.34.192/32 |
157
-
| Azure China | 139.217.51.16/32, 139.217.171.176/32 |
151
+
* All the control plane traffic from Internet to the management endpoint of your API Management service are routed through a specific set of Inbound IPs hosted by API Management. When the traffic is force tunneled the responses will not symmetrically map back to these Inbound source IPs. To overcome the limitation, we need to add the following user-defined routes ([UDRs][UDRs]) to steer traffic back to Azure by setting the destination of these host routes to "Internet". The set of Inbound IPs for control Plane traffic is documented [Control Plane IP Addresses](#control-plane-ips)
158
152
159
153
* For other API Management service dependencies which are force tunneled, there should be a way to resolve the hostname and reach out to the endpoint. These include
160
154
- Metrics and Health Monitoring
@@ -180,7 +174,7 @@ Azure reserves some IP addresses within each subnet, and these addresses can't b
180
174
181
175
In addition to the IP addresses used by the Azure VNET infrastructure, each Api Management instance in the subnet uses two IP addresses per unit of Premium SKU or one IP address for the Developer SKU. Each instance reserves an additional IP address for the external load balancer. When deploying into Internal vnet, it requires an additional IP address for the internal load balancer.
182
176
183
-
Given the calculation above the minimum size of the subnet, in which API Management can be deployed is /29 which gives three IP addresses.
177
+
Given the calculation above the minimum size of the subnet, in which API Management can be deployed is /29 that gives three usable IP addresses.
184
178
185
179
## <aname="routing"> </a> Routing
186
180
+ A load balanced public IP address (VIP) will be reserved to provide access to all service endpoints.
@@ -194,12 +188,76 @@ Given the calculation above the minimum size of the subnet, in which API Managem
194
188
* For multi-region API Management deployments configured in Internal virtual network mode, users are responsible for managing the load balancing across multiple regions, as they own the routing.
195
189
* Connectivity from a resource in a globally peered VNET in another region to API Management service in Internal mode will not work due to platform limitation. For more information, see [Resources in one virtual network cannot communicate with Azure internal load balancer in peered virtual network](../virtual-network/virtual-network-manage-peering.md#requirements-and-constraints)
196
190
191
+
## <aname="control-plane-ips"> </a> Control Plane IP Addresses
192
+
193
+
The IP Addresses are divided by **Azure Environment**. When allowing inbound requests IP address marked with **Global** must be whitelisted along with the **Region** specific IP Address.
0 commit comments