Azure News - 2026-10-21

To identify which sovereign cloud solution may fit your organization’s needs, take the Microsoft Sovereign Cloud assessment

New and upcoming controls, where they apply, and how they fit into sovereign Azure architecture. At the October Frontier Tour, we are announcing new and expanded capabilities for Microsoft Sovereign Public Cloud. This post explains what each capability does, where it applies, and how customers can combine controls within an Azure architecture. 

It is written for the platform engineer responsible for the landing zone, the security engineer answering operator-access questions, the compliance professional translating requirements into controls and evidence, and the architect deciding where and how an AI workload can run. The One Microsoft Blog provides the broader business framing. 

Why the control surface changed

For years, residency addressed many sovereignty questions: select the appropriate region, understand commitments such as the EU Data Boundary and in-country processing, and design the workload accordingly. Those commitments continue to provide an important foundation. 

AI makes the choice of controls increasingly important. An AI workload can help organizations create and process sensitive information across prompts, retrieved context, model responses, embeddings, model artifacts, and operational data. Each can have its own residency, protection, and access considerations. Sovereignty therefore needs to extend across the workload architecture, not only the location in which the workload runs. Sovereignty is not one-size-fits-all. With Microsoft Sovereign Public Cloud, organizations can select and combine sovereign controls based on the requirements of each workload while benefiting from the innovation and scale of the public cloud. Data residency controls, including the choice of more than 80 Azure regions and the EU Data Boundary, help customers address where data is stored and processed.  

Customer-managed keys with Azure Key Vault Managed HSM strengthen customer control over data at rest; Private Link and TLS protect data in transit; and Azure Confidential Computing helps extend protection to data while it is being processed. Customer Lockbox provides additional control over Microsoft access to customer data, while Sovereign Landing Zone uses policy-based guardrails to help organizations apply sovereignty requirements at scale. Together, these complementary controls allow customers to tailor architectures to specific sovereignty, regulatory, and workload requirements while benefiting from Azure’s hyperscale infrastructure and advanced cloud and AI capabilities. 

Prompts, retrieved context, and model responses are processed in memory. For supported workloads, Azure confidential computing helps protect this data during processing using hardware-based, attested trusted execution environments. For supported workloads configured for secure key release, Microsoft Azure Attestation provides claims about the execution environment’s identity and security state. Azure Key Vault Managed HSM evaluates those claims against the configured release policy before releasing a key. Residency and encryption protections for stored embeddings, vector indexes, and model artifacts depend on the services and configurations used. Operational telemetry should be assessed separately against the applicable service’s data handling and residency commitments. 

We are now expanding this portfolio with new and enhanced capabilities that give customers additional choices across sovereignty posture, encryption-key control, the protection of data in use, policy enforcement, operator-access transparency, and business continuity. 

Start with the workload

Consider an AI-powered application that uses sensitive organizational information to answer questions. Information moves from the source records to a search index, then to an AI model that generates a response. Instead of using every available sovereignty control, the organization first reviews the requirements and risks for this workload. It then chooses the controls that best address those needs. 

Each stage of that pipeline raises a different question. Source records raise residency and encryption-at-rest questions. Embedding and indexing determine where vector representations of sensitive data live. Inference determines where prompts and retrieved context are processed, and whether that processing is hardware-isolated. Responses and operational telemetry raise retention, logging, and access questions. The sections that follow introduce each new capability against these stages, and the table at the end consolidates the mapping. 

Sovereign Control Panel Public Preview at Microsoft Ignite

Organizations increasingly need to demonstrate not only where their data resides, but also how sovereignty controls are applied, monitored, and evidenced. Answering questions from executives, auditors, regulators, and risk teams can require information spread across policy, security, monitoring, and operational processes. This fragmentation can make sovereignty posture difficult for organizations to assess and demonstrate consistently. Sovereign Control Panel, currently in private preview, will enter public preview at Microsoft Ignite. Delivery timelines are subject to change. 

Just as Microsoft Defender for Cloud helps organizations understand and improve their security posture, and Microsoft Purview brings visibility and governance to data, Sovereign Control Panel is designed to bring organizations greater clarity and operational focus to sovereignty. 

Sovereign Control Panel is an Azure-based posture and evidence experience designed to help organizations assess, monitor, and demonstrate their sovereignty posture from a centralized position. Instead of manually assembling information across tools and teams for every assessment, customers can gain a more continuous and actionable understanding of their posture across their existing Azure estate. 

The experience is organized around a continuous Discover, Control, Act model. Discover helps organizations understand where they stand and why by establishing their actual sovereignty posture, surfacing evidence, identifying gaps and risks, and explaining the underlying drivers. It also supports business continuity readiness by helping organizations assess dependencies and readiness for portability across operating environments, if required. Control helps organizations define what should be true and how it should be maintained by selecting and configuring controls, assigning ownership, applying guardrails, and detecting deviations. Act helps organizations address identified gaps through guided remediation and verify the resulting posture. 

