AWS Database Cost Audit

* Reserved Instance purchases are a commitment decision that belongs to you: savings assume the workload keeps running for the full term, and only you have insight into future usage plans (migrations, re-platforming, decommissions). The scanner sees history, not roadmaps. Mechanics: groups running size-flexible instances by account, region, family, engine, and AZ config; subtracts active RI coverage in normalized units. Savings compare live public On-Demand rates against matching RI offering rates (upfront amortized) - the rate math is exact. Confidence reflects workload longevity: high when every instance in the group has run 6+ months, medium when younger. Instances too young to prove steady demand are excluded entirely, as are instances this report recommends scheduling, deleting, moving to another family, or converting from Multi-AZ; instances flagged for a same-family downsize are sized at their target class, never today's larger one. Also weigh the Database Savings Plans alternative (see that section): RIs discount deeper on stable shapes, a Savings Plan follows the estate through engine, family, and region changes.

* Commitment decision belongs to the client (see Reserved Instance note). ElastiCache reserved nodes match exact node types with no size flexibility; clusters already flagged for deletion, right-sizing, or migration are excluded from sizing. Savings compare live On-Demand against the lowest matching offering, upfront amortized.

* Commitment decision belongs to the client (see Reserved Instance note). Exact node-type matching; clusters pending pause, resize, or RA3 migration are excluded. Savings compare live On-Demand against the lowest matching offering, upfront amortized.

* Commitment decision belongs to the client (see Reserved Instance note). Exact instance-type matching; actioned domains excluded. Savings compare live On-Demand against the lowest matching offering.

* Commitment decision belongs to the client (see Reserved Instance note). Database Savings Plans (1-year, no upfront) apply automatically across engines, instance families, sizes, and regions - so they survive the modernization moves this report recommends. Discounts are published as up-to ranges (20% provisioned / 35% serverless), not per-resource rates the scanner can verify, so no dollar amount is claimed. RIs and reserved nodes discount deeper on stable shapes; do not stack both over the same usage.

Purchased reservation hours going unused - usually family drift after migrations or scheduling of RI-covered instances. Re-match, exchange, or resell where the term allows.

Reservations ending inside the warning window. A lapsed RI silently reverts covered instances to On-Demand rates; renewal analysis should start now, not at expiry.

An instance qualifies when it shows zero connections during the stop window on 95%+ of observed windows over the full lookback. Each row states its window in the region's business timezone (e.g. Asia/Kolkata for ap-south-1) - never assume UTC. Savings cover the nightly windows plus weekends, and weekend daytime is checked separately: any weekend traffic drops the estimate to the nightly windows alone rather than assuming the weekend is free. Stopped compute hours only; storage and backups keep billing. RDS auto-starts instances stopped 7+ days; AWS Instance Scheduler handles that rotation.

DocumentDB clusters stop like RDS instances (auto-restart after 7 days; storage keeps billing). Window evaluated per member in the region's business timezone shown on each row.

Neptune clusters support stop/start with the same 7-day auto-restart. Window evaluated per member in the region's business timezone shown on each row.

Redshift's native pause/resume schedule stops per-hour compute billing during the stated stop window and weekends; managed storage continues. Each row states its window and timezone. Resume takes minutes - built for exactly these non-production warehouses.

Read replicas with zero connections across the whole window serve no traffic. Deleting one saves its full compute and storage; recreating from the source later takes minutes.

Caches with zero connections across the whole window bill 24/7 and cannot be stopped. Redis/Valkey snapshot to S3 and restore in minutes; memcached holds no durable data. Delete after confirming ownership.

Domains with zero search and indexing traffic all window bill 24/7 and cannot be stopped. Snapshot to S3, delete, restore in under an hour if ever needed.

MemoryDB is durable Redis: a final snapshot preserves the full dataset, and idle clusters bill every node 24/7. Delete after confirming ownership.

DMS replication instances bill 24/7 whether tasks run or not - the classic leftover from a finished one-time migration. Export task configurations, delete the instance, recreate in minutes when the next migration comes.

No reads or writes across the whole window. Export to S3 or take an on-demand backup, then delete. Confirm no seasonal consumer first.

A GSI that serves no reads still replicates every table write and bills its own capacity and storage. Deleting is safe; recreating later is a background backfill.

Stopped instances keep billing storage, and RDS restarts them every 7 days. Long-stopped usually means forgotten: snapshot and delete after confirming ownership.

Decision uses p95 of hourly CPU maxima over the lookback with a spike guard, plus verified memory headroom where instance RAM is known — never plain averages. Targets stay one size down in the same family, preserving size-flexible RI coverage. Execute in a maintenance window; expect a brief failover/restart.

Decision uses p95 CPU (EngineCPUUtilization where the engine reports it) with a spike guard, plus memory usage where available. Redis scales down online; memcached needs a replacement cluster. Savings use live public node rates.

Elastic resize sheds nodes online in minutes. Recommended only when p95 CPU is low AND disk usage leaves room for each remaining node's share to double after halving.

p95 CPU with a spike guard plus verified JVM memory pressure headroom - heap-bound domains never shrink. Blue/green deployment applies the change without downtime.

