# Separate Elastic SAN capacity expansion from performance expansion

> Additional capacity increases storage space, while base capacity determines the SAN's shared IOPS and throughput pool.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-360-separate-elastic-san-capacity-expansion-from-performance-expansion/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:25:56+00:00
- Modified: 2026-09-10T02:01:56+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Additional capacity increases storage space, while base capacity determines the SAN's shared IOPS and throughput pool.

## Potentially affected

Azure Elastic SAN capacity planning for VM-connected volumes.

## DSE recommendation

Identify whether the shortfall is space, SAN performance, volume limits or VM limits before expanding capacity.

## Article

## Source facts

Elastic SAN distinguishes base capacity from additional capacity. Increasing additional capacity does not increase IOPS or throughput; the SAN’s performance pool grows with base capacity and is shared across its volumes.

Individual volumes have their own performance limits, and combined volume demand cannot exceed the SAN’s total IOPS and throughput. VM type and size introduce their own limits, so an application’s request can be throttled at more than one boundary. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-performance).

## Applicability

Record the actual SAN base and additional capacities, relevant volumes and connected VM types. Distinguish a need for more stored data from a need for more serviceable I/O.

## DSE recommendation

DSE recommends tracing the observed bottleneck before selecting an expansion. Compare concurrent workload demand with the shared SAN budget and each participating volume and VM limit. Do not justify additional-capacity expansion as an IOPS fix without evidence that the selected change addresses the limiting boundary. Review competing workloads together rather than treating each volume’s maximum as independently reserved performance.

## Verification

Use an approved representative workload to compare latency, throughput and IOPS before and after the chosen adjustment. Include the concurrent demand expected from other volumes. Retain the capacity split and relevant limits with the measurements. If the expected improvement does not occur, reassess the limiting layer instead of repeatedly adding storage space to a performance problem.

## Official references

[Microsoft Learn: Learn about Azure Elastic SAN and VM performance](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-performance). Source retrieved September 9, 2026.

## Primary reference

- Name: Learn about Azure Elastic SAN and VM performance | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-performance
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Separate Elastic SAN capacity expansion from performance expansion,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-360-separate-elastic-san-capacity-expansion-from-performance-expansion/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.