-
Delete what should not exist
Orphaned instances, leftover DMS replication instances, stopped-but-storage-billing clusters, idle read replicas, unused DynamoDB global secondary indexes, aged manual snapshots. Deletion is a 100% saving, and every deleted instance shrinks the baseline you would otherwise reserve.
pull: aws rds describe-db-instances + 60d CloudWatch connections check: DatabaseConnections p95 = 0, no reads/writes, owner unknown
-
Schedule non-production off-hours
Dev, staging, and QA rarely need nights and weekends. A 12×5 schedule cuts those instances ~65%. Scheduled instances must leave the reservation baseline entirely. A reserved instance that sleeps 60% of the time is a commitment to waste.
pull: instance tags/naming (env), CPU + connections by hour-of-week check: flat overnight utilization in your business timezone
-
Right-size on p95, not averages
Averages hide idle; two-week windows hide month-end spikes. Use p95 of hourly maxima over at least 60 days, and verify memory headroom and connection counts before dropping a size class. The size you reserve should be the size you land on, not the size you started with.
pull: 60d hourly CPUUtilization max, FreeableMemory, connections check: p95 < ~30% and no spikes above ~60% before downsizing one step
-
Modernize the generation first
Previous-generation families (r4, m4, db.r5 in some regions) cost more for less. Graviton equivalents run 10–20% cheaper where the engine supports them. Reserving a legacy family locks in legacy pricing for the full term.
pull: instance class inventory vs. current-gen equivalents check: engine + version supports Graviton; no unsupported extensions
-
Strip non-reservable spend from the math
Storage, IOPS, backups, I/O, data transfer, and Extended Support surcharges cannot be reserved at all. Any “on-demand spend” figure that includes them inflates your apparent reservation gap. It is the single most common error in RI-tool recommendations.
pull: Cost Explorer grouped by usage type check: reservation math uses InstanceUsage / NodeUsage lines only
-
Check version runway and Extended Support
An engine version near end-of-life means either an upgrade (which may change instance requirements) or Extended Support surcharges of roughly 2× on compute. Upgrade first, then reserve what the upgraded estate actually needs.
pull: engine versions vs. AWS EOL calendar check: nothing you're about to reserve enters Extended Support mid-term
-
Confirm the 12-month roadmap
Migrations to Aurora or serverless, engine switches, consolidation plans, products being sunset: any of these can strand a reservation. Reserve the steady-state floor you are confident survives the term, not today's peak inventory.
pull: 30 minutes with the teams that own the databases check: no migration/rearchitecture planned for anything in the basket
-
Now price the commitment properly
Only after checks 1–7: compute the gap on reservable compute, price it against live RI offering rates with upfront amortized, target the steady floor (not 100% coverage), and stagger expirations so renewals never land in one quarter.
pull: live RI offerings via pricing API for the exact class/region check: coverage target ≤ steady floor; calendar reminder before expiry
Want this run against a real account?
The free scan applies these checks, and about forty more, to one AWS account. Read-only role, 15-minute setup, report in 48 hours. You keep the report either way. Not ready to talk to anyone? Run the 30-second estimate instead — no email, nothing leaves your browser.
Request a free scan See a sample report