Kategorie: Microsoft Azure

The 2026 Agent Confidence Index: Where 300 builders see real momentum

A couple of months ago, I sat across from my nine-year-old daughter’s teachers at a parent-teacher conference. They were kind but concerned. She takes her time on assignments, they said—often deep in thought. How would she do on timed tests next year? I told them I wasn’t worried. What they described as a problem is, to me, one of the most important things she can learn: the ability to take a hard problem and reason through it from beginning to end. In a world optimized for efficiency, qualities like patience, perseverance, and attention to detail are not deficiencies. They are the foundation of sound judgment, which will become the skills we need most.

The more time I spend working with AI, the more convinced I become: the question that matters for her future isn’t how quickly she can answer. It’s whether she has the judgment to know when an answer can be trusted.

I’ve spent decades at Microsoft watching this tension play out: first building tools for other developers, then working across AI as models moved from research curiosities to systems deployed at scale. Now we’re building Microsoft IQ, where we’re exploring how an organization’s collective intelligence can become its greatest advantage. Through every one of those chapters, one thing has remained true: it’s never enough for a system to be powerful, it must also be trustworthy.

Trust is what turns assistance into delegation. When we can trust an agent to do what we intend, within the limits we set, we can hand off the work we never wanted to spend our lives on: the repetitive tasks that drain attention, the mundane work that fills a day without moving anything meaningful forward, the dangerous work humans should not have to do, the work too vast for any individual or team. Agents should take on that toil, extend our reach, and give us back our time for the work that calls for something only humans bring.

My daughter doesn’t know any of this yet. But by the time she’s grown, most of the work that rewards speed and repetition will be work we delegate. What will matter then is exactly what gave her teachers pause: the patience to stay with a hard problem, reason through it, and decide when she’s reached a conclusion she can trust. The very thing they feared might hold her back could be exactly what the next era prizes most.

So no, I’m not worried about the timed test. I hope she grows up in a world where software carries the toil and people are freed for the work that is unmistakably ours—to think, to judge, to create, to care for one another. That is the future I want agents to make real.

But my hope is not evidence it will happen. The future I just described turns on a single question: can we trust agents to do the work? Trust is earned one task at a time. So, I went looking for evidence of where it’s been earned, and where it hasn’t.

For the past year, the conversation around AI agents has circled the same promise: eliminate toil so people can focus on what matters. But I keep coming back to sharper questions. What, exactly, is toilsome? Where does toil actually live in people’s work? What are the technical leaders closest to this shift willing to hand off—and what gives them the confidence to do it? To find out, we partnered with MIT Technology Review Insights on new research that draws directly from the people building this frontier. Not the people talking about it, the people doing it. We surveyed 300 technical experts across AI, data, and cloud domains, spanning 12 industries and 4 regions of the world, asking them to rank their confidence across 101 of the top tasks. What we got back is the 2026 Agent Confidence Index, an honest map of where agents are delivering real value, so our community can see what’s working and move forward together with conviction.

Explore the 2026 Agent Confidence Index report

Learn from where confidence is highest

Across the 101 tasks measured, average confidence already lands at 64 out of 100, and thirty tasks clear 70. The highest scores cluster on work that is both predictable and draining: the late nights, the interruptions, the low-value repetition. Automated report generation leads at 83.5. Boilerplate code generation for new features sits at 82.5, the hours a developer no longer spends rewriting the same patterns, freed for the work that challenges them. Certificate expiration monitoring and renewal, at 81.5, ends the scramble that pulls engineers off high-stakes problems for something entirely routine. Real-time data stream monitoring follows at 80.5, and release note generation from commit history at 79.5, the manual end-of-sprint commit review, gone. This is where frontier teams are already delegating to agents, regularly.

The pattern holds across every discipline. In developer and AI workflows it extends to API client maintenance and code identification; in cloud operations, to ticket routing and cost optimization; in data, to anomaly detection. Wherever it sits in the stack, this is work technical teams now trust agents to own.

What matters most here isn’t what the data says about the tasks, it’s what it says about the people delegating them. When technical experts believe in something deeply enough to hand it real work, that belief ripples outward. It becomes the recommendation they make to their leadership, the solution they build for their customers, and the culture they create for their teams.

Even the toughest agent tasks are gaining traction

Here’s what strikes me most: the tasks ranked lower on the index are still high in absolute terms. Service mesh configuration and troubleshooting sits at 37.5, database schema migration scripting at 46.5, memory leak detection at 48.5. These sit at the very frontier, the interconnected, high-stakes work where investment and innovation are concentrated right now.

Consider what they demand. Service mesh configuration touches many systems at once. Database migration carries real stakes, requiring precision across data, application, and infrastructure layers at the same time. Memory leak detection means diving deep into a system’s behavior under load, accounting for conditions that shift from one deployment to the next. These are the challenges that have separated great engineers from exceptional ones—and even here, experts see agents helping. Not carrying the work alone, but contributing where it used to be unthinkable. That confidence is still climbing, and that’s telling.

We’re shipping new capabilities constantly to support this momentum. Database migration tooling in GitHub Copilot now covers not just scripts but the full application and infrastructure migration story. The Azure Site Reliability Engineering (SRE) Agent brings decades of experience operating Azure at scale and deep profiling capabilities directly into memory analysis and performance diagnosis.

Why human judgment remains paramount

When we asked technical experts how they’re navigating agent adoption, 59% named “keeping humans in the loop” as their top priority—ahead of better observability, ahead of governance documentation, and ahead of everything else. That’s a mark of maturity. Teams moving forward with clarity treat agent oversight as non-negotiable, regardless of how capabilities evolve.

The boundary itself is straightforward. Agents excel at well-specified, high-volume, reversible work: they synthesize data, automate known workflows, and surface anomalies at a speed and scale no human team could match. The moment a decision becomes high-stakes, context-dependent, or hard to undo, a human signs off. That isn’t a limitation of the technology, it’s the architecture of a trustworthy system.

What’s changing, and what remains underappreciated, is the skill it takes to draw that boundary well: the discipline of full-lifecycle evaluations and guardrails. Success means measuring agent output against intent and keeping behavior inside your business strategy. It’s new territory for most engineering teams, and it’s becoming table stakes for modern software faster than most organizations realize. The good news: the same tools generating the work can help you build the harness. Ask GitHub Copilot to write the evals and it will. Frontier teams are already doing this, and it’s why they’re pulling ahead.

Agents are opening career doors for engineering

Across system reliability and site operations, evaluations and quality assurance, and data pipeline management, 80% or more of respondents see meaningful career opportunity ahead. We believe this is one of the most significant moments in the history of building software, not because agents replace what technical people do, but because what’s left when they take on the toil is the work that defines a career: the judgment calls, the architectural vision, the reasoning to navigate complexity under pressure. That fluency will define the next generation of technical leadership.

We’re living this shift at Microsoft, right alongside our customers. Junior developers are using agents to explore codebases on their own and arriving at mentoring conversations with sharper, more sophisticated questions. Senior engineers are covering more ground because the repetitive work that used to fill their days is now delegated, and the work that’s left is harder, more interesting, and more consequential. Both are growing into more capable versions of themselves. For me, that’s the outcome I’ve always believed technology could deliver.

An integrated approach to intelligence and trust

Designing more sophisticated agent systems has made one thing clear: agents thrive in well-integrated environments, working best when your whole stack draws on a single source of truth. The high-confidence tasks are the ones we’ve already figured out; the meaningful frontier is the harder, interconnected work, and that’s exactly where observability, governance, security, and unified intelligence have to operate as one.

Microsoft IQ brings your enterprise context into a single, continuous intelligence layer. Within it, Work IQ builds semantic understanding of how your business operates across email, calendar, meetings, chats, files, people, and collaboration patterns. Such depth of knowledge is the reason technical teams choose us and it’s what drives my focus and passion in learning how people actually work so their agents get them. My colleague Kim Manis, CVP of Product for Microsoft Fabric, has written specifically about what this means for data professionals, and the integral role of Fabric IQ.

It’s all part of the Microsoft Agent Platform, which is becoming the operating system for enterprise AI at scale. From building in GitHub and contextualizing with Microsoft IQ, to running in Microsoft Foundry and governing in Microsoft Agent 365, Microsoft is uniquely positioned to help customers bring together data, models, agents, and human judgment into a continuously improving and secure system.

Frontier transformation is being led by builders like you.

Next steps:

Download The 2026 Agent Confidence Index from our partners at MIT Technology Review Insights.It is a free, ungated deep dive into all 101 tasks, broken out by role and workflow, with the patterns and reasoning behind where confidence is strongest and the frontier is expanding.

Join us at the AI Engineering World’s Fair (June 29-July 2) where our very own Pablo Castro will keynote, and our teams will offer 16 breakout sessions and 4 labs. Swing by the Microsoft booth as well to explore an interactive 3D visualization of the Index data. We want to hear what’s working for you right now.

Learn more about Microsoft IQ and how it connects across Work IQ, Fabirc IQ, Foundry IQ, and the newly announced Web IQ. You can catch up on all the developer innovation from Microsoft Build through Satya Nadella’s keynote, Kyle Daigle’s blog post, and the Microsoft Build CLI.

What’s Working in Agentic AI

The 2026 Agent Confidence Index report reveals where agents are trusted, the challenges they face, and what leaders should do next

Download the 2026 Agent Confidence Index report

The post The 2026 Agent Confidence Index: Where 300 builders see real momentum appeared first on Microsoft Azure Blog.
Quelle: Azure

Claude in Microsoft Foundry is now generally available

Claude in Microsoft Foundry is the production path enterprises have been asking for: true frontier model choice, Azure-native controls, simplified procurement, and faster time to value.

Most enterprise AI projects do not stall because of model quality. They stall because of everything around the model: procurement, governance, networking, and data. Claude in Microsoft Foundry is now generally available, hosted on Azure, giving teams a faster path from agent experimentation to production.

Enterprises can build with Claude through their existing Azure account, using the authentication, billing, networking, governance, and data controls their teams already trust. Instead of solving for infrastructure, teams can focus on building agentic applications that run their work with Claude, in the environment where they already operate.

This is a real step forward for customers building agentic applications and want to move from AI experimentation to production. Claude brings leading capabilities for coding, agentic workflows, and complex reasoning. Microsoft Foundry brings the enterprise harness to build, evaluate, deploy, and scale those agents on Azure. Together, they give teams a trusted path to production AI with frontier model quality and the Azure controls they already trust.

