Kategorie: Microsoft Azure

The Platform Behind the Next AI Breakthrough

This article has been written and paid for by Microsoft. The content is not WIRED editorial content. The content does not necessarily reflect the views of WIRED, its affiliates, or owner, and does not reflect any endorsement direct or indirect of Microsoft, its affiliates, or other clients.

The next frontier of AI is coming into focus as agents take on longer, more strategic work. They can write and validate code, coordinate across systems, rebalance inventory as conditions change, manage production operations, or carry a migration from plan to completion. AI is no longer supporting one step; it is executing and reshaping the process itself.

New models help drive this change by expanding what AI can reason about, create, and accomplish. But the combination of advances in models and infrastructure is key to moving agents from isolated tasks to sustained, high-impact work. Realizing that potential requires silicon, compute, storage, and networking to work together so workloads run faster and more reliably at scale.

Agents Are a Different Kind of Workload

Cloud infrastructure has evolved before to support new kinds of applications. Even the most advanced cloud-native applications often followed predictable request-and-response paths. To deliver this at scale, cloud-native architectures turned to containers, distributed services, and dynamic scaling, to make the platform more automated and flexible. Agentic applications build on that foundation but introduce another shift: long-running work whose path and resource needs are dynamic and often unpredictable.

An agent may work for hours or days, moving between reasoning, data retrieval, tool use, and code execution while preserving progress between steps. Its needs may shift throughout the task. It might require a burst of computing power for one step, fast access to large amounts of data for another, and then pause while another tool or another agent finishes its work. Supporting this ebb and flow requires the platform to evolve again—this time around how agents operate.

Infrastructure Must Work as One System

Every layer of infrastructure is evolving for AI. Compute must respond to the changing demand of agentic workloads. Storage must preserve progress across long-running work. And networking must move data quickly among models, tools, and business systems. But improving each layer independently is no longer enough.

Agent performance depends on how well those layers are evolving and how well they all work together. More computing power will not help if the platform cannot move data quickly or maintain progress between steps. Silicon, compute, storage, and networking need to be co-designed and continuously optimized as one system.

This integrated approach also changes infrastructure operations. Teams need a complete view of performance, capacity, and cost so they can find bottlenecks and improve the full workload instead of tuning one component at a time. That system-wide view helps turn infrastructure improvements into faster, more reliable, cost-effective workloads.

Different Workloads, One Operational Approach

That consistent operational view becomes even more important as teams choose different technologies for different workloads. A customer-facing agent may prioritize low latency, while a complex workflow may need deeper reasoning. Teams need the freedom to choose the right model, run time, silicon, and environment for each workload while balancing performance and cost.

But more choice can create operational complexity because each combination may require a different approach to deployment, monitoring, and optimization. An integrated platform preserves flexibility while giving teams a consistent way to operate across models and infrastructure. Teams can choose what works best without managing every combination differently.

Levi Strauss & Co. And the Value of an Integrated Platform

Levi Strauss & Co. began its path to AI transformation by preparing existing business systems for the future. The company moved its data centers to Microsoft Azure, consolidated ERP platforms, modernized applications, and unified its data in a governed, real-time layer. But that was only the beginning.

Levi Strauss & Co. is now building a unified “super agent” to coordinate more than 1,000 domain-specific agents. Its platform must support both the critical processes that run the business today and a new class of intelligent workloads that coordinates work across functions. The lesson is clear: A durable platform must be built for current applications and whatever AI makes possible next.

Three practical tests for an agentic platform

Technical leaders can begin with three questions to assess readiness for an agentic platform.

First, do I have the high-performance compute, storage, and networking that models and agents need—or am I trying to run tomorrow’s applications on yesterday’s platform?

Second, can I choose the right model, run time, silicon, and location for each agentic workload while balancing performance, cost, complexity, and risk?

Third, can I use agents to operate the platform by moving workloads into production faster, resolving incidents before disruption, and continuously improving performance, reliability, and AI economics?

Building for the next decade

The next decade of AI will not be defined by a single breakthrough. Models will become even more capable, agents will take on work we have not yet imagined, and infrastructure demands will shift with them. Organizations need a durable platform that can embrace each new wave of innovation without being rebuilt whenever the frontier moves.

Azure is the platform foundation for that future. Microsoft has spent years bringing some of the world’s most advanced and demanding AI solutions online at massive scale. The lessons from that work continually shape Azure silicon, compute, storage, networking, and operations—and make those capabilities available to customers.

This is the opportunity of Frontier Transformation: continually turning advances across the AI stack into new ways to operate, compete, and grow.

Learn more at azure.com.
The post The Platform Behind the Next AI Breakthrough appeared first on Microsoft Azure Blog.
Quelle: Azure

Azure Cloud HSM Hardware Audit Logging: Verifiable audit trails for security and compliance

Organizations running regulated and security-sensitive workloads need trusted evidence of which authenticated users performed management operations on their hardware security modules (HSMs), what actions they took, and when. Today, we are announcing Hardware Audit Logging for Azure Cloud HSM, which collects audit records generated by the HSM itself for supported management operations. Security, compliance, and operations teams can use this hardware-originated evidence for monitoring, compliance reporting, and forensic investigations.

Learn more about Azure Cloud HSM

Why hardware-generated audit evidence matters

HSMs protect some of an organization’s most sensitive cryptographic assets. The security of those assets depends not only on how keys are generated and protected, but also on how the HSM is configured and administered over time. Authentication events, user changes, policy updates, backup operations, and key lifecycle activity can all be important when teams investigate an incident, validate operational controls, or prepare evidence for an audit.

