AWS Cost Optimization: How to Find Cloud Resources You Are Paying For but No Longer Need

The fastest way to reduce an AWS bill is also the fastest way to cause an outage: find something that looks idle, and delete it.

The short answer: AWS cost optimization is not indiscriminate cost cutting. It means finding infrastructure that is unused, oversized or unnecessarily expensive, proving with evidence why it exists and whether anything still depends on it, and only then reducing spend. Detecting waste and deciding to delete are two different steps, and most cost-cutting incidents happen when a team collapses them into one.

AWS itself frames cost optimization as delivering business value at the lowest appropriate price point, not as minimizing the invoice. That distinction is where most cleanup projects succeed or fail.

An unattached storage volume is usually a straightforward cleanup candidate. An EC2 instance sitting at 2 percent CPU may run a critical scheduled process once a month. A database with almost no connections today may carry quarter-end reporting next week. The saving is real in each case. The deletion decision is not the same in any of them.

What does AWS cost optimization actually mean?

AWS cost optimization is the continuous process of matching cloud spend to the capability the business actually needs.

In practice it covers six different actions, and only one of them is deletion:

1. removing infrastructure that is no longer required,
2. stopping or scheduling resources that do not need to run around the clock,
3. rightsizing resources whose configured capacity exceeds the workload,
4. changing configuration or architecture so the same function costs less,
5. using a pricing model that fits a usage pattern you have already validated,
6. improving visibility and ownership so avoidable spend does not rebuild itself.

The important word is continuous. An environment that was correctly sized six months ago can be wasteful today because customers, teams, deployment patterns and data volumes have all moved since then. Cost optimization is an operating discipline, not an annual clean-up.

Why do AWS bills keep growing when workloads do not?

Cloud infrastructure is easy to create and easy to forget. A developer spins up a test environment. A migration completes and leaves the old estate running. A project ends while its volumes, snapshots, addresses and networking components stay behind. A production system is scaled up for a traffic peak and never scaled back down.

Bills therefore grow for four fundamentally different reasons, and each one calls for a different response.

1. Genuine business growth. More users, data and transactions legitimately consume more infrastructure. That is not a cost problem in itself. The question is whether unit economics still hold, which is the same question behind any serious cloud cost comparison.

2. Overprovisioning. The resource is needed, but the configured capacity is larger than the workload requires. The fix is rightsizing, not removal.

3. Idle or abandoned infrastructure. The resource is no longer delivering business value at all. This is the first place most teams look, and the place where most mistakes get made.

4. Architectural cost. Every resource is genuinely in use, yet the design is still more expensive than it needs to be. Network paths, log ingestion and retention, storage class choices, always-on non-production environments and managed-service selection all sit in this category.

An AWS cost review that only asks "which resource is expensive?" will find the fourth category last, if at all. The better question is: what business function does this cost support, and is there a cheaper way to support the same function safely?

Which AWS resources should you check for unnecessary spend?

There is no single resource type responsible for cloud waste. AWS idle-resource recommendations already span compute, storage, database, networking and managed services, and each category is judged on its own activity signals rather than one generic idle rule.

A practical sweep should cover the following.

Idle and oversized EC2 instances

Has it been running continuously? What do CPU and network show over a full cycle? Is it production, staging or a leftover development box? Does it run a scheduled or infrequent job? Is it oversized rather than unnecessary? Who owns the workload? Low utilization here usually points at rightsizing, not termination.

Unattached EBS volumes and orphaned snapshots

An unattached volume is a strong candidate, but unattached is not the same as unimportant. Check whether it holds data under retention, a recovery copy, migration data, or a deliberately detached workload. Snapshots deserve their own pass: an old snapshot that no longer backs an AMI and whose source volume is gone is a much safer target than one that is still someone's restore path. Storage waste is also not limited to orphans, since a volume can be attached, in use, and still provisioned for IOPS and throughput the workload never touches.

Idle RDS and Aurora databases

A database can look lightly used and still be business critical. Look at connections, CPU, I/O, storage growth, replica and standby roles, and the workload calendar. For databases, business context should outweigh any single utilization metric. Note also that a stopped instance is not a free instance: compute stops billing, storage does not.

NAT Gateways carrying no traffic

Networking is easy to overlook because attention goes to compute and databases first. A NAT Gateway carrying almost no traffic is worth investigating, but route tables and private-subnet egress paths must be validated before it is removed.

Unassociated Elastic IPs and idle load balancers

Both routinely outlive the workloads that needed them. An unassociated Elastic IP is a common finding, and a load balancer with zero registered targets, or targets that are all unhealthy, is another. Treat Elastic IP release with particular care: it is irreversible, and an address attached to a temporarily stopped instance is not the same as an abandoned one.

Quiet networking and edge services

Interface VPC endpoints, VPN connections, Transit Gateway attachments, Client VPN endpoints and disabled CloudFront distributions all keep billing while producing no traffic. They rarely appear on anyone's dashboard because nobody remembers creating them.

Always-on non-production environments

Development, QA, staging, demo and migration environments deserve a separate review with a different question. Not "should this environment exist?" but "does it need production-sized infrastructure running 24x7?" The answer usually leads to scheduling and scaling changes rather than deletion.

Why does low utilization not mean a resource is safe to delete?

Because utilization is evidence, not intent.

Monitoring can tell you what a resource has been doing. It cannot tell you why the business created it, or what will be asked of it next month.

Consider three EC2 instances, all showing 2 percent average CPU:

• Instance A is a forgotten development server from a project that ended six months ago.
• Instance B is a disaster-recovery node that is designed to sit idle until the day it is needed.
• Instance C is a reporting server that runs a heavy workload for two days at month-end.

The metric is identical. The correct decision is different in all three cases, and only context separates them. This is also why AWS applies resource-specific criteria and lookback periods to idle recommendations instead of scoring every resource from one metric and one time window.

It helps to keep the vocabulary strict, because "idle" is a technical finding while "removable" is an operational decision:

Classification	What it means	Likely action
Idle	Little or no observed activity over the window	Investigate why it exists
Underutilized	In use, but capacity materially exceeds need	Rightsize or reschedule
Unowned	No team or person claims responsibility	Escalate before acting
Redundant	Another resource already provides the function	Consider removal
Removable	Evidence and context both support removal	Plan a reversible removal

The two-level rule that prevents most cleanup incidents

Almost every bad cost-cleanup decision has the same shape. A verdict is made from a level-1 signal: a point-in-time state, or the mere existence of an attachment.

"The Elastic IP is associated, so keep it." "The volume is attached, so it is in use." "The WAF is attached, so it matters." "The instance is stopped, so release its address." Each of these sounds reasonable and each is wrong, because none of them asks the level-2 questions:

1. Next-hop health. Is the thing it is attached to, or depends on, itself alive? An Elastic IP attached to an idle instance, or a web ACL attached to a disabled distribution, is a dead chain that still bills.
2. Usage over the window. Across a representative period, is it actually carrying work, or are its metrics flat?
3. Recency and duration. How long has it been in this state? An instance stopped this morning is probably a scheduled shutdown. One stopped for four months is probably abandoned.

Level-1 signal	Naive verdict	Level-2 question that changes the answer
EBS volume is attached	In use, keep	Is the instance it is attached to running and doing work?
Elastic IP is associated	Keep	Is the associated instance active, idle, or stopped, and for how long?
Load balancer exists	Serving traffic	Are any targets registered, and are any of them healthy?
Web ACL is attached	Protecting something	Is the resource it protects enabled and receiving requests?
Instance is stopped	Safe to clean up	Stopped for how long, and is the storage or address still billing?

What evidence should you collect before removing an AWS resource?

Four kinds of evidence, in this order.

1. Cost evidence. What does the resource actually cost, how has that changed, and is the amount material enough to justify engineering time? Cost Explorer is the source of truth for spend. Per-resource estimates are useful for ranking, not for reporting savings. Do not spend three engineering days eliminating a rounding error while a larger opportunity sits untouched.

