Publish internal APIs to external users

In this scenario, an organization consolidates multiple APIs internally using Azure API Management deployed inside a Virtual Network.

Architecture

Download a Visio file of this architecture.

The preceding diagram covers a complete lifecycle of internal APIs that are consumed by the external users.

Dataflow

The data flows as follows:

1. Developers check in code to a GitHub repository that's connected to a CI/CD pipeline agent that's installed on an Azure VM.
2. The agent pushes the build to the API application that's hosted on ILB ASE.
3. Azure API Management consumes the preceding APIs via HOST headers that are specified in API Management policy.
4. API Management uses the App Service Environment's DNS name for all the APIs.
5. Application Gateway exposes API Management's developer and API portal.
6. Azure Private DNS is used to route the traffic internally between ASE, API Management, and Application Gateway.
7. External users utilize the exposed developer portal to consume the APIs via Application Gateway's public IP.

Components

• Azure Virtual Network enables Azure resources to securely communicate with each other, the internet, and on-premises networks.
• Azure Private DNS allows domain names to be resolved in a virtual network without needing to add a custom DNS solution.
• Azure API Management helps organizations publish APIs to external, partner, and internal developers to use their data and services.
• Application Gateway is a web traffic load balancer that helps you to manage traffic to your web applications.
• Internal Load Balancer App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.
• Azure DevOps is a service for managing your development lifecycle and includes features for planning and project management, code management, build, and release.
• Application Insights is an extensible Application Performance Management (APM) service for web developers on multiple platforms.
• Azure Cosmos DB is Microsoft's globally distributed, multi-model database service.

Alternatives

• In an Azure lift and shift scenario deployed into an Azure Virtual Network, back-end servers could be directly addressed through private IP addresses.
• If using on-premises resources, the API Management instance could reach back to the internal service privately via an Azure VPN gateway and site-to-site IPSec VPN connection or ExpressRoute making a hybrid Azure and on-premises scenario.
• Existing or open-source DNS providers could be used instead of the Azure-based DNS Service.
• Internal APIs deployed outside of Azure can still benefit by exposing the APIs through API Management Service.

Scenario details

In this scenario, an organization hosts multiple APIs using Azure Application Service Environment (ILB ASE), and they want to consolidate these APIs internally by using Azure API Management (APIM) deployed inside a Virtual Network. The internal API Management instance could also be exposed to external users to allow for utilization of the full potential of the APIs. This external exposure could be achieved using Azure Application Gateway forwarding requests to the internal API Management service, which in turn consumes the APIs deployed in the ASE.

• The web APIs are hosted over secured HTTPS protocol and will be using a TLS Certificate.
• The Application Gateway also is configured over port 443 for secured and reliable outbound calls.
• The API Management service is configured to use custom domains using TLS certificates.
• Review the suggested network configuration for App Service Environments
• There needs to be an explicit mention about port 3443 allowing API Management to manage via the Azure portal or PowerShell.
• Leverage policies within APIM to add a HOST header for the API hosted on ASE. This ensures that the ASE's load balancer will properly forward the request.
• The API Management accepts ASE's DNS entry for all the apps hosted under App Service Environments. Add an APIM policy to explicitly set the HOST header to allow the ASE load balancer to differentiate between Apps under the App Service Environment.
• Consider Integrating with Azure Application Insights, which also surfaces metrics through Azure Monitor for monitoring.
• If you use CI/CD pipelines for deploying Internal APIs, consider building your own Hosted Agent on a VM inside the Virtual Network.

Potential use cases

• Synchronize customer address information internally after the customer makes a change.
• Attract developers to your platform by exposing unique data assets.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Reliability

Reliability ensures your application can meet the commitments you make to your customers. For more information, see Overview of the reliability pillar."

Availability

You can deploy Azure API Management service as a Multi-Region deployment for higher availability and also to reduce latencies. This feature is only available in Premium mode. The API Management service in this specific scenario consumes APIs from App Service Environments. You can also use APIM for APIs hosted on the internal on-premises infrastructure.

App Service Environments could make use of Traffic Manager profiles to distribute the traffic hosted on App Service Environments for higher scale and availability.

Resiliency

Though this example scenario talks more about configuration, the APIs hosted on the App Service Environments should be resilient enough to handle errors in the requests, which are eventually managed by the API Management service and Application Gateway. Consider Retry and Circuit breaker patterns in the API design. For general guidance on designing resilient solutions, see Designing resilient applications for Azure.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

Because the preceding example scenario is hosted completely on an internal network, API Management and ASE are already deployed on secured infrastructure (Azure VNet). You can integrate Application Gateways with Microsoft Defender for Cloud to provide a seamless way to prevent, detect, and respond to threats to the environment. For general guidance on designing secure solutions, see the Azure Security Documentation.

Cost optimization

Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.

