Cloud Computing Köln

Two zones or three? A design framework for zone-resilient Azure workloads

Takeaway: Zone resiliency isn’t a single number you apply to a whole workload. The useful question isn’t “how many zones?” but “how many zones does each component need to survive the loss of one?” Decide zone patterns component by component, use service-managed zone redundancy wherever it fits, and reserve three-zone designs for the components that genuinely require a third failure domain. For a deeper, decision-oriented walkthrough on choosing between two-zone and three-zone patterns for your specific workloads, see the companion post, Choosing two-zone and three-zone patterns for zone-resilient Azure workloads.

Ask a room of architects how many Microsoft Azure availability zones a production workload needs, and most will answer “three.” It’s a reasonable instinct, but “three zones everywhere” is a rule of thumb standing in for a decision that deserves more thought. Treating it as a default quietly costs you capacity, money, and operational complexity you may not need while occasionally giving you less protection than you assumed.

Zone resiliency is not a property you switch on for an entire workload. It’s a set of decisions you make component by component. Some components are fully protected across two zones. Some genuinely need a third. And for a growing number, Azure manages zone redundancy for you, and the best decision is to let it. This post is about how to tell the difference.

Learn architecture strategies for availability zones and regions

What availability zones protect against (and what they don’t)

An Azure region that supports availability zones is made up of separate groups of datacenters, each with independent power, cooling, and networking. Zone resiliency protects you against the loss of one of those zones. It does not protect you against the loss of the entire region. If your workload is mission-critical or carries strict disaster-recovery requirements, zones are necessary but not sufficient: you also need a multi-region conversation, and that’s a separate design exercise.

It’s worth being precise about what “using zones” means, because Azure services expose it in two different ways:

Zone-redundant resources are spread or replicated across zones by Azure itself. Azure handles the replication, request distribution, and failover. Where a service offers zone redundancy and it meets your requirements, it should generally be the starting point, especially for production workloads.

Zonal resources are pinned to one zone. A zonal resource is isolated from failures in other zones, but it is not automatically resilient to a failure in its own. To make a zonal design resilient, you deploy instances across zones yourself and own the routing, replication, failure detection, and recovery.

That distinction matters, because reliability on Azure is a shared responsibility. The resilience of a zone-redundant service is Microsoft’s responsibility to deliver; the resilience of a zonal design you assemble yourself is largely yours to configure and prove. No layer makes up for a gap in another.

Decide at the component level, not the workload level

The reason “three zones everywhere” may not be the correct starting point is that a workload is not one thing. It’s a stateless front end, an application tier, a queue, a cache, a relational database, an object store, and often a quorum-based system or two each with different failure behavior. Applying one zone count to all of them optimizes for none of them.

Break the workload down by critical flow, then by component, and ask three questions of each:

Resource availability: If one zone goes down, can the remaining zone or zones carry the operating state you need? For a single-zone failure, two zones and three zones can both meet the objective. The third zone does not, by itself, make a component resilient to more than one zone failure in the same region.

Data consistency and durability: Does the component’s correctness depend on a third failure domain? Quorum, consensus, leader election, split-brain prevention, and the highest durability targets often do.

Cost and capacity: For the same post-failure performance, recovery capacity is distributed differently across two zones versus three. Decide the resiliency objective first, then optimize cost, not the other way around.

One subtlety worth flagging: If more than one zone is unavailable in the same region at once, your problem has usually stopped being a workload problem and become a regional one: foundational regional services themselves depend on surviving zones. Designing past a single-zone failure puts you in disaster-recovery territory, which is a different conversation.

A starting point: Where common components tend to land

Most components fall into one of a few buckets. Treat this as a first read, not a support matrix. Zone behavior varies by service, SKU, tier, region, and configuration, so always validate against the service’s own reliability guidance.

Component typeTypical zone decisionStateless compute, application, or network components (no persistent data)Two or three zones, based on remaining capacity, routing, latency, and operations. Both can meet a single-zone objective.Stateful systems using quorum, consensus, or leader electionThree zones, a third failure domain, or a product-specific witness pattern to avoid split-brain and quorum loss.Critical data stores needing three replicas for the highest durability targetsThree-zone replication is often required to reach the intended durability level. Validate the service’s specific claims.Other stateful resourcesTwo-zone, three-zone, or service-managed, depending on recovery time objective (RTO), recovery point objective (RPO), durability, and failover behavior.Anything Azure can make zone-redundant for youUse service-managed zone redundancy when it meets your requirements.