2. Activity evidence. The right signal depends on the resource: CPU and network for instances, connections and I/O for databases, bytes processed for NAT Gateways and VPC endpoints, request counts and target health for load balancers, attachment state for volumes and addresses, last-accessed dates for secrets. One metric is never the whole model of a workload.

3. Dependency evidence. What calls this resource? What route points at it? What application references it? Is it part of a failover path? Does infrastructure as code still define it, so that deleting it by hand simply recreates it on the next apply? A resource can show almost no direct activity and still be load-bearing.

4. Business context. Who owns it? Why was it created? Is the project still active? Is it retained for audit, recovery or regulatory reasons? Is the workload seasonal? What breaks if it disappears? This is the layer that telemetry cannot infer, and it is why fully automated deletion is a poor default.

A useful discipline here: absence of a signal is not evidence of non-use. If a resource has no metrics because nothing was ever monitoring it, the honest verdict is "investigate, and start collecting", not "unused".

The AWS cost optimization decision framework

AWS billing and cost data
          +
Resource inventory (every region, every account)
          +
Activity evidence over a representative window
          +
Dependency, ownership and business context
          |
          v
Optimization finding
          |
          v
Confidence classification    ->    Financial impact
          |
          v
Human validation where the blast radius warrants it
          |
          v
KEEP  /  STOP  /  SCHEDULE  /  RESIZE  /  DELETE
          |
          v
Verify workload health, then verify the bill actually fell

The separation that matters most sits in the middle of that diagram: the system that detects cost waste does not need to be the system authorized to change production infrastructure. Keeping discovery strictly read-only, and putting change behind normal engineering controls, removes an entire class of risk from cost work without slowing the analysis down.

What does a safe AWS cost optimization workflow look like?

Step 1: Start from the bill, not the console

Understand spend by account, service, region, environment and team wherever allocation exists. Browsing resources at random finds small things and misses large ones.

Step 2: Build the candidate inventory

Idle resources, underutilized resources, unattached resources, abandoned environments, resources with no owner, and services whose spend looks disproportionate to their role.

Step 3: Gather evidence over a representative window

A workload that is quiet on Tuesday morning may be critical on Friday night, and a month-end job is invisible in a seven-day view. Match the window to the workload cycle.

Step 4: Classify confidence, not just cost

High confidence means no meaningful activity across a representative window, a known owner, and no identified dependency. Medium confidence means some activity exists or ownership is unclear. Low confidence means one weak signal, a poorly understood workload, or a large blast radius. Low-confidence findings are research tasks, not work items.

Step 5: Choose the action deliberately

Keep, stop, schedule, resize, change storage class, scale in, delete, or redesign. Deletion is one option among eight, and often not the best return.

Step 6: Define the rollback before the change

Snapshot the volume, take a final RDS snapshot, capture the AMI, record the route table state, keep the infrastructure-as-code definition, agree a maintenance window. Anything irreversible, such as releasing an Elastic IP, deserves an explicit decision rather than a batch action.

Step 7: Verify twice

Confirm the workloads still behave correctly, then confirm the saving actually appeared on the next bill. A recommendation that was never applied and a change that never reduced cost look identical in a spreadsheet.

The objective is not a list of recommendations. It is durable cost reduction that does not degrade reliability, which is the same standard we hold cloud architecture and operations work to.

When "nothing found" actually means "could not look"

A cost report is most dangerous when a gap looks like a clean bill of health.

Two blind spots account for most of it.

Permissions gaps. If the scanning role cannot call an API, the honest output is "not checked", not "nothing found". A report that says no web ACLs exist because the caller lacked permission to list them is worse than no report, because it manufactures confidence. Any tool or process you rely on should state explicitly which resource types it could not inspect and which permissions it needed.

Coverage gaps against the bill. Inventory-driven reviews only find the resource types someone thought to look for. Reconciling the inventory against actual Cost Explorer spend exposes the rest: an S3 line item, a Route 53 charge, a CloudWatch ingestion bill, an ECS or EKS cluster that no resource sweep covered. Start from the money and the gaps announce themselves.