Today’s announcement builds on the strategic partnership Microsoft, NVIDIA, and Anthropic announced in November 2025 to expand enterprise access to Claude on NVIDIA accelerated computing. Claude runs on NVIDIA Blackwell Ultra systems, connected by InfiniBand networking, bringing the rack-scale AI infrastructure designed for inference performance and efficiency.

Build with Claude through your Azure account

Developers can access Claude through the Messages API and use core capabilities including prompt caching, extended thinking, and tool streaming. For teams building agents, Foundry Agent Service uses Claude as the reasoning core to orchestrate multi-step planning, tool use, and task execution across enterprise systems.

Inference is processed in Azure, and customers can choose between Global and US data zones, for teams with data residency requirements. Anthropic operates the inference and is the data processor and SLA provider. Because Claude is available natively through Foundry, teams can work inside the Azure environment they already use. They can authenticate with Microsoft Entra ID, apply Azure role-based access controls, manage access through existing governance policies, and track usage through familiar Azure management experiences.

For high-sensitivity workloads, zero data retention is also available, so prompts and completions are not retained by Anthropic after the API call completes. For commercial teams, it also simplifies how Claude is purchased and consumed. Claude usage is billed in Claude Consumption Units (CCU), a single, consolidated line on your Azure bill, with MACC drawdown and per-model detail in Foundry unchanged.

For many enterprises, that matters as much as model capability. The barrier to production isn’t only whether a model is powerful enough, it’s whether teams can procure it, govern it, secure it, and operate it at scale inside their existing cloud. With Claude in Foundry, they get frontier capabilities in an Azure environment that aligns with enterprise requirements for security, compliance posture, governance, and data residency.

Running Anthropic’s models on Azure has given us the sustained throughput and reliability our enterprise customers expect. The combination of frontier model quality and enterprise-grade infrastructure is what makes Bolt viable for the Fortune 500.
—Gary Ballabio, Vice President, Partnerships, Bolt

Customers are already building with Claude in Foundry

Enterprises aren’t just running isolated pilots; they’re building production systems and agents that need throughput, reliability, governance, security, and scale.

At NVIDIA, we use autonomous AI agents every day to help our teams move faster and think bigger. Anthropic’s Claude models bring strong reasoning, coding and enterprise capabilities that are valuable for complex technical work. With Claude now available in Microsoft Foundry running on NVIDIA GB300 GPUs, more organizations can run advanced, specialized AI agents with the performance, scale and security needed for production.
—Justin Boitano, Vice President and GM of Enterprise Computing, NVIDIA

Our customers describe their tests in plain English, and Momentic runs through the interface to verify everything works before a release ships. We found Claude’s Opus models especially suited to this, and running them on Microsoft Foundry we now serve millions of tokens per minute with the reliability our customers depend on.
—Jeff An, Co-Founder and CEO, Momentic

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://azure.microsoft.com/en-us/blog/wp-content/uploads/2026/06/Replit_Thumb-1-scaled.jpg”,”title”:””,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F4240300-replitonmicrosoftfoundrywithclaude%2F4240300-ReplitOnMicrosoftFoundryWithClaude_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”},{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4240300-ReplitOnMicrosoftFoundryWithClaude_audio_en-us”,”locale”:”en-us”,”mediaType”:”audio”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6a47a7aeadec9″, options);
});

Built for coding, agents, and complex reasoning

Claude models are especially well-suited to some of the fastest-growing enterprise AI workloads. For software teams, Claude supports code generation, refactoring, debugging, test creation, and large-scale development workflows. For teams building agents, it powers multi-step reasoning, tool use, planning, and task execution. For business teams, it supports document-heavy analysis, research synthesis, and complex decision support.

In Microsoft Foundry, these capabilities connect to the broader Azure ecosystem. With Foundry Agent Service, teams orchestrate multi-step, goal-driven agents that use Claude as their reasoning core, planning, calling tools, and executing tasks across enterprise systems. Features like model router enable customers to automatically route queries to the most appropriate Claude model, saving up to 50% while improving user satisfaction. All this governed and monitored by Foundry Control Plane which continuously runs evaluations to ensure agent responses match customer expectations, even blocking responses that violate rules before they reach users.

Between Anthropic and Azure, we get the best capabilities in the world and we get the best security in the world. And that’s exactly what nuclear needs. It’s how we compressed a safety analysis that would have taken 200 human days into a single day.
—Matt Huang, Founding Product Lead, Everstar

And with Microsoft IQ, agents have access to live enterprise context which radically improves value per token, and helps Foundry amplify the impact customers can have: tools like agent optimizer in Foundry Agent Service tune the prompts which define agents so they perform better regardless of what model is under the hood.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/4234700-AI-Skills-Studio_tbmnl_en-us?wid=1280″,”title”:””,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F4234700-ai-skills-studio%2F4234700-AI-Skills-Studio_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”},{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/4234700-AI-Skills-Studio_audio_en-us”,”locale”:”en-us”,”mediaType”:”audio”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6a47a7aeae198″, options);
});

A stronger foundation for enterprise AI on Azure

The next phase of enterprise AI will be defined by production systems: coding agents, business process agents, research assistants, customer-facing applications, and domain-specific workflows that operate reliably at scale. That takes more than access to a model. It takes a platform.

With Claude now generally available in Microsoft Foundry and hosted on Azure, customers can build with Anthropic’s leading models, orchestrating them as agents with Foundry Agent Service and grounding them in enterprise knowledge with Microsoft IQ, while using the Azure controls, commitments, and infrastructure they already trust.

Try Claude in Foundry today

Build with Anthropic’s leading models in the Azure ecosystem you know and trust.

Get started

The post Claude in Microsoft Foundry is now generally available appeared first on Microsoft Azure Blog.
Quelle: Azure

Azure IaaS: How to design, build, and optimize cloud infrastructure for long-term cost efficiency

In this article

Compute: Matching resources to workload requirementsStorage: Balancing performance and lifecycle managementNetworking: Improving efficiency without compromising resiliencyContinuous optimization is where long-term savings happenContinue your Azure IaaS optimization journeyCreate a resilient infrastructure with Azure

This blog post is the third part of a blog series called Azure IaaS which will share best practices and guidance to help you build a trusted infrastructure platform—from performance, resiliency, and security to scalability and cost efficiency.

As organizations modernize infrastructure, migrate mission-critical workloads, build cloud-native applications, and scale AI—cost efficiency remains a foundational principle of cloud architectures.

Discover the Benefits of Azure IaaS

Yet cloud costs are rarely driven by a single decision. More often, across Azure Infrastructure-as-a-Service (IaaS) environments, they are the result of many compounded architectural choices across compute, storage, and networking.

Common examples include overprovisioning infrastructure when selecting a larger virtual machine than a workload requires or keeping infrequently accessed data on premium storage, building resilient architectures that introduce unnecessary overhead, or collecting and retaining more operational data than is needed. Individually, these decisions may seem minor, but over time they can significantly impact both cost and operational efficiency.

These challenges become even more important as organizations expand AI initiatives, modernize applications, and support growing performance and resiliency requirements.

The opportunity lies in addressing these inefficiencies before they become entrenched. By making informed infrastructure decisions during planning, deployment, and ongoing operations, organizations can improve resource utilization, reduce total cost of ownership (TCO), and create a more scalable foundation for future growth.

In this blog, we’ll explore some of the most common infrastructure cost challenges organizations face today and examine how Azure IaaS capabilities across compute, storage, and networking can help improve efficiency, reduce TCO, and highlight resources available in the Azure IaaS Resource Center to help you make more informed decisions.

Many of the most impactful optimization opportunities originate long before a workload enters production. To better understand where these opportunities exist, let’s examine common efficiency challenges (and solutions) across compute, storage, and networking.

Compute: Matching resources to workload requirements

Compute inefficiencies are often the easiest to identify because they directly affect both performance and infrastructure spend.

The goal is not simply to select the lowest-cost compute option, but rather to align infrastructure resources with workload requirements while preserving flexibility for future growth.

Azure provides a broad portfolio of virtual machine options, enabling organizations to select the architecture, processor type, performance profile, and scale characteristics that best match workload needs; allowing organizations to align infrastructure investments with workload needs rather than paying for unused capacity.

Equally important is taking advantage of Azure’s flexible pricing options. Depending on workload characteristics, organizations can combine Pay-As-You-Go pricing, Azure savings plans, Azure Reservations, and Azure Spot Virtual Machines to better align costs with actual usage patterns.

For highly scalable environments, services such as Azure Virtual Machine Scale Sets automatically balance compute demand with available capacity by scaling resources up or down in real time, ensuring the environment is right-sized while optimizing cost efficiency. Azure Compute Fleet help organizations intelligently balance capacity, availability, and price-performance across large deployments; reducing the operational complexity associated with managing infrastructure at scale.

The result is a compute environment that is not only cost-efficient, but also better aligned to application requirements and business outcomes.

Storage: Balancing performance and lifecycle management

Storage inefficiencies often develop gradually, at times making them difficult to identify until environments reach significant scale. The key is to ensure that performance, capacity, and data access requirements remain aligned.

Choose the right storage service for the workload

Storage performance requirements vary dramatically across workloads. Some applications demand consistent low-latency block storage, while others prioritize storage capacity, durability, or long-term retention. Selecting the appropriate storage service and performance tier is critical to maximizing both efficiency and value.

For example:

Business applications may benefit from Premium SSD v2 offerings.

Business-critical transactional databases may require Ultra Disk to meet stringent low-latency performance requirements.

Large-scale block storage environments can benefit from consolidated architectures using Azure Elastic Storage Area Network (SAN).

Linux/Windows file shares, home directories, and shared storage scenarios may benefit from Azure Files or Azure NetApp Files.

Object storage workloads often benefit from the alignment between Azure Blob Storage tiers and data access patterns.

Automate data lifecycle management

Equally important is ensuring data remains on the appropriate storage tier throughout its lifecycle. In many environments, data access patterns change significantly over time, yet storage configurations remain static. This disconnect often results in organizations paying for performance they no longer need.

Azure Blob Storage provides capabilities that help organizations automatically align storage costs with data access patterns. Automated tiering and lifecycle policies maintain low-latency access for frequently used data while optimizing costs by transitioning infrequently accessed data to lower-cost tiers.

The result is a storage strategy that continuously adapts as usage patterns evolve, without requiring ongoing manual intervention.

Improve visibility across your storage estate

Optimization starts with understanding where costs are being generated.

