Microsoft announced general availability of the Lasv5 and Laosv5 storage-optimized Azure VM series on September 29, 2026. Both use fifth-generation AMD EPYC processors and target workloads that need substantial local NVMe storage. Read the Azure GA announcement.
This is the general-availability milestone following the private preview previously covered on this blog. For engineers evaluating these families, the decision now needs to connect storage density with the way the application survives a node replacement.
My recommendation: benchmark the complete workload and rehearse recovery before using the headline capacity to consolidate a cluster.
Two Families with Different Storage Density
Microsoft's launch article lists up to 30.7 TB of local storage for Lasv5 and up to 138 TB for Laosv5, with maximum network bandwidth of 200 Gbps. These are series-level maxima, not specifications that apply to every size. Launch details.
The size tables provide the per-SKU configuration. For example, Standard_L16as_v5 lists one 3,840 GB local disk, while the Laosv5 family offers a denser local-storage profile. Lasv5 specifications and Laosv5 specifications.
I would begin with the workload's working set, replication policy, memory requirement, and expected growth. Select a candidate size from those requirements, then check its actual disk, network, and remote-storage limits together.
Avoid building a sizing spreadsheet that combines the smallest VM's cost with the largest VM's performance. Every proposed configuration should identify an exact SKU and its relevant limits.
Local NVMe Is Not a Durability Strategy
The series documentation describes this capacity as local temporary storage. Microsoft's NVMe guidance distinguishes transient local disks from persistent remote storage: local data can disappear. Local-storage specifications and temporary NVMe guidance.
My proposed architecture review asks which data can be reconstructed and which data is authoritative. Document the source of truth, the replication or restore process, and the condition that makes a replacement node ready to serve requests.
For a hypothetical cache tier, a node with an empty cache should have a planned warm-up behavior. For a distributed database, the application team should explain how the cluster maintains its intended guarantees while a node is unavailable and being rebuilt.
Do not interpret encryption as persistence. Protecting data from unauthorized access and recovering data after storage loss are separate responsibilities.
Benchmark Steady-State Work, Not Only Fresh Disks
The Lasv5 documentation explicitly describes its temporary-disk performance figures as best-case numbers. It notes that block size, read/write patterns, queue depth, and device state matter, and that steady-state write performance is lower than the published clean-device figures. Performance assumptions.
For my evaluation, I would use the application's real mixture of reads, writes, and background work with approved test data. Record response-time percentiles and completed application operations alongside infrastructure metrics.
Run long enough to observe the behavior that matters to the service, including compaction, indexing, checkpoints, or cache churn where applicable. State the test conditions so that another engineer can repeat the comparison.
Keep the result separate from Microsoft's launch claims. A published maximum is a useful configuration reference, not a benchmark result for your database or search workload.
Measure the Cost of Losing One Large Node
My proposed failure exercise starts with a disposable nonproduction node and a known-good source of recoverable data. Measure how long replacement, data reconstruction, and return to normal service take.
Watch the surviving nodes during that interval. A design may meet its normal throughput target but leave too little headroom to rebuild while serving requests.
Compare the proposed node count as well as the VM size. Consolidating into fewer, denser nodes changes the amount of work the remaining cluster must absorb when one is absent.
Write down the acceptance threshold before the test. The desired outcome is a configuration that meets both steady-state and recovery requirements, not merely the smallest fleet that can pass a healthy-state demonstration.
Availability Belongs in the Design Record
At launch, Microsoft listed Lasv5 in North Europe, South Central US, West Europe, West US 2, and West US 3, and Laosv5 in East US. Treat that as the announcement's availability snapshot and verify the intended region and SKU before planning a deployment. Launch availability.
My selection record would also include the operating-system image, deployment automation, quota, and capacity assumptions. Validate disk discovery and application startup on a clean instance rather than relying on a manually prepared benchmark machine.
Review the complete operating cost using the intended configuration, including any separately provisioned storage and supporting services. I am not claiming a particular saving or workload speedup here; those require a measured comparison for the actual deployment.
Practical Cloud Engineer Takeaway
Choose an exact SKU based on storage, memory, compute, and network needs.
Document the source of truth and recovery path for local data.
Benchmark representative steady-state application behavior.
Rehearse replacement and reconstruction on disposable test resources.
Measure the impact on the rest of the cluster during recovery.
Verify current regional availability and deployment prerequisites.
Compare the complete configuration, not isolated headline figures.
Who Should Care?
Teams operating storage-heavy distributed systems, caching platforms, analytics workloads, search infrastructure, and databases designed to use local NVMe capacity safely.
Bottom Line
Lasv5 and Laosv5 GA expand Azure's storage-dense compute options. The strongest design is the one that can use that capacity efficiently and recover predictably when a node is replaced.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments