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.