Tools such as Azure Storage Discovery and Azure Storage Actions can help organizations gain visibility into their storage environments, uncover optimization opportunities, and automate actions across large-scale deployments.

Rather than managing storage account by account, teams can identify patterns and implement cost-saving actions consistently across their entire data estate.

Together, these capabilities help organizations move beyond storage provisioning and toward ongoing storage optimization.

Networking: Improving efficiency without compromising resiliency

Networking presents a unique optimization challenge because organizations must balance connectivity, performance, resiliency, and operational visibility.

Achieve resiliency more efficiently

Historically, improving resiliency often requires duplicating infrastructure components, creating additional cost and management overhead. Today, organizations increasingly seek architectures that deliver resiliency while minimizing complexity and excess infrastructure.

Azure networking capabilities help organizations evaluate these tradeoffs more effectively. Services such as ExpressRoute Metro, Zone Redundant NAT Gateway, and scalable networking architectures provide opportunities to improve resiliency and scalability while maintaining operational efficiency.

Reduce operational and logging expenses

Operational visibility is another important consideration. Network and firewall logs are essential for troubleshooting, security, and governance, but collecting every possible data point can create significant storage and operational costs over time.

Modern filtering and analytics capabilities help teams focus on the most relevant network data, reducing both storage consumption and investigation complexity.

This gives organizations the information they need while avoiding excessive log growth and long-term retention costs.

By implementing filtering, automation, and intelligent logging strategies, organizations can focus on the data that provides actionable insights while reducing unnecessary information collection and retention.

Continuous optimization is where long-term savings happen

Infrastructure efficiency is not achieved through a single migration, architecture review, or pricing decision.

As workloads evolve, usage patterns shift, and new platform capabilities become available, opportunities for optimization continuously emerge.

The organizations that realize the greatest value from cloud investments are often those that treat optimization as an ongoing operational discipline. They regularly evaluate infrastructure utilization, revisit architectural assumptions, automate lifecycle management processes, and adopt new capabilities that improve efficiency across their environments.

While individual improvements may appear incremental, the cumulative impact can be substantial. A right-sized virtual machine (VM), a more appropriate storage tier, an automated lifecycle policy, or a more efficient networking architecture may each deliver modest savings independently. Together, they create a more efficient, scalable, and resilient infrastructure foundation.

Azure continues to deliver important capabilities such as Azure Copilot to help customers optimize cloud costs by combining real-time insights, AI-driven recommendations, and automated optimization actions, empowering teams to quickly identify waste, right-size resources, and forecast spend with minimal effort.

Continue your Azure IaaS optimization journey

Whether you’re supporting AI workloads, modernizing existing applications, migrating existing workloads, or planning future growth, building efficiency into cloud architectures has never been more important.

The Azure IaaS Resource Center provides guidance, best practices, technical resources, and optimization strategies across compute, storage, and networking to help you design, build, and optimize Azure environments with confidence.

Visit the Azure IaaS Resource Center to explore cost optimization guidance, architectural best practices, product resources, and tools that can help you maximize value from your Azure infrastructure investments.

To go deeper, explore the Azure IaaS Resource Center for tutorials, best practices, and guidance across compute, storage, and networking to help you design and operate resilient infrastructure with greater confidence.

Create a resilient infrastructure with Azure

Visit the Azure IaaS Resource Center to start building a stronger, more efficient infrastructure today.

Get started with Azure

Did you miss these posts in the Azure IaaS series?

Explore new resources for building a stronger, more efficient infrastructure

Keep critical applications running with built-in resiliency at scale

Defense in depth built on secure-by-design principles 

Deploy high-performance workloads with a system-level approach 

The post Azure IaaS: How to design, build, and optimize cloud infrastructure for long-term cost efficiency appeared first on Microsoft Azure Blog.
Quelle: Azure

Proving application resilience on Azure with Chaos Studio

Takeaway: Azure Chaos Studio helps organizations validate application resilience by simulating outages, failovers, network disruptions, and infrastructure failures before they impact production.

You don’t know with certainty that your application is resilient until that resilience is tested. Better to learn it isn’t by deliberately breaking it in a test environment and watching how it reacts, than by a failure in production. Azure Chaos Studio is our managed service for doing exactly that, safely and on purpose.

Today, Azure Chaos Studio Workspaces is in public preview: a scenario-focused approach that lets you test the failure modes Azure customers actually see in production. We’ve been hard at work making Workspaces easy to use, with broad fault support and named scenarios that mirror real outages, instead of isolated faults.

Explore Azure Chaos Studio Workspaces

Why designing for resilience isn’t enough

Azure customers have invested in resilient design: multi-zone deployments, geo-redundant storage, automatic database failover, retry logic, load-balanced front ends. However, the real question is when an incident begins: when the failure arrives, do those mechanisms recover your application in the time you assumed they would?

Real outages don’t read the architecture diagram. A zone-redundant deployment can fail because a health probe was misconfigured years ago. A database with automatic failover can leave the application dead because a connection string is hard coded to a single region. Geo-redundant storage can briefly produce stale reads the application code never expected. These mistakes are common, and they only show up when the failure happens.

Reliability and resiliency on Azure are a shared responsibility. Microsoft is responsible for the platform and the resilience built into Azure services. Customers are responsible for configuring that resilience and the code that uses it. No layer makes up for a gap in another. The only way to know whether your architecture, configuration, and application logic will hold up in production is to prove they hold under failure before an outage tests them for you.

How Chaos Studio Workspaces changes resilience testing

Chaos Studio is Azure’s managed chaos engineering service for validating how applications behave under failure. By simulating controlled disruptions across infrastructure, networking, databases, and application dependencies, it helps teams uncover resilience gaps before customers experience them. Chaos Studio Workspaces focuses on scenarios that match what happens in production, so you start from a real outage pattern instead of assembling individual faults. You begin with a named scenario like Zone Down, DNS Outage, or SQL failover, already sequenced against the resources in a Workspace.

Most outages exercise two layers at once. There’s the platform layer: did the service come back, did failover complete within your Recovery Time Objective, did traffic reroute. And there’s the application layer: did your code maintain data integrity, pick up in-flight transactions, retry the right things, degrade gracefully. A chaos test that only stops a Virtual Machine (VM) tells you about the platform layer. The scenarios in Chaos Studio Workspaces are designed to validate the entire stack.

Workspaces reduce the burden of getting started. The most common reason resilience testing stalls is that teams don’t know where to start. The Workspace is the new top-level resource: you point it at a subscription or resource group, and its managed identity discovers what’s in scope and recommends the scenarios that apply. Those scenarios show up inside the Workspace, ready to configure and run, and a refresh, updates the recommendations whenever your infrastructure changes.

A library of real outage scenarios. Chaos Studio Workspaces ships with curated scenarios informed by patterns observed in real Azure incidents, so the patterns you test against are the patterns customers actually experience. Think of these as resilience templates, a fast path to the failure modes most teams need to test, and when you need something different, design your own from the same fault library.

Available today:

Availability Zone Down: Virtual Machine Scale Sets (VMSS) shutdown with per-zone targeting to validate cross-zone routing and recovery.

Availability Zone Down and Database failover: Compute Zone Down composed with Azure Database for PostgreSQL (Flexible Server) failover, to observe failover behavior against your configured recovery objectives and application-side connection handling.

DNS Outage: a full DNS resolution outage via NSG rules that block resolver traffic, to validate how your application behaves when name resolution fails.

Microsoft Entra ID Outage: identity-provider failure that exercises authentication retry, token caching, and fallback paths.

Cache Stampede: Redis flush combined with database restart and an App Service process crash, to validate behavior under a cache-miss storm and the resulting database surge. The App Service process-crash variant currently supports Windows App Service plans.

Event-Driven Messaging Disruption: Azure Service Bus and Event Hubs disable, to validate dead-letter handling and backpressure.

Behind every scenario are granular API-level actions built for Workspaces:

Zonal VMSS shutdown

App Service process kill

Force-failover for Azure Database for PostgreSQL (Flexible Server)

Azure Managed Redis flush

Network Security Group (NSG)-based network controls

Each scenario composes the right faults automatically. And when a curated scenario doesn’t match your workload, you can build your own. The new Scenario Designer is a drag-and-drop experience in the Azure portal for composing any of these faults into a custom scenario arranging steps, branches, and faults with the same flexibility as classic Chaos Studio experiments, now available directly inside Workspaces. Start with a curated template, or design from scratch using the full fault library.

VM agent faults such as Central Processing Unit (CPU) and memory pressure also run in Workspaces. Each scenario sequences the right combination of faults automatically, so running Zone Down + Database Failover doesn’t mean thinking in terms of “shut down VMSS instances in zone 1, then force-failover the database primary.” The library will keep growing through public preview and into GA, with plans to explore additional scenarios over time, such as:

Storage account failover

Microsoft Azure SQL Managed Instance failover

Microsoft Azure Front Door and Microsoft Azure Application Gateway

Partial zone degradation

Microsoft Azure Kubernetes Service (AKS)-native pod chaos

Customer-observed region down

That same foundation is also relevant for AI applications moving into production. Copilots, agents, retrieval-augmented generation pipelines, and inference endpoints may introduce new AI-specific failure modes, but they still rely on the same Azure building blocks as other distributed applications: compute, databases, caches, search indexes, identity, networking, messaging, and storage. Chaos Studio Workspaces can validate that foundation today through scenarios like Zone Down, Database Failover, DNS Outage, Cache Stampede, and Event-Driven Messaging Disruption, while the catalog continues to evolve toward AI-specific behaviors such as retrieval drift, token throttling, and model behavior shifts under load as more insights are gathered fromworking closely with customers building AI on Azure.

Scenario reports. When a run finishes, Chaos Studio Workspaces generates a structured drill report. It lays out what the scenario injected, which resources it affected, how the recovery timeline played out, which signals were attributable to the drill versus the normal baseline, and where the workload behaved differently than expected. The report reads like an internal post-incident review, which makes it useful both for the team that ran the drill and for the leaders who want to see resilience being validated regularly. Teams can export it and attach it to change tickets, audit evidence, or service health reviews.

Bringing resilience testing into AI-powered operations

Alongside the product, we’re shipping two ways to drive Chaos Studio from the tools engineers already work in. The first is the Chaos Studio Skill for GitHub Copilot: it walks you through the whole loop in a conversation. Point a Workspace at a subscription, see the scenarios it recommends, run a drill, and get back a report of what actually happened, correlated against your Azure Monitor signals.

