API management is probably one of the best services you can use for abstracting back-end services and for presenting sets of APIs via one HTTP endpoint.

However, here are two important questions most organizations ask about API management:

1 – How to protect API management’s Internet-facing public endpoint?

2 – How to expose selected APIs while keeping others internal?

The good news is that Microsoft offers a blueprint to support this. There are a couple of architectural components you need:

• Deploy the API Management in the internal VNET Mode
• Get the WAF Application Gateway to expose subsets of APIs externally

Here is is a diagrammatic representation of what goes on:

However, there are some challenges you will face to achieve this. The blueprints work, but there are some comprehensive elements it omits. This post aims to provide a clearer guide to this scenario.

Architectural Overview

How to deem parts of the API “external” via the internet?

Is the configuration App Gateway or API-M?

The answers to these questions are easy:

Within the API-M, there are separate APIs created based on their /external and /internal URLs

The path-based routing rule inside the API Gateway redirects all API requests that have /external in their URL to the API-M back-end.

This same routing rule eliminates API requests with /internal in the URL

Here is what happens:

Note: The VNET integrations are available in either Premium or Developer tier. Work with the Developer mode for as long as you can because the Premium mode is quite costly. Maybe, eventually, Microsoft will offer a Basic and Standard tier in the future.

Certificates

If you want to add a custom domain to API-M and expose it via the App Gateway, you need two things:

• A public name to which you can add DNS records
• SSL certificate for the domain

Remember, the deployment script assumes that you would have these two certificates:

• yourdomain.org — for the API gateway
• yourdomain.org — for the developer portal

Use sslforfree.com for testing these certificates at no cost (free).

Deployment Script

Here are some important rules to recall before you proceed.

Adding a routine rule may not allow you to create the maps or allow you to apply routing rules in one single operation. This is why, the script first deploys the App Gateway, and then proceeds to apply the “external” routing rule.

It takes time to deploy the resources. Expect at least 60mins run-time.

Here is the extra code you may need for the routing rule:

DNS Resolution

When you configure the API Management to a custom domain, it will respond only to the new host address, i.e., those mentioned above.

These two scenarios follow:

• Externally: external DNS – >App Gateway Public IP Address
• Internally: internal DNS/hosts file – > API-M private IP Address

Testing

You have two scenarios you must test:

1. Assess the API across the Internet via the App Gateway

a – The external API should succeed

b – The Internal API should fail

2.  Assess the API’s internally

a – Both external and internal APIs should succeed

Conclusion

There may be some differences in the architecture, and you need to find the missing pieces on your own.

Individual configurations of these components are quite straightforward.

With this setup, you can have a single API-M and use the Application Gateway to publish a subset of APIs.