Both are worth checking on any cost tooling you adopt, including your own scripts. When ITMTB reviews an AWS estate, the list of resource types the scan could not inspect is part of the deliverable, and both blind spots fall inside the scope of a broader technology stack audit when the estate has grown faster than its documentation.

Which AWS tools already help with cost optimization?

Before adding another layer, use what AWS already provides.

AWS Compute Optimizer analyzes resource configuration and CloudWatch utilization metrics to produce rightsizing recommendations and identify idle resources, with resource-specific criteria and lookback periods per category.

AWS Cost Optimization Hub consolidates optimization opportunities across AWS services, including rightsizing and idle-resource recommendations, with estimated savings in one place.

AWS Support cost optimization checks cover conditions such as overprovisioned EBS volumes, low-utilization EC2 instances, idle load balancers, idle databases and unassociated Elastic IP addresses.

Cost Explorer, budgets and anomaly detection answer the first question of any review: where is the money going, and what changed.

These are genuinely useful, and the remaining problem is rarely a shortage of signals. It is turning many technical signals into a prioritized review that a team can act on, with enough evidence attached to each finding that someone is willing to approve the change.

Where Cloud Cost Sentinel fits

Cloud Cost Sentinel is one of the self-serve tools ITMTB ships through TomorrowCentral. It scans an AWS account through a scoped role you can revoke at any time, ranks the top cost offenders, and returns a verdict per resource with the evidence behind it.

Three design decisions are worth borrowing whether or not you use the tool:

Discovery is read-only. The scan and analysis paths never call a mutating AWS API. Nothing that finds waste is able to cause an outage.

Verdicts carry their evidence, and missing evidence is its own verdict. Every resource comes back as keep, investigate or removable. A resource with no usable metrics is investigate plus a recorded monitoring gap, never a silent removable. Protective tags such as keep, prod or do-not-delete veto an automatic removable verdict outright.

Deletion is gated, reversible and separate. Removal requires the verdict and an explicit approval list and a confirmation flag, takes a backup first where the resource type supports one, and refuses rather than forces unsafe deletes such as a deletion-protected RDS instance.

The tool is also exposed over MCP, so an agent can request an AWS cost analysis without holding permission to change anything, which is the agent-facing distribution question more software companies are now facing. That is the right shape for agentic operations generally: give the agent the read-only tool, keep the write path behind approval. It is the same principle we apply when building governed agent workflows on Orchestrik, where what an agent is allowed to do matters more than what it is able to see.

The result is that finding potential waste gets much cheaper, without pretending that every recommendation should be executed automatically.

What usually goes wrong during AWS cost optimization?

Treating low CPU as proof of waste. CPU is one signal and a poor model of workload value on its own. Network activity, connections, request counts and the workload calendar all carry information CPU does not.

Deleting before understanding dependencies. A resource can look unused from the compute perspective while remaining essential to networking, recovery or batch processing.

Observing for too short a window. Daily, weekly, monthly, quarterly and seasonal workloads behave differently. The window has to cover the cycle, or the evidence proves nothing.

Chasing the largest number instead of the highest confidence. A small, well-understood cleanup beats a large, poorly understood change. Rank by cost and confidence together.

Buying commitments before cleaning the baseline. Savings Plans and Reserved Instances reward stable, intentional usage. Committing to a baseline that still contains waste locks in the waste for one to three years.

Treating optimization as a one-time exercise. Environments keep changing: projects finish, workloads move, capacity requirements shift. The teams that stay optimized run this as a recurring review, usually as part of managed cloud operations rather than as an annual project.

AWS cost optimization checklist

Cost visibility

• Identify the services and accounts driving the largest spend.
• Separate genuine workload growth from avoidable waste.
• Review cost by account, region and environment.
• Identify unallocated or unowned spend.

Resource analysis

• Review idle-resource and rightsizing recommendations.
• Review unattached volumes and orphaned snapshots.
• Review databases with near-zero connections.
• Review networking: NAT Gateways, load balancers, Elastic IPs, VPC endpoints, VPN and Transit Gateway attachments.
• Review non-production environments running around the clock.
• List the resource types your scan could not inspect, and why.