The second is an Model Context Protocol (MCP) server that exposes the same Chaos Studio operations as typed tools, so other assistants and autonomous agents: Claude, Cursor, Codex, or your own, can provision a Workspace, run a scenario, and query the signals around it without a person in the loop. Both run against the same Chaos Studio APIs and your own Azure sign-in, and you can try them today.

We’re shipping this on day one for one reason: When a customer asks an AI assistant about Chaos Studio, the experience should be shaped by us, not improvised by a large language model (LLM) reading our REST API. In our experience, one of the hardest parts of resilience testing is often deciding to run the drill in the first place, and that decision increasingly lives in the chat tools engineers already use, so this needs to live there too.

Where this is headed: The Skill becoming a step inside automated operations flows on Microsoft Foundry, and one of the ways an Azure SRE agent validates its own assumptions about how a workload fails. Try it and tell us what’s missing; we’ll close the gaps through public preview.

Get started

Azure Chaos Studio Workspaces is in public preview today. General availability is currently targeted for late 2026, subject to change.

To start:

Create a Workspace scoped to a subscription or resource group you want to test.

Let discovery populate the recommended scenarios for the resources it finds. Prefer to build your own? Open the Scenario Designer and compose a custom scenario from the fault library, no scripting required.

Run your first drill. If you’ve never run a chaos experiment, run Zone Down. A full availability-zone failure surfaces how compute placement, database failover, DNS resolution, and application-layer retry logic respond under stress. If your workload recovers within an acceptable time, you’ve gained evidence about how it responds to one of the most common causes of extended cloud downtime. If it doesn’t, you’ve found the gap on your terms instead of your customers’.

Resilience isn’t something a single feature, a single redundancy mechanism, or a single architecture decision will give you. It’s an engineering discipline, and the discipline requires verification. Azure Chaos Studio Workspaces is how we’re making that verification the default for Azure workloads, including the AI workloads more of our customers are putting into production.

Related resources

Azure Chaos Studio

Microsoft Azure Well-Architected Framework—Reliability

Recommendations for using availability zones and regions

Business continuity and disaster recovery

Reliability guides for Azure services

Chaos Studio Workspaces documentation

Scenario catalog

Quickstart: create a Workspace and run your first drill

Announcing Azure Infrastructure Resiliency Manager Public Preview

Run your first resilience testing today

With Azure Chaos Studio Workspaces, you can simulate failures across your stack and gain practical insight into recovery behavior

Try now

The post Proving application resilience on Azure with Chaos Studio appeared first on Microsoft Azure Blog.
Quelle: Azure

Meet Brain: The AI system behind Azure reliability

In this article

How Azure's AI-powered reliability intelligence system worksWhy Brain is neededWhat is Brain? Azure’s centralized AIOps for cloud reliabilityFoundations of Azure’s digital twin for cloud healthWhat it means to operate against a cloud intelligence systemThe future of agentic AI and cloud operationsWhat's next for Azure reliability and BrainAzure reliability

Takeaway: Brain is Azure’s AI-powered cloud reliability intelligence system: an AIOps system that sits as an intelligent layer on top of Azure Resource Graph and fuses platform telemetry, AI/ML models, service dependencies, and customer impact into a single, continuously updated view of how every service, region, and workload is performing. It already powers customer Azure resource health notifications, deployment safeguards, and outage declaration, and it is the foundation for agentic AI now reshaping how Azure operates. This post starts a multi-part series on what Brain is, how we built it, what we’ve learned operating it at scale, and where it goes next.

How Azure’s AI-powered reliability intelligence system works

Azure runs on a digital twin of its own health. Brain is an AIOps-powered cloud health intelligence system that operates as an intelligent layer on top of Azure Resource Graph (ARG); together, they form this digital twin. It integrates platform telemetry, AI/ML models, and data engineering to continuously maintain and enrich a real-time view of how services, regions, and customer workloads are performing across Azure. Over time, that shared picture is becoming the foundation for a more automated reliability surface: one that can turn insight into action.

Today, Brain already powers important reliability workflows across Azure, such as health notifications for customer’s resources, deployment safeguards, and outage declaration. If you run on Azure, Brain is already changing three things you can notice:

How fast we tell you when something is wrong.

How accurately we scope it to your resources.

How quickly the right engineer gets on it.

This post is about how and what it lets you do differently.

We’re starting a multi-post series with this one to take you through what Brain is, how we built it, what it has learned operating Azure at scale, and where it goes next. Today, the foundation.

Learn more about Azure reliability

Why Brain is needed

Azure runs hundreds of services across more than 80 Azure regions, over 500 datacenters, and over 800,000 kilometers of fiber and subsea cable, representing one of the world’s largest global cloud footprints. And yet with the massive amount of activity these Azure services create, manage, and process worldwide, on a quietly degrading day, we will sometimes still learn about an issue from a customer before our own systems do. For customers, that gap is the worst kind of incident; the one where they are debugging their own application before they learn the fault was ours.

That gap between what we measure and what we know is the limiting factor on cloud reliability today. It is not a tooling problem. We have plenty of tools. It is a comprehension problem. The amount of signal a hyperscale cloud produces has outgrown the human ability to read it, and the conventional answer: more dashboards, more alerts, more on-call rotations. It’s a treadmill, not an answer. Every additional dashboard gives an operator another window to look through; what’s missing is something that tells them what they’re looking at, in time to act.

Closing that gap meant building something we hadn’t built yet: not better dashboards, not smarter alerts, but a continuously updated model of the platform’s health that reasons across every signal in real time, and acts on those conclusions automatically at the scale the platform demands.

What is Brain? Azure’s centralized AIOps for cloud reliability

Brain is Azure’s centralized AIOps-powered cloud health intelligence system that uses AI/ML, including agentic AI and data engineering, to continuously model Azure’s health and to automatically take reliability actions based on it. It has been utilized in Azure production generating resource health determinations across the platform. 

At its core, Brain is shaped by three things: what goes in, what comes out, and what those outputs drive.

Brain at a glance.

Brain ingests signals from three classes of source:

Standardized service-level indicators: the SLIs Azure customers and operators already know from their reliability dashboards.

Domain-specific monitors that individual service teams have built and registered with Brain, and the broader telemetry stream including deployments, support volume, and cross-service dependency signals.

Third-party indicators that surround every Azure operation.

Each path serves a different purpose; together, they give Brain coverage that no single path could.

Regardless of the input, Brain evaluates every subject (service, region, deployment unit, or customer resource) and returns four outputs: health state, severity, impact, and the reason for its conclusion. Standard outputs in standard vocabulary mean every downstream system speaks the same language; no more disconnect in what “impacted” means across teams.

The insights generated by Brain power a growing set of automated reliability actions, including:

Outage declarations based on blast radius.

Customer notifications targeted to affected subscriptions and regions.

Incident routing to the appropriate service team.

Deployment gates that pause harmful rollouts.

Linking related incidents.

Diagnostic tools that help engineers investigate issues.

Foundations of Azure’s digital twin for cloud health

To understand what makes “the intelligence system” different from “a dashboard,” it helps to look at what’s actually in its foundation. Brain’s representation of Azure carries, at minimum:

Topology: every service, region, availability zone, deployment unit, and dependency graph enabled by Azure Resource Graph is represented as a live model that updates as services scale, dependencies change, and new components come online. This transparency into Azure service health and downstream impact helps Azure customers understand and diagnose application issues more quickly and improves the reliability of applications built on Azure.

Service catalog: what each service does, who owns it, what its tier is, what its expected behavior looks like, and what its service-level objectives are.

Runtime state: live indicators of how every component is currently behaving, including error rates, latency, throughput, resource utilization, and error distributions across customers.

Intent: what’s supposed to be happening right now, which deployments are in flight, which planned operations are underway, and which capacity changes are scheduled.

History: prior incidents, what caused them, what mitigated them, and which signals preceded them. The system’s working memory of how Azure has gotten unhealthy before, and what worked to fix it.

The customer’s view: what each tenant is currently experiencing. Not just what the platform is emitting, but what’s actually arriving at the customer’s application. Errors customers see, latency customers feel, and regions where their traffic is succeeding or failing.

None of these are novel on their own: every cloud platform has versions of each. Brain brings them together into a single, unified, AI-driven representation instead of scattering them across twelve separate dashboards in twelve separate tools that an operator has to mentally connect under time pressure.

When Brain says a service is degrading, that statement is not a threshold being crossed. It is a determination made by reasoning across topology, runtime state, current intent, historical patterns, and customer-side evidence simultaneously. It is the intelligence system speaking, not a metric firing. And it is the speed of that determination measured in seconds, not in the minutes a human would take to assemble the same picture from separate tools that translates directly into customer experience: shorter incidents, sharper notifications, and faster routing.

What it means to operate against a cloud intelligence system

This is the move that changes everything for an Azure customer, and it’s the one most easily missed if you read “digital twin” as a metaphor rather than as a system.

Consider how a deployment-driven degradation typically resolves in two different worlds.

In a world without a shared intelligence system, the work is reconstruction. A rollout is in flight. A region’s error rate begins to drift.

The team that owns the service sees the drift in their dashboard.

The team that owns the upstream dependency sees a different metric drift in their dashboard.

The team that owns the deployment system sees the rollout proceeding normally from their dashboard.

None of those three teams initially have the picture; they get on a bridge and assemble it from fragments. While they assemble, the customer impact spreads. By the time the connection between the rollout, the dependency, and the customer-visible errors is made, by humans, under pressure, mid-incident, the rollout has reached more regions, the customer ticket queue has grown, and the resolution is now harder than it had to be.

In a world with the intelligence system, the work is consumption. The rollout is in the intelligence system, Brain knows it’s in flight: what it’s changing, what regions it’s reaching, what it’s supposed to do. The error-rate drift is in the system: Brain sees it correlated to the rollout, weighted against the dependency graph, evaluated against historical patterns of what “small wobble” looks like versus what “real degradation” looks like.

The affected customers are in the system, their tenants map to platform resources affected by the upstream dependency, which is itself affected by the rollout. Brain produces a single determination: the rollout is causing customer-visible impact in this region; expected resolution requires the rollout to pause.

That determination then flows, at the same moment, to every system that needs to act on it. The deployment system pauses the rollout while the determination is true, so the next set of customers Brain would have impacted aren’t impacted at all.

