Accurate Pricing for Azure Files Premium Volumes

The gap: shared volumes were mispriced

Azure gives Kubernetes two very different storage backends, and both show up as PersistentVolumes:

• Managed Disk — a block device, one pod at a time (ReadWriteOnce). CSI driver disk.csi.azure.com.
• Azure Files — a network file share over SMB/NFS, many pods at once (ReadWriteMany). CSI driver file.csi.azure.com.

We had disks priced. Azure Files had no price, so any shared (RWX) PV fell back to the wrong static rate — quietly skewing storage costs for anyone using file shares.

Why Files Premium is priceable (and EFS wasn't)

Azure Files Premium is provisioned: you declare the share size in GiB and Azure bills a flat $/GiB-month on that provisioned size, regardless of how many bytes you actually store. That provisioned size is exactly the Kubernetes PVC capacity — so:

monthly cost = rate ($/GiB-month) × PVC capacity (GiB)

That's an exact answer. It's also why we skipped AWS EFS: EFS is elastic, billed on the bytes you actually store, and the Kubernetes capacity number is essentially fictional — there's no reliable way to turn it into a cost. Azure Files Premium is the opposite, so we can price it precisely.

What we changed

• Prices. Kubeadapt now also pulls Azure file-share prices (Premium LRS and ZRS).
• Matching. A shared file-share PV is matched to those prices by its CSI driver (file.csi.azure.com), not by skuName alone, because the SKU names overlap with managed disks.

What's covered

Standard Files stays unpriced

Standard Azure Files is pay-as-you-use (billed on stored bytes, not provisioned size), so like EFS it has no reliable per-GiB provisioned rate. We leave it unpriced rather than guess.

What you'll see

If you run RWX workloads on Azure Files Premium, those volumes now carry a real monthly cost across the dashboard — storage totals, orphaned-volume detection, and namespace/team rollups all reflect the correct rate. No configuration needed; pricing updates automatically on the next fetch.