Evidence

• Use an observation window that covers the workload cycle.
• Check the metrics appropriate to each resource type, not just CPU.
• Apply the level-2 check: is the next hop alive, used and stable?
• Identify the owner.
• Check application, networking and infrastructure-as-code dependencies.
• Estimate the financial impact before spending engineering time.

Remediation

• Classify confidence before acting.
• Choose stop, schedule, resize, delete or keep deliberately.
• Define rollback for every consequential change.
• Take backups where the resource type supports them.
• Obtain approval where the blast radius warrants it.
• Monitor workloads after the change.
• Confirm the expected saving appeared on the next bill.

Continuous control

• Repeat the analysis on a schedule.
• Assign cost ownership by team or environment.
• Set a lifecycle expectation when new infrastructure is created.
• Revisit rightsizing after major workload changes.

Frequently asked questions about AWS cost optimization

What is AWS cost optimization?

AWS cost optimization is the process of reducing unnecessary AWS spend while preserving the performance, reliability and capability the business needs. It includes removing infrastructure that is no longer required, stopping or scheduling resources that do not need to run continuously, rightsizing overprovisioned resources, and improving how infrastructure is operated and owned.

How do I find unused resources in AWS?

Start from the bill so you know which services and accounts matter, then inventory the usual candidates: unattached volumes, orphaned snapshots, idle instances and databases, NAT Gateways with no traffic, unassociated Elastic IPs, load balancers with no healthy targets, and always-on non-production environments. Validate each one against resource-specific activity metrics over a representative window, then check dependencies and ownership before removing anything.

Does low EC2 CPU mean I should terminate the instance?

No. Low CPU can indicate a rightsizing opportunity, but the same 2 percent average can describe an abandoned development box, a standby disaster-recovery node, or a reporting server that runs a heavy job once a month. Check network activity, the workload calendar, dependencies and ownership first.

What is the difference between an idle and an underutilized AWS resource?

An idle resource shows little or no meaningful activity. An underutilized resource is genuinely in use but has more capacity than the workload needs. Idle resources are candidates for stopping, scheduling or removal. Underutilized resources are usually candidates for rightsizing.

How long should I observe a resource before deciding it is unused?

Long enough to cover the workload's natural cycle. A full week catches weekday and weekend patterns, but month-end reporting, quarterly close, seasonal traffic and annual audit workloads need longer. If the window is shorter than the cycle, the data cannot support a deletion decision no matter how flat the graph looks.

Should AWS cost optimization be automated?

Analysis and evidence collection should be automated, because they are repetitive and read-only. Production changes should be automated only where the organization understands the blast radius, the permissions involved, the approval path and the rollback. Automated discovery with human approval before deletion is a safe default.

Can AI agents help with AWS cost optimization?

Yes, for querying analytical tools, collecting evidence, summarizing findings and prioritizing review. The design question is what permissions the agent and its tools hold. Read-only analysis can be exposed to an agent safely, while deletion stays behind separate approval and execution controls the analysis tool does not have.

Key takeaways

• AWS cost optimization is about spending appropriately, not about cutting the bill at any cost.
• Idle detection is the start of a review, not the deletion decision.
• Cost, activity, dependency and business context all have to line up before a resource is removed.
• Never decide from a level-1 signal alone: check next-hop health, usage over the window, and how long the state has held.
• Different resource types need different signals and different observation windows.
• The right action is often stop, schedule or resize rather than delete.
• Discovery should be read-only, and deletion should be gated, backed up and reversible where possible.
• A report that cannot say what it failed to inspect is not a clean bill of health.
• The teams that stay optimized treat this as a recurring operations discipline.

Sources

1. AWS Well-Architected Framework, Cost Optimization Pillar
2. AWS Compute Optimizer user guide
3. AWS Compute Optimizer idle resource recommendations
4. Identifying opportunities with AWS Cost Optimization Hub
5. AWS Support cost optimization checks