API Management is offered in four tiers: developer, basic, standard, and premium. You can find detailed guidance on the difference in these tiers at the Azure API Management pricing guidance here.

Customers can scale API Management by adding and removing units. Each unit has capacity that depends on its tier.

To view projected costs and customize to your deployment needs, you can modify the number of scale units and App Service instances in the Azure Pricing Calculator.

Similarly, you can find the App Service Environments pricing guidance.

You can configure Application Gateway pricing depending upon the required tier and resources.

Performance efficiency

Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner. For more information, see Performance efficiency pillar overview.

Scalability

You can scale out API Management instances depending upon a number of factors, like number and rate of concurrent connections, the kind and number of configured policies, request and response sizes, and back-end latencies on the APIs. Scaling out instance options are available in Basic, Standard, and Premium Tiers, but are bound by an upper scale limit in Basic and Standard tiers. The instances are referred to as Units and can be scaled up to a max of two units in Basic tier, four units in Standard tier and any number of units in the Premium tier. Auto Scaling options are also available to enable scale out based on rules.

App Service Environments are designed for scale with limits based on the pricing tier. You can configure the apps hosted under the App Service Environments to scale out (number of instances) or scale up (instance size) depending upon the requirements of the application.

Azure Application Gateway auto scaling is available as a part of the Zone redundant SKU in all global Azure regions. See the public preview feature regarding App gateway Auto scaling.

Deploy this scenario

Prerequisites and assumptions

1. You need to purchase a custom domain name.
2. You need a TLS certificate (we used a wildcard certificate from Azure Certificates Service) to use one for all our custom domains. You can also procure a self-signed certificate for Dev Test scenarios.
3. This specific deployment uses the domain name contoso.org and a wildcard TLS certificate for the domain.
4. The deployment uses the resource names and address spaces mentioned in the Deployment section. You can configure the resource names and address spaces.

Deployment and putting the pieces together

You need to further configure the components deployed using the preceding Resource Manager template as follows:

1. VNet with the following configurations:

   • Name: ase-internal-vnet
   • Address space for VNet: 10.0.0.0/16
   • Four Subnets
     • backendSubnet for DNS Service: 10.0.0.0/24
     • apimsubnet for Internal API Management Service: 10.0.1.0/28
     • asesubnet for ILB ASE: 10.0.2.0/24
     • VMSubnet for Test VMs and Internal DevOps Hosted Agent VM: 10.0.3.0/24

2. Private DNS service (Public Preview) since adding a DNS service requires the VNet to be empty.

   • Refer to the deployment guidelines for more information

3. App Service Environment with Internal Load Balancer (ILB) option: aseinternal (DNS: aseinternal.contoso.org). Once the Deployment is complete, upload the wild-card cert for the ILB

4. App Service Plan with ASE as location

5. An API App (App Services for simplicity) - srasprest (URL: https://srasprest.contoso.org) – ASP.NET MVC-based web API. After the deployment, configure:

   • Web app to use the TLS certificate
   • Application Insights to the preceding apps: api-insights
   • Create an Azure Cosmos DB service for web APIs hosted internal to VNet: noderestapidb
   • Create DNS entries on the Private DNS zone created
   • You can make use of Azure Pipelines to configure the agents on Virtual Machines to deploy the code for Web App on internal Network
   • For testing the API App internally, create a test VM within the VNet subnet

6. Create API Management service: apim-internal

7. Configure the service to connect to internal VNet on Subnet: apimsubnet. After the deployment is complete, perform the following additional steps:

   • Configure custom domains for APIM Services using TLS
     • API portal (api.contoso.org)
     • Dev Portal (portal.contoso.org)
     • In the APIs section, configure the ASE Apps using ASE's DNS name added Policy for HOST Header for the Web app
     • Use the preceding created test VM to test the API Management service internal on the Virtual Network

   Note

   Testing the APIM APIs from the Azure portal won't work, because api.contoso.org isn't able to be publicly resolved.*

8. Configure the Application Gateway (WAF V1) to access the API service: apim-gateway on Port 80. Add TLS certs to the Application Gateway and corresponding health probes and http settings. Also configure the Rules and Listeners to use the TLS cert.

Once the preceding steps are successfully completed, configure the DNS entries in the web registrar CNAME entries of api.contoso.org and portal.contoso.org with the Application Gateway's public DNS name: ase-appgtwy.westus.cloudapp.azure.com. Verify that you're able to reach the Dev Portal from Public and that you're able to test the APIM services APIs using the Azure portal.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributor.

Principal author:

• Srikant Sarwa | Senior Customer Engineer

Other contributors:

• Shawn Kupfer | Technical Writer

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps

• Tutorial: Import and publish your first API
• Tutorial: Create and publish a product
• Tutorial: Publish multiple versions of your API

Related resources

Migrate a web app using Azure API Management