Allow for Empty Default Landing Page in Azure Function App Deployments

My company's first venture into Azure Functions as a possible solution to micro-servicing our web app was met with unexpected bandwidth charges (just under $100) billed to two Azure Function App Consumption plans (each in a different region) that had only been up for three days. Only one actually had a function in it, and this function was tested about 30 or so times on the third day.

It was at that time the bandwidth charges were spotted in the Azure portal, and the plans and related resources were deleted.

Seeing how these Azure Function App Consumption plans were deployed for just "playing around" with the service to get a feel for how a micro-service approach might be taken with Azure Functions, it was quite the shock to see such crazy amount of bandwidth charges for what amounted to two empty app deployments with a "Hello world" function on one of them.

When you consider that in a micro-service approach there would be many Function App deployments making up the overall backend of the SPA web app, and that there would be multiple regions of deployments for failovers, you can quickly see the costs mounting up to be unsustainable in just a matter of a few days.

We filed a complaint with Azure and are still waiting for a resolution or, at the very least, an explanation for these inexplicable bandwidth charges. But this has been dragging on for almost two weeks. So we decided to do an investigation of our own.

After creating a new Azure account and subscription for the investigation and deploying the same set up, with a few variations, we started to suspect that the bandwidth charges were related to using the Azure Function apps in a backend pool of Azure Front Door, which incessantly fires health probes to the backend pools to determine which backend the user should be routed to.

The Azure Front Door health probes are an http or https request to a path of your choosing. In this case the path was left at the default "/" root of the Function apps as we did not want to use a function trigger for reasons that will be obvious here shortly.

Because Azure Front Door is globally based, it has God knows how many edges around the world. Each of these edges are apparently performing the health probes to the backend pools. So depending on the interval set you choose (5 to 255 seconds), this could add up to a crazy amount of requests per second in health probes.

Since the health probes were not firing a function request, we were baffled at what was actually causing that much outbound data transfers to justify the bandwidth charges. After binging and googling the web for "unexpected Azure bandwidth charges," we came across this [article](https://stackoverflow.com/questions/55572932/azure-front-door-generates-a-large-amount-of-bandwidth), which helped us understand the possible culprit.

Apparently, there is a 147 KB landing page for Azure Function app deployments. Every time Azure Front Door probes one of the Azure Function apps from one of its many edges, there is an extra and unnecessary 147 KB payload added to the outbound data transfers tally, which quickly surpasses the 5 GB monthly free allotment given by Azure for bandwidth costs.

The only current option that the Azure Function team has provided regarding this landing page is the option to disable it. This unfortunately causes Azure Front Door health probe checks to fail. Only an http or https response of 200 is accepted as passing the health probe checks.

Using a function or a proxy to serve up an empty 200 response is not an option either, as Azure Front Door will keep the function or proxy constantly running and eventually incurring costs Azure Function execution and resource costs there as well.

Look, we get there will always be some hidden or unexpected costs when piecing together various Azure cloud services. But the feature request here would help mitigate these costs and allow for continue use with Azure Front Door for possible failovers and quick application delivery. To give some perspective, we also were also using a static SPA on a Azure Storage account that sits in a separate backend pool in Azure Front Door. The health probe checks this backend pool are not generating any bandwidth charges to speak of, and the health probes were a 100% successful.

We are asking the Azure Functions team to allow for an empty landing page or to allow for a http or https 200 ok response if the landing page is diabled. This would greatly mitigate or completely eliminate the bandwidth charges incurred when using an Azure Function app in a backend pool of Azure Front Door.