1. Hosting:

    1. Azure Regions

      For this application, two Azure Datacenters are located at USE2 as primary region and North Europe. 

    2. Environments

      Subscriptions Environment Contributor On RG APIM IP Address Resource Groups
      SDX GLOBAL SHARED SERVICES DEV SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.170.5 IST-GLB-USE2-SAS-DEV-RG01
      SDX GLOBAL SHARED SERVICES DEV SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.138.197 IST-GLB-IENO-SAS-DEV-RG01
      Subscriptions Environment Contributor On RG APIM IP Address Resource Groups
      SDX GLOBAL SHARED SERVICES UAT SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.169.198 IST-GLB-USE2-SAS-UAT-RG01
      SDX GLOBAL SHARED SERVICES UAT SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.138.230 IST-GLB-IENO-SAS-UAT-RG01
      Subscriptions Environment Contributor On RG APIM IP Address Resource Groups
      SDX GLOBAL SHARED SERVICES PRD SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.168.70 IST-GLB-USE2-SAS-PRD-RG01
      SDX GLOBAL SHARED SERVICES PRD SG.CE.FR.ILM-GIS_APIM_TEAM 10.167.138.246 IST-GLB-IENO-SAS-PRD-RG01

    3. Platform Components

  2. Network:

  3. Routing Mechanism:

    Azure Front Door supports different kinds of traffic-routing methods to determine how to route HTTP/HTTPS traffic to different service endpoints. When client requests reaching Front Door, the configured routing method gets applied to ensure the requests are forwarded to the best backend instance.

    Lowest latencies-based traffic-routing The default traffic-routing method for Front Door configuration forwards requests from Internet to the closest backend of the Front Door environment that received the request. Combined with the Anycast architecture of Azure Front Door, this approach ensures that each of the request get maximum performance personalized based on the request location.

    The 'closest' backend isn't necessarily closest as measured by geographic distance. Instead, Front Door determines the closest backends by measuring network latency

    Before we dive deep into flow mechanism, one important point to mention is that BUs are solely responsible for deployment of their APIs (with respect to regions) The above flow diagram shows the sample request routing from either US or IENO region. Please see below the scenarios considered in the routing mechanism

    1. BUs deploying backend APIs in 1 region (For Ex: CoEU) and serving users from multiple regions

      1. Request from a user in EU

        User Request -> Azure Front Door Europe server -> EU NVA Server -> EU APIM Gateway -> Backend API

      2. Request from a user outside EU (For ex: US)

        User Request -> Azure Front Door US server -> US NVA Server -> GDS NA -> ISONET -> EU NVA Server -> EU APIM Gateway -> Backend API

    2. BUs deploying backend APIs in 1 region (For Ex: CoEU) and serving users from that region alone

      1. Request from a user in EU

        User Request -> Azure FD EU server -> EU NVA Server -> EU APIM Gateway -> Backend API

    3. BUs deploying backend APIs in multiple regions and serving users from all the regions (Future Enhancements)

      1. Request from a user who is in the region where API server is available

      2. Request from a user who is outside of any region where API server is available

  4. Performance Posture

    The Shared APIM will be deployed on Azure API Management with Premium tier. Below are the features of Premium tier. Premium tier supports

    Shared APIM will be added autoscaling capability through Azure Monitor. However, it will be auto scaled up to maximum requirement of RPS by any BU. Shared APIM will be auto scaled by 1 unit at a time and will be scaled down if RPS goes down. This will be done to keep a check on the costs