Why Is My AWS Bill So High? Causes & Fast Fixes

A jump in the AWS bill doesn't necessarily mean the business is growing. Some of the sharpest increases I investigate come from a single deployment that changed how something behaves - and they can be fixed without reducing capacity or touching reliability.

This guide shows how to diagnose an AWS bill spike, walks through a typical investigation from the first Cost Explorer view to the fix, and lists the causes I check most often.

Short answer: group the bill by service and then by usage type in Cost Explorer, compare daily spend with the previous period, and drill into the Cost and Usage Report when the cause isn't obvious. Then connect the cost to a specific workload and deployment - that is what turns "the bill went up" into something an engineer can fix.

A typical bill spike: +40% from one deployment

An illustrative case, representative of what these investigations find: a SaaS company's AWS bill rose about 40% month over month, with no comparable increase in customer traffic.

How the cause was found

1. Cost Explorer, grouped by service: CloudWatch accounted for most of the increase.
2. Grouped by usage type: the increase was log ingestion, not storage, metrics or a pricing change.
3. Log investigation: the extra volume came from a recently deployed service emitting repetitive debug messages.

The important step was the last one. Telling an engineering team that "logging costs are too high" changes nothing; showing them which service, which deployment and which messages gives them something to fix.

The fix

1. Remove unnecessary debug output and repetitive log messages at the source.
2. Review log levels, and sample high-volume events instead of logging every one.
3. Set retention policies on the log groups involved.
4. Add monitoring on log ingestion volume and on spending anomalies, so the next one is caught in days.

Retention alone would not have solved it. Retention limits how long logs are stored; it does nothing about what is ingested, and ingestion was the expensive part.

How quickly the bill came down

Once the excessive logging stops, ingestion charges fall straight away. The monthly bill takes longer to reflect it, depending on where in the billing cycle the fix lands. Verify with the daily ingestion volume and cost before and after the fix, then confirm in the next billing report.

Why logging can move a bill by 40%

CloudWatch Logs charges per GB ingested - $0.50 per GB for the Standard log class in us-east-1 at the time of writing, plus a much smaller monthly storage charge (see CloudWatch pricing). Ingestion adds up faster than intuition suggests. As pure arithmetic:

500 requests/second x 2 KB of log per request = ~1 MB/s
1 MB/s x 730 hours x 3,600 s = ~2,628 GB a month
2,628 GB x $0.50/GB = ~$1,314 a month in ingestion alone

One verbose service at moderate traffic is enough. For logs you rarely query, the Infrequent Access log class halves the ingestion price - but logging less is still the bigger lever.

How to diagnose a high AWS bill

1. Cost Explorer, grouped by service. Compare the last three months side by side. The service with the largest increase - not necessarily the largest total - is usually the cause.
2. Group by usage type. This separates, for example, CloudWatch Logs ingestion (DataProcessing-Bytes) from log storage (TimedStorage-ByteHrs), or NAT processing (NatGateway-Bytes) from cross-AZ transfer (DataTransfer-Regional-Bytes).
3. Switch to daily granularity. A step change on one day usually lines up with a deployment; a steady ramp points to growth or a leak.
4. Drill into the Cost and Usage Report when you need the resource. In CUR, CloudWatch Logs ingestion is attributed to the log group:

SELECT line_item_resource_id AS log_group,
       SUM(line_item_unblended_cost) AS cost
FROM cur
WHERE line_item_product_code = 'AmazonCloudWatch'
  AND line_item_usage_type LIKE '%DataProcessing-Bytes%'
  AND date(line_item_usage_start_date) >= current_date - INTERVAL '30' DAY
GROUP BY 1
ORDER BY cost DESC
LIMIT 10;

Without CUR, the per-log-group IncomingBytes metric gives the same answer in volume rather than dollars (see CloudWatch Logs metrics):

aws cloudwatch get-metric-statistics --namespace AWS/Logs --metric-name IncomingBytes \
  --dimensions Name=LogGroupName,Value=/ecs/new-service \
  --start-time 2026-10-01T00:00:00Z --end-time 2026-10-08T00:00:00Z \
  --period 86400 --statistics Sum

Finally, turn on AWS Cost Anomaly Detection. It baselines spend per service and alerts on deviations, which is how a spike like the one above gets caught in days instead of at the end of the month.

The causes I check most often

1. Logging volume. Verbose or debug logging shipped to production, as in the case above - and log groups left on the default "never expire" retention.
2. NAT Gateway processing. Every GB through a NAT Gateway pays a processing charge, including traffic to S3, ECR and other AWS services that a VPC endpoint could carry instead. See the NAT Gateway cost guide.
3. Data transfer. Cross-AZ traffic between chatty services, inter-region replication and internet egress. See AWS data transfer costs.
4. Oversized EC2 and RDS instances sized for a peak that never repeated. See EC2 rightsizing and RDS right-sizing.
5. Forgotten resources. Unattached EBS volumes, idle load balancers, unused Elastic IPs and snapshots of instances deleted long ago.
6. Runaway scaling. A retry loop, a deployment bug or bot traffic pushing Auto Scaling groups or Lambda concurrency far past normal.
7. DynamoDB in the wrong capacity mode for its traffic shape. The DynamoDB capacity calculator shows which mode is cheaper.
8. S3 data that never moves tier, stored in Standard long after anyone reads it.
9. Redundancy applied everywhere. Multi-AZ databases and cross-region replicas in environments that don't need them.
10. Expired commitments. A Savings Plan or Reserved Instance term ends and the same usage quietly reverts to on-demand rates.

Fixes you can apply today

• Set retention on every log group, and lower log levels on the noisiest services.
• Delete unattached EBS volumes, unused Elastic IPs and orphaned snapshots.
• Add VPC gateway endpoints for S3 and DynamoDB - they're free and take that traffic off the NAT Gateway.
• Turn on Cost Anomaly Detection and a budget alert, so the next spike reaches you within a day or two.
• Check commitment expiry dates in the Savings Plans and Reserved Instances consoles.

FAQ

How do I see what's driving my AWS bill up?

In Cost Explorer, group by service and then by usage type, and compare the current month with the previous two at daily granularity. The service and usage type with the largest increase - not the largest total - is usually the driver.

Can a single deployment really spike the bill?

Yes. A change in log verbosity, retry behaviour, scaling configuration or network routing can add hundreds or thousands of dollars a month without any change in traffic. Daily cost data lined up against deployment dates usually shows the step.

Does setting log retention reduce CloudWatch costs?

It reduces storage costs. It does not reduce ingestion costs, which are charged per GB as logs arrive - for those, you have to log less at the source.

Why is my AWS bill so high even though traffic hasn't grown?

Look for changes in behaviour rather than load: a new service's logging, retries, a scaling policy, data moving through a NAT Gateway, an expired commitment, or resources left running after a project ended.

Is AWS Cost Anomaly Detection worth enabling?

Yes. It costs nothing extra to enable, baselines your normal spend per service, and alerts on deviations - usually days before the invoice would have shown the problem.

Want the spike traced for you?

Finding which workload and which deployment caused a cost increase is the first step of every AWS cost optimization engagement I run. The full method is in the AWS cost optimization guide, and the reporting that catches spikes early is in what FinOps actually reports.

Sources

• Amazon CloudWatch pricing - log ingestion and storage rates
• CloudWatch Logs metrics - IncomingBytes per log group
• CloudWatch Logs log classes
• AWS Cost Explorer and AWS Cost Anomaly Detection
• AWS Cost and Usage Reports