Where two zones are enough

Two zones is not a compromise. For many components it’s simply the right answer: fully meeting a single-zone failure objective while being simpler to deploy, test, and operate. Two zones tend to be enough when:

The component is stateless or easily replaced, and traffic can shift to the surviving zone.

An active-active or active-passive pair is easier to reason about and operate.

A latency-sensitive synchronous path performs within budget on a tested zone pair.

A customer-managed zonal design has validated capacity, failover, monitoring, recovery, and failback.

The component can run in an approved degraded state after losing a zone.

Whichever you choose, define exactly what happens when a zone goes away: remaining capacity, acceptable degradation, data consistency, failover behavior, recovery steps, observability, and who owns each of them.

Where three zones earn their keep

Three zones are required when two cannot meet the component’s needs during or after a single-zone failure. In practice that’s usually one of:

A post-failure operating state the remaining zone in a two-zone design simply can’t sustain

Durability or replication that depends on placement across three zones: triple-replica placement for the highest durability targets

Quorum, consensus, or leader-election designs that need a third failure domain or witness to avoid losing quorum or splitting brain.

A caution that trips up even experienced teams: three replicas are not the same as three failure domains. Place a majority-quorum system’s replicas across only two zones and you can still lose quorum when the majority-holding zone goes down. Replica count is not replica placement.

Be honest, too, about a middle category. Some components don’t require a third zone but benefit from one for capacity distribution, maintenance flexibility, or operational margin. That’s a legitimate reason to choose three zones. It’s just a different reason than “we’d lose the system otherwise,” and it’s worth writing down which one applies.

The cost conversation comes last

Cost and operational complexity are real, but they belong at the end of the decision, not the start. Don’t let them talk you out of a two-zone design that meets requirements, and don’t let them justify a two-zone design that doesn’t. Counterintuitively, for the same post-failure capacity target, a three-zone design can provision less total capacity than a two-zone one, because the recovery headroom is spread across more zones. Model that tradeoff before you optimize, use commitment-based discounts such as Azure savings plans or Azure Reservations where usage is predictable, and make sure whichever you pick can actually be operated: deployed, monitored, tested, failed over, recovered, and reviewed.

Discover saving plans for compute and databases workloads

Component classification checklist

Run each component through this checklist and confirm that:

Every critical flow is decomposed into the components that support it.

Each component is evaluated for resource availability, data consistency and durability, and cost or capacity impact.

Each component is classified as service-managed zone-redundant, two-zone customer-managed, or three-zone required.

Wherever three zones are required, the specific requirement driving that decision is written down.

Each service’s zone support is validated for the SKU, tier, region, and configuration you’re actually using.

Customer-managed zonal resources have validated routing, load balancing, replication, failover, monitoring, recovery, and failback.

Remaining capacity and acceptable degradation after one zone loss are documented.

Quorum-based components have validated replica placement, witness or tie-breaker behavior, leader election, and split-brain prevention.

Latency-sensitive paths are tested across the actual zone placement they’ll run on.

Security, identity, monitoring, and data-protection requirements are preserved across the design.

Ownership for testing, incident response, failover, failback, and periodic reassessment are assigned.

The discipline is in the details

Zone resiliency isn’t a slider you set once for an entire workload, and it isn’t a number you can copy from someone else’s architecture. It’s a series of deliberate, component-level decisions about how much failure each part of your system has to absorb. The discipline is in making each one on purpose, writing down why, and validating that the design behaves the way you assumed when a zone actually goes down.

Get that right, and “two zones or three?” stops being a debate. It becomes what it should be: an answer you can defend, component by component.

Related resources

Azure services that support availability zones

Enable zone resiliency for Azure workloads

Zonal resources and zone resiliency

What are Azure availability zones

Architecture strategies for availability zones and regions

Design for resilience with Azure Regions and Availability Zones

Learn how to use Azure regions and Availability Zones to improve workload resiliency, reduce downtime, and support business continuity with well-architected deployment strategies.

Explore best practices

The post Two zones or three? A design framework for zone-resilient Azure workloads appeared first on Microsoft Azure Blog.
Quelle: Azure

The future of infrastructure resiliency starts with modernization

Why infrastructure resiliency is essential for modern applications and AI workloads

