A lap around F5 NGINX on Azure

One of the announcements during Microsoft Build 2022 – among many – that caught my eye was that F5 NGINX is now natively available on Azure. NGINX has been around for some time on Azure, but as compute-based, you’re deploying a plain old virtual machine to run your service. No thanks to that – but yes, please to the new F5 NGINX capability.

Ostensibly, F5 claims the new offering is a Software as a Service. I doubt that myself, as it seems more of a Platform as a Service-type capability, but I’ll take what I can. But first, let’s get the basics out of the way before we’ll take a lap around the service.

What are NGINX and F5, and why do I need them?

Nginx – pronounced “Engine X” – is a free and open-source web server. The “F5” part of the service is a company called F5 Networks, which acquired Nginx, Inc. back in the day. And F5 has and is a big player in the firewall and network equipment and software market.

Nginx can act as an HTTP proxy and a web server. Thus it can serve content, behave as an application server, and act as a load balancer.

Nginx Plus is the commercial version, adding bells and whistles.

Therefore, the service that Microsoft now announced is based on the F5 vision of what Nginx does. And it’s now stylized as F5 NGINX.

Setting up F5 NGINX on Azure

When you search for NGINX on the Azure Marketplace, you’ll get a long list of offerings. The last one is the new one:

The others are the previous incarnation of F5 NGINX, based on compute capabilities. Provisioning is a breeze – select a region and a pricing plan. For the region, the selection is minimal: East US 2, West US, West Central US, and Australia East. I’m a bit surprised that nothing outside the US exists beyond a particular region in Australia. I opted for East US 2, it’s, ahem, closest to me from Finland.

The pricing plan only has one option – Public Preview. Next, you need to allocate which Virtual Network and subnet to deploy the instance in. You can also use an existing (public or private) IP address or provision a new one. That’s it. Provisioning takes just a few minutes to complete. It’s worth noting here that the virtual network has to be fresh – no NSGs or other fancy stuff can exist on it before deploying NGINX for it.

Once provisioned, the Azure Portal-based management interface to the shiny new F5 NGINX instance is somewhat unimpressive.

Three settings and that’s it. You can add new certificates under NGINX certificates to be then used for your traffic. Azure Monitor-based analysis and monitoring are under NGINX monitoring. And the actual configuration of the instance occurs via NGINX configuration. None of the first two work, as they require a Managed Identity, which isn’t auto-enabled for you. So head over to Identity and flip it on. But wait, it only supports user assigned managed identities and those you create in a different view outside NGINX. The blue button is truthful, but not helpful at all.

Once I’ve added a new user assigned managed identity through Azure Portal, I can refresh the page and add it to NGINX.

There we go! We could add a new certificate, which thankfully supports Azure Key Vault.

Configuring the NGINX instance on Azure

Now, to the heart of the matter – configuring our instance. The instance is alive and responding with an HTTP/200 OK through the IP address we associated during provisioning. Not immensely helpful.

I’ve never operated a real NGINX instance, so I had very few expectations. All configuration is done through configuration files. They can be either JavaScript or Nginx-formatted. The latter is the default, and you can have multiple config files – you have to remember them by heart.

The format reminds me a bit of JavaScript and JSON mashed together. You have directives, such as includeto work your way through multiple files. The editor is based on Visual Studio Code, so it’s almost a joy to use in this limited incarnation.

By default, there are no config files. I copy-pasted the one you see in the screenshot from a sample. Once you submit it, Azure Portal starts injecting it, taking about 30 seconds to complete. While waiting, you cannot leave the current view, which is frustrating and odd.

The changes are then immediately reflected on the instance. I have a habit of injecting an emoji in random places to see how different systems react to this modern communication model. NGINX didn’t like this. After changing the embedded HTML within the config file to hello there 😏 and submitting the change, NGINX kept trying to commit it endlessly. I guess it times out after 20 minutes, but I didn’t have the patience to wait. If you reload the page, all changes are lost – of course. And if you wait, all you can do is wait and hope for the best.

To have the NGINX instance do something useful beyond plain HTML, you can introduce your frontend (or backend) services with the http context keyword. You could introduce multiple load-balanced nodes from the backend, introduce SSL certificates, and manage how traffic flows between the user and your services. This approach is, of course, very close to what you would do with an Apache-based web server.

It is pretty tedious to configure your central web server/load balancer/reverse proxy like this. Therefore, you can also introduce your config files as GZIP’d packages or handily via GitHub. The latter is a bit of a surprise, as it seems pretty convenient also. You can check out the documentation on how to set that up here.

Monitoring NGINX

To monitor, you first have to send all metrics to Azure Monitor. This is a one-time switch to enable, and after this, you can use Azure Monitor, or the metrics view directly in the NGINX management blade on Azure Portal.

Metrics dimensions provided include SSL statistics, NGINX statistics, connection statistics, request and response statistics, and upstream statistics. I couldn’t get much out, as most dimensions were either empty (due to my limited usage so far), or the Azure Monitor view kept reverting to default views, as if not seemingly happy with the NGINX-based metrics being offered.

It works well after a while, but many of the metrics were initially sluggish and picky.

Pricing

How much does it cost, then? Azure Pricing Calculator doesn’t reflect this, and I’m unsure why. Grafana is there, and it isn’t a Microsoft product. But NGINX is not there, even if it’s a first-class citizen in Azure now. It could also be that this is a preview that the APC hasn’t been refreshed yet.

Azure Marketplace lists the cost as follows:

Using these values, we can add that per month (per 730 hours), a single instance will cost you 35 € for the capacity unit. Data processed on top of this will cost you 0.0096 €/GB.

I feel this is very affordable, at least in smaller deployments. You cannot select the number of capacity units while provisioning the service. I peek at the deployment template, which sku is empty when deploying the public preview. I assume this means a single capacity unit, and future SKUs allow for scaling.

It’s an exciting service, and I feel those well-versed with NGINX see a huge benefit with this. For everyone else, I think it’s just easier and better to stick with Azure Firewall, Web Application Firewall, and Azure FrontDoor.