Dedicated masters coordinate cluster state; they serve no queries. AWS guidance sizes them by data-node count, and small domains need small masters.

p95 engine CPU with a spike guard plus memory usage where reported. MemoryDB scales node type online per shard.

p95 of hourly consumed capacity against the provisioned floor. Targets are p95 plus headroom with auto scaling attached to absorb anything above.

Provisioned tables running near-empty pay for capacity nobody uses; on-demand tables with steady heavy traffic pay a premium per request. Each row states the direction. One-click change, reversible once per 24h.

These instances look oversized on p95 CPU, but at least one spike above the threshold occurred in the window. Downsizing now would amplify the spike on smaller hardware. Fix the cause first; each then becomes a normal right-sizing candidate at the stated potential saving.

Same-size move from x86 to AWS Graviton, typically 10-20% cheaper with equal or better throughput. Managed engines need no application changes; execute as a normal class modification in a maintenance window. Instances already flagged for right-sizing are excluded here - do one class move, not two.

Previous-generation instance classes cost more per unit of performance than current ones. Listed instances run engines without a Graviton path; the upgrade stays on x86.

Valkey is the Linux Foundation fork of Redis OSS 7.2 - same API, same tools - and AWS lists it ~20% below Redis OSS on ElastiCache nodes (~30% on MemoryDB, 33% on serverless). The engine upgrades in place with no data loss. Savings compare live rates for both engines on the exact node type; clusters already flagged for deletion, right-sizing, or a class move are excluded - one change at a time.

Engine versions past standard support bill the RDS Extended Support surcharge per vCPU-hour, doubling in year 3 - versions already in year 3 are estimated at the doubled rate. DocumentDB 3.6 instead bills a percentage premium on the instance rate. Because the surcharge accrues only while an instance runs, instances this report also recommends scheduling off are sized on their remaining running hours. Upgrading the engine removes the charge and restores full security patching.

Multi-AZ bills the standby at the full instance rate. Non-production environments that tolerate minutes of downtime rarely justify it; converting to Single-AZ halves compute cost.

Graviton RG nodes follow AWS's published RA3 mapping: rg.xlarge replaces ra3.xlplus one-for-one, and three rg.4xlarge replace four ra3.4xlarge (each RG node carries 1.33x the vCPU and memory). Savings compare live node rates; findings appear only in regions where a live RG rate exists. Three further RG advantages are counted as zero: Spectrum's per-TB scan charge disappears, warehouse workloads benchmark up to 2.2x faster, and manual snapshots bill on unique data blocks only (incremental snapshot billing, June 2026) where RA3 keeps paying full size per snapshot - the deduplication ratio cannot be known before migrating, so it is evidence, not a claim. Elastic resize performs the move online; clusters already flagged for pause or resize are excluded.

Previous-generation node types couple compute to storage. RA3 with managed storage scales them independently and usually wins economically; sizing depends on the storage profile, so no automated saving is claimed.

OpenSearch Optimized (OR2/OM2) instances use S3-backed replicas - replica EBS volumes disappear - and index up to 70% faster than r7g at equal size. Flagged domains are indexing-heavy on general-purpose families; sizing depends on the workload mix, so the finding is consultative with no claimed saving.

gp3 costs ~20% less per GB than gp2 and includes a 3,000-IOPS baseline regardless of size. Conversion is online with no downtime. Savings use live per-GB rates for both volume types.

io1/io2 volumes provisioned at 16,000 IOPS or less fit inside gp3's range, where IOPS above the free baseline cost a fraction of provisioned-IOPS rates. Peak observed IOPS are shown as evidence that the ceiling is safe.

Manual snapshots never expire on their own. Old and orphaned snapshots (source instance deleted) accumulate storage cost silently. Savings are approximate - snapshots bill on used, not allocated, bytes. Deletion is irreversible; check retention policy first.

Standard-IA cuts storage ~60% but raises request and capacity prices ~25%. Flagged only where storage cost exceeds throughput cost, and the saving shown is net: the storage discount minus the request premium on current throughput.

Point-in-time recovery bills per GB-month continuously. Non-production data that can be regenerated rarely justifies it.

Aurora I/O-Optimized trades +30% instance and +125% storage cost for free I/O. Worth it when I/O runs above ~25% of cluster spend. Account-level estimate; evaluate and switch per cluster.

T-family instances charged surplus CPU credits run beyond baseline permanently - a hidden hourly surcharge. Fixed-performance classes usually cost less at sustained load.

Spiky, mostly-idle non-production Aurora workloads fit Serverless v2, which scales capacity to near zero between runs. Model ACU consumption before converting.

OpenSearch Serverless NextGen scales indexing and search OCUs to zero after 10 minutes of inactivity with no minimum. Flagged domains are mostly-idle non-production. Model OCU consumption before migrating - steady workloads stay cheaper on provisioned domains.

Enterprise-edition license premiums often exceed infrastructure cost. Feature-usage review with the DBA team decides whether Standard edition or BYOL applies. Consultative - no automated saving claimed.

Services with real spend but no deep-dive analyzer yet: the figure marks the opportunity, the checklist starts the review. Deprecated services (QLDB) are migration deadlines, not optimizations.