Skip to main content

Optimize Azure App Services

Azure App Services is a fully managed platform that allows you to build and host web applications, APIs, and mobile backends. App Services are hosted within an App Service Plan, which defines the region and compute resources used to run your app. Configuring App Services correctly is crucial to ensure they are secure, reliable, and performant.

In this guide, we'll discuss best practices and recommendations for optimizing your Azure App Services.

Optimize Your Azure Environment with Us!
Looking to enhance your Azure setup for cost efficiency, performance, reliability, or security?
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!

Performance Recommendations

HTTP/2 for Improved Performance

Impact: Low

HTTP/2 can improve protocol efficiency by multiplexing requests, reusing connections, and compressing headers. Enabling HTTP/2 can lead to faster page loads and better use of available resources.

Enable HTTP/2 to reduce latency and increase the efficiency of communication.

Application Code Dependencies

Impact: High

Regularly review and optimize your application code to remove unnecessary dependencies and reduce the application's memory and CPU usage. Also, ensure the app is running the most efficient version of its dependencies.

Optimize code and update dependencies to minimize the performance overhead.

Use Scaling to Handle Traffic Spikes

Impact: High

Configure auto-scaling to dynamically adjust the number of app instances based on traffic demand. This ensures your app can handle spikes in traffic without overloading resources.

Set up auto-scaling rules based on performance metrics (e.g., CPU utilization, request count).

Reliability Recommendations

Disable Session Affinity (Sticky Sessions)

Impact: Medium

Session Affinity, also known as sticky sessions, is a configuration that forces user traffic to always route to the same instance of an application. This is typically used to maintain session state for users during their interactions with the application, ensuring that all requests from the same user during a session are handled by the same server.

However, while this can be useful in certain scenarios, it can also introduce significant challenges in terms of scalability and application reliability.

For stateles applications (such as those based on REST principles), enabling session affinity can cause performance bottlenecks. Sticky sessions force requests from the same user to go to a specific instance, which may lead to uneven load distribution and less efficient use of resources across your app service plan.

Here are the reasons to disable session affinity when possible:

  • Improved Load Distribution: Without session affinity, traffic is more evenly distributed across the available instances, which allows for better scalability and resource utilization.
  • Enhanced Fault Tolerance: Disabling session affinity means that if one instance becomes unavailable, the load balancer can route traffic to other healthy instances without concern for session continuity, improving application reliability.
  • Better Scalability: Stateless applications are designed to handle requests independently, meaning they don't rely on session data stored on a specific instance. Disabling sticky sessions allows for more flexible scaling, as new instances can be added or removed without worrying about session persistence.

While it's generally recommended to disable session affinity for stateless applications, there are some cases where session affinity may be necessary:

  • Stateful Applications: If your application requires maintaining user state across multiple requests then session affinity may be necessary to ensure that all requests from a user go to the same instance. However, consider using other methods to persist session data (e.g., Redis cache, distributed session stores) to avoid sticky sessions.
  • Legacy Applications: Some legacy applications that were built with stateful architecture may require sticky sessions for proper operation.

If possible, disable session affinity to allow better load distribution across instances.

Enable Automatic Healing

Impact: Low

Configure automatic healing rules based on request count, memory limits, slow requests, and other performance indicators. This helps ensure your app can recover automatically from problems without manual intervention.

Enable automatic healing to ensure your app can recover from unexpected failures.

Implement Health Checks

Impact: Medium

Enable health checks by configuring a health check endpoint in your app. Health checks monitor your app's health, and unhealthy instances can be automatically isolated, allowing traffic to be routed only to healthy instances.

Enable health checks for early detection of issues and automatic remediation.

Always On for shared App Service Plans

Impact: Low

Enable the Always On feature for applications hosted in shared App Service Plans to prevent apps from unloading during idle periods. This helps avoid cold starts, which can result in request timeouts.

Enable Always On for better performance.

Security Recommendations

Enforce TLS 1.2 or Higher

Impact: Medium

App Services should be configured to use TLS 1.2 or higher to secure communication channels. Any configurations using older versions of TLS (such as TLS 1.0 or 1.1) should be reviewed and updated.

Enforce TLS 1.2 to prevent vulnerabilities associated with older TLS versions.

Managed Identity for Resource Access

Impact: High

Configure Azure Active Directory (AAD) authentication or other secure identity providers to protect your App Services. Avoid using basic authentication or embedding credentials directly in the app such as passwords in database connection strings.

When connecting to Azure resources such as databases, storage accounts, or Redis caches, avoid using traditional authentication methods like usernames and passwords in connection strings. Instead, leverage Managed Identity to secure your resources.

A Managed Identity is an account that provides an identity for Azure resources to use when connecting to other Azure resources. This identity can be assigned specific permissions, allowing secure access without the need for storing credentials like usernames and passwords. Since Managed Identity does not involve storing sensitive credentials, it is inherently more secure and simplifies access management.

Benefits of Managed Identity

  • No Credentials Stored: Managed Identity eliminates the need for credentials such as usernames and passwords. It's particularly beneficial when an employee leaves the organization, as the identity remains within the Azure tenancy and cannot be taken or misused.
  • Simplified Access Management: You can allocate permissions directly to the Managed Identity for accessing resources. This reduces the risk of credential leakage.
  • Cost-Free: Managed Identity is provided at no extra cost by Azure, making it a cost-effective security solution.

By following these best practices, you ensure secure and streamlined access to Azure resources, while eliminating the risk of credential management issues.

Store Secrets Securely in Key Vault

Impact: Medium

Store application settings and configuration variables securely using Azure Key Vault and avoid hardcoding them in the application code. This allows you to manage sensitive data separately and securely.

Use Azure Key Vault to securely store sensitive settings such as API keys, and secrets.