By connecting posture assessment, control management, remediation, and verification, Sovereign Control Panel is designed to help customers move from manually assembling sovereignty information toward a continuous, insight-driven approach to managing sovereignty. It complements the policy-based guardrails provided by Sovereign Landing Zone and provides a foundation for progressively bringing sovereignty posture and operator-access visibility together in one experience. 

Data Guardian and Production Touch Ledger

Customers increasingly expect cloud-provider access to be governed, monitored, and evidenced. Existing controls already govern access before it begins. Just-in-Time Access reviews time-bound Microsoft engineer access, while Customer Lockbox adds customer approval when customer data is in scope. 

We are rolling out two complementary additions to these operator-access controls for customers in the EU and EFTA: Data Guardian and Production Touch Ledger. 

Data Guardian strengthens operational oversight by enabling European-resident oversight by a trusted EU partner to monitor qualifying Microsoft engineer remote access to in-scope production systems in EU and EFTA regions. This oversight spans Azure, Microsoft 365, and Dynamics 365 workloads. 

Production Touch Ledger, also launched with phased rollout, complements this oversight with tamper-evident records of the actions performed during qualifying remote Microsoft engineer access to in-scope production systems in EU and EFTA regions.  

Together, these capabilities extend the operator-access lifecycle from access governance to oversight and evidence: 

• Govern: Just-in-Time Access and Customer Lockbox govern access before it begins. 

• Monitor: Data Guardian provides EU-resident oversight by a trusted EU partner during qualifying Microsoft engineer access to in-scope production environments. 

• Record: Production Touch Ledger preserves tamper-evident records of access and the actions performed for validation reconstruction. 

External Key Management with Azure Managed HSM, generally available

Azure Managed HSM already provides customers with dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. We are now announcing the general availability of External Key Management with Azure Managed HSM, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. 

With External Key Management, the key-encryption key remains in a customer-owned and customer-operated HSM, either on-premises or hosted by a trusted third party. When a supported Azure service needs to wrap or unwrap a data-encryption key, Azure Managed HSM delegates the cryptographic operation to the external HSM through an External Key Management proxy. 

Azure Managed HSM remains the Azure-facing service for authorization and key management, while External Key Management allows the key-encryption key to remain in an HSM physically controlled by the customer or a third-party provider. 

Because the external HSM, proxy, and connectivity become part of the workload’s critical path, organizations should design and test availability, failover, key rotation, rewrapping, and recovery procedures before production deployment. External Key Management is available to customers globally.  

Azure Confidential Clean Rooms: In Limited Preview

 Some of the most valuable insights require organizations to bring data together, but sensitive data often can’t simply be shared. Azure Confidential Clean Rooms, currently in Limited Preview, is designed to help organizations collaborate on sensitive data while keeping the underlying data protected. Participants can analyze approved datasets together using Spark SQL within a hardware-protected environment, helping enable scenarios such as advertising measurement, customer matching, joint risk analysis, and other multiparty analytics without broadly exposing each participant’s raw data.

Built on Azure confidential computing, Azure Confidential Clean Rooms brings a verifiable trust model to these collaborations. Participants encrypt their data, agree to the analysis being performed, and can use attestation to verify the expected environment and code before encryption keys are released. Only approved results leave the protected environment, while tamper-resistant audit trails help record important activity. Azure Confidential Clean Rooms is moving toward making confidential, multiparty data collaboration available to a broader set of customers and scenarios. 

Sovereign Landing Zone with Bicep, Terraform, and Azure Verified Modules, now available

Sovereign Landing Zone provides a policy-based foundation for implementing sovereign controls across Azure environments, using a management group hierarchy and Azure Policy definitions, initiatives, and assignments to help organizations apply sovereignty requirements consistently. 
 
We’re announcing an updated Sovereign Landing Zone implementation supporting both Bicep and Terraform, using Azure Verified Modules to provide reusable infrastructure-as-code building blocks that platform teams can integrate into their existing deployment practices- 
 
In the current geopolitical environment, organizations are revisiting how they maintain control, continuity, and resilience for critical workloads. Azure Local can support these requirements by providing an option to run workloads in a customer-controlled environment, including disconnected operations when needed. 

The new Local management group in the Sovereign landing zone hierarchy gives customers a clear place to govern Azure Local clusters and the workloads running on them. It also helps teams design workloads in Azure public cloud today with a potential exit path to Azure Local later, so business continuity planning is built into the architecture rather than addressed only during a disruption.

Business Continuity and Portability

Sovereign business continuity extends beyond traditional high availability and disaster recovery. It starts with understanding what should remain operational when disruptions affect access, connectivity or cloud-platform assumptions.