The incident management system creates a single incident with the upstream dependency identified, not three duplicate incidents from three confused teams so the right engineer reaches the right problem first. The customer communication system drafts a notification with the right tenant scope and the right plain-English description, so the customers who are affected receive updates from Microsoft sooner, with information they can actually use. For Azure customers, none of that coordination is visible. What’s visible is a shorter incident, an accurate alert that hit their automation instead of a human, and diagnosis that was already named when their on call opened the bridge. On services where Brain’s resource-health evaluation is in production, detection precision for service-impacting issues has improved significantly, and coverage of in-scope incidents continues to expand.

In the past year, a substantial majority of Brain-integrated outages were auto-communicated to affected customers, and on those, time-to-notification improved materially compared to manually issued notifications.

None of those downstream systems are doing their own investigation. They all consume the same determination from the intelligence system, in the same vocabulary, with the same supporting evidence. That is what “operating against an intelligence system” means and it is the first thing we found we had to build before any of the agentic AI work that people associate with Azure today became viable.

This not only helps to improve Azure’s reliability, but also benefits Azure customers who built their applications on top of Azure by providing transparency of service health and timely communications.

The future of agentic AI and cloud operations

There is a larger conversation happening across the cloud industry this year about agentic AI and about AI systems that act, not just observe. Microsoft is part of that conversation. But the conversation has a quiet asymmetry that gets less attention than it deserves.

Agents need something to be agentic about:

A triage agent that doesn’t know the dependency graph cannot triage anything.

A diagnosis agent that cannot reach prior incident history cannot reason about root cause.

A communication agent that doesn’t know which customers are actually affected cannot write to them.

None of these systems are meaningfully autonomous; none of them deserve your trust if every one of them has to do their own investigation of what reality is, every time, from raw signals.

That is what made the health intelligence system “the digital twin”: the prerequisite, not the consequence, of agentic operations at this scale. Build the agents first, on top of fragmented data, and you get a federation of confident systems that disagree with each other in production. Build the model first, and the agents become composable: they reason from the same picture, and the picture is one you can audit.

This is the throughline of the series we’re starting today. Brain is the cloud health intelligence system the next generation of cloud agents will need. If your organization is exploring agentic AI for any operations function: your cloud, your applications, or your infrastructure, the architectural pattern Brain represents is one to look at carefully. The agents are the headline; the intelligence system underneath is the work.

What’s next for Azure reliability and Brain

We have the system. The system has determination. A service in a region is degrading.

However, degrading compared to what? Healthy by whose definition? When two teams disagree about whether their service is healthy, which one is right? When the platform is degrading but no individual customer is impacted yet, what state are we actually in?

Those are not philosophical questions. They are the next engineering questions we have to answer, because a system cannot make determinations until the people building it agree on what determinations actually are. Most of the industry, until recently, has been quietly getting this wrong.

In the next post in this series, we’ll show you exactly how, and what we built to replace the broken vocabulary of cloud health that the industry has been operating on for the last decade. To follow the series as new posts are published, see the Advancing reliability blog tag.

Azure reliability

Query, explore, and analyze your cloud resources at scale.

Learn more

Acknowledgments

This work reflects the contributions of many engineers and researchers across the Brain AIOps team, MSR (Microsoft Research), and Azure service teams.
The post Meet Brain: The AI system behind Azure reliability appeared first on Microsoft Azure Blog.
Quelle: Azure

The performance dividend: Optimizing PostgreSQL on Azure directly in Visual Studio Code

Poor database performance is never just a database problem. In enterprise teams, it shows up as missed service-level agreements (SLAs), delayed releases, frustrated development teams, and rising operational risk. The performance problem compounds further in business impact, often resulting in frustrated customers, retention and conversion risk, and lost revenue.

I have seen this repeatedly while working with enterprises building and running large‑scale data platforms, both as a customer and partner, and now with Microsoft. When teams are forced to jump between SQL editors, monitoring dashboards, cloud portals, and documentation just to diagnose a slow query, the real cost is not just technical. It’s also time, trust, and momentum lost across the business.

A more integrated way to run PostgreSQL on Azure

This is why I am optimistic about where PostgreSQL on Azure stands today. Microsoft’s investment in open source and PostgreSQL has matured significantly over the last several years. Azure Database for PostgreSQL has evolved into a fully managed, fully open-source enterprise-ready platform, Azure HorizonDB has entered the conversation as the next-gen Postgres on Azure delivering 3x faster performance than self-managed Postgres, and Microsoft is extending that value directly into the tools developers and database administrators (DBAs) already use. The PostgreSQL extension for Visual Studio Code is a clear example of that progress, especially with its new performance‑enhancing capabilities.

Try PostgreSQL on Azure

Most enterprise teams do not lack tooling. They lack integration. Performance work often breaks down because insights live in one place, actions live in another, and context is lost in between. Microsoft’s direction with the PostgreSQL extension for VS Code focuses on closing those gaps by bringing development, diagnostics, and tuning into a single workflow.

The extension is designed to help teams manage PostgreSQL across the full lifecycle, from authoring queries and exploring schemas to monitoring server health and optimizing performance. For organizations standardizing PostgreSQL on Azure, this creates a more coherent operating model that reduces friction between developers, DBAs, and platform teams.

Learn more about the PostgreSQL extension for VS Code

Seeing performance clearly with the Server Metrics Dashboard

One of the most impactful additions is the server metrics dashboard. For DBAs and platform engineers, this dashboard brings key performance signals such as CPU, memory, storage, and connections directly into VS Code. Instead of switching contexts to investigate an issue, teams can view metrics where they already work.

Because the dashboard is integrated with Azure, it provides Azure‑specific telemetry and historical insights that help teams understand trends, not just snapshots. When performance issues arise, the time from detection to investigation is significantly reduced.

From insight to action with Azure Advisor in VS Code

Observability only matters if it leads to action. The PostgreSQL extension surfaces Azure Advisor recommendations directly in the editor, connecting performance insights with concrete guidance. These recommendations can include suggestions around configuration, indexing, and resource optimization based on Azure telemetry.

For enterprise teams, this shortens the feedback loop. Instead of manually correlating metrics with best practices, teams receive contextual recommendations aligned to their actual workloads. This improves operational confidence and helps standardize tuning practices across environments.

Optimize your resources with Azure Advisor

Faster diagnosis with Query Plan visualization and AI assistance

Performance tuning often comes down to understanding query behavior. Recent improvements to the extension enhance query plan visualization, making execution plans easier to interpret during troubleshooting and optimization.

Beyond visualization, Microsoft is embedding AI‑assisted query analysis and optimization directly into the workflow. Developers and DBAs can analyze query plans, understand potential bottlenecks, and explore optimization options without leaving VS Code. This does not replace deep PostgreSQL expertise, but it helps teams move faster and make better decisions earlier in the development cycle.

These capabilities are especially valuable for enterprise environments where not every developer is a PostgreSQL specialist, yet performance expectations remain high.

Better authoring experiences reduce performance issues upstream

Performance work does not start in production. It starts when schemas are designed and queries are written. The PostgreSQL extension improves this experience with schema‑aware IntelliSense, search_path‑aware query authoring, and reliable object explorer behavior for large and complex databases.

Developers can write, run, and refine SQL with better context, while DBAs benefit from more consistent and predictable interactions with large schema estates. Improvements to object explorer reliability also matter at enterprise scale, where long‑running sessions and frequent refreshes are common.

Combined with Microsoft Entra ID authentication and integrated Azure resource discovery, the extension provides a secure and governed way to work with PostgreSQL across development and production environments.

Try PostgreSQL extension for VS Code

From tuning to performance payout

Taken together, these capabilities change the day‑to‑day experience of running PostgreSQL on Azure. Azure Database for PostgreSQL already delivers the managed fundamentals enterprises expect, including high availability, security, and best‑practice guidance. The PostgreSQL extension for VS Code extends that value into execution by making performance management part of the same workflow as development.

This integration is a practical differentiator. It reflects an understanding of how enterprise teams actually work and where time is lost today. Instead of adding more tools, Azure is tightening the loop between insight and action.

A look ahead: AI‑native PostgreSQL with Azure HorizonDB

As enterprises look toward AI‑native architectures, Microsoft is also introducing Azure HorizonDB in public preview. Azure HorizonDB is designed for cloud‑native, AI‑ready PostgreSQL‑compatible workloads that require advanced scalability and integrated AI capabilities.

For most production workloads today, Azure Database for PostgreSQL remains the recommended choice. Azure HorizonDB represents an adjacent, forward‑looking option for teams exploring what comes next for their AI‑powered applications.

Watch video: Azure HorizonDB + VS Code: Your AI App Development Workspace

Turning performance into a competitive advantage

The real advantage of these new capabilities is the way they come together to reduce friction, improve clarity, and help teams act faster. For enterprises managing PostgreSQL at scale, that translates directly into better reliability, faster delivery, and lower operational risk.

If you are running PostgreSQL on Azure today, now is a good time to see what this looks like in practice. Try the PostgreSQL extension for VS Code and connect it to your Postgres databases on Azure to diagnose issues faster, optimize performance with greater confidence, and keep critical workloads running the way your business and your customers expect.

Try the PostgreSQL extension for VS Code

Diagnose issues faster and optimize performance with confidence

Get started

The post The performance dividend: Optimizing PostgreSQL on Azure directly in Visual Studio Code appeared first on Microsoft Azure Blog.
Quelle: Azure

From insight to action: The next phase of agentic cloud operations

In this article

Governance connects insight to actionObservability is the intelligence layerFrom signals to resolutionOptimization becomes continuous From dashboards to connected workflowsOptimization intelligence across tools and environmentsBringing it all together in a closed loop system Get started with AzureAzure Copilot

What if your cloud environment could help you move from insight to action in real time, with systems already working through the next set of decisions?

As applications scale across hybrid infrastructure, microservices, and AI workloads, leading organizations are moving toward operating models where insight flows directly into action as part of an ongoing, system-driven loop.

This is where agentic cloud operations comes in. Agentic cloud operations is an approach in which AI-powered agents—guided by user intent—continuously observe, reason, and assist with actions across the cloud lifecycle. Signals are not treated as isolated events. They are input into coordinated workflows that evolve over time, helping improve performance, cost, and reliability as systems run.

According to recent research conducted with Material, 79% of organizations are already deploying agentic AI in production, reflecting how quickly this model is becoming part of how cloud environments are operated.

Explore the research findings

Governance connects insight to action

To operate this model, governance needs to be built directly into how cloud operations run. Observability provides a continuous stream of signals and context, but those signals only become useful when they can drive action in a controlled and consistent way. As agents begin to take on more responsibility across detection, investigation, and remediation, every action should be designed to follow human-defined policies, respect access controls, and remain aligned with organizational intent.

