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! PierreAzure 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 RomanPremium SSD v2 and Instant Access Snapshots: A Better, Faster, Cheaper Disk for Your Azure VMs
Hello Folks! If you have been running Premium SSD v1 because that is just what you have always done, this session from the Microsoft Azure Infra Summit 2026 is going to be a wake up call. Raymond Lui and Adam Li from the Azure Disk Storage team walked us through Premium SSD v2 (PV2 for short) and the new Instant Access Snapshots, and the punchline is simple. PV2 is faster, it is cheaper, and the operational story around it just keeps getting better. 📺 Watch the session: Why IT Pros Should Care If you are an infrastructure person, a SQL DBA, an SAP Basis admin, or anyone who has ever had to right-size a VM around its storage tier, this matters to you. In short, Premium SSD v2 changes the rules around how you provision block storage in Azure. Here is what stood out from the session: 4x more IOPS and 2x more throughput compared to Premium SSD v1, on a matched configuration that costs 42% less. Sub-millisecond average latency, with a top configuration of 800,000 IOPS and 20 GB/s of throughput on a single VM. Capacity, IOPS, and throughput are decoupled. You dial each one independently, in 1 GB increments, instead of buying a tiered SKU. 3,000 baseline IOPS and 125 MB/s throughput included on every disk, with no extra cost. Live Resize. You can grow disk size, IOPS, or throughput on a running VM with no restart required. Instant Access Snapshots make restores feel actually instant, with up to 10x faster hydration and 90% lower read latency during hydration. That is a lot of wins on one slide. Let’s break it down. What Premium SSD v2 Is, Technical Overview Premium SSD v2 is Azure’s purpose-built block storage for I/O-intensive enterprise workloads. Microsoft Learn describes it as designed for workloads that need sub-millisecond disk latency, high IOPS, and high throughput at a low cost. The target list is broad: SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data and analytics, gaming, and stateful containers running on AKS. The architectural shift that Raymond highlighted is independent scaling. With Premium SSD v1, you bought a fixed SKU. If you wanted more IOPS, you had to buy more capacity, even if you did not need it. With PV2, capacity, IOPS, and throughput are three separate dials. You provision capacity in 1 GB increments, then you set IOPS and throughput to match what your workload actually needs. If you over-provisioned, you tune it down. If you under-provisioned, you tune it up, and the VM keeps running. Raymond highlighted three primary use cases in the session: SAP workloads, including SAP application VMs, SAP HANA databases, and non-HANA databases like Oracle, DB2, and SQL Server in SAP environments. SQL Server. According to a GigaOM benchmark cited in the session, SQL Server on PV2 delivered 51% more transactions per second and 39% lower cost per transaction compared to AWS EC2, with a 9% lower 3-year TCO. Big data and analytics replacing local SSD. This one is a bit of a surprise. On D-series VMs, PV2 delivered over 1,400 MB/s of throughput compared to 720 MB/s from local SSD. That means you can run Spark or Databricks workloads on cheaper VM SKUs (without local storage) and still get more performance than you had before. Premium SSD v2 supports a 4k physical sector size by default, with 512E available for legacy applications. There are a few honest tradeoffs to know about. PV2 disks cannot be used as an OS disk, and they cannot be used with Azure Compute Gallery. PV2 also does not support host caching. For regions with availability zones, PV2 disks can only be attached to zonal VMs, so plan your VM placement accordingly. How It Works, Under the Hood Raymond covered the architecture briefly, and it is worth understanding. PV2 uses direct VM-to-storage-node communication, with 3-replica durability behind the scenes. That direct path is part of how it gets sub-millisecond latency consistently. For Instant Access Snapshots, Adam walked through the architectural difference between the classic incremental snapshot path and the new Instant Access path. With classic incremental snapshots for PV2 and Ultra Disk, the snapshot is created, then the data has to copy in the background to Standard HDD before the snapshot is usable for restore. That copy could take a while on a large disk, and restored disks would then hydrate slowly, which dragged down read latency until hydration finished. With Instant Access, the snapshot is usable the moment it exists. The data stays in the same high-performance storage as the source disk for a configurable duration (60 to 300 minutes, controlled by the InstantAccessDurationMins parameter). At the same time, Azure copies the snapshot data to Standard ZRS in the background for long-term retention. When the Instant Access window expires, the snapshot transitions to a regular incremental snapshot, sitting on cheap durable storage. You get the speed and the long-term durability without running two separate workflows. In short, your VM can boot and run at near-full performance while the data hydrates in the background. There are some limits to keep in mind. Instant Access counts toward the existing limit of three in-progress snapshots per disk, and you can create up to 15 disks concurrently from all instant access snapshots of a single disk. Real-World Value (Use Cases, ROI, Scenarios) Adam closed his portion of the session with a BCDR demo. He cloned 12 disks of an M-series production database into a recovery VM, attached them, and was immediately running roughly 500,000 IOPS at single-digit-millisecond latency. No waiting for hydration. No degraded performance window. That is a meaningful improvement to your Recovery Time Objective (RTO). A few scenarios where this combination really pays off: Pre-deployment safety nets. Take an instant access snapshot before a big upgrade. If something goes sideways, roll back in seconds instead of hours. Rapid scale-out for stateful apps. Spin up multiple disk copies of a primary instance in seconds. You can even place them across availability zones in the same region. Dev/test environment refresh. Clone production into dev or test on demand, with full performance from the first I/O. No more “we’ll refresh dev next quarter” because the restore takes too long. SAP HANA always-on operations. Live Resize means you can scale IOPS or throughput up on a running database during a load spike, without a maintenance window. Right-sizing to cut spend. If you have been paying for VM SKUs purely to get local SSD throughput, PV2 may let you drop to a smaller, cheaper VM and still hit higher numbers. One nuance came up in the live Q&A. Jens asked a great question about profiling: how do you know when PV2 is the right choice versus Standard SSD? Raymond’s guidance was direct. If the workload needs high IOPS or high throughput, PV2 is generally the right call. The VM SKU also needs to support “Premium Disk” capability for PV2 to attach, so check that compatibility first. Getting Started Concrete first steps so you can start kicking the tires: Confirm region and zone support. Use az vm list-skus --resource-type disks --query "[?name=='PremiumV2_LRS']" to see which regions and availability zones are supported in your subscription. Pick a Premium-capable VM in a supported zone. Remember, PV2 is zonal in AZ regions. Decide on the zone before you create the VM. Provision a disk. Start with default performance (3,000 IOPS, 125 MB/s) and a small capacity. You are paying for the dials you turn up; defaults are reasonable for most starting points. Plan your v1 to v2 migration. Raymond demoed two paths. Option A: detach the disk from a running VM and convert it (the VM keeps running on its other disks). Option B: stop and deallocate the VM, then convert in place. Both preserve data, and you can raise IOPS and throughput as part of the conversion. Try Instant Access Snapshots. Add --instant-access-duration-in-minutes (or the equivalent ARM/PowerShell parameter) to your existing snapshot command. That is all the change you need to enable it. For AKS users, define a storage class with skuName: PremiumV2_LRS and let dynamic provisioning take it from there. Resources Select a disk type for Azure IaaS VMs (managed disks) Deploy a Premium SSD v2 managed disk Convert managed disks storage between different disk types Instant access snapshots for Azure managed disks Use Premium SSD v2 with VMs in an availability set Use Azure Premium SSD v2 disks on Azure Kubernetes Service Azure managed disks overview SAP HANA Azure virtual machine Premium SSD v2 storage configurations Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanAzure Elastic SAN: Pooled, Cloud-Native Block Storage That Actually Acts Like a SAN
Hello Folks! If you have ever lived through a Friday night SAN expansion, racking new shelves and praying the zoning held together, the idea of getting that same shared block storage model in Azure (without owning a single fibre channel cable) sounds almost too good to be true. In his session at the Microsoft Azure Infra Summit 2026, Kiran Cherukuwada, Principal PM in Azure Storage, walked us through exactly how Azure Elastic SAN does that, and where it fits next to the other block storage options on Azure. 📺 Watch the session: Why IT Pros Should Care Most of us were taught a simple rule. One workload, one disk, size it for peak, move on. That rule has been kind to managed disks, but it gets expensive fast when you have dozens or hundreds of workloads that all peak at different times. Elastic SAN flips the model. You provision a pool of capacity and performance once, then carve volumes out of it for many workloads. Here is why that matters for IT pros: You stop over-provisioning each workload to its own peak; the SAN absorbs the bursts. You get a SAN-style resource hierarchy (SAN, volume groups, volumes) that looks and behaves like the on-prem model you already know. iSCSI connectivity means a wide compute footprint, including Azure Virtual Machines, Azure Kubernetes Service, Azure Container Instances, Azure VMware Solution, and Nutanix Cloud Clusters. You can drive storage throughput over VM network bandwidth, which often lets you keep a smaller (and cheaper) VM SKU. In short, if you have many IO-intensive workloads sharing one region, Elastic SAN is the lever that turns “buy peak for every workload” into “buy combined peak for the group.” What Azure Elastic SAN Is, Technical Overview Azure Elastic SAN is the industry’s first fully managed SAN storage service in the cloud. It brings the on-prem SAN consumption model to Azure as a single managed pool of block storage, shared across many workloads, accessed over the industry-standard iSCSI protocol. Inside the service you get three resources, matching the on-prem mental model: The Elastic SAN itself. Top-level resource. This is where you provision overall capacity and performance, and where billing happens. Volume groups. Where you set network rules (service or private endpoints) and security policies. Any policy you apply here is inherited by every volume in the group, so a volume group is effectively your workload boundary. Volumes. The LUNs that you mount on compute. They show up as raw block devices on a VM, as iSCSI targets to a Kubernetes node, or as VMware data stores on AVS. A single SAN can scale to a petabyte of capacity, 2 million IOPS, and 80 GB/s of throughput. It is locally redundant by default, with a zone-redundant option, and shared volume support is there for clustered solutions like SQL Server Failover Cluster Instances and Azure VMware Solution. Network isolation is delivered via service endpoints and private endpoints, and data is encrypted at rest. Incremental snapshots are supported for fast point-in-time restore, and snapshots can be exported to managed disk snapshots when you need a hardened copy for backup or DR purposes. Where does it land in the block storage portfolio? Kiran framed it simply. Premium SSD v2 is the best price/performance for dedicated per-workload performance. Ultra Disk is for the mission-critical, every-microsecond-matters workloads. Elastic SAN is the best price/performance option at scale, when you have many workloads that can share a storage pool. How It Works, Under the Hood The economics live in the provisioning model. You buy two types of units: Base unit. Each base unit gives you 1 TiB of capacity plus 5,000 IOPS and 200 MB/s. Roughly 8 cents per GiB per month in East US. Capacity-only unit. Each capacity-only unit gives you 1 TiB of capacity but no extra performance. About 25 percent cheaper, around 6 cents per GiB per month in East US. The pattern Kiran showed is “size for performance first, then top up capacity.” A 250 TiB SAN delivering 1 million IOPS and 40 GB/s came out to roughly 200 base units plus 50 capacity-only units, landing around 20 grand per month for the whole pool. The magic ingredient is dynamic performance sharing. With traditional disks you provision each workload to its own peak. With Elastic SAN, you provision the combined peak. So a SQL Server needing 60,000 IOPS, an AVS cluster needing 40,000, and an Oracle workload needing 100,000 IOPS look like 200,000 IOPS of dedicated disk. But if they never peak simultaneously, you can land a 150,000 IOPS SAN and let each workload hit its peak on demand. That is real money back. The second lever is throughput over network bandwidth. Because Elastic SAN connects over iSCSI, storage I/O flows through the VM’s network pipe, not the VM’s disk throughput cap. Most VMs have far more network bandwidth than disk bandwidth, so you can drive higher storage throughput from a smaller VM SKU. That smaller SKU is cheaper to run, and (this is the quiet win) it can also cut per-core database licensing costs. As one attendee asked in the live Q&A, “Why is it possible to go beyond the VM disk throughput limit with SAN?” The answer: iSCSI traffic uses VM network bandwidth like any other VM-to-VM traffic, so the disk throttle does not apply. One honest tradeoff: that same network bandwidth is also used by your app-tier-to-database traffic. So if you are planning to push storage hard, size the VM with both flows in mind. Real-World Value Where does this actually pay off? Mixed enterprise workloads on Azure VMs. SQL Server, Oracle, custom OLTP, sharing one SAN. Kiran’s demo ran SQL TPCC, an AVS cluster benchmark, and an Oracle OLTP load simultaneously off a single 30-base-unit SAN, and the metrics blade showed exactly how each volume group consumed performance. Extending Azure VMware Solution storage. Instead of buying expensive vSAN nodes just to grow storage, you connect AVS to an Elastic SAN datastore. Gen2 AVS private clouds skip the ExpressRoute gateway requirement and let you use a single private endpoint on the volume group. Container Storage. Azure Container Storage v2 with Elastic SAN backing is generally available. The fast attach and detach behavior means that even if a node or cluster goes down, the data sits on the SAN and persists. Lift and shift from on-prem SAN. Kiran shared one migration example: a workload with 100-plus vCPUs running off a mid-tier all-flash SAN array landed on Elastic SAN with roughly 64 percent TCO savings and performance that exceeded the original array. In short, this is a “many workloads, one pool” story. If you have one heavy workload, premium SSD v2 may be a better fit. Getting Started Here is a practical order of operations: Size the SAN. Add up the combined peak IOPS and throughput for the workloads you plan to consolidate, then pick base units to cover performance and capacity-only units to top up storage. Lock down the network. Access is closed by default. Choose service endpoints or private endpoints per volume group, and open them only to the right subnets. Place compute in the same zone. For best latency, deploy your VMs (or AVS cluster) in the same region and availability zone as the SAN. Tune the client. Use Gen 5 (D, E, or M series) VMs with Accelerated Networking on, configure the iSCSI initiator, set up native MPIO on Windows or Linux, and use the Connect scripts from the portal which default to 32 sessions per volume. Watch the metrics. The SAN’s Metrics tab shows transactions, ingress, and egress at the SAN, volume group, and individual volume level. Drop the granularity to one minute when you are troubleshooting. Plan snapshots. Use Elastic SAN volume snapshots for fast dev/test restores. Export to managed disk snapshots when you need hardened backup or cross-region DR. If you are coming from on-prem, the partnership with Cirrus Data (free in the Azure Marketplace) is the recommended path to migrate storage at the block level. Resources Azure Elastic SAN documentation hub What is Azure Elastic SAN (introduction) Plan for an Azure Elastic SAN deployment Azure Elastic SAN configuration best practices Snapshot Azure Elastic SAN volumes Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanModernize VDI with Azure Files and Entra Cloud-Native Identities
Hello Folks! If you have ever run a Virtual Desktop Infrastructure (VDI) estate, you know the recurring riddle. The session hosts are designed to be stateless and pooled, yet every user expects a persistent Outlook profile, their OneDrive cache, their pinned apps, and a sub-ten-second logon. In this session at the Microsoft Azure Infrastructure Summit 2026, Adam Groves and Priyanka Gangal from the Azure Files team showed how Azure Files plus Microsoft Entra ID finally let you deliver that experience without dragging domain controllers along for the ride. 📺 Watch the session: Why IT Pros Should Care VDI has always been a balancing act between elasticity and continuity. The compute layer wants to be ephemeral. The user wants to be at home. Bridging those two worlds used to mean a stack of identity plumbing that quietly grew until it became its own platform. This session changes that math. Here is what jumped out for me: Cloud-only identity for SMB. Azure Files now authenticates pure Microsoft Entra ID users and groups, including B2B guests, directly over SMB Kerberos. No on-premises Active Directory required, no Entra Connect required, no line of sight to a domain controller. NTFS ACLs and Kerberos preserved. You keep the security model your apps already understand. Permissions still live on the file system, tickets still come over SMB, and FSLogix does not care that the identity stack underneath is different. Performance built for the spike. Metadata caching is generally available and rolling out by default. Concurrent file handles per share are moving from 2,000 today to 10,000, with a roadmap toward 30,000 to 50,000. That means fewer storage accounts to shard across when 9 AM hits. Zonal placement and smarter alerts. Premium LRS now lets you co-locate the share with its session hosts inside the same availability zone, and new percentage-based metrics finally make alert thresholds portable across shares of any size. In short, the boring identity and storage plumbing that propped up VDI for a decade is being collapsed into something you can actually run as a cloud-native service. What This Is, A Technical Overview Let’s set the table. VDI on Azure (whether you run Azure Virtual Desktop, Citrix on Azure, or Omnissa Horizon) uses pooled session hosts. Those hosts are intentionally stateless so they can be patched, scaled, and recycled without ceremony. The user’s identity is “Connie Cloud” today, and on a different host tomorrow. FSLogix solves the continuity half of the puzzle. It packages the user’s profile and Office data containers (the profile container and the ODFC, the Office Data Folder Container) as VHDX files that get dynamically attached when Connie logs on and detached when she signs out. Those VHDX files need to live somewhere durable, fast, and reachable over SMB from any host in the pool. That is precisely what Azure Files delivers. It is a fully managed SMB file share service that integrates cleanly with FSLogix profile containers and App Attach image stores for AVD. The reference architecture and sizing guidance are documented on Microsoft Learn for anyone who wants the official map. The historic friction was identity. Until recently, SMB authentication to Azure Files required either on-premises AD DS joined to the storage account or hybrid identities synced through Entra Connect. That meant keeping domain controllers (and the network paths to reach them) alive purely to satisfy storage authentication. As of this year, Azure Files supports pure Microsoft Entra ID identities for SMB Kerberos, which closes that loop. How It Works, Under the Hood Here is the simplified flow Adam and Priyanka walked through during the demo. The user (an Entra-only account, no on-prem footprint) signs into an Entra-joined AVD session host with single sign-on. The session host needs to mount the user’s FSLogix profile container from an Azure Files share. The host requests a Kerberos service ticket. Because the share has Microsoft Entra Kerberos authentication enabled, Entra ID issues that ticket directly, no on-prem KDC involved. The SMB connection is established, the share-level RBAC role (for example Storage File Data SMB Share Contributor) is checked, and then the directory and file ACLs (standard NTFS) are evaluated. FSLogix attaches the VHDX, the profile loads, Outlook is happy, OneDrive is happy, and Connie’s pinned taskbar shows up exactly the way she left it. A few details worth filing away: Two layers of authorization. Share-level access uses Azure RBAC roles. Item-level access uses NTFS ACLs. Both still apply, which is why your existing permissions model carries over cleanly. B2B guest support. Vendor and contractor accounts that come in as guests in your tenant can be granted access to file shares without needing a synced shadow account. Metadata caching is the unlock. VDI is metadata-heavy: directory enumerations, file opens, renames, and closes hammer the share at logon. Metadata caching reduces P50 latency on those operations by roughly 80 to 90% and roughly doubles metadata transaction throughput, which is what makes the higher concurrent handle limits realistic. The full SMB performance reference on Microsoft Learn lays out the knobs. Zonal placement. Premium LRS lets you pin the share to the same availability zone as your session host pool, so the SMB traffic does not bounce across zones. Real-World Value Where does this show up in your operations review? Retire orphan domain controllers. Plenty of shops have a couple of DCs in Azure that exist only so Azure Files can authenticate. Cloud-native Entra ID lets you turn those off and shrink the identity attack surface. Simpler M&A and vendor onboarding. Adding a partner organization or a new acquisition no longer requires forest trusts or a sync project. Invite guests, assign them to a group, grant the group access to the share. Fewer storage accounts and shares to manage. Higher concurrent handle limits mean you can consolidate users that you previously had to spread across many accounts just to dodge the 2,000-handle ceiling. Less sprawl, less monitoring, fewer naming conventions to remember. Predictable logon times at scale. Metadata caching is the kind of feature you only notice when it is missing. With it on by default, large host pools see flatter logon latency curves during the morning rush. Operational consistency. Percentage-based metrics let you set a single rule like “alert at 10% remaining capacity” and apply it cleanly to a 5 TiB share and a 100 TiB share without bespoke thresholds. In short, the ROI conversation moves from “how do we keep VDI running” to “how much of the supporting cast can we delete.” Getting Started If you want to kick the tires this week, here is a practical starting path. Inventory your VDI identity story. Are you running hybrid because the apps need it, or because Azure Files used to need it? If it’s the second one, you have a candidate workload for cloud-only identity. Spin up a pilot Premium SSD Azure Files share in the same region (and ideally the same availability zone) as a small AVD host pool. Enable Microsoft Entra Kerberos authentication on the storage account. The configuration is now in the standard Azure portal, no more side trips to the fileperms portal. Assign Azure RBAC roles at the share level (Storage File Data SMB Share Reader, Contributor, or Elevated Contributor as appropriate) to your Entra groups. Set NTFS ACLs on the directories that will host FSLogix containers, and point FSLogix at the share’s UNC path. Test with a cloud-only user (no on-prem identity at all) to confirm the end-to-end flow. Turn on metadata caching and the new metrics and set percentage-based alerts so you find the limits before your users do. Resources Azure Files documentation Use Azure Files for virtual desktop workloads Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities on Azure Files Improve performance for SMB Azure file shares (metadata caching, multichannel, handle limits) Data redundancy for Premium file shares 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 RomanMoving Petabytes Without the Panic: At-Scale Storage Assessments and Migrations to Azure
Hello Folks! If you have ever been asked to move all our file shares to the cloud ASAP. You already know that storage migration is one of those projects that looks easy on a slide and gets ugly in reality. In this session at the Microsoft Azure Infra Summit 2026, Anusha Subramanian and Madhuri Narayana Rao (both Product Managers on the Azure Storage team) walked through a guided roadmap for discovering, assessing, and moving large-scale storage to Azure without the homegrown scripts and the late-night reruns. 📺 Watch the session: Why IT Pros Should Care In short, this session matters because data migration is consistently underestimated. Anusha put it well: customers focus on migrating applications and workloads, and the big chunk of storage those apps depend on tends to be an afterthought. That afterthought is where projects go sideways. Wrong target tier, wrong tool, wrong sizing, and suddenly you are unwinding an architecture six months in. Here is what you get out of the new tooling Anusha and Madhuri covered: A first-party, end-to-end path from discovery to assessment to cutover, all inside services you already pay for. File share discovery and assessment now generally available in Azure Migrate, so you stop guessing about your on-premises estate. A fully managed online migration service (Azure Storage Mover) that handles retries, logging, bandwidth, and scheduling for you. An offline option (Azure Data Box) for when your network is the bottleneck and you are staring down hundreds of terabytes. A partner program (the Storage Migration Program) that covers the edge cases first-party tools do not yet cover, with the ISV software cost picked up by Azure. If you manage file servers, NAS, or large object stores and you have a migration on your roadmap, this is your toolkit. What This Toolkit Does: Technical Overview The session framed large-scale storage migration as a guided roadmap with clear phases. You discover what you have on premises, assess how it is used, pick the right cloud target, decide on a migration strategy, execute in phases, and then run post-migration checks before you cut over. The point of the new tooling is to make each of those steps repeatable instead of bespoke. Three services do most of the heavy lifting: Azure Migrate file share assessment (generally available). Azure Migrate has been Microsoft’s first-party migration platform for a while, but until recently it was very compute-focused (think VMware, Hyper-V, and physical server lift-and-shift). The new capability extends that same discovery appliance to the file shares hosted on those servers. You get share inventory, OS type, protocol, capacity, and basic performance metrics like IOPS and throughput, all flowing back into your Azure Migrate project automatically. Azure Storage Mover. This is the fully managed online migration service. It moves files and folders to Azure without custom scripts or migration infrastructure that you have to babysit. It supports on-premises SMB and NFS sources, cloud-to-cloud moves within Azure (for example, Blob container to Blob container), and AWS S3 to Azure Blob today (with more clouds on the roadmap). Azure Data Box. The offline path. Ruggedized, encrypted, shipped to your datacenter, copied locally, shipped back, and ingested into Azure Storage. The current SKUs include 7 TB disks, 120 TB devices, and 525 TB devices, with 256-bit AES encryption end to end. How It Works Under the Hood For Azure Migrate file share assessment, you download (or update) the Migrate appliance and deploy it on your VMware, Hyper-V, or physical server estate. Grant the required permissions, and the appliance starts collecting share metadata and performance telemetry. That data flows back into your Azure Migrate project, and you see file shares appear as first-class entities in the Infrastructure tab right alongside servers. From there you can tag shares, scope them into groups, and generate assessments that map each share to a recommended Azure Files SKU, give you a TCO estimate, surface readiness blockers, and recommend a migration tool. You can export the whole thing to Excel or PowerPoint, which is exactly what you need when finance asks for the business case. For Storage Mover, the key architectural detail is that the data path is separate from the management path. You deploy a Storage Mover agent close to your source (on premises, in another cloud, or wherever the data lives). The Storage Mover resource in Azure can sit in any region. The agent pulls data from SMB or NFS, then pushes it via REST API directly to the target storage account. Only logs and metadata flow through the service itself. That means migration velocity is governed by the proximity between the agent and the target storage account, not by the region of the management resource. SMB credentials are stored in Azure Key Vault, the agent fetches them at runtime, and one central Storage Mover resource can manage agents deployed globally. Data Box is conceptually simpler. Order the device through the Azure portal, receive it, copy locally over your LAN at LAN speeds, ship it back, and Azure ingests the data into the storage account you specified. The Data Box family is documented at the Microsoft Learn link in the Resources section below. Real-World Value Where does this actually pay off? A few scenarios came up in the session. Lift-and-shift of file servers. Discover with Azure Migrate, assess, get target SKU recommendations and TCO, then move with Storage Mover. Permissions, metadata, and folder structure are preserved during the copy. Cloud-to-cloud (AWS S3 to Azure Blob). The session demoed the multi-cloud connector workflow: deploy a Storage Mover resource, add an AWS connector with an Inventory and Storage Data Management solution, run the AWS CloudFormation template, then create a project, a job definition, and start the job. It is portal-driven from beginning to end. Petabyte-scale offline lift. When you cannot saturate your production WAN for weeks, Data Box gets your seed data to Azure. Then Storage Mover handles the automated delta sync so the cutover window stays small. Recurring incremental sync. Storage Mover now supports recurring schedules (one-time, daily, weekly, or monthly) combined with bandwidth management for peak and off-peak windows. That is useful when data is being collected continuously on premises and you want predictable, throttled transfers. Sovereign cloud. Storage Mover is now available in Azure US Government, so federal and public sector customers can run the same workflow inside their sovereign environment. Specialized scenarios. For source-target pairs the first-party services do not cover yet (say, on-premises NetApp to Azure NetApp Files, which Anusha confirmed in the live Q&A is not yet in Azure Migrate’s scope), the Storage Migration Program brings in partners like Atempo, Data Dynamics, Cirrus Data, and Cirrata. The ISV software cost is covered by Azure. The honest tradeoff: Storage Mover assumes a reasonable network connection between the agent and the target. If the pipe is tiny and the dataset is huge, the math does not work and you should be ordering Data Box hardware. The session was clear about this, and that kind of “use the right tool” guidance is exactly what saves projects. Getting Started If you are kicking off a storage migration, here is the practical sequence. Stand up (or update) an Azure Migrate project and deploy the Migrate appliance on premises. If you already have one, just update to the latest version so file share discovery lights up automatically. Let discovery run, then create an Azure Files assessment scoped to the shares you care about. Pick your region, redundancy, performance look-back window, and percentile utilization. Export the results to Excel or PowerPoint and use it to build your business case. Decide online vs offline based on your dataset size and available bandwidth. Most projects can use Storage Mover. The biggest ones, or the ones with constrained WAN, start with Data Box seed data and then incremental sync with Storage Mover. For Storage Mover, create the resource, deploy the agent close to your data, register it, define endpoints, create a project and job definition, and start the job. Configure bandwidth schedules so your production traffic does not suffer. For specialized source-target pairs, reach out via the Storage Migration Program contact (azstoragemigration at microsoft.com) and engage a listed partner. Resources Azure Migrate file share assessment overview Azure Storage Mover documentation Azure Data Box documentation Azure Data Box overview (SKUs and capacities) Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre Roman