Sovereign Control Panel introduces portability evaluations that help customers assess continuity risks and measure readiness for portability across operating environments, if required. These evaluations help identify baseline considerations such as service availability and compatibility, while recognizing that porting the applications may require additional architectural work.

We are also publishing a new Sovereign Business Continuity guidance and architecture patterns starting with an initial set, with more to follow in the coming months. The library provides prescriptive architecture guidance in the form of flexibly composable patterns for designing continuity paths across Azure, Azure Local, and Azure Local disconnected operations. Combined with governance capabilities in Sovereign Landing Zone for Azure Local, these resources can help customers inform risk-based continuity planning and establish recovery ready architectures.

Putting them together

Choosing between these controls is usually a small number of concrete decisions. If a customer requires the root encryption key to remain in hardware outside Microsoft infrastructure, External Key Management applies, and the external HSM, proxy, and connectivity become part of the workload's critical path. If the requirement is strong customer control of keys without external custody, customer-managed keys in Managed HSM may be sufficient. If prompts, retrieved context, or model weights must be protected while in use, the workload needs confidential computing SKUs and attestation-gated key release rather than encryption at rest alone. If the requirement is record of who accessed the environment, the operator-access controls apply. And if the requirement is the ability to keep operating through disruption, continuity and portability planning belongs in the architecture from the start rather than at the point of failure.

The result is not a single prescribed sovereign architecture. It is a tailored sovereignty architecture in which organizations combine the controls that meet the requirements and risk profile of each workload while continuing to benefit from the innovation and scale of the public cloud. Service, region, SKU, and workload support vary by capability, so validate availability before making any control an architectural dependency.

Resources

• Microsoft Sovereign Cloud overview: https://learn.microsoft.com/azure/azure-sovereign-clouds/
• Capabilities of Sovereign Public Cloud: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/sovereign-public-cloud-capabilities
• Confidential Computing: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/confidential-computing
• Data Guardian: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/data-guardian
• External Key Management: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/external-key-management
• Sovereign Control Panel: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/sovereign-control-panel
• Sovereign Landing Zone: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/overview-sovereign-landing-zone
• Sovereign Landing Zone implementation options: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/implementation-options
• New Local Management Group for ALZ https://techcommunity.microsoft.com/blog/azuregovernanceandmanagementblog/new-local-management-group-for-alz--updated-sovereign-policies-for-slz/4515156
• Sovereign Private Cloud Tech Community blog

Microsoft is excited to attend NVIDIA GTC Berlin October 20 through 22, bringing news across the AI stack. We are expanding the infrastructure and platform capabilities organizations need to build and run AI across cloud and customer-controlled environments. This includes new capabilities for Microsoft Sovereign Cloud supported by NVIDIA accelerated computing, open-model choice with NVIDIA Nemotron models through Fireworks AI on Azure, and GPU-accelerated analytics in Microsoft Fabric.  Find us at booth 3066 and off site at the JW Marriott. 

What ties these areas together is a question customers in every industry are asking us: how can we use the latest models and infrastructure while retaining control over where our workloads run and who can access them? For many organizations, especially those in regulated industries, answering these questions is essential to expanding the use of AI and agentic workloads. Through our work with NVIDIA, these are some of the challenges we are helping customers address in Berlin. 

Control and choice, wherever AI runs 

Teams want the newest, most capable models running on the most performant hardware, all while keeping control over their data, models, and outputs. The public cloud is the right solution for many workloads.  

Other workloads may need to run in specialized, secured environments because of requirements for data residency, operator access, connectivity, latency, or operational control. Microsoft is building solutions to meet customers across this range of needs. 

Microsoft’s approach to sovereign AI starts with the level of control each workload requires. Depending on the workload, this can include control over where data and models reside, who can access and operate the environment, how AI workloads are governed, and whether critical operations can continue when cloud connectivity is restricted or unavailable. The goal is to help organizations meet these requirements while maintaining access to modern cloud and AI capabilities. 

A consistent platform, from Cloud to the edge 

Microsoft provides resilient infrastructure for AI demands across Azure and Azure Local, supported by NVIDIA accelerated computing. This hardware spans accelerated systems in Azure datacenters and NVIDIA GPUs in Azure Local environments that customers operate themselves. It connects two important needs: building and scaling AI in the cloud, and deploying and operating where latency, connectivity, data residency, or operational control matter. 

This gives organizations more choice in where they build, deploy, and operate AI workloads, while applying consistent management and governance across their environments. 

Sovereign AI on Azure Local with NVIDIA accelerated computing 

With Sovereign Private Cloud, built on Azure Local, organizations can bring AI closer to sensitive data and physical operations across connected and disconnected environments. At Microsoft Ignite, Foundry Local on Azure Local will become generally available for local model deployment and inference. This enables organizations to run AI models within their own environments so that models and sensitive workload information can remain under local control. Microsoft is also expanding support for grounded and agentic AI scenarios that use enterprise data within the customer’s local environment. 

NVIDIA accelerated computing supports these deployments. Looking ahead, Microsoft is working to bring support for NVIDIA HGX-based multi-GPU systems to Azure Local, providing the dense accelerated infrastructure needed to run larger models with Foundry Local in customer-controlled environments. With high-performance NVIDIA GPUs on Azure Local, organizations can build, test, and deploy AI workloads in sovereign and edge environments. 

Beyond Azure Local, Microsoft is also a key partner in the NVIDIA OpenShell Reference Architecture for Safe AI Agents, supporting the extension of secure agentic AI from the datacenter to the edge, including the recently launched NVIDIA RTX Spark and DGX Station running Windows. 

Confidential virtual machines on Azure Local are generally available, extending hardware-based data-in-use protection to customer-controlled infrastructure. Hardware-encrypted memory and attestation help protect supported workloads from the host operating environment and infrastructure administrators. 

Microsoft is a key partner in the NVIDIA OpenShell Reference Architecture for Safe AI Agents, supporting the extension of secure agentic AI from the data center to the edge, including the recently launched NVIDIA RTX Spark and DGX Station running Windows. 

For data in use, confidential computing adds protection enforced from the silicon up, so security leaders can explain where trust is enforced at each layer.  

Open models you can choose, and change: NVIDIA Nemotron with Fireworks AI on Azure 

Customers continue to prioritize avoiding model provider lock-in. Fireworks AI is bringing open models including the family of NVIDIA Nemotron models to Azure as managed endpoints, so teams can put open models into production without having to build and run the serving stack themselves. Fireworks serves these models on NVIDIA accelerated computing with TensorRT-LLM and Dynamo. 

The same emphasis on model choice carries into Microsoft Foundry, where NVIDIA open models are available alongside a broader model catalog. For workloads that need to run within a customer-controlled environment, Foundry Local provides a path to deploy supported models locally. 

Faster data for AI: Microsoft Fabric with NVIDIA accelerated computing  

As analytics become more conversational, the warehouse has to answer more queries, more interactively, and at greater scale. To meet that demand, GPU-accelerated query acceleration, powered by NVIDIA accelerated computing, is now in public preview. Based on award-winning research, it accelerates your analytical workloads without requiring changes to your data or your SQL queries, with benefits that become increasingly important under the high-concurrency patterns AI experiences create. 

Our customers across industries are already seeing value from GPU-accelerated Fabric Data Warehouse: 

“In healthcare, timely insights matter, and GPU-accelerated Fabric Data Warehouse will help ensure critical data is available when clinicians and leaders need it most. We’re seeing up to 5x improvement in our query speeds, which allows our teams to spend less time managing performance and more time delivering meaningful insights.” 
- Shaun McDonald, IT Manager, UNC Health 

“Our experience with GPU-accelerated Fabric Data Warehouse has been excellent. The capability integrates seamlessly into our existing architecture and has delivered meaningful performance improvements across a range of queries, with complex workloads running 3.4x faster at single concurrency and more consistently. 

At WTW, we operate a shared data platform supporting multiple applications and reporting workloads. GPU-accelerated Fabric Data Warehouse enables us to serve high volumes of queries more efficiently, directly improving the responsiveness of our downstream analytics and reporting. We see the potential for this capability to help unify how we deliver data across our platform.” 

- Andrew Bradbrook, Director – Systems Architecture, WTW 

Better data for physical AI: NVIDIA Cosmos Data Factory on Azure 

For teams building autonomous vehicles, robotics and vision AI agents, creating and improving physical systems intelligence depends on having the right training data not just more of it. Rare conditions are difficult to capture, and turning raw recordings into useful datasets often means moving between disconnected tools and manual processes. NVIDIA Cosmos Data Factory brings data curation, processing and synthetic data generation into a connected workflow. Its agentic blueprints and composable skills help developers prepare high-quality real and synthetic datasets, expanding coverage of the scenarios their models need to handle. 

This week NVIDIA Cosmos Data Factory’s AV Dataset Generation blueprint becomes generally available on Azure. The workflow turns raw driving video and vehicle signals into curated, searchable, augmented and evaluated datasets, with engineers setting the target scenarios and data-quality criteria. A rare cut-in on a wet road, for example, can become the starting point for finding similar recordings and generating additional variations. NVIDIA supplies the data workflows and open models, while Azure supplies the compute to run them at scale helping teams spend less effort preparing data and more time developing and testing. 

