Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design
Hello Folks! Operating at Azure scale means managing change across multiple interconnected systems. As applications, services, and dependencies evolve, resilience becomes a foundational design principle rather than an afterthought. In this Microsoft Azure Infra Summit 2026 session, Bhavana Konchada, Principal Software Engineer at Microsoft and lead architect of the Resilience Control Platform, takes us behind the scenes of a production-grade resilience platform built on Azure and explains the engineering choices that helped bring it to life. Why IT Pros Should Care Most of us have shipped a system that worked beautifully on day one and then quietly fell apart the first time something downstream blinked. Bhavana’s session is a brutally honest tour of the decisions you make early that determine whether your platform survives reality. Here’s what you walk away with: A pragmatic blueprint for service boundaries that you can actually operate at 2 a.m. Concrete Durable Functions patterns (Monitor, continue-as-new, idempotency) that keep long-running workflows healthy. A Cosmos DB partitioning strategy grounded in real access patterns, not gut feel. A multi-region, fail-and-continue mindset (instead of fail-and-recover) that holds up when a region disappears. Real lessons from production, including the “non-deterministic orchestration” outages nobody warns you about. In short, if you build, run, or modernize platforms on Azure, this session reshapes how you think about reliability. What DR by Design Actually Means, a Technical Overview Bhavana frames the Resilience Control Platform as five chapters: architecture and service boundaries, orchestration with Durable Functions, the Cosmos DB data layer, identity across multiple user realms, and the resilience playbook itself. The platform has four moving parts: A portal where operators define and monitor scenarios. An orchestration engine that executes long-running workflows. Cosmos DB as a shared persistence layer. Downstream infrastructure APIs the engine acts on. The big “DR by Design” idea is that resiliency isn’t bolted on later. It’s a property of every choice from boundaries upward. As Bhavana puts it, you stop designing for “fail and recover” and start designing for “fail and continue.” Users don’t know (or care) which region runs their workflow; they just need it to run reliably, consistently, and without interruption. How It Works, Under the Hood Bhavana’s team made several deliberate design moves worth borrowing. Arm’s-length service boundaries. Version one had the portal and orchestration engine tightly coupled with shared dependency injection and a shared database context. It felt clean until they tried to operate it. Now the two services talk over REST contracts, each with its own dependencies. Yes, that means a bit of duplicated code. What they gained, independent deployments, isolated failures, and clear ownership, more than paid for it. The right runtime for the workload. The portal is a session-driven web app, so it lives on App Service. The orchestration engine bursts on demand and runs workflows for minutes (sometimes hours), so it’s built on Durable Functions. Forcing both into one model would have looked simpler on paper and been worse in practice. Accept Fast, Process Asynchronously. Clicking Execute returns a 202 immediately. The orchestrator does the heavy lifting in the background and updates status in Cosmos DB. The portal just reflects progress. Users never wait on long workflows. Durable Functions patterns that actually scale. Three lessons stood out: The Monitor pattern replaces busy polling with durable timers. The orchestrator wakes up, checks status, and goes back to sleep without holding compute. Orchestrators are state machines, not scripts. Calling DateTime.UtcNow inside an orchestrator produces non-deterministic replay and random production failures. The fix is to use the orchestration context for time and IDs. Continue-as-new keeps replay history bounded. Long-running orchestrations otherwise spend more time replaying history than doing real work. Cosmos DB designed around access, not org charts. Partitioning by tenant feels logical and creates hotspots the moment one tenant gets busy. The team partitions by entity (each plan owns its partition) and uses hierarchical keys combining plan ID and execution ID. They also lean on TTL for data lifecycle so completed records expire automatically, no cleanup jobs required. Identity as an execution boundary. Corporate users authenticate through Microsoft Entra with OpenID Connect. Operations users come in through a federated WS-Federation system. Instead of forking the app, the team built home realm discovery at the front door, normalized everything into a single identity model behind it, and added custom middleware in the Azure Functions isolated worker model to extract, validate, enrich, and fail-fast on every token. Authorization is config-driven so every endpoint gets the same treatment. Multi-region from day one. The full stack (portal, engine, APIs, supporting services) runs in parallel across regions, fronted by Azure Front Door as the global entry point. Health probes drive automatic regional failover with no human in the loop. Cosmos DB single-write with automatic failover. Multi-write looks attractive on a slide and introduces real conflict-resolution complexity. The team chose one primary write region plus a replica with automatic failover. The Cosmos SDK detects region unavailability and routes requests to the promoted region without application code changes. Idempotency from day zero. Once you have retries (and Front Door, the SDK, and your clients all retry), every operation has to be safe to run more than once. Client-provided IDs, Cosmos conflict detection (a 409 means “already succeeded”), and idempotent orchestration events make sure the same outcome lands no matter how many times a signal arrives. Real-World Value, Use Cases, ROI, Scenarios What does this buy you in practice? Scenario validation under stress without compromising production. The platform is built to proactively validate and govern system behavior at scale. Long-running workflows that survive everything. Host restarts, transient downstream errors, regional failovers, none of them lose work in flight. Predictable cost. Durable timers and continue-as-new mean you stop paying for compute that’s only waiting. Operability at scale. Independent services, clean contracts, and centralized identity all mean a smaller cognitive load when something breaks at 2 a.m. Honest tradeoffs. Single-write Cosmos loses theoretical write latency in the second region and gains predictable behavior, no conflict ambiguity, and far easier debugging during failovers. That’s usually the right trade. In short, the platform behaves the same on a quiet Tuesday and during a regional outage. That’s the whole point. Getting Started You don’t need to build the Resilience Control Platform tomorrow. You can start applying these patterns this week. Map your service boundaries honestly. If two services share a DI container or database context, decouple them behind a REST contract. Pick runtimes by workload, not by consistency. Interactive UI on App Service; long-running orchestrations on Durable Functions. Adopt the 202-Accepted pattern for anything that could take more than a couple of seconds. Audit your Durable orchestrators for DateTime.UtcNow, Guid.NewGuid, and direct HTTP calls. Move them into activities, use the orchestration context for time and IDs, and apply continue-as-new on long loops. Revisit your Cosmos partition keys against actual access patterns and enable TTL for transient data. Stand up a second region behind Azure Front Door, enable Cosmos DB automatic failover, and make every write operation idempotent with client-provided IDs. Resources Reliability design principles, Azure Well-Architected Framework Durable Orchestrations overview Azure Durable Functions documentation Azure Functions documentation Hierarchical partition keys in Azure Cosmos DB Azure Cosmos DB documentation Azure Front Door documentation Microsoft Entra ID documentation Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanContainer Network Insights Agent (CNIA): Your AI Teammate for AKS Networking Incidents
Hello Folks! If you run AKS in production, you already know the script. A pod cannot reach an external service, every dashboard says the cluster is healthy, and somebody is SSHing into a node with five browser tabs open trying to piece the story together. This session from the Microsoft Azure Infra Summit 2026 tackles that exact pain. Shaifali Garg (PM for Azure Container Networking on AKS) sits down with Jonathan Wang, an AKS operator running 30 clusters across two regions on Cilium, and they walk through what a real networking incident feels like, then introduce the Container Network Insights Agent (CNIA) live in the cluster. Why IT Pros Should Care In Jonathan’s environment, about 40% of incidents end up being networking problems. The tools all exist (kubectl, dashboards, detectors, Hubble), but the time sink is figuring out which layer the problem lives in and what to check next. CNIA goes after that gap. Here is what you actually get back: A symptom-to-classification jump in seconds, so you skip the first 30 minutes of “is this DNS, policy, node, or app?” One chat window with one evidence table, one root cause, and one copy-paste fix command, instead of jumping across five tabs Senior SRE tribal knowledge baked into the workflow, so anyone on the team can run the same investigation a principal engineer would Read-only by design, so the agent never changes anything on your cluster. You stay the human in the loop Installs as an AKS extension (no Helm chart, no YAML to babysit), and Azure handles the lifecycle In short, CNIA is not trying to replace your SRE team. It hands them back 20 or 30 minutes on every networking ticket, which adds up fast across a fleet. What CNIA Is, A Technical Overview Think of CNIA as an AI teammate that lives inside your AKS cluster as a pod. You describe what is broken in plain English, the way you would ping a senior engineer on Slack, and behind the scenes the agent does four things in order. It classifies the kind of problem (DNS, egress, policy, node, app), it pulls live evidence from your cluster, it analyzes that evidence, and it hands you back a clean report with evidence, root cause, and a copy-paste exec command. Two architectural choices stand out. First, the agent uses your own Azure OpenAI resource (bring your own), so prompts and diagnostic content stay in your tenant and your region. Microsoft does not see your diagnostic data, and nothing gets persisted externally. Second, the answer is grounded in evidence pulled from your cluster, not from the internet. Your pods, your policies, your CoreDNS, your host-level NIC and kernel counters. If the evidence is inconclusive, CNIA says so rather than fabricating a root cause. That last bit is what earns trust with senior SREs. CNIA fits inside the broader Advanced Container Networking Services (ACNS) story on AKS. ACNS gives you metrics in Azure Managed Prometheus and Grafana, stored and on-demand network logs with Hubble, and FQDN-based filtering with Cilium. CNIA sits on top, automating the triage loop across those signals so you do not have to walk through the playbook by hand every time. How It Works, Under the Hood The install is an AKS extension. Roughly 5 to 7 minutes from “az aks extension” to “you have an SRE buddy in your cluster.” One small pod runs continuously. A second helper only spins up on the node during a deep packet-drop investigation, reads host-level network counters, and is cleaned up right after. Nothing left behind. Permissions are deliberately narrow: Read-only RBAC on the cluster. The agent looks, it never changes anything A workload identity tied to your Azure OpenAI resource. No shared credentials Outbound traffic is HTTPS to your OpenAI endpoint on port 443, and nothing else. If you want to log that further through an NSG or firewall, that is supported On the safety side, CNIA layers two protections against prompt injection. The agent is scope-restricted by design, so off-topic requests get rejected straight away. In one of Jonathan’s demos, Shefali asks the agent to “delete core-dns” and to “write a script to scrape LinkedIn profiles.” Both are refused on the spot. The second layer is the read-only RBAC at the cluster level. Even if someone tricked the prompt into emitting a destructive command, the cluster itself would refuse. The pod’s execution is scoped to specific diagnostic commands. It is not an open shell. Honest tradeoffs, because you will ask: It is one cluster at a time. Multi-cluster correlation is not in scope yet It does not auto-remediate. It tells you the fix, you verify and run it It is AKS only. EKS and GKE are not supported today Session state lives in the pod in memory. If the pod restarts, you start a fresh chat (past sessions are still available in history) Heavy packet-drop investigations have been validated up to around 7 concurrent users on smaller clusters. The team is actively scaling that up Real-World Value The session includes two demos that map directly to incidents you have probably lived through. Demo 1, egress that silently dies. Pods cannot reach google.com. CoreDNS resolves it fine, example.com works from the same pod, every dashboard says healthy. CNIA classifies it as an egress connectivity problem (not DNS) and surfaces the actual culprit: a Cilium network policy named “restrict external FQDN” with a toFQDN rule that only allows example.com. Everything else gets silently dropped at the egress gate. DNS was allowed, the TCP connection was not. The fix command (a kubectl patch to add google.com to the allow list) is right there in the report. End-to-end fix in under a minute. Demo 2, the target port typo. A service is down with connection refused. Pods running, service exists, endpoints populated, no network policies. The agent goes inside the pod, looks at the actual listening sockets, and proves the mismatch: target port 8080, but nginx listens on port 80. One-digit typo in YAML that no kubectl get would surface on its own. The ROI math is straightforward. If your team handles networking incidents weekly and each one costs 20 to 30 minutes of “where do I even start,” that capacity adds up across the org. And critically, the win is not just speed. When the one engineer who knows where to look goes on leave, the rest of the team is no longer stuck calling them at home. Getting Started Three steps. That is it. Read the public docs, get an overview, scan the use cases, and understand what CNIA does and does not cover Pick a cluster (dev or staging is a great place to start) and install the AKS extension. Give it 5 to 7 minutes Run a few real network tickets through it. Compare your time-to-answer before and after. Hit thumbs-up or thumbs-down in the chat so the product team sees real signal Pricing in preview: no license fee. You pay for the Azure OpenAI tokens it uses (your tenant, your resource), plus the tiny bit of cluster compute for the pod. If you already have Azure OpenAI in your tenant, just point CNIA at it. Resources Diagnose and resolve AKS network issues with Advanced Container Networking Services Advanced Container Networking Services overview Configure Azure CNI Powered by Cilium in AKS AKS cluster extensions Deploy and configure Microsoft Entra Workload ID on an AKS cluster What is Azure OpenAI Service? Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki Cheers! Pierre RomanOperating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads
Hello Folks! If you have ever inherited a sprawling Azure environment and quietly wondered whether every VM, database, AKS cluster, and storage account in it is actually being backed up the way the business thinks it is, you are in good company. In session this session of the Microsoft Azure Infra Summit 2026, Bhavya Tadikonda and Shobhit Garg from the Azure Resiliency product team walked us through how Azure Backup is evolving into a unified, application-centric service that protects IaaS, PaaS, AKS, PostgreSQL, and unstructured storage from a single pane of glass. Why IT Pros Should Care Backup is one of those topics nobody talks about until the day it really matters. Then it is the only topic. The session framed Azure Resiliency around three pillars (infrastructure resiliency, data resiliency, and cyber recovery), and Azure Backup sits squarely in the middle of the last two. The reason this session lands hard for ops teams is that the surface area we are expected to protect keeps growing: VMs, SQL on Azure VMs, SAP HANA, Sybase, AKS, PostgreSQL flexible servers, Azure Files, blobs, ADLS, and on it goes. Here is why this should matter to you: One vault model now protects IaaS, PaaS, AKS, PostgreSQL flexible server, and storage workloads, with consistent policies and reporting. Cyber resiliency is built into the vault layer with immutability, soft delete, and multi-user authorization, so backups themselves can survive a ransomware event. A new threat detection preview (powered by Microsoft Defender for Cloud) scans restore points and tags them healthy or suspicious before you recover. Azure Backup for AKS protects cluster resources and persistent volumes with granular restores and immutable recovery points. You can configure backups from VS Code through the Azure MCP server using natural language prompts, which is genuinely useful when you are protecting dozens of resources. In short, fewer point tools, fewer scripts, and a much better chance of actually meeting your RPO and RTO targets when the day comes. What Operating Azure Backup at Scale Means, a Technical Overview The session opened with a quick reminder that resiliency in Azure stands on three pillars working together. Infrastructure resiliency keeps the underlying VMs, zones, and networks alive. Data resiliency keeps your data intact, available, and recoverable. Cyber recovery assumes the worst (a ransomware attack or insider event) and gives you air-gapped, immutable backups plus isolated recovery to restore safely. Azure Backup is the connective tissue across data resiliency and cyber recovery. At the data layer, it offers snapshot tier backups for instant operational recovery (with up to a four-hour RPO), vault tier backups for long-term retention, and an archive tier for cold compliance storage. For databases, you get database-aware protection for SQL Server in Azure VMs, SAP HANA, and SAP ASE (Sybase), with point-in-time restore and log backups as frequent as every 15 minutes. That gets you to an RPO as low as 15 minutes for SQL, which is a number most IT pros will recognise as good enough for the vast majority of business apps. At the vault layer, three security primitives stack together: soft delete (deleted backups are kept for an additional retention window), immutability (no operation can shorten retention or destroy recovery points before expiry), and multi-user authorization (critical operations need approval from a second admin via a Resource Guard). These are not bolt-ons. They are baked into Recovery Services vaults and Backup vaults. How It Works, Under the Hood The session followed a Contoso scenario where John, a cloud architect, configures backup for an application VM and a database VM. He picks a Recovery Services vault, creates a backup policy, and defines frequency and retention based on his RTO and RPO requirements. For the Linux application tier, John enables the new agentless, crash-consistent backup, which is non-invasive and protects performance-sensitive workloads without an in-guest agent. For the database tier, John enables Azure Backup for SQL in Azure VMs. The service auto-discovers all databases inside the VM, removes the manual config dance, and lets him layer log backups, differential backups, and archival retention. For SQL Always On, HANA HSR, and Sybase HA clusters, snapshot-based acceleration gives him faster backups and instant restores. Then John turns to cyber resiliency. From vault properties he reviews soft delete, immutability, and multi-user authorization, then enables the new threat detection preview. This integration with Microsoft Defender for Cloud scans restore points for malware so you can confirm a recovery point is clean before you roll back. Inside the protected items view, each restore point is marked healthy or suspicious, which is exactly the signal you want during an incident response. For PaaS and cloud-native, Shobhit took over and walked through Azure Backup for AKS and Azure Backup for PostgreSQL flexible server. AKS protection covers the cluster resources, the persistent volumes, and the namespaces, with automated scheduled backups, granular restores, immutable recovery points, and flexible retention. PostgreSQL flexible server gets vaulted backups with long-term retention plus a unified view for monitoring and alerts. The piece that made the room sit up was the demo of configuring backup from VS Code using the Azure MCP server. John installs the Azure MCP extension, validates mcp.json, opens the chat window, and starts the MCP server. He prompts it to list unprotected AKS clusters in his subscription, then asks it to configure backup for a specific cluster. The MCP server reuses an existing vault and policy, creates the protected item, and applies the enterprise security defaults. That is the kind of conversational ops experience that scales nicely when you have hundreds of resources. For unstructured data, Azure Backup brings file shares, ADLS data, application artifacts, and large object stores into the same vault-based model, with off-site protection, long-term retention, immutability, soft delete, and MUA applied consistently. Real-World Value So where does the ROI show up? A few honest scenarios: Ransomware attack on production VMs. With immutability and MUA, even a compromised admin account cannot destroy your recovery points. With threat detection, you avoid restoring an infected snapshot. Accidental deletion of an AKS namespace. Granular AKS backup gets you a controlled, application-aware restore without redeploying the whole cluster. Compliance audit on a regulated workload. Vault tier plus archive tier gives you the retention you need without inflating hot storage costs. A cloud architect onboarding 30 new VMs and 10 PostgreSQL servers. Using Azure MCP from VS Code, they can configure backup conversationally instead of click-clicking through portal blades. A BCDR drill. The resiliency agent (powered by Azure Copilot) can recommend enabling Azure Site Recovery on top of Azure Backup for stricter RTO and RPO, then guide you through enabling it. Honest tradeoff: threat detection is in preview, agentless crash-consistent backup is newer than the in-guest variant, and multi-user authorization requires a Resource Guard that lives in a separate subscription (ideally a separate tenant). That is extra setup work, but it is the right design for separation of duties. Getting Started Concrete first steps you can take this week: Open Backup Center (or the new Resiliency in Azure experience) and inventory what is already protected versus exposed. Pick one Recovery Services vault and turn on enhanced soft delete with a meaningful retention period, then make it AlwaysOn for production. Stand up a Resource Guard in a separate subscription or tenant and wire up MUA on your most critical vault. For a non-production AKS cluster, install the Backup extension and protect a namespace end to end, including a test restore. Try the Azure MCP server from VS Code to list unprotected resources and configure backup with a prompt. If you run SQL on Azure VMs, enable log backups every 15 minutes on one database and validate a point-in-time restore. Resources Azure Backup documentation (official docs for vaults, policies, and workload protection) Configure Multi-user authorization using Resource Guard (separation of duties for critical backup operations) Threat detection in Azure Backup with Microsoft Defender for Cloud (preview) (healthy or suspicious tagging for VM restore points) Back up Azure Kubernetes Service by using Azure Backup (cluster resources, namespaces, and persistent volumes) Azure Backup for PostgreSQL flexible server (vaulted backups with long-term retention) Azure Site Recovery documentation (DR replication on top of Azure Backup) Keep Learning... Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! PierreZonal Resiliency in Azure: Application-Centric Goals, Recovery Plans, and Drills
Hello Folks If you have ever stared at a multi-tier app in Azure and asked yourself, “Is this actually going to survive a zone outage?”, you are not alone. In session MAIS23 of the Microsoft Azure Infra Summit 2026, Bhavya, Aditya, and Chaya from the Azure Resiliency product team walked us through the new Resiliency in Azure experiences (formerly Azure Business Continuity Center) and showed how to stop treating resiliency as a per-resource checkbox and start treating it as an application-level outcome. Why IT Pros Should Care Most of us have lived this story. An app is “in the cloud”, spread across IaaS VMs, PaaS databases, an app service plan, and a shared Azure Firewall managed by some other team. Then a zonal blip hits, and suddenly nobody can answer the simple question: was this app supposed to be zone resilient or not? The session opened with a customer scenario called Zava, a fast-growing insurance company running a claims app at 99.9 percent availability that just lost more than $40,000 in revenue in one week because of zonal outages. That is the price tag the speakers put on the problem, and it lines up with the patterns I see every week. Here is why this matters to IT pros: You finally get a single pane to see zonal resiliency posture across IaaS, PaaS, and shared services. Resiliency goals are set at the application level, not buried inside each resource blade. You get tailored Azure Advisor recommendations plus an Azure Copilot guided flow that emits remediation scripts. You can run zone-down drills powered by Azure Chaos Studio without stitching together five different tools. Recovery plans orchestrate failover in a defined order, with on-demand readiness checks before the next real outage. In short, less guessing, less spreadsheet bookkeeping, and a lot more confidence that the app will behave the way you told the business it would. What Resiliency in Azure Does, a Technical Overview The team has rebranded Azure Business Continuity Center to Resiliency in Azure. It is a unified solution that covers infra, data, and cyber resiliency in one place. Today the focus is zonal resiliency, with regional disaster recovery (and proper RPO/RTO goals) on the roadmap. The central concept is the service group. A service group is a logical application unit that can span subscriptions and resource groups. You add the VMs, databases, app service plans, Redis caches, and other Azure resources that make up an application, and from that point on, resiliency operations work against the whole app, not one resource at a time. There are two views you will spend most of your time in: Resource resiliency, a zonal configuration summary across the (roughly 20) resource types supported today. Service group resiliency, the same summary but pivoted to the application level, so you can prioritize the apps that need attention first. The speakers were honest about scope. Goals today are a simple intent (“this service group should be evaluated for zonal resilience”). Once additional pillars like regional DR ship, goals will expand to include RPO and RTO targets. I appreciate that they did not oversell it. How It Works, Under the Hood Once a service group exists, the workflow has three big building blocks. Each one solves a problem I bet you have hit. Goals and recommendations. You assign a zonal resiliency goal to the service group, and Azure Advisor surfaces tailored recommendations for the resources inside it. Two details I liked: The view shows cost implications before you flip the switch. Some Azure services have no cost delta for zone redundancy. Others do. You see it inline, not in a separate calculator tab. There is an Azure Copilot guided remediation flow that walks you through the recommendation and, at the end, emits a script. That script accounts for resource-type corner cases (SKU changes, redeploys, and so on) and is meant to be run through your automation pipeline. You can also exclude a resource with a reason (“not critical, zonal redundancy not required”) or manually attest a resource when your own custom solution already provides resiliency that the platform cannot auto-detect. That escape hatch is important, because real environments always have a few weird cases. Application-centric recovery plans. Instead of failing over one resource at a time, a recovery plan orchestrates the entire app. It auto-detects existing solutions (Azure Site Recovery for VMs, for example), lets you group and order the resources for failover, and excludes resources that are already configured for high availability (no point failing them over if they did not go down). You can run an on-demand readiness check any time the app structure changes, so you find configuration drift before an outage finds it for you. Zone-down drills powered by Azure Chaos Studio. A zone-down drill template identifies the service group resources, pre-populates the right native faults per resource type (think a Redis cache fault, a VM scale set shutdown, and so on), bundles in identity and permission checks, monitoring, and the recovery plan you already built. When you execute, you pick the region and the target zone, the drill runs a pre-validation check, injects the fault, runs failover, then reprotection and failback, and tracks all of it as a single job in the execution report. Per-resource metrics let you visualize the actual downtime each component experienced. If a native fault is not what you want, you can override with a custom runbook. That last point is the part I think a lot of folks miss. A drill is not just fault injection. It is fault injection plus failover plus reprotection plus failback, all measured and attestable in one place. Real-World Value Back to Zava. They needed to answer three questions: what is our current zonal resiliency posture across these Azure services, what should we prioritize against our 99.9 percent target, and how do we validate that we will actually perform during an outage? Resiliency in Azure answers all three without forcing the platform team to write a 200-line PowerShell script. Use cases that should be on your shortlist: Regulated workloads (insurance, healthcare, financial services) that need to evidence drills for compliance. The notes and manual attestation features were clearly designed with auditors in mind. Apps with mixed estates, where a central platform team owns shared services (firewalls, identity) and app teams own everything else. Service groups can be parented to mirror that org structure. Apps with custom resiliency solutions that the platform cannot detect. Manual attestation keeps the dashboard honest without forcing you to refactor. Game-day rehearsals. The pre-built zone-down template means you can run a meaningful drill in an afternoon instead of standing up a custom Chaos Studio experiment from scratch. The honest tradeoff: zone redundancy is not free for every service, and not every resource type is in scope yet (around 20 today). Plan accordingly, exclude what is not critical, and attest what is covered by something else. Getting Started Here is the path I would take on a Monday morning: Open the Azure portal and search for Resiliency. You will land on the Resiliency in Azure page that replaces the old Business Continuity Center. Create a service group. Add resources directly, or add resource groups if each resource group is already an application boundary in your environment. Assign the zonal resiliency goal to the service group. Review the summary tiles. Exclude or manually attest the resources that need it. Walk the Advisor recommendations. Use the Copilot guided flow to generate a remediation script and run it through your automation. Build an application-centric recovery plan, group and order the resources, run an on-demand readiness check. Create a zone-down drill from the template, validate identity, monitoring, and faults, then execute the drill in a non-production zone first. Resources Resiliency in Azure documentation Zonal resources and zone resiliency Azure service groups overview Azure Advisor reliability recommendations Azure Chaos Studio documentation Azure Site Recovery overview Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki Cheers! Pierre RomanAgentic Migrations and Modernization: How the Azure Migrate Agent Keeps Your Intent Alive End to End
Hello Folks! If you have ever tried to move a few hundred VMs, a pile of databases, and a couple of web apps from on-prem to Azure, you already know the hard part is not the tooling. The hard part is keeping context, intent, and momentum alive across weeks of planning, hand-offs, and decisions. In session MAIS15 at the Microsoft Azure Infra Summit 2026, Ankur Gupta (Senior Product Manager on the Azure Migrate team) walked us through the new Azure Migrate agent, an AI layer that sits on top of Azure Migrate and carries your intent from “I have an idea” all the way to “the landing zone is deployed.” Why IT Pros Should Care Ankur opened with a line that stuck with me. Infrastructure complexity has far outpaced human scale. We have MySQL here, PostgreSQL there, web apps, storage devices, networking gear, multiple dashboards, multiple alerts, and we are all expected to move faster than ever, with fewer mistakes. In short, migrations rarely fail because someone picked the wrong tool. They fail because the system between the stages breaks. Here is why the agentic approach matters for the folks in the trenches: It keeps context across the entire lifecycle, so the intent you set on day one is still the intent at execution. It guides you when you are stuck, instead of leaving you to figure out which of three discovery methods is the right one. It compresses tasks that used to take days of analysis (think side-by-side business cases) into a few hours. It connects IT ops, architects, and developers through a single thread of information, including a clean handoff to GitHub Copilot for code work. It builds on the Azure Migrate portal you already know, so nothing you have learned goes to waste. That last point is important. The portal does not go away. The agent is a layer on top. You can still do everything you do today. What the Azure Migrate Agent Is, technical overview Azure Migrate has always been Microsoft’s hub for discover, assess, and migrate. What Ankur showed at MAIS15 is the next evolution. Azure Migrate is becoming a migration control plane that spans the whole lifecycle (Decide, Plan, Execute), and the Azure Migrate agent is the conversational, guidance-oriented layer that ties it all together. In Ankur’s words, the agent is educational and guidance-oriented. You ask one natural-language question, like “how should I plan moving my VMware workloads to Azure,” and you get the next steps you actually need to take. Behind the scenes, the agent is doing three things very well. It maintains state across the entire lifecycle. Preferences you set early stay with you. It carries context across discovery, plan, and execute. You can jump around, repeat steps, change your mind, and the agent remembers what your goal was. It recommends the right next move based on what it has learned about your intent. This is the heart of the “agentic” part. The agent is not a chatbot grafted onto a portal. It is a stateful workflow runner that remembers you. How It Works, under the hood The session walked through a full VMware-to-Azure scenario, and the flow is worth seeing because it shows how the pieces snap together. The agent supports three discovery methods today: appliance-based discovery, RV Tools, and the new Azure Migrate collector. The collector is the new lightweight option. It ships as a set of PowerShell scripts you run on a machine that can reach your vCenter, it produces a zip file, and you upload that zip to your Azure Migrate project. No appliance to deploy, no inbound network plumbing. Once the inventory lands, the agent reads it. Ankur asked for a summary and got a card showing 207 VMs, 177 SQL databases, one PostgreSQL instance, and some web apps. He then asked for all servers with an out-of-support OS, got a list of around 50, and tagged them right inside the conversation so he could refer back to them later. Next came the business case. Ankur asked the agent to generate one based on a modernize preference. A few minutes later, he had Azure cost, on-prem cost, and projected savings. Then he asked for a second business case for lift and shift, and a side-by-side comparison. The agent ran it, showed that the on-prem cost in the lift-and-shift comparison was higher and that lift-and-shift TCO savings were actually higher in that specific scenario, and gave him the data points he needed to bring the decision to leadership. From there, Ankur moved to application assessment, this time back in the portal. He created an assessment for two apps (Airsonic and Parts Unlimited), let the high-confidence plan run, and got a modernize recommendation with 100% readiness and a target cost of about $580 per month, plus an emissions estimate of 32 kgs of CO2. App Service for the web tier, Azure Database for PostgreSQL for the data tier. Both were flagged “ready with conditions,” with clickable links into why. Then came one of my favorite parts. Ankur connected GitHub for a Copilot Assessment, which adds code-level insights on top of the infrastructure readiness assessment. The system recalculated, and the migration effort estimate sharpened up. Finally, the agent built a wave plan from the assessment, then generated a platform landing zone aligned with Azure best practices. He could ask the agent about chosen defaults, request changes to the deployment mechanism, swap in a third-party firewall, or apply naming conventions. The agent produced a downloadable Infrastructure-as-Code template and handed it to a cloud architect, who refined it in their IDE using GitHub Copilot. That last handoff is the bridge between Azure Migrate’s planning world and the developer world. Real-World Value (use cases, ROI, scenarios) So where does this actually pay off? A few scenarios stood out. Pitching the business case to leadership. Ankur framed the demo around “I need to pitch a migration proposal to the planning committee.” Generating modernize, lift-and-shift, and Azure VMware Solution business cases used to be days of spreadsheet work. With the agent, it is hours. Cleaning up legacy debt. Tagging out-of-support servers in one conversational step lets you plan upgrades without exporting CSVs and slicing them by hand. Mixed estates with web apps and databases. The agent surfaces App Service and Azure Database for PostgreSQL targets, gives SKU recommendations, and flags the warnings worth investigating. Closing the IT-to-developer gap. The GitHub Copilot Assessment and the IaC handoff to the IDE means developers and architects work from the same context. Reducing intent drift on long migrations. Multi-week journeys lose their original intent. The agent remembers. In short, the ROI here is measured in calendar time, not just dollars. And honestly, in fewer late-night calls when something goes sideways because nobody remembered the original decision. Tradeoffs worth flagging: the agentic capabilities are landing in preview, and outputs are advisory. You still need human review, testing, and governance on every recommendation. That is by design. Getting Started (concrete first steps) Here is a practical onramp. Stand up an Azure Migrate project in the Azure portal if you do not already have one. Pick a discovery method that fits your environment. If you cannot deploy an appliance, try the new collector. Download the PowerShell scripts, run them from a host that can reach vCenter, and upload the zip. Bring in the Azure Migrate agent from inside the portal and ask it to summarize your discovered inventory. Generate at least two business cases (modernize and lift-and-shift). Compare them. Run an application assessment on a small, representative set of apps. Connect GitHub and add a Copilot Assessment for code-level insight. Ask the agent to build a wave plan and a platform landing zone template, then push the IaC to your repo for the architects. Start small, build the muscle, and scale out. Resources Azure Migrate documentation (Microsoft Learn) About Azure Migrate, including the Azure Copilot migration agent (Microsoft Learn) GitHub Copilot modernization overview (Microsoft Learn) GitHub Copilot modernization agent overview (Microsoft Learn) GitHub Copilot modernization documentation (Microsoft Learn) Assess and migrate a .NET project with GitHub Copilot modernization (Microsoft Learn) GitHub Copilot modernization overview for .NET (Microsoft Learn) Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Microsoft Azure Infra Summit 2026 Cheers! Pierre RomanFrom Alert to Resolved: Building a Self-Healing Azure Platform with SRE Agent
Hello Folks! It’s 3 a.m. Your phone lights up. A critical workload that spans multiple clouds is on fire, ownership is fuzzy, the alert routed to the wrong team first, and now it’s your problem. You sit up in bed, cold and groggy, and start the ritual. Open the runbook. Pull logs from one place. Pull metrics from another. Stare at three dashboards. None of them tell the whole story. So you build a theory. The theory is wrong. The clock keeps ticking. The customer impact keeps climbing. Every wrong turn costs you time, context, and confidence. That is the scene Lee Oommen opened with at MAIS14, and it is the reason Azure SRE Agent exists. In this session, Lee walks through the four classic SRE pain points and shows how an agentic operations platform compresses MTTR from hours to minutes. I am going to unpack what he showed, why it matters for IT pros, and how to get your hands on it. Why IT Pros Should Care If you carry a pager, write runbooks, or get pulled into post-mortems, this one is for you. The clock is the enemy, not the incident. Lee said it plainly: there is almost always an expert who can fix the problem. The real damage comes from the minutes spent finding that expert and reconstructing context. Dashboards lie in both directions. False positives create alert fatigue. False negatives let the customer call you before your monitors do. Neither outcome is acceptable. RCAs take weeks because the answer never lives in one layer. Infrastructure, network, deployments, dependencies, databases, app code. You need someone, or something, that can correlate across all of them in one pass. You did not become an SRE to be a dashboard watcher. Toil is the work that holds back the people who should be designing reliability into the next generation of services. What is the SRE Agent Let’s start with what it is not. It is not a dashboard. It is not a monitoring tool. It is not a chatbot. Azure SRE Agent is an end-to-end agentic operations platform. Think of it as a senior SRE who sits inside your team, works 24 by 7, never gets tired, never misses a signal, and is fluent in your stack. Reasons over telemetry, not just text. It pulls metrics, logs, traces, deployment history, and activity logs, then correlates across them. Takes governed actions. Every action runs inside the permission boundary you define. You decide whether the agent proposes a fix, asks for approval, or acts autonomously. Authors RCAs in minutes, not weeks. It traces the root cause in a single flow across the entire stack and produces the report immediately after remediation. Remembers. It captures organizational memory from every incident, every chat, and every scheduled task, then applies it to the next investigation. Lee called it the operations half of DevOps, and that framing stuck with me. We have automated build and deploy. The operations side has been stuck in toil. SRE Agent closes that loop. From Alert to Resolved (the workflow) Lee demonstrated the full loop live. Here is what it looks like end to end. Detect. The agent integrates with Azure Monitor, PagerDuty, or ServiceNow. When an alert fires, the agent acknowledges it within seconds. The human does not have to wake up cold. Investigate. The agent runs diagnostics in parallel across the connected resources. It queries Log Analytics, App Insights, Azure Monitor metrics, and any third-party observability tools you wired in through MCP connectors. Correlate. It uses distributed tracing, cross-workspace KQL queries, and time-based signal alignment to connect dots across services that do not even share trace IDs. It also checks past incidents in memory to see if this looks familiar. Diagnose. It produces a root cause analysis with the relevant evidence linked inline. No more reconstruction exercise across multiple teams. Propose or Act. Based on your run mode and the permissions granted, the agent either proposes a fix and waits for approval, or executes the remediation autonomously. Lee demonstrated both. He set up a bad slot swap on Azure App Service, generated HTTP 500 errors, watched the agent acknowledge the alert, investigate, identify the bad slot, ask for permission, and then perform the slot swap to restore the service. Close the loop. The agent files a GitHub or Azure DevOps issue with full context, opens a pull request with proposed code changes when appropriate, and writes a session insights summary you can review. Three modes to interact with it: Interactive. Chat with the agent like a copilot. Most customers start here to build trust. Reactive. Event-driven. The agent reacts to incidents from Azure Monitor, PagerDuty, or ServiceNow. One agent per incident platform. Proactive. Scheduled tasks that run every five minutes, every hour, daily, or weekly. Certificate health audits, well-architected framework assessments, cost optimization sweeps, compliance checks. Lee showed a scheduled task that flagged a certificate expiring in 50 days before it could ever fire an alert. Real-World Value This is where the conversation gets practical. A few things from Lee’s demo and the live Q&A that I want to call out. Multi-cloud reality. SRE Agent lives in Azure but is not limited to Azure. Custom runbooks, Python execution, MCP servers, and connectors let it orchestrate across AWS, GCP, and on-premises. Treat it as the central SRE brain. Your data stays yours. Each agent gets a dedicated data store in your subscription and resource group. Memory, knowledge, threads, and session insights live in your chosen region. Nothing is used to train the model provider. Encryption at rest, TLS 1.2 in transit, Azure RBAC, managed identity, customer-managed keys all apply. Identity boundary you already know. The agent uses standard Azure managed identity. Grant the identity RBAC on any cross-subscription resource it needs to reach. Least privilege still applies. Region availability. At session time, agents can be deployed in EastUS2, Sweden Central, and Australia East. The list is updating roughly monthly. Canada is coming. An agent in one region can act on resources globally, but if you have data residency rules, deploy the agent inside the same jurisdiction. Private endpoints today. If your Log Analytics Workspace or databases are fully locked down behind private endpoints with public access disabled, the agent currently needs a VNet-integrated Azure Function as a proxy. Microsoft is actively working on injecting agents directly into private networks. Memory is the multiplier. A principal engineer is more valuable than a junior engineer because of pattern recognition. SRE Agent captures that pattern recognition for the whole team, every time it investigates. Getting Started The pattern is simple, and Lee summarized it cleanly: you teach the tool, you make the connections, and it works for you. Provision the agent. Go to sre.azure.com or the Azure portal, pick a subscription and resource group, pick a region, and stand it up. Takes a few minutes. Onboard it like a new engineer. Tell it about your team, your workloads, and your procedures. Upload runbooks, troubleshooting guides, wikis, and architecture docs to the knowledge base. If you do not have these documents, ask the agent to draft them for you. Connect your observability stack. Azure Monitor, Log Analytics, App Insights are wired in by default. Add third-party tools through MCP connectors. Wire in your incident platform. Azure Monitor, PagerDuty, or ServiceNow. One agent per platform. Grant code access. Connect your GitHub or Azure DevOps repositories so the agent can reason over application code, propose fixes, and open pull requests. Pick your run mode. Start in interactive mode while you build trust. Move to approval-gated reactive mode. Graduate to autonomous mode on safe operations once you have the audit trail you trust. Resources Azure SRE Agent documentation on Microsoft Learn Azure SRE Agent product docs Get Started guide Automate incident response Official Microsoft SRE Agent GitHub repository (issues, labs, resources) Watch the Rest of the Summit If you found this useful, the rest of the Azure Infra Summit 2026 is packed with sessions on identity, AKS, deployment, storage, networking, and resiliency. Grab the full playlist here and binge what is relevant to your stack:Microsoft Azure Infra Summit 2026 Big thanks to Lee Oommen for walking us through this. The 3 a.m. pager scenario is something every one of us has lived, and seeing an agent take the first hour of that incident off your plate is a tangible win. Cheers! Pierre RomanDesigning Azure Networks That Scale: From Small Deployments to Enterprise-Grade
Hello Folks! If you have ever spent a long afternoon untangling overlapping CIDR ranges, chasing down a broken VNet peering, or trying to remember which UDR points to which firewall, this MAIS 2026 session is going to feel uncomfortably familiar. Jon Ormond (Principal PM, Azure Networking) brought along Jay Li and Jeff Lovett from the Azure Networking team to walk through what actually happens when an Azure network grows from a handful of VNets into a real enterprise estate, and where most teams hit the wall. The headline they kept coming back to is simple. Azure networks do not usually fail because they were built wrong on day one. They fail because they did not evolve fast enough. Scale is not a smooth ramp. It is a step function, and every step adds an order of magnitude of complexity. Why IT Pros Should Care You may be running three VNets today. That is fine. But the day a second team shows up, or you cross into a second region, or somebody asks for hybrid connectivity to the datacenter, your operating model changes whether you planned for it or not. The session is built around two pivots every growing Azure environment hits: Management and control inside Azure (VNets, peerings, routes, security rules). Connectivity and hybrid (VPN, ExpressRoute, Virtual WAN, reliability). Both of those break quietly. By the time you notice, you are already firefighting drift, broken peerings, or unpredictable latency from on-prem. Bottom line, here is what you take away: Design for the next stage, not the one you are in. Put the management layer in before complexity outpaces manual effort. Treat reliability as a design choice, not an afterthought. Start Small, Plan to Grow One VNet, one subnet, one workload. Nothing wrong with that. You can manage it with the portal, a spreadsheet for CIDR tracking, and a calm heart. The problem is that the jump from “one VNet” to “a few VNets across teams” is not gradual. As soon as you have a second team that needs isolation, you are into hub and spoke territory. Ten spokes feels manageable. Fifty spokes across multiple subscriptions does not. And by the time you hit a hundred, the spreadsheet is a liability. Jay made the case that the smartest move at small scale is not to stay manual until it hurts. It is to put Azure Virtual Network Manager (AVNM) in early, even if you only have three VNets. AVNM lets you declare intent once and let the platform handle the rest: IP address management (IPAM) so new spokes get non-overlapping CIDRs automatically. Network groups with tag-based dynamic membership so VNets land in the right group the moment they exist. Connectivity (hub and spoke or mesh) without hand-built peerings. Security admin rules pushed centrally across the estate. Routing intent so traffic flows through the right firewall by default. The honest tradeoff: AVNM is one more thing to learn and operate, and it adds cost. The counter-question Jay kept asking is, “What is the cost of drift?” One overlapping CIDR or one missing UDR at 100 VNets can cascade into an outage that takes days to unwind. That is the real tradeoff. Mid-Stage Patterns: Hub and Spoke, Peering, and the First Cracks The hub and spoke topology is the workhorse of Azure networking and the pattern the Cloud Adoption Framework recommends for most enterprises. It centralises shared services (firewall, DNS, ExpressRoute and VPN gateways, Private DNS zones) in a hub VNet, and connects spoke VNets through peerings. Where teams get into trouble at this stage: Peering sprawl. Every new spoke needs a peering, sometimes two if you want transitive paths. Doing this by hand across subscriptions is where human error lives. Route table drift. UDRs copied from spoke to spoke get out of sync. One spoke routes through the firewall, another bypasses it. Now you have a compliance problem. Security rule drift. NSGs and security policies start as a copy paste exercise and end as a forensic exercise. CIDR collisions. “Just give me a /24” turns into a multi day investigation when the new spoke overlaps with on-prem. Jay’s point on this was sharp. The mistake is not the topology. Hub and spoke is the right pattern. The mistake is staying manual on top of it. AVNM network groups let you say, “any VNet tagged environment=production joins the production group, gets the production security baseline, peers to the production hub, and inherits the routing intent that sends east-west traffic through the firewall.” No tickets, no copy paste, no drift. If you are already deployed via Azure Landing Zones (ALZ) with Bicep or Terraform, AVNM is not a replacement, it is another construct in your template. As Jon put it in the chat, it is “just another object” in your ALZ, and the two layers work together rather than competing. Enterprise Scale: Virtual WAN, Segmentation, and Governance At some point hub and spoke stops scaling cleanly. You start adding regions. Branch offices show up. You need SD-WAN integration, more than 30 IPsec tunnels, or transitive routing between VPN and ExpressRoute. That is when Microsoft pushes you toward Azure Virtual WAN. Virtual WAN is a Microsoft managed global transit network. You deploy regional virtual hubs and connect everything (Azure VNets, branches, remote users, ExpressRoute circuits) into them with consistent routing and security. The trade up is real: Any to any connectivity by default. Hub to hub mesh is built in. Routing intent and policies for centralised internet egress and east-west inspection through Azure Firewall or a partner NVA in a secured hub. Branch scale. Tens or hundreds of sites stop being a custom integration project. Operational simplification. Microsoft owns the hub control plane so you stop babysitting peerings. For hybrid connectivity itself, Jeff walked the curve every customer travels: VPN Gateway is the on-ramp. Cheap, fast to stand up, good enough until public internet latency, throughput, or regulatory requirements force a change. ExpressRoute circuits give you dedicated bandwidth from 50 Mbps to 100+ Gbps, with predictable performance and over 200 service providers worldwide. Scalable ExpressRoute virtual network gateways grow and shrink with usage, so you deploy once and stop re-architecting every time traffic changes. ExpressRoute Metro is the headliner. Same price as a standard circuit, but the redundant device lives in a second, physically distinct co-location facility across town. Building fire, flood, or power outage in one site, and your traffic keeps flowing. Multiple circuits are still on the table when “this cannot fail” actually means it cannot fail. Honest tradeoff on Virtual WAN: it is opinionated, Microsoft managed, and you give up some of the granular control you have in a customer managed hub. For most enterprises that is a win. For the few with very specific routing requirements or heavy NVA investments, traditional hub and spoke with Azure Route Server can still be the right call. The CAF guidance lays this out in detail. Getting Started If you take one thing from this session, take this. Design for the next stage. Three concrete moves: Stand up AVNM now, even at small scale. Declare your intent for IPAM, connectivity, security, and routing once. Let new VNets inherit it. Pick your topology with eyes open. Hub and spoke for customer managed control, Virtual WAN for Microsoft managed global transit at scale. The CAF decision tree is the right starting point. Plan hybrid for failure, not for the sunny day. ExpressRoute with Metro by default. Multiple circuits for the workloads that genuinely cannot go down. Test the failover. Resources Azure Virtual Network Manager overview Azure ExpressRoute introduction About ExpressRoute virtual network gateways About Azure VPN Gateway About Azure Virtual WAN Hub-spoke network topology in Azure Define an Azure network topology (Cloud Adoption Framework) Virtual WAN network topology in an Azure landing zone Watch the Rest of the Summit This was one of many great sessions at the Microsoft Azure Infra Summit 2026. If you want to catch the keynotes, the deep dives on storage and AKS, and everything in between, the full playlist is here: Microsoft Azure Infra Summit 2026 Playlist Big thanks to Jon Ormond for moderating, and to Jay Li and Jeff Lovett for the practical, no-fluff walk through what actually breaks at scale and how to design ahead of it. Cheers! Pierre RomanAzure Files, Reimagined: Top-Level Shares with Per-Share Networking, Billing, and Scale
Hello Folks! If you have ever wrestled with Azure Files inside a storage account, juggling shared RBAC, shared networking, and shared IOPS across a pile of shares that really should not live together, this session is going to address all that. During Microsoft Azure Infra Summit 2026, Vincent Du and Will Gries (both Product Managers on the Azure Files team) walked us through the new Microsoft.FileShares resource provider, a management model that promotes the file share itself to a top-level Azure resource. Why IT Pros Should Care For years, file shares lived inside a storage account, and that storage account dictated a lot of decisions for you. If one team needed a private endpoint and another needed a service endpoint, you either compromised or you created another storage account. If one share got hot and consumed all the IOPS, the other shares felt it too. Vincent and Will are on the team that built the new model to remove that compromise. Here is what changes for you as an IT pro: Each file share is its own Azure resource with its own RBAC, networking, billing, IOPS, and throughput. Per-share cost shows up directly in Azure Cost Management’s per-resource view, no more Excel guesswork. Encryption in transit is on by default for NFS shares, at no extra cost. Provisioning is dramatically faster. In their head-to-head demo, 200 shares finished in about 50 seconds on the new model versus about 720 seconds with the classic flow. A new MCP server lets you create and manage shares from GitHub Copilot in VS Code with natural language. In short, the new model trades the storage-account-as-gatekeeper pattern for something that feels a lot more like the rest of Azure (think VMs and disks, where the resource you care about is the resource you actually manage). What Microsoft.FileShares Does, a Technical Overview The new Microsoft.FileShares resource provider lets you deploy a file share without first standing up a storage account. When you go into the Azure portal, search for “File share,” and click create, you fill out a single create blade with the things that actually matter for that share: name, region, redundancy (LRS or ZRS), provisioned capacity, IOPS and throughput, networking, and tags. Microsoft Learn confirms the provisioned capacity range is 32 GiB to 262,144 GiB, and only LRS and ZRS redundancy are available at launch (see the Create a file share doc linked below). At GA, the new experience supports NFS 4.1 on the SSD media tier. SMB support, HDD support, customer-managed key encryption at rest, soft delete, and the AKS CSI driver integration are all on the roadmap and called out as the most-requested follow-ups. If you need those features today, the classic file share inside a storage account is still there for you. In the portal, Vincent showed off a small but meaningful detail: the icon color changed from blue (classic) to purple (new). It is a small thing, but when you are scanning a resource group, that visual cue saves you a click. How It Works Under the Hood The new model is built on the provisioned v2 billing structure. Microsoft Learn describes provisioned v2 as a billing model where you independently provision storage, IOPS, and throughput, and you pay for what you provision regardless of how much you actually use. This is a real shift from the older provisioned v1 model, where IOPS and throughput were a function of how much storage you provisioned. Will walked through the math. In his example, provisioning 14 TiB of storage on v1 gave 17,000 IOPS, about 1.5 GB/s throughput, and a bill of roughly $2,297. Moving to v2 with the exact same numbers was already noticeably cheaper. Then, because v2 lets you tune storage, IOPS, and throughput separately, he provisioned the exact storage he needed with slightly less IOPS and throughput, dropping the bill to roughly a third. For database-hot workloads you can dial IOPS up; for hot archive scenarios you can dial them down to the minimum. That kind of flexibility is genuinely useful. Encryption in transit deserves its own callout. The new shares default to encrypted NFS mounts using the AZNFS mount helper. Microsoft Learn explains that AZNFS wraps the NFS connection in a Stunnel-based TLS tunnel using AES-GCM, so you get TLS protection without needing Kerberos or external authentication. The helper installs cleanly on Ubuntu, RHEL, SUSE, Rocky, Oracle Linux, Alma Linux, and Azure Linux. If a workload genuinely cannot use the encrypted mount, you can uncheck the box and fall back to a traditional NFS mount. Networking is per share. You can attach a service endpoint or a private endpoint to each individual share, which means you can put a strict private-endpoint-only share next to a service-endpoint share for dev/test, all in the same resource group, without compromise. On the request side, classic shares throttle with a fixed window (you can burst, then you are locked out for the rest of the window). The new model uses a token-bucket algorithm (the same one Azure Resource Manager itself uses), which means you get a sustained refill rate. The team also gave you a separate delete bucket, so a big cleanup operation does not starve writes. That detail matters more than it sounds: batch cleanups against the classic model regularly crowd out new share creation. Real-World Value Where does this actually pay off? A few honest scenarios: Mission-critical and regulated workloads. A healthcare org with workloads at different sensitivity levels can put strict private-endpoint-only shares next to less sensitive service-endpoint shares without the storage-account ceiling. Chargeback and showback. With per-share resources, finance can pull a cost report that lines up to the team or project that owns each share. No more saying “we cannot itemize, the storage account is shared.” High-density tenants. The classic model effectively caps you at 34 file shares on an SSD provisioned v2 storage account (because of IOPS minimums) and 50 absolute. The new model goes up to 10,000 shares per subscription per region. That is a different game. Tuned database and analytics shares. Provisioned v2 lets you right-size IOPS to the workload. As Will showed, that can drop the bill to roughly a third for the right shape of workload. Faster deployment automation. A 14x improvement on a 200-share deployment is not a micro-optimization. If you spin up environments for CI, training, or per-customer tenants, that adds up quickly. The honest tradeoff: today, the new model is NFS-only on SSD. If you need SMB, HDD, customer-managed keys for NFS, or AKS CSI driver support, stay on the classic model for now. The team was upfront about that, and the GA-and-then-iterate roadmap is clear. Getting Started Here is the concrete path: Register the Microsoft.FileShares and Microsoft.Storage resource providers on your subscription (Subscriptions, Resource providers, Register). From the Azure portal, search for “File share” in the marketplace and click Create. Pick LRS or ZRS, set the capacity between 32 GiB and 262 TiB, and either accept the recommended IOPS/throughput or set them manually. On the Advanced tab, leave “Require encryption in transit” enabled (it is on by default) and pick a custom mount name if you want one distinct from the resource name. On the Networking tab, attach a service endpoint or a private endpoint, per share. Mount it on your Linux VM with the AZNFS mount helper. The portal generates the exact command for your distribution. If you live in IaC land, the Microsoft.FileShares ARM and Bicep types are available, and Terraform support is coming. If you live in AI-assisted dev land, install the Azure MCP server and ask Copilot in VS Code to create a share for you, pointing at an existing VNet. Resources Create an Azure file share with Microsoft.FileShares Understand Azure Files billing (provisioned v1 and v2) Encryption in Transit for NFS Azure file shares NFS file shares in Azure Files (protocol overview) Azure Files documentation home Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here. Cheers! Pierre RomanCut Your Azure Blob Storage Bill in Half: A Practical Walkthrough of Object Storage TCO
Hello Folks! If you have ever opened your monthly Azure invoice, stared at the object storage line, and quietly wondered how it grew so much, this one is for you. At the Microsoft Azure Infra Summit 2026, Benedict Berger and George Trossell from the Azure Storage Engineering team walked through a real customer scenario and showed how to bring that bill down without touching a single application. 📺 Watch the session: Why IT Pros Should Care Storage is one of those services we configure once at account creation, then never revisit. Redundancy, default tier, lifecycle rules. All decided on day one, then forgotten. Meanwhile, applications get built on top, dashboards get wired up, and the bill keeps climbing in a department nobody really audits. Here is what you get when you make storage TCO a first-class part of your operating model: A defensible understanding of capacity, transactions, and data retrieval charges (the three real cost drivers). Fewer surprise spikes when a cool tier read pattern runs hotter than expected. Cost optimization that runs on its own, instead of a quarterly cleanup project nobody volunteers for. Storage standards baked into your Infrastructure as Code, so cost-efficient defaults travel with every new account. In short, this is one of the highest-leverage cost levers you have in Azure. And unlike compute right-sizing, you can act on most of it from the portal in an afternoon. What Storage TCO Actually Means on Object Storage, a Technical Overview When Benedict and George talk about Total Cost of Ownership on Azure Blob Storage, they mean four moving parts: Capacity. The per-gigabyte cost of the data you store, which varies by access tier and by redundancy. Transactions. Every read, write, list, and metadata call against the storage account. Priced in packages of 10,000 operations. Data retrieval. A per-gigabyte fee that applies when you read from cool or cold tiers. It is free on hot. Network egress. The charge for moving data out of an Azure region. The trap most teams fall into is looking only at the per-gigabyte capacity column and picking the cheapest tier they see. That ignores the fact that as data gets cooler, transaction and retrieval costs climb sharply, and cold has a 90-day early deletion penalty that can erase your savings outright. Microsoft Learn documents this trade-off clearly in the access tiers overview, where you can see the minimum retention windows and the relationship between storage cost and access cost across hot, cool, cold, and archive. Redundancy is the other dial. LRS keeps three copies in a single zone. ZRS spreads three copies across three zones in the region. GRS adds an asynchronous secondary in a paired region. The honest tradeoff George highlighted: redundancy protects your data, not your application. If your app is not zone-aware, ZRS alone will not keep you running through a zone outage. And GRS failover is a manual operation in most cases, with the secondary in read-only mode until you stand up new accounts to write into. How It Works, Under the Hood The session walked through a worked transaction example that finally made the math click for me. Picture a Spark job uploading 1,000 parquet files of 5 GB each into the hot tier, using an 8 MB block size. Each 5 GB file is roughly 5,120 MB, divided by 8 MB blocks, which gives 640 put block operations. One additional put block list call commits the upload, so each object costs 641 write operations. Times 1,000 files, that is 641,000 operations, which works out to about 3.52 US dollars in that hour just for writes. Now flip it. Read those same 1,000 files from the cool tier. The transaction count is similar, but you also pay a data retrieval fee on every gigabyte you pull back. That retrieval fee is where most teams get blindsided, because it does not show up on the hot tier at all. Block size matters too. Larger blocks mean fewer transactions per upload. And for small objects (under 128 KB), there is a new wrinkle to plan for: starting July 2026 for existing accounts and already in effect for new accounts created from July 2025, cooler tiers bill a 128 KB minimum object size. That means a 4 KB log file moved to cool gets charged as if it were 128 KB. The fix is either to leave small objects in hot, or bin-pack them into larger objects (a TAR or ZIP, for example) before tiering them down. The Microsoft Learn page on access tier best practices covers packing strategies in detail. Real-World Value, Use Cases, and ROI The customer in the session went from roughly 65,000 US dollars a month to around 25,000. That is not a marketing number, it is what happens when you apply the levers in order: Right-size redundancy. Move non-production and easily reproducible data off LRS in production. Reserve GRS for the workloads where a compliance regulation actually requires a second region. Match tiers to access patterns. Use premium for bursty, latency-sensitive workloads. Hot for active reads and writes. Cool and cold only when you genuinely access the data infrequently and have budgeted for the retrieval fees. Buy reserved capacity for the steady-state portion of your footprint. A one or three year commitment unlocks a discount on block blob capacity. See reserved capacity for Blob storage for terms and tier coverage. Kill wasteful transactions. Replace polling-for-changes with change feed. Replace recurring list-blob loops with a daily or weekly blob inventory report. Use conditional request headers (If-Modified-Since and friends) so reads skip unchanged objects. Pack small objects, or leave them in hot. Either is fine; tiering them down without packing is not. In short, the same scenario, with the same applications, runs at less than half the cost once you actually look at it. Getting Started Here is the order of operations I would follow tomorrow morning: Pull a blob inventory report on your largest storage accounts to see what is actually there: tier mix, object sizes, last modified dates, snapshots, versions. Open the Azure pricing calculator and model your scenario with realistic transaction counts and retrieval volumes. Do not just compare per-GB prices. Audit your redundancy choices against the workload. If an account is LRS in production with no easy way to rebuild the data, change it. Enable Smart Tier on your zone-redundant accounts. New objects start in hot, get demoted to cool after 30 days of inactivity, and to cold after 90, with no charges for tier transitions, early deletions, or data retrieval. Anything accessed gets instantly promoted back to hot. For accounts that cannot use Smart Tier, write a lifecycle management policy. Keep the rules simple at first: tier down after 30 days, archive after 180, expire snapshots and versions on a schedule. Convert one of your existing lifecycle policies to ARM or Bicep, then commit it to source control. Add an Azure Policy that flags any new storage account that does not match your standard. That last step is the one that sticks. As Benedict put it, cost optimization must become part of your system, not an afterthought. Resources Access tiers for blob data, Microsoft Learn Best practices for using blob access tiers, Microsoft Learn Azure Blob Storage lifecycle management overview, Microsoft Learn Optimize costs for Blob storage with reserved capacity, Microsoft Learn Enable Azure Storage blob inventory reports, Microsoft Learn Azure pricing calculator Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanFeeding the GPUs: File Storage for AI and Cloud-Native Workloads on Azure
Hello Folks! If you are running AI workloads on Azure, you have probably learned the hard way that the wrong storage choice can leave a rack of very expensive GPUs sitting idle, waiting for data. In this session during the Microsoft Azure Infra Summit 2026, Wolfgang de Salvador and Reena Shah from the Azure Storage team walked through how Azure Managed Lustre and Azure Files map to the distinct stages of the AI pipeline, and why picking the right file system per stage is one of the highest leverage decisions you will make. 📺 Watch the session: Why IT Pros Should Care You probably did not get into IT to babysit checkpoint writes or debug Hugging Face egress bills at 2 a.m. But that is exactly the kind of work that lands on your plate when storage is not matched to the workload. Here is why MAIS28 matters for the IT pros, platform engineers, and Azure architects in the room: GPU time is the most expensive compute you will ever buy. Slow data loading and slow checkpoints turn that into burned cash. AI workloads are not one workload. Data prep, training, fine-tuning, and inferencing each have a different storage profile. Cloud-native AI on AKS and Azure Container Apps lives or dies on the ReadWriteMany experience. If model loading is slow or shared model caches do not exist, every cold start re-downloads hundreds of gigabytes. Storage choices ripple into security and compliance. Encryption in transit, redundancy, and snapshots are not optional in 2026. In short, this session is for anyone who has to answer the question, “What persistent volume should we use for this AI workload?” and wants a defensible answer. What Azure Brings to the Table, Technical Overview Wolfgang opened with the storage profile of every stage of an AI workflow. Data preparation needs hundreds of petabytes at the best TCO (think Azure Blob Storage as the durable core). Training and fine-tuning need extreme throughput so GPUs stay fed during data loading and so checkpoint writes complete fast. Inferencing needs fast model loads, low-latency KV cache, and grounded data for RAG. One filesystem does not fit all of those at once, and trying to make it fit is where teams overspend. Azure’s answer is a tiered, file-based portfolio that lines up with those stages: Azure Managed Lustre (AMLFS) is a fully managed, accelerator-tier filesystem. It scales to 25 PB of capacity and up to 512 GB/s of throughput, integrates with Azure Blob Storage as the durable core, and exposes a standard Lustre client plus a CSI driver for AKS. Azure Files is the natural ReadWriteMany choice for cloud-native AI on AKS and Azure Container Apps. It tops out at 256 TB of capacity and 10.4 GB/s of throughput, offers LRS and ZRS redundancy with snapshots and soft delete, and ships with a 99.99% SLA. Azure Blob Storage sits underneath both of these as the cheap, durable core for data prep and long-term retention. The mental model the speakers used is “accelerator and core”. Blob is the core, durable and economical. AMLFS is the accelerator for training. Azure Files is the accelerator for inferencing and shared state. Pick the right pair for the stage you are running. How It Works, Under the Hood For training, Wolfgang showed the demo most folks came to see: a 32 x H100 ND H100 v5 AKS cluster deployed from the Azure AI Infrastructure repository, running a 30B-parameter GPT-3 training job backed by AMLFS. Two things matter here. First, AMLFS absorbs checkpoint write bursts. When 32 H100s flush state at the same time, you need a filesystem that can take the punch without stalling. AMLFS does, which keeps GPU utilization drops short and contained. Second, the AMLFS Lustre CSI driver for AKS supports both static and dynamic provisioning with availability-zone placement, and there are five SKU tiers from MLFS20 (cheapest by capacity) to MLFS500 (cheapest by bandwidth). That means you can pick a cost-performance point that matches your training budget instead of buying the top SKU and hoping for the best. For inferencing, Reena’s half of the session was just as practical. Five reasons Azure Files fits AKS ReadWriteMany workloads: Standard Kubernetes RWM volume over NFS or SMB. 256 TB capacity ceiling and up to 10.4 GB/s of throughput per share. LRS or ZRS redundancy with snapshots and soft delete for protection. 99.99% SLA so it shows up in your availability math. Native support across AKS and Azure Container Apps, including serverless GPU. The headline feature is Azure Files Provisioned v2. In the old model, IOPS and throughput were a function of how much capacity you provisioned, which is wrong for AI shapes that need small capacity but very high IOPS and bandwidth. Provisioned v2 splits capacity, IOPS, and throughput into three independent knobs you can dial without downtime or remount. That alone changes the economics for a lot of inferencing patterns. The other big inferencing feature is NFS v4.1 encryption in transit, delivered with the az-nfs utility and stunnel. You get AES-GCM TLS protection on the wire, with no Kerberos and no Active Directory needed, and the application has no idea it is happening. Reena’s live demo showed an AKS pod with an encrypted NFS mount, transparent to the workload. And then the pattern that ties it together: the shared model cache. Download the model once into Azure Files, mount it across every replica via ReadWriteMany. No per-pod cold start, no re-download from Hugging Face, no egress bill. The demo used GPT-OSS 120B with VLLM on 32 x H100, and the pattern scales down to small fine-tuned models running on serverless GPU in Azure Container Apps. Real-World Value The session closed with the Viton case study. Viton is a Paris-based fashion AI startup. Their image-generation platform runs on Azure Container Apps serverless GPU, with Azure Service Bus for job routing and Azure Files NFS as the shared model store. Workers pull jobs, mount the shared model cache, generate the image, and scale to zero when the queue drains. The economics only work because they are not paying to re-download the model on every cold start, and because they only pay for GPU when there is work to do. The same pattern shows up across customer scenarios: Training a foundation model on AKS with AMLFS as the scratch tier and Blob as the durable archive. Fine-tuning smaller models where AMLFS checkpoints absorb the write bursts and the final artifact lands back in Blob. Inferencing with VLLM on AKS where Azure Files holds the model weights once and every replica reads from the same RWM mount. Serverless inferencing on Azure Container Apps with the same shared model cache pattern, but with scale-to-zero economics. Honest tradeoff: Lustre is not the right filesystem for a 10-pod web app, and Azure Files is not the right filesystem for a 32-GPU training run. The whole point of the tiering is that you pick the right one per stage. Do not try to make one filesystem do all four jobs. Getting Started If you want to put this into practice this week: Go to the Azure AI Infrastructure repository on GitHub. Wolfgang’s demo cluster came straight out of it, and you can spin up an AI-ready AKS cluster with GPU and InfiniBand operators in your own dev/test subscription. Install the Azure Managed Lustre CSI driver on AKS if you are running training or fine-tuning. Start with a smaller MLFS SKU and size up. Turn on Azure Files Provisioned v2 on a new share, then dial capacity, IOPS, and throughput independently to match your inferencing shape. Enable NFS v4.1 encryption in transit with az-nfs and stunnel before you put any sensitive workload on the wire. Try the shared model cache pattern. Pick one VLLM deployment, point it at an Azure Files RWM mount, and measure cold start time before and after. Resources Azure Managed Lustre documentation Use the Azure Managed Lustre CSI driver with Azure Kubernetes Service Azure Files documentation Understand Azure Files billing (Provisioned v2) Encryption in transit for NFS Azure file shares Azure Container Apps serverless GPUs Azure AI Infrastructure repository on GitHub Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre Roman
