The AWS Services Most Companies Pay For but Barely Use | Savishty

The AWS Services Most Companies Pay For but Barely Use

Your AWS bill arrives.

EC2 looks expensive.

S3 has grown.

RDS is consuming a chunk of the budget.

Then you notice something strange:

Some of the charges aren't coming from workloads your team actively thinks about anymore.

An old EBS volume is still attached.

A NAT Gateway is processing almost no traffic.

A database is oversized “just in case.”

CloudWatch logs have been accumulating for months.

A test environment is running 24/7 even though nobody uses it after working hours.

This is one of the uncomfortable realities of cloud:

You don't always waste money because you're using too much cloud. Sometimes you waste money because you're paying for things you barely use.

AWS itself provides cost-optimization recommendations for idle resources, rightsizing, deleting unused resources, Savings Plans and other actions through Cost Optimization Hub. �

AWS Documentation +1

So let's look at some of the areas worth putting under the microscope.

1. EC2: The “Just in Case” Server

EC2 is often one of the first places businesses look when trying to reduce AWS costs.

But the problem isn't always the number of servers.

It's how those servers are sized and used.

A development environment might have:

8 vCPUs + 32 GB RAM

even though the workload barely uses:

1–2 vCPUs + 8 GB RAM.

Why?

Because someone originally thought:

“Let's give it some headroom.”

Then nobody revisited the decision.

AWS recommends ongoing rightsizing because workload requirements change over time, and its tools can identify underutilized EC2 resources. �

AWS Documentation +1

Ask yourself:

Is the instance consistently underutilized?

Does it need to run 24/7?

Could it be smaller?

Could it use a newer generation?

Could non-production environments be scheduled?

Sometimes the cheapest server is simply the one you don't need running.

2. EBS Volumes: The Storage You Forgot About

Here's a classic cloud cleanup problem.

A developer launches an EC2 instance.

It gets terminated six months later.

But the attached EBS volume survives.

Then another one gets created.

Then another.

Eventually:

Unused storage starts quietly generating a bill.

AWS specifically recommends identifying low-utilization EBS volumes and, where appropriate, snapshotting and deleting them. �

AWS Documentation

The dangerous part?

Nobody notices because the monthly cost of one volume may look insignificant.

But multiply that across:

100 volumes × 12 months.

That's when “small” becomes meaningful.

3. NAT Gateway: The Infrastructure Charge Teams Forget

NAT Gateway is extremely useful.

It allows resources in private subnets to communicate with external services.

But it can also become a surprisingly important cost driver.

AWS charges NAT Gateways based on hourly availability and the amount of data processed. �

AWS Documentation

Imagine an application generating significant outbound traffic.

The traffic goes:

Private EC2

↓

NAT Gateway

↓

Internet

Now you're paying for the NAT Gateway and its data processing.

AWS's current Cost Optimization Hub also includes NAT Gateway recommendations, and in 2026 AWS enhanced Trusted Advisor's unused NAT Gateway detection using additional utilization signals. �

AWS Documentation +1

The question isn't:

“Do we have a NAT Gateway?”

It's:

“Do we understand what is flowing through it and why?”

4. RDS: “Let's Buy a Bigger Database”

Databases are another place where teams often overprovision.

The logic usually sounds reasonable:

“It's production. We can't afford it to be slow.”

So someone chooses a large instance.

But workloads change.

Traffic changes.

Queries change.

Applications get optimized.

And the database may spend most of its time nowhere near its capacity limits.

AWS Cost Optimization Hub supports recommendations for RDS, Aurora and other database resources. �

AWS Documentation

Before upgrading the database, look at:

CPU

Memory

Connections

I/O

Storage

Query performance

Peak vs average usage

“Bigger” isn't the same thing as “better.”

5. Load Balancers: Still Running After the Application Is Gone

Here's another one that can hide in plain sight.

You deploy an application.

Create a load balancer.

Later:

The application is removed.

The load balancer remains.

Or you create separate load balancers for temporary environments that never get cleaned up.

AWS specifically identifies idle load balancers as resources that can contribute to unnecessary spending. �

Amazon Web Services, Inc.

A monthly infrastructure review should ask:

“Does every load balancer still have a business purpose?”

If nobody knows why it exists, investigate it.

6. S3: The “We'll Never Delete Anything” Problem

S3 makes storing data incredibly easy.

And that's exactly why businesses can accumulate enormous amounts of it.

Think about:

Old application logs

Temporary exports

Duplicate files

Old backups

Development data

Previous versions

Unused media

The problem isn't necessarily S3 itself.

It's data lifecycle management.

AWS recommends analyzing S3 access patterns and using lower-cost storage tiers or lifecycle policies where appropriate. �

AWS Documentation

Instead of:

Store forever → pay forever

you can design:

New Data

↓

Frequent Access

↓

Less Frequent Access

↓

Archive

↓

Delete (when policy allows)

The important word is policy.

Don't delete business-critical data just to save money.

7. CloudWatch: Observability Can Have a Bill Too

Monitoring is essential.

But “collect everything forever” isn't always a good strategy.

Companies can accumulate:

Application logs

Debug logs