Organizations today face constant pressure to modernize; business-critical applications are being transformed, AI workloads are becoming foundational to business operations, and infrastructure environments continue to grow in complexity. Yet modernization only succeeds when organizations have confidence that their applications, data, and infrastructure can withstand disruption and continue supporting critical operations.

As organizations adopt distributed applications, AI-powered services, and hybrid and multicloud architectures, the resiliency of their IT estate has become more than a technical consideration, it is a business requirement. Resiliency is the ability of infrastructure and workloads to withstand, adapt to, and recover from disruptions while maintaining critical business operations. Organizations need infrastructure platforms that can help reduce the impact of disruption, maintain workload availability, and support effective recovery when challenges occur.

Learn about resilient cloud applications

At the same time, resiliency strategy is evolving. Historically, organizations often approached resiliency through backups, redundancy, and disaster recovery plans. While these capabilities remain essential, modern resiliency requires a broader approach that spans architecture, operations, recovery, and continuous optimization. Customers increasingly recognize that resiliency is not about preventing every disruption. It is about designing for uncertainty, minimizing operational impact, recovering effectively, and continuously strengthening readiness over time.

At Microsoft, we believe Azure IaaS resiliency is an ongoing partnership and shared responsibility that helps organizations modernize with confidence. Microsoft Azure provides the infrastructure foundation, platform capabilities, and guidance that enable customers to build resilience into workloads from the start, maintain operational continuity as environments evolve, and continuously improve recovery readiness over time.

Resilient by design

Resiliency starts long before an outage occurs.

As organizations modernize business-critical applications, cloud-native services, and AI workloads, resiliency can no longer be bolted on after deployment. The most effective resiliency strategies begin during planning and design, with architectures that align availability, recovery, performance, compliance, and operational requirements to the needs of each workload. Not every application requires the same resiliency strategy, and a one-size-fits-all approach is no longer sufficient. This is especially true for AI and business-critical workloads, where downtime, performance degradation, or data loss can have significant business consequences.

Azure helps organizations build resiliency into infrastructure from the start through availability zones, resilient networking architectures, durable storage options, recovery services, and proven guidance from the Azure Well-Architected Framework and Azure Architecture Center.

The recently announced Azure Infrastructure Resiliency Manager extends this foundation by helping organizations define resiliency goals, understand workload criticality, identify gaps, and evaluate resiliency posture at the application level. Rather than relying on manual reviews and static assessments, organizations can continuously understand how workloads align to resiliency objectives and where improvements may be needed.

Explore Azure Infrastructure Resiliency Manager

To further simplify resiliency adoption, Azure Infrastructure Resiliency Manager provides recommendations, deployment guidance, and AI-assisted experiences through the resiliency agent in Azure Copilot. Teams can describe workloads, generate resilient deployment templates, assess existing environments, and receive recommendations aligned to their resiliency goals. This helps organizations embed resiliency earlier in the lifecycle and reduce the effort required to operationalize best practices.

The goal is simple: make resiliency part of how applications are designed, not something organizations revisit only after a disruption has occurred.

Innovate without interruption

Modernization is not a one-time project. Applications evolve, new services are introduced, new dependencies emerge, and infrastructure environments continuously change.

As environments evolve, resiliency must evolve with them.

One of the most common challenges organizations face is maintaining operational continuity while introducing change. New deployments, configuration drift, scaling requirements, infrastructure updates, and evolving application architectures can gradually move workloads away from their original resiliency objectives. What was resilient six months ago may no longer meet current availability or recovery requirements.

This is why resiliency is becoming a continuous operational practice rather than a one-time design exercise. Organizations increasingly need visibility into resiliency posture, the ability to prioritize remediation efforts, and mechanisms for validating whether workloads continue to meet business objectives as they grow and change. Azure Infrastructure Resiliency Manager helps organizations continuously assess resiliency posture, identify high-priority gaps, and increase uptime through recommendations, operational guidance, and application-centric resiliency management.

Azure is also embedding resiliency more deeply across the infrastructure stack, enabling the platform to respond to certain component-level disruptions while helping unaffected resources continue operating. This increasingly self-healing approach can reduce the blast radius of isolated failures and help maintain continuity as infrastructure conditions change.