Traditional platform and application logs remain valuable, but regulated organizations often want evidence that originates as close as possible to the protected cryptographic boundary. By sourcing audit information directly from the HSM, Azure Cloud HSM provides records tied to the device performing the protected operations. This gives customers an additional layer of evidence for understanding administrative activity and validating the records incorporated into their monitoring and compliance processes.

Monitor HSM management operations with hardware-generated audit logs

Hardware Audit Logging captures a broad range of HSM management activities, including:

User authentication and session events.

User and administrator management.

Policy and configuration changes.

Key lifecycle operations.

Backup and restore activities.

Together, these events help organizations build a more complete view of how the HSM is being operated. Security teams can examine authentication and administrative activity, compliance teams can use the records as evidence for control assessments, and operations teams can investigate configuration or lifecycle changes that may affect a protected workload.

Independent, end-to-end audit verification

Customers can access human-readable audit records, the corresponding HSM-signed binary audit data, signatures, and HSM certificates needed to independently verify the authenticity and integrity of signed audit batches. This customer-controlled verification path helps connect the records used in monitoring and reporting back to the signed evidence produced by the HSM.

This approach is important because auditability is not only about collecting readable events. It is also about establishing confidence in where the records came from and whether the signed audit batches remain intact.

Maintain consistent audit coverage for supported management activity

Audit logging is enabled as an immutable HSM partition policy. This design helps maintain consistent coverage of supported management activity and reduces the risk that logging could be disabled as part of routine HSM administration. For organizations that separate cryptographic administration, security monitoring, and compliance responsibilities, continuous hardware-originated logging can support clearer oversight across those functions.

The capability is designed to complement an organization’s existing governance model. Customers remain responsible for configuring access to their monitoring environment, defining retention requirements, establishing alerting and review processes, and determining how audit evidence should be used within their control framework. Hardware Audit Logging provides the HSM-originated records and verification materials that those processes can use.

Integrate HSM audit data into security operations

Hardware Audit Logging is designed for organizations with stringent compliance and security requirements, including financial services, payment processing, government, critical infrastructure, and other highly regulated industries. These organizations may need to demonstrate that sensitive cryptographic systems are administered through controlled processes and that important management activities can be reviewed after the fact.

Audit events are delivered to Azure Monitor Log Analytics, enabling customers to incorporate HSM management activity into broader monitoring, investigation, and security operations workflows, including Microsoft Sentinel. Centralizing these events alongside other relevant operational and security data can help teams correlate HSM activity with events elsewhere in the environment, apply queries and analytics, and support established investigation and reporting workflows.

For example, a security operations team may want to review unexpected authentication activity, an administrator change, or a policy update in the context of related Azure activity. A compliance team may need evidence that privileged management operations were logged during a defined assessment period. An incident response team may need to reconstruct the sequence of HSM management events surrounding a security investigation. Hardware-originated audit records provide an important source for each of these scenarios.

Strengthen HSM auditability with verifiable evidence

Azure Cloud HSM provides more than log visibility. Readable audit records support day-to-day operations. It also provides HSM-signed binary evidence, signatures, certificates, and verification utilities behind those records, which lead to an independent way to trace each record back to the HSM that signed it.

It also allows for keeping that evidence outside the logging workflow and checking it cryptographically whenever an audit or investigation calls for it, instead of relying only on delivered text records. Teams get an audit trail they can verify for the workloads that matter most.

What does Azure Cloud HSM Hardware Audit Logging provide

It provides hardware-generated records for supported HSM management operations, sends audit events to Azure Monitor Log Analytics, and gives customers signed binary audit data and verification materials for independent validation.

Azure Cloud HSM Hardware Audit Logging availability

Hardware Audit Logging is rolling out across Azure Cloud HSM public regions and is automatically enabled for newly provisioned Azure Cloud HSM resources where the feature is available. Customers should review current Azure Cloud HSM regional availability and product documentation for the latest availability details and configuration guidance.

Review the resources below to learn about Azure Cloud HSM, configure operation audit logs, and confirm regional availability.

Overview of Azure Cloud HSM

Configure and query HSM operation audit logs for Azure Cloud HSM

Azure products available by region

Azure Cloud HSM

Manage HSMs used in the cloud.

Get started

The post Azure Cloud HSM Hardware Audit Logging: Verifiable audit trails for security and compliance appeared first on Microsoft Azure Blog.
Quelle: Azure

Scale reservoir uncertainty analysis with agile reservoir modeling

Turn subsurface uncertainty into decision-ready insight

Drilling campaigns are among the most expensive and operationally complex activities in the energy industry. Rigs, crews, equipment, and logistics are scheduled months in advance, leaving little room for delay. Every hour of downtime can carry significant costs. Geoscientists and engineers rely on reservoir models to understand the subsurface and guide drilling decisions, often under intense time pressure. Yet the current modeling infrastructure that many companies rely on for these critical decisions was designed for smaller datasets, simpler workflows, and siloed operations. As subsurface data grows in scale and complexity, teams need a faster, more connected way to transform uncertainty into actionable decisions.

Now generally available, agile reservoir modeling (ARM) from SLB, integrated with Azure Data Manager for Energy (ADME), is co-engineered for cloud scale to close that gap. The combined solution connects ensemble-centric reservoir modeling and simulation with a governed data foundation, elastic Azure high-performance computing, and scalable storage designed for the throughput and concurrency of large ensemble studies.

Learn more about Azure Data Manager for Energy

Scale ensemble modeling with ARM on Azure

A single reservoir model represents one plausible interpretation of the subsurface. Ensemble modeling evaluates hundreds of model realizations together, giving asset teams a broader view of potential outcomes and a stronger basis for understanding uncertainty and risk.