At Microsoft Build, this emerged as a key requirement. Developers and IT need governance embedded within the same workflows that connect observability to optimization. As insights trigger actions, those actions remain constrained, auditable, and repeatable across environments.

Our vision for agentic operations includes a shared operating model that brings observability and optimization together, where insights lead directly to action and every action is governed by built‑in policy and control, with humans always in the loop. In Azure, we’re building a system in which observability, governance, and optimization work together. Signals are continuously interpreted, actions are applied within policy boundaries, and outcomes feed back into the system to guide the next decision.

Observability is the intelligence layer

As cloud environments expand, telemetry and alerts have outpaced what teams can manage through manual processes alone. Engineers often spend significant time correlating signals, validating issues, and understanding what changed.

In an agentic model, observability aims to provide continuous intelligence. It gives AI agents the context they need to identify meaningful signals, understand dependencies across the environment, and surface relevant insights early. Observability helps answer what is happening and why, with greater clarity and timeliness.

From signals to resolution

Building on this foundation, the Azure Copilot observability agent, now generally available, brings this intelligence into day-to-day operations. The observability agent can continuously analyze telemetry across your environment, including application topology, dependencies, and baseline behavior. When an issue begins to emerge, it can identify patterns, begin investigation, and provide context before teams start their analysis.

Agentic observability changes how incidents are handled in practice. Issues can be surfaced earlier, with related signals already grouped to reduce noise. Investigations can begin automatically, tracing dependencies across services to help identify likely root causes. Teams are provided with clear, contextual recommendations that support faster decision-making.

Observability also extends to AI workloads, so agents, services, and infrastructure can be viewed together. The result helps enable more consistent flow from detection to understanding to action, with less manual effort required along the way.

The biggest value is speed… The observability agent helps us resolve incidents faster and reduce operational overhead… we’ve reclaimed an estimated 250 engineering hours monthly.
—Narmada Krishnaswamy, Head of KPMG Audit Application Support and Operations

Observability provides a clearer view of what is happening. It also creates the foundation for the next step. Observability answers the most urgent question in cloud operations: what’s happening, and why? But for organizations operating at scale, that’s only the beginning.

Optimization becomes continuous

When observability provides consistent, real-time context, it can be used to guide ongoing improvement.

Microsoft defines optimization as the continuous practice of improving cloud workloads across cost, performance, resilience, and sustainability. In an agentic model, optimization becomes part of everyday workflows rather than a separate, periodic activity.

At FinOps X 2026, many organizations shared that AI is introducing new cost dynamics. Usage patterns are more variable, less predictable, and often tied to rapid changes in workloads. This makes it harder to rely on periodic reviews and traditional cost management approaches. Optimization must happen closer to where decisions are made.

From dashboards to connected workflows

As optimization becomes more integrated, the way work gets done also evolves. Instead of switching between tools and dashboards, teams can interact with systems through guided workflows. Agents help estimate costs before resources are created, apply governance guardrails automatically, monitor usage patterns, and surface potential issues earlier.

For example, during development, cost implications can be surfaced before deployment, along with relevant policy guidance. As systems run, patterns in usage can be monitored and changes can be investigated with supporting context. When opportunities for improvement are identified, agents can help prioritize and guide next steps. This approach helps bring cost, performance, and efficiency considerations into the flow of work in a more consistent way.

Optimization intelligence across tools and environments

To support this model, Microsoft is extending cost and usage intelligence beyond the Azure portal into the tools teams already use.

The Azure Resource Manager MCP Server, now in public preview, enables AI agents to access cost and usage data through a standardized interface. This allows cost insights to appear within developer environments, copilots, and custom workflows without requiring custom integrations.

As a result, developers can build with greater awareness of cost implications, and operations teams can investigate and optimize using natural language interactions. Workflows can be applied more consistently across teams and environments.

Multi-step processes such as estimation, investigation, and optimization can also be organized into reusable workflows, helping teams scale these practices.

Bringing it all together in a closed loop system

Observability and optimization are increasingly connected. Observability provides continuous context. Agentic AI helps interpret signals and support actions. Optimization reflects the outcomes of those actions over time, guided by governance and policy. This creates a system where insights can more directly inform the next step, and where each action contributes to ongoing improvement. Over time, this supports more consistent operations across environments and teams.

In this model, progress comes from acting with better context and greater consistency. Microsoft is helping organizations adopt this approach by connecting people, data, and tools through Azure Copilot and related capabilities. Teams gain the ability to resolve issues more efficiently, apply optimization continuously, and operate with governance built in.

Get started with Azure

To see how these capabilities come together in practice, you can explore and try them across your environment:

Azure Copilot

An AI-powered assistant that helps translate operational signals into guided actions across your cloud environment.

Azure Copilot observability agent (generally available)

Identify root causes and accelerate resolution through continuous analysis and assisted investigation.

Azure FinOps MCP Server (public preview)

Connect cost and usage intelligence into agent workflows, developer tools, and custom environments through an open interface.

Azure Copilot

Learn how Azure Copilot can help you operate in cloud environments.

Get started

The post From insight to action: The next phase of agentic cloud operations appeared first on Microsoft Azure Blog.
Quelle: Azure

Modernize your data with Azure Storage: Plan and migrate with confidence

Enterprise storage migrations are rarely just about copying data. They are about protecting business continuity, maintaining performance, managing cost, and giving teams confidence when terabytes or petabytes of data sit at the heart of critical applications.

That confidence is difficult to build when migration planning is fragmented. Many organizations still rely on a patchwork of scripts, third-party tools, and disconnected processes to: assess environments, move data, and keep systems aligned during transition. The result can be delayed timelines, avoidable disruption, and teams struggling to keep critical workloads running.

Explore Azure Storage migration solutions

A successful migration strategy starts with understanding that different data requires different approaches:

Some workloads need dependency assessment and sequencing before anything moves.

Some datasets are too large to transfer efficiently over the network.

Some file systems must remain synchronized while business operations continue.

Some data needs to land in Azure ready to support modernization scenarios such as analytics, AI, or application transformation initiatives.

In this blog, we’ll walk through how to approach Azure Storage migration from planning to execution:

How Azure Migrate and Azure Copilot Migration Agent can support assessment and decision-making.

How to select the right Microsoft first-party migration tool.

Azure Storage Mover and Azure Data Box can help address online, offline, and phased migration scenarios across real-world customer needs.

Tool overview

Azure Migrate: Centralized hub for migration discovery, assessment, and planning.

Azure Copilot Migration Agent: AI-powered extension for Azure Migrate, streamlining storage migration decisions (preview).

Azure Storage Mover: Free, managed online migration and synchronization tool for file/object data.

Azure Data Box: Secure offline transfer solution for large-scale or bandwidth-constrained datasets.

1. Azure Storage migration planning: Build your data migration strategy

Before organizations select a migration tool, they need to understand what they are moving, how systems are connected, which workloads carry the most risk, and what the destination architecture needs to support.

Azure Migrate provides a centralized hub for migration discovery, assessment, business case development, dependency analysis, and planning. It helps teams discover infrastructure and workloads, assess Azure readiness, evaluate cost considerations, understand dependencies, and organize migration activity across on-premises and multicloud environments. For customers moving servers, applications, databases, or dependent workloads to Azure, this creates the planning foundation needed to make informed migration decisions before execution begins.

Azure Copilot Migration Agent: Preview and benefits

To help close the gap between planning and action, Azure Copilot Migration Agent is extending Azure Migrate with new Azure Storage integration, now available in preview. Instead of leaving teams to interpret assessment outputs and manually map them to a storage migration approach, this guided, AI-powered experience uses Azure Migrate project data to help evaluate storage options, align workloads to the right Azure storage services, and identify the most appropriate execution tool, whether that is Azure Storage Move, Azure Data Box, or another Azure storage migration approach. The result is a faster, more connected path from discovery to decision, helping teams reduce uncertainty and move into execution with greater confidence. 

Find more preview information here

From there, teams need to make storage-specific decisions. Azure Storage migration guidance follows a phased approach:

Assess the source environment.

Select the right Azure Storage target.

Define the migration strategy.

Select the migration tool.

Execute.

This sequence matters because the right tool should follow the data requirements and destination architecture, not the other way around.

The goal is not to force every migration through a single path. It is to use the right Microsoft solution at the right stage of the journey.

2. Select the right Azure migration tool

Optimally, tool selection comes after assessment, target selection, and migration strategy. At this stage, organizations should understand what they are moving, where it needs to land, and how it needs to move. The decision should be guided by data volume, network capacity, downtime tolerance, synchronization needs, application dependencies, and whether the migration is online, offline, or phased.

3. Cloud data migration: Online and continuous migration with Azure Storage Mover

Azure Storage Mover supports managed online data movement and synchronization for file and object data for free. It is well suited for large-scale, repeatable migrations where data needs to move over the network with orchestration, monitoring, and control, including on-premises data estates and cloud-to-cloud transfers such as AWS S3 to Azure Blob Storage.

Azure Storage Mover is best suited for:

Online migration and incremental synchronization from on-premises data estates.

Cloud-to-cloud transfers, including AWS S3 to Azure Blob.

Data movement within Azure, including blob container-to-container copies.

As organizations evaluate cost, performance, and flexibility across cloud environments, the ability to move data between providers becomes more than a technical capability. It becomes a strategic advantage. Azure Storage Mover helps teams replatform data estates from AWS S3 to Azure Blob Storage without unnecessarily disrupting access or rebuilding the migration process from the ground up.

Learn how to migrate data from AWS S3 to Azure Blob

While Storage Mover helps with seamless, large- scale data migrations from AWS S3, customers often also need to migrate and modernize applications accessing that data. To address this, we now offer a new Copilot skill (in preview) that supports application migration, delivering a more complete end-to-end migration experience.

If you’re interested in trying the S3 app migration skill alongside your data migration, write to us at AzStorageMigration@microsoft.com.

All current Azure Storage Mover capabilities are available at no cost. Standard storage, transaction, and networking charges apply.

4. Offline data migration: Azure Data Box for large-scale transfers

Learn how Azure Data Box accelerates migration to cloud

Azure Data Box supports offline transfer for large-scale or bandwidth-constrained datasets. It is especially useful when network capacity or operational constraints make online transfer impractical, or when organizations need to accelerate initial bulk movement before later synchronization or cutover.

Azure Data Box 120 and Azure Data Box 525 are now available with no service fees and no Microsoft-managed shipping fees.

Azure Data Box is best suited for:

Datacenter exits and hybrid cloud transformation at scale.