The next step is connecting that data foundation to model improvement. NVIDIA Alpamayo Agentic Factory, coming soon to Azure, builds on Cosmos Data Factory to connect targeted dataset creation with driving-model post-training and simulation evaluation. Engineers define the goal, review outputs and guide subsequent experiments, while agents plan and execute the development steps. The aim is a repeatable path from a known driving failure to an evaluated model improvement, with each iteration informing what to test next. 

From announcements to availability 

Across these announcements, Microsoft and NVIDA are expanding the choices available to originations building expand the options available to organizations building AI across cloud and customer-controlled environments. Confidential virtual machines on Azure Local are generally available today. At Microsoft Ignite, Foundry Local on Azure Local will become generally available for local model deployment and inference across connected and disconnected environments. 

What's next 

Berlin is the first stop in Microsoft's FY27 NVIDIA GTC series. Next is NVIDIA GTC Washington, D.C., November 30 to December 3, followed by GTC San Jose, March 15 to 18, 2027. There is more on Azure AI infrastructure coming at Microsoft Ignite, hosted in San Francisco November 16 – 20.  

If you are in Berlin, stop by booth 3066 on October 21 and 22, or join our 15-minute theater session, "Sovereign AI, From Azure to the Edge," on Thursday, October 22 at 11:00 CEST or find us at our space at the JW Marriott. Bring your hard-hitting and pressing questions! 

Learn more: Microsoft Sovereign Cloud · Azure AI infrastructure, silicon to systems · Next in the series: Microsoft at NVIDIA GTC Washington, D.C. 

There’s been a lot happening with Azure SRE Agent lately, with new guidance, examples, and resources to help teams get more out of the service. Whether you’re thinking through security and architecture, connecting tools like Splunk, or looking for practical ways to improve how your agents work, there’s plenty to dig into.

So, we’ve pulled the latest updates together in one place. Here’s a look at what’s new and what to start.

Understand how Azure SRE Agent handles security and data

Security questions often come first when teams evaluate Azure SRE Agent: What can it access? Where does data go? How are actions controlled? Our updated security overview and data residency guidance answer those questions in one place.

Our latest guidance brings those answers together. It explains how Azure SRE Agent approaches security through execution isolation, secretless credential management, customer separation, encryption, network controls, and logging. It also covers how data such as prompts, responses, conversation history, and resource analysis is stored and processed, including important data residency considerations when choosing a model provider.

Explore the guidance docs: Security overview for Azure SRE Agent, Data residency and privacy in Azure SRE Agent and If you want a secure AI agent, start restricting its environment.

Plan a governed enterprise deployment

Get more from your agent from day one

Creating an agent is the easy part. The real value comes from giving it the right scope, data, and operational context. Our new practical setup guide explains the choices that make the biggest difference. The guidance covers how to start with a focused set of resources, connect code and telemetry, configure incident integrations, and add the runbooks and knowledge your team already relies on. These steps help ground the agent in your environment so it can support real investigations, not just generic questions.

Read the practical guide: Getting the best out of Azure SRE Agent.

Enterprise Adoption Guide

Getting started with Azure SRE Agent is one thing. Figuring out how to expand it across teams and make it part of the way your organization operates is another. In this two-part guide, we share practical lessons for both ends of that journey: how to get your first SRE Agent up and running, and how to build on that foundation as more teams and use cases come on board. The guides walk through resource design, identity, connec?tivity, governance, and integration patterns so platform and architecture teams can build an approach that fits and scale in their environment.

Read the guidance: Part 1: deploying your SRE Agent and Part 2: from one team to enterprise-wide adoption.

Connect operations and development with Azure SRE Agent Canvas in GitHub Copilot

We are also introducing Azure SRE Agent Canvas in GitHub Copilot Apps and Copilot CLI, a new collaborative experience that brings operational findings and context into GitHub Copilot. It gives developers and operators a shared place to review evidence, work through an issue, and decide what to do next.

To help you see how the experience works, we have put together three resources:

• Documentation: Learn how to use Azure SRE Agent Canvas in GitHub Copilot during an investigation. https://aka.ms/sreagent/canvas/doc
• Blog: Read more about how the experience helps operations and development teams work from the same context. https://aka.ms/sreagent/canvas/blog
• Demo: Watch Azure SRE Agent Canvas in GitHub Copilot support an investigation from initial findings through team handoff. https://aka.ms/sreagent/canvas/demo

Azure SRE Agent Canvas in GitHub Copilot brings cloud operations context into a familiar developer workflow, helping teams investigate and resolve issues together without starting over in another tool.

Extend Azure SRE Agent with plugins and response plans

If your Splunk Enterprise environment is private, two new MCP samples can help you connect it to Azure SRE Agent without opening Splunk to inbound internet traffic. Each sample provides a starting point that you can adapt to your own network and production requirements. Both samples could be useful for anyone who uses SRE Agent and Splunk together. Choose the pattern that matches your setup:

• Same-region deployment: Run Azure SRE Agent and the private Splunk workload in the same Azure region and virtual network, with isolated subnets and private MCP traffic. Private Splunk MCP—same region
• Cross-region deployment: Keep Splunk in another Azure region and route private MCP traffic through Global VNet Peering and private DNS. Private Splunk MCP—cross region.

You can now use a private Azure DevOps repo as a plugin marketplace for Azure SRE Agent. This gives your team one place to manage and share plugins and skills built around the tools, processes, and knowledge you already use. The Azure DevOps plugins blog shows how to connect a repo and install those capabilities in Azure SRE Agent.

If your team uses ServiceNow, you can also create more advanced response plans based on the type of incident you are handling. The ServiceNow response plans blog walks through how to set up targeted plans that trigger the right investigation workflow while fitting into the ServiceNow processes your team already has in place.

Where to start

Not sure which resource to open first? Start with the question you are trying to answer:

• Evaluating security or compliance? Start with the security overview, data residency guidance, and Security and Governance white paper.
• Designing for production? Use the Enterprise Architecture Guide to align platform, identity, networking, and governance decisions.
• Configuring a new agent? Follow the practical setup guide to add the context that improves investigation quality.
• Want to connect operational work with developer collaboration? Explore the documentation, blog, and demo for Azure SRE Agent Canvas in GitHub Copilot.
• Connecting with plugins? Choose the right Splunk MCP sample and learn more from the Azure DevOps plugins blogs and ServiceNow responses plan blog.

Additional resources:

• Get started: https://sre.azure.com/
• Documentation: https://learn.microsoft.com/azure/sre-agent/
• Azure SRE Agent on GitHub: https://aka.ms/sreagent/github
• Azure SRE Agent blogs: https://aka.ms/sreagent/blog

Have feedback or a question? Join the discussion in the Azure SRE Agent GitHub repository.

Azure Container Registry now provides two new platform metrics that make it easier to understand outbound data transfer, inspect API traffic, and investigate throttled or failed requests without first opening a support request.

We're excited to share the general availability of the Data Transfer and Transactions metrics for Azure Container Registry (ACR). Both metrics are emitted automatically through Azure Monitor and include dimensions that help you move from “something changed” to the operation, response, and region that explain the change.

Available to all ACR customers today: The Data Transfer and Transactions metrics are available automatically for every registry, with no additional configuration or cost for the metrics themselves.

Deeper visibility into registry activity

ACR's existing platform metrics provide useful high-level signals such as total and successful pull and push counts, along with storage usage. However, those aggregate signals don't tell you which API operation changed, which region served the traffic, or whether requests were successful, rejected, or throttled.

Answering those questions often required you to configure diagnostic settings, query logs, correlate client-side telemetry, or contact support. The new metrics add built-in dimensions for common operational investigations, so you can identify the traffic pattern first and then decide whether to tune clients, adjust deployment behavior, change capacity, or investigate a failure.

This visibility is especially useful for shared registries and geo-replicated environments. If request volume increases, outbound transfer changes, or clients begin receiving HTTP 429 responses, you can investigate the activity directly in Azure Monitor or the integrated Grafana experience.

What is new

Data Transfer: understand outbound registry traffic

The Data Transfer metric measures total outbound data transferred from your registry in bytes. Split the metric by ApiName to distinguish client blob and manifest downloads, geo-replication traffic, and data read when another registry imports content from this registry. Split by Region to see where that transfer originated.

Transactions: understand registry API activity

The Transactions metric counts registry API operations. Use its dimensions to identify which operations are generating traffic, where requests are served, and whether the response succeeded, redirected, failed, or was throttled.

ApiName

DataTransfer/Transactions

Region

DataTransfer/Transactions

ResponseType

Transactions

For the complete list of API names and response classifications, see the Azure Container Registry monitoring data reference .

Questions you can answer

Which APIs are busiest?

Split Transactions metric by ApiName to compare manifest, layer, metadata, and authentication operations.

How is traffic distributed across my registry geo-replications?

Split Transactions and DataTransfer metrics by Region to monitor transaction volume and outbound data transfer across the registry's geo-replications.

Are my requests being throttled?

Filter Transactions by ResponseType = Throttled, then split by ApiName or Region to find the affected traffic.

What operations are driving outbound data transfer from my registry?

Split DataTransfer by ApiName to compare client downloads, replication, and import-source traffic.

You can explore these new insights in two ways. Start with the integrated Grafana dashboard for a curated, customizable view of registry health and activity. For quick questions or focused investigations, use Azure Monitor Metrics to filter and split the underlying metrics by API, region, and response type.

Start with the integrated Grafana dashboard

Alongside these metrics, we're introducing a new visualization experience for ACR customers: Dashboards with Grafana. The experience is enabled by Azure Managed Grafana and brings a prebuilt, customizable Grafana dashboard into the registry's Azure portal experience. The dashboard provides out-of-the-box panels for key operational insights, including transaction activity and request outcomes by region, outbound data transfer, throttled requests, and storage consumption.

