Azure 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 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 RomanJoin us at Microsoft Azure Infra Summit 2026 for deep technical Azure infrastructure content
Microsoft Azure Infra Summit 2026 is a free, engineering-led virtual event created for IT professionals, platform engineers, SREs, and infrastructure teams who want to go deeper on how Azure really works in production. It will take place May 19-21, 2026. This event is built for the people responsible for keeping systems running, making sound architecture decisions, and dealing with the operational realities that show up long after deployment day. Over the past year, one message has come through clearly from the community: infrastructure and operations audiences want more in-depth technical content. They want fewer surface-level overviews and more practical guidance from the engineers and experts who build, run, and support these systems every day. That is exactly what Azure Infra Summit aims to deliver. All content is created AND delivered by engineering, targeting folks working with Azure infrastructure and operating production environments. Who is this for: IT professionals, platform engineers, SREs, and infrastructure teams When: May 19-21, 2026 - 8:00 AM–1:00 PM Pacific Time, all 3 days Where: Online Virtual Cost: Free Level: Most sessions are advanced (L300-400). Register here: https://aka.ms/MAIS-Reg Built for the people who run workloads on Azure Azure Infra Summit is for the people who do more than deploy to Azure. It is for the people who run it. If your day involves uptime, patching, governance, monitoring, reliability, networking, identity, storage, or hybrid infrastructure, this event is for you. Whether you are an IT professional managing enterprise environments, a platform engineer designing landing zones, an Azure administrator, an architect, or an SRE responsible for resilience and operational excellence, you will find content built with your needs in mind. We are intentionally shaping this event around peer-to-peer technical learning. That means engineering-led sessions, practical examples, and candid discussion about architecture, failure modes, operational tradeoffs, and what breaks in production. The promise here is straightforward: less fluff, more infrastructure. What to expect Azure Infra Summit will feature deep technical content in the 300 to 400 level range, with sessions designed by engineering to help you build, operate, and optimize Azure infrastructure more effectively. The event will include a mix of live and pre-recorded sessions and live Q&A. Throughout the three days, we will dig into topics such as: Hybrid operations and management Networking at scale Storage, backup, and disaster recovery Observability, SLOs, and day-2 operations Confidential compute Architecture, automation, governance, and optimization in Azure Core environments And more… The goal is simple: to give you practical guidance you can take back to your environment and apply right away. We want attendees to leave with stronger mental models, a better understanding of how Azure behaves in the real world, and clearer patterns for designing and operating infrastructure with confidence. Why this event matters Infrastructure decisions have a long tail. The choices we make around architecture, operations, governance, and resilience show up later in the form of performance issues, outages, cost, complexity, and recovery challenges. That is why deep technical learning matters, and why events like this matter. Join us I hope you will join us for Microsoft Azure Infra Summit 2026, happening May 19-21, 2026. If you care about how Azure infrastructure behaves in the real world, and you want practical, engineering-led guidance on how to build, operate, and optimize it, this event was built for you. Register here: https://aka.ms/MAIS-Reg Cheers! Pierre RomanAutomating Large‑Scale Data Management with Azure Storage Actions
Azure Storage customers increasingly operate at massive scale, with millions or even billions of items distributed across multiple storage accounts. As the scale of the data increases, managing the data introduces a different set of challenges. In a recent episode of Azure Storage Talk, I sat down with Shashank, a Product Manager on the Azure Storage Actions team, to discuss how Azure Storage Actions helps customers automate common data management tasks without writing custom code or managing infrastructure. This post summarizes the key concepts, scenarios, and learnings from that conversation. Listen to the full conversation below. The Problem: Data Management at Scale Is Hard As storage estates grow, customers often need to: Apply retention or immutability policies for compliance Protect sensitive or important data from modification Optimize storage costs by tiering infrequently accessed data Add or clean up metadata (blob index tags) for discovery and downstream processing Today, many customers handle these needs by writing custom scripts or maintaining internal tooling. This approach requires significant engineering effort, ongoing maintenance, careful credential handling, and extensive testing, especially when operating across millions of item across multiple storage accounts. These challenges become more pronounced as data estates sprawl across regions and subscriptions. What Is Azure Storage Actions? Azure Storage Actions is a fully managed, serverless automation platform designed to perform routine data management operations at scale for: Azure Blob Storage Azure Data Lake Storage It allows customers to define condition-based logic and apply native storage operations such as tagging, tiering, deletion, or immutability, across large datasets without deploying or managing servers. Azure Storage Actions is built around two main concepts: Storage Tasks A storage task is an Azure Resource Manager (ARM) resource that defines: The conditions used to evaluate blobs (for example, file name, size, timestamps, or index tags) The actions to take when conditions are met (such as changing tiers, adding immutability, or modifying tags) The task definition is created once and centrally managed. Task Assignments A task assignment applies a storage task to one or more storage accounts. This allows the same logic to be reused without redefining it for each account. Each assignment can: Run once (for cleanup or one-off processing) Run on a recurring schedule Be scoped using container filters or excluded prefixes Walkthrough Scenario: Compliance and Cost Optimization During the episode, Shashank demonstrated a real-world scenario involving a storage account used by a legal team. The Goal Identify PDF files tagged as important Apply a time-based immutability policy to prevent tampering Move those files from the Hot tier to the Archive tier to reduce storage costs Add a new tag indicating the data is protected Move all other blobs to the Cool tier for cost efficiency The Traditional Approach Without Storage Actions, this would typically require: Writing scripts to iterate through blobs Handling credentials and permissions Testing logic on sample data Scaling execution safely across large datasets Maintaining and rerunning the scripts over time Using Azure Storage Actions With Storage Actions, the administrator: Defines conditions based on file extension and index tags Chains multiple actions (immutability, tiering, tagging) Uses a built-in preview capability to validate which blobs match the conditions Executes the task without provisioning infrastructure The entire workflow is authored declaratively in the Azure portal and executed by the platform. Visibility, Monitoring, and Auditability Azure Storage Actions provides built-in observability: Preview conditions allow customers to validate logic against a subset of blobs before execution Azure Monitor metrics track task runs, targeted objects, and successful operations Execution reports are generated as CSV files for each run, detailing: Blobs processed Actions performed Execution status for audit purposes This makes Storage Actions suitable for scenarios where traceability and review are important. Common Customer Use Cases Shashank shared several examples of how customers are using Azure Storage Actions today: Financial services: Applying immutability and retention policies to call recordings for compliance Airlines: Cost optimization by tiering or cleaning up blobs based on creation time or size Manufacturing: One-time processing to reset or remove blob index tags on IoT-generated data These scenarios range from recurring automation to one-off operational tasks. Getting Started and Sharing Feedback Azure Storage Actions is available in over 40 public Azure regions. To learn more, check out: Azure Storage Actions product page: https://azure.microsoft.com/en-us/products/storage-actions Azure Storage Actions public documentation: https://learn.microsoft.com/en-us/azure/storage-actions/storage-tasks/storage-task-quickstart-portal Azure Storage Actions pricing page: https://azure.microsoft.com/en-us/pricing/details/storage-actions/ For questions or feedback, the team can be reached at: storageactions@microsoft.com
MSLE Office Hours — French
Bienvenue à l'heure de permanence de MSLE animée par Cecilia, notre responsable de la communauté francophone de MSLE. Cette réunion vous offre l’opportunité de poser des questions, clarifier des concepts et recevoir des conseils personnalisés sur des sujets tels que le programme MSLE, l’intégration des cours de MSLE dans vos cours, l’exploration des parcours de certification et bien plus encore. Rejoignez l’heure de permanence iciAZ-500: Microsoft Azure Security Technologies Study Guide
The AZ-500 certification provides professionals with the skills and knowledge needed to secure Azure infrastructure, services, and data. The exam covers identity and access management, data protection, platform security, and governance in Azure. Learners can prepare for the exam with Microsoft's self-paced curriculum, instructor-led course, and documentation. The certification measures the learner’s knowledge of managing, monitoring, and implementing security for resources in Azure, multi-cloud, and hybrid environments. Azure Firewall, Key Vault, and Azure Active Directory are some of the topics covered in the exam.Lightbits for Azure VMware Solution
As users of Azure VMware Solution, we most likely will come across a time where we need to add storage and not necessarily need more compute from an additional host. Lightbits is another option in the Azure Marketplace to add storage that will scale and run storage intensive apps.Game of Learner Clinics for Data 2022
The Game of Learners Clinics for Data is a 5-week skilling initiative, which aims to help you learn and gain technical skills on how to work with data in the cloud. This Initiative will also provide you with the option to get to receive a free voucher to sit for the DP-900 Azure Data Fundamentals Exam. Register at https://aka.ms/dataclinics/registerBlobfuse is an open source project developed to provide a virtual filesystem backed by the Azure Blob storage.
First published on MSDN on Feb 20, 2019 Blobfuse uses the libfuse open source library to communicate with the Linux FUSE kernel module, and implements the filesystem operations using the Azure Storage Blob REST APIs.
