Find idle managed databases across AWS, Azure, and GCP by inventorying every instance, pulling connection, CPU, and IO metrics over a trailing window of at least two weeks, and flagging those with near-zero connections and very low CPU and IO. The single clearest signal is database connections: a database with effectively no connections is serving no application. Confirm each candidate with its owner, then rightsize the oversized, pause or move intermittent ones to a serverless tier, and snapshot then delete the truly unused. Always take a final snapshot before deletion, and add a recurring check so new idle databases are caught automatically.
Last updated: June 2026
An idle managed database is a hosted database instance, such as Amazon RDS, Azure SQL Database, or Google Cloud SQL, that keeps billing its hourly compute and storage rate while serving little or no real traffic. Because managed databases charge for provisioned capacity rather than queries run, an instance with no connections costs the same as a busy one. This is the Cut step of FinOps aimed at one of its most reliable targets: clear idle spend, the capacity you provisioned but no longer use, across all four clouds.
This article is part of our rightsizing and waste elimination cluster. For the full picture start with the complete guide to cloud rightsizing and waste elimination, the pillar this piece links up to. Idle databases are one accelerator-free form of waste; the GPU equivalent is covered in how to find underutilized GPUs and idle accelerators.
How do I know if a managed database is idle?
A managed database is idle when it shows near-zero active connections, very low CPU utilization, and minimal read and write activity over a sustained window of at least two weeks. The clearest single signal is the database connections metric: a database with effectively no connections is serving no application, regardless of how it was sized. Use a two-week minimum window so you do not flag a database that is quiet on weekends but busy on weekdays, and combine connections with CPU and IO so a low-traffic but genuinely used database is not mistaken for an idle one.
Which metrics identify an idle database on each cloud?
The same three signals exist on every cloud under different metric names. On AWS RDS and Aurora, use DatabaseConnections, CPUUtilization, and ReadIOPS and WriteIOPS in CloudWatch for RDS. On Azure SQL Database, use connection_successful, cpu_percent, and the IO metrics in Azure Monitor. On Google Cloud SQL, use the connections, CPU utilization, and disk read and write metrics in Cloud Monitoring. In every case the idle pattern is identical: near-zero connections plus low CPU and IO sustained over the window.
How do I find idle managed databases, step by step?
Follow these six steps to find idle databases across all your clouds and act on them without risking data.
- Inventory all managed database instances. List every RDS, Aurora, Azure SQL, and Cloud SQL instance across regions and accounts together with its size and monthly cost, so you know the full population and what each one is worth.
- Pull connection and CPU metrics. Collect database connections, CPU utilization, and read and write IOPS over a trailing window of at least two weeks from each cloud's monitoring service.
- Apply an idle threshold. Flag instances with near-zero connections and very low CPU and IO across the whole window as idle candidates, using the same thresholds on every cloud for consistency.
- Confirm with the owner. Check each candidate with its owning team to rule out a dormant but needed database, such as a disaster-recovery replica or a seasonal workload, before acting.
- Choose rightsize, pause, or remove. Rightsize an oversized but used instance, pause or move an intermittent one to a serverless or auto-pause tier, and snapshot then delete a truly unused one.
- Add recurring idle detection. Schedule the metric check so newly idle databases are flagged automatically, instead of accumulating until the next manual audit.
Databases billing full price for no queries?
Our cost audit inventories every managed database across your clouds, finds the idle and oversized ones by metric, and rightsizes, pauses, or removes them with a snapshot-first safety net. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →What should I do with an idle database?
The right action depends on the usage pattern, not just the idle flag. Rightsize a database that is genuinely used but oversized down to a smaller instance class; pause or move to a serverless or auto-pause tier one that is used only intermittently, so it scales to near zero when quiet; and snapshot then delete one that is genuinely unused. Always take a final snapshot before any deletion so the data can be restored if the database turns out to be needed. Matching the action to the pattern is the difference between safe savings and an outage, which is the core discipline of rightsizing and waste elimination.
Can I just stop an idle managed database?
Sometimes, but with caveats worth knowing. RDS lets you stop an instance, but it restarts automatically after seven days and storage continues to bill while it is stopped, so a stop is a pause, not a removal. Azure SQL and Cloud SQL offer serverless or auto-pause tiers that suit intermittent use better than manual stops. For databases that are truly unused, a snapshot followed by deletion removes both compute and storage cost, which a stop does not. Choose stop or auto-pause for intermittent use and snapshot-and-delete for genuine retirement.
The Cloud Waste Audit Framework includes the idle-database metric queries for all three clouds and the snapshot-first removal runbook. It is the downloadable companion to this article.
Frequently asked questions
How do I know if a managed database is idle?
A managed database is idle when it shows near-zero active connections, very low CPU utilization, and minimal read and write activity over a sustained window of at least two weeks. The clearest single signal is the database connections metric: a database with effectively no connections is serving no application. Combine connections with CPU and IOPS to avoid flagging a low-traffic but genuinely used database.
Which metrics identify an idle database on each cloud?
On AWS RDS and Aurora, use DatabaseConnections, CPUUtilization, and ReadIOPS and WriteIOPS in CloudWatch. On Azure SQL Database, use connection_successful, cpu_percent, and IO metrics in Azure Monitor. On Google Cloud SQL, use the connections, cpu utilization, and disk read and write metrics in Cloud Monitoring. The pattern is identical across clouds: near-zero connections plus low CPU and IO over a sustained window.
What should I do with an idle database?
It depends on the pattern. Rightsize a database that is used but oversized to a smaller instance class; pause or move to a serverless or auto-pause tier one that is used only intermittently; and snapshot then delete one that is genuinely unused. Always take a final snapshot before deletion so the data can be restored if the database turns out to be needed.
Can I just stop an idle managed database?
Sometimes, but with caveats. RDS lets you stop an instance, but it restarts automatically after seven days and storage still bills while stopped. Azure SQL and Cloud SQL offer serverless or auto-pause tiers better suited to intermittent use than manual stops. For databases that are truly unused, a snapshot and delete removes both compute and storage cost, which a stop does not.
The short version
Find idle managed databases across AWS, Azure, and GCP by inventorying every instance, pulling connection, CPU, and IO metrics over at least two weeks, and flagging near-zero connections with low CPU and IO. Confirm with the owner, then rightsize, pause, or snapshot-and-delete depending on the pattern. When you want every idle database across your clouds found and safely acted on, that is exactly what our rightsizing and waste elimination service delivers.
Written by Fredrik Filipsson and reviewed by Morten Andersen, applying the See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, Azure pricing ↗, Google Cloud pricing ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.