To get started, open your registry in the Azure portal and select Monitoring > Dashboards with Grafana. The gallery includes the Azure Container Registry observability dashboard with views for data transfer, transaction trends, throttling, and storage consumption. You don't need to deploy or manage a separate Grafana instance. For teams that already use Grafana, the ACR Observability dashboard is also available in the public Grafana dashboard gallery, where it can be imported and customized for existing monitoring environments.

Use the prebuilt dashboard as a starting point, then add panels and customize the views to surface and save the insights most important to your team. You can also use Grafana Explore for ad hoc analysis.

The integrated observability dashboard brings key registry metrics together in one view.

The dashboard is broken down into sections: Overview, Data Transfer, Transactions, and Storage.

Explore the dashboard sections, including Transactions, to view overall request breakdown and audit throttle activity.

For dashboard creation, customization, access, and deployment guidance, see Use Grafana dashboards in Azure Container Registry.

Run ad hoc metric queries in Azure Monitor

For a quick question or focused investigation, open your registry and select Monitoring > Metrics. Select Data Transfer or Transactions, then use filtering and splitting to analyze the relevant API, region, or response dimensions.

Investigating throttling? Start with Transactions, filter ResponseType to Throttled, and split by ApiName. After you identify the traffic pattern, review the mitigation guidance in Azure Container Registry SKU features and limits .

Use the Transactions dimensions to investigate operation volume, regional traffic, and outcomes.

Use Data Transfer dimensions to identify the operations and regions generating outbound transfer.

Learn more

• Monitor Azure Container Registry
• Azure Container Registry monitoring data reference
• Use Grafana dashboards in Azure Container Registry
• Azure Container Registry API request rate limits

Engineering deep dives

For a closer look behind the scenes, these engineering deep dives explain how our team designed and implemented the capabilities that make these new insights possible.

• Making ACR Data Transfer Visible: The Storage Activity Platform Behind GetBlob Metrics
• Making Registry Activity Visible at Scale

Start exploring the metrics today

By Brian Benz, Paul Yu, Maya Singh, Johnson Shi

GPU memory allocation can be tricky to get right. Allocate too little and your AI workload can slow down or fail with an out-of-memory error, often during peak traffic when reliability matters most. Allocate too much and expensive GPU capacity sits unused. Getting an informed view of your workload's actual memory needs from the start helps you avoid both problems.

Kubernetes dashboards can show that GPU memory is under pressure, but they cannot tell you which functions in your AI workload are responsible. Without that detail, teams are left shrinking the workload, moving it to a larger GPU, or restarting it and hoping the problem does not return. That guesswork gets expensive fast.

GPU memory profiling on Azure Kubernetes Service (AKS) provides the evidence to show which functions allocate GPU memory while the workload runs. You can use that visibility to size memory with an informed perspective from the beginning, troubleshoot unexpected pressure, and validate that later adjustments work as intended.

Preview

This preview covers GPU memory allocations, not GPU compute utilization. Your existing GPU metrics tell you that something is going on; the profile gives you specific details on where it is happening.

From guessing to seeing

A GPU memory profile is a record of where allocations occur across your application's function call paths while the workload runs. Instead of showing only how much memory is in use, it connects that memory to the functions that requested it. This gives you a path from the symptom to the code responsible.

In Grafana, the profile is visualized as a flame graph displayed in an icicle-style, top-down layout. Each block represents a function in a call path, and wider bars represent more attributed GPU memory. That helps you identify where to investigate and make targeted changes.

GPU memory profile flame graph showing allocation call paths

You don't add profiling code to your app, and you don't need a sidecar or pod restart to turn it on. Enable profiling on the cluster before deploying your workload, or enable it while an existing workload is running so its CUDA allocation calls can be captured. Profiling won't decide for you that an allocation is wasteful, and it won't tune your workload automatically. It gives you the evidence to decide what your workload needs.

How it works

GPU memory profiling on AKS runs on Inspektor Gadget, an open-source, eBPF-based observability framework for Kubernetes and a CNCF project that Microsoft helps maintain. For GPU profiling, it traces CUDA memory-allocation calls directly from the node, which is why there's no profiling code or sidecar container needed. Enable profiling before deploying the workload, or restart it afterward when you need to capture allocations that occurred during startup.

It's also secure: the Inspektor Gadget project recently completed its first independent security audit; three issues were found and fixed in version 0.51.1.

Results flow into Pyroscope and show up in Grafana as flame graphs rendered in a top-down layout. Pair that with Azure Monitor managed service for Prometheus, and you get memory pressure in one panel and the code path behind it in another.