Fuel AI and machine learning with high-volume data ingestion.

Protect and preserve bulk backup and media archives.

Modernize healthcare and mission-critical data systems.

Enable secure migration for government and regulated workloads.

Power enterprise analytics and modern data platforms.

Data Box enables high throughput transfer directly to Azure datacenters, reducing dependency on network performance and helping teams meet migration timelines when bandwidth is limited. It can also be used as part of a phased strategy, with Data Box handling the initial bulk transfer and online tools supporting later synchronization or cutover.

5. Real-world migration scenarios: Hybrid cloud, AI, and more

Most migration efforts involve more than one constraint. Teams may need to manage scale, connectivity, regulatory requirements, downtime windows, cost targets, and modernization goals at the same time. The value of Azure’s approach is realized when these solutions are used together.

Datacenter exit and hybrid cloud expansion

For datacenter exits and hybrid cloud expansion, organizations often need to move large, heterogeneous environments under strict timelines with minimal tolerance for disruption. Azure Migrate can help identify dependencies and sequence workloads. Azure Data Box can accelerate bulk transfers independent of network constraints. Azure Storage Mover can support synchronization and final cutover. This allows teams to execute phased migrations, validate workloads before cutover, and decommission infrastructure on schedule.

The success of datacenter exits is reflected in customer migrations already executed at scale. For example, Copeland used Azure Data Box to migrate more than 300 terabytes of data to Azure during a time-sensitive datacenter transition while maintaining business continuity.

Learn how Copeland rebuilt Connect+ on Azure

AI and machine learning data readiness

For AI and machine learning readiness, organizations need large volumes of high-quality data to be centralized, accessible, and continuously updated. Azure Data Box can support rapid ingestion of massive training datasets, research archives, or historical data. Azure Storage Mover can support ongoing synchronization and pipeline updates, helping data remain current for model training, experimentation, analytics, and AI development.

Backup, media archives, and long-term retention

For backup, media archives, and long-term retention, organizations often need to move large volumes of infrequently accessed data while maintaining durability, accessibility, and cost efficiency. Azure Data Box can support efficient transfer of large archival datasets, while Azure Storage tiers help optimize cost over time. Azure Storage Mover can support post-migration workflows where ongoing access or updates are required.

This approach is reflected in how The WNET Group modernized its media archive. Using Azure Data Box, WNET migrated approximately 3.6 petabytes of content, representing more than 800,000 hours of media, to Azure. The move enabled a datacenter exit while maintaining continuous broadcast operations, reduced asset retrieval times from up to 24 hours to under four hours and positioned the organization to apply machine learning for metadata enrichment and content discovery.

See how The WNET Group modernized with Azure Data Box

Healthcare, regulated, and mission-critical systems

For healthcare, regulated, and mission-critical systems, migration must balance security, compliance, governance, and operational continuity. Azure Migrate can help assess dependencies and support controlled sequencing. Azure Data Box can enable offline transfer for large sensitive datasets. Azure Storage Mover can support incremental updates where ongoing synchronization is required.

Astellas Pharma used Azure Data Box to transfer a 500-terabyte local file share to Azure and meet a six-month migration timeline that enabled the closure of six global datacenters. For regulated industries, this shows how offline transfer can help organizations move quickly while maintaining continuity and control over critical data.

Learn how Astellas Pharma moved to Azure

From migration execution to modernization outcomes

Migration is not the objective, it is the enabling step.

Once data is established in Azure, organizations can extend into analytics, artificial intelligence, and cloud-native architecture.

By aligning Azure Migrate, Azure Storage Mover, and Azure Data Box, organizations gain a migration strategy that reflects real-world conditions while positioning data for long-term value.

Get started with Azure Storage migration solutions

Explore Azure Storage and data migration solutions and begin building a migration strategy aligned to your environment, your timelines, and your modernization goals.

Explore Azure Storage Migration solutions

Discover Microsoft’s first-party tools for planning, managing, and executing data migrations at scale.

Get started with Azure

The post Modernize your data with Azure Storage: Plan and migrate with confidence appeared first on Microsoft Azure Blog.
Quelle: Azure

3 things leaders need to know from Microsoft Build 2026

In this article

1. Your AI is only as good as what it knows about your business2. Tools don't transform organizations. Systems do.3. The bar has moved. AI is expected to deliver real business outcomes.Your next step to build an AI-powered business
Related Build headlines

I’ve had a front-row seat to a few major technology advancements—the internet, then cloud, and now agentic AI. Before joining Microsoft, I founded a systems integration business, which means I sat on the other side of the table—the side where you’re trying to figure out which wave is real, what it means for your organization, and whether you’re moving fast enough.

That experience shapes how I think about moments like this one.

Every year, Microsoft Build delivers dozens of news and updates that developers follow closely. Most years, the story is about new capabilities for technical teams to explore. What’s different this year is that these capabilities feel less about exploration and more about meeting expectations to reshape how organizations operate, compete, and deliver results.

If you’re not a developer, Build can feel pretty technical, and it’s not always immediately obvious how the announcements can translate into business growth or savings. So I want to share a few of my takeaways for business leaders wanting a fast pass understanding of what matters most.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/408385-AzureBuild_tbmnl_en-us?wid=1280″,”title”:””,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/408385-AzureBuild-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/408385-AzureBuild-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/408385-AzureBuild-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/408385-AzureBuild-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6a2f11f92e321″, options);
});

Learn more about what Azure has to offer

1. Your AI is only as good as what it knows about your business

Models matter, but lasting advantage increasingly comes from how well AI understands your business—your unique data, your processes, and how your organization operates.

Every time a team deploys a new AI project, they run into the same problem—the AI starts without that context. It doesn’t know your customers the way your sales team does. It doesn’t understand your definitions of revenue, risk, or success. And as a result, every new project starts from scratch.

That’s why context has become a scaling issue. If every AI project has to rebuild the same foundation, organizations lose time, consistency, and momentum. That’s the gap we focused on closing at Build.

What this looks like in practice: A shared intelligence foundation for your entire organization.

Microsoft IQ introduces an enterprise intelligence layer where your data, processes, and organizational knowledge have live connections across every AI system, so new agents can start with an understanding of your business and improve as usage grows.

That shared intelligence layer moved from vision to reality with general availability. Work IQ helps AI understand how people work and how the business operates. Fabric IQ connects business data across systems and Power BI. Foundry IQ extends that grounding into deployed applications in Azure, unstructured data, and custom sources. Together, they help agents work from the same business context across the systems your organization relies on.

We also introduced Web IQ in limited preview as the newest member of the layer, bringing real-world context from outside the organization.

Together, these layers help agents work from the same business context across the systems your organization relies on. With that shared context in place, the next step is making the models themselves reflect your business.

And, with capabilities like Frontier Tuning, organizations can fine-tune models using their own data and workflows, reducing costs by up to 10x while improving response speed.

This is especially significant because we’re moving from AI that knows a lot about the world to AI that knows a lot about your world. For business leaders, that’s the difference between a generic tool and a system that reflects how your organization actually operates—maximizing your own data and expertise with AI systems for competitive advantage.

2. Tools don’t transform organizations. Systems do.

Most organizations have accumulated a collection of AI tools. A pilot here, an assistant there, a proof of concept that worked well enough to expand. What they haven’t built yet is an industrialized system designed for end-to-end production at scale.

The distinction matters. Individual tools produce individual results. A system that shares context, enforces governance, and gets smarter the longer it runs.

This was front and center at Build this year, and its core to how we’ve built Azure.

What this looks like in practice: An integrated platform for building, running, and governing agents at scale.

Built on Azure, the Microsoft Agent Platform brings together what organizations need to build, run, govern, and scale agents across the business. It’s the foundation for moving agents out of pilots and into production—and it’s designed to solve three challenges that consistently slow that transition down.

The first challenge is speed: moving from a promising prototype to something the business can actually run. Rayfin helps close that gap by making it easier to go from concept to enterprise-grade deployment, with security, data management, and governance built in from the start.

The second challenge is modernization. Once AI starts touching core business systems, those systems need to evolve continuously, not through large, disruptive transformation cycles. New agentic capabilities in Azure help teams update, integrate, and improve applications in parallel and on an ongoing basis, so systems can keep pace with the business without slowing operations down.

And the third challenge is trust at scale. As more agents move into production, governance and security need to be part of the system from the beginning. That’s why Azure brings together Microsoft Foundry, Agent 365, Azure Container Apps, and the broader Microsoft Security stack to help organizations run agents with controls built in from the moment they start operating.

The winners of this era won’t be the organizations with the most AI tools. They’ll be the ones that build the best system around them.

3. The bar has moved. AI is expected to deliver real business outcomes.

It would be easy to read the Build announcements as something to watch from the sidelines. But your board or C-Suite might have other ideas. There’s a version of this moment where business leaders read the Build announcements and think, interesting, I’ll keep watching. Your board or C-suite might already be several steps ahead.

Why? Because the question organizations were asking a year ago, does AI actually work?, has been answered. The question now is different: why isn’t it running significant parts of our business yet?

In other words, AI is now expected to deliver measurable outcomes—like faster cycle times, lower costs, and improved customer experiences—not just insights or experimentation.

What this looks like in practice: Enterprise-ready choice, control, and resilience.

Foundry now offers the broadest selection of frontier models in the industry—from OpenAI’s GPT-5 series to the latest from Anthropic and Fireworks AI’s open-weight lineup—all with security and governance built in. We also entered the frontier model space at Build with a new family of enterprise-ready MAI models, giving organizations more control over cost, performance, and how AI is applied to specific business scenarios. The business point is not simply model choice. It’s the ability to shape AI around your own data, workflows, and needs so it can deliver better outcomes at lower cost.

Microsoft Discovery helps BHP’s copper innovation

Learn more ↗

That control matters most when AI moves beyond assistance and into deep, scientific, and engineering work. Microsoft Discovery, our agentic AI platform for scientific research and complex problem-solving, is now generally available. It uses specialized AI agents to dig through research, generate hypotheses, run simulations, and refine results in continuous loops—compressing timelines that used to take years into months. This is the shift business leaders should pay attention to: AI is beginning to compress the timeline for work that used to take long cycles of research, analysis, and iteration.

To support that shift, the infrastructure is also changing. GPU-accelerated Fabric Data Warehouse delivers up to 7x faster query performance for AI-scale workloads, relative to three comparable external vendors for reporting and application workloads at 64-user. Azure Cobalt 200 VMs bring purpose-built cloud infrastructure for AI-native workloads.

