Azure NetApp Files Capacity Pool
Does ZopNight manage Azure NetApp Files Capacity Pool?
Azure NetApp Files bills for the provisioned size of each capacity pool, reserved in 1 TiB-plus increments at the pool's service level, regardless of what the volumes inside actually consume. ZopNight discovers every pool and its provisioned size via Resource Graph and attributes its billed cost; compare pool size with volume quotas to spot over-provisioning.
Rules that fire on Azure NetApp Files Capacity Pool
No active rule family targets Azure NetApp Files Capacity Pool today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure NetApp Files capacity pools reserve high-performance file storage in 1 TiB-plus increments at premium prices. Over-provisioned pools bill for reserved capacity that volumes never consume.
Reservation pricing at a 1 TiB granularity
A capacity pool bills for its entire provisioned size at the hourly rate of its service level (Standard, Premium, or Ultra) from the moment it exists. The meter reads the reservation, not the usage: a pool provisioned at 4 TiB whose volumes hold 400 GiB pays for 4 TiB of Ultra-class storage all the same. Because the minimum pool is measured in tebibytes and the service levels are priced for demanding enterprise file workloads, this is among the most expensive idle capacity a subscription can hold per unit. Throughput entitlement scales with provisioned size too, which tempts teams to oversize pools for performance and then forget the capacity side of that decision.
Pool-level visibility through Resource Graph
ZopNight discovers each capacity pool via Azure Resource Graph with its provisioned size, and Cost Management billing attributes the spend. No recommendation rule covers NetApp pools today, so finding pools whose reservation comfortably exceeds what their volumes need is a manual comparison. A pool has no stop or pause operation, so nothing here schedules; the levers are shrinking the pool toward actual volume demand, stepping down the service level where the throughput headroom is unused, and deleting pools whose workloads have moved on.
Where reserved file capacity goes to waste
Typical leaks: a pool sized for a migration’s peak transfer window and never resized after cutover; an Ultra-tier pool serving a workload whose latency needs Standard would meet; and empty or near-empty pools kept “just in case” after their volumes were deleted, each still billing its full reservation.
Inspecting pools under a NetApp account
Azure portal → Azure NetApp Files → select the NetApp account → Capacity pools lists each pool with service level, provisioned size, and the volumes allocated from it. Comparing pool size against the sum of volume quotas exposes the reservation gap directly.