DB Cost Audit · field checklist

The 8 checks before you reserve an AWS database instance

Reservations are the last lever, not the first. Every check below can change the size, family, or count of what you commit to for the next one to three years — which is why the order matters more than any single check.

The rule in one line: delete → schedule → right-size → modernize → then reserve. Committing first locks yesterday's waste into next year's bill.

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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 — the single most common error in RI-tool recommendations.

    pull: Cost Explorer grouped by usage type check: reservation math uses InstanceUsage / NodeUsage lines only

  6. 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

  7. 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

  8. 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.

Request a free scan See a sample report