The industry has long recognized the value of ensemble modeling for risk-aware decision-making, but adoption has been constrained by infrastructure and software designed for smaller, sequential studies. Moving from a limited model set to hundreds of realizations multiplies the compute, storage, data movement, and results that must be managed. ARM addresses this barrier by distributing realization generation and simulation across elastic Azure high-performance computing, while scalable storage provides the capacity, throughput, and parallel access required by ensembles of different sizes.

Connect reservoir workflows to a governed data foundation

Building and updating reservoir models draws on many systems: seismic, wellbore, interpretation, and simulation data, plus the applications and compute that process them. When these pieces are fragmented, customers must connect and orchestrate them on their own, and large-scale simulation becomes a disconnected, one-off exercise.

SLB and Microsoft combined their respective technologies, ARM engineered by SLB and ADME engineered by Microsoft, to remove that burden. Rather than a set of loosely connected tools, customers get one integrated workflow in which each component has a clear role:

Azure Data Manager for Energy is the governed data foundation. OSDU® Technical Standard-aligned services and OSDU Domain Data Management Services (DDMS) manage seismic, wellbore, interpretation, and simulation data.

Petrel™ subsurface software is where engineers define interpretation and uncertainty workflows, connected directly to data in ADME.

Agile reservoir modeling is the ensemble workflow engine. It orchestrates the generation of reservoir realizations and simulation runs and supports discovery and analysis at enterprise scale.

As a result, teams build ensembles from trusted corporate data and publish results back for discovery and reuse, which reduces data movement and improves collaboration across asset teams.

Put ensemble modeling into practice with a connected workflow

Beyond integration and scale, ARM distinguishes itself by orchestrating all stages of an ensemble study across modeling, simulation, data management, and analysis. The workflow tightly connects the tools reservoir teams already use with Azure-scale infrastructure and the governed data services provided by Azure Data Manager for Energy.

Agile Reservoir Modeling workflow using cloud HPC to generate and simulate multiple reservoir-model realizations in parallel delivered to web-based interface for analysis.

A walkthrough of how this works today:

Reservoir engineers define uncertainty workflows in Petrel software and prepare simulation models for supported SLB simulators, including the Intersect™ reservoir simulator and Eclipse™ reservoir simulator. ARM generates the realizations, prepares the simulation cases, and coordinates their execution across the Azure environment.

Azure high-performance computing executes multiple realizations in parallel. A shared, high-performance Azure Files volume holds model inputs, grids, simulation decks, temporary files, and results so the simulation fleet can read and write concurrently. Because compute capacity, storage capacity, throughput, and IOPS can be scaled independently, the environment can be sized for the concurrency of the ensemble rather than the constraints of fixed infrastructure.

As simulations complete, SLB reservoir engineering services manage the resulting ensembles and use OSDU search capabilities on ADME to support discovery, filtering, and sorting across large studies. Teams can locate relevant realizations and supported, published results without manually navigating disconnected project stores.

Engineers can analyze ensembles in the reservoir engineering workspace or load them back into Petrel software for further interpretation, history matching, and reservoir engineering studies. This allows teams to work in the environment and application best suited to each task while maintaining continuity, without having to step outside their workflow to manage orchestration.

ADME provides entitlement-based access control integrated with Microsoft Entra ID and supports compliance controls such as OSDU legal tags. Connecting ARM workflows to this governed data foundation helps maintain consistent access and compliance as corporate subsurface data is used across modeling and simulation. Because ARM workflows are integrated through Petrel software in ADME, reservoir engineers can perform ensemble-scale studies leveraging their corporate-wide data stores and publish results for discovery, eliminating friction and driving collaboration. Microsoft and SLB engineering collaborated closely to build the integration between Petrel software and ARM for enterprise-scale performance.

For reservoir engineers and asset teams, ARM turns ensemble modeling into a repeatable workflow rather than a bespoke infrastructure project. Teams can stress-test development concepts against calibrated ensembles that honor observed production history, not simply run a larger number of models. As new wells are drilled and new data becomes available, they can update their reservoir understanding without waiting for a major model rebuild. For energy IT and data leaders, the workflow connects simulation to an OSDU standard-aligned architecture with consistent identity, governance, search, and interoperability, reducing isolated data copies and disconnected applications.

The future of the reservoir lifecycle

Building on this partnership, Microsoft and SLB are working within the OSDU community to advance a more cloud-native standard for reservoir data. This work will help models, simulation results, and engineering workflows operate more consistently across applications, improving interoperability while reducing dependence on proprietary formats and silos. A shared, governed data foundation also paves the way for AI and agentic experiences that can discover data, coordinate workflows, and surface insights across the reservoir lifecycle. Combined with Azure-scale compute and storage, this creates a path toward more automated and continuous reservoir modeling.

Get started with ARM on Azure Data Manager for Energy

Agile reservoir modeling on Azure Data Manager for Energy is generally available today. Learn more about agile reservoir modeling from SLB and Azure Data Manager for Energy. Contact your Microsoft and SLB account teams to identify an initial reservoir workflow and discuss the path to deployment.

Azure Data Manager for Energy

Accelerate your energy intelligence.

Get started

The post Scale reservoir uncertainty analysis with agile reservoir modeling appeared first on Microsoft Azure Blog.
Quelle: Azure

Designing for sovereign AI: A shared foundation from edge to cloud

As organizations apply AI to more business-critical and data-intensive workloads, AI processing is moving closer to where data is created, decisions are made, and operations take place.

Manufacturers can analyze confidential production data next to the systems that generate it.

Pharmaceutical companies can apply AI to clinical trials within controlled environments.

Government agencies can run AI applications on sensitive information while maintaining established security and operational boundaries.

