Cost

Right-size EBS storage volumes

Match volume size, IOPS, and throughput to actual usage — most gp3 volumes are provisioned for headroom nobody uses.

14 min·10 sections·AWS

Last reviewed 27 May 2026

EBS right-sizing: the basics

What does it mean to right-size an EBS volume?

An EBS volume has three independent dimensions you pay for: capacity in GB, provisioned IOPS, and provisioned throughput in MiB/s. On gp3, capacity bills per GB-month, with 3,000 IOPS and 125 MiB/s included for free; anything above that is paid for separately. On io1/io2 every provisioned IOP is billed, at roughly $0.065 per PIOPS-month for io1. Right-sizing means making sure the number on each of those three knobs actually matches what the workload uses.

The most common over-provisioning pattern shows up after a gp2 → gp3 migration. Teams script the upgrade and tell it to "match the prior IOPS" of the gp2 baseline, which scaled with volume size at 3 IOPS per GB. A 4 TB gp2 volume had a 12,000 IOPS baseline — so the migration provisions 12,000 IOPS on the new gp3 volume "to be safe." Most of those workloads never saw more than 500 IOPS on the original volume. The headroom was incidental, but the bill for it on gp3 is real.

The flip side is also true: an under-provisioned volume throttles, latency rises, and the application starts looking unhealthy in ways that don't immediately point at storage. EBS right-sizing isn't about cutting to the bone — it's about matching each of the three dimensions to actual observed usage with a sensible buffer, and then re-checking quarterly as the workload changes.

In this lesson you'll learn how EBS pricing splits into capacity, IOPS, and throughput; which CloudWatch metrics actually tell you what a volume is using; how to apply IOPS and throughput changes online with modify-volume; and why capacity-shrink is a fundamentally different (and harder) operation that requires a snapshot-and-swap. You'll see a Compute Optimizer EBS recommendation and the exact CLI calls to apply the safe parts of it.

Fun fact

The gp2-to-gp3 migration tax

When AWS launched gp3 in late 2020, the official upgrade guidance was to migrate gp2 volumes and "preserve the prior performance baseline" — which translated, for most automation, into provisioning IOPS at 3× the volume size. The result was that a wave of teams locked in gp3 volumes with 6,000–16,000 IOPS provisioned, paying for extra IOPS they never used on gp2 (where the baseline was "free" because it was bundled). Three years later, those volumes are still sitting there with the same over-provisioned IOPS — and they're now one of the single largest sources of low-risk gp3 savings in any mature AWS account.

EBS right-sizing in action

Nina runs SRE for a healthcare analytics platform. A monthly cost review flags that EBS is the second-largest line on the AWS bill — and a sizable chunk of it is gp3 IOPS surcharges, not capacity. She picks one of the biggest offenders: a 2 TB gp3 volume on a Postgres replica, provisioned at 12,000 IOPS and 500 MiB/s throughput.

She pulls 14 days of CloudWatch data. VolumeReadOps and VolumeWriteOps sum to a p99 of about 1,400 IOPS — well under the 3,000 IOPS that come free on gp3. Throughput peaks at 65 MiB/s, about half the free baseline. The volume is paying for 9,000 IOPS and 375 MiB/s of headroom that nobody is touching.

She cross-checks against Compute Optimizer's EBS recommendations, which classify the volume as Over-provisioned. The recommended target: 3,000 IOPS, 125 MiB/s, capacity unchanged. Projected monthly savings: roughly $530 per volume — and there are 34 volumes with the same shape across the fleet.

First, confirm the IOPS signal by pulling the operations metrics directly. CloudWatch reports them as a count per period — divide by the period seconds to get IOPS.

$ aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeReadOps --dimensions Name=VolumeId,Value=vol-0abc123def456 --start-time $(date -u -d '14 days ago' +%FT%TZ) --end-time $(date -u +%FT%TZ) --period 300 --statistics Sum Maximum

{

"Datapoints": [

{ "Timestamp": "2026-05-01T08:00:00Z", "Sum": 187000, "Maximum": 420000, "Unit": "Count" },

{ "Timestamp": "2026-05-02T08:00:00Z", "Sum": 192400, "Maximum": 415000, "Unit": "Count" },

{ "Timestamp": "2026-05-03T08:00:00Z", "Sum": 198100, "Maximum": 438000, "Unit": "Count" }

]

}

