Azure Elastic SAN — Simply Explained

Most Azure storage problems don't start with a big failure. They start with one virtual machine and one managed disk. It seems simple. Your VM needs a place for its operating system, app data or database files, so you attach a disk and forget about it. Then your company grows. More VMs show up, more databases need faster storage, and each machine gets its own set of disks, its own performance limits, and its own settings. Soon you find yourself paying for performance on quiet disks while one busy database waits for more capacity. That's the tricky part. You might be paying for storage speed you aren't even using while another workload can't borrow that spare capacity. Think of it like separate filing cabinets. Each one locked to its own worker with no way to borrow unused space. That's the problem Azure Elastic Sand is designed to solve. Azure Elastic Sand takes a different approach. It puts high performance block storage into a shared pool instead of locking it inside separate VM disks. But shared storage only saves money when your workloads use it the right way. So let's start with the old layout and see whether pressure builds. Why separate disks turn into a storage problem? Let's walk through a scenario. Imagine you run a small app on one Azure virtual machine. You attach a managed disk, choose a type in size, and the VM sees it like a local hard drive. For a single server that works well. It's easy to understand, easy to set up, and usually the right choice. But here's where things change. The trouble begins when that one server turns into a group of systems. Maybe you now run SQL Server for your main business app. You have app servers that write logs and process files. You have cluster nodes that need fast shared data. You may also have Kubernetes workloads that create and remove storage as app scale. None of these systems stay busy the same way. Your SQL database might work hard as that month end. A reporting server may spike early in the morning. A backup job can push large amounts of data overnight. Meanwhile, other disks sit mostly quiet. The goal is simple. Keep every workload fast enough when it needs storage. The obstacle, managed disks are usually planned one disk at a time, and each VM has a limit on how much disk work it can handle as a whole. So you'll often hear two terms in this conversation. Iops and throughput. Let's clear up what those mean. Iops stands for input and output operations per second. In plain English, it counts how many small read or write requests your storage can handle each second. A database often sends lots of small requests, reading a record, updating an order, checking an index. High Iops helps when many of those small jobs arrive quickly. throughput measures the amount of data that moves each second. Think of copying a large backup file or reading a huge report. You might not need a massive number of tiny requests, but you do need a wide enough pipe to move a lot of data. That's throughput, usually measured in megabytes per second, both matter, but different workloads need different mixes. And the challenge is that your workloads don't all fit the same pattern. Now, picture a company with rows of filing cabinets. Every employee gets their own cabinet, and each cabinet has a fixed number of drawers and a fixed speed for opening them. One person has a cabinet packed with urgent work. The cabinet beside it has empty drawers and no one touching it. Yet the busy person can't use that spare capacity because it belongs to someone else. That's what can happen with separate disks. You end up paying for a cabinet with extra drawers that nobody uses while another person struggles with a slow cabinet. You might choose a larger or faster disk for a database because it needs a short burst of performance once a day. For the rest of the day, much of that performance sits unused. Then you repeat that choice for another database, just in case it also gets busy. The bill grows from all that just in case performance. A common answer is fine, add more disks. Sometimes that helps. A VM can spread work across several disks and software inside the VM can combine them, but adding disks doesn't remove every limit. The VM itself still has a total disk iOps and throughput ceiling based on its size. The VM's disk limit acts like a bottleneck. No matter how fast the disk is, the road to the VM can only carry so much traffic. So you can buy faster disks, attach more of them, and still find that the VM can't push the amount of storage traffic you expected. That's frustrating because the storage may have room to work harder, but the route through the VM has reached its limit on premises data centers dealt with this for years through a storage area network or sand. Instead of treating every server storage like a private cabinet, teams built a central storage room that many servers could connect to. Azure Elastic Sand brings that shared room idea into Azure without asking you to buy storage controllers, wire up racks, or look after sand hardware. And that's why separate disks can turn into a real storage problem. What Azure Elastic Sand actually is? So what actually is Azure Elastic Sand? In plain English, it's managed block storage in Azure, designed as a shared pool for workloads that need fast storage. Here's a simple way to think about it. Imagine an office building with one central record's room. Inside that room, there are many locked drawers with clear labels. The finance team has its drawers, the sales system has its drawers, a database has its own drawers too. They keep their own files separate, but the building manages the room and it's available storage power in one place. The Elastic Sand works the same way. It's the central storage room. You create separate volumes inside it, and each volume acts like a block device that a workload can use as storage, a virtual machine sees that volume much like it sees a local disk, then formats it and stores data on it. Block storage means the workload reads and writes small chunks of data directly. That matters for systems like databases. SQL Server doesn't want to save a document in a shared folder and hope for the best. It needs controlled, fast reads and writes to data files, log files, and other pieces that keep the database running. Elastic Sand gives workloads that disc-like storage experience, but the storage connects over the network instead of attaching as a standard Azure managed disk. That connection uses something called ICSI. ISSI stands for Internet Small Computer Systems Interface, but don't worry about the full name. Think of it as a private route that carries storage commands between a server and the Elastic Sand. Your VM sends a request. Read this data block, write this database log entry, return this part of the file. The request travels over a dedicated network connection to the SAN and the SAN response. To the workload, it looks like another local disk. This doesn't mean Elastic Sand replaces every Azure storage service. Blob storage is built for objects like backups, images, and video files. It's more like a warehouse where you store named boxes. Azure files gives you shared folders that people and apps can access over a network. It behaves like a company file share. Managed disks are still the simple choice for many virtual machines that meet their own dedicated disk. Elastic SAN sits in a different part of the picture. It provides central high-performance block storage for workloads that benefit from sharing a larger storage pool. And because Azure runs the service, you don't manage the physical SAN equipment behind it. No storage racks to order, no controllers to replace, no physical cables between servers and the storage array. Azure handles the hardware behind the scenes while you configure the capacity, performance level, network path, and volumes your workloads need. The performance model is where this gets interesting. Elastic SAN includes base capacity, and that base capacity brings performance with it. For every one TIE-B of base capacity, the SAN receives 5,000 IOPS and 200 medabyte per second of throughput. These numbers belong to the SAN pool, not just one volume. So if you build a larger pool, you create more shared room for workloads that need fast reads and writes at different times. You still need to plan carefully because all workloads can't demand the full pool at once without consequences. But the storage isn't one giant disc that every app touches without structure. Azure divides it into layers, and the next layer explains how you keep related workloads organized and control who can connect. The three building blocks. SAN, volume groups, and volumes. Inside Azure Elastic SAN, you work with three layers, the SAN, volume groups, and volumes. Think of the SAN as the top-level storage space. This is where you set the overall capacity, total performance for the pool, and redundancy choice for the data. It's the main Azure resource you create before any workload connects. A SAN can hold many related storage volumes. That means you no longer need to treat every piece of storage as a separate thing with separate network settings and separate management work. You start with one larger storage resource, then organize its contents to match the teams and apps that use it. Under the SAN, you create volume groups. A volume group is a management boundary for related volumes. You might create one for production SQL Server workloads, another for test and development databases, and a third for an Azure Kubernetes Service or AKS environment. Those workloads can live in the same elastic SAN, but they don't need to share the same connection rules. For example, your production SQL servers might sit on one private network and your test servers on another. Instead of setting up network access over and over for every new database volume, you set the connection rules on the right volume group. Then the volumes inside that group follow those settings. That inheritance saves time when storage grows. Imagine a database team creates 10 new volumes over the next few months. If the volumes belong to the production SQL volume group, they can use the same approved network path and connection setup as the rest of that group. You don't rebuild the same access rules 10 times and hope every setting matches. It also makes ownership clearer. When someone opens the elastic SAN resource, they can see which area belongs to production, which to testing, and which to a container platform. Storage doesn't turn into a long, confusing list of volumes with names that only made sense to the person who created them. At the bottom layer, you have volumes. A volume is the actual block storage unit that a workload connects to. You create a volume with a size, place it inside a volume group, and then connected to an approved VM cluster or supported platform through ISCSI. A SQL server might use one volume for database files and another for transaction logs. An AKS storage setup may create volumes for application data that needs to persist even when a container restarts. A clustered workload may connect to storage designed for its shared storage pattern. Each volume remains its own separate storage unit. That point can confuse people. A shared SAN doesn't mean every workload writes into one huge common drive. Volumes keep data separate, and each volume has its own size and own performance limits. The SAN provides the wider pool. The volume defines what one workload can connect to and use, so there are limits at more than one level. A volume must be large enough for the data it holds, but it must also have the right size for the performance it needs. At the same time, the whole SAN must have enough total capacity and performance for all its volumes together. You can't create a tiny volume and expect it to behave like an unlimited storage device, just because it sits inside a large SAN. Access also stays private. You don't expose an elastic SAN volume to the public internet like a web page. You set up private network paths, then allow approved workload connections through the volume group. That gives you a clear boundary around who can reach the storage. So the structure is simple. The SAN is the overall resource. Volume groups organize workloads and apply shared connection rules. Volumes are the individual storage units that workloads use. That handles organization and access. The next part is what changes the design, how the available storage performance gets shared when different workloads needed at different times. How shared performance changes the design? Imagine you have four SQL databases in the same business. The sales database gets busy during the day while finance runs heavy reports near month end. A warehouse system works hardest overnight and another database barely moves except during a weekly import. With separate disks, each database needs enough performance for its own worst moment. That often means buying more speed than each disk uses most of the time. So the storage stays ready, but much of it sits idle. Elastic SAN changes that pattern because the volumes draw from a shared performance budget. If the finance volume needs more IOPS while the warehouse volume stays quiet, finance can use more of the SANs available pool. When the workload shifts later, the available performance can shift too. That can reduce waste, but it also changes what you need to monitor. Instead of looking only at one disk and one VM, you watch the whole say N because every volume connected to it can affect the others when demand rises at the same time. Managed disks use a different model. A disk has its own performance level and the VM has an overall limit for disk IOPS and throughput. Do you plan each server around those boundaries which gives clear isolation but can also force you to buy a larger VM or faster disks just to reach a storage target? Elastic SAN volumes connect over the network through ISCSI. That means they don't use the usual managed disk slots and they don't depend on the VM's normal disk throughput limits in the same way. Instead, the design depends on the SANs total performance, the performance limit of each volume and the network capacity between the workload and the SAN. So you've moved the limit, not removed it, a shared pool doesn't create unlimited storage speed. If several busy volumes ask for more IOPS and throughput then the SAN can supply Azure Throttles the extra work, request take longer and your apps may feel slower. The SAN needs enough headroom for the combined peak demand you expect. Each volume has limits too. It can reach up to 80,000 IOPS and 1,180 Mbps, but only when it's size, the SAN configuration and the connection setup supported. Notice that first part. When its size supports it. With Elastic SAN, a volume's possible performance rises with its size until it reaches the service limit. So if a workload needs very high IOPS you can't create a tiny volume and expect it to pull that much from the pool. Here's the thing, think of it like a loading dock. The whole building may have a large number of workers and trucks available, but a small loading bay only has room for so much activity at once. The SAN is the building's total capacity, the volume is the loading bay for one workload and both need enough room. Let's make that practical. A company runs several SQL server databases. One handles customer orders during business hours, another runs payroll every second Friday and a third receives large data imports overnight. With separate disks, the team might size all three for their individual peak even though those peaks rarely happen together. With Elastic SAN, they can measure the actual timing and size a shared pool around the likely combined demand. So one database can use more performance while the others stay quiet, without paying for the same unused peak capacity three times. But more storage performance won't repair every slow system. A poor SQL query can still scan far too much data and a missing index can still delay a report. A VM with two little CPU can still struggle and a weak network path can slow ISC-SI traffic before the SAN even gets a chance to help. Storage only fixes a storage problem. That's why planning starts with real measurements. Look at I/OPS, throughput, latency and when each workload gets busy. Base capacity gives your SAN its starting performance pool so adding capacity can also add more performance headroom. Watch the demand before you grow the pool. Shared performance can lower wasted spend but only when the workloads truly take turns using it. Where Elastic SAN fits and where it doesn't. Elastic SAN works best when you have several workloads that need fast block storage and their storage demand doesn't peak at the same time. A group of SQL server databases is a good example. You may have separate database servers for orders, reporting, finance and internal apps. They all need reliable storage but their busiest hours can differ, which gives a shared SAN room to work. It can also fit clustered SQL server designs including SQL server failover cluster instances which expect shared storage that more than one cluster node can reach. Elastic SAN gives you a managed Azure option for that familiar SAN pattern without asking you to build and run storage hardware yourself. For database teams moving workloads from an on-premises data center, this can feel more natural than redesigning every storage layout around separate VM disks. Azure VMWare solution is another strong use case. VMWare environments often use data stores and storage growth can become tied to adding more cluster hosts. With Elastic SAN, you can connect external ISCSI storage as a data store, meaning you can add storage capacity without automatically adding compute capacity that you may not need. That separation can matter when your virtual machines need more room for data but the AVS cluster already has enough CPU and memory. Kubernetes can use Elastic SAN too through supported storage designs. Containers come and go but some applications need data to remain after a container restarts. A database running in a container, for example, can't treat its data as temporary. So the storage design needs to match the Kubernetes platform, the application and the supported Azure connection method. Don't treat Elastic SAN as a generic container storage switch. Check the storage driver, access mode, network path and recovery design before you put an application into production because Kubernetes adds its own layer of rules and the storage needs to fit those rules. Data protection also comes into the picture. Elastic SAN supports point in time snapshots of volumes which record changes over time and can help you restore a volume or create a new volume from a recovery point. That can be useful when a database refresh goes wrong. A test environment needs a copy or a team needs to recover from a bad change. Still, a snapshot isn't the same thing as a complete backup plan. Your workload may need application-aware backups, copies kept for a longer period, recovery tests and a plan for a wider outage. A database can have data on storage that looks healthy while its transaction state still needs careful recovery so the storage layer can help but it can't decide that process for you. Azure also encrypts Elastic SAN data address and you can choose redundancy options based on what's available for your region and design while access stays on private network paths keeping storage traffic away from the public internet. Those controls reduce risk but they don't replace good network design or monitoring. So when does Elastic SAN not make sense? A small app server with one modest data disk usually doesn't need it and a simple VM with steady, low storage demand doesn't need it either. In those cases, manage disks remain easier to set up, easier to reason about and often cheaper. The same applies when a workload needs strict performance isolation. With a shared pool, you need to plan for other workloads using the same sense. So if one application must always have its own fixed storage performance and there's no wider group to share with, a dedicated managed disk design may be the cleaner choice. The cost rules stay simple. Pooling helps when many workloads can share capacity and performance but if you only need one small private disk, a shared SAN can add setup work and cost without giving you much back. So Elastic SAN doesn't remove the need for backups, network planning, workload testing or watching performance over time. It gives you a different storage model and whether that model fits depends on the workloads you place inside it. We'll explore each of these use cases in more detail in future episodes. So stay tuned. A simple way to decide. Grab a list of the workloads you already run. Note how much storage each one needs, its peak IOPS and throughput and when those busy periods actually hit. Don't guess based on one quiet day, pull monitoring data from normal operations, batch jobs, reporting cycles, and backups. That gives you the real picture. Now look for a pattern. Do you have several performance heavy workloads that all need block storage and do their busiest times avoid overlapping? If so, Elastic SAN is worth a closer look. Here's the real test. Compare it against the managed disk design you would otherwise build. Factor in disk charges, VM disk limits, the hours spent wrangling dozens of separate disks and all that performance you end up paying for, but never using. Before you commit, run a small test with one related workload group. Measure latency, IOPS, throughput and how the SAN handles total demand under realistic load. Test recovery too. Once the numbers back the design, you can scale from there. When the pattern fits, you end up with storage that's easier to organize and file a scatter across individual servers. That's the payoff. So what exactly is Azure Elastic SAN? It takes high performance block storage and turns it into a managed shared pool inside Azure. You create one SAN, organize access through volume groups and connect individual volumes to approved workloads over ISC ESI. This works well for groups of databases, clustered apps, VMware setups and supported container designs. Anywhere you need fast storage and the workloads can share performance sensibly. Your practical next step, pick one group of related database or clustered workloads, compare their combined peak demand against the separate managed disks they used today and check whether those peaks really overlap. If they don't, the pool approach wins. For everything else, Azure managed disks with a private disk per VM might still be the better fit.