AWS Cost Optimization Tips Nobody Tells You

Look, I've been there. You spin up a few EC2 instances for a "quick test," set up an RDS database, maybe throw in some Lambda functions, and before you know it, your AWS bill looks like a phone number. We've all had that mini heart attack moment when the monthly invoice arrives.

After years of managing AWS infrastructure (and making plenty of expensive mistakes), I've picked up some cost optimization tricks that aren't always in the official documentation. These are the real-world lessons learned from production environments, not just theoretical best practices.

1. The S3 Intelligent-Tiering Secret Nobody Uses

Everyone talks about S3 storage classes, but here's what they don't tell you: S3 Intelligent-Tiering is almost always worth it, even if you think you know your access patterns.

I used to manually move data between storage classes. What a waste of time. Intelligent-Tiering automatically moves objects between access tiers based on usage patterns, and here's the kicker - there's no retrieval fee for the frequent and infrequent access tiers.

The monitoring cost is just $0.0025 per 1,000 objects. For most use cases, this pays for itself within the first month. I've seen this single change reduce S3 costs by 40-60% for projects with mixed access patterns.

Pro tip: Enable it on existing buckets with a lifecycle policy. You don't need to migrate data - AWS handles everything in the background.

2. EC2 Savings Plans Are Better Than Reserved Instances (Usually)

Reserved Instances get all the attention, but Savings Plans are often the better deal. Here's why this matters:

With Savings Plans, you commit to a dollar amount per hour (like $10/hour) instead of specific instance types. This gives you flexibility to:

• Change instance families (m5 to c5, for example)
• Switch between regions
• Move workloads between EC2, Lambda, and Fargate

I've personally saved about 30% more with Savings Plans compared to RIs simply because I wasn't locked into specific instance types when requirements changed.

The catch: You need at least 3 months of usage data to make smart commitments. Don't jump in on day one.

3. NAT Gateways Are Silently Expensive

This one hurts because NAT Gateways seem so innocent. At $0.045 per hour plus data processing charges, a single NAT Gateway costs about $32/month. But the data processing fees? That's where they get you.

I once discovered a NAT Gateway processing 10TB/month of data that didn't need to go through it at all. Cost: over $450/month. The fix?

Solution:

• Use VPC endpoints for AWS services (S3, DynamoDB, etc.) - they're free for data transfer
• Consider NAT instances for low-traffic environments
• Set up CloudWatch alarms for data processing costs

One company I consulted for reduced their NAT Gateway costs from $2,000/month to $300/month just by implementing VPC endpoints for their S3-heavy workloads.

4. The EBS Volume Zombie Problem

Here's a dirty secret: unattached EBS volumes cost the same as attached ones. When you terminate an EC2 instance, the EBS volume often doesn't get deleted automatically.

I wrote a simple Lambda function that runs weekly to find unattached volumes older than 7 days and sends me a report. Implementing this across our infrastructure uncovered $800/month in zombie volumes.

# Quick Lambda to find unattached volumes
import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )

    for volume in volumes['Volumes']:
        print(f"Unattached: {volume['VolumeId']} - {volume['Size']}GB")

Bonus tip: Enable the "DeleteOnTermination" attribute for root volumes when launching instances.

5. CloudWatch Logs Will Bankrupt You (If You're Not Careful)

CloudWatch Logs pricing is sneaky. Ingestion is cheap ($0.50/GB), but storage adds up fast, and nobody tells you about the query costs.

I learned this the hard way when debugging a production issue - ran a few CloudWatch Insights queries and got hit with a $200 charge. Here's the defense strategy:

• Set up log retention policies (7-30 days for most logs)
• Export old logs to S3 using Kinesis Firehose (way cheaper)
• Use log sampling for high-volume applications
• Consider alternatives like Grafana Loki for certain use cases

Real numbers: Moving logs older than 30 days to S3 reduced one client's logging costs from $1,200/month to $200/month.

6. Lambda Memory Settings Are Backwards

Most people set Lambda memory based on... well, memory needs. But here's the counterintuitive part: sometimes increasing memory decreases costs.

Lambda pricing is based on GB-seconds, and when you increase memory, you also get proportionally more CPU power. A function that runs in 3 seconds with 512MB might run in 1 second with 1024MB.

I tested this with an image processing function:

• 512MB: 3.2 seconds average → $0.000000667 per invocation
• 1024MB: 1.1 seconds average → $0.000000528 per invocation

That's 20% cost savings by increasing resources. Always test multiple configurations.

Tool recommendation: AWS Lambda Power Tuning (open source) automates this testing for you.

7. Data Transfer Costs Are the Hidden Killer

Data transfer between AWS services in different regions, or between AZs, adds up faster than you'd think. This is the cost that sneaks up on you.

A few strategies that saved me thousands:

• Keep EC2 instances and RDS in the same AZ when possible
• Use S3 Transfer Acceleration only when necessary
• Consider CloudFront even for APIs (yes, really) - it can reduce data transfer costs
• Put load balancers and target instances in the same AZ

War story: A microservices architecture with cross-region database replication was costing $3K/month in data transfer alone. We consolidated regions and dropped it to $400/month without impacting performance.

8. The RDS Storage Autoscaling Trap

RDS storage autoscaling sounds great in theory - your database grows automatically as needed. But here's the problem: it only grows, never shrinks.

I've seen databases that temporarily needed extra space keep that storage (and keep paying for it) forever. A 1TB database that spiked to 2TB during a data migration will stay at 2TB.

Better approach:

• Start conservative with autoscaling
• Set maximum storage thresholds
• Monitor actual usage vs allocated storage
• Consider manual scaling for predictable growth

9. Elastic IPs Cost Money When Unused

This catches so many people. An Elastic IP is free when attached to a running instance, but costs $0.005 per hour ($3.60/month) when it's not associated with anything.

I once found an account with 47 unassociated Elastic IPs. That's $170/month for literally nothing.

Quick fix: Run this AWS CLI command regularly:

aws ec2 describe-addresses --query 'Addresses[?AssociationId==null]'

10. Use AWS Cost Anomaly Detection (Seriously)

This is a free AWS service that uses machine learning to detect unusual spending. I was skeptical at first, but it caught several issues before they became expensive:

• A Lambda function stuck in a retry loop ($400 anomaly)
• An RDS instance that someone upsized for testing and forgot to downsize ($600 anomaly)
• A misconfigured auto-scaling group that went rogue ($1,200 anomaly)

Set it up once, forget about it, and let it watch your back.

The Real Cost Optimization Strategy

Here's the truth: cost optimization isn't a one-time project. It's a habit.

What works for me:

• Weekly 15-minute review of Cost Explorer
• Monthly deep dive into anomalies
• Quarterly architecture review for new optimization opportunities
• Tag everything properly (seriously, do this from day one)

The best advice I can give? Start small. Pick one thing from this list, implement it this week, and measure the impact. Then move to the next.

Conclusion

AWS cost optimization isn't about penny-pinching or running everything on the smallest instances. It's about being intentional with your infrastructure and eliminating waste.

The examples I shared here saved real companies real money - collectively over $100K/year. Your mileage will vary, but the principles remain the same.

What's your AWS cost optimization story? Have you discovered any tips that aren't widely known? I'd love to hear about them in the comments.

---

Remember: The best time to optimize costs was when you first set up your infrastructure. The second best time is now.