Frequently Asked Questions

Common questions about NGINX as a Service for Azure.

How often does NGINX as a Service for Azure get billed?

Will my deployment autodetect a new version of my TLS certificate and apply it?

  • Not currently. This enhancement is coming in a future release.

Can my deployment listen on ports other than TCP 80 and 443?

  • Not currently. This enhancement is coming soon.

Can I reference my upstream servers by internal DNS hostname?

  • Yes. If your DNS nameservers are configured in the same VNet used by your deployment, then you can use those DNS nameservers to resolve the hostname of the upstream servers referenced in your NGINX configuration.

How can I review the NGINX access and error logs?

Why do the metrics show more connections and requests than I was expecting?

  • The agent gathers stats via an internal HTTP request incrementing the request count. The Azure service health probe checks for status via a TCP connection on port 80/443 incrementing the connection count. This contributes to minimal traffic and should not affect any of these metrics greatly.

What are the specific permissions NGINXaaS for Azure needs?

  • The specific permissions required to deploy NGINXaaS are:

    • microsoft.network/publicIPAddresses/join/action

    • nginx.nginxplus/nginxDeployments/Write

    • microsoft.network/virtualNetworks/subnets/join/action

    • nginx.nginxplus/nginxDeployments/configurations/Write

    • nginx.nginxplus/nginxDeployments/certificates/Write

  • Additionally, if you are creating the Virtual Network or IP address resources that NGINXaaS for Azure will be using, then you probably also want those permissions as well.

  • Note that assigning the managed identity permissions normally requires an “Owner” role.

Why are min and max aggregation types reporting zero in Azure Monitor?

  • NGINXaaS for Azure does not currently report on the min and max of the NGINX metrics. In this case, the service will simply report a value of zero when either of these aggregation types is selected in Azure Monitor.

Can I use an existing subnet to create my deployment?

  • You can use an existing subnet to create a deployment. Please make sure that the subnet is delegated to NGINX.NGINXPLUS/nginxDeployments before creating a deployment in it. To delegate a subnet to an Azure service, see Delegate a subnet to an Azure service.

How do I resolve Terraform expected sku to be one of errors?

Upgrade your version of azurerm. The list of valid SKUs changes occasionally, and azurerm has validation logic.

Example error that can be fixed with an azurerm upgrade:

│ Error: expected sku to be one of [publicpreview_Monthly_gmz7xq9ge3py], got standard_Monthly
│
│   with azurerm_nginx_deployment.demo,
│   on main.tf line 73, in resource "azurerm_nginx_deployment" "demo":
│   73:   sku                      = "standard_Monthly"
│

How do I resolve Terraform PaymentRequired errors?

‘PaymentRequired’ errors can happen when trying to create a deployment using an old SKU. Occasionally NGINXaaS changes SKUs, and the old ones cease to be available. To fix this, upgrade to the latest version of azurerm, and use one of the current SKUs.

Example error fixed with a SKU change:

│ Error: creating Nginx Deployment (Subscription: "........-....-....-....-............"
│ Resource Group Name: "example"
│ Deployment Name: "example"): performing DeploymentsCreateOrUpdate: nginxdeployment.NginxDeploymentClient#DeploymentsCreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="PaymentRequired" Message="SaaS Purchase Payment Check Failed as validationResponse was {\"isEligible\":false,\"errorMessage\":\"Plan 'publicpreview' is defined as stop sell in offer 'f5-nginx-for-azure'. Availability not found with action Purchase for plan 'publicpreview' and offer 'f5-nginx-for-azure'.\"}"
│
│   with azurerm_nginx_deployment.demo,
│   on main.tf line N, in resource "azurerm_nginx_deployment" "demo":
│   N: resource "azurerm_nginx_deployment" "demo" {
│
│ creating Nginx Deployment (Subscription: "........-....-....-....-............"
│ Resource Group Name: "example"
│ Deployment Name: "example"): performing DeploymentsCreateOrUpdate: nginxdeployment.NginxDeploymentClient#DeploymentsCreateOrUpdate: Failure sending request: StatusCode=0 --
│ Original Error: Code="PaymentRequired" Message="SaaS Purchase Payment Check Failed as validationResponse was {\"isEligible\":false,\"errorMessage\":\"Plan 'publicpreview' is
│ defined as stop sell in offer 'f5-nginx-for-azure'. Availability not found with action Purchase for plan 'publicpreview' and offer 'f5-nginx-for-azure'.\"}"

How do I resolve other Terraform errors?

Upgrade your version of azurerm. See Lock and Upgrade Provider Versions for more details on how to upgrade terraform providers like azurerm.

azurerm releases frequently, and may contain a fix for your problem. See service/nginx issues for a complete list.

Why are there two resource groups associated with my deployment?

Each NGINXaaS deployment has two resource groups associated with it:

  • A resource group specified by the user as part of creating the deployment. This resource group contains the NGINXaaS deployment and is fully controlled by the end user.
  • A secondary managed resource group created by the NGINXaaS service which contains networking resources related to the NGINXaaS deployment. The service manages the lifecycle of resources created within the managed resource group. The default naming convention for the managed resource group is NGX_MyResourceGroup_MyDeployment_Location. Users can name the managed resource group when creating a deployment with the Azure CLI, Terraform, and other client SDKs.

Things to keep in mind when working with the managed resource group:

  • You cannot specify the managed resource group when creating the deployment with the Azure Portal.
  • You cannot use an existing resource group as the managed resource group.
  • The resource group should belong to the same subscription as the NGINXaaS deployment.
  • You should not modify any exisitng properties on the resource group such as tags or related resource within it. Doing so might cause issues with deployment operations such as upgrades, scaling, and deletions. For example, locking the resource group or resources within it might cause issues with the NGINXaaS deployment.