This shift reflects ongoing innovation across the technology ecosystem to give organizations greater flexibility in where they run AI and process sensitive data, and it is changing the digital sovereignty conversation. It now encompasses where data is stored and processed, where workloads run, who can access and operate the systems around them, and how those systems remain secure and operational as requirements change. The next phase of digital sovereignty will take shape across the technology ecosystem, through closer alignment among silicon, infrastructure, cloud, security, data, and AI.

Learn more about digital sovereignty

As AI extends into more sensitive and mission-critical workloads, sovereignty must be designed across the stack, from silicon and infrastructure to cloud, data, and AI. Microsoft and Intel® are working together to help organizations create a more consistent foundation for innovation, while retaining greater choice over where workloads run and how they are controlled.

A flexible sovereign architecture allows organizations to place each workload in the right environment, apply the controls it requires, and maintain a more consistent technology and operating foundation as requirements evolve.

Sovereignty must work across the technology stack

Sovereignty requirements vary by workload. The right level of control depends on factors such as data sensitivity, regulation, latency, connectivity, operational access, and resilience requirements. This creates a continuum, where organizations can apply different levels of control across public cloud, customer-controlled environments, and trusted partner solutions.

Delivering that flexibility requires the underlying technology layers to work together. The controls that shape where a workload runs, how data is protected, who can access it, and how the environment is verified extend across silicon, infrastructure, cloud, security, data, and AI.

This is where the Microsoft and Intel partnership comes into focus. Together, we are working to create a more consistent foundation across these layers, giving organizations greater choice in where workloads run and how they are controlled. This principle is central to the work between Microsoft and Intel. Azure Local, running on Intel® Xeon® 6 processors, brings distributed Azure infrastructure together with a common compute foundation for customer-controlled environments. Organizations can extend cloud and AI capabilities closer to their data and operations while maintaining consistent approaches to security, management, and governance.

Trust must be designed for and verified

For sensitive workloads, trust must be supported by technical protections and verifiable evidence. Organizations need to protect workloads across the technology stack and verify that systems are operating under the security conditions they have established.

That starts at the compute layer and extends through identity, encryption, governance, policy, and operations. For supported Azure Confidential VM configurations, Intel® Xeon® processors provide hardware-based protections, including Intel® Trust Domain Extensions (Intel TDX), which can help isolate workloads while they are in use. Hardware-backed attestation can provide evidence that helps organizations verify relevant security properties of the environment against their requirements. Microsoft extends this foundation through security and governance controls across cloud and customer-controlled environments.

Together, these capabilities can help organizations verify relevant security properties of the environment against their requirements. This is particularly important as AI brings regulated, proprietary, and mission-critical data into new workloads.

Each workload should receive protections proportionate to its risk. Isolation, encryption, attestation, and operational controls can be applied where they provide meaningful value while preserving a manageable operating model across the broader environment.

Digital sovereignty requires trust across the technology stack. Together, Intel and Microsoft are combining hardware-based security and confidential computing with cloud, AI and distributed infrastructure to help customers protect sensitive workloads and verify the environments in which they run. This shared foundation gives organizations greater control, confidence and choice, with the performance and scale to continue innovating as AI moves into more regulated and mission-critical environments.
—Anand Pashupathy, Vice President and General Manager, Intel Product Assurance and Security

Sovereign AI brings intelligence closer to data

Much of the data with the greatest potential for AI must remain within defined operational, regulatory, or security boundaries. This includes data tied to industrial operations, government services, clinical environments, intellectual property, and proprietary research.

Workload placement has therefore become a practical AI decision. Organizations need the flexibility to run AI closer to their data, applications, and operations. Delivering that flexibility requires infrastructure, cloud platforms, AI software, and security capabilities to work as a connected foundation.

Microsoft Foundry helps organizations build and deploy AI applications and models, with options for where AI runs based on their requirements. Foundry Local enables organizations to run AI inference in their own environments, closer to the data and applications those models rely on. On the same infrastructure, Intel Xeon 6 processors with Intel® Advanced Matrix Extensions (Intel AMX) can accelerate AI workloads directly on the CPU. Intel® OpenVINO™ helps developers optimize and deploy models across supported infrastructure.

This approach extends across the broader application environment. Organizations may need to manage AI, applications, data, development, and productivity workloads within the same governance and operational boundary. Microsoft 365 Local and GitHub Enterprise Local extend customer-controlled options to collaboration, source code, and software development workflows.

Sovereign AI brings models, data, applications, development tools, and infrastructure together under the controls each workload requires. This approach allows organizations to apply AI within the operational and governance boundaries established for their most sensitive data.

Organizations want to apply AI to their most valuable data while maintaining the controls that data requires. On supported Azure confidential VM configurations, Intel TDX helps make that possible by running AI workloads in hardware-isolated trust domains, protecting models and data while in use and isolating them from the host and hypervisor. Hardware-backed attestation then gives organizations evidence they can check against their own requirements, so they can move from trusting their environment to verifying it.
—Anand Pashupathy, Vice President and General Manager, Intel Product Assurance and Security

Sovereignty architecture must be adaptable

Sovereignty requirements will continue to change. A workload that runs in a connected environment today may face different regulatory, resilience, or connectivity requirements tomorrow. AI models, applications, and infrastructure will also continue to evolve.

A sovereign architecture must therefore provide control without creating rigidity. Organizations should be able to adapt where workloads run, how they are secured, and how they connect without rebuilding their management and security model each time requirements change.

This is another reason partnership across the technology stack matters. Alignment across silicon, infrastructure, cloud, security, and AI software can give organizations a more stable foundation even as individual technologies and workload requirements evolve.

A well-designed sovereign architecture gives organizations room to respond as regulations, technologies, and operating conditions change.

Explore Microsoft Sovereign Cloud in Europe

