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.A Guide to Azure Data Transfer Pricing
Understanding Azure networking charges is essential for businesses aiming to manage their budgets effectively. Given the complexity of Azure networking pricing, which involves various influencing factors, the goal here is to bring a clearer understanding of the associated data transfer costs by breaking down the pricing models into the following use cases: VM to VM VM to Private Endpoint VM to Internal Standard Load Balancer (ILB) VM to Internet Hybrid connectivity Please note this is a first version, with a second version to follow that will include additional scenarios. Disclaimer: Pricing may change over time, check the public Azure pricing calculator for up-to-date pricing information. Actual pricing may vary depending on agreements, purchase dates, and currency exchange rates. Sign in to the Azure pricing calculator to see pricing based on your current program/offer with Microsoft. 1. VM to VM 1.1. VM to VM, same VNet Data transfer within the same virtual network (VNet) is free of charge. This means that traffic between VMs within the same VNet will not incur any additional costs. Doc. Data transfer across Availability Zones (AZ) is free. Doc. 1.2. VM to VM, across VNet peering Azure VNet peering enables seamless connectivity between two virtual networks, allowing resources in different VNets to communicate with each other as if they were within the same network. When data is transferred between VNets, charges apply for both ingress and egress data. Doc: VM to VM, across VNet peering, same region VM to VM, across Global VNet peering Azure regions are grouped into 3 Zones (distinct from Avaialbility Zones within a specific Azure region). The pricing for Global VNet Peering is based on that geographic structure. Data transfer between VNets in different zones incurs outbound and inbound data transfer rates for the respective zones. When data is transferred from a VNet in Zone 1 to a VNet in Zone 2, outbound data transfer rates for Zone 1 and inbound data transfer rates for Zone 2 will be applicable. Doc. 1.3. VM to VM, through Network Virtual Appliance (NVA) Data transfer through an NVA involves charges for both ingress and egress data, depending on the volume of data processed. When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via an NVA (firewall...) in the hub VNet, it incurs VM to VM pricing twice. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 2. VM to Private Endpoint (PE) Private Endpoint pricing includes charges for the provisioned resource and data transfer costs based on traffic direction. For instance, writing to a Storage Account through a Private Endpoint incurs outbound data charges, while reading incurs inbound data charges. Doc: 2.1. VM to PE, same VNet Since data transfer within a VNet is free, charges are only applied for data processing through the Private Endpoint. Cross-region traffic will incur additional costs if the Storage Account and the Private Endpoint are located in different regions. 2.2. VM to PE, across VNet peering Accessing Private Endpoints from a peered network incurs only Private Link Premium charges, with no peering fees. Doc. VM to PE, across VNet peering, same region VM to PE, across VNet peering, PE region != SA region 2.3. VM to PE, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA. However, as per the PE pricing model, there are no charges between the NVA and the PE. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 3. VM to Internal Load Balancer (ILB) Azure Standard Load Balancer pricing is based on the number of load balancing rules as well as the volume of data processed. Doc: 3.1. VM to ILB, same VNet Data transfer within the same virtual network (VNet) is free. However, the data processed by the ILB is charged based on its volume and on the number load balancing rules implemented. Only the inbound traffic is processed by the ILB (and charged), the return traffic goes direct from the backend to the source VM (free of charge). 3.2. VM to ILB, across VNet peering In addition to the Load Balancer costs, data transfer charges between VNets apply for both ingress and egress. 3.3. VM to ILB, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA and VM to ILB charges between the NVA and the ILB/backend resource. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 4. VM to internet 4.1. Data transfer and inter-region pricing model Bandwidth refers to data moving in and out of Azure data centers, as well as data moving between Azure data centers; other transfers are explicitly covered by the Content Delivery Network, ExpressRoute pricing, or Peering. Doc: 4.2. Routing Preference in Azure and internet egress pricing model When creating a public IP in Azure, Azure Routing Preference allows you to choose how your traffic routes between Azure and the Internet. You can select either the Microsoft Global Network or the public internet for routing your traffic. Doc: See how this choice can impact the performance and reliability of network traffic: By selecting a Routing Preference set to Microsoft network, ingress traffic enters the Microsoft network closest to the user, and egress traffic exits the network closest to the user, minimizing travel on the public internet (“Cold Potato” routing). On the contrary, setting the Routing Preference to internet, ingress traffic enters the Microsoft network closest to the hosted service region. Transit ISP networks are used to route traffic, travel on the Microsoft Global Network is minimized (“Hot Potato” routing). Bandwidth pricing for internet egress, Doc: 4.3. VM to internet, direct Data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. It is important to note that default outbound access for VMs in Azure will be retired on September 30 2025, migration to an explicit outbound internet connectivity method is recommended. Doc. 4.4. VM to internet, with a public IP Here a standard public IP is explicitly associated to a VM NIC, that incurs additional costs. Like in the previous scenario, data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. 4.5. VM to internet, with NAT Gateway In addition to the previous costs, data transfer through a NAT Gateway involves charges for both the data processed and the NAT Gateway itself, Doc: 5. Hybrid connectivity Hybrid connectivity involves connecting on-premises networks to Azure VNets. The pricing model includes charges for data transfer between the on-premises network and Azure, as well as any additional costs for using Network Virtual Appliances (NVAs) or Azure Firewalls in the hub VNet. 5.1. H&S Hybrid connectivity without firewall inspection in the hub For an inbound flow, from the ExpressRoute Gateway to a spoke VNet, VNet peering charges are applied once on the spoke inbound. There are no charges on the hub outbound. For an outbound flow, from a spoke VNet to an ER branch, VNet peering charges are applied once, outbound of the spoke only. There are no charges on the hub inbound. Doc. The table above does not include ExpressRoute connectivity related costs. 5.2. H&S Hybrid connectivity with firewall inspection in the hub Since traffic transits and is inspected via a firewall in the hub VNet (Azure Firewall or 3P firewall NVA), the previous concepts do not apply. “Standard” inter-VNet VM-to-VM charges apply between the FW and the destination VM : inbound and outbound on both directions. Once outbound from the source VNet (Hub or Spoke), once inbound on the destination VNet (Spoke or Hub). The table above reflects only data transfer charges within Azure and does not include NVA/Azure Firewall processing costs nor the costs related to ExpressRoute connectivity. 5.3. H&S Hybrid connectivity via a 3rd party connectivity NVA (SDWAN or IPSec) Standard inter-VNet VM-to-VM charges apply between the NVA and the destination VM: inbound and outbound on both directions, both in the Hub VNet and in the Spoke VNet. 5.4. vWAN scenarios VNet peering is charged only from the point of view of the spoke – see examples and vWAN pricing components. Next steps with cost management To optimize cost management, Azure offers tools for monitoring and analyzing network charges. Azure Cost Management and Billing allows you to track and allocate costs across various services and resources, ensuring transparency and control over your expenses. By leveraging these tools, businesses can gain a deeper understanding of their network costs and make informed decisions to optimize their Azure spending.Announcing the General Availability of Azure Load Balancer Health Event Logs
Health event logs are now fully available in all public, Azure China, and Government regions under the Azure Monitor resource log category LoadBalancerHealthEvent, providing you with enhanced capabilities to monitor and troubleshoot your load balancer resources. Health Event Types As announced in our previous public preview blog, the following health events are now logged when detected by the Azure Load Balancer platform. These events are designed to address the most critical issues affecting your load balancer’s health and availability: LoadBalancerHealthEventType Scenario DataPathAvailabilityWarning Detect when the Data Path Availability metric of the frontend IP is less than 90% due to platform issues DataPathAvailabilityCritical Detect when the Data Path Availability metric of the frontend IP is less than 25% due to platform issues NoHealthyBackends Detect when all backend instances in a pool are not responding to the configured health probes HighSnatPortUsage Detect when a backend instance utilizes more than 75% of its allocated ports from a single frontend IP SnatPortExhaustion Detect when a backend instance has exhausted all allocated ports and will fail further outbound connections until ports have been released or more ports are allocated Benefits of Using Health Event Logs Health event logs provide deeper insights into the health of your load balancer, eliminating the need to set thresholds for metric-based alerts or manage complex metric data for historical analysis. Here’s how you can get started using these logs today: Create Diagnostic Settings: Archive or analyze these logs for long-term insights. Leverage Log Analytics: Use powerful querying capabilities to gain detailed insights. Configure Alerts: Set up alerts to trigger actions based on the generated logs. For more detailed instructions on how to enable and use health event logs, refer to our documentation here. Contoso’s Story Context: Contoso uses a Standard Public Load Balancer with outbound rules to connect their application to public APIs. They allocate 8k ports to each backend instance using an outbound rule, anticipating up to 8 backend instances in a pool. Problem: Contoso is concerned about SNAT port exhaustion and wants to create alerts to warn them if backend instances are close to consuming all allocated SNAT ports. Solution with metrics: Initially, they create an alert using the Used SNAT ports metric, triggering when the value exceeds 6k ports (out of 8k). However, this requires constant adjustment as they scale their infrastructure and update port allocation on outbound rules. Solution with health event logs: With the new health event logs, Contoso configures two alerts: HighSnatPortUsage: Sends an email and creates an incident whenever this event is generated, warning network engineers to allocate more SNAT ports. SnatPortExhaustion: Notifies the on-call engineer immediately to address critical impact to outbound connectivity due to lack of SNAT ports. Now, Contoso no longer needs to adjust alert rules as they scale, ensuring seamless monitoring and response. What’s Next? This general availability announcement marks a significant step in enhancing the health and monitoring capabilities of Azure Load Balancer. We are committed to expanding these capabilities with additional health event types, providing configuration guidance, best practices, and warnings for service-related limits. We welcome your feedback and look forward to hearing about your experiences with health event logs. Get started today by exploring our public documentation. Stay tuned on Azure Updates for future announcements and enhancements!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.
How to build highly resilient applications with Azure Load Balancer
As customers move workloads to the cloud, designing their applications for high resiliency becomes a key consideration. This blog will highlight how Azure Load Balancer enables highly resilient applications across multiple resiliency categories. How to approach resiliency with Azure Load Balancer? When it comes to designing highly resilient applications, there are multiple types of design patterns that should be considered. Zone-redundancy Customers want to ensure that their deployments in an Azure region are resilient to any data center failures. Azure provides within-region resiliency via Azure Availability Zones. Availability Zones are separated groups of datacenters within a region. Customers can deploy their applications and Azure Load Balancer in a zone-redundant deployment method. A zone-redundant load balancer is replicated across all available zones. If one of the zones fails, then all incoming traffic will be sent to the other two zones, ensuring high availability. Global resiliency For mission critical applications or applications that need a global presence, replicating them across multiple Azure regions will ensure the application is globally resilient. This design pattern will ensure that no single region or geography becomes a single point of failure. In case a region goes offline, traffic will failover to the next available region, ensuring high availability of the application. Azure global Load Balancer can then be used to distribute traffic to these multi-region applications. Azure global Load Balancer is a globally distributed layer-4 load balancing solution. Global load balancer provides features such as a globally static IP address, geo-proximity routing, and automatic failover to the next available region. Subscription resiliency The last two categories of resiliency focused on ensuring the infrastructure itself is resilient. A third bucket focuses on resource management and isolation. Deploying resources and applications into multiple subscriptions can ensure that they are resilient to any subscription-level events. For example, if someone accidentally deletes a subscription or changes permissions, the overall application will still be available due to the replicated instances in the other subscriptions. To support multi-subscription workloads, Azure now supports cross-subscription load balancing. Now, the load balancer’s frontend IP address or backend pool can be located in a subscription that is different than the load balancer. An example of a real world customer To better understand how all the categories of resiliency can be combined, let’s explore an example customer scenario. In this scenario, we will walk through the customer’s use-case and how Azure Load Balancer helped them deploy a highly resilient application. Who is the customer? In this scenario we will be learning about an example customer called Contoso. Contoso is a large retail company based in Europe, and they have a global presence. Contoso is moving off their on-prem environment and onto Azure to support their high-scale needs. What are the application requirements? As the team at Contoso is looking at moving their application to the cloud, they have strict requirements around resiliency that need to be addressed. As mentioned above, Contoso has a global presence and most of their applications need to be globally available. With that, Contoso will deploy replicas of an application across multiple Azure regions to ensure high-availability and resiliency for their global user base. Second, given the criticality of some applications (e.g., inventory manager), these applications need to be deployed in a redundant manner. As mentioned earlier, these applications will be replicated across multiple Azure regions, but Contoso needs these applications to also be replicated within a single Azure region. Third, each application deployment should be isolated from each other, and shouldn’t share a single resource (virtual machine, IP address, etc.). This requirement also extends to subscriptions, where each application replica will be isolated in its own subscription. In addition to the requirements outlined above, Contoso decided that Azure Load Balancer would be a perfect fit for their ingress needs, given its ultra-low latency capabilities. However, Contoso wanted to ensure that Azure Load Balancer would be able to meet their strict resiliency requirements. How did Azure Load Balancer help? To address Contoso’s resiliency requirements, they deployed Azure Load Balancer in a multi-tier architecture. To support their multi-region requirement, an Azure global load balancer was deployed. The global load balancer would then be the gateway into the overall application. Whenever traffic would be sent to the global endpoint, Azure would route it to the closest deployment to that user. In addition, global load balancer’s automatic health probes and failover capabilities gave Contoso peace of mind, knowing that in the off chance of a regional failure, traffic would be automatically routed to the other geos. To support their in-region redundancy requirements, Contoso adopted a zone-redundant architecture for all of their in-region infrastructure (virtual machines, IP addresses, load balancers, etc.). Finally, Contoso adopted the new cross-subscription load balancing feature. With this feature, Contoso can deploy each application replica in its own subscription and then link them to their Azure global Load Balancer. This allows each deployment to be independent and avoid a common failure point. Contoso, after adopting Azure Load Balancer, has developed an architecture that addresses resiliency across the stack. Furthermore, Contoso’s application is now resilient globally, regionally, and at the subscription layer. Learn more Azure global Load Balancer Azure cross-subscription Load Balancer Zone-redundancy with Azure Load BalancerTroubleshoot health probe failures with Azure Load Balancer Health Status
In today's fast-paced cloud computing environment, maintaining the optimal performance and reliability of your applications is crucial. Azure Load Balancer's Health Status feature , now generally available to customers, significantly simplifies this task by providing detailed health information about your backend instances without the need to file a support ticket. This tool offers invaluable insights into the health state of each backend instance and the specific reasons behind their status, whether user-triggered or platform-triggered. By leveraging this feature, customers can proactively address issues, ensure minimal downtime, and enhance the overall user experience, all while reducing reliance on support services. What is Health Status? Health Status is an Azure Load Balancer feature that gives you detailed health information about the backend instances connected to your Azure Load Balancer’s backend pool. Each status is linked to your load balancing rules and provides two key insights: the health state of each backend instance and the reasoning behind its state. The health state indicates whether your backend instance is healthy ("Up") or unhealthy ("Down"). The reasoning behind these states is explained through reason codes, which fall into two categories: User Triggered Reason Codes and Platform Triggered Reason Codes. User Triggered Reason Codes are based on how you configured your load balancer setup and can be addressed by you. Platform Triggered Reason Codes are based on the Azure Load Balancer platform and cannot be addressed by you. For more information about the different reason codes, view our public documentation. Why use Health Status? In the past, customers were not provided with insights into why their backend instances were deemed healthy or unhealthy. To access this crucial information, customers often had to follow troubleshooting procedures such as taking packet captures or going through the process of creating a support ticket, relying on support engineers to identify the cause of a failed health probe. This process was not only complex and time-consuming but also incurred additional costs and added significant management overhead. Now, with the Health Status feature, customers can easily access real-time health information of their backend instances. This empowers them to make swift and informed decisions, minimizing downtime, reducing support costs, and enhancing the overall user experience. By leveraging these insights, customers can proactively manage their environment and ensure optimal performance. Retrieving Health Status Health Status can be easily retrieved on a per load balancing rule basis. To retrieve Health Status: Sign in to the Azure Portal and search for "Load balancers". Select your load balancer and navigate to "Load balancing rules" under Settings. View the health status of the rule by clicking “View details” value of the corresponding rule. Refresh button can be used to get the latest status. Figure 1: Sample Health Status in Azure Portal Contoso's Utilization of Health Status for Game Server Maintenance Let’s explore how one of our customers, Contoso, uses the Health Status feature for efficient decision-making and troubleshooting. Who is Contoso and what is their issue Contoso, a prominent name in the gaming industry, has been leveraging Azure Load Balancer to distribute traffic to their highly popular game server hosted on Azure Virtual Machine Scale Sets. Their users love using Contoso’s servers due to the reliability and performance achieved on them. Recently, Contoso encountered an issue where one of their game servers became unhealthy, leading to disruptions in the gaming experience for their users. How Health Status resolved their issue Thanks to the Azure Load Balancer Health Status feature, the Contoso team was able to quickly navigate to the Load balancing rule page in Portal to view the health status of the unhealthy virtual machine instance. By doing so, they retrieved detailed insights into why their game server was marked unhealthy. This real-time information highlighted “the backend instance was unhealthy due to Admin State set to Down”. Armed with this crucial data, Contoso's Network team swiftly addressed the configuration issue by toggling the Admin State value of unhealthy server to “None”, thereby restoring the server to a healthy state. After a root cause analysis, it was determined that the previous engineer mistakenly toggled the wrong server to a Down Admin State value when trying to do fixes on another server. Benefits of using Health Status Instead of creating a support ticket and waiting for assistance, they utilized the Health Status feature to diagnose and resolve the problem independently. This proactive approach not only minimized downtime but also reduced support costs and enhanced the overall user experience. Conclusion By incorporating the Health Status feature into their operational workflow, Contoso has been able to make efficient, data-driven decisions and troubleshooting issues promptly, ensuring their gaming services remain robust and reliable for their users. Get Started We are excited to bring the Azure Load Balancer’s Health Status feature to you. This feature provides valuable insights into the health of your backend instances, helping you ensure better troubleshooting for optimal performance and reliability of your applications. For more information and to get started, visit the following links: Overview of health status concepts How to retrieve health status We hope you can take advantage of this feature, and we welcome your feedback. Please feel free to leave a comment below.Secure, High-Performance Networking for Data-Intensive Kubernetes Workloads
In today’s data-driven world, AI and high-performance computing (HPC) workloads demand a robust, scalable, and secure networking infrastructure. As organizations rely on Kubernetes to manage these complex workloads, the need for advanced network performance becomes paramount. In this blog series, we explore how Azure CNI powered by Cilium, built on eBPF technology, is transforming Kubernetes networking. From high throughput and low latency to enhanced security and real-time observability, discover how these cutting-edge advancements are paving the way for secure, high-performance AI workloads. Ready to optimize your Kubernetes clusters?
