Azure CNI Overlay for Application Gateway for Containers and Application Gateway Ingress Controller
What are Azure CNI Overlay and Application Gateway? Azure CNI Overlay leverages logical network spaces for pod IP assignment management (IPAM). This provides enhanced IP scalability with reduced management responsibilities. Application Gateway for Containers is the latest and most recommended container L7 load-balancing solution. It introduces a new scalable control plane and data plane to address the performance demands and modern workloads being deployed to AKS clusters on Azure. Azure network control plane configures routing between Application Gateway and overlay pods. Why is the feature needed? As businesses increasingly use containerized solutions, managing container networks at scale has become a priority. Within container network management, IP address exhaustion, scalability and application load balancing performance are highly requested and discussed in many forums. Azure CNI Overlay is the default container networking IPAM mode on AKS. In the overlay design, AKS nodes use IPs from Azure virtual network (VNet) IP address range and pods are addressed from an overlay IP address range. The overlay pods can communicate with each other directly via a different routing domain. Overlay IP addresses can be reused across multiple clusters in the same VNet, provisioning a solution for IP exhaustion and increasing IP scale to over 1M. Azure CNI Overlay supporting Application Gateway for Containers provides customers with a more performant, reliable, and scalable container networking solution. Meanwhile, Azure CNI Overlay supporting AGIC provides customers with full feature parity if they choose to upgrade AKS clusters from kubenet to Azure CNI Overlay. Key Benefits High scale with Azure CNI Overlay combined with a high-performance ingress solution Azure CNI Overlay provides direct pod to pod routing with high IP scale using direct azure native routing with no encapsulation overhead. IPs can be reused across clusters in the same VNET allowing customers to conserve IP addresses. Application Gateway for Containers is the latest and most recommended container L7 load-balancing solution. Installing Application Gateway for Containers on AKS clusters with Azure CNI Overlay provides customers with the best solution combination of IP scalability and ingress solution on Azure. Feature parity between kubenet and Azure CNI Overlay With the retirement announcement of kubenet, we expect to see customers upgrade their AKS container networking solution from kubenet to Azure CNI Overlay soon. This feature allows customers to maintain business continuity during the transitioning process. Learn More Read more about Azure CNI Overlay and Application Gateway for Containers. Learn more on how to upgrade AKS clusters’ IPAM to Azure CNI Overlay. Learn more about Azure Kubernetes Service and Application Gateway.Unlock enterprise AI/ML with confidence: Azure Application Gateway as your scalable AI access layer
As enterprises accelerate their adoption of generative AI and machine learning to transform operations, enhance productivity, and deliver smarter customer experiences, Microsoft Azure has emerged as a leading platform for hosting and scaling intelligent applications. With offerings like Azure OpenAI, Azure Machine Learning, and Cognitive Services, organizations are building copilots, virtual agents, recommendation engines, and advanced analytics platforms that push the boundaries of what is possible. However, scaling these applications to serve global users introduces new complexities: latency, traffic bursts, backend rate limits, quota distribution, and regional failovers must all be managed effectively to ensure seamless user experiences and resilient architectures. Azure Application Gateway: The AI access layer Azure Application Gateway plays a foundational role in enabling AI/ML at scale by acting as a high-performance Layer 7 reverse proxy—built to intelligently route, protect, and optimize traffic between clients and AI services. Hundreds of enterprise customers are already using Azure Application Gateway to efficiently manage traffic across diverse Azure-hosted AI/ML models—ensuring uptime, performance, and security at global scale. The AI delivery challenge Inferencing against AI/ML backends is more than connecting to a service. It is about doing so: Reliably: across regions, regardless of load conditions Securely: protecting access from bad actors and abusive patterns Efficiently: minimizing latency and request cost Scalable: handling bursts and high concurrency without errors Observably: with real-time insights, diagnostics, and feedback loops for proactive tuning Key features of Azure Application Gateway for AI traffic Smart request distribution: Path-based and round-robin routing across OpenAI and ML endpoints. Built-in health probes: Automatically bypass unhealthy endpoints Security enforcement: With WAF, TLS offload, and mTLS to protect sensitive AI/ML workloads Unified endpoint: Expose a single endpoint for clients; manage complexity internally. Observability: Full diagnostics, logs, and metrics for traffic and routing visibility. Smart rewrite rules: Append path, or rewrite headers per policy. Horizontal scalability: Easily scale to handle surges in demand by distributing load across multiple regions, instances, or models. SSE and real-time streaming: Optimize connection handling and buffering to enable seamless AI response streaming. Azure Web Application Firewall (WAF) Protections for AI/ML Workloads When deploying AI/ML workloads, especially those exposed via APIs, model endpoints, or interactive web apps, security is as critical as performance. A modern WAF helps protect not just the application, but also the sensitive models, training data, and inference pipelines behind it. Core Protections: SQL injection – Prevents malicious database queries targeting training datasets, metadata stores, or experiment tracking systems. Cross-site scripting (XSS) – Blocks injected scripts that could compromise AI dashboards, model monitoring tools, or annotation platforms. Malformed payloads – Stops corrupted or adversarial crafted inputs designed to break parsing logic or exploit model pre/post-processing pipelines. Bot protections – Bot Protection Rule Set detects & blocks known malicious bot patterns (credential stuffing, password spraying). Block traffic based on request body size, HTTP headers, IP addresses, or geolocation to prevent oversized payloads or region-specific attacks on model APIs. Enforce header requirements to ensure only authorized clients can access model inference or fine-tuning endpoints. Rate limiting based on IP, headers, or user agent to prevent inference overloads, cost spikes, or denial of service against AI models. By integrating these WAF protections, AI/ML workloads can be shielded from both conventional web threats and emerging AI-specific attack vectors, ensuring models remain accurate, reliable, and secure. Architecture Real-world architectures with Azure Application Gateway Industries across sectors rely on Azure Application Gateway to securely expose AI and ML workloads: Healthcare → Protecting patient-facing copilots and clinical decision support tools with HIPAA-compliant routing, private inference endpoints, and strict access control. Finance → Safeguarding trading assistants, fraud-detection APIs, and customer chatbots with enterprise WAF rules, rate limiting, and region-specific compliance. Retail & eCommerce → Defending product recommendation engines, conversational shopping copilots, and personalization APIs from scraping and automated abuse. Manufacturing & industrial IoT → Securing AI-driven quality control, predictive maintenance APIs, and digital twin interfaces with private routing and bot protection. Education → Hosting learning copilots and tutoring assistants safely behind WAF, preventing misuse while scaling access for students and researchers. Public sector & government → Enforcing FIPS-compliant TLS, private routing, and zero-trust controls for citizen services and AI-powered case management. Telecommunications & media → Protecting inference endpoints powering real-time translation, content moderation, and media recommendations at scale. Energy & utilities → Safeguarding smart grid analytics, sustainability dashboards, and AI-powered forecasting models through secure gateway routing. Advanced integrations Position Azure Application Gateway as the secure, scalable network entry point to your AI infrastructure Private-only Azure Application Gateway: Host AI endpoints entirely within virtual networks for secure internal access SSE support: Configure HTTP settings for streaming completions via Server-Sent Events Azure Application Gateway+ Azure Functions: Build adaptive policies that reroute traffic based on usage, cost, or time of day Azure Application Gateway + API management to protect OpenAI workloads What’s next: Adaptive AI gateways Microsoft is evolving Azure Application Gateway into a more intelligent, AI aware platform with capabilities such as: Auto rerouting to healthy endpoints or more cost-efficient models. Dynamic token management directly within Azure Application Gateway to optimize AI inference usage. Integrated feedback loops with Azure Monitor and Log Analytics for real-time performance tuning. The goal is to transform Azure Application Gateway from a traditional traffic manager into an adaptive inference orchestrator one that predicts failures, optimizes operational costs, and safeguards AI workloads from misuse. Conclusion Azure Application Gateway is not just a load balancer—it’s becoming a critical enabler for enterprise-grade AI delivery. Today, it delivers smart routing, security enforcement, adaptive observability, and a compliance-ready architecture, enabling organizations to scale AI confidently while safeguarding performance and cost. Looking ahead, Microsoft’s vision includes future capabilities such as quota resiliency to intelligently manage and balance AI usage limits, auto-rerouting to healthy endpoints or more cost-efficient models, dynamic token management within Azure Application Gateway to optimize inference usage, and integrated feedback loops with Azure Monitor and Log Analytics for real-time performance tuning. Together, these advancements will transform Azure Application Gateway from a traditional traffic manager into an adaptive inference orchestrator capable of anticipating failures, optimizing costs, and protecting AI workloads from misuse. If you’re building with Azure OpenAI, Machine Learning, or Cognitive Services, let Azure Application Gateway be your intelligent command center—anticipating needs, adapting in real time, and orchestrating every interaction so your AI can deliver with precision, security, and limitless scale. For more information, please visit: What is Azure Application Gateway v2? | Microsoft Learn What Is Azure Web Application Firewall on Azure Application Gateway? | Microsoft Learn Azure Application Gateway URL-based content routing overview | Microsoft Learn Using Server-sent events with Application Gateway (Preview) | Microsoft Learn AI Architecture Design - Azure Architecture Center | Microsoft Learn
Decoding On-Premises ADC Rules: Migration to Azure Application Gateway
Overview As Azure Application Gateway evolves, many organizations are considering how their existing on-premises solutions—such as F5, NetScaler, and Radware—can transition to leverage Azure’s native services. During this shift to cloud-native architecture, a frequent question arises: ‘Can Application Gateway support my current load balancing configurations?’” The short answer: It depends on your use case. With the right approach, the transition can be smooth, scalable, and secure. Azure Application Gateway, especially when used with Azure-native services like Web Application Firewall (WAF), Azure Front Door, and Azure Firewall, can support common use cases. This guide provides a functional comparison, outlines what’s supported and offers a blueprint for successful migration. Key Capabilities of Application Gateway Azure Application Gateway v2 brings a host of enhancements that align with the needs of modern, cloud-first organizations: Autoscaling & Zone Redundancy Native WAF + Azure DDoS Protection Native support for Header Rewrites, URL-based routing, and SSL termination Integration with Azure Monitor, Log Analytics, Defender for Cloud Azure-native deployment: ARM/Bicep, CLI, GitOps, Terraform, CI/CD These features make App Gateway a strong option for cloud-first and hybrid scenarios, especially for cloud-first and hybrid scenarios. customers benefit from simplified operations, improved agility, and enhanced security. What are ADC Rules? On-premises ADCs (Application Delivery Controllers) often include advanced traffic management features, such as iRules and Citrix policy expressions. These Layer 4–7 devices go beyond basic load balancing, enabling traffic manipulation at various stages of the connection lifecycle. ADCs are powerful, flexible, and often deeply embedded in enterprise traffic logic. If you rely on these features, migration is still possible—Azure Application Gateway supports many commonly used functionalities out of the box. Common ADCs scenarios: Redirects and rewrites IP filtering and geo-blocking Custom error handling Event-driven logic like HTTP_REQUEST, CLIENT_ACCEPTED Application Gateway Feature Patterns ADCs traffic management features are powerful and flexible, often deeply embedded in enterprise traffic flows. Application Gateway does provide native support for many common scenarios. In this guide, we’ll show you how to translate advanced rules typical patterns into configurations. [Note]: When migrating WAF rules, enable detection mode first to identify false positives before enforcing blocks Citrix Features iRule Feature App Gateway v2 Equivalent Supported for App Gateway? Responder Policies Redirects (301/302) Native redirect rules ✅ Rewrite Policies Header rewrites Rewrite Set rules ✅ GSLB + Responder Policies Geo-based Routing Combining with Azure Front Door ✅ Content Switching Policies URL-based routing Path-based routing rules ✅ Responder/ACLs IP filtering WAF custom rules or NSGs ✅ GSLB + Policy Expressions Geo-blocking WAF rules ✅ Content Switching Policies Path-based routing URL path maps ✅ Content Switching / Rewrite Policies Header-based Routing Limited with parameter-based path selection ➗ Advanced Policy Expressions (Regex supported) Regex-based routing Limited regex support via path parameters ➗ Priority Queues / Rate Control Real-time traffic shaping Limited with Azure Front Door ➗ AppExpert with TCP expressions TCP payload inspection Not supported ❌ Not supported Event-driven hooks (HTTP_REQUEST, etc) Not supported ❌ Not Supported Query Pool Not supported ❌ Not supported Per-request scripting Not supported ❌ Deep packet inspection + Policies (limited) Payload-based routing Not supported ❌ Not supported Full scripting (TCL) Not supported ❌ Translating Advanced Rules Migrating features such as iRules and Citrix policy expressions from ADCs is less about line-by-line translation and more about recognizing patterns. Think of it as translating a language—not word-for-word, but intent-for-intent. How to get started: Tool-assisted translation: Use Copilot or GPT-based tools to translate common ADC rule patterns. Inventory & analyze: Break complex rules into modular App Gateway functions (Redirects, Rewrites) Document: Document everything of original goal and their translated equivalents. Where to Configure in Azure You can implement routing and rewrite logic via: Azure portal UI Azure CLI / PowerShell (az network application-gateway) ARM templates / Bicep (for infrastructure-as-code deployments) REST API (for automation/CI-CD pipelines) Example: Configure header rewrite in the portal Open your Application Gateway in the Azure portal Navigate to Rewrites on the sidebar Click + Add Rewrite Set, then apply it to your routing rule Define your rewrite conditions and actions [NOTE]: Not sure what rewrites are? Learn more here about Rewrite HTTP Headers. Rewrite configuration: click + Add Rewrite set to apply a new Rewrite to your routing rule: Resources Application Gateway v1 to v2: Migrate from App Gateway v1 to v2 Best Practices: Architecture Best Practices for Azure Application Gateway v2 - Microsoft Azure Well-Architected Framework | Microsoft Learn Rewrites: https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url Header-based routing: https://learn.microsoft.com/en-us/azure/application-gateway/parameter-based-path-selection-portal Tuning WAF rules: Tune Azure Web Application Firewall for Azure Front Door | Microsoft Learn Conclusion While AI-powered assistants can help interpret and translate common ADC traffic management patterns, manual recreation and validation of rules are still necessary to ensure accuracy and alignment with your specific requirements. Nevertheless, migrating to Application Gateway v2 is not only feasible—it represents a strategic move toward a modern, cloud-native infrastructure. With thoughtful planning and the right mindset, organizations can maintain traffic flexibility while gaining the agility, scalability, and operational efficiency of the Azure ecosystem. If you are unsure whether your current on-premises configuration can be supported in Azure Application Gateway, please consult the official Azure documentation or reach out to Microsoft support for guidance.
Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.Understanding Azure App Service Authentication Challenges with Path-Based Routing
Host-Based vs Path-Based Routing Firstly, it's important to understand that path-based routing is not the only option. When building web applications, ensuring users can access the right content efficiently is crucial. One of the most important decisions in structuring web traffic is choosing between host-based and path-based routing. Both approaches can be used to determine how incoming requests are directed to different parts of your application(s). So why does this matter when configuring authentication? In modern authentication flows, the identity provider redirects users after successful login to what is known as a callback URL. This URL needs to be correctly configured both in your app’s settings and in the identity provider’s configuration to ensure the authentication flow completes properly. A mismatch or misconfiguration of the callback URL can break the authentication process, causing redirect errors or security issues. With that in mind, lets looks at each approach in more detail. Host-Based Routing Host-based routing is often the preferred choice when each app has distinct requirements or independent functionality. In this approach, each application is assigned a separate hostname or subdomain (e.g., https://app1.domain.com and https://app2.domain.com), meaning each application behind the App Gateway can maintain unique authentication configurations without conflicting callback paths. Path-Based Routing Path-based routing, however, is often used when the apps or services are related and need to share a common base URL. Examples include, sites with shared authentication or endpoints that are part of the same application. In these cases, path-based routing may be preferable, but more nuanced scenarios will require careful configuration to ensure authentication flows work as expected. Challenges include: Callback URLs must match the configuration in the Azure App Registration and authentication settings. Host Headers might be overridden or mismatched due to reverse proxy settings, leading to unexpected redirects. Path-based routing rules require careful configuration to avoid conflicts, particularly with wildcard entries or overlapping path patterns. Important From this point forward, this write-up highlights the particular challenge of handling a mix of authenticated and anonymous apps under a single domain using Azure App Gateway and App Service. App Service Authentication options with Path-Based Routing The diagram above illustrates a scenario where path-based routing was selected to facilitate rapid deployment of automated environments in an attempt to minimise domain and certificate management overhead. Here, multiple apps with varying authentication requirements—one requiring authentication and another allowing anonymous access—share an App Service plan to optimise costs. Authentication can be handled using two options: easy auth and code-based authentication. In both options, the default App Service hostname is used to avoid domain conflicts. This is because you cannot configure the same custom domain for multiple App Services. See Azure’s documentation for more information. Warning Not using a custom domain on the App Service backend goes against general best practice. If you choose to experiment with using the default app service hostname instead of a customer domain, be sure to review the Azure’s host name preservation guide to verify the impact. Lets look at the two options shown in the diagram. Option 1: Easy Auth with Host Header Override Using Azure App Service’s Easy Auth with path-based routing requires configuring the host headers and authentication settings to ensure that requests respect the path and route configurations. Note: The guidance below assumes you have an existing Azure App Service with easy auth enabled and an Azure Application Gateway set up with path-based routing rules. Configuration: App Gateway Configuration: Set up the backend HTTP setting in App Gateway to pick the hostname from the backend target. This uses the default App Service hostname to avoid domain conflicts. App Registration Callback URL: Ensure the app registration includes the correct callback URL, including the path (e.g., https://yourdomain.com/yourpath/.auth/login/aad/callback). Easy Auth Configuration (auth.json): When using App Service Easy Auth behind Application Gateway, authentication redirects default to the app's Azure domain, often causing errors. To fix this, configure Easy Auth to read the X-Original-Host header from Application Gateway using file-based configuration as described in Azure’s documentation. The documentation describes how you can create a file called auth.json to override the behaviour of App Service Authentication / Authorization for that site After creating the auth.json file, ensure you update it to define the required HTTP settings shown below: "httpSettings": { "requireHttps": true, "routes": { "apiPrefix": "/YOUR_APP_PATH/.auth" }, "forwardProxy": { "convention": "Custom", "customHostHeaderName": "X-Original-Host" } } If issues persist, refer to the configuration file reference and ensure you have the correct configuration for your scenario. For example, adding a value for "allowedExternalRedirectUrls" to include https://YOURDOMAIN.com/YOURPATH. Finally, make sure your app is configured to accept requests at the specified path. For Windows App Services, this can be done by mapping a virtual directory to the path. For Linux, this can be done by updating the app routes in your code. Note One aspect that's not well-documented is the impact of the apiPrefix setting within file-based configuration. Without setting this value, Easy Auth will redirect to the root domain, disregarding your path-based routing configuration. To ensure correct routing, modify the apiPrefix value to match your app's path, as shown in the auth.json example above. Option 2: Code-Based Authentication with Host Header Override For scenarios requiring more flexibility, implementing custom authentication within the app code can be beneficial. This allows for handling authentication requests programmatically, which can help with maintaining control over redirect paths and headers. With this approach the user can also be presented with a custom login page before accessing the app. Note: The guidance below assumes you have an existing Azure App Service and an Azure Application Gateway set up with path-based routing rules. Configuration: Set up Authentication in Code: Configure your app to authenticate users using a code-based approach with Microsoft Entra ID. Refer to the Quickstart for Python Flask web app to set up authentication with a sample app. App Registration Adjustments: Ensure the redirect URI in the app registration matches that of your app hostname and path. For the quickstart this will be 'https://YOURDOMAIN.COM/YOURPATH/getAToken' Path-Based Routing Adjustments: Update the app routes in app.py to ensure your app responds to the path set in App Gateway. Each route must be configured to accept requests at the specified path (e.g., @app.route("/YOURPATH")). Define the REDIRECT_PATH in app_config.py with the format /YOURPATH/getAToken. Deployment: Deploy the app to your Azure App Service using your CI/CD process or the Azure Tools extension in VSCode. Options Summary and Considerations Choosing the right authentication approach depends on your specific requirements, trade-offs, and constraints. Below is a summary of the options discussed, along with key considerations to help ensure a smooth implementation. Approach Pros Cons Easy Auth Minimal app code changes Complex App Service configuration, limited flexibility Code-Based Auth Full control, flexible, login page customisation Dependency on developer skills and code level changes With both options keep the following in mind: Host Headers and Redirect URLs: Ensure that host headers match expected values to prevent redirect mismatches. Callback URL Consistency: Confirm that callback URLs are consistently configured in both App Service and Entra ID to match the path-based routing setup. Avoid Overlapping Paths: Be cautious with wildcard entries in routing (e.g., /app*), which may unintentionally capture routes for other applications. Health Probes: When using App Gateway, configure health probes to target the correct path (e.g., /YOUR_APP_PATH/) and verify that App Service responds correctly. Conclusion While path-based routing enables apps to share a common domain, it does introduce additional authentication complexities that shouldn't be considered lightly when comparing to the additional domain and certificate management of the subdomain approach. Managing callback URLs, host headers, and routing conflicts can complicate authentication workflows, especially when mixing authenticated and anonymous apps. Given these challenges, using host-based routing (with subdomains) is often a simpler and more reliable solution for managing distinct apps. By assigning each app its own subdomain, you can maintain separate authentication configurations, reducing the risk of conflicts and simplifying management. Path-based routing can still be used effectively in scenarios where apps share common authentication requirements, but subdomains offer a more streamlined approach when dealing with varied app needs.Introducing Copilot in Azure for Networking: Your AI-Powered Azure Networking Assistant
As cloud networking grows in complexity, managing and operating these services efficiently can be tedious and time consuming. That’s where Copilot in Azure for Networking steps in, a generative AI tool that simplifies every aspect of network management, making it easier for network administrators to stay on top of their Azure infrastructure. With Copilot, network professionals can design, deploy, and troubleshoot Azure Networking services using a streamlined, AI-powered approach. A Comprehensive Networking Assistant for Azure We’ve designed Copilot to really feel like an intuitive assistant you can talk to just like a colleague. Copilot understands networking-related questions in simple terms and responds with actionable solutions, drawing from Microsoft’s expansive networking knowledge base and the specifics of your unique Azure environment. Think of Copilot as an all-encompassing AI-Powered Azure Networking Assistant. It acts as: Your Cloud Networking Specialist by quickly answering questions about Azure networking services, providing product guidance, and configuration suggestions. Your Cloud Network Architect by helping you select the right network services, architectures, and patterns to connect, secure, and scale your workloads in Azure. Your Cloud Network Engineer by helping you diagnose and troubleshoot network connectivity issues with step-by-step guidance. One of the most powerful features of Copilot in Azure is its ability to automatically diagnose common networking issues. Misconfigurations, connectivity failures, or degraded performance? Copilot can help with step-by-step guidance to resolve these issues quickly with minimal input and assistance from the user, simply ask questions like ”Why can’t my VM connect to the internet?”. As seen above, upon the user identifying the source and destination, Copilot can automatically discover the connectivity path and analyze the state and status of all the network elements in the path to pinpoint issues such as blocked ports, unhealthy network devices, or misconfigured Network Security Groups (NSGs). Technical Deep Dive: Contextualized Responses with Real-Time Insights When users ask a question on the Azure Portal, it gets sent to the Orchestrator. This step is crucial to generating a deep semantic understanding of the user’s question, reasoning over all Azure resources, and then determining that the question requires Network-specific capabilities to be answered. Copilot then collects contextual information based on what the user is looking at and what they have access to before dispatching the question to the relevant domain-specific plugins. Those plugins then use their service-specific capabilities to answer the user’s question. Copilot may even combine information from multiple plugins to provide responses to complex questions. In the case of questions relevant to Azure Networking services, Copilot uses real-time data from sources like diagnostic APIs, user logs, Azure metrics, Azure Resource Graph etc. all while maintaining complete privacy and security and only accessing what the user can access as defined in Azure Role based Access Control (RBAC) to help generate data-driven insights that help keep your network operating smoothly and securely. This information is then used by Copilot to help answer the user’s question via a variety of techniques including but not limited to Retrieval-Augmented Generation (RAG) and grounding. To learn more about how Copilot works, including our Responsible AI commitments, see Copilot in Azure Technical Deep Dive | Microsoft Community Hub. Summary: Key Benefits, Capabilities and Sample Prompts Copilot boosts efficiency by automating routine tasks and offering targeted answers, which saves network administrators time while troubleshooting, configuring and architecting their environments. Copilot also helps organizations reduce costs by minimizing manual work and catching errors while empowering customers to resolve networking issues on their own with AI-powered insights backed by Azure expertise. Copilot is equipped with powerful skills to assist users with network product information and selection, resource inventory and topology, and troubleshooting. For product information, Copilot can answer questions about Azure Networking products by leveraging published documentation, helping users with questions like “What type of Firewall is best suited for my environment?”. It offers tailored guidance for selecting and planning network architectures, including specific services like Azure Load Balancer and Azure Firewall. This guidance also extends to resilience-related questions like “What more can I do to ensure my app gateway is resilient?” involving services such as Azure Application Gateway and Azure Traffic Manager, among others. When it comes to inventory and topology, Copilot can help with questions like “What is the data path between my VM and the internet?” by mapping network resources, visualizing topologies, and tracking traffic paths, providing users with clear topology maps and connectivity graphs. For troubleshooting questions like “Why can’t I connect to my VM from on prem?”, Copilot analyzes both the control plane and data plane, offering diagnostics at the network and individual service levels. By using on-behalf-of RBAC, Copilot maintains secure, authorized access, ensuring users interact only with resources permitted by their access level. Looking Forward: Future Enhancements This is only the first step we are taking toward bringing interactive, generative-AI powered capabilities to Azure Networking services and as it evolves over time, future releases will introduce advanced capabilities. We also acknowledge that today Copilot in preview works better with certain Azure Networking services, and we will continue to onboard more services to the capabilities we are launching today. Some of the more advanced capabilities we are working on include predictive troubleshooting where Copilot will anticipate potential issues before they impact network performance. Network optimization capabilities that suggest ways to optimize your network for better performance, resilience and reliability alongside enhanced security capabilities providing insights into network security and compliance, helping organizations meet regulatory requirements starting with the integration of Security Copilot attack investigation capabilities for Azure Firewall. Conclusion Copilot in Azure for Networking is intended to enhance the overall Azure experience and help network administrators easily manage their Azure Networking services. By combining AI-driven insights with user-friendly interfaces, it empowers networking professionals and users to plan, deploy, and operate their Azure Network. These capabilities are now in preview, see Azure networking capabilities using Microsoft Copilot in Azure (preview) | Microsoft Learn to learn more and get started.QUIC based HTTP/3 with Application Gateway: Feature information Private Preview
Azure Application Gateway now supports HTTP/3 QUIC. As part of private preview, Application Gateway users can create HTTP/3 enabled Listeners which can support either of HTTP/1.1 or HTTP/2 along with HTTP/3. Note: HTTP/3, if enabled on one listener, will be available on that listener only. If some of your clients do not support HTTP/3, there’s no panic. They will still be able to communicate with HTTP/3 enabled listeners using previous HTTP versions. Why should HTTP/3 with Application Gateway be used? HTTP/3 is the latest version of the Hypertext Transfer Protocol built on the top of QUIC which operates over UDP. It represents a significant leap forward in terms of user experience, efficiency, and security. Here are some compelling reasons why migrating to HTTP/3 could greatly benefit your organization: Faster Web Page Loading (~200ms advantage): If you run a website or web application, implementing HTTP/3 can lead to faster page load times and improved user experiences. HTTP/3's reduced connection establishment latency and multiplexing capabilities help deliver resources more efficiently. Table below shows latency numbers of different HTTP versions. HTTPS (TCP+TLS) QUIC 1-RTT QUIC 0-RTT* First time connection 300ms 100ms 100ms Repeat Connection 200ms 50ms 0ms *0-RTT comes with its share of security risks and is not part of the private preview Enhanced Web Application Performance: Applications that make use of multiple resources, like images, scripts, and stylesheets, can benefit from HTTP/3's multiplexing and concurrent stream support. Mobile Applications: If you develop mobile apps, integrating HTTP/3 can enhance data transfer speed and responsiveness, which is especially important on mobile networks where latency can be higher. Reducing HOL Blocking: HTTP/3's use of QUIC helps mitigate head-of-line blocking, where the delay of one resource can block the delivery of others. This is especially advantageous for applications that require efficient resource loading. Security: HTTP/3's integration with QUIC provides improved security features by design, reducing the risk of certain types of attacks compared to previous versions of HTTP. Presently, 26.5% of the internet traffic is on HTTP/3 and there has been a steady increase in the adoption compared to HTTP/2 which has seen a decreasing trend (by ~10% in the last 12 months) owing to some of its demerits (explained in the sections later). How should HTTP/3 with Application Gateway be enabled? Prerequisite: You have an existing Application Gateway resource on standard_v2 SKU only. Please reach out to us @ quicforappgw@microsoft.com with the Resource URI on which you want the HTTP/3 feature enabled and we'll take you along with the next steps. What all HTTP/3 features are supported in private preview? HTTP/3 will be supported only in the front leg of the connection and backends will continue to be HTTP1.1. Application Gateway will support client-initiated connection migration (explained below) Application Gateway will support PMTU discovery. Application Gateway can advertise support for HTTP/3 via alt-svc header as part of HTTP1/2 response. (Image below explains the flow) What is HTTP/3 & QUIC? TCP (Transmission Control Protocol) (RFC793) has been the most widely used transport layer protocol since its inception. But, with the advent of more real time applications, the evolution of the edge, and an ever increasing need to reduce latency and congestion, using TCP is becoming untenable. UDP (User Datagram Protocol) (RFC768) was always seen as an alternative to TCP especially in instances where connectionless-less-reliable transmission was okey-dokey! But UDP suffered with the implementation of congestion control. TLS (Transport Layer Security) (RFC8446) adds another layer over TCP after the 3-way handshake for TLS negotiation to establish session key and session data encryption. Though the combination provides reliability and security, increased connection establishment has made application developers smirk than smile. QUIC (Quick UDP Internet Connections) (RFC9000) attempts to bridge these UDP gaps by inducing the TCP niceties and attempts to reduce the TCP ossification in the network. Put in brief, TCP encapsulated and encrypted in a UDP payload is QUIC. It appears like a bidirectional concealed UDP packet sequence to the external network. To the endpoints, it provides an advantage over TCP by deliberately concealing the transport parameters from the network and by shifting the responsibility of the flow control and the encryption service to the application layer from the transport layer. Pre-HTTP/3 protocols: HTTP/1.1 and HTTP/2 are done over TCP. HTTP/1.x versions have slow response times and never satisfy faster-load-times hungry webpages. HTTP/1.1, being a textual protocol, does a below average job in resource prioritization by transmitting the request and response headers as plain text. Without multiplexing capabilities, network requests are served in an ordered and blocking manner. With this approach, HTTP/1.1 suffers from HTTP Head of Line (HOL) blocking where the client waits for the previous requests to be serviced before sending another resulting in the subsequent blocked requests on a single TCP connection. Imagine a webpage needing multiple resources to load (Images, CSS, HTML files, Js files etc) the complete page! To overcome all these HTTP/1.1 limitations, HTTP/2 was brought in. It introduced header field compression by binary framing layer and creating a stream for communication reducing the amount of data in the header. Concurrent exchanges on the same connection by interleaving request and response messages and efficient coding of HTTP header fields. Prioritization of requests allowed more important requests complete quicker thus improving performance. HTTP/2 protocol communication involved binary encoded frames that carried data mapped to messages (request/response) in a stream which contained identifiers and priority information multiplexed in a single TCP connection. Figure-1 shows the flow of protocol communication in HTTP/2. All these enhancements mean lesser no. of TCP connections, longer-lived connections, less competition with other flows leading to better network utilization. By allowing multiple HTTP requests over a single TCP connection, HTTP/2 resolved HTTP HOL blocking issue but created the TCP HOL blocking issue. In the event of a network blip like network congestion, unavailability of network or change of a cell in a mobile network which might lead to loss of a packet throwing a TCP connection into a tizzy as it ensures that the order of packets transmitted and received are same. A loss of one packet will mean everything stops until the lost packet is retransmitted. In the case of multiple requests multiplexed onto a single TCP connection, all the requests are blocked although the “lost packet” in real impacts only one request. With increasing no. of mobile friendly apps, increase in the usage of cellular networks, and, in countries with not so good networks and high chances of network blips, such an issue can cause interruption to services. Enter QUIC based HTTP/3: HTTP/3 is based on QUIC. It is designed to be faster than TCP with lower latency, lesser overhead during connection establishment and quicker data transfer over the established connection. QUIC is based on UDP and offers 0-RTT and 1-RTT handshakes compared to 3-way handshakes of TCP. This is possible as it supports additional streams. HTTP/3 retains all the niceties of HTTP/2 like server push mechanism, multiplexing of requests over single connection via streams, resource prioritization. It ensures the issue of TCP HOL blocking is resolved. “Lost packets” along the way will not interrupt the data transfer. QUIC sees to it that transferring other data is uninterrupted while the issue of the “lost packet” is being resolved. QUIC based HTTP/3 features and use-cases: Faster connection establishment The regular 3-way handshake gives way to the 1-RTT and 0-RTT handshakes based on QUIC which will lead to a drop in the connection establishment by 66%-95%. The 1-RTT and the 0-RTT connection establishment helps in the improvement of page load times in web browsing immensely. Instant messaging applications, voice assistants, transactional systems (financial transactions, online purchases) benefit from quick connection establishment. In these scenarios, 1-RTT connection establishment can make a noticeable difference in reducing initial delays and enhancing overall user satisfaction. Financial institutions will find a wide range of benefits due the low latency with their mobile apps, online banking portals, provide customers with real-time notifications, effective API integration and many such use cases. Independent HTTP Streams (no TCP HOL Blocking) TCP HOL blocking occurs when a single delayed or lost packet holds up the delivery of subsequent packets, impacting overall communication efficiency. Avoiding TCP HOL blocking can offer significant advantages in real-life scenarios where minimizing latency, improving responsiveness, and optimizing data transmission are crucial. Removing unnecessary bottlenecks and making communication smoother results in happy customers. Web browsing without HOL blocking will help in fetching multiple resources in the page leading to quicker page loading times and thus providing the users with a rich browsing experience. Without HOL blocking, messages in an instant messaging application are delivered promptly without being held up providing the end user a fluid experience. IoT devices that transmit sensor data and updates will be able to deliver all the necessary data without being delayed by a single lost or slow packet, ensuring timely and accurate reporting. Avoiding HOL blocking in financial transactions ensures that data related to transactions is transmitted without unnecessary delays, contributing to real-time processing and confirmations without which CSAT is impacted vastly. Connection Migration Customers are always on the move. Especially with the ever-improving cellular networks, they are seldom stuck to a single network or a cell in the network. This nature of being on the move constantly will mean constant registration with the network and establishing connections frequently and deriving data from different servers. In the traditional HTTP and TCP method, this would lead to several drops in the connectivity. But that is a thing of the past with QUIC and HTTP/3. The QUIC-HTTP/3 combine provides users with a Connection Migration feature. During the QUIC connection establishment, the server provides the client with a set of Connection IDs (CID) as part of the QUIC header. Using this CID, the client can retain an existing connection despite moving networks and attaining new IP addresses. With the help of the connection migration, uninterrupted web browsing would be possible for users. IoT devices’ that need to maintain continuous communication will find the connection migration extremely useful. Users moving from private to public WiFi networks at malls, airports and other public places will be provided with seamless app experience. How to sign up? https://forms.office.com/r/iGeYgrmydA