Per-disk resiliency for Azure Managed Disks, now available in public preview in select regions, illustrates this approach at the storage layer. Traditionally, when a virtual machine lost connectivity to an attached managed disk for an extended period, Azure recovered the virtual machine after connectivity was restored. With per-disk resiliency enabled, Azure can temporarily take only the affected data disk offline while allowing the virtual machine and its remaining disks to continue operating. After connectivity is restored, Azure automatically reattaches the disk.

For workloads that can tolerate the temporary loss of an individual data disk, including clustered applications, workloads using auxiliary disks, and certain containerized architectures, this approach can help reduce the impact of isolated storage disruptions and allow critical workload operations to continue. It reflects a broader trend in cloud resiliency: reducing the blast radius of failures and helping organizations continue innovating even when individual infrastructure components encounter issues.

Improve workload availability with per-disk resiliency

Recover with confidence

No organization can prevent every disruption.

The measure of resiliency is not whether disruption occurs. It is how effectively organizations prepare for, respond to, recover from, and learn from those events.

Historically, recovery planning was often treated as a periodic exercise. Today, leading organizations recognize that recovery readiness must be continuously validated. Recovery plans that have never been tested may not perform as expected during an actual disruption.

Azure helps organizations improve recovery readiness through integrated backup, disaster recovery, monitoring, and resiliency management capabilities. Organizations can define recovery objectives, validate failover strategies, monitor recovery performance, and continuously improve resiliency posture over time. Azure Infrastructure Resiliency Manager and Azure Chaos Studio extend this process by helping teams test recovery plans under controlled conditions, validate failover procedures, identify hidden dependencies, and measure recovery outcomes against defined objectives before a real disruption occurs.

A configuration that looks resilient on paper still has to withstand a real failure. Azure Chaos Studio helps organizations simulate outage conditions and validate how applications respond. From availability zone failures and database failovers to DNS and Microsoft Entra disruptions, teams can safely test assumptions, verify recovery procedures, and build confidence that their resiliency strategies will perform as intended. Guided drills, automated cleanup, and audit-ready reporting help transform resiliency validation into an ongoing operational practice rather than an infrequent event.

Recovery confidence also depends on protecting data and preparing for increasingly sophisticated cyber threats. Infrastructure failures are only part of the resiliency equation. Organizations must also plan for accidental deletion, data corruption, ransomware, and compromised credentials.

Azure Backup helps organizations improve recovery readiness with built-in capabilities that protect backup data, support cyber resilience, and simplify recovery. Features such as immutable vaults, soft delete, multi-user authorization, and recovery orchestration help organizations preserve clean recovery points and restore critical workloads with confidence.

When recovery involves a cyberattack rather than an infrastructure failure, trust becomes just as important as speed. Capabilities such as immutable vaults, multi-user authorization, and isolated recovery experiences help organizations identify trusted recovery points and restore operations without reintroducing compromised data or configurations.

The future of resiliency is not simply recovering faster. It is enabling organizations to build resilient foundations, operate with confidence as environments evolve, and continuously strengthen recovery readiness over time.

Modernize confidently with help from the Azure IaaS Resource Center

See Azure resiliency capabilities in action

Join Microsoft’s Azure webinar series “Minimize downtime with resilient cloud applications” episode on September 17 at 10:00 AM PT, where Azure resiliency experts will demonstrate how organizations can build resilient architectures, assess resiliency posture, validate recovery readiness, and strengthen recovery outcomes using Azure Infrastructure Resiliency Manager, Azure Backup, Azure Site Recovery, Azure Chaos Studio, and the Azure Copilot Resiliency Agent.

Minimize downtime with resilient cloud applications

Learn strategies to improve application resilience, reduce downtime, and maintain business continuity in the cloud.

Register for webinar

The post The future of infrastructure resiliency starts with modernization appeared first on Microsoft Azure Blog.
Quelle: Azure

The Economics of Agent Optimization: How AI agent governance controls cost and proves ROI

This blog post is the fourth and final installment of The Economics of Agent Optimization, which shares the strategies, capabilities, and proof points that can help you optimize agent costs and run AI as a managed investment system on Microsoft Foundry. The first post set out the three decisions that systems rest on, the second post took the request at runtime, and the third post took the workflow over time. This post takes the decision that never stops running: governing the spend.

AI agents are moving from isolated pilots into an enterprise estate. They work across teams, connect to data and tools, and make decisions with varying degrees of autonomy. For IT leaders, that creates a broader operating question: how do you govern a agentic system that can grow and act faster than traditional applications?

