Explanation
Why the waste happens and who it affects.
Each block or boot volume is charged per GB-month for storage plus a number of volume performance units (VPUs) per GB-month set by its performance level: 0 for Lower Cost, 10 for Balanced, 20 for Higher Performance and 30 to 120 for Ultra High Performance. Volumes are often raised to Higher or Ultra High Performance for a migration, a load test or a database launch and not lowered afterwards, so they keep paying two to twelve times the Balanced VPU charge for IOPS and throughput they no longer use.
A related case: large block volumes that serve sequential, throughput-oriented work such as streaming, log processing or data warehouse files stay on the default Balanced level, when Lower Cost, with no VPU charge, is Oracle's recommended level for that I/O pattern. Performance can be changed on an existing volume without re-creating it, so both cases can be corrected in place.
Billing model
The pricing dimensions that drive this cost.
Performance is priced per GB, so the VPU charge grows with volume size as well as with the performance level.
- Block Volume Storage
- Billed per GB of provisioned capacity per month for block and boot volumes
- Volume performance units
- Billed per VPU per GB per month; Balanced is 10 VPUs/GB, Higher Performance 20, Ultra High Performance 30 to 120
- Lower Cost level
- 0 VPUs/GB, storage cost only, available for block volumes but not boot volumes
- Performance-based auto-tuning
- Adjusts a volume between a Default VPUs/GB floor and a Maximum VPUs/GB ceiling based on monitored performance
How to detect
5 checks to find it in your estate.
- List block and boot volumes whose vpusPerGB is 20 or more (oci bv volume list and oci bv boot-volume list return vpusPerGB for each volume), grouped by compartment and attached instance
- For each, compare VolumeReadOps plus VolumeWriteOps and VolumeReadThroughput plus VolumeWriteThroughput in the oci_blockstore namespace with VolumeGuaranteedIOPS and VolumeGuaranteedThroughput over several weeks, including peaks; sustained use far below the guarantee means the level is higher than needed
- Check VolumeThrottledIOs before lowering a level: volumes with throttled I/O are using their performance and are not candidates
- Flag Ultra High Performance volumes whose attachments are not multipath-enabled or whose instance shape does not support UHP, since multipath-enabled attachments are required for UHP performance
- Find large block volumes on Balanced that serve sequential, throughput-bound workloads (streaming, log processing, data warehouse files) and could use Lower Cost
How to fix
5 ways to remove the waste.
- Lower vpusPerGB on overprovisioned volumes from the volume's Edit panel or with oci bv volume update --vpus-per-gb (0, 10, 20 or 30 to 120); the change applies to the existing volume without re-creating it
- For volumes with occasional peaks, enable performance-based auto-tuning with a low Default VPUs/GB floor and a Maximum VPUs/GB ceiling, so the higher level is used only when monitored performance needs it
- Move sequential, throughput-bound block volumes to Lower Cost after testing, noting that the IOPS performance SLA does not apply at Lower Cost and latency can be higher and more variable
- Keep boot volumes at Balanced unless a measured need exists, since boot volumes cannot use Lower Cost and are created at Balanced by default
- Enable detached volume auto-tuning on volumes that are periodically detached so they drop to Lower Cost while detached
Documentation
Vendor references for pricing and configuration.