Where Your AWS Bill Really Goes: 7 Costs We Find in Almost Every Review
By Motti Dadison · October 13, 2026 · 7 min read
Most AWS accounts do not have one big cost problem. They have many small ones that together are 20-40% of the bill. Here are the seven we find most often, how to find them yourself in less than an hour, and how to fix each one.
When we start a FinOps review, the client usually expects us to find one big problem. In practice, we almost always find many small ones. Each of them looks unimportant on its own, but together they are often 20–40% of the monthly AWS bill .
This article lists the seven costs we find in almost every AWS account we review, how to find them yourself in less than an hour, and what to do about each one. Prices are AWS list prices for us-east-1 at the time of writing. Other regions, including il-central-1 (Tel Aviv), are usually more expensive, so the savings there are bigger.
Before you start: look at the bill by usage type
The default Cost Explorer view groups costs by service. That view hides most of the problems in this list, because "EC2-Other" mixes NAT Gateways, EBS volumes, snapshots, data transfer and public IP addresses into one line.
Open Cost Explorer, choose the last full month, and group by Usage type . Sort by cost. The top 20 lines usually tell you where to look first.
1. Compute that is idle or too large
This is the biggest item in most accounts. Typical examples:
Development and staging environments that run 24 hours a day, 7 days a week, but are used only during working hours.
Instances that were sized for a peak load that never came, with average CPU usage under 10%.
Old instance generations (for example m5 instead of m7g or m7i ), which give less performance for the same price.
How to find it: turn on AWS Compute Optimizer (it is free) and wait about 14 days for data. Then:
aws compute-optimizer get-ec2-instance-recommendations \ --query 'instanceRecommendations[?finding==`OVER_PROVISIONED`].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType]' \ --output table
What to do: stop non-production environments outside working hours (a working week is 50 hours out of 168, so this alone saves about 70% of their compute cost). Resize over-provisioned instances one step at a time. Where your software supports ARM, move to Graviton instances, which are usually about 20% cheaper for the same work.
2. NAT Gateway data processing
A NAT Gateway costs about $0.045 per hour plus $0.045 for every GB that goes through it. The hourly part is small. The data part can be very large, because traffic from private subnets to AWS services also goes through the NAT Gateway, unless you stop it.
We often find workloads in private subnets that read and write terabytes per month to S3 or pull container images from ECR, all through the NAT Gateway.
How to find it: in Cost Explorer, filter usage type by NatGateway-Bytes . If this line is more than a few hundred dollars, look further.
What to do:
Add VPC gateway endpoints for S3 and DynamoDB. They are free, and traffic to these services then does not go through the NAT Gateway.
For heavy use of ECR, CloudWatch or other services, compare the cost of interface endpoints with the NAT data cost. Above a few TB per month, the endpoint is usually cheaper.
Use VPC Flow Logs to find which workloads send the most data through the NAT Gateway.
3. Traffic between Availability Zones
Data that moves between Availability Zones in the same region costs $0.01 per GB in each direction . This sounds small, but chatty microservices, databases with replicas in other zones, and Kafka clusters can move hundreds of TB per month.
How to find it: filter usage type by DataTransfer-Regional-Bytes .
What to do: keep high availability, but avoid cross-zone traffic that has no purpose. In Kubernetes, use topology-aware routing so that services prefer endpoints in the same zone. For Kafka, configure consumers to fetch from the nearest replica ( client.rack ). Check that your load balancers do not send traffic to other zones without a reason.
4. Storage that nobody uses
Three types of storage collect over time:
Unattached EBS volumes , left behind when an instance was deleted. You pay for them every month.
gp2 volumes. gp3 costs about 20% less per GB ($0.08 compared to $0.10 per GB-month) and gives better baseline performance. The change is online and has no downtime.
Old EBS snapshots , often created by backup jobs without a retention rule.
How to find it:
# Unattached volumes aws ec2 describe-volumes --filters Name=status,Values=available \ --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output table # gp2 volumes that can move to gp3 aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \ --query 'Volumes[].[VolumeId,Size]' --output table # Snapshots older than a date you choose aws ec2 describe-snapshots --owner-ids self \ --query 'Snapshots[?StartTime<=`2025-10-01`].[SnapshotId,VolumeSize,StartTime]' --output table
What to do: take a final snapshot of unattached volumes if you are not sure, then delete them. Change gp2 to gp3. Use Amazon Data Lifecycle Manager or AWS Backup with a clear retention period, and move long-term snapshots to the archive tier.
5. CloudWatch Logs with no retention
By default, a CloudWatch log group keeps data forever . Ingestion costs about $0.50 per GB and storage about $0.03 per GB-month . A debug-level application log that nobody reads can cost more than the application itself.
How to find it:
aws logs describe-log-groups \ --query 'logGroups[?!retentionInDays].[logGroupName,storedBytes]' --output table
What to do: set a retention period on every log group (for example 14 or 30 days for application logs, longer only where an audit rule needs it). Lower the log level in production. For high-volume logs, consider the Infrequent Access log class, or send the logs directly to S3.
6. Too little Savings Plans coverage
Savings Plans give a discount of up to 72% for a commitment to a fixed amount of compute spend per hour, for one or three years. Many companies either have no commitment at all, or bought one years ago and never updated it while their usage grew.
How to find it: in Cost Explorer, open Savings Plans → Coverage . If coverage of steady compute is below about 70%, you are paying list price for usage that is predictable.
What to do: first remove waste (items 1–5), because a commitment on waste locks the waste in. Then buy Compute Savings Plans in small steps, for example every month or every quarter, so that the commitment follows your real usage. Use Spot instances for workloads that can stop at any time, such as CI runners and batch jobs.
7. Public IPv4 addresses
Since February 2024, AWS charges $0.005 per hour for every public IPv4 address, including addresses attached to running instances. That is about $3.60 per address per month. An account with a few hundred public addresses pays thousands of dollars per year for them.
How to find it: use the Public IP Insights view in Amazon VPC IP Address Manager, or list Elastic IPs that are not attached:
aws ec2 describe-addresses \ --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' --output table
What to do: release Elastic IPs that are not in use. Put instances in private subnets behind a load balancer. Turn off "auto-assign public IP" on subnets that do not need it.
One more: EKS clusters on old versions
An EKS cluster costs $0.10 per hour while its Kubernetes version is in standard support. When the version moves to extended support, the price goes up to $0.60 per hour , six times more. If you have several clusters that are behind on upgrades, check their versions.
Summary
None of these changes needs a new architecture, and most can be done in a few days. The order matters: remove waste first, then commit to what is left.
Want to know what this means for your bill?
Use our FinOps savings calculator to get an estimate in one minute. If you want exact numbers, book a free review: we go through your real billing data and send you a list of what to fix first, ordered by savings. More about our FinOps service .
Topics: FinOps, AWS, Cost Optimization, Cloud