Cut 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 RomanNetwork Security Perimeter for Azure Event Hubs: Hardening Your Data Streams
What is Network Security Perimeter for Azure Event Hubs? Azure Event Hubs now supports Network Security Perimeter (NSP), a logical network isolation boundary that lets you define a security perimeter around your PaaS resources and control public network access through perimeter-based access rules. In practical terms, this means you can now group Event Hubs resources within a perimeter, apply consistent network access policies across them, and prevent unauthorized inbound traffic at the PaaS boundary level. It's not a firewall replacement, it's a compliance and segmentation tool that works alongside your existing NSGs and private endpoints. Before NSP, managing network access to Event Hubs involved: Private endpoints (which route traffic over private networks) IP firewall rules (which block public access from specific CIDR blocks) Virtual Network Service Endpoints (which restrict traffic to VNets) Network Security Perimeter adds a declarative, organization-wide layer: you define which resources belong inside the perimeter, and then manage access rules once, and those policies apply consistently across all perimeter members. Changes to the perimeter automatically cascade to all enrolled resources. Why ITPros Should Care If you're managing Event Hubs in a regulated industry like healthcare, finance, or government, you know the pressure. Compliance auditors want proof that data pipelines are segmented, isolated, and protected from lateral movement. Network Security Perimeter directly addresses that. Operational Value Network Security Perimeter delivers three immediate operational wins: Single Source of Truth for Access Rules. Instead of managing firewall rules on each Event Hubs namespace independently, you manage rules once at the perimeter level. Reduce configuration drift, reduce the attack surface, reduce human error. Compliance and Audit Readiness. Demonstrate network isolation to auditors with a clear diagram: "All Event Hubs in the perimeter are protected by these rules." That narrative matters for SOC 2, FedRAMP, HIPAA, and PCI-DSS compliance. You can export perimeter configurations and attach them to compliance documentation. Simplified Onboarding. When a new Event Hubs namespace joins the organization, add it to the perimeter and it inherits all access rules automatically. No manual rule-by-rule configuration. No weeks of back-and-forth with security teams. Secondary benefits include: Reduced blast radius during incidents, if an application is compromised, perimeter rules limit what it can access. Simplified network topology diagrams for architecture reviews. Faster mean time to remediation (MTTR) when security issues arise. Real-World Example: Securing a Multi-Tenant Event Hub Deployment Let's walk through a practical scenario. You're an ITPro at a financial services firm. You have three Event Hubs namespaces: hubs-prod-transactions (production trading data) hubs-prod-compliance (regulatory event streams) hubs-staging-dev (development and testing) Your security policy mandates: Production namespaces should only accept traffic from specific applications (IP-restricted). Staging can accept traffic from developer VNets but not from the internet. All outbound access to external services must be logged and monitored. Step 1: Define Your Perimeter First, create a Network Security Perimeter in the Azure Portal or via Azure CLI: az network perimeter create --resource-group rg-security --name nsp-financialservices --location eastus This creates the perimeter container. Think of it as a logical security zone. Step 2: Enroll Event Hubs Resources Add your Event Hubs namespaces to the perimeter: az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-prod-apps --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.0.0.0/8 --destination-port-range 5671-5672 Enroll the Event Hubs namespace: az network perimeter resource create --resource-group rg-security --perimeter-name nsp-financialservices --resource-name hubs-prod-transactions --resource-type "Microsoft.EventHub/namespaces" You've now enrolled your production Event Hubs namespace. It inherits the "allow-prod-apps" rule, only traffic from your internal VNET (10.0.0.0/8) is permitted. Step 3: Define Access Rules $ns = "hubs-prod-transactions" $hub = "transactions-hub" $key = (az eventhubs namespace authorization-rule keys list --resource-group rg-prod --namespace-name $ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv) Create rules that reflect your security policy. Allow internal compliance applications: az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name allow-compliance-writers --direction Inbound --access Allow --protocols Tcp --source-address-prefix 10.50.0.0/16 --destination-port-range 5671-5672 Deny all other public traffic: az network perimeter access-rule create --resource-group rg-security --perimeter-name nsp-financialservices --name deny-internet --direction Inbound --access Deny --protocols "*" --source-address-prefix "*" --destination-port-range "*" Now your Event Hubs accept traffic only from specific internal subnets. Everything else is rejected at the PaaS boundary. Step 4: Validate Connectivity Test that legitimate applications can still reach Event Hubs: $ns = "hubs-prod-transactions" $hub = "transactions-hub" $key = (az eventhubs namespace authorization-rule keys list --resource-group rg-prod --namespace-name $ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv) Check logs in Azure Monitor: az monitor log-analytics query --workspace $(az monitor log-analytics workspace list --query "[0].id" -o tsv) --analytics-query "AzureDiagnostics | where ResourceProvider=='MICROSOFT.EVENTHUB' | summarize by NetworkSecurityPerimeter_s" If you see accepted connections logged with your perimeter name, you're good. If you see denied connections from unexpected IPs, you've caught a security issue before it impacts production. Step 5: Monitor and Alert Set up alerts for denied traffic: az monitor metrics alert create --name "NSP-Denied-Connections" --resource-group rg-security --scopes /subscriptions/{subId}/resourceGroups/rg-security/providers/Microsoft.Network/networkSecurityPerimeters/nsp-financialservices --condition "avg ConnectionRejectedCount > 5" --window-size 5m --evaluation-frequency 1m --action email-admin@company.com Now you'll be notified if someone attempts to access Event Hubs from an unauthorized source. Your security posture just went from reactive to proactive. Technical Details: How NSP Works Under the Hood Perimeter Architecture Network Security Perimeter operates at the Azure platform level, not in your VNets. Here's the flow: Connection arrives at Event Hubs public IP. Azure evaluates the source IP/protocol against NSP rules. If allowed, connection is routed to the namespace. If denied, connection is dropped and logged. This happens before TLS handshake, reducing CPU overhead and improving response times. Denied connections generate zero namespace load. Rule Evaluation Order NSP rules are evaluated in this order: Explicit Allow rules (matched first wins) Explicit Deny rules Implicit Deny (default action) Best practice: Create your Allow rules first (be specific about what you permit), then add Deny rules for anything not explicitly allowed. This ensures you don't accidentally block legitimate traffic. Integration with Existing Security Tools NSP works alongside (not instead of): Private Endpoints: NSP adds a policy layer; private endpoints route traffic over Azure backbone. Use both. IP Firewall: NSP provides namespace-level access control; IP firewall is still available for per-namespace rules. VNet Service Endpoints: NSP complements VNet endpoints by adding perimeter-wide policies. Managed Identity + RBAC: NSP is transport-layer security; identity-based access control remains separate. Performance Considerations NSP introduces minimal latency (<1ms typically). Azure evaluates rules in parallel and caches common decisions. For high-throughput Event Hubs: Keep rules simple and specific (avoid wildcard ranges if possible). Use CIDR blocks instead of individual IPs where applicable. Monitor connection acceptance rates in Azure Monitor. Comprehensive Resources Official Microsoft Documentation: Network Security Perimeter Overview Event Hubs Network Security Configuring NSP for Event Hubs Azure CLI: az network perimeter Azure RBAC for Event Hubs Azure Event Hubs Protocol Guide Closing: Perimeter Security for Modern Data Streams Network Security Perimeter for Event Hubs is a quiet but powerful addition to Azure's security toolkit. You get the ability to enforce organization-wide network policies without having to reconfigure every namespace individually. You can demonstrate perimeter-based isolation to auditors. You can catch lateral-movement attacks before they happen. For ITPros managing event-driven architectures, message processors, IoT data streams, financial transactions, this capability directly improves your security posture and reduces operational overhead. I encourage you to: Audit your current Event Hubs deployments. How many namespaces? How many security policies are you managing today? Design your perimeter boundaries. Group namespaces by security zone (prod, staging, dev) or by business unit. Start with one perimeter in a dev environment. Define rules. Validate connectivity. Then expand to staging and production. Document your perimeter architecture and rules. Include it in your security runbook and architecture reviews. Set up monitoring and alerting. Denied connections are a leading indicator of either misconfiguration or attack attempts. The networking challenges in cloud are complex. Network Security Perimeter gives you a declarative, policy-driven way to solve them at scale. Take advantage of it, and let me know how it changes your security workflows. Keep your networks hardened, and your data flowing safe. Cheers! Pierre RomanAz Update - Week 2 of the return editions
Hello Folks! This week's updates all focus on something we hear from IT pros and platform engineers all the time: How do we make our environments more secure, more manageable, and easier to modernize without adding more complexity? Whether you're running PostgreSQL workloads in Azure, securing Kubernetes storage, or planning your next wave of SQL Server migrations, this week's announcements bring practical improvements that can help reduce operational overhead while strengthening your overall platform strategy. We'll look at three newly available capabilities: Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS) Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines As always, I'm approaching these updates from an infrastructure and operations perspective. I'll cover why each capability matters, what to watch out for before production deployment, and some practical steps you can take to start evaluating them in your own environment. Let's dig in. Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server Why ITPros should care This release brings automated security posture assessment directly into managed PostgreSQL environments. For ITPros, this matters because database security is often treated separately from infrastructure security tooling, creating blind spots and silos. What changed is that Defender now runs native vulnerability scanning and compliance checks against PostgreSQL configurations, patches, and the ways a database could be exposed to security risks or attack opportunities. Instead of relying on external scanners or manual audits, you get platform-native assessments integrated with your existing Defender workflows. The operational impact is significant: you can now enforce security baselines at the database layer with the same consistency you apply to VMs and network resources, reducing the gap between infrastructure and data security accountability. Operational value Operationally, this improves your security baseline enforcement and reduces the need for separate database security assessment tools. It also strengthens how well you can demonstrate and prove that security controls are in place and working for compliance reviews where regulators expect consistent, documented security controls. Before production rollout, validate that Defender cost models fit your budget, that assessment frequency aligns with your change windows, and that remediation guidance maps to your patch and maintenance processes. Prerequisites include enabling Microsoft Defender for Cloud, registering the PostgreSQL Flexible Server provider, and ensuring network connectivity so assessments can reach the database endpoint. Real-world example with step-by-step guidance Enable Microsoft Defender for Cloud if not already active, and ensure PostgreSQL Flexible Server subscription coverage. Register the target PostgreSQL Flexible Server instances and confirm Defender has network visibility to the database endpoints. Run a baseline assessment and review initial findings to understand current security posture and common remediation patterns. Prioritise findings by severity and business impact, then schedule patches and configuration changes in maintenance windows. Monitor ongoing assessments and track remediation progress through Defender dashboards, validating that fixes reduce exposure scores. Technical details including code examples This example validates that Defender is actively assessing your PostgreSQL estate. The sequence checks Defender status, confirms PostgreSQL registration, and retrieves current assessment scores. Run these queries in a pilot subscription first to understand data structure and expected output before scaling to production databases. az account set --subscription <subscriptionId> az security sql-vulnerability-assessment baseline show --resource-group <rg> --server-name <postgresServer> --database-name <databaseName> az security pricing show --subscription <subscriptionId> --query "[?name=='VirtualMachines' || name=='SqlServers' || name=='StorageAccounts'].[name,pricingTier]" -o table az provider show --namespace Microsoft.DBforPostgreSQL --query "registrationState" -o tsv Expected behaviour: Defender status shows active, PostgreSQL instances are registered with the provider, and pricing tier reflects your coverage level. If assessments do not run, check network rules, managed identity permissions, and Defender plan activation. If baseline data is missing, trigger a manual scan and wait for completion. Comprehensive Resources Azure update: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server Microsoft Defender for Cloud overview Azure Database for PostgreSQL security SQL vulnerability assessments in Defender for Cloud Enable Defender for Cloud Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS) Why ITPros should care This release closes a significant gap in data protection for Kubernetes workloads consuming NFS shares from Azure Files. Previously, NFS traffic between AKS nodes and Azure Files was unencrypted, creating compliance and security risks for sensitive workloads. What changed is that you can now enforce encryption for NFS communication at the Azure Files layer, not just at the application layer. This is important because traditional NFS lacks built-in encryption, and relying on network isolation alone is increasingly insufficient. For ITPros managing regulated workloads (healthcare, finance, PII-sensitive data), this removes a control gap. Encryption in transit now becomes a platform-native feature instead of a workaround, reducing architecture complexity and improving auditability. Operational value The operational value is stronger compliance posture and reduced attack surface for data in motion between containers and storage. It also simplifies the security story when auditors ask about data protection controls. Before enabling in production, validate that NFS-over-TLS introduces acceptable latency overhead for your workload patterns, test failover and reconnection behaviour under encryption, and confirm that monitoring and logging still work correctly. Prerequisites include running AKS with Azure CNI or Kubenet networking, having Azure Files with NFS 4.1 enabled, and ensuring the NFS client libraries on container images support TLS. Real-world example with step-by-step guidance Create an Azure Files NFS share with encryption in transit enabled and confirm TLS version alignment with your security standards. Deploy a test AKS workload that mounts the NFS share and validate that pods mount successfully with encrypted traffic. Run performance baselines (throughput, latency, CPU overhead) before and after enabling encryption to document operational expectations. Monitor pod logs and Azure Files metrics during the test to confirm no silent failures or unexpected throttling occurs. Roll out to production workloads in stages, with clear rollback criteria tied to application latency and error rates. Technical details including code examples This example validates that your AKS cluster can successfully mount NFS shares with encryption enabled. The sequence checks cluster networking, confirms NFS connectivity, and tests mount success. Run these commands in a non-production cluster first to validate environment readiness before touching production storage. az aks show --resource-group <rg> --name <clusterName> --query "networkProfile.{networkPlugin:networkPlugin,networkPolicy:networkPolicy,podCidr:podCidr}" -o jsonc az storage account show --resource-group <rg> --name <storageAccount> --query "{name:name,kind:kind,accessTier:accessTier}" -o jsonc kubectl get pvc -A --all-namespaces -o wide kubectl describe pv <pvName> | grep -i nfs Expected behaviour: cluster networking is properly configured, storage account kind supports NFS, and PVC/PV resources show NFS mount points. If mounts fail, check network security group rules, storage account firewall allowances, and subnet delegation. If latency increases, monitor resource utilisation and adjust workload placement if needed. Comprehensive Resources Azure update: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS) Azure Files NFS support Mount Azure Files with NFS in AKS Azure storage security AKS networking concepts Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines Why ITPros should care This capability brings SQL Server migration into the Azure Arc operational footprint, creating a unified migration and inventory experience. For ITPros, this matters because SQL Server modernisation is often fragmented across multiple tools and teams. What changed is that you can now discover, assess, and execute SQL migrations through Arc-native workflows, using the same permissions and governance model you already have for infrastructure and hybrid resources. The operational gain is consistency: discovery data feeds migration planning, assessments surface blockers early, and rollout can be controlled through the same change and approvals processes you use for other infrastructure migrations. Operational value Operationally, this reduces tooling sprawl and improves coordination between infrastructure and database teams. Arc becomes your single control plane for tracking migration progress, managing runbooks, and collecting audit evidence. Before production use, validate that your SQL Server inventory is complete, that migration blockers are understood and addressed, and that your maintenance windows can accommodate expected cutover timings. Prerequisites include Azure Arc agent deployment on source VMs, Azure Database Migration Service readiness, and network connectivity to target Azure SQL resources. Real-world example with step-by-step guidance Deploy Azure Arc agents to SQL Server VMs and confirm all instances report healthy status with complete inventory data. Run Arc-integrated SQL Server assessments to identify compatibility issues, dependencies, and recommended migration targets. Pilot migration for a non-critical workload to establish runbook patterns, measure cutover time, and validate post-migration validation procedures. Execute validation tests: connectivity, login success, database consistency checks, job execution, and application integration tests. Scale migration in waves using documented runbooks, with gates for monitoring data health and application performance after each cutover. Technical details including code examples This example validates Arc agent health and SQL Server discovery completeness. The sequence ensures your Arc infrastructure is ready for migration workflows. Run these commands as part of your pre-migration checklist to catch configuration gaps before committing to migration timelines. az account show --output table az connectedmachine list --resource-group <rg> --query "[].{name:name,status:status,osName:osName}" -o table az resource list --resource-type Microsoft.AzureArcData/sqlServerInstances --query "[].{name:name,resourceGroup:resourceGroup,location:location}" -o table az connectedmachine machine extension list --resource-group <rg> --machine-name <vmName> --query "[].{name:name,provisioningState:provisioningState}" -o table Expected behaviour: Arc agents report healthy status, SQL Server instances are fully discovered with accurate inventory, and required extensions are provisioned successfully. If discovery is incomplete, check Arc agent connectivity, extension deployment, and SQL service running status on source VMs. If migration pre-checks fail, verify SQL Server version compatibility and review Defender logs for blocking issues. Comprehensive Resources Azure update: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines Azure Arc SQL Server Overview Azure Arc-enabled servers SQL Server on Azure Virtual Machines Azure Database Migration Service For any new capability this week, if they map to your operational roadmap, run a controlled pilot, measure the impact, and then scale with confidence. That is how you move the needle on modernisation while managing risk. 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 RomanPlanning the Monitoring of my hybrid environment.
Hello folks, By now you may have read that I’ve rebuilt my demo environment to look like what a typical hybrid environment would look like. I did it slowly without having to rip and replace everything in my on-prem environment. Started out with establishing a site-to-site VPN, then a solution to remote into all the servers in my environment, configured a resilient way of resolving the names of all servers in my hybrid deployment, and lastly, configuring an Azure Arc Private Link Scope so that all my on-prem machines could connect to Azure using the VPN and not the open internet. Now as I look at all the operational tasks I need to implement (monitoring/insights, patch management, change management, etc...) To support all these operational requirements, I need the common underpinning provided by the Azure Log Analytics workspace.Modernize 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 RomanBuild and Optimize a Data Lakehouse for Unified Data Intelligence
Hello Folks! Welcome back to the ITOpsTalk Blog and the Microsoft Azure Infrastructure Summit 2026 series. In this session James Baker and Sai Runtham, both from the Azure Data Lake Storage product team, take us through what a modern Lakehouse actually is, how to design one on Azure, and then they roll up their sleeves and build one end to end. If you have been hearing “Lakehouse” thrown around in architecture reviews and were not 100% sure what it changes for you as an IT Pro, this one is for you. 📺 Watch the session: Why IT Pros Should Care You might be thinking, “I run infrastructure, not analytics.” Fair point. But here is the thing. The lakehouse is increasingly the platform your business will run BI dashboards, AI agents, and decision support systems on, and you are the one who has to keep the data safe, governed, and reachable. Here is what is in it for you: It is a platform conversation. James spends a big chunk of the session on horizontal platform capabilities (storage, catalog, identity, secrets, network, policy) versus vertical pipeline concerns. That is squarely an IT Pro problem. Data is the asset. Workspaces, query engines, and dashboards are transient. The data lives forever, and protecting it is on your plate. Governance is what stops your data lake from rotting into a data swamp. Scale is a virtuous cycle. More data drives more insight, which drives more data. Your platform cannot become the ceiling. AI agents are the new consumers. They do not just read dashboards, they query gold tables directly. Your network, identity, and access controls have to keep up. What is a data lakehouse A data lakehouse is exactly what it sounds like. You take the cheap, flexible, schema-light scale of a data lake, and you fuse it with the low-latency query performance, update semantics, and governance of a data warehouse. One copy of the data. One place to govern it. No more forking from the lake into a warehouse just to make BI tools happy. Quick contrast: Data lake. Big, cheap, flexible. No schema enforced on write. Historically prone to becoming a swamp. Data warehouse. Low-latency queries, updates, strong governance, structured. Hits a scale ceiling and costs more. Data lakehouse. Lake-scale storage, with a high-performance query layer and warehouse-grade governance sitting over the top. No data fork. The big shift is that the data does not move. Your BI dashboards, your AI agents, your serverless SQL queries, they all hit the same governed tables in the lake. That keeps lineage clean and your security model sane. Building it on Azure James and Sai are clear that the architecture is less a fixed diagram and more a list of platform capabilities you compose. Here is the shape of it on Azure. Storage layer (the asset). Azure Data Lake Storage Gen2 (ADLS) with hierarchical namespace turned on. That is non-negotiable for analytics workloads. It gives you atomic directory operations, POSIX-style ACLs, and the performance Delta Lake relies on. OneLake in Microsoft Fabric if you want a tenant-wide logical lake that is built on ADLS Gen2 and stores everything in open Delta Parquet by default. Table format and pipelines. Open table formats: Delta Lake (and Apache Iceberg as it converges) give you ACID transactions, time travel, schema evolution, and streaming on cheap object storage. Azure Databricks Lakeflow Declarative Pipelines with Autoloader for incremental ingestion of both batch and streaming sources straight into Delta tables. Autoloader handles new file discovery, schema inference, and evolution for you. The medallion architecture for stamping out repeatable pipelines: o Bronze. Raw, append-only landing zone. Source of truth. o Silver. Cleansed, deduplicated, conformed, enriched. o Gold. Business-ready, aggregated, performance-optimized for consumption. Governance and identity. Unity Catalog as the single source of truth for catalog, lineage, and fine-grained access control across bronze, silver, and gold. Entra ID for identity. Managed identities for compute. Key Vault for secrets. Network protection around the perimeter. The data is the crown jewel, so private endpoints, firewalls, and VNet-attached compute are baseline. Consumption layer. Power BI Direct Query against a serverless SQL warehouse on the gold tables. No data copies, governance flows through. AI agents like Databricks Genie pointed at gold tables. Natural-language questions, live lineage, no data movement. The demo that ties it together. Sai walked through a real pipeline: NYC TLC taxi trips enriched with NOAA weather and ESPN/MLB sports events, ingested by Autoloader into bronze, transformed through silver, aggregated into gold. A parallel streaming pipeline handled synthetic live events for a real-time demand view. Power BI dashboards hit gold via Direct Query. And Genie answered questions like “which zones are most sensitive to sport events” by mapping demand around Madison Square Garden, with the query and the chart generated for you. All against the same lakehouse, no data movement, full lineage. Optimizing for cost and performance This is where a lot of lakehouses go sideways. A few things from the session and from the official guidance worth pinning to your wall: Get hierarchical namespace right. It is the difference between atomic directory operations and “copy then delete,” which is slow and expensive at scale. Use storage tiers and lifecycle policies. Hot for working data, Cool or Cold for older partitions, Archive for compliance retention. Lifecycle rules on ADLS do this automatically. Partition and file-size matter. Lots of tiny files kill query performance. Use OPTIMIZE, Z-Order, or liquid clustering on Delta tables, and partition on the columns your queries actually filter on. Lean on vectorized reads. ADLS plus Delta plus modern query engines push a lot of work down to columnar Parquet, which keeps your compute bill in check. Use serverless SQL warehouses where it fits. Direct Query against a serverless endpoint scales compute to demand and lets you keep dashboards fresh without import refreshes. Observe data, not just systems. “Is Databricks up” is necessary but not sufficient. Watch data freshness, row counts, pipeline blockages, and SLAs on the data itself. Govern everything. A well-governed lakehouse drives trust, which drives use, which drives value. Skipping governance early always costs more later. Getting Started If you want to put hands on a keyboard this week: Spin up an Azure Storage account with hierarchical namespace enabled. That is your ADLS Gen2 foundation. Stand up an Azure Databricks workspace, enable Unity Catalog, and point it at your ADLS account. Create a Lakeflow Declarative Pipeline. Use Autoloader to ingest a sample dataset (the NYC taxi data is a classic starting point) into a bronze Delta table. Add silver and gold notebooks or pipelines that clean and aggregate the data. Connect Power BI to a serverless SQL warehouse on your gold tables with Direct Query. If you are a Fabric tenant, mirror or shortcut data into OneLake and try the same pattern there, no infra to manage. Read the Hitchhiker’s Guide to ADLS before you scale up. It will save you future you a lot of grief. Resources Introduction to Azure Data Lake Storage The Hitchhiker’s Guide to the Data Lake Microsoft OneLake documentation Azure Databricks documentation Delta Lake on Azure Databricks Design Delta Lake architecture and medallion patterns Implement medallion lakehouse architecture in Microsoft Fabric Watch the rest of the Summit This session is one stop on a big tour. The full Microsoft Azure Infrastructure Summit 2026 playlist covers everything from sovereign cloud and AKS networking to backup, storage, and AI-assisted operations. If your job touches Azure, there is something in here for you. Head over to the full playlist and binge what is useful: https://www.youtube.com/playlist?list=PLjt5SKzX1iI8con7FJDB56G6hHqxGm7ki Cheers! Pierre Roman
