Azure App Service Auto-Heal: Capturing Relevant Data During Performance Issues
Introduction Azure App Service is a powerful platform that simplifies the deployment and management of web applications. However, maintaining application performance and availability is crucial. When performance issues arise, identifying the root cause can be challenging. This is where Auto-Heal in Azure App Service becomes a game-changer. Auto-Heal is a diagnostic and recovery feature that allows you to proactively detect and mitigate issues affecting your application’s performance. It enables automatic corrective actions and helps capture vital diagnostic data to troubleshoot problems efficiently. In this blog, we’ll explore how Auto-Heal works, its configuration, and how it assists in diagnosing performance bottlenecks. What is Auto-Heal in Azure App Service? Auto-Heal is a self-healing mechanism that allows you to define custom rules to detect and respond to problematic conditions in your application. When an issue meets the defined conditions, Auto-Heal can take actions such as: Recycling the application process Collecting diagnostic dumps Logging additional telemetry for analysis Triggering a custom action By leveraging Auto-Heal, you can minimize downtime, improve reliability, and reduce manual intervention for troubleshooting. Configuring Auto-Heal in Azure App Service To set up Auto-Heal, follow these steps: Access Auto-Heal Settings Navigate to the Azure Portal. Go to your App Service. Select Diagnose and Solve Problems. Search for Auto-Heal or go to Diagnostic tools tile and select Auto-Heal. Define Auto-Heal Rules Auto-Heal allows you to define rules based on: Request Duration: If a request takes too long, trigger an action. Memory Usage: If memory consumption exceeds a certain threshold. HTTP Status Codes: If multiple requests return specific status codes (e.g., 500 errors). Request Count: If excessive requests occur within a defined time frame. Configure Auto-Heal Actions Once conditions are set, you can configure one or more of the following actions: Recycle Process: Restart the worker process to restore the application. Log Events: Capture logs for further analysis. Custom Action: You can do the following: Run Diagnostics: Gather diagnostic data (Memory Dump, CLR Profiler, CLR Profiler with Threads Stacks, Java Memory Dump, Java Thread Dump) for troubleshooting. Run any Executable: Run scripts to automate corrective measures. Capturing Relevant Data During Performance Issues One of the most powerful aspects of Auto-Heal is its ability to capture valuable diagnostic data when an issue occurs. Here’s how: Collecting Memory Dumps Memory dumps provide insights into application crashes, high CP or high memory usage. These can be analyzed using WinDbg or DebugDiag. Enabling Logs for Deeper Insights Auto-Heal logs detailed events in Kudu Console, Application Insights, and Azure Monitor Logs. This helps identify patterns and root causes. Collecting CLR Profiler traces CLR Profiler traces capture call stacks and exceptions, providing a user-friendly report for diagnosing slow responses and HTTP issues at the application code level. In this article, we will cover the steps to configure an Auto-Heal rule for the following performance issues: To capture a .NET Profiler/CLR Profiler trace for Slow responses. To capture a .NET Profiler/CLR Profiler trace for HTTP 5XX Status codes. To capture Memory dump for a High Memory usage. Auto-Heal rule to capture .NET Profiler trace for Slow response: 1. Navigate to your App Service on Azure Portal, and click on Diagnose and Solve problems: 2. Search for Auto-Heal or go to Diagnostic tools tile and select Auto-Heal: 3. Click on 'On': 4. Select Request Duration and click on Add Slow Request rule: 5. Add the following information with respect to how much slowness you are facing: After how many slow requests you want this condition to kick in? - After how many slow requests you want this Auto-Heal rule to start writing/capturing relevant data. What should be minimum duration (in seconds) for these slow requests? - How many seconds should the request take to be considered as a slow request. What is the time interval (in seconds) in which the above condition should be met? - In how many seconds, the above defined slow request should occur. What is the request path (leave blank for all requests)? - If there is a specific URL which is slow, you can add that in this section or leave it as blank. In the below screenshot, the rule is set for this example "1 request taking 30 seconds in 5 minutes/300 seconds should trigger this rule" Add the values in the text boxes available and click "Ok" 6. Select Custom Action and select CLR Profiler with Thread Stacks option: 7. The tool options provide three choices: CollectKillAnalyze: If this option is selected, the tool will collect the data, analyze and generate the report and recycle the process. CollectLogs: If this option is selected, the tool will collect the data only. It will not analyze and generate the report and recycle the process. Troubleshoot: If this option is selected, the tool will collect the data and analyze and generate the report, but it will not recycle the process. Select the option, according to your scenario: Click on "Save". 8. Review the new settings of the rule: Clicking on "Save" will cause a restart as this is a configuration level change and for this to get in effect a restart is required. So, it is advised to make such changes in non-business hours. 9. Click on "Save". Once you click on Save, the app will get restarted and the rule will become active and monitor for Slow requests. Auto-Heal rule to capture .NET Profiler trace for HTTP 5XX Status code: For this scenario, Steps 1, 2, 3 will remain the same as above (from the Slow requests scenario). There will be following changes: 1. Select Status code and click on Add Status Code rule 2. Add the following value with respect to what Status code or range of status code you want this rule to be triggered by: Do you want to set this rule for a specific status code or a range of status codes? - Is it single status code you want to set this rule for or a range of status code. After how many requests you want this condition to kick in? - After how many requests throwing the concerned status code you want this Auto-Heal rule to start writing/capturing relevant data. What should be the status code for these requests? - Mention the status code here. What should be the sub-status code for these requests? - Mention the sub-status code here, if any, else you can leave this blank. What should be the win32-status code for these requests? - Mention the win32-status code here, if any, else you can leave this blank. What is the time interval (in seconds) in which the above condition should be met? - In how many seconds, the above defined status code should occur. What is the request path (leave blank for all requests)? - If there is a specific URL which is throwing that status code, you can add that in this section or leave it as blank. Add the values according to your scenario and click on "Ok" In the below screenshot, the rule is set for this example "1 request throwing HTTP 500 status code in 60 seconds should trigger this rule" After adding the above information, you can follow the Steps 6, 7 ,8, 9 from the first scenario (Slow Requests) and the Auto-Heal rule for the status code will become active and monitor for this performance issue. Auto-Heal rule to capture Memory dump for High Memory usage: For this scenario, Steps 1, 2, 3 will remain the same as above (from the Slow requests scenario). There will be following changes: 1. Select Memory Limit and click on Configure Private Bytes rule: 2. According to your application's memory usage, add the Private bytes in KB at which this rule should be triggered: In the below screenshot, the rule is set for this example "The application process using 2000000 KB (~2 GB) should trigger this rule" Click on "Ok" 3. In Configure Actions, select Custom Action and click on Memory Dump: 4. The tool options provide three choices: CollectKillAnalyze: If this option is selected, the tool will collect the data, analyze and generate the report and recycle the process. CollectLogs: If this option is selected, the tool will collect the data only. It will not analyze and generate the report and recycle the process. Troubleshoot: If this option is selected, the tool will collect the data and analyze and generate the report, but it will not recycle the process. Select the option, according to your scenario: 5. For the memory dumps/reports to get saved, you will have to select either an existing Storage Account or will have to create a new one: Click on Select: Create a new one or choose existing: 6. Once the storage account is set, click on "Save". Review the rule settings and click on "Save". Clicking on "Save" will cause a restart as this is a configuration level change and for this to get in effect a restart is required. So, it is advised to make such changes in non-business hours. Best Practices for Using Auto-Heal Start with Conservative Rules: Avoid overly aggressive auto-restarts to prevent unnecessary disruptions. Monitor Performance Trends: Use Azure Monitor to correlate Auto-Heal events with performance metrics. Regularly Review Logs: Periodically analyze collected logs and dumps to fine-tune your Auto-Heal strategy. Combine with Application Insights: Leverage Application Insights for end-to-end monitoring and deeper diagnostics. Conclusion Auto-Heal in Azure App Service is a powerful tool that not only helps maintain application stability but also provides critical diagnostic data when performance issues arise. By proactively setting up Auto-Heal rules and leveraging its diagnostic capabilities, you can minimize downtime and streamline troubleshooting efforts. Have you used Auto-Heal in your application? Share your experiences and insights in the comments! Stay tuned for more Azure tips and best practices!Capture .NET Profiler Trace on the Azure App Service platform
Summary The article provides guidance on using the .NET Profiler Trace feature in Microsoft Azure App Service to diagnose performance issues in ASP.NET applications. It explains how to configure and collect the trace by accessing the Azure Portal, navigating to the Azure App Service, and selecting the "Collect .NET Profiler Trace" feature. Users can choose between "Collect and Analyze Data" or "Collect Data only" and must select the instance to perform the trace on. The trace stops after 60 seconds but can be extended up to 15 minutes. After analysis, users can view the report online or download the trace file for local analysis, which includes information like slow requests and CPU stacks. The article also details how to analyze the trace using Perf View, a tool available on GitHub, to identify performance issues. Additionally, it provides a table outlining scenarios for using .NET Profiler Trace or memory dumps based on various factors like issue type and symptom code. This tool is particularly useful for diagnosing slow or hung ASP.NET applications and is available only in Standard or higher SKUs with the Always On setting enabled. In this article How to configure and collect the .NET Profiler Trace How to download the .NET Profiler Trace How to analyze a .NET Profiler Trace When to use .NET Profilers tracing vs. a memory dump The tool is exceptionally suited for scenarios where an ASP.NET application is performing slower than expected or gets hung. As shown in Figure 1, this feature is available only in Standard or higher Stock Keeping Unit (SKU) and Always On is enabled. If you try to configure .NET Profiler Trace, without both configurations the following messages is rendered. Azure App Service Diagnose and solve problems blade in the Azure Portal error messages Error – This tool is supported only on Standard, Premium, and Isolated Stock Keeping Unit (SKU) only with AlwaysOn setting enabled to TRUE. Error – We determined that the web app is not "Always-On" enabled and diagnostic does not work reliably with Auto Heal. Turn on the Always-On setting by going to the Application Settings for the web app and then run these tools. How to configure and collect the .NET Profiler Trace To configure a .NET Profiler Trace access the Azure Portal and navigate to the Azure App Service which is experiencing a performance issue. Select Diagnose and solve problems and then the Diagnostic Tools tile. Azure App Service Diagnose and solve problems blade in the Azure Portal Select the "Collect .NET Profiler Trace" feature on the Diagnostic Tools blade and the following blade is rendered. Notice that you can only select Collect and Analyze Data or Collect Data only. Choose the one you prefer but do consider having the feature perform the analysis. You can download the trace for offline analysis if necessary. Also notice that you need to **select the instance** on which you want to perform the trace. In the scenario, there is only one, so the selection is simple. However, if your app runs on multiple instances, either select them all or if you identify a specific instance which is behaving slowly, select only that one. You realize the best results if you can isolate a single instance enough so that the request you sent is the only one received on that instance. However, in a scenario where the request or instance is not known, the trace adds value and insights. Adding a thread report provides list of all the threads in the process is also collected at the end of the profiler trace. The thread report is useful especially if you are troubleshooting hung processes, deadlocks, or requests taking more than 60 seconds. This pauses your process for a few seconds until the thread dump is generated. CAUTION: a thread report is NOT recommended if you are experiencing High CPU in your application, you may experience issues during trace analysis if CPU consumption is high. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace blade in the Azure Portal There are a few points called out in the previous image which are important to read and consider. Specifically the .NET Profiler Trace will stop after 60 seconds from the time that it is started. Therefore, if you can reproduce the issue, have the reproduction steps ready before you start the profiling. If you are not able to reproduce the issue, then you may need to run the trace a few times until the slowness or hang occurs. The collection time can be increased up to 15 minutes (900 seconds) by adding an application setting named IIS_PROFILING_TIMEOUT_IN_SECONDS with a value of up to 900. After selecting the instance to perform the trace on, press the Collect Profiler Trace button, wait for the profiler to start as seen here, then reproduce the issue or wait for it to occur. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace status starting window After the issue is reproduced the .NET Profiler Trace continues to the next step of stopping as seen here. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace status stopping window Once stopped, the process continues to the analysis phase if you selected the Collect and Analyze Data option, as seen in the following image, otherwise you are provided a link to download the file for analysis on your local machine. The analysis can take some time, so be patient. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace status analyzing window After the analysis is complete, you can either view the Analysis online or download the trace file for local development. How to download the .NET Profiler Trace Once the analysis is complete you can view the report by selecting the link in the Reports column, as seen here. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace status complete window Clicking on the report you see the following. There is some useful information in this report, like a list of slow requests, Failed Requests, Thread Call stacks, and CPU stacks. Also shown is a breakdown of where the time was spent during the response generation into categories like Application Code, Platform, and Network. In this case, all the time is spent in the Application code. Azure App Service Diagnose and solve problems, Collect .NET Profiler Trace review the Report To find out specifically where in the Application Code this request performs the analysis of the trace locally. How to analyze a .NET Profiler Trace After downloading the network trace by selecting the link in the Data column, you can use a tool named Perf View which is downloadable on GitHub here. Begin by opening Perf View and double-clicking on the ".DIAGSESSION" file, after some moments expand it to render the Event Trace Log (ETL) file, as shown here. Analyze Azure App Service .NET Profiler Trace with Perf View Double-click on the Thread Time (with startStop Activities) Stacks which open up a new window similar to shown next. If your App Service is configured as out-of-process select the dotnet process which is associated to your app code. If your App Service is in-process select the w3wp process. Analyze Azure App Service .NET Profiler Trace with Perf View, dotnet out-of-process Double-click on dotnet and another window is rendered, as shown here. From the previous image, .NET Profiler Trace reviews the Report, it is clear where slowness is coming from, find that in the Name column or search for it by entering the page name into the Find text box. Analyze Azure App Service .NET Profiler Trace with Perf View, dotnet out-of-process, method, and class discovery Once found right-click on the row and select Drill Into from the pop-up menu, shown here. Select the Call Tree tab and the reason for the issue renders showing which request was performing slow. Analyze Azure App Service .NET Profiler Trace with Perf View, dotnet out-of-process, root cause This example is relatively. As you analyze more performance issues using Perf View to analyze a .NET Profiler Trace your ability to find the root cause of more complicated performance issues can be realized. When to use .NET Profilers tracing vs. a memory dump That same issue is seen in a memory dump, however there are some scenarios where a .NET Profile trace would be best. Here is a table, Table 1, which describes scenarios for when to capture a .NET profile trace or to capture a memory dump. Issue Type Symptom Code Symptom Stack Startup Issue Intermittent Scenario Performance 200 Requests take 500 ms to 2.5 seconds, or takes <= 60 seconds ASP.NET/ASP.NET Core No No Profiler Performance 200 Requests take > 60 seconds & < 230 seconds ASP.NET/ASP.NET Core No No Dump Performance 502.3/500.121/503 Requests take >=120 to <= 230 seconds ASP.NET No No Dump, Profiler Performance 502.3/500.121/503 Requests timing out >=230 ASP.NET/ASP.NET Core Yes/No Yes/No Dump Performance 502.3/500.121/503 App hangs or deadlocks (ex: due to async anti-pattern) ASP.NET/ASP.NET Core Yes/No Yes/No Dump Performance 502.3/500.121/503 App hangs on startup (ex: caused by nonasync deadlock issue) ASP.NET/ASP.NET Core No Yes/No Dump Performance 502.3/500.121 Request timing out >=230 (time out) ASP.NET/ASP.NET Core No No Dump Availability 502.3/500.121/503 High CPU causing app downtime ASP.NET No No Profiler, Dump Availability 502.3/500.121/503 High Memory causing app downtime ASP.NET/ASP.NET Core No No Dump Availability 500.0[121]/503 SQLException or Some Exception causes app downtime ASP.NET No No Dump, Profiler Availability 500.0[121]/503 App crashing due to fatal exception at native layer ASP.NET/ASP.NET Core Yes/No Yes/No Dump Availability 500.0[121]/503 App crashing due to exit code (ex: 0xC0000374) ASP.NET/ASP.NET Core Yes/No Yes/No Dump Availability 500.0 App begin nonfatal exceptions (during a context of a request) ASP.NET No No Profiler, Dump Availability 500.0 App begin nonfatal exceptions (during a context of a request) ASP.NET/ASP.NET Core No Yes/No Dump Table 1, when to capture a .NET Profiler Trace or a Memory Dump on Azure App Service, Diagnose and solve problems Use this list as a guide to help decide how to approach the solving of performance and availability applications problems which are occurring in your application source code. Here are some descriptions regarding the column heading. - Issues Type – Performance means that a request to the app is responding or processing the response but not at a speed in which it is expected to. Availability means that the request is failing or consuming more resources than expected. - Symptom Code – the HTTP Status and/or sub status which is returned by the request. - Symptom – a description of the behavior experienced while engaging with the application. - Stack – this table targets .NET, specifically ASP.NET, and ASP.NET Core applications. - Startup Issue – if "No" then the Scenario can or should be used, "No" represents that the issue is not at startup. If "Yes/No" it means the Scenario is useful for troubleshooting startup issues. - Intermittent – if "No" then the Scenario can or should be used, "No" means the issue is not intermittent or that it can be reproduced. If "Yes/No" it means the Scenario is useful if the issue happens randomly or cannot be reproduced. Meaning that the tool can be set to trigger on a specific event or left running for a specific amount of time until the exception happens. - Scenario – "Profiler" means that the collection of a .NET Profiler Trace would be recommended. "Dump" means that a memory dump would be your best option. If both are provided, then both can be useful when the given symptoms and system codes are present. You might find the videos in Table 2 useful which instruct you how to collect and analyze a memory dump or .NET Profiler Trace. Product Stack Hosting Symptom Capture Analyze Scenario App Service Windows in High CPU link link Dump App Service Windows in High Memory link link Dump App Service Windows in Terminate link link Dump App Service Windows in Hang link link Dump App Service Windows out High CPU link link Dump App Service Windows out High Memory link link Dump App Service Windows out Terminate link link Dump App Service Windows out Hang link link Dump App Service Windows in High CPU link link Dump Function App Windows in High Memory link link Dump Function App Windows in Terminate link link Dump Function App Windows in Hang link link Dump Function App Windows out High CPU link link Dump Function App Windows out High Memory link link Dump Function App Windows out Terminate link link Dump Function App Windows out Hang link link Dump Azure WebJob Windows in High CPU link link Dump App Service Windows in High CPU link link .NET Profiler App Service Windows in Hang link link .NET Profiler App Service Windows in Exception link link .NET Profiler App Service Windows out High CPU link link .NET Profiler App Service Windows out Hang link link .NET Profiler App Service Windows out Exception link link .NET Profiler Table 2, short video instructions on capturing and analyzing dumps and profiler traces Here are a few other helpful videos for troubleshooting Azure App Service Availability and Performance issues: View Application EventLogs Azure App Service Add Application Insights To Azure App Service Prior to capturing and analyzing memory dumps, consider viewing this short video: Setting up WinDbg to analyze Managed code memory dumps and this blog post titled: Capture memory dumps on the Azure App Service platform. Question & Answers - Q: What are the prerequisites for using the .NET Profiler Trace feature in Azure App Service? A: To use the .NET Profiler Trace feature in Azure App Service, the application must be running on a Standard or higher Stock Keeping Unit (SKU) with the Always On setting enabled. If these conditions are not met, the tool will not function, and error messages will be displayed indicating the need for these configurations. - Q: How can you extend the default collection time for a .NET Profiler Trace beyond 60 seconds? A: The default collection time for a .NET Profiler Trace is 60 seconds, but it can be extended up to 15 minutes (900 seconds) by adding an application setting named IIS_PROFILING_TIMEOUT_IN_SECONDS with a value of up to 900. This allows for a longer duration to capture the necessary data for analysis. - Q: When should you use a .NET Profiler Trace instead of a memory dump for diagnosing performance issues in an ASP.NET application? A: A .NET Profiler Trace is recommended for diagnosing performance issues where requests take between 500 milliseconds to 2.5 seconds or less than 60 seconds. It is also useful for identifying high CPU usage causing app downtime. In contrast, a memory dump is more suitable for scenarios where requests take longer than 60 seconds, the application hangs or deadlocks, or there are issues related to high memory usage or app crashes due to fatal exceptions. Keywords Microsoft Azure, Azure App Service, .NET Profiler Trace, ASP.NET performance, Azure debugging tools, .NET performance issues, Azure diagnostic tools, Collect .NET Profiler Trace, Analyze .NET Profiler Trace, Azure portal, Performance troubleshooting, ASP.NET application, Slow ASP.NET app, Azure Standard SKU, Always On setting, Memory dump vs profiler trace, Perf View analysis, Azure performance diagnostics, .NET application profiling, Diagnose ASP.NET slowness, Azure app performance, High CPU usage ASP.NET, Azure app diagnostics, .NET Profiler configuration, Azure app service performanceGiving Granular Controls to Azure EasyAuth
When working with web applications, implementing authentication and authorization is crucial for security. Traditionally, there have been various ways from simple username/password inputs to OAuth-based approaches. However, implementing authentication and authorization logics can be quite complex and challenging. Fortunately, Azure offers a feature called EasyAuth, which simplifies this process. EasyAuth is built in Azure PaaS services like App Service, Functions, Container Apps, and Static Web Apps. The best part of using EasyAuth is that you don't have to modify existing code for the EasyAuth integration. Having said that, since EasyAuth follows one of the cloud architecture patterns – Sidecar pattern, it secures the entire web application. However, fine-tuned control – such as protecting only specific areas or excluding certain parts – can be tricky to achieve. To address this limitation, the developer community has explored various solutions: EasyAuth for App Service by Maxime Rouiller EasyAuth for Azure Container Apps by John Reilly EasyAuth for Azure Static Web Apps by Anthony Chu These approaches are still valid today but require updates to align with the latest .NET features. Throughout this post, I'm going to explore how to transform the authentication token generated by EasyAuth in Azure App Service and Azure Container Apps into a format usable by Blazor and other ASP.NET Core web applications. Please refer to my previous post about EasyAuth on Azure Static Web Apps. Download NuGet Package A few NuGet packages are available for ASP.NET Core web applications to integrate the Client Principal token generated by EasyAuth. Currently, the packages support Microsoft Entra ID and GitHub OAuth. NOTE: These packages are not the Microsoft official ones. Therefore, use these packages with your own care. Package Version Downloads Aliencube.Azure.Extensions.EasyAuth Aliencube.Azure.Extensions.EasyAuth.EntraID Aliencube.Azure.Extensions.EasyAuth.GitHub You can find the source code of these NuGet packages on this GitHub repository. Getting Started with Azure Developer CLI The NuGet package repository has sample apps for you to deploy ASP.NET Core web apps to both Azure App Service and Azure Container Apps. Clone the repository. Make sure you have the latest version of Azure CLI, Azure Bicep CLI and Azure Developer CLI. Login to Azure by running the azd auth login command. Deploy the sample apps by running azd up command. You might be asked to provide both Client ID and Client Secret values of a GitHub OAuth app. If you don't have it, leave them blank. Apply NuGet Package to Web App The example uses a Blazor web app, but the same approach applies to any ASP.NET Core web application. Microsoft Entra ID Add the NuGet package to your Blazor application. dotnet add package Aliencube.Azure.Extensions.EasyAuth.EntraID NOTE: At the time of writing, it's still in preview. Therefore, use the --prerelease tag at the end of the command like dotnet add package Aliencube.Azure.Extensions.EasyAuth.EntraID --prerelease . Open the Program.cs file and find the code line, var app = builder.Build(); . Then, add dependencies for authentication and authorisation. // 👇👇👇 Add dependencies for authentication/authorisation builder.Services.AddAuthentication(EasyAuthAuthenticationScheme.Name) .AddAzureEasyAuthHandler<EntraIDEasyAuthAuthenticationHandler>(); builder.Services.AddAuthorization(); // 👆👆👆 Add dependencies for authentication/authorisation var app = builder.Build(); In the same Program.cs file and find the code line, app.Run(); . Then activate authentication and authorisation. // 👇👇👇 Activate authentication/authorisation app.UseAuthentication(); app.UseAuthorization(); // 👆👆👆 Activate authentication/authorisation app.Run(); Apply the Authorize attribute to a specific page component. PAGE "/random-page-url" @* 👇👇👇 Apply authorisation *@ @using Aliencube.Azure.Extensions.EasyAuth @using Microsoft.AspNetCore.Authorization @attribute [Authorize(AuthenticationSchemes = EasyAuthAuthenticationScheme.Name)] @* 👆👆👆 Apply authorisation *@ Deploy the app to either Azure App Service or Azure Container Apps. After deployment, configure the authentication settings like: Open your web browser and navigate the page component you applied authorisation, and see the 401 (Unauthorized) error. Sign into the web app through /.auth/login/aad and visite the page again, and verify you're able to see the content on that page. GitHub OAuth It's mostly the same as using Microsoft Entra ID, except using a different NuGet package. Install the GitHub-specific NuGet package. dotnet add package Aliencube.Azure.Extensions.EasyAuth.GitHub NOTE: At the time of writing, it's still in preview. Therefore, use the --prerelease tag at the end of the command like dotnet add package Aliencube.Azure.Extensions.EasyAuth.GitHub --prerelease . Open the Program.cs file and find the code line, var app = builder.Build(); . Then, add dependencies for authentication and authorisation. Make sure this time you use GitHubEasyAuthAuthenticationHandler instead of EntraIDEasyAuthAuthenticationHandler . // 👇👇👇 Add dependencies for authentication/authorisation builder.Services.AddAuthentication(EasyAuthAuthenticationScheme.Name) .AddAzureEasyAuthHandler<GitHubEasyAuthAuthenticationHandler>(); builder.Services.AddAuthorization(); // 👆👆👆 Add dependencies for authentication/authorisation var app = builder.Build(); Follow the same steps as above. How Does It Work? When authenticated through Azure EasyAuth, a request header X-MS-CLIENT-PRINCIPAL is created. It contains a base-64 encoded JSON object, which needs to be decoded and transformed into a ClaimsPrincipal instance for role-based access control. Here's the JSON object. For brevity, most claims are omitted except two. Here's the JSON object generated from Microsoft Entra ID authentication. { "auth_typ": "aad", "name_typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "role_typ": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "claims": [ { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "val": "john.doe@contoso.com" }, { "typ": "roles", "val": "User" } ] } And, here's the JSON object generated from GitHub authentication. { "auth_typ": "github", "name_typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "role_typ": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "claims": [ { "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "val": "John Doe" }, { "typ": "urn:github:type", "val": "User" } ] } This JSON object should be converted into the ClaimsPrincipal instance for granular control on each page. Let's understand the JSON object. auth_typ : It indicates the authentication method currently used. For example, Microsoft Entra ID says aad and GitHub says github . name_typ : After the authentication, the claim with this key is bound to HttpContext.User.Identity.Name . role_typ : They claim key for authorisation by roles. claims : A collection of claims generated by either Microsoft Entra ID or GitHub. But the challenge on the X-MS-CLIENT-PRINCIPAL token is that it has no role claims matching to the role_typ key. The Entra ID one contains the roles claim and GitHub one contains the urn:github:type claim, which is not following the OpenID Connect standard, while ClaimsPrincipal object on ASP.NET Core web apps do follow the standard. The NuGet packages above convert the role values. By adding and activating the conversion handler, users are now able to login to the web app with EasyAuth and access to certain pages with proper permissions. Here's the example that uses the AuthenticationSchemes property to let users access to pages as long as they sign in with EasyAuth. PAGE "/random-page-url" @attribute [Authorize(AuthenticationSchemes = EasyAuthAuthenticationScheme.Name)] This is another example that uses the Roles property to let users having the User permission to access to the given page. PAGE "/random-page-url" @attribute [Authorize(Roles = "User")] NOTE: Make sure that X-MS-CLIENT-PRINCIPAL token from Microsoft Entra ID doesn't contain the roles claims out-of-the-box because it really depends on each tenant's policy. Roadmap Azure EasyAuth supports multiple identity providers, but the NuGet packages currently support Microsoft Entra ID and GitHub OAuth. ✅ Microsoft Entra ID ✅ GitHub ⏹️ OpenID Connect ⏹️ Google ⏹️ Facebook ⏹️ X ⏹️ Apple Contributions are always welcome! So far, we've walked through how to transform Azure EasyAuth authentication token to the ClaimsPrincipal object to be used within ASP.NET Core web apps. With these packages, you can control individual pages based on the users' role and increase apps' security with less efforts. Learn More For further details on Azure EasyAuth, check out: Azure App Service EasyAuth Azure Functions EasyAuth Azure Container Apps EasyAuth Azure Static Web Apps EasyAuth Azure EasyAuth Extensions (Code) Azure EasyAuth Samples (Code)New Features in Azure Container Apps VS Code extension
👆 Install VS Code extension Summary of Major Changes New Managed Identity Support for connecting container apps to container registries. This is now the preferred method for securing these resources, provided you have sufficient privileges. New Container View: Introduced with several commands for easier editing of container images and environment variables. One-Click Deployment: Deploy to Container App... added to the top-level container app node. This supports deployments from a workspace project or container registry. To manage multiple applications in a workspace project or enable faster deployments with saved settings, use Deploy Project from Workspace. It can be accessed via the workspace view. Improved Activity Log Output: All major commands now include improved activity log outputs, making it easier to track and manage your activities. Quickstart Image for Container App Creation: The "Create container app..." command now initializes with a quickstart image, simplifying the setup process. New Commands and Enhancements Managed Identity support for new connections to container registries New command Deploy to Container App... found on the container app item. This one-click deploy command allows deploying from a workspace project or container registry while in single revision mode. New Container view under the container app item allows direct access to the container's image and environment variables. New command Edit Container Image... allows editing of container images without prompting to update environment variables. Environment Variable CRUD Commands: Multiple new commands for creating, reading, updating, and deleting environment variables. Convert Environment Variable to Secret: Quickly turn an environment variable into a container app secret with this new command. Changes and Improvements Command Create Container App... now always starts with a quickstart image. Renamed the Update Container Image... command to Edit Container.... This command is now found on the container item. When running Deploy Project from Workspace..., if remote environment variables conflict with saved settings, prompt for update. Add new envPath option useRemoteConfiguration. Deploying an image with the Docker extension now allows targeting specific revisions and containers. When deploying a new image to a container app, only show ingress prompt when more than the image tag is changed. Improved ACR selection dropdowns, providing better pick recommendations and sorting by resource group. Improved activity log outputs for major commands. Changed draft deploy prompt to be a quick pick instead of a pop-up window. We hope these new features and improvements will simplify deployments and make your Azure Container Apps experience even better. Stay tuned for more updates, and as always, we appreciate your feedback! Try out these new features today and let us know what you think! Your feedback is invaluable in helping us continue to improve and innovate. Azure Container Apps VS Code Extension Full changelog:Azure App Service Logging: How to Monitor Your Web Apps in Real-Time
As a developer, having visibility into the behavior of your applications is crucial to maintaining the reliability and performance of your software. Luckily, Azure App Service provides two powerful logging features to help you monitor your web apps in real-time: App Service Logs and Log Stream. In this blog post, we'll explore how to configure these features for both Windows and Linux Web Apps in Azure App Service.Unlock New AI and Cloud Potential with .NET 9 & Azure: Faster, Smarter, and Built for the Future
.NET 9, now available to developers, marks a significant milestone in the evolution of the .NET platform, pushing the boundaries of performance, cloud-native development, and AI integration. This release, shaped by contributions from over 9,000 community members worldwide, introduces thousands of improvements that set the stage for the future of application development. With seamless integration with Azure and a focus on cloud-native development and AI capabilities, .NET 9 empowers developers to build scalable, intelligent applications with unprecedented ease. Expanding Azure PaaS Support for .NET 9 With the release of .NET 9, a comprehensive range of Azure Platform as a Service (PaaS) offerings now fully support the platform’s new capabilities, including the latest .NET SDK for any Azure developer. This extensive support allows developers to build, deploy, and scale .NET 9 applications with optimal performance and adaptability on Azure. Additionally, developers can access a wealth of architecture references and sample solutions to guide them in creating high-performance .NET 9 applications on Azure’s powerful cloud services: Azure App Service: Run, manage, and scale .NET 9 web applications efficiently. Check out this blog to learn more about what's new in Azure App Service. Azure Functions: Leverage serverless computing to build event-driven .NET 9 applications with improved runtime capabilities. Azure Container Apps: Deploy microservices and containerized .NET 9 workloads with integrated observability. Azure Kubernetes Service (AKS): Run .NET 9 applications in a managed Kubernetes environment with expanded ARM64 support. Azure AI Services and Azure OpenAI Services: Integrate advanced AI and OpenAI capabilities directly into your .NET 9 applications. Azure API Management, Azure Logic Apps, Azure Cognitive Services, and Azure SignalR Service: Ensure seamless integration and scaling for .NET 9 solutions. These services provide developers with a robust platform to build high-performance, scalable, and cloud-native applications while leveraging Azure’s optimized environment for .NET. Streamlined Cloud-Native Development with .NET Aspire .NET Aspire is a game-changer for cloud-native applications, enabling developers to build distributed, production-ready solutions efficiently. Available in preview with .NET 9, Aspire streamlines app development, with cloud efficiency and observability at its core. The latest updates in Aspire include secure defaults, Azure Functions support, and enhanced container management. Key capabilities include: Optimized Azure Integrations: Aspire works seamlessly with Azure, enabling fast deployments, automated scaling, and consistent management of cloud-native applications. Easier Deployments to Azure Container Apps: Designed for containerized environments, .NET Aspire integrates with Azure Container Apps (ACA) to simplify the deployment process. Using the Azure Developer CLI (azd), developers can quickly provision and deploy .NET Aspire projects to ACA, with built-in support for Redis caching, application logging, and scalability. Built-In Observability: A real-time dashboard provides insights into logs, distributed traces, and metrics, enabling local and production monitoring with Azure Monitor. With these capabilities, .NET Aspire allows developers to deploy microservices and containerized applications effortlessly on ACA, streamlining the path from development to production in a fully managed, serverless environment. Integrating AI into .NET: A Seamless Experience In our ongoing effort to empower developers, we’ve made integrating AI into .NET applications simpler than ever. Our strategic partnerships, including collaborations with OpenAI, LlamaIndex, and Qdrant, have enriched the AI ecosystem and strengthened .NET’s capabilities. This year alone, usage of Azure OpenAI services has surged to nearly a billion API calls per month, illustrating the growing impact of AI-powered .NET applications. Real-World AI Solutions with .NET: .NET has been pivotal in driving AI innovations. From internal teams like Microsoft Copilot creating AI experiences with .NET Aspire to tools like GitHub Copilot, developed with .NET to enhance productivity in Visual Studio and VS Code, the platform showcases AI at its best. KPMG Clara is a prime example, developed to enhance audit quality and efficiency for 95,000 auditors worldwide. By leveraging .NET and scaling securely on Azure, KPMG implemented robust AI features aligned with strict industry standards, underscoring .NET and Azure as the backbone for high-performing, scalable AI solutions. Performance Enhancements in .NET 9: Raising the Bar for Azure Workloads .NET 9 introduces substantial performance upgrades with over 7,500 merged pull requests focused on speed and efficiency, ensuring .NET 9 applications run optimally on Azure. These improvements contribute to reduced cloud costs and provide a high-performance experience across Windows, Linux, and macOS. To see how significant these performance gains can be for cloud services, take a look at what past .NET upgrades achieved for Microsoft’s high-scale internal services: Bing achieved a major reduction in startup times, enhanced efficiency, and decreased latency across its high-performance search workflows. Microsoft Teams improved efficiency by 50%, reduced latency by 30–45%, and achieved up to 100% gains in CPU utilization for key services, resulting in faster user interactions. Microsoft Copilot and other AI-powered applications benefited from optimized runtime performance, enabling scalable, high-quality experiences for users. Upgrading to the latest .NET version offers similar benefits for cloud apps, optimizing both performance and cost-efficiency. For more information on updating your applications, check out the .NET Upgrade Assistant. For additional details on ASP.NET Core, .NET MAUI, NuGet, and more enhancements across the .NET platform, check out the full Announcing .NET 9 blog post. Conclusion: Your Path to the Future with .NET 9 and Azure .NET 9 isn’t just an upgrade—it’s a leap forward, combining cutting-edge AI integration, cloud-native development, and unparalleled performance. Paired with Azure’s scalability, these advancements provide a trusted, high-performance foundation for modern applications. Get started by downloading .NET 9 and exploring its features. Leverage .NET Aspire for streamlined cloud-native development, deploy scalable apps with Azure, and embrace new productivity enhancements to build for the future. For additional insights on ASP.NET, .NET MAUI, NuGet, and more, check out the full Announcing .NET 9 blog post. Explore the future of cloud-native and AI development with .NET 9 and Azure—your toolkit for creating the next generation of intelligent applications.Easily deploy .NET apps to Azure Container Apps with default configuration for data protection
The Azure Container Apps and .NET team have made it easier than ever to deploy your .NET application by supporting automatic configuration for data protection. This support is currently available as an opt-in feature in the Container Apps API version 2024-02-02-preview. This blog post will discuss the feature and what it enables, how to determine if your application is correctly configured, and how to enable configuration for data protection across a variety of .NET versions.The Power of Conversational Diagnostics (Public Preview) and Diagnostic Workflows
We are thrilled to introduce our latest innovation: the integration of Conversational Diagnostics (Public Preview) with sophisticated Diagnostic Workflows. This powerful combination makes the diagnostic process both intuitive and efficient. For this announcement we will use an Azure Web App hosted on Linux. The Benefits of Diagnostic Workflows Introduced last year, Diagnostic Workflows empower users to tackle complex problems through an intuitive, tree-like interface. This design helps users navigate different paths to diagnose and solve issues effectively, reducing clutter and focusing on essential diagnostics. By providing clear explanations for each decision path, Diagnostic Workflows facilitate a deeper understanding of the diagnostic process, which is particularly beneficial for new users in ramping up quickly. Diagnostic Workflows are available from Azure Portal under Diagnose and solve problems. Conversational Diagnostics: A New Era Building on the introduction of Conversational Diagnostics (Preview) from last year, we have now combined it with Diagnostic Workflows to create an integrated, natural language-based solution. This system comprehends user intent, selects the appropriate Diagnostic Workflow, and keeps users engaged by providing real-time updates and actionable insights through chat. This transparency helps build user trust and guides them efficiently towards resolving their issues. Finally, Conversational Diagnostics provides the grounded data Generative AI used to produce solutions empowering users to check the conclusions. Exciting Developments Ahead The integration of Conversational Diagnostics and Diagnostic Workflows marks a significant advancement in diagnostic capabilities. We are excited to announce that this feature will be available as part of Ignite 2024, and we welcome your feedback to help us continue improving this experience. Stay tuned for more updates and get ready to experience the transformative power of Generative AI-driven diagnostics firsthand. Thank you!
What's New in Azure App Service at Ignite 2024
Learn about the GA of sidecar extensibility on Linux and see team members demonstrating the latest tools for AI assisted web application migration and modernization as well as the latest updates to Java JBoss EAP on Azure App Service. Team members will also demonstrate integrating the Phi-3 small language model with a web application via the new sidecar extensibility using existing App Service hardware! Also new for this year’s Ignite, many topics that attendees see in App Service related sessions are also available for hands-on learning across multiple hands-on labs (HoLs). Don’t just watch team members demonstrating concepts on-stage, drop by one of the many HoL sessions and test drive the functionality yourself! Azure App Service team members will also be in attendance at the Expert Meetup area on the third floor in the Hub – drop by and chat if you are attending in-person! Additional demos, presentations and hands-on labs covering App Service are listed at the end of this blog post for easy reference. Sidecar Extensibility GA for Azure App Service on Linux Sidecar extensibility for Azure App Service on Linux is now GA! Linux applications deployed from source-code as well as applications deployed using custom containers can take advantage of sidecar extensibility. Sidecars enable developers to attach additional capabilities like third-party application monitoring providers, in-memory caches, or even local SLM (small language model) support to their applications without having to bake that functionality directly into their applications. Developers can configure up to four sidecar containers per application, with each sidecar being associated with its own container registry and (optional) startup command. Examples of configuring an OpenTelemetry collector sidecar are available in the documentation for both container-based applications and source-code based applications. There are also several recent blog posts demonstrating additional sidecar scenarios. One example walks through using a Redis cache sidecar as an in-memory cache to accelerate data retrieval in a web application (sample code here). Another example demonstrates adding a sidecar containing the Phi-3 SLM to a custom container web application (sample code here). Once the web app is running with the SLM sidecar, Phi-3 processes text prompts directly on the web server without the need to call remote LLMs or host models on scarce GPU hardware. Similar examples for source deployed applications are available in the Ignite 2024 hands on lab demonstrating sidecars. Exercise three walks through attaching an OTel sidecar to a source-code based application, and exercise four shows how to attach a Phi-3 sidecar to a source-code based application. Looking ahead to the future, App Service will be adding “curated sidecars” to the platform to make it easier for developers to integrate common sidecar scenarios. Development is already underway to include options for popular third-party application monitoring providers, Redis cache support, as well as a curated sidecar encapsulating the Phi-3 SLM example mentioned earlier. Stay tuned for these enhancements in the future! If you are attending Microsoft Ignite 2024 in person, drop by the theater session “Modernize your apps with AI without completely rewriting your code” (session code: THR 614) which demonstrates using sidecar extensibility to add Open Telemetry monitoring as well as Phi-3 SLM support to applications on App Service for Linux! .NET 9 GA, JBoss EAP and More Language Updates! With the recent GA of .NET 9 last week developers can deploy applications running .NET 9 GA on both Windows and Linux variants of App Service! Visual Studio, Visual Studio Code, Azure DevOps and GitHub Actions all support building and deploying .NET 9 applications onto App Service. Start a new project using .NET 9 or upgrade your existing .NET applications in-place and take advantage of .NET 9! For JBoss EAP on App Service for Linux, customers will soon be able to bring their existing JBoss licenses with them when moving JBoss EAP workloads onto App Service for Linux. This change will make it easier and more cost effective than ever for JBoss EAP customers to migrate existing workloads to App Service, including JBoss versions 7.3, 7.4 and 8.0! As a quick reminder, last month App Service also announced reduced pricing for JBoss EAP licenses (for net-new workloads) as well as expanded hardware support (both memory-optimized and Free tier are now supported for JBoss EAP applications). App Service is planning to release both Node 22 and Python 3.13 onto App Service for Linux with expected availability in December! Python 3.13 is the latest stable Python release which means developers will be able to leverage this version with confidence given long term support runs into 2029. Node 22 is the latest active LTS release of Node and is a great version for developers to adopt with its long-term support lasting into 2026. A special note for Linux Python developers, App Service now supports “auto-instrumentation” in public preview for Python versions 3.8 through 3.12. This makes it trivial for source-code based Python applications to enable Application Insights monitoring for their applications by simply turning the feature “on” in the Azure Portal. If you ever thought to yourself that it can be a hassle setting up application monitoring and hence find yourself procrastinating, this is the monitoring feature for you! Looking ahead just a few short weeks until December, App Service also plans to release PHP 8.4 for developers on App Service for Linux. This will enable PHP developers to leverage the latest fully supported PHP release with an expected support cycle stretching into 2028. For WordPress customers Azure App Service has added support for managed identities when connecting to MySQL database as well as storage accounts. The platform has also transitioned WordPress from Alpine Linux to Debian, aligning with App Service for Linux to offer a more secure platform. Looking ahead, App Service is excited to introduce some new features by the end of the year, including an App Service plugin for WordPress! This plugin will enable users to manage WordPress integration with Azure Communication Services email, set up Single Sign-On using Microsoft Entra ID, and diagnose performance bottlenecks. Stay tuned for upcoming WordPress announcements! End-to-End TLS & Min TLS Cipher Suite are now GA End-to-end TLS encryption for public multi-tenant App Service is now GA! When E2E TLS is configured, traffic between the App Service frontends and individual workers is secured using a platform supplied TLS certificate. This additional level of security is available for both Windows and Linux sites using Standard SKU and above as well as Isolatedv2 SKUs. You can enable this feature easily in the Azure Portal by going to your resource, clicking the “Configuration” blade and turning the feature “On” as shown below: Configuration of the minimum TLS cipher suite for a web application is also GA! With this feature developers can choose from a pre-determined list of cipher suites. When a minimum cipher suite is selected, the App Service frontends will reject any incoming requests that use a cipher suite weaker than the selected minimum cipher suite. This feature is supported for both Windows and Linux applications using Basic SKU and higher as well as Isolatedv2 SKUs. You configure a minimum TLS cipher suite in the Azure Portal by going to the “Configuration” blade for a website and selecting “Change” for the Minimum Inbound TLS Cipher Suite setting. In the resulting blade (shown below) you can select the minimum cipher suite for your application: To learn more about these and other TLS features on App Service, please refer to the App Service TLS overview. AI-Powered Conversational Diagnostics Building on the Conversational Diagnostics AI-powered tool and the guided decision making path introduced in Diagnostic Workflows, the team has created a new AI-driven natural language-based diagnostics solution for App Service on Linux. The new solution brings together previous functionality to create an experience that comprehends user intent, selects the appropriate Diagnostic Workflow, and keeps users engaged by providing real-time updates and actionable insights through chat. Conversational Diagnostics also provides the grounding data that the generative AI back-end uses to produce recommendations thus empowering users to check the conclusions. The integration of Conversational Diagnostics and Diagnostic Workflows marks a significant advancement in the platform’s diagnostic capabilities. Stay tuned for more updates and experience the transformative power of Generative AI-driven diagnostics firsthand! App Service Migration and Modernization The team just recently introduced new architectural guidance around evolving and modernizing web applications with the Modern Web Application pattern for .NET and Java! This guidance builds on the Reliable Web App pattern for .NET and Java as well as the Azure Migrate application and code assessment tool. With the newly released Modern Web Application guidance, there is a well-documented path for migrating web applications from on-premises/VM deployments using the application and code assessment tool, iterating and evolving web applications with best practices using guidance from the Reliable Web App pattern, and subsequently going deeper on modernization and re-factoring following guidance from the Modern Web Application pattern. Best of all customers can choose to “enter” this journey at any point and progress as far down the modernization path as needed based on their unique business and technical requirements! As a quick recap on the code assessment tool, it is a guided experience inside of Visual Studio with GitHub Copilot providing actionable guidance and feedback on recommended changes needed to migrate applications to a variety of Azure services including Azure App Service. Combined with AI-powered Conversational Diagnostics (mentioned earlier), developers now have AI-guided journeys supporting them from migration all the way through deployment and runtime operation on App Service! Networking and ASE Updates As of November 1, 2024, we are excited to announce that App Service multi-plan subnet join is generally available across all public Azure regions! Multi-plan subnet join eases network management by reducing subnet sprawl, enabling developers to connect multiple app service plans to a single subnet. There is no limit to the number of app service plans that connect to a single subnet. However, developers should keep in mind the number of available IPs since tasks such as changing the SKU for an app service plan will temporarily double the number of IP addresses used in a connected subnet. For more information as well as examples on using multi-plan subnet join see the documentation! App Service also recently announced GA of memory optimized options for Isolatedv2 on App Service Environment v3. The new memory-optimized options range from two virtual cores with 16 GB RAM in I1mv2 (compared to two virtual cores, 8 GB RAM in I1v2) all the way up to 32 virtual cores with 256 GB RAM in I5mv2. The new plans are available in most regions. Check back regularly to see if your preferred region is supported. For more details on the technical specifications of these plans, as well as information on the complete range of tiers and plans for Microsoft Azure App Service, visit our pricing page. Using services such as Application Gateway and Azure Front Door with App Service as entry points for client traffic is a common scenario that many of our customers implement. However, when using these services together, there are integration challenges around the default cookie domain for HTTP cookies, including the ARRAffinity cookie used for session affinity. App Service collaborated with the Application Gateway team to introduce a simple solution that addresses the session affinity problem. App Service introduced a new session affinity proxy configuration setting in October which tells App Service to always set the hostname for outbound cookies based on the upstream hostname seen by Application Gateway or Azure Front Door. This simplifies integration with a single-click experience for App Service developers who front-end their websites using one of Azure’s reverse proxies, and it solves the challenge of round-tripping the ArrAffinity cookie when upstream proxies are involved. Looking ahead to early 2025, App Service will shortly be expanding support for IPv6 to include both inbound and outbound connections (currently only inbound connections are supported). The current public preview includes dual-stack support for both IPv4 and IPv6, allowing for a smooth transition and compatibility with existing systems. Read more about the latest status of the IPv6 public preview on App Service here ! Lastly, the new application naming and hostname convention that was rolled out a few months earlier for App Service is now GA for App Service. The platform has also extended this new naming convention to Azure Functions where it is now available in public preview for newly created functions. To learn more about the new naming convention and the protection it provides against subdomain takeover take a look at the introductory blog post about the unique default hostname feature. Upcoming Availability Zone Improvements New Availability Zone features are currently rolling out that will make zone redundant App Service deployments more cost efficient and simpler to manage in early 2025! The platform will be changing the minimum requirement for enabling Availability Zones to two instances instead of three, while still maintaining a 99.99% SLA. Many existing app service plans with two or more instances will also automatically become capable of supporting Availability Zones without requiring additional setup. Additionally, the zone redundant setting will be mutable throughout the life of an app service plan. This upcoming improvement will allow customers on Premium V2, Premium V3, or Isolated V2 plans, to toggle zone redundancy on or off as needed. Customers will also gain enhanced visibility into Availability Zone information, including physical zone placement and counts. As a sneak peek into the future, the screenshot below shows what the new experience will look like in the Azure Portal: Stay tuned for Availability Zone updates coming to App Service in early 2025! Next Steps Developers can learn more about Azure App Service at Getting Started with Azure App Service. Stay up to date on new features and innovations on Azure App Service via Azure Updates as well as the Azure App Service (@AzAppService) X feed. There is always a steady stream of great deep-dive technical articles about App Service as well as the breadth of developer focused Azure services over on the Apps on Azure blog. Azure App Service (virtually!) attended the recently completed November .Net Conf 2024. App Service functionality was featured showing a .NET 9.0 app using Azure Sql’s recently released native vector data type support that enables developers to perform hybrid text searches on Azure Sql data using vectors generated via Azure OpenAI embeddings! And lastly take a look at Azure App Service Community Standups hosted on the Microsoft Azure Developers YouTube channel. The Azure App Service Community Standup series regularly features walkthroughs of new and upcoming features from folks that work directly on the product! Ignite 2024 Session Reference (Note: some sessions/labs have more than one timeslot spanning multiple days). (Note: all times below are listed in Chicago time - Central Standard Time). Modernize your apps with AI without completely rewriting your code Modernize your apps with AI without completely rewriting your code [Note: this session includes a demonstration of the Phi-3 sidecar scenario] Wednesday, November 20 th 1:00 PM - 1:30 PM Central Standard Time Theater Session – In-Person Only (THR614) McCormick Place West Building – Level 3, Hub, Theater C Unlock AI: Assess your app and data estate for AI-powered innovation Unlock AI: Assess your app and data estate for AI-powered innovation Wednesday, November 20 th 1:15 PM – 2:00 PM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK137) Modernize and scale enterprise Java applications on Azure Modernize and scale enterprise Java applications on Azure Thursday, November 21 st 8:30 AM - 9:15 AM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK147) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Tuesday, November 19 th 1:15 PM - 2:30 PM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB408) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Wednesday, November 20 th 8:30 AM - 9:45 AM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB411) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Wednesday, November 20 th 6:30 PM - 7:45 PM Central Time McCormick Place West Building – Level 4, Room W470b Hands on Lab – In-Person Only (LAB408-R1) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Thursday, November 21 st 10:15 AM - 11:30 AM Central Time McCormick Place West Building – Level 1, Room W180 Hands on Lab – In-Person Only (LAB411-R1) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Friday, November 22 nd 9:00 AM – 10:15 AM Central Time McCormick Place West Building – Level 4, Room W474 Hands on Lab – In-Person Only (LAB408-R2)