Metrics

Traces

Events

without deciding:

How long do we actually need this?

You don't necessarily need the same retention period for:

Debug logs

as you do for:

Security or compliance logs.

The goal isn't to stop monitoring.

It's to make monitoring intentional.

Ask:

What are we collecting?

Why are we collecting it?

How long do we need it?

Who actually uses it?

Can noisy logs be reduced?

8. Development and Testing Environments

This might be one of the easiest wins.

Production runs 24/7.

Development doesn't always need to.

But many teams build environments like this:

Production → 24/7

Staging → 24/7

QA → 24/7

Development → 24/7

Testing → 24/7

Ask a simple question:

“Who is using this environment at 3 AM?”

If the answer is:

Nobody.

Then why is it running?

AWS recommends scheduling resources to match business demand and provides options for stopping resources during non-operating hours. �

Amazon Web Services, Inc.

9. Lambda: Small Cost, Huge Volume

Serverless can feel inexpensive because individual executions can be small.

But scale changes the calculation.

Imagine:

Millions of invocations

combined with:

High memory allocation

Long execution times

Inefficient code

Excessive logging

Unnecessary downstream calls

The result can become meaningful.

AWS Cost Optimization Hub includes Lambda rightsizing recommendations, so serverless workloads should be part of your optimization review too. �

AWS Documentation

The question isn't:

“Is Lambda cheap?”

It's:

“Is this Lambda workload efficient?”

10. Reserved Capacity and Savings Plans You Bought Too Early

Here's an interesting one.

Businesses sometimes optimize costs by committing to discounts.

That's normally a good thing.

But what happens if your workload changes?

You may end up paying for a commitment that doesn't match your actual usage.

AWS provides Savings Plans and reservation recommendations as part of its cost-management tooling, but these decisions should be based on actual usage patterns and expected demand. �

AWS Documentation

Don't commit simply because:

“The discount looks good.”

Commit when:

“We understand our baseline usage well enough to make the commitment.”

The Bigger Problem Isn't One AWS Service

Here's what I think companies often get wrong.

They look at the AWS bill and ask:

“Which service costs the most?”

That's useful.

But it isn't enough.

A better question is:

“Which resources aren't producing enough value for what we're paying?”

Because a $5,000 service that powers your core business may be completely justified.

A $500 service nobody uses is pure waste.

Your AWS Bill Is a Business Dashboard

Your cloud bill can tell you a lot about your organization.

For example:

Growing compute costs

Maybe the business is growing.

Or maybe infrastructure is poorly optimized.

Growing storage costs

Maybe you're accumulating valuable data.

Or maybe nobody has implemented lifecycle policies.

Growing database costs

Maybe traffic is increasing.

Or maybe the database is oversized.

Growing data-transfer costs

Maybe your architecture is evolving.

Or maybe systems are communicating inefficiently.

The bill isn't just an expense report.

It's a signal about your architecture.

A Simple Monthly AWS Cost Audit

You don't need a massive FinOps team to start.

Once a month, review:

Compute

Idle EC2

Oversized EC2

Unused ECS/Fargate resources

Lambda utilization

Storage

Unattached EBS

Old snapshots

S3 growth

Storage lifecycle policies

Networking

NAT Gateway usage

Data transfer

Load balancers

Unused public IP resources

Databases

Oversized RDS

Idle databases

Storage growth

Reserved capacity utilization

Commitments

Savings Plan utilization

Reservation utilization

AWS Cost Optimization Hub can consolidate recommendations across AWS accounts and Regions, including rightsizing, idle resources, Savings Plans and reservations. �

Amazon Web Services, Inc.

Don't Optimize Everything at Once

This is another mistake.

You don't need to spend three weeks saving $20.

Prioritize based on:

Potential savings × business impact × implementation effort

For example:

Opportunity

Potential Impact

Priority

Idle EC2 fleet

High

🔥 High

Oversized RDS

High

🔥 High

Unused NAT Gateway

Medium

High

Old EBS volumes

Medium

High

S3 lifecycle

Medium

Medium

Tiny unused resource

Low

Low

The goal isn't:

“Reduce every AWS charge.

The goal is:

“Eliminate meaningful waste without hurting reliability.

And Here's the Part Companies Often Miss

Cloud optimization isn't a one-time project.

You can reduce the AWS bill today.

Then six months later:

Traffic changes

New developers join

New services are launched

Data grows

Architecture changes

AI workloads arrive

And the waste comes back.

AWS itself describes rightsizing as an ongoing process because workload requirements change over time.

Amazon Web Services, Inc.

That's why mature organizations treat cloud cost optimization as an operating discipline, not a one-time cleanup exercise.

Final Thought

The most expensive AWS resource isn't necessarily the one with the highest price.

Sometimes it's the resource nobody remembers creating.

The server nobody uses.

The database that's massively oversized.

The storage nobody reviews.

The NAT Gateway nobody monitors.

The environment that runs all weekend.

The commitment nobody reassessed.

AWS gives you powerful tools to build almost anything.

But that freedom comes with a responsibility:

You have to manage what you build.

Because in the cloud, set it and forget it can quietly become pay for it forever.