Discover how Microsoft Sovereign Cloud in Europe helps organizations address evolving data sovereignty, security, and compliance requirements while accelerating cloud and AI innovation.

Learn more

Three questions leaders should ask

Digital sovereignty can become abstract quickly. A better place to start is the workload.

1. What must remain under your control?

Consider the data, infrastructure, administrative access, software operations, and connectivity on which the workload depends. The answer may differ by application, even within the same organization.

2. Can you verify that those controls are working?

Policies and contractual commitments are important, but sensitive workloads may also require technical evidence. Consider how your architecture supports encryption, isolation, identity and access control, policy enforcement, attestation, and operational transparency.

3. Will the architecture leave you room to adapt?

AI capabilities, regulations, operating conditions, and workload requirements will continue to change. Your architecture should allow you to adopt new models, move processing closer to data, and adjust where workloads run without creating an entirely separate technology environment each time.

Digital sovereignty depends on cloud, infrastructure, security, AI, and silicon working together. Our collaboration with Intel gives customers a more consistent foundation across these layers, so they can apply stronger controls where needed while retaining the flexibility to innovate.
—Bernardo Caldas, CVP, Azure Edge Product Management

The strongest sovereignty strategy preserves choice

Digital sovereignty should give organizations greater control over the technology and data they depend on while preserving their capacity to innovate.

Achieving that outcome requires collaboration across the technology ecosystem. Microsoft and Intel are connecting silicon, infrastructure, cloud, security, and AI to give organizations greater flexibility in where workloads run, how they are protected, and how they evolve.

A shared foundation across these layers allows organizations to apply the right controls to each workload and benefit from advances across the broader technology ecosystem.

A strong sovereignty strategy meets today’s requirements while preserving tomorrow’s options.

Resources to learn more

Dive deeper into digital sovereignty to learn how Microsoft is helping organizations address data residency, operational control, security, and regulatory requirements across cloud and customer-controlled environments.

Learn more about Microsoft Sovereign Private Cloud.

Join us at Microsoft Ignite in November to hear the latest on Microsoft Sovereign Cloud, Azure Local, AI, security, and infrastructure innovation.

Azure Local

Learn how organizations can run distributed infrastructure and applications with a consistent Azure experience

Read more

The post Designing for sovereign AI: A shared foundation from edge to cloud appeared first on Microsoft Azure Blog.
Quelle: Azure

Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms

We’re proud to share that Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms. We believe this recognition comes at an important moment for enterprise infrastructure. The question is no longer simply which hypervisor to run. It is how to create a consistent operating model across cloud, datacenter, edge, and sovereign environments. Microsoft addresses that challenge at two levels: operational consistency through Azure and Azure Arc, and infrastructure consistency through Hyper-V.

Read the report

From choosing a hypervisor to choosing an operating model

For years, the primary virtualization decision was which hypervisor to run. Today, the more consequential decision is how infrastructure will be operated across every environment the business depends on. Virtualization remains a critical foundation, but the value of the platform increasingly depends on how infrastructure is managed, governed, secured, updated, and connected across environments. As infrastructure becomes more distributed, how it is operated becomes as important as where it runs.

Microsoft delivers that consistency at two complementary levels:

Operational consistency: Azure provides common management, governance, and security across cloud, datacenter, and edge environments. Azure Arc extends those capabilities to distributed infrastructure, giving organizations a unified way to operate diverse environments.

Infrastructure consistency: Hyper-V provides a common virtualization foundation across Azure, Azure Local, and Windows Server, helping organizations maintain a consistent infrastructure layer wherever workloads run.

Together, these layers help organizations preserve choice without multiplying operational models. Workloads can move, environments can evolve, and new technologies can be adopted without requiring a separate operating model for every environment.

Ready for what comes next

Operational and infrastructure consistency will become even more important as AI reshapes enterprise IT. Models, agents, applications, and data will increasingly span cloud, datacenter, edge, and sovereign environments. AI alone will not reduce the complexity of distributed infrastructure; in many cases, it will increase the need for common management, governance, security, and infrastructure foundations.

Being named a Leader in this Magic Quadrant is an honor for us. More importantly, we believe it reflects a direction many organizations are pursuing: operational consistency across increasingly distributed environments. We remain committed to helping customers combine the flexibility to run workloads where they choose with the consistency required to manage them as one environment.

Recognized as a Leader

in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms

Read the report

Gartner, Magic Quadrant for Server Virtualization Platforms, Tony Harvey, Daniel Bowers, Paul Delory, Tony Iams, Owen Marino, 14 September 2026.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Microsoft here.
The post Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms appeared first on Microsoft Azure Blog.
Quelle: Azure

Evolving the cloud-native foundation for the next generation of AI

Building a cloud-native foundation for AI

The relationship between model innovation and AI infrastructure has never been more clear; as AI becomes more capable, the platform underneath it matters even more. Agents are fundamentally changing how applications work, and with that, what organizations need from the cloud.

Learn how to build a cloud-native AI foundation

Cloud-native practices gave organizations the scale, flexibility and resilience to build a generation of distributed applications. Agents build on that foundation, but they work differently, placing new demands on it. Unlike applications designed around more predictable workflows, agents behave in entirely new ways, gathering information and deep intelligence from across the business, using tools, making decisions, and coordinating work across long-running processes. To complete complex tasks, they pause for approval, respond to new information in real time and change course as conditions evolve. All this changes what the platform needs to deliver.

Customers need infrastructure that adapts as demand changes, applications that remain reliable as work becomes more dynamic, and the visibility and control to understand what is happening across the system. Meeting those needs doesn’t mean starting over, but it does require that the cloud-native foundation organizations already rely on, to evolve. Compute, storage and networking need to work together. Application platforms need to make it easier to build and run AI workloads. Open technologies need to give customers flexibility without adding unnecessary complexity.

