Introduction to Azure Function Proxies

Let’s discuss about Azure Function Proxies which provides “Reverse Proxy Functionality” for Azure Functions. Azure Function Proxies is quite similar to Azure API management.  This episode is largely inspired by Matthew Henderson of Microsoft Azure Function Team. In his blog post – Azure Functions Proxies public preview, Matthew explains the reason behind why Microsoft came up with the ideology for Azure Function Proxies.

This blog was originally published in Serverless360.

What is Azure Function Proxies?

The basic ideology of Azure Function Proxies is that it allows us to define a single API surface for multiple function apps. Now any function app can define an endpoint that serves as Reverse Proxy for another API. The endpoint can be an function app or it can be anything else.

Are you looking out for an off the shelf tool to manage and monitor your Azure Functions? Try out here for free.

Reason for implementing Azure Function Proxy

For some users, it was difficult to manage large solutions with a single function app and there are a bunch of organizations using Azure Function in their micro service architecture with deployment between individual components. This case is related to each function app having its own hosting and there can be a lot different function app to keep track of it. We may also have some function app combined with other API but they could be in various regions, so what we end up doing is that we pass along a lot of that complexity down to our consuming client or consuming system.

So Azure Function Proxies come to the rescue by providing a unified URI (Uniform Resource Identifier) which client can actually consume and in the meantime, we would be abstracting all of the different function app or other API and it would also enable us to build our API at a faster rate.


In the Solution Architecture Diagram above, we have an Azure Function Proxy followed by Azure Function and Service Bus Queue on the back-end to store information. At the other end of the diagram, we have Data Publishers, for the discussion purpose, let us consider the Power Equipment generates the tag event and forwards to Azure Functions through Proxy.

Initially, we create a function app by selecting the function option from the Azure portal. Here let us consider the case of creating an HTTP trigger for C# where the function of HTTP trigger is to invoke a function with an HTTP request. Now we create two functions, one being the PostTag which represents our post if we want to create a tag. The Code for the PostTag function is,

Post Tag

Then, we create another function called GetTag with the code specified as,

Get Tag

We use GetTag to pull the message from the queue and last tag value returns to the client.

We can select the link specified below to fetch the URL of both the functions. This link will provide us with Security Token for Authorization.

To Get Function URL

At this point, we move over to Function App Settings and enable the Azure Function Proxies having the latest proxy runtime version of 0.2. Consequently, we will select the “New Proxy” option from Function App Development which would enable us to create two proxies. They are Proxy GetTag and Proxy PostTag. The available options in proxy are,

  • Proxy URL
  • Route Template
  • Backend URL

The URL specified in Proxy URL and the Route Template would be the same regarding both the GetTag and PostTag event. The Backend URL of Proxy GetTag will be related to GetTag event but for Proxy PostTag it would be related to PostTag event.


Azure Functions Proxies is a great way to mock and test your Azure Functions endpoint even before the actual back-end development begin. Also, it can be used even in the production where is a need to route one URI to another and more.

I would like to conclude that Azure Function Proxies is one of the most engaging and go to market features that the Azure Functions team has provided.

Source link