For more details and to get started, check out the AKS GPU profiling documentation, which covers the prerequisites, extension installation, and wiring up Pyroscope, Grafana, and the dashboard.

A real before and after

A GPU memory flame graph shows which function call paths are responsible for GPU memory allocations. Unlike a distributed trace, it doesn't show operations in chronological order. Instead, it combines many allocation call stacks into a single aggregated view.

The diagram below illustrates the basic idea in the same top-down orientation used by Grafana. Each block represents a function in a call path, stacked blocks show caller-to-callee relationships, and wider blocks represent more attributed GPU memory. The diagram is conceptual, not an actual AKS profile; its colors and example hotspot are illustrative rather than indicators of memory waste.

Conceptual flame graph illustration in the same top-down, icicle-style orientation used by Grafana. Read from top to bottom. Wider blocks mean more GPU memory is attributed to that function or call path.

In the Grafana view below, read the graph from top to bottom. Start at the total allocation at the top and follow the function calls downward. Each horizontal bar represents a function. Its width represents the memory attributed to that function and the functions it calls, while horizontal position does not represent time. A tall stack of equally wide bars does not mean each function allocated that memory separately; the same allocation is attributed through the call path.

The AKS documentation includes a vLLM inference example. At the top, the profile shows 65.9 GiB of attributed allocations. One wide branch accounts for 55.1 GiB. Follow that branch downward through the Python and vLLM call stack to find where the memory was allocated.

Expanded Grafana flame graph for a vLLM workload showing GPU memory allocation call stacks

Expanded flame graph from the AKS documentation. Read from top to bottom, following the widest allocation path toward the function with high self memory allocation.

Two terms help you interpret the bars:

• Total: memory attributed to a function, including allocations made by functions it calls.
• Self: memory allocated directly by that function, rather than deeper functions in the recorded stack.

A bar can show 55.1 GiB of total allocation with little or no self allocation because the memory was allocated further down its call path. Keep following the branch downward until you find high self allocation. In this example, that leads to GPUModelRunner._allocate_kv_cache_tensors, which the profile attributes with approximately 55.1 GiB of self allocation. This function creates the KV cache tensors that vLLM uses to reuse previously computed attention keys and values during inference.

The flame graph identifies where memory was allocated, not whether that allocation is unnecessary or the underlying cause of an out-of-memory error. The profile also describes recorded allocations, which are not necessarily the same as the amount of GPU memory simultaneously in use.

A large KV cache isn't automatically a problem; it's doing real work. The real question is whether it's sized for the traffic you actually serve. For a vLLM service, that usually means comparing your configured context length and concurrency against real-world usage, then right-sizing the settings that control them.

Here's a loop to find and fix issues in the flame graph data:

1. See the memory pressure.
2. Find the allocation path in the flame graph.
3. Change one setting, based on what your workload actually needs.
4. Run the same load again, and profile it again.
5. Compare memory, performance, and reliability before you call it done.

What this means for reliability, capacity, and cost

Reliability is the most direct win. When you can trace an out-of-memory failure back to a specific allocation, you fix the actual cause instead of guessing, and you can prove it by profiling again.

Memory efficiency comes next. You might find memory you can safely give back, or confirm the workload genuinely needs what it has. Both answers are useful: one frees up headroom, the other stops you from "optimizing" something that didn't need it.

Capacity and cost are downstream of both. A validated drop in memory use might let you fit more work on the GPUs you already have, or reconsider the GPU size you're requesting; call it responsible resourcing. The profiler isn't a cost calculator and won't resize nodes for you, so you still have to test the change and do the math yourself.

Either way, the decision is now backed by a real allocation path and a repeatable test, not a hunch.

One more example: fine-tuning Stable Diffusion XL on KubeRay

Everything so far has focused on inference, but the same workflow applies to training. The KubeRay GPU profiling demo for AKS with Anyscale spins up an AKS Automatic cluster with GPU Node Autoprovisioning, Inspektor Gadget, Pyroscope, Azure Monitor managed Prometheus, and Azure Managed Grafana.

The demo runs Anyscale's Fine-tuning Stable Diffusion XL with Ray Train template: DreamBooth LoRA fine-tuning across four GPU workers, moving through model loading, training, checkpointing, and image generation.

It's a useful reminder that profiling isn't just for inference. Watch the metrics, find the allocation path, make one change, profile again; the loop works whether you're serving a model or training one.

Try it yourself

Start with the GPU profiling documentation on Microsoft Learn for setup. Once you're running, it's worth exploring the open-source contributions:

• Inspektor Gadget
• Advanced GPU Observability dashboards
• Pyroscope

Preview

GPU memory profiling on AKS is in preview, so there could be breaking changes as the product evolves in response to feedback. Point it at a workload, see what the flame graph can tell you, fix your GPU allocation issues, and share feedback with us on what you find useful and what could be improved.