The platform decisions organizations make today are increasingly strategic, shaping how effectively they can put AI to work for their business. Evolving the cloud-native foundation is essential to helping organizations get more from AI today while giving them the flexibility to take advantage of new capabilities as they emerge.

Optimize infrastructure for AI workloads

The true measure of AI infrastructure is the useful work it enables. AI workloads rarely place the same demands on infrastructure from beginning to end. Different parts of the work may need accelerated compute, CPUs, fast access to data or connectivity across applications and environments. The answer isn’t simply more capacity, but rather, to match the right resources to the right work at the right time.

That makes coordination across the infrastructure extremely important. Compute, storage and networking need to work together as demands change. When they do, teams can spend less time managing infrastructure and more time focused on the applications and outcomes that matter to their business.

Economics matter, too. Infrastructure needs to be tuned to the demands of the application and the business value it delivers, with the right balance of performance, reliability and cost across the complete workload.

Basecamp Research is one example. The company used Azure to assemble 9.7 trillion nucleotides for EDEN, its therapeutic-design models, and reported laboratory validation across three therapeutic applications within about three weeks. In this example, AI didn’t simply require more infrastructure, it needed AI infrastructure that was coordinated and designed around the outcome – bringing together the compute, data and platform capabilities needed to move complex work forward.

As Glen Gowers, co-founder of Basecamp Research put it: “To really be successful here, we need those three ingredients to come together. We need someone scaling the data; that’s us. But someone who really knows how to scale models and scale compute is Microsoft.”

Leadership takeaway: Measure success by the useful work AI completes. Judge infrastructure investment by the performance, reliability and cost of delivering those outcomes, with compute, storage and networking operating as one system.

Turn open-source innovation into production capability

Open technologies have long helped drive cloud innovation, and AI is accelerating that pace. New models, frameworks and cloud-native technologies give organizations more choice in how they build and adapt applications.

That opportunity builds on an established cloud-native foundation. Gartner forecasts that by 2028, 95% of new AI agent deployment will use Kubernetes.1 Reusing established components can shorten the path to production, allowing developers to focus on differentiated business capabilities rather than rebuilding the foundation.

More choice can also bring more complexity. Taking advantage of open-source innovation often requires specialized expertise to integrate, manage and maintain technologies in production. That expertise is hard to find and even harder to scale. We need to make these capabilities accessible to more businesses, without requiring every organization to build and maintain that expertise themselves.

Azure helps reduce that burden. Services like Azure Kubernetes Service give teams access to open-source innovation while helping manage the complexity and risk of running it in production. This makes it easier for more businesses to take advantage of open technologies while preserving the flexibility to adapt with changing needs.

Leadership takeaway: Choose a platform that helps turn open-source freedom into business advantage. Preserve the ability to adapt and optimize while reducing the expertise and operating effort required to sustain those choices in production.

Align AI infrastructure costs with business value

As more organizations put AI into production, understanding the economics becomes increasingly important. AI investment starts with an expectation of business value: faster decisions, more responsive services or greater capacity to get useful work done. Then, it’s evaluating whether the value justifies the investment to deliver it. FinOps can help teams understand that return and make more informed decisions in this area.

For customers, that starts with understanding the full investment required to run AI applications and how to optimize it as workloads scale. Models represent a significant expense, with token usage and agent behavior influencing spending. Compute, storage, networking and operations also factor into the equation. Considering these together helps customers make more informed decisions about where to optimize.

Learn FinOps best practices for compute

Teams can’t simply place their bets on spending less. They need to carefully consider that a more capable model or additional infrastructure that costs more may be the right choice if it produces greater value long-term. Teams need to understand the full cost, establish ownership and put guardrails in place as they scale. From there, they can use business outcomes to decide where to optimize and where to invest.

Leadership takeaway: Manage AI investment against the business return it needs to deliver. Evaluate model and platform costs together, then use evidence of outcome value to decide where to optimize and where to invest.

Transform cloud operations with agentic AI

Operations teams are already stretched thin, keeping critical services running while balancing competing priorities and constant change. AI adds new complexity, and it also creates an opportunity to change how those environments are managed.

Cloud-native operations gave teams a new model for managing infrastructure, bringing increased automation, visibility and resilience. Agentic operations build on that foundation, bringing deeper intelligence across applications and infrastructure by connecting signals from otherwise disconnected systems. This helps teams identify issues earlier and resolve them faster, while increasing automation and continuously improving how their environments perform; all within the tools they already use.

Over time, AI can help operations teams move from reacting to problems toward anticipating and addressing them before they disrupt the business. As these capabilities mature, more actions can be automated within defined controls, with people remaining in the loop and accountable for critical decisions. When operations teams have greater reach without additional manual effort, reliability, performance and cost are continuously improved while critical services remain uninterrupted.

Leadership takeaway: Invest in operations that can anticipate problems and coordinate action across the environment. Expand autonomy as capabilities are validated, with clear controls and human accountability protecting critical business services.

Automate operations with Azure SRE Agent

Build a cloud-native AI foundation on Azure

Azure serves as the foundation customers need to put AI to work at scale. That means infrastructure designed around the complete workload, access to open innovation without unnecessary complexity, and a clear view of cost and business value. Greater intelligence across cloud operations helps teams anticipate issues and continuously improve how their environments perform as application needs evolve.

We’re continuing to invest in capabilities across Azure that give customers greater flexibility in how they build and run AI applications. From secure, isolated environments for agents to simpler application deployment and the ability to run workloads across cloud and edge environments, these investments help customers take advantage of new capabilities without adding unnecessary operational complexity.