AI agent governance starts with knowing which agents exist, who owns them, what they can access, and which policies apply. It is often discussed in terms of security, compliance, and lifecycle management. It is also fundamental to cost optimization. Without consistent governance, each team makes its own choices about models, tools, capacity, and limits—and small inefficiencies multiply across every agent and every turn.

Good governance makes consumption visible, attributable, and bounded. IT needs to see which agents and teams are driving usage. Finance needs budgets and cost allocation it can trust, without discovering an unexpected increase after the invoice closes. Developers need controls that can respond at the speed agents run.

That last requirement exposes an important distinction. Traditional cost management tools can track spending and alert on actual or forecasted costs, but they typically operate on billing data rather than in the request path. An agent caught in a retry loop does not wait for the next budget evaluation.

A budget alert is a smoke detector. An agent also needs a circuit breaker. Effective cost governance therefore depends on three things: seeing the spend, bounding it, and proving the return.

See the spend where it starts

AI costs become difficult to manage when they arrive as one aggregate number. One deployment may serve several agents; one agent may use several models and tools; and one outcome may require many turns. By the time that appears on an invoice, the business context has disappeared.

Cost management capabilities in Foundry brings that context closer to the systems creating it. Teams can see estimated costs across projects, inspect cost and token usage for individual agents, and monitor model costs. These estimates support operating decisions; Microsoft Cost Management and invoiced charges remain the system of record for financial reconciliation.

Foundry also supports project-level cost attribution. Every Foundry project is automatically associated with a project tag on its underlying usage. FinOps teams can filter Cost Analysis by that tag to allocate spending to the business unit, team, or workload that incurred it. This capability is currently in preview for models sold by Microsoft Azure, including Azure OpenAI.

At the gateway, Azure API Management’s AI Gateway can emit token metrics by API, product, user, subscription, gateway, and backend. Tracing in Foundry captures tool usage, retries, latency, token consumption, and costs for an agent run.

Together, observability signals explain not only how much an agent consumed, but why:

Traces reveal model calls, tool invocations, retries, latency, and token usage.

Monitoring surfaces production trends and anomalies.

Evaluations measure quality, safety, groundedness, and task completion. Run continuously, they give teams evidence to test whether a smaller model still meets their quality bar rather than defaulting to the largest one. Safety evaluators can also flag issues such as prompt injection, sensitive data leakage, and harmful content before they reach production, where remediation can be costly.

Viewed together, these signals help teams understand whether rising costs are driven by customer demand, inefficient agent behavior, quality regressions, or architectural issues.

That context turns cost data into actionable governance. Before teams can set limits or measure ROI, they need to understand how agents behave in production.

Set spend limits at every layer

Visibility tells you where the money went. Limits determine whether it can keep going. There are three layers to the control system, each working at a different scope and speed:

1. Enforce limits in Foundry

With AI Gateway configured, Foundry Control Plane can enforce tokens-per-minute rate limits and total token quotas for model deployments at the project scope. A request that exceeds the rate limit receives a 429 Too Many Requests response. A caller that exhausts its token quota receives a 403 Forbidden response.

Unlike a cost alert, enforcement happens in the request path. Teams can contain one project’s consumption before it monopolizes shared capacity and establish different boundaries for different projects. Quotas can operate over hourly, daily, weekly, monthly, or yearly periods. Teams can configure the Azure API Management-backed gateway and manage its token limits through Foundry Control Plane.

2. Apply policy across models and providers

For controls spanning projects or model providers, the llm-token-limit policy limits consumption per key using a rate, a cumulative quota, or both. The key can represent a subscription, application, team, customer, workload identity, or another business boundary.

AI Gateway applies the same governance model across OpenAI-compatible APIs, the Anthropic Messages API, as well as MCP servers and agent-to-agent APIs. Backend load balancing can prioritize provisioned capacity before spilling over to pay-as-you-go deployments, while circuit breakers can temporarily stop sending requests to a failing or throttled backend.

Like any distributed limit, these controls have boundaries. Counters are maintained independently at each gateway, and concurrent requests can create a small temporary overage because final token consumption is known only after responses return. The goal is to replace unbounded consumption with a predictable operating boundary.

3. Use financial budgets for accountability and escalation

