APIM's premium tied provided multi-regional capability. This ensures that APIM node is closer to possible client, and in addition if one of regions fail, traffic will be rerouted to other regions. But this is guaranteed only between client and APIM node, no such guarantees are made for APIM<->backend communication, since from APIM side there is no way to infer your backend infrastructure. So this requires some configuration.
You could use Traffic Manager in front of your backend to aggregate multiple backend endpoints into one and rely on health probes to route traffic (much like APIM does for its own regional endpoints).
Alternatively you could handle multiple backend endpoints in APIM policies switching traffic between one and another on some condition. Here is some simple implementation of this:
<policies>
<inbound>
<base />
</inbound>
<backend>
<retry condition="@(context.Response.StatusCode >= 500)" count="1" interval="0" first-fast-retry="true">
<choose>
<when condition="@(context.Response.StatusCode >= 500)">
<set-backend-service base-url="https://my-second-endpoint" />
</when>
</choose>
<forward-request />
</retry>
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Now this is quite inefficient, since it always makes first call to a default endpoint, waits for 500 and makes second call to an alternative one. You could improve that by employing caching policies to store active endpoint, and do switch when you detect 500.
Or you can have static configuration and rely on external health probes and automation to update APIM policies in case of incident.
You could try to set your status code as 302 and when it satisfy the status code it will use the corresponding backend service. Here is sample code:
<when condition="condition="@(context.Response != null && (context.Response.StatusCode==302))">
For more details, you could refer to this article and this one.