# 420k ops / 300s = ~1,400 IOPS p99 — well below the 3,000 IOPS gp3 baseline.

14-day 5-minute window of read operations on the Postgres replica volume.

Now ask Compute Optimizer for its EBS recommendation. It's already been observing the volume and produces a target shape with a performance risk score.

$ aws compute-optimizer get-ebs-volume-recommendations --volume-arns arn:aws:ec2:eu-west-1:123456789012:volume/vol-0abc123def456 --query 'volumeRecommendations[0]'

{

"finding": "NotOptimized",

"currentConfiguration": { "volumeType": "gp3", "volumeSize": 2048, "volumeBaselineIOPS": 12000, "volumeBaselineThroughput": 500 },

"volumeRecommendationOptions": [

{

"configuration": { "volumeType": "gp3", "volumeSize": 2048, "volumeBaselineIOPS": 3000, "volumeBaselineThroughput": 125 },

"performanceRisk": 1.0,

"savingsOpportunity": { "savingsOpportunityPercentage": 38.4, "estimatedMonthlySavings": { "value": 531.20, "currency": "USD" } }

}

]

}

# performanceRisk 1.0 = LOW. Drop IOPS and throughput; keep capacity.

Compute Optimizer's recommendation on the same volume.

EBS right-sizing under the hooddeep dive

gp3 pricing in us-east-1 is roughly $0.08 per GB-month, $0.005 per provisioned IOP-month above the 3,000 baseline, and $0.04 per provisioned MiB/s-month above the 125 baseline. That means a 2 TB volume with 12,000 IOPS and 500 MiB/s is paying about $164/mo for capacity, $45/mo for the extra 9,000 IOPS, and $15/mo for the extra 375 MiB/s — roughly 27% of the line is performance, not storage. On io1/io2 the IOPS line is even larger: every PIOPS is billed at $0.065/mo on io1, so cutting from 12,000 to 3,000 PIOPS on io1 saves about $585/mo on a single volume.

IOPS and throughput modifications are online — you call ec2 modify-volume and the volume transitions through modifying → optimizing → in-use while the workload keeps running. The only constraint is the 6-hour cooldown between successive modifications on the same volume, so you can't oscillate. Capacity changes are also online, but only in one direction: EBS can grow a volume but it cannot shrink one. There is no --size 1024 call on a 2,048 GB volume that just gives you back the difference.

