skip to Main Content

I have a virtual network (vnet) configured, it has subnets defined for private endpoints, web apps, databases and vpn point to site etc…

The point is simple, I dont want any of my services accessible via the internet.

I am trying to configure an azure api management service (APIM) in order to be the gateway to access all my api’s in the vnet.

Is there a method of setting this up? as it would seem the only way to do this is via adding the APIM to the VNET which only works with with a premium AMS service and that’s way out of my price range?

I dont think the APIM private inbound endpoint works the way I want them to

Cheers

2

Answers


  1. Yes, you can integrate APIM into a VNet to connect to private backends. But yes, that requires Premium tier.

    See here https://learn.microsoft.com/en-us/azure/api-management/api-management-using-with-vnet?tabs=stv2

    The alternative would be to lock down all your backend services using network filtering to only allow traffic originating from your APIM, even if they still have public endpoints.

    Login or Signup to reply.
  2. One point at add from what @silent mentioned. If you’re critically focused on VNet usage, the way that APIM works under the covers might give you a mild concern for pause.

    APIM will still need a public IP address attached to it. This is because there is a management API for APIM that needs to be reached via thh Azure Portal, CLI, PowerShell, ARM, Terraform, whatever. That component does not live on the VNet. It manages the a functional components of APIM, which is a VM Scale Set. This includes the Network Load Balancer (which holds the VIP and does live on your VNet) and the virtual machines that are the "gateways" that also live on your VNet.

    The documentation and deployment require specific NSG rules because the Management API has to reach into the VNet through the SD Networking goodness. However, even though that works, other things do not. When you setup an API, the "Testing" functionality inside the APIM resource doesn’t work because those tests from from the Management system that doesn’t live in your VNet. Also, not documented anywhere I could find, adding internal APIs by importing the schema through a URL… that also will not work because it originates form the the Management system… that doesn’t live on your VNet.

    In my view, this should be fixed architecturally in APIM. The gateways have IP line of sight to the resources. The Management system should just hand those requests over to the gateways which could be handled through a queue and then return the response to the queue.

    I have been dealing with AWS a lot lately and the way APIM works feels a lot like the duct tape and bailing wire of everything in AWS. I rarely get that feeling when working with Azure resources.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search