Get started with Azure Kubernetes Service (AKS)

AI is changing what applications can do, and Azure has already evolved to support that shift. The cloud platform has to evolve with them. Years of focused engineering investment have built the foundation for some of the most advanced AI workloads running today, with continued innovation to support what comes next.

Build for the next generation of AI

Platform value compounds when improvements reinforce one another: faster information access keeps compute productive, operational insight exposes waste, and open technologies preserve room to adapt. The leadership task is to make those gains work together. That is the next chapter of cloud native: a foundation that turns advances in AI into dependable business value.

To learn more about the recent Azure innovations and how Azure is evolving the cloud-native foundation for AI applications and agents, explore:

Flex Nodes for AKS

Azure SRE Agent

Azure Container Apps Sandboxes

Azure Container Apps Express

Explore what this means for your organization. Register for our upcoming discovery session to learn how to put a cloud-native foundation for AI applications and agents into practice.

Build your AI foundation

Learn how to put a cloud-native foundation for AI applications and agents into practice in our upcoming discovery session.

Register now

1 Gartner®, Magic Quadrant™ for Container Management, Dennis Smith, Wataru Katsurashima, et al., 6 August 2025

GARTNER and MAGIC QUADRANT are trademarks of Gartner, Inc. and/or its affiliates.
The post Evolving the cloud-native foundation for the next generation of AI appeared first on Microsoft Azure Blog.
Quelle: Azure

Deep dive into Azure Maia 300 architecture

From its inception, Azure Maia has been built around a single architectural philosophy: optimize the entire system for LLM inference so that every watt and every dollar delivers more intelligence. Now in its third generation, Maia 300 is the fullest expression of that philosophy. Maia 300 is built as a complete system, with software, silicon, physical rack infrastructure, networking, and datacenters co-designed to operate as a single platform to meet the demands of cloud-scale agentic inference.

Learn more about Maia 300 here

That system-level approach is increasingly necessary as agentic workloads, including multi-step execution, long-context decoding, and tool use, change the computational profile and arithmetic intensity of inference. Meeting these demands requires sustaining locality, supplying compute with enough memory capacity and bandwidth, minimizing data movement, scaling communication efficiently, and fitting the most capability within a datacenter’s fixed power and cooling envelope.

At Microsoft, we see this transformation firsthand through the products and platforms our customers use every day, from Microsoft Copilot and GitHub Copilot to Microsoft Foundry. Operating these workloads at scale gives us a unique view into how AI is being adopted across industries and the infrastructure needed to support the next generation of AI applications and agents. Maia 300 is designed to maximize useful tokens per watt and useful tokens per dollar, bringing more capacity, capability, and performance to these products and Microsoft’s broader AI portfolio for our customers.

Energy-efficient inference through software-defined dataflow

Maia 200 introduced a new class of accelerator architecture called Software Defined Locally Accessed Dataflow Architecture, or SDLA. It begins with the observation that efficient data management, including storing, moving and converting data, is one of the central challenges in modern AI systems. The Maia programmable dataflow architecture separates control path programming from data path execution and allows software to explicitly coordinate data placement, movement, conversion and synchronization across specialized local memories, DMA engines, compute engines, and the network.

Maia 300 system-on-chip architecture

Maia 300 evolves this architecture for long-context, reasoning-intensive, and decode-heavy inference. First, memory moves from the uniform memory access (UMA) organization of the SoC to a locality-aware non-uniform (NUMA) organization across chiplets, so software can place data near the compute that uses it. Second, new narrow-precision formats with hardware-accelerated data type conversion reduce the bytes moved for each token. Third, the rack doubles to 96 accelerators and the scale-up domain grows to a superpod of 12,288 accelerators, enabling more accelerators to work effectively as a single system.

Rather than scaling performance through increased power and silicon area alone, Maia 300 improves performance per watt through a set of architectural innovations that optimize data movement, locality, precision, and memory efficiency across the system:

Multi-chiplet architecture boosts performance by placing compute on TSMC N2P, where the advanced process delivers the greatest performance-per-watt benefit, while separating memory-controller and I/O functions onto dies optimized for bandwidth, connectivity, and cost. This increases the silicon area dedicated to compute performance and allows each function to use the technology best suited to its role, while SDLA manages locality and data movement across the package. This strategy increases the system’s compute FLOPs by 36%, adds 2.5 times HBM bandwidth, and provides 14% more scale-up bandwidth.

Optimized low precision inference, introducing enhanced MXFP4 and sub-3-bit storage formats. Narrower representations reduce memory footprint and data movement, allowing the system to support larger models, longer contexts, and more concurrent sessions within the same power envelope.

Optimized inference kernel through ISA enhancement: The vector engine adds optimizations for key inference kernels, including softmax, low precision data casting, and other operations.

Efficient on-die data movement, Maia 300 changes memory from a uniform organization to a non-uniform (NUMA) one across chiplets. Each compute region has nearby memory, and SDLA’s explicit control over DMA engines, local SRAM, HBM and the network-on-chip places data next to the compute that uses it. Data travels shorter distances, which reduces the energy spent moving it.

Memory hierarchy optimized for bandwidth per watt, combining software-managed on-die SRAM with eight HBM4 stacks providing 288 GB of capacity and 18 TB/s of bandwidth per accelerator. Compared with Maia 200, this delivers 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt, keeping more model and KV state close to compute.

Maia 300 brings 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt compared with Maia 200

One scale-up fabric: From pod to superpod

Maia 300 makes the network a native extension of its software-defined dataflow architecture. Maia’s AI network controller implements custom AI transport based on Ethernet. A two-tier network builds a high-performance superpod with up to 12,288 accelerators. Maia presents one communication model to software—the same semantics to move data directly to any accelerator within a superpod.