To actually reduce capacity, you need a snapshot-and-swap: snapshot the source volume, create a new, smaller volume from the snapshot (or from a logical backup if the filesystem doesn't fit), then detach the old volume and attach the new one. For stateful workloads this means downtime or careful coordination — typically a maintenance window, a brief read-only mode, or a database-level replication switchover. This asymmetry is why the cheapest and safest right-sizing target is almost always IOPS and throughput first, capacity second.

# Online: drop IOPS and throughput on a gp3 volume back to the free baseline.
aws ec2 modify-volume \
  --volume-id vol-0abc123def456 \
  --iops 3000 \
  --throughput 125

# Watch the modification progress; the workload stays online throughout.
aws ec2 describe-volumes-modifications \
  --volume-ids vol-0abc123def456 \
  --query 'VolumesModifications[0].[ModificationState,Progress,TargetIops,TargetThroughput]'

What is the impact of running over-provisioned EBS volumes?

The immediate impact is direct spend. A fleet with 200 over-provisioned gp3 volumes carrying an average of 8,000 IOPS and 300 MiB/s above baseline is paying roughly $130k/year in IOPS and throughput surcharges alone, before you touch the capacity line. On io1/io2 the multiplier is much harsher — IOPS is the dominant cost component, and "we provisioned 20,000 PIOPS to be safe" is a $15k/month decision per volume.

The second-order impact is that over-provisioned EBS distorts your storage tier choices. If gp3 volumes are silently expensive because everyone over-IOPSes them, teams start migrating workloads to instance-store volumes, NVMe-equipped families, or even back to gp2 "because gp3 is more expensive" — which is only true relative to a misconfigured baseline. Right-sizing the gp3 fleet first usually flips the comparison and lets gp3 deliver what it was designed for: cheaper, more predictable performance.

Capacity over-provisioning has a different impact profile. The marginal cost per unused GB is small (about $0.08/mo on gp3), but the operational cost of carrying it is large: backups, snapshots, replication targets, and DR copies all bill against the same provisioned size. A 4 TB volume with 1 TB of actual data is paying for 3 TB of empty space on every nightly snapshot, every cross-region copy, every restore-test rehearsal. That compounds quickly.

Finally, over-provisioned IOPS hides genuine performance signals. If your volumes are sized for 5× their actual peak, you'll never see throttling alarms — even when a query plan regresses or an application starts doing the wrong thing at scale. Right-sizing brings the baseline closer to actual usage and re-engages the early-warning signal you want anyway.

How do you right-size EBS volumes safely?

EBS right-sizing is a four-step loop: measure honestly, change the cheap dimensions first, plan the hard dimension as a project, and re-check on a cadence. Each step is straightforward; skipping any of them is where teams get hurt.

1. Measure IOPS and throughput against the 14-day p99

Pull VolumeReadOps + VolumeWriteOps from CloudWatch over 14 days at 5-minute resolution, sum them per period, and convert to IOPS by dividing by the period in seconds. Do the same for VolumeReadBytes + VolumeWriteBytes to get MiB/s. Use the p99 (not the average — averages hide bursts). Compare those numbers to the gp3 free baselines (3,000 IOPS, 125 MiB/s). Anything well below baseline with extra IOPS or throughput provisioned is a target.

2. Apply the IOPS and throughput cut online via modify-volume

ec2 modify-volume changes IOPS and throughput without detaching. The workload keeps running. The volume goes through modifying → optimizing and lands at the new shape, usually within minutes. Respect the 6-hour cooldown — you can't make two modifications in quick succession on the same volume — and use describe-volumes-modifications to confirm before moving on. This is by far the highest savings-per-risk move.

3. Plan capacity reduction as a snapshot-and-swap, not a click

Capacity cannot be shrunk in place. To actually reduce a volume's size you snapshot it, restore the snapshot into a smaller volume (or rebuild via a logical backup if the data fits), then detach the old and attach the new. Schedule a maintenance window, document a rollback path back to the original volume, and verify the workload reads/writes cleanly before deleting the old volume. For database hosts, prefer a replica-based switchover — promote a smaller replica, repoint the application, then decommission the oversized primary.

4. Re-evaluate quarterly and on workload change

A right-sized volume today is wrong in three months — data grew, a new index changed the IO pattern, or a feature shipped that 10×'d traffic. Wire Compute Optimizer's EBS recommendations into a weekly digest, and put a 30-minute review on the FinOps cadence. Tag volumes with their last-reviewed date so you can spot the ones that have been ignored.

# Bulk-list every EBS volume Compute Optimizer marks as over-provisioned, low-risk.
aws compute-optimizer get-ebs-volume-recommendations \
  --filters name=Finding,values=NotOptimized \
  --query 'volumeRecommendations[?volumeRecommendationOptions[0].performanceRisk==`1.0`].[volumeArn,volumeRecommendationOptions[0].configuration]' \
  --output json > over-provisioned-ebs.json

# Review the list, exclude any volumes under change-freeze, then schedule modify-volume calls.

Quick quiz

Question 1 of 5

You have a 2 TB gp3 volume provisioned at 12,000 IOPS and 500 MiB/s. CloudWatch p99 over 14 days shows ~1,400 IOPS and ~65 MiB/s. Compute Optimizer recommends 3,000 IOPS and 125 MiB/s, performanceRisk = 1.0. What's the right next move?

Keep learning

Dig deeper into how EBS bills, what the metrics mean, and how to plan capacity-reduction safely.

You've completed Right-size EBS storage volumes. You now know the three dimensions of EBS pricing, why the gp2 → gp3 migration left so much over-provisioned IOPS on the table, how to cut IOPS and throughput online with modify-volume, and why capacity reduction is a snapshot-and-swap project rather than a click. The next time the bill flags EBS, you'll have a four-step loop — measure, modify, swap, re-check — ready to run.

Back to the library

EBS right-sizing: the unit economics

Three independent cost knobs, two of which you can cut online with no risk

An EBS volume bills on three separate meters: capacity in GB, IOPS above 3,000, and throughput above 125 MiB/s. On gp3, IOPS overage costs roughly $0.005 per provisioned IOP per month and throughput overage costs $0.04 per provisioned MiB/s per month. Those are per-unit rates on numbers you pick, so the math is deterministic: provisioning 12,000 IOPS instead of 3,000 on a gp3 volume is exactly $45/month more, every month, whether those IOPS are used or not.

The gp2-to-gp3 migration left most accounts with hundreds of volumes over-IOPSed by a factor of 3–8x. Teams carried over the gp2 IOPS baseline — which was bundled, not extra-billed — into gp3 as provisioned IOPS, which are extra-billed. The workloads didn't change; the bill did. Compute Optimizer surfaces this as NotOptimized findings with a performance risk of 1.0 (low risk to cut). That's a finance-readable signal: here are the line items you're paying for but not using.

The right framing is three buckets: IOPS and throughput overage are the cheapest and safest cuts (online, no maintenance window, instant billing effect); capacity overage requires a snapshot-and-swap project and has a smaller per-GB rate but compounds across every backup and snapshot copy. Start with the IOPS and throughput bucket — it's where most of the savings are and the risk is minimal.

This lesson is for the finance partner who sees a large EBS line on the AWS invoice and wants to understand which part is recoverable and what it takes to recover it. You'll learn exactly how the three billing meters work (capacity, IOPS, throughput), why the gp2-to-gp3 migration is the most common source of gp3 IOPS overspend, how to read a Compute Optimizer recommendation as a dollar-and-risk signal, and which savings are low-touch versus which require an engineering project. No commands required.

Fun fact

The gp2-to-gp3 migration tax

How a finance partner turns the EBS bill into a right-sizing work order

Raj is the FinOps lead. At the monthly cloud bill review he notices that EBS is 18% of total AWS spend — unexpectedly large for a platform that isn't storage-heavy. He pulls Compute Optimizer's EBS findings and finds 47 volumes flagged NotOptimized, most of them with a performance risk of 1.0 (low). The bulk of the cost is IOPS and throughput overage on gp3 volumes that were migrated from gp2 eighteen months ago.

He builds a simple table: volume ID, current provisioned IOPS, 14-day p99 IOPS from CloudWatch, estimated monthly savings from cutting to the baseline. The top 20 volumes account for $8,400/month in avoidable IOPS charges. None of them are in a change-freeze window; all are flagged low-risk by Compute Optimizer.

Raj presents engineering with a pre-sorted list: 20 volumes, estimated $8,400/month savings, all modifiable online with no maintenance window. He doesn't ask for heroics — just a one-sprint blitz through modify-volume calls on the list. The remaining 27 volumes get tagged for the next quarterly review. The budget impact is visible before the sprint even starts, which makes it easy to prioritise.

Why over-provisioned EBS is a finance problem, not just an engineering one

The direct cost impact is unusually easy to quantify because the billing model is deterministic. Every provisioned IOP above the 3,000 gp3 baseline costs exactly $0.005 per month whether it's used or not. A fleet of 200 volumes carrying an average of 8,000 excess IOPS is paying $8,000/month in avoidable IOPS charges — a number you can calculate before touching a single volume, and verify on the next invoice after remediation.

The compounding impact is on backups and snapshots. AWS snapshots bill against provisioned volume size, and EBS snapshot costs compound across every copy: nightly snapshots, cross-region DR copies, and restore-test rehearsals all carry the same oversized footprint. A 4 TB volume with 1 TB of real data is burning money on 3 TB of empty space every time a snapshot runs. The per-GB rate is low, but at fleet scale it's a material fraction of the storage line.

For chargeback and showback, over-provisioned EBS distorts team-level unit economics. If the platform team allocates EBS costs by volume per service, a service running a gp3 volume at 5× its actual IOPS need appears expensive compared to a service running bare-minimum provisioning. Right-sizing before the allocation cycle ensures the cost signals each team sees reflect actual consumption, not historical accidents.

Finally, IOPS over-provisioning suppresses the performance alarms that catch regressions early. A right-sized fleet where volumes operate near their provisioned limits produces meaningful throttle signals when IO patterns change. An over-provisioned fleet is quiet even when something is wrong — which shifts the cost of catching problems from a CloudWatch alarm to a customer complaint.

What finance can drive on EBS right-sizing

Finance can't run modify-volume, but it controls the levers that make right-sizing happen consistently rather than once. Four actions, tied to the regular cadence.

1. Pull the Compute Optimizer EBS savings estimate before each sprint cycle

Compute Optimizer produces per-volume savings projections with a performance-risk score. Ask for a report of all volumes at risk 1.0 (low) with their estimated monthly savings before each engineering sprint cycle. That gives the team a pre-sorted, pre-valued work list and makes the dollar impact of the sprint visible before a single change is made.

2. Separate IOPS/throughput savings from capacity savings in the tracking

IOPS and throughput cuts are online, low-risk, and show up on the next invoice. Capacity reductions require a snapshot-and-swap project and are inherently slower. Track them separately — IOPS/throughput savings should close within the current quarter; capacity savings belong in a project backlog with a realistic timeline. Mixing them in a single savings number sets unrealistic expectations.

3. Add `last-reviewed` date to volume tagging standards

Require a last-reviewed tag on every EBS volume, updated each time the volume is assessed against current usage. Include volume age since last review in the monthly EBS cost report. Volumes that haven't been reviewed in 90+ days are the most likely source of fresh overspend — the tag makes them findable without a deep audit.

4. Use EBS unit economics in chargeback, not raw provisioned size

When allocating EBS costs to teams, allocate on actual usage (CloudWatch p99) plus a defined headroom factor — not on provisioned IOPS. That way teams are charged for the performance they consume, not for the headroom someone provisioned three years ago. It also creates a direct financial signal: a team that over-provisions is directly accountable for the overage on their chargeback statement.

Quick quiz

Question 1 of 5

Compute Optimizer flags 60 gp3 volumes as NotOptimized with performanceRisk 1.0. Estimated monthly savings: $14,200 on IOPS/throughput cuts and $1,800 on capacity reductions. Engineering has one sprint available. What's the right approach to prioritise?

Keep learning

Dig deeper into how EBS bills, what the metrics mean, and how to plan capacity-reduction safely.

You've finished the finance view of EBS right-sizing. You know the three billing meters and which ones are deterministic (IOPS overage is exactly $0.005 per provisioned IOP per month, every month, whether used or not), why the gp2-to-gp3 migration is the most common source of gp3 waste, how to use Compute Optimizer as a pre-valued work list, and why IOPS/throughput savings belong in the current quarter while capacity savings are a separate project. Next time EBS is a large line on the bill, you'll have both the math and the triage framework to turn it into a concrete savings commitment.

Back to the library

EBS right-sizing: the headline

Cloud storage bills for what you provision, not what you use — most teams never reconciled the two

EBS charges for the storage performance you configure, not the performance your workloads actually consume. When teams migrated from the old storage type to gp3, they copy-pasted the old IOPS numbers into the new billing model — not realising that what was "free headroom" before became a paid line item. The result is that most mature AWS accounts are carrying persistent, predictable storage overspend that appeared during a routine migration and was never cleaned up.

This is not a one-time audit item. Storage volumes are created, modified, and forgotten continuously. Without a recurring review process, the over-provisioning accumulates. The leadership question is whether there is a governance mechanism — a quarterly right-sizing review, Compute Optimizer recommendations wired into the FinOps cadence — that keeps provisioned performance aligned with actual usage by default, rather than catching it in an annual cost-cutting exercise.

A short read for the leader who wants to understand why EBS keeps appearing on the waste list. You'll get the plain-English version of how storage performance billing works, why a routine infrastructure migration silently inflated the bill for most accounts, what a right-sizing cadence looks like as a governance process, and the one question to ask in the FinOps review to confirm it's being managed. No technical depth needed.

Fun fact

The gp2-to-gp3 migration tax

What a well-governed EBS fleet looks like from the outside

At one company the head of infrastructure, Tomás, inherited a bill where EBS was the third-largest AWS line and climbing. A one-time audit found over $200k/year in IOPS surcharges from a gp3 migration the team had done two years earlier and never revisited. Cutting most of it took two engineers one week — modify-volume calls are online and take minutes.

The deeper issue wasn't the $200k. It was that nobody had a process to catch it. Volumes were created, migrated, and forgotten. Compute Optimizer had been flagging the waste for months, but the recommendations weren't wired into any recurring review.

Tomás's fix was structural: Compute Optimizer findings go into the monthly FinOps review as a standing agenda item, and every volume gets a last-reviewed tag updated when it's assessed. The one-time savings were meaningful; the recurring governance process is what prevents the same problem from accumulating again.

Why this keeps appearing on the waste report

EBS over-provisioning is almost always the product of a one-time migration decision — usually gp2 to gp3 — that copied performance settings into a new billing model without anyone realising the economics had changed. It then persists because no process exists to revisit it. The volumes were provisioned, the workloads kept running, and the bill kept climbing. It's not negligence; it's the natural result of optimising for uptime over cost at the point of migration.

The executive consequence is predictable and avoidable spend. Unlike variable usage costs that fluctuate with traffic, IOPS and throughput overage on gp3 is a fixed monthly charge. It doesn't scale down at night or on weekends. It's the cloud equivalent of leasing office space you're not using — and unlike office space, you can give it back online without taking anything offline.

The governance question is whether right-sizing is a standing process or a one-time project. A one-time audit recovers what's there now; without a quarterly review cadence the same pattern accumulates again as new volumes are created with default-high provisioning. The sign of a mature FinOps practice is that this line stays flat or shrinks as the fleet grows — not that it periodically spikes and gets cut.

The leadership position on EBS right-sizing

The executive role here is to ensure that right-sizing is a repeating process with accountability, not a one-time cleanup that fades. Three governance moves cover it.

1. Make Compute Optimizer findings a standing FinOps agenda item

EBS right-sizing opportunities surface continuously as new volumes are created and workloads change. Treat Compute Optimizer's EBS NotOptimized count and associated savings estimate as a standing metric in the monthly FinOps review — not a project that completes and disappears. A consistently low number means the process is working; a climbing number is an early signal that provisioning discipline has loosened.

2. Require a last-reviewed tag and audit it

Policy without accountability drifts. Require that every EBS volume carries a last-reviewed date tag, and include the count of volumes not reviewed in 90+ days on the infrastructure health report. That single metric tells you whether the right-sizing process is actually running or whether the team is reviewing the same handful of volumes while the rest accumulate.

3. Distinguish quick wins from project work in the roadmap

IOPS and throughput cuts are engineering hours, not a project — they can be batched and executed in a sprint with Compute Optimizer as the work list. Capacity reductions are a project, with maintenance windows and rollback plans. Ask for both in the roadmap, but with different timelines. Conflating them is the main reason right-sizing stalls.

Quick quiz

Question 1 of 5

Your FinOps review shows Compute Optimizer EBS savings have climbed from $5k/month to $22k/month over the past six months despite two previous clean-up sprints. What does this signal?

Keep learning

Dig deeper into how EBS bills, what the metrics mean, and how to plan capacity-reduction safely.

That's the lesson. Two takeaways: EBS charges for what you provision, not what you use, and the most common source of waste — over-provisioned gp3 IOPS from a migration years ago — persists not because it's hard to fix but because no recurring process owns it. The leadership question isn't whether you cleaned it up once; it's whether there's a governance cadence that prevents it accumulating again.

Back to the library

Part of the learning path Cut your storage bill

Right-size EBS storage volumes

EBS right-sizing: the basics

The gp2-to-gp3 migration tax

EBS right-sizing in action

EBS right-sizing under the hooddeep dive

What is the impact of running over-provisioned EBS volumes?

How do you right-size EBS volumes safely?

1. Measure IOPS and throughput against the 14-day p99

2. Apply the IOPS and throughput cut online via modify-volume

3. Plan capacity reduction as a snapshot-and-swap, not a click

4. Re-evaluate quarterly and on workload change

Quick quiz

Keep learning

EBS right-sizing: the unit economics

The gp2-to-gp3 migration tax

How a finance partner turns the EBS bill into a right-sizing work order

Why over-provisioned EBS is a finance problem, not just an engineering one

What finance can drive on EBS right-sizing

1. Pull the Compute Optimizer EBS savings estimate before each sprint cycle

2. Separate IOPS/throughput savings from capacity savings in the tracking

3. Add last-reviewed date to volume tagging standards

4. Use EBS unit economics in chargeback, not raw provisioned size

Quick quiz

Keep learning

EBS right-sizing: the headline

The gp2-to-gp3 migration tax

What a well-governed EBS fleet looks like from the outside

Why this keeps appearing on the waste report

The leadership position on EBS right-sizing

1. Make Compute Optimizer findings a standing FinOps agenda item

2. Require a last-reviewed tag and audit it

3. Distinguish quick wins from project work in the roadmap

Quick quiz

Keep learning

Related cost lessons

3. Add `last-reviewed` date to volume tagging standards