Microsoft Cost Management budgets serve a different purpose from token limits. They use Azure billing data, including actual prices, credits, and purchasing commitments, to give finance and IT an authoritative view of what the organization has spent and is forecast to spend.

Teams can set budget thresholds and notify owners when actual or forecasted costs approach them. They can also connect a budget to an Azure Monitor action group, which can invoke a customer-designed workflow such as opening a ticket, notifying an operations team, or starting a Logic App or automation runbook. Cost anomaly detection provides another warning when spending departs from its historical pattern.

These are valuable accountability and escalation tools, but they are not instant spending caps. They respond to billing data after consumption occurs. Token limits operate earlier, in the path of each model request, where they can reject new calls after a rate limit or quota is reached. Organizations need both: token limits to contain consumption as agents run, and financial budgets to keep owners accountable and prevent finance from being surprised.

Today, these two layers use different units. The platform enforces consumption in tokens, while finance plans and allocates investment in dollars. Because token prices vary by model and offer, a token quota does not translate into one stable dollar amount.

We are actively working to close that gap with future capabilities in Microsoft Foundry and the AI Gateway in Azure API Management that bring dollar-denominated budgets, finer-grained attribution, and policy-driven controls closer to where agents run.

Measure the value the agent creates

Putting a ceiling on consumption solves only half of the governance problem.

While cost controls can help organizations manage spending, they do not answer a more important question: is the agent delivering enough business value to justify that investment?

The least expensive agent is not necessarily the best investment. An agent that costs more but resolves substantially more cases may deserve additional capacity. An inexpensive agent that rarely completes its task may not. Governance therefore needs a second unit alongside tokens and dollars: business outcomes.

This is ultimately an ROI problem. Organizations want to understand whether their agents are creating more value than they cost. However, connecting business outcomes to the underlying cost of running an agent can be difficult.

ROI for agents in Foundry, currently in private preview, helps organizations connect agent costs to business outcomes. Teams define the outcomes they want to track, such as successful task completion, customer satisfaction, or case deflection. They then assign a business value to those outcomes and define how success should be measured. Foundry tracks which outcomes an agent achieves, and the model and tool costs incurred along the way, calculating:

Value generated: The total value attributed to successful business outcomes.

Total cost: The model and tool costs incurred to achieve those outcomes.

Net value: The value remaining after costs are subtracted.

ROI: The return generated relative to the investment required.

The dashboard shows daily trends and separates models from tool costs. Teams can compare agent versions using average value per conversation, pass rate, and improvement percentage. That makes optimization decisions defensible in business terms: not merely “the new version uses fewer tokens,” but “the new version produces more net value.”

The ROI feature also connects the business view to engineering evidence. Teams can inspect the lowest-ROI conversations and traces to find an oversized model, repetitive tool calls, or a workflow consuming tokens without producing meaningful outcomes. Because ROI is connected to observability data, teams can move directly from a business metric to the traces, evaluations, and operational signals that explain what is driving cost, quality, and business outcomes.

A low-ROI trace can point to a request that should be routed differently, context that should be removed, or an agent configuration that should be optimized. The same telemetry used to improve quality and efficiency can now help organizations answer the question the business ultimately asks: is this agent worth what it costs?

Run AI as one managed investment system

Together, the four posts in this series describe one optimization system operating at three speeds. At runtime, model routing, deployment choices, and caching right-size each request. Over days and weeks, context engineering, memory, tools, and agent optimization improve the workflow. Continuously, governance attributes consumption, enforces limits, and measures whether the portfolio is creating value.

The same evidence connects every layer, and answers different questions:

Traces show what an agent did on a run, exposing expensive requests and inefficient context.

Evaluations show whether the output was good, protecting quality as configurations change.

Cost attribution shows where the money went, pointing to the project, agent, or model to intervene on.

ROI shows whether the work was worth it, telling leaders whether to optimize an agent, give it more capacity, or retire it.

Cost is only one part of a much bigger governance story, and it helps to be clear about who owns which part.

Foundry is built for developers creating agents. It’s where developers build, test, and optimize, and Foundry Control Plane gives them an operating view of everything they’ve shipped, from cost trends and anomalies to token usage and lifecycle controls, with Azure Policy, Microsoft Defender, and Microsoft Purview woven in so compliance and security aren’t an afterthought.

Microsoft Agent 365 is built for the people responsible for the entire enterprise estate. IT administrators and security teams use it to discover, inventory, secure, and manage every agent in the tenant, whether it came out of Foundry, Microsoft 365, or a partner platform, and to extend the same identity, access, and data protections to agents that they already apply to people.