And Azure Infrastructure Resiliency Manager helps organizations plan for resilience when AI is running real operations.

The net is production readiness: giving organizations the control, speed, compute, and resilience they need to run AI in the parts of the business where performance matters.

Your next step to build an AI-powered business

For me, the throughline is how expectation has replaced experimentation.

AI is now embedded in workflows, connected across systems, and expected to deliver meaningful outcomes.

For business leaders, the implication is strategic and immediate. The question is no longer whether AI works, but where and how it should be running in your business right now. That means using the next planning cycle to ask a more operational set of questions:

Where are we still treating AI as an isolated pilot instead of connecting it to core workflows?

Where do we need shared data and context before another tool or model will make a difference?

Which prototypes are ready to move into production, where value can actually be realized?

Which AI initiatives are tied directly to business outcomes like cost reduction, speed, and customer impact?

Where should AI be running meaningful parts of the business today, not next year?

Your competitive advantage won’t come from experimenting with AI. It will come from how quickly you put it to work with a solid system that’s grounded in your own intelligence and run on a foundation you can trust.

Related Build headlines

Microsoft Build 2026: Be yourself at work

AI alone won’t change your business. The system running it will.

Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases

Building a hill-climbing machine: Launching seven new MAI models

Majorana 2, made more reliable with Microsoft Discovery agentic AI

Build and scale AI systems with Azure

From Microsoft IQ and Foundry IQ to HorizonDB, find out what you can do with Azure.

Get started

The post 3 things leaders need to know from Microsoft Build 2026 appeared first on Microsoft Azure Blog.
Quelle: Azure

A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

The hardest part of building AI systems today is no longer getting access to a capable model. It is knowing how to choose, validate, optimize, and operate the right model across the full lifecycle of a real application.

Take a retrieval-augmented generation (RAG)-based customer support copilot or a tool-calling agent that helps employees complete business workflows. In a prototype, it may be enough to pick a strong model, connect a few data sources, and get a useful response. In production, the system needs to retrieve the right context, call the right tools, meet quality and safety thresholds, stay within latency targets, and run at a cost the business can sustain.

Models evolve, costs shift, and production requirements often arrive after the first version is already working. Success depends less on choosing the most powerful model and more on building a disciplined operating approach around the application.

That is where Microsoft Foundry comes in: a unified platform to select, evaluate, optimize, operate, and continuously improve AI applications at production scale.

What’s new

Microsoft Foundry continues to expand the model ecosystem and operating surface for developers building production AI systems.

Fireworks AI on Microsoft Foundry is now generally available, giving developers access to production-grade open model inference through a single Azure endpoint, with enterprise service-level agreements (SLAs) and zero-setup onboarding.

Foundry is also adding new model families and capabilities across modalities, including Microsoft AI models, partner models, open-source models, custom models, and post-trained variants. Together, these updates give developers more choice while keeping selection, evaluation, deployment, and operations in one consistent workflow.

The challenge is no longer access. It is operations.

In a prototype, the questions are simple: Can the model answer the prompt? Can it connect to my data? Can it complete the happy path?

In production, the questions change. Which model fits each task? How do I validate it on my own data? What latency budget does this experience require? How much throughput do I need at peak? What happens when quota is constrained, costs spike, or a newer model becomes available? How do I monitor quality, detect eval drift, roll back safely, and prove the system is governed?

Agentic systems often fail when the model is mismatched, evaluation is incomplete, costs run unchecked, or governance arrives too late. Teams that rely on a single provider face another risk: lock-in, with no escape hatch when a model degrades, pricing changes, or capacity becomes constrained.

Foundry is built on the opposite philosophy. It is a model-agnostic platform spanning Microsoft, open-source, and independent software vendor (ISV) partner models, all on the same operating surface.

The answer is to treat model selection and optimization as a continuous operating discipline: 

1. Select the right model for the task

Model selection is about workload fit, not leaderboard rank. Before choosing a model, define the task contract: what the model needs to do, what good looks like, what constraints it must operate within, and which failure modes are unacceptable.

A routing step may need low latency. A policy question may need grounded reasoning with citations. A coding agent may need deeper reasoning and tool use. A customer-facing copilot may need strong safety boundaries, predictable latency, and cost efficiency at scale.

A simple model selection framework:

Workload needFavor this approachWhyClassification, routing, extraction, or high-volume chatSmaller, lower-latency modelKeeps cost and latency lowComplex reasoning, coding, or planningStronger reasoning modelImproves quality for harder tasksImage, speech, voice, or physical AIModality-specific modelMatches the model to the input and output typeMixed workloads with different complexityModel RouterRoutes each request based on quality, cost, and latencyDomain-specific behavior, tone, or formatFine-tuned or custom modelImproves consistency for your scenario

Effective model choice depends on four dimensions: capability, safety, latency, and cost.

Foundry helps developers make these tradeoffs through a broad model ecosystem and a consistent operating surface. Developers can access Microsoft models, leading base models, partner models like Fireworks AI, open-source models, custom models, and post-trained variants through one selection, evaluation, and deployment workflow.

Developer tip: For developers who want to bypass manual selection, Foundry provides Model Router in Foundry Models. Model Router automatically routes each request to the most appropriate model based on workload characteristics, cost targets, and latency requirements.

2. Validate with your own evals and data

Benchmarks are not enough. A model that leads a public leaderboard may still underperform on your prompts, your data, your users, and your business rules. Production confidence comes from evaluating against the workloads your application will actually run.

With Foundry, developers can bring their own evaluation inputs, including CSV or JSONL datasets with prompts, expected outputs, labels, or ground-truth answers. They can run side-by-side comparisons across models and prompts, evaluate agents and multi-step workflows, and inspect results across datasets, traces, and production-like scenarios.

Built-in quality and safety evaluators help measure signals such as relevance, groundedness, coherence, fluency, safety, and policy adherence. Custom evaluators can capture application-specific rules, formats, and business logic.

A strong evaluation covers:

Quality: Did the model complete the task correctly? Accuracy and groundedness: Did it produce reliable answers based on the right context? Safety: Did it follow policies and avoid unacceptable responses? Performance: Did it meet latency, throughput, and reliability requirements? Cost: Did it deliver the right outcome at the right price?

Evaluation should run continuously as new model versions, fine-tuned variants, agent changes, or new model families become available.

Developer tip: Define success criteria before opening the model catalog. Criteria-first evaluation prevents anchoring on model reputation instead of workload fit.

3. Optimize cost and performance

Cost is a first-class architectural concern, not an afterthought. In prototypes, it may be acceptable to send every task to the most capable model. In production, that approach breaks down quickly.

A simple classification task, a RAG response, a long-context reasoning workflow, and a multi-step agentic process should not always use the same model or deployment strategy.

Foundry gives developers levers to optimize across quality, cost, and latency at the system level:

Intelligent routing: Send each task to the right model based on complexity and budget. Batching: Use asynchronous processing for workloads that do not require real-time responses. Caching: Avoid paying repeatedly for identical or near-identical requests. Provisioned throughput: Use dedicated capacity for predictable performance at scale. Quota management: Scale more predictably with quota tiering, global customer quota, and data zone customer quota. Model optimization: Use model compression, fine-tuning, or distillation where appropriate.

Fireworks AI on Foundry is now generally available, giving developers access to a high-performance open model catalog through a single Azure endpoint, with enterprise SLAs, no separate infrastructure, and no separate contracts.

Developer tip: Profile cost by task type before optimizing globally. Routing decisions are workload-specific, not one-size-fits-all.

4. Operate at scale with enterprise confidence

Deploying an endpoint is not the same as operating a production AI system. Teams need to understand how the system behaves, enforce policies, monitor usage and cost, test model changes safely, and roll back when quality or performance regresses.

Foundry brings these operating capabilities into one surface: versioning, SLA-backed reliability, security, governance, access controls, audit logging, usage monitoring, and controlled upgrades.

Teams can monitor token usage and throughput, inspect logs and traces, evaluate model and agent behavior, enforce policies, and compare changes before rolling them out broadly. As new model versions become available, they can test against evaluation datasets and traces, validate quality, latency, and cost impact, and reduce risk with versioning and rollback strategies.

The Fireworks AI on Foundry generally available (GA) release is a concrete example of this operating model, with enterprise SLAs, provisioned throughput unit (PTU) Data Zone support, SOC2 readiness, and the same access controls and audit logging that govern Foundry.

Production adopters span AI-native and traditional enterprise workloads, including Perplexity, Motif, UiPath, and StackBlitz. During preview, the platform processed more than 176 billion tokens across 17 S&P 500 enterprises.

Developer tip: Treat model upgrades like dependency upgrades: test against baselines, stage rollouts, monitor regressions, and keep a rollback plan.

5. Continuously improve as models and workloads evolve

AI systems are dynamic. Models improve, workloads shift, user behavior changes, pricing evolves, and new model families arrive. The best system today may not be the best system six months from now.

That is why the lifecycle loop matters:

Select the right model for the task. Evaluate it against your own data and production baselines. Optimize for quality, cost, latency, and throughput. Operate with governance, observability, and reliability. Improve as new models, tools, and customization options emerge.

For engineering teams, every model, prompt, tool, agent, or workflow change should be treated like a production change. New model versions should be tested automatically against regression datasets, production traces, and known edge cases before rollout.

A model may improve quality but increase latency, reduce cost but weaken groundedness, or perform better on common cases while regressing on high-risk scenarios. Automated evaluations help teams detect those tradeoffs early.

Developer tip: Automate your evaluation pipeline so every new model version is compared against production baselines for quality, safety, latency, throughput, and cost before deployment.

What this means for developers

The next phase of AI development will not be won by teams that simply have access to the biggest models. It will be won by teams that know how to operate models well.

That means choosing by workload fit, validating with real data, optimizing cost and performance, deploying with governance, and improving as the landscape shifts.

Microsoft Foundry is designed for exactly this reality: a model-agnostic platform spanning Microsoft, open-source, and ISV models, all on one operating surface. No lock-in. No re-architecture. No guesswork.

The future of AI development is not about guessing which model might work. It is about building an operating discipline that lets you know.

Get started

Microsoft Foundry portal

Microsoft Foundry documentation

Fireworks AI on Foundry (now generally available)

Evaluation quickstart

Quota management docs

Watch BRK230: Build smarter AI systems in Foundry as models and costs evolve

Claude Foundry Skilling Learning Path

The post A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry appeared first on Microsoft Azure Blog.
Quelle: Azure