Azure APIM and Application Gateway Integration

mahammad thahif
6 min readJun 12, 2023

--

Of late, I happened to work on a customer project for setting up a cloud based integration platform. The customer’s existing gateway solutions TIBCO, CA were reaching end of life and license had to be renewed. As part of their long term cloud strategy, they wanted to adopt a modern cloud based integration solution which is secure, scalable and allows cost segregation amongst the different departments of the organization

The obvious choice was to choose Azure APIM — API management service which provides multiple benefits such as

  • Abstract backend architecture diversity and complexity from API consumers
  • Securely expose services hosted on and outside of Azure as APIs
  • Protect, accelerate, and observe APIs
  • Enable API discovery and consumption by internal and external users

Before we dive in, let’s look at some of the key requirements of the project.

  1. Design a secure, scalable integration platform that should cater to both internal & external consumers
  2. The APIM service should not be publicly exposed
  3. The APIM should allow traffic originating only from a particular region/country
  4. The communication should be end to end encrypted
  5. Expose developer portal to only internal consumers
  6. Enable a chargeback mechanism when the APIs are being used by multiple departments/agencies
  7. NO DR requirement

Architecture

To accommodate all of these requirements, we choose Azure APIM combination with application gateway as a front end. The app GW would act as a reverse proxy , protecting the APIM which will be deployed in an internal mode. The App GW is also attached with WAF (v2) instance to accommodate other aspects of the design requirements ,such as Geo filtering and to protect against common OWASP vulnerabilities.

Implementation

Create an application gateway in a separate subnet, ensure enough CIDR range to accommodate scaling requirements.

Ensure below key points while deploying the App GW.

  • Since a single app gateway is used to terminate both internal and external traffic, it is essential to create 2 listeners.

Public-listener — Public IP as the frontend IP

Pvt-listener — Private IP as the frontend IP

One important factor to keep in mind, the SSL certificate that needs to be uploaded to listener configuration should be properly created in pfx format. This can be placed in keyvault or manually uploaded from the local machine.

Whether the certificate was procured from an external vendor or self-signed certificates, make sure it contains data from actual domain pfx certificate as well as from intermediatory certificate.

In short, we have to export both domain certificate and intermediatory certificates in pfx format, combine them and then upload to listener configuration.

  • Create 2 backend pools, one with custom domain name of API GW and another one with custom domain of the developer portal
  • Create 2 backend settings , one for the gateway and another for the developer portal .Ensure to make it as HTTPS.
  • Create 2 custom probes. Note both Path and response code match parameters.

Test the probes before proceeding.

Gateway custom probe properties

Portal custom probe properties

  • Create 3 Rules combining all the above settings.

1 rule for combining public listener, GW backend pool, GW backend setting and custom GW probe.

1 rule for combining pvt listener, GW backend pool, GW backend setting and custom GW probe.

1 rule for combining pvt listener, dev portal backend pool, dev portal backend setting and custom dev portal probe.

  • When same port is used (443) for both pvt and public listeners, some NSG rules need to be created.
  • Configure app GW specific NSG rules for the proper functioning of the application gateway

As a next step, let’s look at the APIM deployment key points.

Deploy APIM in an internal mode with appropriate SKU as decided.

Create custom domain for the gateway and portal URLs.

Create APIM specific NSG rules for APIM to work properly.

Procure an SSL certificate for your API endpoint. Make sure to procure either a wildcard or SAN certificate to accommodate all the URLs.

Ex: https://yourpublicapi.yourdomain.com — publicly exposed API endpoint pointing to app GW public IP

https://prodapigw.yourdomain.com — API GW custom domain URL mapped to GW URL

https://proddevportal.yourdomain.com — APIM custom domain mapped to developer portal

This completes the integration of APIM with app gateway from networking perspective. As a next step, start creating APIs with appropriate policies and authorizations.

DNS Resolution

Since we have consumers originating from external and internal, it is imperative to get the DNS configured correctly.

In your external DNS provider (like GoDaaddy) , create an A record pointing to App GW’s public IP.

In your internal DNS server , create an A record pointing to App GW’s private IP.

Create 2 more A records per below to complete the DNS config.

A record pointing APIM GW custom URL to pvt IP of the APIM

A record pointing APIM developer portal URL to pvt IP of the APIM

WAF Configuration

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection of your web applications from common exploits and vulnerabilities.

Our requirement was to allow traffic emerging from a particular region and enable all the managed rulesets.

Create a custom geo location rule , allowing traffic alone from the required region.

Initially , enable WAF in Detection mode for some days and switch to prevention mode to prevent any legitimate request being dropped!

Note: If you expose development portal and management endpoint externally through the app GW, make sure to disable mentioned WAF rules for the proper functioning.

Testing

Test, Test, Test !

End to end testing crucial in any implementation, especially in API based setup when requests are initiated from multiple different locations, systems and departments.

Look at the simple GET requests to a backend service served from a 3rd party, notice the API GW URL , which is in turn pointed to app gateway public IP.

Additional Tips

If you use other PaaS service for backend processes such as logic app, service bus or event hubs, enable private endpoint as a best practice.

If your provider works based on IP whitelisting, APIM public IP will be used for making outbound IP connections.

Conclusion

With this long post, we have seen how an APIM can be securely deployed in an internal mode and how App gateway can be front ended to handle the API requests. The app gateway public and pvt IP acts as the entry point for originating requests and accordingly forwards the requests to backend pools.

This architecture can be extended to include multiple APIM services as backend with appropriate listener configuration done on the app gateway side.

--

--