The FinOps capabilities we’ve covered in this series live on the Foundry side of that line, giving developers and platform teams the levers to keep spend predictable, while IT and security govern the estate around them in Agent 365.

Agent optimization isn’t about driving the cost of every request to zero. It’s about running agents with the same discipline you’d apply to any other serious investment, and that is what Foundry is built for: helping developers build and manage agents that are efficient by design, contained as they scale, and accountable for the value they create.

Get started

If you’re governing agents today, start by making their consumption visible and attributable. Identify which agents and teams are driving usage, apply request-time limits to contain unexpected consumption, and pair those controls with financial budgets and alerts. Then connect cost to business outcomes so you can decide which agents to optimize, scale, or retire.

Enforce token limits for model deployments in Microsoft Foundry.

Plan, monitor, and allocate AI costs in Microsoft Foundry costs.

Create budgets and alerts in Cost Management.

Explore AI Gateway governance capabilities in Azure API Management.

Learn about observability and ROI for agents in Foundry.

Microsoft Foundry

The enterprise AI platform to build, ground, and govern AI apps and agents at scale.

Start managing agents

Did you miss these posts in The Economics of Agent Optimization series?

AI cost management: From AI pilots to measurable ROI

AI cost optimization: How to lower AI spend

AI agent optimization: How context engineering lowers AI costs

The post The Economics of Agent Optimization: How AI agent governance controls cost and proves ROI appeared first on Microsoft Azure Blog.
Quelle: Azure

Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Container Management

I am pleased to share that Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Container Management, positioned furthest to the right on Completeness of Vision. We believe this recognition reflects our ability to help customers modernize existing applications and embrace AI workloads without adding operational complexity.

Furthermore, this recognition comes at a moment when container platforms are being asked to support a far broader range of workloads, operating models, and deployment environments than many organizations ever anticipated.

Read the Gartner® Magic Quadrant™ Report

When we started working on Kubernetes over a decade ago, the problem was narrow: democratize distributed systems so that reliable services were easier to build. We were careful to describe workloads in terms of what they needed instead of where they should go, mostly because we wanted the scheduler to have room to make good decisions. That turned out to matter more than we expected, because it meant the system never had strong opinions about what the workloads actually were.

AI has reshaped the requirements for container management. While Kubernetes has proved well suited for AI workloads, the bigger shift is that applications and AI now need to run closer to data and users, and increasingly inside specific sovereign and regulatory boundaries. Organizations now need more than container orchestration; they need a platform that provides a consistent operating model across cloud, edge, and hybrid deployments while adapting to new requirements without needing applications to be rebuilt. This vision underpins Microsoft’s container portfolio, spanning Azure Kubernetes Service (AKS), Azure Container Apps, Azure Arc, and Azure Kubernetes Fleet Manager..

Run AI on the platform you already operate

Across customer deployments, we’ve seen it settle into two distinct architectural models. In the first, a platform team owns a persistent serving layer, GPU scheduling, model lifecycle, and the compliance boundary around the system. Once volume is high and predictable, organizations increasingly want AI infrastructure to behave like any other platform capability: application teams consume it, while platform teams retain control over how it is operated and governed. On AKS, open-source tooling such as the AI toolchain operator helps automate model deployment and GPU provisioning, while AKS holding CNCF AI Conformance certification gives customers confidence that the ecosystem around their applications remains compatible as it evolves.

In the second model, an application or agent invokes inference when needed, runs generated code, and releases capacity when the work finishes. This model places a premium on elasticity and isolation. Capacity needs to appear quickly, be removed when it’s no longer needed, and safely contain workloads whose behavior isn’t always predictable in advance. Azure Container Apps is designed around that operating model, with serverless GPUs for on-demand inference, and hardware-isolated sandboxes for agent hosting that preserve state between interactions.

Almost every enterprise we work with needs both, and I’d argue the interesting engineering problem is making the boundary between them easy to cross: the same image, the same identity and network controls, the same policy, whichever side a team lands on. Platform teams want the control the first model gives them for the models the business depends on. Application teams and agent frameworks want the second, and they often want it without learning Kubernetes.

Keep one operating model as the estate spreads out