Half-switched in-rack topologyEach accelerator divides its scale-up connectivity between direct links and switched paths. Direct links connect two accelerators in a tray, while the switched fabric connects all 96 accelerators in the rack to form a pod. All in-rack connectivity uses electrical links to reduce power and cost.

Optical second tier across racksSecond-tier switches connect up to 128 racks together to form a superpod. Optics provide the reach required to extend scale-up network across the pods.

One fabric from the accelerators in a pod to the superpod

One fabric rather than separate scale-up and scale-out domainsIntegrated network controllers and specialized AI transport use the same communication semantics inside the pod and across the superpod. Maia accelerators can directly initiate communication to any accelerator in the superpod, without involving the host or a discrete scale-out NIC.

Low-hop communication pathsThere are three latency domains: A direct connected accelerator pair is the lowest latency domain, then accelerators within a pod are one switch hop away, and any accelerator across pods is three switch hops away. Software can keep latency-sensitive tensor-parallel traffic local within the lowest latency domains.

Bandwidth allocated to the workloadThe bandwidth split between in-rack and cross-rack bandwidth per accelerator is not fixed at the system design time. It becomes a parameter that is set based on job packing. An accelerator can drive up to 750 GB/s to any peer within the superpod, when only a subset of accelerators are going cross-rack. Refer to the spare tray example below.

Flexible job placementTensor parallelism can remain within the 96-accelerator rack, while wider expert and pipeline parallelism span racks. Jobs can use capacity across rack boundaries, reducing stranded accelerators when workload sizes do not align with the physical rack configuration.

A 64-accelerator job can run as four 16-accelerator shards, one in each of four racks

Disaggregated inference within the scale-up domainPrefill and decode workers can be sized and placed independently. After prefill computation completes, KV state moves directly to the selected decode workers over the same scale-up fabric rather than leaving the domain through a separate host-mediated scale-out path.

Resilience across racksWhen accelerators become unavailable, schedulers can use hot-spare capacity in another rack within the superpod transparently to software kernels. The workload remains on the scale-up fabric, trading additional path latency for improved availability and resource utilization.

A spare tray in one rack can offset a failed tray in another rack

Rack-scale architecture for deployment efficiency

At datacenter scale, efficiency is determined by how much useful infrastructure can be deployed and operated within a fixed power and cooling envelope. Building on the foundational energy efficiency of the Maia SoC architecture, the Maia 300 rack co-designs server layout and density, network topology and switching, power and cooling design, and advanced telemetry to deliver up to 2.5x more performance per watt compared to Maia 200.

96 accelerators within 167 kWMaia 300 integrates 96 accelerators across 24 four-accelerator trays within a 167-kW rack, doubling the accelerator density of Maia 200. Each tray incorporates four accelerators with its host processor, memory, storage, and cooling. Eliminating separate host trays frees rack space and allows power and thermal resources to be managed as one system, increasing the inference capacity deployed within each rack.

Consolidated switch architectureSix high-radix switch ASICs are integrated into three liquid-cooled switch trays, providing the rack-local connectivity required by all 96 accelerators while minimizing the space and power consumed by switching.

Rack-level power deliveryDual power feeds, high-capacity power shelves, and a 50 V busbar architecture distribute power efficiently across accelerator and switch trays while providing operational redundancy. The integrated rack automatic transfer switch maintains high availability even when a single power feed is offline for servicing.

Flexible cooling architectureLiquid cooling removes more than 80% of the rack’s thermal load from accelerators, voltage regulators, and switch ASICs, while air cooling supports memory, storage, and other ancillary components. Maia 300 can connect directly to facility water where it is available or use a heat-exchanger unit to reject heat in air-cooled datacenter environments. This provides greater flexibility in where and how the system can be deployed at scale.

Datacenter-integrated telemetryWe have incorporated deployment learnings to strengthen reliability, availability, and serviceability (RAS), observability, debuggability, fault handling, and redundancy, improving robustness as we deploy additional volume. Rack and row level power telemetry connect with datacenter operations, enabling operating points to be managed against available power and cooling capacity. This data informs algorithms that dynamically allocate power and optimize workload placement and deployment density, improving utilization and tokens delivered per watt.

What Maia 300 delivers

Maia 300 is the next step in a multigenerational program to deploy efficient AI systems at scale. The design is optimized end to end across software, silicon, physical rack infrastructure, networking, and datacenters to deliver a leap in performance and efficiency for cloud-scale agentic inference.

Relative to Maia 200, Maia 300 delivers up to 7 times greater rack-scale token throughput in its full 96-accelerator configuration and more than 2.5 times the performance per watt. It brings more memory bandwidth per watt and twice the accelerators per rack, while building on SDLA, our software-defined dataflow architecture and a two-tier scale-up network to support a single programming model spanning kernel to data center scale. Together, these advances enable us to deliver more useful intelligence, more efficiently, to more people and organizations.

Maia 300 delivers up to 7 times greater rack-scale token throughput and more than 2.5 times the performance per watt compared with Maia 200

The opportunity ahead is not simply to build more compute. It is to make advanced AI capabilities more accessible, affordable, and useful. Maia 300 is an important step toward that goal.

Next month at Microsoft Ignite 2026 in San Francisco and online, we’re looking forward to sharing more information on our AI strategy, technology adoption trends, and success in Frontier Transformation.

Read about the latest Azure Maia 300’s news here.

Learn more about Azure Maia 300 here.

Learn more about Azure’s silicon to systems approach here.
The post Deep dive into Azure Maia 300 architecture appeared first on Microsoft Azure Blog.
Quelle: Azure