diff --git a/content/includes/nginxaas-azure/ssl-tls-prerequisites.md b/content/includes/nginxaas-azure/ssl-tls-prerequisites.md index c37a4ac13..1d95d498d 100644 --- a/content/includes/nginxaas-azure/ssl-tls-prerequisites.md +++ b/content/includes/nginxaas-azure/ssl-tls-prerequisites.md @@ -2,9 +2,11 @@ docs: "DOCS-000" --- +NGINXaaS natively integrates with [Azure Key Vault (AKV)](https://azure.microsoft.com/en-us/products/key-vault), so you can bring your own certificates and manage them in a centralized location. You will need: + - AKV to store certificates that you want to add to the deployment. -- A user or system assigned identity associated with your NGINXaaS deployment. Ensure that your managed identity (MI) has read access to secrets stored in AKV: +- A user or system assigned identity associated with your NGINXaaS deployment. Ensure that your Managed Identity (MI) has read access to secrets stored in AKV: - If using Azure RBAC for AKV, ensure that your MI has [Key Vault Secrets User](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#key-vault-secrets-user) or higher permissions. diff --git a/content/nginxaas-azure/billing/overview.md b/content/nginxaas-azure/billing/overview.md index 4eaa5d4b4..c0f5df504 100644 --- a/content/nginxaas-azure/billing/overview.md +++ b/content/nginxaas-azure/billing/overview.md @@ -8,8 +8,12 @@ type: - concept --- +NGINXaaS for Azure is deployed into your Azure subscription. Your NGINXaaS deployment resource is visible within your subscription, while the underlying infrastructure is managed by F5 and is abstracted away from you. + ## Pricing plans +NGINXaaS for Azure is billed monthly based on hourly consumption. + F5 NGINX as a Service for Azure (NGINXaaS) provides two pricing plans. ### Standard V2 plan @@ -69,3 +73,7 @@ The standard Azure [networking](https://azure.microsoft.com/en-us/pricing/detail {{< note >}}The management traffic for NGINX instances is billed as a `Virtual Network Peering - Intra-Region Egress` charge. This charge includes the data for shipping metrics and logs. The cost for shipping metrics data is approximately $0.03/month. If you enable NGINX logging the cost increases by roughly $0.005 per GB of logs NGINX generates. To estimate this, multiply the number of requests by the average log line size of the access_log format you have configured. {{< /note >}} + +## Review billing data + +NGINXaaS billing data is reported per deployment and can be viewed in the Azure Portal under "Cost Management + Billing".​ \ No newline at end of file diff --git a/content/nginxaas-azure/changelog-archive/changelog-2022.md b/content/nginxaas-azure/changelog-archive/changelog-2022.md index 8556e99f6..a0e8d10fa 100644 --- a/content/nginxaas-azure/changelog-archive/changelog-2022.md +++ b/content/nginxaas-azure/changelog-archive/changelog-2022.md @@ -101,6 +101,6 @@ To see a list of currently active issues, visit the [Known issues]({{< ref "/ngi ### Welcome to the NGINXaaS Public Preview -NGINXaaS for Azure is now available for public preview. Give it a try! If you find any issues please let us know by [raising a support ticket]({{< ref "/nginxaas-azure/troubleshooting/troubleshooting.md" >}}). +NGINXaaS for Azure is now available for public preview. Give it a try! If you find any issues please let us know by [raising a support ticket]({{< ref "/nginxaas-azure/get-help.md" >}}). Visit the [Known issues]({{< ref "/nginxaas-azure/known-issues.md" >}}) section to learn about the issues present in this release. diff --git a/content/nginxaas-azure/changelog-archive/changelog-2023.md b/content/nginxaas-azure/changelog-archive/changelog-2023.md index b1f778f43..6f3eddf78 100644 --- a/content/nginxaas-azure/changelog-archive/changelog-2023.md +++ b/content/nginxaas-azure/changelog-archive/changelog-2023.md @@ -70,7 +70,7 @@ To see a list of currently active issues, visit the [Known issues]({{< ref "/ngi To get started using HTTP/3 and NGINXaaS: - Update the [network security group](https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-filter-network-traffic#create-security-rules) associated with the NGINXaaS deployment’s subnet to allow inbound traffic for HTTP/3 UDP ports in the NGINX configuration. - See our [FAQ]({{< ref "/nginxaas-azure/faq" >}}), for limits on how many unique ports may be specified in a configuration and a list of restricted ports. + See the [NGINXaaS limitations]({{< ref "/nginxaas-azure/overview/overview.md#limitations" >}}), for limits on how many unique ports may be specified in a configuration and a list of restricted ports. - Additionally, add a [Managed Identity]({{< ref "/nginxaas-azure/getting-started/managed-identity-portal.md" >}}) to your deployment and create [SSL/TLS Certificates]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/" >}}). For more information on using NGINX with HTTP/3, see the [HTTP/3 module](https://nginx.org/en/docs/http/ngx_http_v3_module.html). @@ -265,7 +265,7 @@ To see a list of currently active issues, visit the [Known issues]({{< ref "/ngi Update the [network security group's inbound security rules](https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-filter-network-traffic#create-security-rules) associated with the NGINXaaS deployment's subnet to allow inbound traffic for all listen ports in the NGINX configuration. - See our [FAQ]({{< ref "/nginxaas-azure/faq" >}}), for limits on how many unique ports may be specified in a configuration and a list of restricted ports. + See our [NGINX configuration overview]({{< ref "/nginxaas-azure/getting-started/nginx-configuration/overview.md#nginx-listen-port-restrictions" >}}) document for limits on how many unique ports may be specified in a configuration and a list of restricted ports. ## March 16, 2023 diff --git a/content/nginxaas-azure/changelog-archive/changelog-2024.md b/content/nginxaas-azure/changelog-archive/changelog-2024.md index 0abcf3455..6c05a33c1 100644 --- a/content/nginxaas-azure/changelog-archive/changelog-2024.md +++ b/content/nginxaas-azure/changelog-archive/changelog-2024.md @@ -114,7 +114,7 @@ An NGINXaaS deployment can now be gracefully updated to a new subnet with zero d Please review the [NGINX Plus Release 32 (R32)](https://docs.nginx.com/nginx/releases/#nginxplusrelease-32-r32) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R32 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one. - If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/troubleshooting/troubleshooting.md" >}}). + If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/get-help.md" >}}). ## July 30, 2024 @@ -182,7 +182,7 @@ An NGINXaaS deployment can now be gracefully updated to a new subnet with zero d Please review the [NGINX Plus Release 31 (R31)](https://docs.nginx.com/nginx/releases/#nginxplusrelease-31-r31) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R31 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one. - If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/troubleshooting/troubleshooting.md" >}}). + If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/get-help.md" >}}). ## May 20, 2024 diff --git a/content/nginxaas-azure/changelog.md b/content/nginxaas-azure/changelog.md index de3ebc390..131c0b2b3 100644 --- a/content/nginxaas-azure/changelog.md +++ b/content/nginxaas-azure/changelog.md @@ -43,9 +43,9 @@ NGINX App Protect WAF is now generally available and is no longer a preview feat NGINXaaS for Azure deployments using the **Stable** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}) will be updated to [NGINX Plus Release 33 (R33)]({{< ref "/nginx/releases.md#nginxplusrelease-33-r33" >}}) during the week of May 05-09, 2025. This will also include updates to the following NGINX Plus modules: - nginx-plus-module-njs - Please review the [NGINX Plus Release 33 (R33)]({{< ref "/nginx/releases.md#nginxplusrelease-33-r33" >}}) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R33 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one. For entitlement and visibility policy, check [the FAQs]({{< ref "/nginxaas-azure/faq.md" >}}) to address any additional questions you might have. + Please review the [NGINX Plus Release 33 (R33)]({{< ref "/nginx/releases.md#nginxplusrelease-33-r33" >}}) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R33 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one. - If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/troubleshooting/troubleshooting.md" >}}). + If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/get-help.md" >}}). ## March 31, 2025 @@ -70,7 +70,7 @@ See the [Supported Regions]({{< ref "/nginxaas-azure/overview/overview.md#suppor - {{% icon-info %}} **Retirement of Standard Plan** - The `Standard` plan for NGINXaaS for Azure has been retired, and you can no longer use it to create new deployments. If you have a deployment running on the `Standard` plan, consider [migrating]({{< ref "/nginxaas-azure/troubleshooting/migrate-from-standard.md">}}) it to the [`Standard V2 plan`]({{< ref "/nginxaas-azure/billing/overview.md#standard-v2-plan" >}}) to access new features such as NGINX App Protect WAF and additional listen ports. Plan migration does not incur downtime. + The `Standard` plan for NGINXaaS for Azure has been retired, and you can no longer use it to create new deployments. If you have a deployment running on the `Standard` plan, consider [migrating]({{< ref "/nginxaas-azure/getting-started/migrate-from-standard.md">}}) it to the [`Standard V2 plan`]({{< ref "/nginxaas-azure/billing/overview.md#standard-v2-plan" >}}) to access new features such as NGINX App Protect WAF and additional listen ports. Plan migration does not incur downtime. ## February 10, 2025 @@ -82,4 +82,4 @@ See the [Supported Regions]({{< ref "/nginxaas-azure/overview/overview.md#suppor - {{< icon-feature >}} **In-place SKU Migration from Standard to Standard V2** - You can now migrate NGINXaaS for Azure from the Standard plan to the Standard V2 plan without redeploying. We recommend upgrading to the Standard V2 plan to access features like NGINX App Protect WAF and more listen ports. The Standard plan will be retired soon. For migration details, see [migrate from standard]({{< ref "/nginxaas-azure/troubleshooting/migrate-from-standard.md">}}). + You can now migrate NGINXaaS for Azure from the Standard plan to the Standard V2 plan without redeploying. We recommend upgrading to the Standard V2 plan to access features like NGINX App Protect WAF and more listen ports. The Standard plan will be retired soon. For migration details, see [migrate from standard]({{< ref "/nginxaas-azure/getting-started/migrate-from-standard.md">}}). diff --git a/content/nginxaas-azure/faq.md b/content/nginxaas-azure/faq.md deleted file mode 100644 index 21919a539..000000000 --- a/content/nginxaas-azure/faq.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: Frequently Asked Questions -weight: 800 -toc: true -docs: DOCS-881 -url: /nginxaas/azure/faq/ -type: -- concept ---- - -Common questions about F5 NGINX as a Service for Azure (NGINXaaS). - -### Do I need to manually supply a JWT license for my instances? -- No, the license management process is handled automatically by NGINXaaS. - -### Where is the usage data reported? -- The usage data is reported to NGINXaaS. - -### Is NGINXaaS available in my subscription or in F5 subscription? -- Your NGINXaaS deployment resource is visible to you under your subscription. The underlying compute resources of your deployment, which are managed by NGINX on your behalf, are not visible in your subscription. - -### Is NGINXaaS active-active? What is the architecture of NGINXaaS? -- NGINXaaS is deployed as an active-active pattern for high availability. To learn more, see the [user guide]({{< ref "/nginxaas-azure/overview/overview.md#architecture" >}}). - -### In which Azure regions is NGINXaaS currently supported? -- We are constantly adding support for new regions. You can find the updated list of supported regions in the [NGINXaaS documentation]({{< ref "/nginxaas-azure/overview/overview.md" >}}). - -### My servers are located in different geographies, can NGINXaaS load balance for these upstream servers? -- Yes, NGINXaaS can load balance even if upstream servers are located in different geography as long as no networking limitations are mentioned in the [Known Issues]({{< ref "known-issues.md" >}}). - -### How do I analyze traffic statistics for NGINXaaS? -- NGINXaaS is integrated with [Azure monitoring](https://learn.microsoft.com/en-us/azure/azure-monitor/overview). NGINXaaS publishes [traffic statistics]({{< ref "/nginxaas-azure/monitoring/metrics-catalog.md" >}}) in Azure monitoring. Customers can analyze the traffic statistics by following the steps mentioned in the [NGINXaaS Monitoring]({{< ref "/nginxaas-azure/monitoring/enable-monitoring.md" >}}) documentation. - -### When should I scale my deployment? -- Consider requesting additional NCUs if the number of consumed NCUs is over 70% of the number of provisioned NCUs. Consider reducing the number of requested NCUs when the number of consumed NCUs is under 60% of the number of provisioned NCUs. For more information on observing the consumed and provisioned NCUs in your deployment, see the [Scaling documentation]({{< ref "/nginxaas-azure/quickstart/scaling.md#metrics" >}}). - -- Alternatively, [enable autoscaling]({{< ref "/nginxaas-azure/quickstart/scaling.md#autoscaling" >}}) to let the system automatically scale your deployment for you. - -### I am an NGINX Plus customer; how can I switch to NGINXaaS? -- In NGINX Plus, customers SSH into the NGINX Plus system, store their certificates in some kind of storage and configure the network and subnet to connect to NGINX Plus. - -- For NGINXaaS, customers store their certificates in the Azure key vault and configure NGINXaaS in the same VNet or peer to the VNet in which NGINXaaS is deployed. - -### How does NGINXaaS react to a workload/traffic spike? -- You can monitor the NCUs consumed by looking at the metrics tab of NGINXaaS. To learn about the NCUs consumed, choose NGINXaaS statistics and select "NCU consumed." If the NCU consumed is close to the requested NCUs, we encourage you to scale your system and increase the NCU units. You can manually scale from your base NCUs (For example, 10) to up to 500 NCUs by selecting the NGINXaaS scaling tab. - -- Currently, we support scaling in 10 NCU intervals (10, 20, 30, and so on). - -- Alternatively, you can enable autoscaling, and NGINXaaS will automatically scale your deployment based on the consumption of NCUs. - -- See the [Scaling Guidance]({{< ref "/nginxaas-azure/quickstart/scaling.md" >}}) documentation for more information. - -### What types and formats of certificates are supported in NGINXaaS? -- NGINXaaS supports self-signed certificates, Domain Validated (DV) certificates, Organization Validated (OV) certificates, and Extended Validation (EV) certificates. - -- Currently, NGINXaaS supports PEM and PKCS12 format certificates. - -- See the [SSL/TLS Certificates documentation]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/ssl-tls-certificates-portal.md" >}}) to learn how to change certificates. - -### Does NGINXaaS support layer 4 load balancing? -- Yes, NGINXaaS currently supports layer 4 TCP and HTTP layer 7 load balancing. - -### Does NGINXaaS support IP v6? -- No, NGINXaaS does not support IPv6 yet. - -### What protocols do NGINXaaS support? - -- At this time, we support the following protocols: - - - HTTPS - - HTTP - - HTTP/2 - - HTTP/3 - - TCP - - QUIC - - IMAP - - POP3 - - SMTP - -### Does NGINXaaS support multiple public IPs, a mix of public and private IPs? - -- NGINXaaS supports one public or private IP per deployment. NGINXaaS doesn't support a mix of public and private IPs at this time. - -### Can I change the IP address used for an NGINXaaS deployment to be public or private? - -- You cannot change the IP address associated with an NGINXaaS deployment from public to private, or from private to public. - -### How large should I make the subnet for NGINXaaS? - -- The minimum subnet size is `/27` and is sufficient for a single NGINXaaS deployment even at large scales. Multiple NGINXaaS deployments can be placed in a single delegated subnet, along with other resources. When doing so, a larger subnet, e.g. a `/24`, is recommended. - -### Can I deploy more than one NGINXaaS to a single subnet? -- Yes, however, every deployment in the subnet will share the address space (range of IP addresses that resources can use within the VNet), so ensure the subnet is adequately sized to scale the deployments. - -### How long does it take to deploy NGINXaaS? -- Typically you can deploy NGINXaaS in under 5 minutes. - -### Any downtime in the periodic updates? -- There's no downtime during updates to NGINXaaS. - -### Does changing the capacity of NGINXaaS result in any downtime? -- No, there's no downtime while an NGINXaaS deployment changes capacity. - -### How is my application safe at the time of disaster? Any method for disaster recovery? -- In any Azure region with more than one availability zone, NGINXaaS provides cross-zone replication for disaster recovery. See [Architecture]({{< ref "/nginxaas-azure/overview/overview.md#architecture" >}}) for more details. - -### Can I configure the TLS policy to control TLS protocol versions? -- Yes. You can overwrite the NGINX default protocol to configure the desired TLS/SSL policy. Read more about the procedure in the [Module ngx_http_ssl_module](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols) documentation. - -### How many TLS/SSL certificates does NGINXaaS support? -- NGINXaaS supports up to 100 TLS/SSL certificates. - -### Does NGINXaaS natively integrate with Azure Key Vault? -- Yes, NGINXaaS natively integrates with Azure Key Vault, so you can bring your own certificates and manage them in a centralized location. You can learn more about adding certificates in Azure Key Vault in the [SSL/TLS Certificates documentation]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/ssl-tls-certificates-portal.md" >}}). - -### Can I deploy any other resources in the NGINXaaS subnet? -- Yes, the subnet can contain other resources and is not dedicated to the NGINXaaS for Azure resources; ensure the subnet size is adequate to scale the NGINXaaS deployment. - -### Are NSG (Network Security Group) supported on the NGINXaaS? -- Yes, an NSG is required in the subnet where NGINXaaS will be deployed to ensure that the deployment is secured and inbound connections are allowed to the ports the NGINX service listens to. - -### Can I restrict access to NGINXaaS based on various criteria, such as IP addresses, domain names, and HTTP headers? -- Yes, you can restrict access to NGINXaaS by defining restriction rules at the Network Security Group level or using NGINX's access control list. To learn more, see the [NGINX module ngx_http_access_module](http://nginx.org/en/docs/http/ngx_http_access_module.html) documentation. - -### What are the supported networking services of NGINXaaS? -- NGINX currently supports VNet, and VPN gateway if they do not have limitations. Known limitations can be found in the [Known Issues]({{< ref "known-issues.md" >}}). - -### Does NGINXaaS support end-to-end encryption from client to the upstream server? -- Yes, NGINXaaS supports end-to-end encryption from client to upstream server. - -### What types of logs does NGINXaaS provide? -- NGINXaaS supports the following [two types of logs]({{< ref "/nginxaas-azure/monitoring/enable-logging/">}}). - -- Access Log: To troubleshoot server issues, analyze web traffic patterns and monitor server performance. For more details, please see the [Module ngx_http_log_module](https://nginx.org/en/docs/http/ngx_http_log_module.html?&_ga=2.80762515.545098740.1677716889-256521444.1670450998#access_log) documentation. - -- Error Log: To capture, troubleshoot and identify issues that may occur during the server's operations, such as 400 bad requests, 401 unauthorized, 500 internal server errors, etc. For more details, please see the [Core functionality](https://nginx.org/en/docs/ngx_core_module.html?&_ga=2.8347062.545098740.1677716889-256521444.1670450998#error_log) documentation. - -### What is the retention policy for the above logs? How long are the logs stored? Where are they stored? -- NGINXaaS logs are stored in customer’s storage. Customers can custom define the retention policy. Customers can configure the storage by following the steps outlined in the [NGINXaaS Logging]({{< ref "/nginxaas-azure/monitoring/enable-logging/">}}) documentation. - -### Can I set up an alert with NGINXaaS? -- You can set up an alert with NGINXaaS by following the steps outlined in the [Configure Alerts]({{< ref "/nginxaas-azure/monitoring/configure-alerts.md">}}) documentation. - -### Is request tracing supported in NGINXaaS? -- Yes, see the [Application Performance Management with NGINX Variables](https://www.nginx.com/blog/application-tracing-nginx-plus/) documentation to learn more about tracing. - -### Can I select my desired instance type for NGINXaaS deployment? -- No; NGINXaaS will deploy the right resources to ensure you get the right price-to-performance ratio. - -### Can I migrate from on-prem NGINX+ to NGINXaaS on Azure? -- Yes, you can bring your own configurations or create a new configuration in the cloud. See the [NGINXaaS Deployment]({{< ref "/nginxaas-azure/getting-started/create-deployment/">}}) documentation for more details. - -### Can I associate multiple certificates for the same domain? -- Yes, the "ssl_certificate" directive can be specified multiple times to load certificates of different types. To learn more, see the [Module ngx_http_ssl_module](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate) documentation. - -### What types of redirects does the NGINXaaS support? -- In addition to HTTP to HTTPS, HTTPS to HTTP, and HTTP to HTTP, NGINXaaS provides the ability to create new rules for redirecting. See [How to Create NGINX Rewrite Rules | NGINX](https://www.nginx.com/blog/creating-nginx-rewrite-rules/) for more details. - -### What content types does NGINXaaS support for the message body for upstream/NGINXaaS error status code responses? -- Customers can use any type of response message, including the following: - - - text/plain - - text/css - - text/html - - application/javascript - - application/json - -### Where do I find the NGINXaaS IP (Internet Protocol) address? -- Once you successfully deploy NGINXaaS, you can double-click on NGINXaaS in the Azure portal; you can see both public and private IP addresses, as shown in the following screenshot: - -{{< img src="nginxaas-azure/faq-ip-location-one.png" alt="IP location one" >}} - -{{< img src="nginxaas-azure/faq-ip-location-two.png" alt="IP location two" >}} - -### Does my deployment IP change over time? -- The NGINXaaS deployment IP doesn't change over time. - -### Does NGINXaaS support autoscaling? -- Yes; NGINXaaS supports autoscaling as well as manual scaling. Refer to the [Scaling Guidance]({{< ref "/nginxaas-azure/quickstart/scaling.md#autoscaling" >}}) for more information. - -### How can I manually start/stop NGINXaaS? -- Currently, we can't manually start/stop NGINXaaS. You have the option to delete the deployment and re-deploy at a future date. - -### Can I change the virtual network or subnet for an existing NGINXaaS? -- If the existing NGINXaaS deployment is using a public IP address, you can change the backend virtual network or subnet. 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](https://learn.microsoft.com/en-us/azure/virtual-network/manage-subnet-delegation?source=recommendations#delegate-a-subnet-to-an-azure-service). - -- If the existing NGINXaaS deployment is using a private IP address, you can only change the backend subnet. You cannot change the backend virtual network because the frontend and backend subnets must be in the same virtual network. - -### How do I configure HTTPS listeners for .com and .net sites? -- NGINXaaS is a Layer 7 HTTP protocol. To configure .com and .net servers, refer to the server name in the server block within the HTTP context. To learn more, and see examples, follow the instructions in the [NGINX Configuration]({{< ref "/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md#nginx-configuration-validation" >}}) documentation. - -### If I remove/delete an NGINXaaS deployment, what will happen to the eNICs that were associated with it? -- When you remove or delete an NGINXaaS deployment, the associated eNICs will automatically be deleted. - -### What are the specific permissions that 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. - -### Can I reference my upstream servers by internal DNS hostname? - -- Yes. If your DNS nameservers are configured in the same VNet as your deployment, then you can use those DNS nameservers to resolve the hostname of the upstream servers referenced in your NGINX configuration. - -### Will updates to my virtual network's DNS settings automatically apply to my NGINXaaS deployment? - -No, changes to a virtual network's DNS settings will not be applied automatically to your NGINXaaS deployment. To ensure DNS settings are applied, you must add any custom DNS servers to the VNET's DNS settings before creating an NGINXaaS deployment. As a workaround for existing deployments, we recommend using the [`resolver` directive](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) to explicitly specify your name server(s) and the [`resolve` parameter](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#resolve) to automatically re-resolve the domain name of the server without restarting NGINX. - -For example, - -```nginx -resolver 10.0.0.2 valid=10s; -upstream backends { - zone backends 64k; - server backends.example.com:8080 resolve; -} - -server { - location / { - proxy_pass http://backends; - } -} -``` - -### Does changing the `worker_connections` in the NGINX config have any effect? -- No. While changing the value of the directive in the config is allowed, the change is not applied to the underlying NGINX resource of your deployment. - -### What ports can my deployment listen on? - -- Due to port restrictions on Azure Load Balancer health probes, ports `19`, `21`, `70`, and `119` are not allowed. The NGINXaaS deployment can listen on all other ports. We limit the maximum listen ports in the NGINX configuration to 5 on the Basic and current Standard (v1) plan. Configurations that specify over 5 unique ports are rejected. With the Standard V2 plan, we allow users to listen on more than 5 ports. The first five ports under this plan come at no extra cost and there are charges for each additional port utilized. - -### How often does my deployment get billed? - -- NGINXaaS is [billed monthly]({{< ref "/nginxaas-azure/billing/overview.md" >}}) based on hourly consumption. - -### Why do the metrics show more connections and requests than I was expecting? - -- The NGINX agent periodically gathers connection and request statistics using an internal HTTP request. An Azure service health probe checks for status using a TCP connection for each listen port in the NGINX configuration, incrementing the connection count for each port. This contributes to minimal traffic and should not affect these metrics significantly. - -### 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](https://learn.microsoft.com/en-us/azure/virtual-network/manage-subnet-delegation?source=recommendations#delegate-a-subnet-to-an-azure-service). - -### Will my deployment detect a new version of my certificate and apply it? - -- NGINXaaS supports certificate rotation. See the [Certificate Rotation documentation]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md#certificate-rotation" >}}) to learn more. - -### Why are some of my deployment's metrics intermittently missing in Azure monitor? - -- This may indicate that the deployment's underlying compute resources are being exhausted. Monitor the `system.cpu` metric to see the deployment's CPU utilization. If it's nearing 100%, consider increasing the deployment's NCU capacity. See the [Scaling Guidance]({{< ref "/nginxaas-azure/quickstart/scaling.md" >}}) documentation for more information. diff --git a/content/nginxaas-azure/troubleshooting/troubleshooting.md b/content/nginxaas-azure/get-help.md similarity index 97% rename from content/nginxaas-azure/troubleshooting/troubleshooting.md rename to content/nginxaas-azure/get-help.md index 2df209ff5..ff1ffc96b 100644 --- a/content/nginxaas-azure/troubleshooting/troubleshooting.md +++ b/content/nginxaas-azure/get-help.md @@ -1,9 +1,9 @@ --- title: Get help -weight: 100 +weight: 750 toc: true docs: DOCS-882 -url: /nginxaas/azure/troubleshooting/troubleshooting/ +url: /nginxaas/azure/get-help/ type: - how-to --- diff --git a/content/nginxaas-azure/getting-started/create-deployment/deploy-azure-portal.md b/content/nginxaas-azure/getting-started/create-deployment/deploy-azure-portal.md index dbbaec46e..3d58d49fb 100644 --- a/content/nginxaas-azure/getting-started/create-deployment/deploy-azure-portal.md +++ b/content/nginxaas-azure/getting-started/create-deployment/deploy-azure-portal.md @@ -20,6 +20,7 @@ You can start the NGINXaaS deployment process by visiting the [Create NGINXaaS]( 1. Use the search field to find "NGINXaaS" in the Azure Portal. In the Services results, select **NGINXaaS**. 1. Select **+ Create** on the **NGINXaaS** page to start the deployment process. + ## Create a deployment ### Basics tab @@ -46,17 +47,44 @@ You can start the NGINXaaS deployment process by visiting the [Create NGINXaaS]( 1. On the Create NGINXaaS Deployment **Networking** page, provide the following information: - {{}} - | Field | Description | - |---------------------------- | ---------------------------- | - | Virtual Network | A virtual network is required for communication between the resources you create.
You can create a new virtual network or use an existing one (for an existing one see note below).
Additionally, you can peer a new virtual network with existing ones (in any region) to create network access from NGINXaaS for Azure to your upstream servers. To peer the virtual network with another see [Create, change, or delete a virtual network peering](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering).| - | Subnet | If you select an existing virtual network, you can select the existing subnet to be used. Before creating a deployment, the existing subnet needs to be delegated to `NGINX.NGINXPLUS/nginxDeployments`. To delegate a subnet to an Azure service, see [Delegate a subnet to an Azure service](https://learn.microsoft.com/en-us/azure/virtual-network/manage-subnet-delegation?source=recommendations#delegate-a-subnet-to-an-azure-service).

Otherwise, if you have chosen to create a new virtual network, a new subnet will be selected by default.

The minimum subnet size is `/27` and is sufficient for a single NGINXaaS deployment even at large scales. Multiple NGINXaaS deployments can be placed in a single delegated subnet, along with other resources. When doing so a larger subnet, e.g. a `/24`, is recommended. | - | Allow NGINX access to Virtual Network | Confirm that you allow:
- Registration of the NGINX provider to your Azure subscription.
- Delegation of the subnet to the NGINX provider.| - | IP address | Set the IP address (public or private) that the service listens to for requests:

If you select a public IP address:
- Create a new public IP or use an existing one (for an existing one see the note below).
- Set the resource name for your public IP address.
Newly created public IPs are [zone-redundant in supported regions](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-addresses#availability-zone).

If you select a private IP address:
- Provide a static IP address from the same subnet range set previously. | - | Inbound port rules | Select `None` to disallow inbound access on any port, or choose to allow traffic from one of these common http(s) ports.

**Note:** This option is only available when specifying a new virtual network as part of the create workflow. If you select an existing virtual network which is associated with a subnet and Network Security Group (NSG), you will need to edit the Inbound security rules to add access for the specific ports you want to allow (for example, ports 80 and 443).| - | Apply default NGINX configuration | Confirm that you want your NGINXaaS deployment to be bootstrapped with a default NGINX configuration and a browsable splash page. | + {{}} + | Field | Description | + |---------------------------- | ---------------------------- | + | Virtual Network | A virtual network is required for communication between the resources you create.
You can create a new virtual network or use an existing one (for an existing one see note below).
Additionally, you can peer a new virtual network with existing ones (in any region) to create network access from NGINXaaS for Azure to your upstream servers. To peer the virtual network with another see [Create, change, or delete a virtual network peering](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering).| + | Subnet | If you select an existing virtual network, you can select the existing subnet to be used. Before creating a deployment, the existing subnet needs to be delegated to `NGINX.NGINXPLUS/nginxDeployments`. To delegate a subnet to an Azure service, see [Delegate a subnet to an Azure service](https://learn.microsoft.com/en-us/azure/virtual-network/manage-subnet-delegation?source=recommendations#delegate-a-subnet-to-an-azure-service).

Otherwise, if you have chosen to create a new virtual network, a new subnet will be selected by default.

The minimum subnet size is `/27` and is sufficient for a single NGINXaaS deployment even at large scales. Multiple NGINXaaS deployments can be placed in a single delegated subnet, along with other resources. When doing so a larger subnet, e.g. a `/24`, is recommended. | + | Allow NGINX access to Virtual Network | Confirm that you allow:
- Registration of the NGINX provider to your Azure subscription.
- Delegation of the subnet to the NGINX provider.| + | IP address | Set the IP address (public or private) that the service listens to for requests:

If you select a public IP address:
- Create a new public IP or use an existing one (for an existing one see the note below).
- Set the resource name for your public IP address.
Newly created public IPs are [zone-redundant in supported regions](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-addresses#availability-zone).

If you select a private IP address:
- Provide a static IP address from the same subnet range set previously. | + | Inbound port rules | Select `None` to disallow inbound access on any port, or choose to allow traffic from one of these common http(s) ports.

**Note:** This option is only available when specifying a new virtual network as part of the create workflow. If you select an existing virtual network which is associated with a subnet and Network Security Group (NSG), you will need to edit the Inbound security rules to add access for the specific ports you want to allow (for example, ports 80 and 443).| + | Apply default NGINX configuration | Confirm that you want your NGINXaaS deployment to be bootstrapped with a default NGINX configuration and a browsable splash page. | {{}} + #### Notes on subnets: + + - The minimum subnet size for NGINXaaS is `/27` and is enough for a single NGINXaaS deployment even at large scales. + - You can use an existing subnet; make sure that the subnet is delegated to `NGINX.NGINXPLUS/nginxDeployments` before creating a deployment in it. The subnet can contain other resources. + - You can deploy more than one NGINXaaS in the same subnet. Every deployment in the subnet will share the subnet IP address space. A larger subnet, for example, a `/24` is recommended. + - Changes to a virtual network's DNS settings will not be applied automatically to your NGINXaaS deployment. To ensure DNS settings are applied, you must add any custom DNS servers to the VNET's DNS settings before creating an NGINXaaS deployment. As a workaround for existing deployments, we recommend using the [`resolver` directive](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) to explicitly specify your name server(s) and the [`resolve` parameter](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#resolve) to automatically re-resolve the domain name of the server without restarting NGINX. + +
+ Example of using the resolver directive + For example, + + ```nginx + resolver 10.0.0.2 valid=10s; + upstream backends { + zone backends 64k; + server backends.example.com:8080 resolve; + } + + server { + location / { + proxy_pass http://backends; + } + } + ``` +
+ + 1. Next, select **Tags**. ### Tags tab @@ -71,7 +99,7 @@ You can start the NGINXaaS deployment process by visiting the [Create NGINXaaS]( 1. After validation has succeeded and you've reviewed the terms, select **Create** for Azure to start the deployment. -1. After the deployment finishes, select the NGINX deployment from the list (with "Type: NGINXaaS") to view information about the deployed resource. +1. After the deployment finishes, select the NGINX deployment from the list (with "Type: NGINXaaS") to view information about the deployed resource, including the deployment IP address. {{< img src="nginxaas-azure/deployment-complete.png" alt="Resource Deployment Completed page showing the available deployments and the new NGINXaaS type deployment in the Deployment details section." >}} @@ -84,6 +112,8 @@ You can start the NGINXaaS deployment process by visiting the [Create NGINXaaS]( {{< img src="nginxaas-azure/test-deployment.png" alt="NGINXaaS Overview page showing the IP address of the deployment in the Essentials section." >}} +{{< note >}}It's not possible to manually stop or start NGINXaaS. If necessary, you have the option to delete the deployment and re-deploy at a future date.{{< /note >}} + ## What's next diff --git a/content/nginxaas-azure/troubleshooting/migrate-from-standard.md b/content/nginxaas-azure/getting-started/migrate-from-standard.md similarity index 90% rename from content/nginxaas-azure/troubleshooting/migrate-from-standard.md rename to content/nginxaas-azure/getting-started/migrate-from-standard.md index 829ff6b5b..8c0f82c85 100644 --- a/content/nginxaas-azure/troubleshooting/migrate-from-standard.md +++ b/content/nginxaas-azure/getting-started/migrate-from-standard.md @@ -1,8 +1,8 @@ --- -title: Migrating from Standard to Standard V2 -weight: 200 +title: Migrate from Standard to Standard V2 +weight: 1000 toc: true -url: /nginxaas/azure/troubleshooting/migrate-from-standard/ +url: /nginxaas/azure/getting-started/migrate-from-standard/ type: - how-to --- @@ -17,13 +17,13 @@ The Standard V2 plan maintains the same price as the Standard plan for existing ## Migration Steps -### Using the Portal +### Use the Azure the Portal 1. Go to the **Overview** page of the NGINXaaS deployment in the Azure portal. 2. Under **Essentials**, find the **Pricing Tier** and select **Click to Upgrade**. 3. Select the Standard V2 plan and select Submit. -### Using Terraform +### Use Terraform 1. Update the Terraform AzureRM provider to 4.6.0 or above. @@ -43,7 +43,7 @@ terraform { 3. Run `terraform plan`. Look at the output of terraform plan to ensure that your NGINXaaS deployment is not being replaced. 4. Run `terraform apply` to upgrade the deployment. -### Using Azure-cli +### Use the Azure-cli Run the below command to update your NGINXaaS deployment. diff --git a/content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md b/content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md index 0b00d2613..498f81133 100644 --- a/content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md +++ b/content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md @@ -15,6 +15,9 @@ An NGINX configuration can be applied to the deployment using the Azure portal i As part of applying your NGINX configuration, the service validates the configuration for syntax and compatibility with F5 NGINX as a Service for Azure (NGINXaaS). The use of certain directives and parameters is not allowed to ensure the NGINX configuration’s compatibility with IaaS deployment model in Azure. Validation errors are reported in the editor for you to correct. For more information, check the [NGINX Configuration Validation]({{< ref "nginx-configuration.md#nginx-configuration-validation" >}}) section. +{{< note >}} +NGINXaaS supports Layer 7 HTTP loadbalancing. To configure .com and .net servers, refer to the server name in the server block within the HTTP context. To learn more, and see examples, follow the instructions in the [NGINX configuration validtion]({{< ref "/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-portal.md#nginx-configuration-validation" >}}) section.{{< /note >}} + ## Prerequisites - If the NGINX configuration requires SSL/TLS certificates, then a managed identity and integration with Azure Key Vault is required. @@ -47,8 +50,6 @@ As part of applying your NGINX configuration, the service validates the configur 1. Select **Submit** to apply the new configuration. -{{}}We currently only support more than 5 unique listen ports on the Standard V2 plan. NGINX configurations that specify more than 5 ports on other plans will be rejected. For more information on listen port limitations, see our [FAQ]({{< ref "/nginxaas-azure/faq" >}}).{{}} - ### NGINX configuration validation NGINX configuration is validated real-time to check for syntax and compatibility with the service. Validation errors are reported in the editor for you to correct. diff --git a/content/nginxaas-azure/getting-started/nginx-configuration/overview.md b/content/nginxaas-azure/getting-started/nginx-configuration/overview.md index a7e3ca93b..48ca51ef6 100644 --- a/content/nginxaas-azure/getting-started/nginx-configuration/overview.md +++ b/content/nginxaas-azure/getting-started/nginx-configuration/overview.md @@ -63,7 +63,7 @@ Some directives cannot be overridden by the user provided configuration. |------------------ | ----------------------- | -----------------| | `user` | `nginx` | The `nginx` user has the correct permissions for accessing certificates, policy files and other auxfiles. | | `worker_processes` | `auto` | Set to `auto` to automatically set `worker_processes` to the number of CPU cores. | - | `worker_connections` | | To ensure reasonable performance of the NGINXaaS deployment for Standard V2 plan, the `worker_connections` is fixed at 400/NCU; for basic plan this is set lower. | + | `worker_connections` | | To ensure reasonable performance of the NGINXaaS deployment for Standard V2 plan, the `worker_connections` is fixed at 400/NCU; for basic plan this is set lower.

Changing the value in the config has no effect on the NGINX process in the deployment. | | `pid` | `/run/nginx/nginx.pid` | Set to this value to allow NGINXaaS to automatically manage the NGINX master process. | | `daemon` | `on` | Automatically set to `on` to allow NGINXaaS to manage the NGINX master process. | | `master_process` | `on` | This directive is intended for NGINX developers. | @@ -71,6 +71,15 @@ Some directives cannot be overridden by the user provided configuration. {{}} + +## NGINX listen port restrictions + +- Due to port restrictions on Azure Load Balancer health probes, ports `19`, `21`, `70`, and `119` are not allowed. The NGINXaaS deployment can listen on all other ports. + +- The [Basic]({{< ref "/nginxaas-azure/billing/overview.md#basic-plan" >}}) plan (and the deprecated Standard (v1) plan) supports a maximum of 5 listen ports in the NGINX configuration. Configurations that specify over 5 unique ports are rejected. + +- The [Standard V2]({{< ref "/nginxaas-azure/billing/overview.md#standard-v2-plan" >}}) plan allow users to listen on more than 5 ports. The first five ports under this plan come at no extra cost and there are charges for each additional port utilized. + ## Configuration directives list
diff --git a/content/nginxaas-azure/getting-started/prerequisites.md b/content/nginxaas-azure/getting-started/prerequisites.md index 58f96d7df..aefcdbf6d 100644 --- a/content/nginxaas-azure/getting-started/prerequisites.md +++ b/content/nginxaas-azure/getting-started/prerequisites.md @@ -1,5 +1,5 @@ --- -title: Prerequisites +title: Overview and prerequisites weight: 100 toc: true docs: DOCS-880 @@ -8,7 +8,9 @@ type: - how-to --- -Before you deploy F5 NGINX as a Service for Azure (NGINXaaS) you need to meet the following prerequisites: +## Before you begin + +Before you deploy NGINXaaS you need to meet the following prerequisites: - An Azure account with an active subscription (if you don’t have one, [create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)). @@ -18,7 +20,18 @@ Before you deploy F5 NGINX as a Service for Azure (NGINXaaS) you need to meet th - It's possible to complete a limited setup with the built-in [Contributor](https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) role. -For specific permissions check the [NGINXaaS for Azure Frequently Asked Questions]({{< ref "/nginxaas-azure/faq" >}}). + +- The specific Azure 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. ## What's next diff --git a/content/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md b/content/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md index f348782da..1a36daa0c 100644 --- a/content/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md +++ b/content/nginxaas-azure/getting-started/ssl-tls-certificates/overview.md @@ -11,6 +11,16 @@ F5 NGINX as a Service for Azure (NGINXaaS) enables customers to secure traffic b This document provides details about using SSL/TLS certificates with your F5 NGINX as a Service for Azure deployment. +## Supported certificate types and formats + +NGINXaaS supports **up to 100** TLS/SSL certificates of the following types: + +- Self-signed certificates, Domain Validated (DV) certificates, Organization Validated (OV) certificates, and Extended Validation (EV) certificates. + +NGINX supports the following certificate formats: + +- PEM and PKCS12 format certificates. + ## Add SSL/TLS certificates Add a certificate from an Azure Key Vault to your NGINXaaS deployment using your preferred client tool: @@ -19,6 +29,10 @@ Add a certificate from an Azure Key Vault to your NGINXaaS deployment using your * [Add certificates using the Azure CLI]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/ssl-tls-certificates-azure-cli.md">}}) * [Add certificates using Terraform]({{< ref "/nginxaas-azure/getting-started/ssl-tls-certificates/ssl-tls-certificates-terraform.md">}}) +{{< note >}}- You can overwrite the NGINX default protocol to configure the desired TLS/SSL policy. Read more about the procedure in the [Module ngx_http_ssl_module](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols) documentation. + +- You can associate multiple certificates for the same domain; the "ssl_certificate" directive can be specified multiple times to load certificates of different types. To learn more, see the [Module ngx_http_ssl_module](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate) documentation.{{}} + ### Add SSL/TLS certificates bundled with NGINXaaS configuration You can also add your certificate as a file to your NGINX configuration filesystem; refer to [Upload an NGINX configuration]({{< ref "/nginxaas-azure/getting-started/nginx-configuration/overview.md">}}) to learn about the different options. Although this is a quick method for adding SSL/TLS certificates to your NGINXaaS deployment, we recommend adding certificates through Azure Key Vault (AKV) for enhanced security, certificate rotation, and monitoring. @@ -65,6 +79,9 @@ To view the status of your SSL/TLS certificates, [enable monitoring]({{< ref "/n The following section describes common errors you might encounter while adding SSL/TLS certificates to your NGINXaaS deployment and how to resolve them. +
+Expand to view common certificate errors + #### Error code: `ForbiddenByRbac` **Description:** The [Managed Identity]({{< ref "/nginxaas-azure/getting-started/managed-identity-portal.md" >}}) associated with the NGINXaaS deployment does not have permissions to fetch certificates from key vault. This error is returned when the key vault's permission model is set to [Azure role-based access control](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview?WT.mc_id=Portal-Microsoft_Azure_KeyVault). @@ -350,3 +367,4 @@ The following section describes common errors you might encounter while adding S **Description:** The PEM certificate could not be parsed. **Resolution:** Ensure the file is not empty and contains properly formatted PEM certificate data. +
\ No newline at end of file diff --git a/content/nginxaas-azure/monitoring/enable-logging/logging-using-cli.md b/content/nginxaas-azure/monitoring/enable-logging/logging-using-cli.md index ac675e393..f2e9c9081 100644 --- a/content/nginxaas-azure/monitoring/enable-logging/logging-using-cli.md +++ b/content/nginxaas-azure/monitoring/enable-logging/logging-using-cli.md @@ -51,6 +51,8 @@ To view the supported log categories for an NGINXaaS resource, use the following az monitor diagnostic-settings list --resource ``` +As NGINXaaS logs are stored in your storage, you can define the retention policy most appropriate for your needs. + ### Analyzing NGINX logs in Azure Storage {{< include "/nginxaas-azure/logging-analysis-azure-storage.md" >}} diff --git a/content/nginxaas-azure/monitoring/enable-logging/logging-using-portal.md b/content/nginxaas-azure/monitoring/enable-logging/logging-using-portal.md index 0254c1908..59be2a8b3 100644 --- a/content/nginxaas-azure/monitoring/enable-logging/logging-using-portal.md +++ b/content/nginxaas-azure/monitoring/enable-logging/logging-using-portal.md @@ -46,6 +46,8 @@ Enabling logs using the **NGINX Logs** blade on your NGINXaaS deployment is now {{< img src="nginxaas-azure/diagnostic-settings.png" alt="Screenshot of the Diagnostic Settings configuration page" >}} +As NGINXaaS logs are stored in your storage, you can define the retention policy most appropriate for your needs. + For more information about diagnostic settings destinations, please see the [Diagnostic Settings Destinations](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/diagnostic-settings#destinations) documentation. {{}}Due to limitations imposed by Azure, if the destination chosen is an Azure Storage account, the resource has to be in the same region as the NGINXaaS deployment resource. diff --git a/content/nginxaas-azure/monitoring/enable-logging/logging-using-terraform.md b/content/nginxaas-azure/monitoring/enable-logging/logging-using-terraform.md index 3565d5ca5..059e1c642 100644 --- a/content/nginxaas-azure/monitoring/enable-logging/logging-using-terraform.md +++ b/content/nginxaas-azure/monitoring/enable-logging/logging-using-terraform.md @@ -40,6 +40,8 @@ terraform plan -var="storage_account_resource_group=myresourcegroup" -var="stora terraform apply plan.cache ``` +As NGINXaaS logs are stored in your storage, you can define the retention policy most appropriate for your needs. + {{}}Due to limitations imposed by Azure, if the destination chosen is an Azure Storage account, the resource has to be in the same region as the NGINXaaS deployment resource. {{}} diff --git a/content/nginxaas-azure/monitoring/enable-monitoring.md b/content/nginxaas-azure/monitoring/enable-monitoring.md index 7eb579cee..c4bc181d2 100644 --- a/content/nginxaas-azure/monitoring/enable-monitoring.md +++ b/content/nginxaas-azure/monitoring/enable-monitoring.md @@ -8,7 +8,7 @@ type: - how-to --- -Monitoring your application's performance is crucial for maintaining its reliability and efficiency. F5 NGINX as a Service for Azure (NGINXaaS) seamlessly integrates with Azure Monitor, allowing you to collect, correlate, and analyze metrics for a thorough understanding of your application's health and behavior. +Monitoring your application's performance is crucial for maintaining its reliability and efficiency. F5 NGINX as a Service for Azure (NGINXaaS) seamlessly integrates with Azure Monitor, allowing you to collect, correlate, and analyze metrics for a thorough understanding of your application's health and behavior. Refer to the [Azure monitor overview](https://docs.microsoft.com/en-us/azure/azure-monitor/overview) documentation from Microsoft to learn more about Azure Monitor. @@ -34,7 +34,19 @@ To configure diagnostic settings for a service, see [Create diagnostic settings Azure Monitor platform metrics are ingested and stored free of charge, with a standard retention period of 93 days. Adding alerts, querying Azure Monitor using REST API or exporting metrics using Azure Monitor's diagnostic settings would incurs costs. For detailed pricing, you can refer to the [Azure Monitor pricing page](https://azure.microsoft.com/en-us/pricing/details/monitor/). -## View metrics with Azure Monitor metrics explorer +## Review metrics + +Once you have enabled monitoring, you can view the metrics using the Azure portal or the Azure Monitor API. + +{{< note >}} NGINX Agent periodically gathers connection and request statistics using an internal HTTP request. An Azure service health probe checks for status using a TCP connection for each listen port in the NGINX configuration, incrementing the connection count for each port. + +This contributes to minimal traffic and should not affect these metrics significantly, but you might see an unexpected number of connections and requests.{{}} + +{{< important >}}If some of your deployment's metrics are intermittently missing in Azure monitor, it may indicate that the underlying resources for your deployment are being exhausted. + +Monitor the `nginxaas.capacity.percentage` metric to see the deployment's resource utilization. If it's nearing 100%, consider increasing the deployment's NCU capacity. See the [Scaling Guidance]({{< ref "/nginxaas-azure/quickstart/scaling.md" >}}) documentation for more information.{{}} + +### View metrics with Azure Monitor metrics explorer Access the [Microsoft Azure portal](https://portal.azure.com) @@ -45,7 +57,7 @@ Refer to the [Azure Monitor metrics explorer](https://docs.microsoft.com/en-us/a {{}}Many of NGINX Plus's advanced statistics need to be enabled in the "nginx.conf" file before they will appear in the metrics explorer, for example "plus.http.request.bytes_*". Refer to [Gathering Data to Appear in Statistics](https://docs.nginx.com/nginx/admin-guide/monitoring/live-activity-monitoring/#gathering-data-to-appear-in-statistics) to learn more.{{}} -## Retrieve metrics through Azure Monitor REST API +### Retrieve metrics through Azure Monitor API This section shows you how to effectively discover, gather and analyze NGINXaaS metrics through the Azure Monitor REST API. diff --git a/content/nginxaas-azure/overview/overview.md b/content/nginxaas-azure/overview/overview.md index c06b74a5e..336bee241 100644 --- a/content/nginxaas-azure/overview/overview.md +++ b/content/nginxaas-azure/overview/overview.md @@ -13,9 +13,11 @@ type: NGINX as a Service for Azure is a service offering that is tightly integrated into Microsoft Azure public cloud and its ecosystem, making applications fast, efficient, and reliable with full lifecycle management of advanced NGINX traffic services. NGINXaaS for Azure is available in the Azure Marketplace. -NGINXaaS for Azure is powered by [NGINX Plus](https://www.nginx.com/products/nginx/), which extends NGINX Open Source with advanced functionality and provides customers with a complete application delivery solution. Initial use cases covered by NGINXaaS include L7 HTTP load balancing and reverse proxy which can be managed through various Azure management tools. +NGINXaaS for Azure is powered by [NGINX Plus](https://www.nginx.com/products/nginx/), which extends NGINX Open Source with advanced functionality and provides customers with a complete application delivery solution. Initial use cases covered by NGINXaaS include L4 TCP and L7 HTTP load balancing and reverse proxy which can be managed through various Azure management tools. NGINXaaS allows you to provision distinct deployments as per your business or technical requirements. +NGINXaaS handles the NGINX Plus license management automatically. + ## Capabilities The key capabilities of NGINXaaS for Azure are: @@ -27,6 +29,16 @@ The key capabilities of NGINXaaS for Azure are: - Integrates with the Azure ecosystem (Microsoft Entra, Azure Key Vault, and Azure Monitor). - Addresses a wide range of deployment scenarios (HTTP reverse proxy, JWT authentication, etc). - Adopts a consumption-based pricing to align infrastructure costs to actual usage by billing transactions using Azure. +- Supports end-to-end encryption from client to upstream server. +- Supports the following protocols: HTTPS, HTTP, HTTP/2, HTTP/3, TCP, QUIC, IMAP, POP3, and SMTP. +- Supports any type of message body for upstream and error status code responses, including text/plain, text/css, text/html, application/javascript, and application/json. + + +## Limitations + +- NGINXaaS does not support IPv6 yet. +- NGINXaaS supports one public or private IP per deployment. NGINXaaS doesn't support a mix of public and private IPs at this time. +- The IP address associated with an NGINXaaS deployment can't be changed from public to private, or from private to public. ## Supported regions @@ -44,6 +56,10 @@ NGINXaaS for Azure is supported in the following regions: - Azure management tools (API, CLI, portal, terraform) work with NGINXaaS to create, update, and delete deployments - Each NGINXaaS deployment has dedicated network and compute resources. There is no possibility of [noisy neighbor problems](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor) or data leakage between deployments +- NGINXaaS can route traffic to upstreams even if the upstream servers are located in different geographies. See [Known Issues]({{< ref "/nginxaas-azure/known-issues.md" >}}) for any networking restrictions. +- NGINXaaS supports request tracing. See the [Application Performance Management with NGINX Variables](https://www.f5.com/company/blog/nginx/application-tracing-nginx-plus) blog to learn more about tracing. +- Supports HTTP to HTTPS, HTTPS to HTTP, and HTTP to HTTP redirects. NGINXaaS also provides the ability to create new rules for redirecting. See [How to Create NGINX Rewrite Rules | NGINX](https://www.nginx.com/blog/creating-nginx-rewrite-rules/) for more details. +- NGINXaaS is deployed inside of your Azure network and can connect to your upstream application running in your ecosystem. Known networking limitations can be found in the [Known Issues]({{< ref "/nginxaas-azure/known-issues.md" >}}). ### Redundancy @@ -60,9 +76,9 @@ With the Standard V2 Plan, NGINXaaS uses the following redundancy features to ke {{< img src="nginxaas-azure/n4a-data-plane-architecture.svg" alt="The diagram illustrates the architecture of F5 NGINXaaS for Azure, showing end users accessing a public IP that routes through a network security group within a customer's Azure subscription. This leads to a delegated subnet in a virtual network, which connects to a zone-redundant load balancer within the NGINXaaS subscription. The load balancer distributes traffic across NGINX Plus instances in multiple availability zones, ensuring scalability and redundancy." >}} -NGINXaaS uses new Azure networking capabilities to keep end-user traffic private. Each NGINX Plus instance passes traffic to downstream services using an elastic network card (NIC) that exists inside your subscription. These NICs are injected into a delegated virtual network. A network security group controls traffic to your NGINX Plus instances. - -NGINX Plus instances are automatically upgraded to receive security patches and the latest stable NGINX Plus version. +- NGINXaaS uses new Azure networking capabilities to keep end-user traffic private. A network security group ensures that the deployment is secured and inbound connections are allowed to the ports the NGINX service listens to. +- You can restrict access to NGINXaaS by defining restriction rules at the Network Security Group level or using NGINX's access control list. To learn more, see the [NGINX module ngx_http_access_module](http://nginx.org/en/docs/http/ngx_http_access_module.html) documentation. +- NGINXaaS deployment is automatically upgraded to receive security patches and the latest stable NGINX Plus version. ## What's next diff --git a/content/nginxaas-azure/quickstart/scaling.md b/content/nginxaas-azure/quickstart/scaling.md index dc77a733c..05f9d1608 100644 --- a/content/nginxaas-azure/quickstart/scaling.md +++ b/content/nginxaas-azure/quickstart/scaling.md @@ -33,8 +33,10 @@ To update the capacity of your deploymentv using the Azure Portal, 1. Select **NGINXaaS scaling** in the left menu. 1. Select `Manual`. - 1. Set the desired number of NCUs. - 1. Click **Submit** to update your deployment. + 1. Set the desired number of NCUs. Scale increases in 10 NCU intervals (10, 20, 30, and so on). + 1. Select **Submit** to update your deployment. + + {{< note >}}There's no downtime while an NGINXaaS deployment changes capacity.{{< /note >}} ## Autoscaling @@ -47,7 +49,7 @@ To enable autoscaling using the Azure Portal, 1. Select **NGINXaaS scaling** in the left menu. 1. Select `Autoscale`. 1. Specify the minimum and maximum NCU count. - 1. Click **Submit** to enable NGINXaaS deployment autoscaling. + 1. Select **Submit** to enable NGINXaaS deployment autoscaling. ### Scaling rules diff --git a/content/nginxaas-azure/troubleshooting/_index.md b/content/nginxaas-azure/troubleshooting/_index.md deleted file mode 100644 index 4fb189898..000000000 --- a/content/nginxaas-azure/troubleshooting/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Troubleshooting -weight: 700 -url: /nginxaas/azure/troubleshooting/ ----