Find and remove idle resources in Oracle Cloud

Why this matters

Idle resources in Oracle Cloud keep charging after the work stops. A stopped compute instance no longer bills OCPU and memory, but its boot volume and any reserved public IP still do. An unattached block volume bills for storage. A load balancer with no healthy backends bills at its shape rate. Object Storage buckets without a lifecycle policy keep every object at the standard tier. None of this appears as a line item named waste.

Idle resources also carry risk. An instance nobody owns still needs patching and still has a network path. A volume with old data is a copy of data you forgot about. A load balancer or security list that no one reviews widens the network surface. Removing idle resources cuts the bill and the attack surface at the same time.

The work is not a one-time project. Compartments multiply, test environments get built and abandoned, and autoscaling leaves volumes behind after scale-in. A monthly review keeps spend flat as usage grows, and it gives you a record of what changed when finance asks about the next bill.

Before you start

Get visibility first. You need read access to every compartment in the tenancy, not just your own. A group with read-only policies is better than using an administrator account for the sweep. You also need access to Billing and Cost Management to open Cost Analysis and Cost Reports. If you use defined tags for cost tracking, check that the tags are applied to resources and not only to compartments.

Define idle before you look. Idle is a decision, not a metric. Set rules per resource type: sustained low CPU and almost no network traffic on a compute instance across a window that covers your batch cycle, no read and write operations on a volume, no healthy backends and no traffic on a load balancer, no requests on a bucket. Use at least two weeks of data, and longer if you run monthly jobs.

Set the rules of engagement. Tell application owners what you plan to review and when. Check the change freeze calendar. List dependencies such as DNS records, backup jobs, disaster recovery pairs, and shared network gateways. Apply a freeform or defined tag like review=idle-candidate to every candidate so the decision is traceable.

How to do it

Start with the bill. Open Cost Analysis in Billing and Cost Management, set the range to the last full month, and group by compartment. Then group by service and by cost tracking tag. Export the report and mark the compartments and services where spend does not match known workloads. That list tells you where to sweep first.

Sweep by resource type. Compute and block storage are usually the largest and easiest wins. Networking comes next: load balancers, reserved public IPs, NAT gateways. Then databases, Object Storage, and backups. Tenancy Explorer and Resource Search let you query across compartments by type and lifecycle state instead of clicking through each one.

Confirm with metrics before you touch anything. The monitoring plugin of the Oracle Cloud Agent publishes CpuUtilization and MemoryUtilization to the Metrics service. If the agent is not enabled, enable it or use network and connection data instead. For volumes, read the volume metrics. For load balancers, check backend health and request counts.

Act in stages: tag, stop, wait, terminate. Stopping an instance preserves the boot volume and gives the owner time to object. When you terminate, decide whether to preserve the boot volume, then delete it separately if it is not needed. Remove backups and snapshots that belong to deleted resources.

1. Export last month's cost by compartment. Open Cost Analysis, set the range to the last full month, and group by compartment, then service. Export the report and mark compartments where spend is higher than the workload explains.
2. Run Cloud Advisor. Open Cloud Advisor and review the Cost Management recommendations. Treat each item as a lead, not a verdict, because its lookback period may differ from yours. Note the ones that match your bill review.
3. Check compute utilization. Pull CpuUtilization and MemoryUtilization for every instance over at least two weeks. Flag instances with sustained low CPU, little traffic, and no known owner. Confirm the monitoring plugin is reporting before you trust a low number.
4. Find unattached volumes. Search for block volumes in the AVAILABLE state, which means no attachment. Check boot volumes left behind by terminated instances. Record size and creation date for each candidate.
5. Audit networking. List load balancers with no healthy backends, reserved public IPs that are not assigned, and gateways no route table references. Check route tables first, because one gateway can serve several subnets.
6. Review databases, buckets and backups. Check Autonomous Databases and DB systems for instances with no recent connections. Find buckets without a lifecycle policy and old backups that belong to deleted resources.
7. Stop, wait, then terminate. Stop instances and non-production databases where the platform allows it, then wait through an agreed period such as one billing cycle. Notify owners before removal. Terminate, delete the boot volume and reserved IP, and record the change.

How to check it worked

Re-run the same Cost Analysis view after a full month and compare usage quantities, not just totals. Compute hours for a terminated instance should fall to zero. Block storage for a deleted volume should disappear. Check each service you touched, one at a time.

Re-run your Resource Search queries. Volumes in the AVAILABLE state should be gone or accounted for. Cloud Advisor should clear the recommendations you acted on. If a recommendation returns, something recreated the resource, and you need to find the automation or the person behind it.

Check that nothing broke. Review alarm state, application health checks, backup completion, and DNS for the workloads you changed. Read the Audit service log for terminate and delete calls and match them to change tickets. Then put the next sweep on the calendar, because idle resources return every month.

Mistakes to avoid

Deleting an instance without checking the preserve boot volume option. The boot volume can be terminated along with the instance, and any local data goes with it. Stop first, take a snapshot if there is doubt, and keep the boot volume for a short period.

Assuming stopped means free. A stopped instance still bills for its boot volume, and an unattached reserved public IP still bills. Stopped instances also count against service limits and can block a deployment in a compartment that looks full.

Removing shared network plumbing. A NAT gateway, service gateway, or dynamic routing gateway may serve several subnets. Check route tables and every resource that references the gateway before you delete it. The same caution applies to security lists and network security groups.

Skipping the owner conversation. Deleting a resource that a team planned to use next quarter costs more in rebuild time than it saves. Tag candidates, publish the list, set a removal date, and let owners respond. If you want a second set of eyes, the Cloud cost audit package from Cloudverg is a two-week, read-only review at a $4,500 fixed price, and it ranks idle resource findings alongside rightsizing and commitment options. It is one option among several for teams that need a credible plan before they delete anything.

Frequently asked questions