Once inference follows the data, the estate stops being centralized. Clusters accumulate across regions, in datacenters, at sites, and in environments where connectivity is intermittent or prohibited outright, often because sovereignty rules require the workload and its data to stay inside a jurisdiction. The resulting failures are usually coordination failures rather than single-cluster failures: configuration drift between locations, upgrades landing unevenly, and policy being applied in one environment but not another. Hybrid strategies can often fail when teams treat coordination problems as isolated cluster issues instead of platform problems.

We know that AI needs to spread from cloud to edge. To address that, we’ve built AKS Everywhere to enable a consistent, Azure-built and secured Kubernetes platform from cloud to edge. Going even broader, with Azure Arc for Kubernetes we extend a common identity, policy, and observability model across CNCF-conformant Kubernetes environments, including clusters in other clouds. With many clusters comes cluster sprawl, and Azure Kubernetes Fleet Manager addresses the coordination problem that emerges as estates grow, helping organizations manage upgrades, workload placement, and policy consistently across fleets.

Holding all of that together depends on AKS staying close to upstream Kubernetes, and we’ve kept it there deliberately. There’s no proprietary fork, and open-source is at the core of our strategy. Microsoft is the second-largest contributor to CNCF projects overall and the largest among cloud providers for the past three years. That work is what keeps the API you build against stable no matter where the workload lands, and why the ecosystem around your cluster looks the same inside Azure and outside it.

Hold operations steady as the estate grows

Cluster counts often grow faster than operations teams do, and most organizations feel that pain before they have a plan for it.

Some of the answer is better defaults. AKS Automatic applies operational practices derived from Microsoft’s experience running Kubernetes at scale, while preserving the flexibility of the Kubernetes API.

The larger shift, however, is agentic operations. I expect this area to change more than any other over the next few years. Azure SRE Agent and the AKS MCP Server help operators move from alert to diagnosis to remediation using the same permissions and controls they already use today. The goal isn’t to replace operators; it’s to reduce the amount of routine investigation that still consumes too much operational time.

A platform built to absorb new requirements has more surface area than one built for a single scenario, and that demands more judgment from the people running it. Our job is to keep pulling that complexity into the platform, and the work is not finished.

Customer momentum

These examples highlight how customers are applying Azure’s container portfolio across AI, business-critical applications, and hybrid environments.

Wayve trains its autonomous driving models on petabytes of video and sensor data, using AKS to pull thousands of GPUs into what amounts to a single elastic training system.

AT&T built Ask AT&T with AKS as the orchestration core for its containerized agents, and every agent clears legal, security, and finance review before it reaches production.

Replit‘s agent takes a plain-language description, writes the application, and deploys it as a Container App inside the customer’s own Azure environment, where it picks up that customer’s network and compliance controls from the first deployment onward. Roughly three-quarters of their enterprise users don’t write code for a living.

SimCorp moved the investment management platform behind many of the world’s largest asset managers from virtual machines onto AKS, driven by the need for identity, logging, and security policy to apply identically for every client in every jurisdiction, and to be auditable when someone asks.

Emirates Global Aluminium runs about two-thirds of its estate in Azure and a third on-premises at its own sites, with image and video analytics running next to the plant floor and applications moving between the two without being re-engineered.

A training cluster spanning thousands of GPUs has very little in common with a regulated multi-tenant SaaS platform or with analytics running beside a smelter. What connects them is that each one eventually needed something its original architecture wasn’t built for.

Azure Kubernetes Service gives us the control and cost efficiency we need. We can scale GPU resources based on call volume and test new models without touching production.
Brian Sutliffe, Vice President of Engineering, CallRevu

Being named a Leader in this Magic Quadrant is an honor for us, and it solidifies clear expectations for our work ahead. At the end of the day, only the team running a workload can decide where it belongs, and the answer will vary across an estate. The platform’s role is to let that answer change without forcing the team to redesign the application or adopt a second operating model. I also want to personally thank all of Azure Cloud Native since this recognition reflects a lot of hard work by many people throughout Microsoft and Azure.

You can read a complimentary copy of the 2026 Gartner® Magic Quadrant™ for Container Management here.

Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Container Management

Read the report

Gartner ® Magic Quadrant™ for Container Management, Dennis Smith, Tony Iams, Wataru Katsurashima, Lucas Albuquerque, 2 September 2026

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

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request here.

The post Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Container Management appeared first on Microsoft Azure Blog.
Quelle: Azure