Azure VM ceiling explorer

Interactive companion

Which ceiling is lowest?

A Cloud Native Qumulo node on Azure inherits its performance ceilings from the Azure VM underneath it. Pick a size and a workload shape, and this page ranks the two published Azure ceilings that actually apply.

Read this first

These are Azure's published limits for the six storage-optimized VM series Qumulo supports on Azure — Lsv2, Lsv3, Lasv3, Lsv4, Lasv4 and Laosv4, 36 sizes in all from 2 to 96 vCPU — plus Microsoft's own Azure Virtual Machines list pricing. They are not Qumulo guidance and not a benchmark. Qumulo's Azure deployment path requires Qumulo Core 7.9.2 or later.

Azure ships new VM sizes regularly and Qumulo's supported list moves with them. For the most recently supported VM sizes and configurations, refer to Qumulo's guide to deploying Cloud Native Qumulo on Azure with Terraform and the provider's supported VM sizes reference before you size anything.

Pick a size and a workload shape

The Lsv4 series includes a 2-vCPU size. Nothing smaller than 8 vCPU is recommended for production workloads.

VM series
Size
Workload shape
 

    Network against the managed-disk path — floor-to-ceiling, across the series

    Converted to megabytes per second so they can be compared at all: published network megabits per second divided by eight, against the managed-disk column's floor–ceiling range — floor is the lower of what Qumulo's provider provisions and Azure's own published platform ceiling, ceiling is the higher of the two; see the limits below. The last column answers for the workload shape selected above, so it changes when that does.

    Scroll the table sideways to see every column.

    Size vCPU Network MB/s (per node) Uncached disk MB/s (floor–ceiling, per node) Disk floor as % of network Lowest published ceiling
    Mandatory caveat. This ratio is our arithmetic on Microsoft's published figures, not a Microsoft or Qumulo benchmark. Microsoft publishes network bandwidth and uncached disk throughput as separate limits with separate throttling metrics, and describes uncached disk I/O as provisioned against a per-VM, network-level allocation with its own prioritized channel — a related allocation, not a stated shared budget. Treat this as a planning heuristic for sizing, never as a performance model.

    The network curve across sizes

    Maximum network bandwidth, as published on each series page. The horizontal axis is vCPU count on a logarithmic scale, so equal steps are equal doublings — which is what makes a flat stretch look flat.

    Scroll the chart sideways to see the full range, or read the figures in the table below it.

      Lsv4, Lasv4 and Lsv3 publish identical network figures wherever their curves coincide, so those runs are drawn with different dash patterns rather than separated. Lasv3 is not plotted; its published network figures match Lsv3 at every shared size except 64 vCPU. Lsv2 tops out at 16 Gbps by 48 vCPU, well below the other series at the same size — a previous-generation ceiling, not a data error. Laosv4 reaches 50 Gbps at 32 vCPU, the highest figure of any series at that size. Azure publishes network bandwidth in megabits per second (Mbps) and disk throughput in megabytes per second (MB/s); this chart shows network in gigabits per second (Gbps), as the AWS and Google Cloud pages do.

      Show the plotted figures as a table

      Scroll the table sideways to see every series.

      The managed-disk curve across sizes

      A solid, marked line at the managed-disk floor — the lower of what Qumulo's provider provisions per node and Azure's own published platform ceiling for the disk column in use — and a faint, unmarked line at the higher of the two. The same floor/ceiling treatment as the network chart above, but for the candidate that actually has a range on this page: see the limits below for why network doesn't. The horizontal axis is vCPU count on a logarithmic scale, so equal steps are equal doublings.

      Scroll the chart sideways to see the full range, or read the figures in the table below it.

        The floor (solid, marked) is what's actually ranked elsewhere on this page; the ceiling (faint, unmarked) is the higher of the two figures. On every size shown, the floor is Azure's own published per-VM ceiling for whichever disk column applies — Ultra Disk / Premium SSD v2 where published, Premium SSD v1 otherwise, same fallback as the readout above — and the ceiling is what Qumulo's provider provisions, which is more than the VM can use. See card 2 in the readout above for the worked explanation on the size selected there.

        Show the plotted figures as a table

        Scroll the table sideways to see every series.

        What this page cannot tell you

        • Both paths are always in play. Qumulo's provider provisions uncached Azure managed disks — Premium SSD v2 when the cluster is deployed across availability zones, with explicit per-node IOPS/throughput targets — as the write cache, attached directly to every node; and it creates Storage accounts for persistent capacity, reached over the network. It is both, always, not an either/or choice: every write is modeled here as crossing the managed-disk ceiling on its way into cache. Two further points apply here too: client protocol write operations don't map one-to-one with the transactions that reach Qumulo's write cache (the filesystem scheduler can combine multiple queued writes into a single internal transaction, improving efficiency under sustained write load); and write-cache mirroring is not a fixed pairing between two nodes — Qumulo mirrors write-cache data across the cluster so majority quorum holds and the data survives, a durability/quorum mechanism rather than a data-placement one, which means a write can generate backend network traffic to more than one node, beyond what a single node's published ceilings describe.
        • The managed-disk figure is the lower of what Qumulo provisions and Azure's platform ceiling. The figure ranked on this page is whichever is lower — what Qumulo's provider actually provisions per node, or Azure's own published per-VM ceiling for the uncached disk column in use. On every size this page covers, Azure's per-VM ceiling is the lower of the two, so it is the figure that binds; what Qumulo provisions is higher, and is shown as the upper end of the managed-disk range as context only. See card 2 above for the worked figures on the size selected.
        • These are published Azure ceilings, not measured Cloud Native Qumulo results. Nothing on this page was benchmarked, by Microsoft, by Qumulo, or by us. A ceiling tells you what you cannot exceed. It does not tell you what you will get.
        • Every figure on this page — every card, chart and table — is per node, not cluster-aggregate. A Cloud Native Qumulo cluster is always more than one node, so cluster capacity is not simply this page's per-node ceiling multiplied by node count. Network is the closest to a clean multiplication, but even it isn't exact: CNQ spreads across a minimum of five Storage accounts, so aggregate ingress scales with account count rather than nodes, and write-cache mirroring rides the cluster for majority quorum rather than a fixed pairing between two nodes — both already covered above — which means a single write can generate backend traffic to more than one node's NIC. Size a node with this page; size a cluster with Qumulo.
        • A single-threaded or single-connection client will not see cluster-aggregate throughput. Cloud Native Qumulo is a distributed file system: reaching the aggregate performance a multi-node cluster is capable of requires concurrent operations — multiple threads, multiple connections, or multiple clients — spread across the cluster. A single client issuing serial, single-threaded I/O is bound by what one node (and one connection) can do, not by the cluster's combined ceilings. Size for the concurrency your workload actually generates, not just its total bytes or operations.
        • No public source maps Cloud Native Qumulo operations per second to core count. Cores do protocol handling, metadata work and data-protection math. How far that dial turns for your workload is something you have to measure, not read off a page.
        • Azure's storage account limits sit above your VMs and are region-tiered. In the regions on Microsoft's enumerated higher-throughput list — which includes East US — the default is 60 Gbps ingress / 200 Gbps egress; in regions not on that list it's 25 Gbps / 50 Gbps. Both are defaults raisable by support request. CNQ spreads across a minimum of five storage accounts, so the aggregate ingress budget scales with account count, not with a single account's limit.
        • The write cache is on managed disk; the read cache is inferred. Qumulo's provider places the write cache on uncached Azure managed disks, provisioned per node with explicit IOPS/throughput targets — never the VM's local NVMe, which serves the read cache instead. But two shapes on this page (read-stream, read-miss) depend on local NVMe serving as the read cache, and Qumulo does not state that role directly for Azure — it is inferred from the VM specification.
        • The write-cache disk type depends on how the cluster is deployed, and this page models only one of the two. Deployed across availability zones, Qumulo's provider provisions Premium SSD v2 write-cache disks with explicit IOPS and throughput for each VM size — the path every figure on this page assumes. Without availability zones, nodes use 256 GiB P15 Premium SSD disks instead, a materially different path with fixed rather than provisioned per-disk performance, so the write-cache numbers this page ranks would not apply. Confirm which configuration a given deployment uses before sizing against the managed-disk figures above.
        • The network-against-disk ratio is our arithmetic — Microsoft doesn't publish the comparison. Its own wording is more nuanced than "one shared NIC": Azure describes uncached disk I/O as provisioned through a VM network-level stage, with a prioritized channel for disk traffic that takes precedence over low-priority network traffic. That implies a shared underlying path, but Microsoft does not state that the two compete for a single budget, and publishes them as separate limits with separate throttling metrics.
        • Accelerated networking is on unconditionally; a proximity placement group applies in single-AZ deployments. This means the published NIC figure ranked above is actually the one a real deployment can reach, not a ceiling gated behind an unconfigured feature.
        • All local-NVMe generations carry the same boilerplate "best case" caveat. But the steady-state write guidance genuinely differs: the v2 and v3 generations only say writes will underperform reads, without quantifying against the published number. Lsv4 is more specific — it says writes will underperform the published spec itself, and explicitly ties that shortfall to device fill state. Lsv4 also publishes separate read/write figures where the v2 and v3 generations publish one combined number, which is presumably why Lsv4 can make the more specific claim.
        • Ultra Disk and Premium SSD v2 columns are inconsistent across the family. Of the six series on this page, Lsv4 is the only one that publishes higher values than Premium SSD v1; Lasv4 and Laosv4 publish identical values; Lsv3's column equals its own non-burst Premium SSD v1 values; Lasv3 publishes no such column at all. Lsv2's column repeats that size's local NVMe figures exactly, so this page falls back to Lsv2's Premium SSD v1 figures instead. A planner who generalizes from one series page will be wrong about the others.
        • Every price here is VM compute only. It is the lease on the machine. Persistent storage, any managed disks and egress are billed separately and are not in these figures.
        • Prices move, and these are list rates. Every price here is East US, Linux, pay-as-you-go, pulled from the Azure Retail Prices API on 19-Oct-2026. Monthly figures are hourly multiplied by 730 — our arithmetic, not a Microsoft-published figure. Reserved Instances and negotiated agreements land materially lower.