Optimize Application Gateways
Azure Application Gateway is a powerful web traffic load balancer that offers advanced routing capabilities, enhanced security, and impressive scalability. To maximize the benefits of Application Gateway and ensure your web applications thrive in the cloud, follow these best practices aligned with the Well-Architected Framework pillars.
Below are actionable recommendations for your Azure Application Gateway.
Talk to an Azure expert! Email us or schedule a 30-minute consultation and let's optimize your Azure environment together!
Stay ahead with actionable insights for Azure optimization. Subscribe to updates and unlock the full potential of Azure!
Cost Optimization Recommendations
Delete Orphaned Application Gateways
Application Gateways with no backend pools are considered orphaned and should be reviewed for deletion to reduce costs.
Orphaned Application Gateways often indicate misconfigurations or resources that are no longer in use. These gateways continue to incur charges despite not serving any traffic or backend workloads.
- Regularly audit your environment to identify orphaned Application Gateways.
- Confirm with stakeholders before deletion to avoid accidental removal of resources under configuration.
Stop App Gateways During Inactivity
To avoid unnecessary costs, identify and stop Application Gateway instances that are not actively serving traffic, particularly in non-production environments during low-usage periods.
A stopped Application Gateway instance doesn't incur costs. Application Gateway instances that continuously run can incur unnecessary costs. Evaluate usage patterns, and stop instances when you don't need them. For example, expect low usage after business hours in dev/test environments.
Monitor Key Cost Driver Metrics
Keep a close eye on Application Gateway metrics such as estimated billed capacity units, fixed billable capacity units, and current capacity units to ensure optimal resource allocation and identify potential areas for optimization.
Use these metrics to validate whether the provisioned instance count matches the amount of incoming traffic, and ensure that you fully utilize the allocated resources. Make sure you account for bandwidth costs.
Performance Recommendations
Minimum Instance Count
Configure the minimum instance count based on your estimated capacity requirements, observed autoscaling trends, and application traffic patterns.
Check the current compute units for the past month. This metric represents the gateway's CPU usage. To define the minimum instance count, divide the peak usage by 10. For example, if your average current compute units in the past month is 50, set the minimum instance count to five. This ensures your Application Gateway can handle baseline traffic demands efficiently. For Application Gateway v2, autoscaling takes approximately three to five minutes before the extra set of instances are ready to serve traffic. During that time, if Application Gateway has short spikes in traffic, expect transient latency or loss of traffic.
Maximum Autoscale Instance Count
Set the maximum autoscale instance count to the highest possible value (125 instances) to allow Application Gateway to scale out effectively during peak traffic periods.
Verify that your dedicated subnet has sufficient IP addresses to support the maximum instance count. Application Gateway can scale out as needed to handle increased traffic to your applications. This setting doesn't increase cost because you only pay for the consumed capacity. Make sure that the Application Gateway dedicated subnet has sufficient available IP addresses to support the increased set of instances.
Dedicated Subnet Size
Use a /24 subnet for your Application Gateway v2 deployment to ensure sufficient IP address space for all instances, including private frontend IP configurations.
Appropriately size the dedicated subnet that Application Gateway requires. If you want to deploy other Application Gateway resources in the same subnet, consider the extra IP addresses that you require for the maximum instance count.
Use a /24 subnet to provide support for all IP addresses that your Application Gateway v2 deployment needs. Application Gateway uses one private IP address for each instance and another private IP address if you configure a private front-end IP. The Standard_v2 or WAF_v2 SKU can support up to 125 instances. Azure reserves five IP addresses in each subnet for internal use.
Security Recommendations
Establish a TLS Policy
Enforce the use of the latest and most secure TLS protocols and cipher suites by implementing a robust TLS policy.
Stay updated with the latest TLS policy versions for optimal protection. Use the latest TLS policy to enforce the use of TLS 1.2 and stronger ciphers. The TLS policy includes control of the TLS protocol version and the cipher suites and also the order in which a TLS handshake uses ciphers.
Implement TLS Termination
Offload TLS handling to Application Gateway, improving performance, simplifying certificate management, and allowing intelligent routing decisions based on request content.
- Performance improves because requests that go to different back ends don't have to reauthenticate to each back end.
- The gateway can access the request content and make intelligent routing decisions.
- You only need to install the certificate on Application Gateway, which simplifies certificate management.
Integratation with Key Vault
Securely store your TLS certificates in Azure Key Vault for enhanced security, streamlined certificate management, and simplified renewal and rotation processes.
This approach provides stronger security, easier separation of roles and responsibilities, support for managed certificates, and an easier certificate renewal and rotation process.
Adhere to All NSG Restrictions for Application Gateway
Respect network security group (NSG) rules applied to the Application Gateway subnet to ensure proper security configuration and prevent unauthorized access
The Application Gateway subnet supports NSGs, but there are some restrictions. For instance, some communication with certain port ranges is prohibited. Make sure you understand the implications of those restrictions.
Reliability Recommendations
Deploy in a Zone-Aware Configuration
Spread Application Gateway instances across availability zones to improve fault tolerance and build redundancy.
When you spread multiple instances across zones, your workload can withstand failures in a single zone. If you have an unavailable zone, traffic automatically shifts to healthy instances in other zones, which maintains application reliability.
- Check regional support for zone redundancy because not all regions offer this feature.
Utilize Application Gateway Health Probes
Configure health probes to continuously monitor the health of your backend servers.
Application Gateway monitors the health of all the servers in its back-end pool and automatically stops sending traffic to any server that it considers unhealthy. Health probes ensure that traffic only routes to back ends that can handle the traffic.
Rate-Limiting Rules for Azure WAF
Protect your application from traffic overload and potential denial-of-service attacks by implementing rate-limiting rules.
Use rate limiting to avoid problems like retry storms. This prevents clients from overwhelming your application with excessive requests.
Avoid UDRs on the App Gateway Subnet
Using User-Defined Routes (UDRs) on the Application Gateway subnet can interfere with backend health reporting, log generation, and metric collection.
Don't use UDRs on the Application Gateway subnet so that the back-end health report functions properly and generates the correct logs and metrics. Avoid using them unless absolutely necessary. If you must use a UDR in the Application Gateway subnet, see Supported UDRs. UDRs on the Application Gateway subnet can cause some problems.
Adjust the IdleTimeout Setting
Ensure connections between Application Gateway and clients remain open even if the backend takes longer than the default four minutes to respond, preventing premature connection closures.
Configure the IdleTimeout setting to match the specific listener, traffic characteristics, and response times of your backend application. The default value is four minutes. You can configure it to a maximum of 30 minutes. If you don't configure this setting, the connection closes, and the client doesn't see the back-end response.
Operational Excellence Recommendations
Configure Alerts on Capacity Metrics
Set up alerts to notify you when capacity metrics, such as CPU usage and compute unit usage, approach or exceed predefined thresholds.
Alerts allows you to address potential performance bottlenecks before they impact your application's availability or responsiveness. Set alerts when metrics cross thresholds so that you know when your usage increases. This approach ensures that you have enough time to implement necessary changes to your workload and prevents degradation or outages.
Alerts for Critical Operational Metrics
Implement alerts for metrics that indicate potential issues at the Application Gateway or backend level, such as unhealthy host counts, response status errors (4xx and 5xx), backend response time, and overall Application Gateway request processing time.
Use alerts to help ensure that your team can respond to problems in a timely manner and facilitate troubleshooting. We recommend that you evaluate the following alerts:
- Unhealthy host count
- Response status, such as 4xx and 5xx errors
- Back-end response status, such as 4xx and 5xx errors
- Back-end last byte response time
- Application Gateway total time
Diagnostic Logs for App Gateway and WAF
Collect detailed logs to gain insights into firewall activity, performance trends, and access patterns.
These logs are invaluable for troubleshooting issues, analyzing performance, and identifying security threats. Use logs to help detect, investigate, and troubleshoot problems with Application Gateway instances and your workload.