Cost Optimization on AWS: The Founder's Guide

AWS bills grow like weeds. Every service is easy to spin up, most bills have dozens of line items, and small overprovisioning decisions compound into serious money over time. Most SaaS teams I audit are overspending on AWS by 30 to 60 percent, not because they made obvious mistakes, but because they made a series of reasonable-looking decisions that added up. The good news is that cost optimization on AWS is a well-understood discipline with a clear playbook. If you follow it, you can typically cut your bill by half without touching reliability or velocity. This post walks through the specific patterns that produce those savings, ranked by impact-per-effort. Start at the top and work down as time allows. Some of these take an hour. Others take a week and require some architectural work. All of them pay back within months and continue paying back for years. The goal is not to squeeze every last dollar out of AWS. It is to stop spending money that produces no value, so you can either put more money into product or extend your runway. Both matter.

Start with visibility, not action

The first mistake founders make is trying to optimize a bill they do not understand. AWS Cost Explorer is a free tool that groups costs by service, tag, and time. Spend an hour in Cost Explorer before you touch anything else. Find the top 5 services by cost. That is almost always where 80 percent of the savings will come from.

Tag every resource with owner, environment, and project. Tagging discipline is what lets you split the bill by team, product, or feature. Without tags, cost analysis is a guessing game and every cost review devolves into arguments about which team owns which line item. Enforce tagging via AWS Config or Service Control Policies so untagged resources cannot be created. This one policy pays back within a quarter through better cost accountability.

Set up a cost anomaly alert that pings you when spending in any service jumps unexpectedly. Bad deploys, forgotten test environments, and misconfigured logging pipelines all cause cost spikes that would otherwise go unnoticed until the monthly bill arrives. Alerts within a day are much cheaper to fix than surprises at month end.

Right-size compute: the biggest single lever

Compute is usually the largest line item, and most compute is overprovisioned. Right-sizing means picking instance types and sizes that match actual usage instead of guessing high. AWS Compute Optimizer looks at CloudWatch metrics and recommends smaller instance sizes where CPU and memory utilization is consistently low. Apply the recommendations and you typically cut EC2, RDS, and ECS costs by 20 to 40 percent.

Look at CPU and memory utilization over the last 30 days. Any instance running below 40 percent utilization on both metrics is a candidate for downsizing. Any instance running below 20 percent on either is almost certainly oversized. Downsize in one step, monitor for a week, and downsize again if utilization stays low. Do not try to jump three sizes at once because the risk of hitting an unexpected spike is not worth the extra savings.

The other angle on compute is instance family. Move workloads to newer instance families like m7g or c7g (Graviton) where possible. Graviton instances offer 20 to 30 percent better price-performance than equivalent x86 instances. The migration is usually straightforward for Linux workloads and pays back immediately.

Buy Savings Plans or Reserved Instances

Once your workloads are right-sized and stable, buy Savings Plans or Reserved Instances for the base load. Savings Plans give you 30 to 50 percent discount on compute in exchange for a 1-year or 3-year commitment. Compute Savings Plans are more flexible and typically the right choice for teams that might change instance types or move between EC2 and Fargate.

The trick is not overcommitting. Buy Savings Plans for the workload floor, not the peak. Analyze your compute usage over the last 3 to 6 months and commit to about 70 to 80 percent of your baseline. Cover the rest with on-demand pricing so you have flexibility as the workload evolves. Overcommitting is a fast way to lock in unused capacity for years.

Reserved Instances still exist for RDS, ElastiCache, and a few other services. Use them for the same reason: predictable base load gets a big discount in exchange for a commitment. Savings Plans and Reserved Instances together often cut compute cost by 40 to 60 percent from on-demand pricing.

S3 lifecycle policies and storage class

S3 is the sleeper cost killer in most AWS bills. Data accumulates for years, storage class stays at Standard, and nobody notices until the S3 line item is thousands of dollars a month. Fix this with lifecycle policies that transition objects to cheaper storage classes as they age.

A common pattern: keep objects in S3 Standard for the first 30 days, transition to Standard-IA for the next 60 days, transition to Glacier Instant Retrieval for the next 6 months, and archive to Glacier Deep Archive after that. Each transition cuts the storage cost significantly. For backups and archival data that you rarely access, Deep Archive costs 1 dollar per TB per month versus 23 dollars per TB per month for Standard. That is a 95 percent saving.

Delete what you do not need. Old logs, old build artifacts, old test data, and abandoned buckets all cost money. Run S3 Storage Lens to find your largest buckets and audit them. Every unused terabyte you delete saves 275 dollars a year at Standard pricing. Our DevOps and cloud team runs these audits quarterly for clients and consistently finds 30 to 50 percent savings on S3 alone.

Data transfer: the invisible cost that adds up

Data transfer out of AWS costs 9 cents per GB, and it adds up faster than founders expect. A busy SaaS moving 5 TB a month out to the internet spends 450 dollars just on egress. High-traffic apps easily hit thousands of dollars a month in transfer costs alone.

The main levers: use CloudFront for anything served to browsers because CloudFront egress is cheaper than direct S3 or EC2 egress and its caching reduces origin fetches. Compress responses aggressively with gzip or Brotli because smaller responses cost less to transfer. Move heavy static assets to edge providers like Cloudflare R2 that charge zero egress.

Cross-AZ data transfer within AWS also costs money at 2 cents per GB in each direction. Databases talking to app servers across AZs, cross-AZ replication, and cross-AZ load balancing all cost real dollars. Architect for AZ affinity where possible: keep chatty services in the same AZ, use RDS Multi-AZ for durability but minimize app-to-database cross-AZ traffic.

Kill zombie resources

Every AWS account has zombies: resources that are running and costing money but nobody uses. Unattached EBS volumes from deleted instances. Old snapshots that were never cleaned up. Load balancers with no targets. NAT gateways in unused VPCs. Orphaned Elastic IPs. Unused Elastic File System volumes.

• EBS: audit for unattached volumes and old snapshots. Delete or archive.
• Elastic IPs: 3.60 dollars per month each when unattached, adds up fast in dev accounts.
• NAT gateways: 32 dollars per month plus data processing. Consolidate or replace with NAT instances at low scale.
• Load balancers: 16 to 25 dollars per month each. Remove unused ones.
• CloudWatch Logs: log groups with infinite retention accumulate forever. Set retention policies.

A quarterly zombie audit typically finds 5 to 15 percent of the bill in resources nobody uses. Add up all the small items and it is real money. Automate the audit with a script that scans all regions and posts findings weekly. Manual audits get skipped.

Environment cleanup and shutdown schedules

Non-production environments run 24/7 by default and eat budget on nights and weekends when nobody uses them. Shut them down outside business hours. A staging environment that runs 40 hours a week instead of 168 costs 76 percent less. Multiply that across all your dev, staging, and QA environments and the savings are substantial.

AWS Instance Scheduler or a simple Lambda function tied to CloudWatch Events can start and stop instances on a schedule. RDS supports scheduled start-stop as well. Some teams push this further with ephemeral environments that spin up per PR and shut down when the PR closes. Vercel and Railway do this by default, and if you are on AWS, tools like Coder or Nx Cloud can replicate the pattern.

Delete environments that are no longer used. Every project has a graveyard of proof-of-concept environments, experimental branches, and one-off customer demos. Audit quarterly and delete anything that has not been touched in 60 days.

Database costs and query optimization

RDS and Aurora bills are often larger than they need to be for two reasons: oversized instances and inefficient queries. Right-size the instance first using CloudWatch memory and CPU metrics. Then look at slow queries using Performance Insights or the equivalent tool. Fixing the top 5 slow queries often reduces database CPU by 30 to 50 percent, which lets you run a smaller instance.

Add read replicas only when you have measured that read load is the bottleneck. Read replicas cost as much as the primary and are frequently added preemptively for scale that never materializes. Also review your backup retention. Default 7 to 30 day backups are usually right, but longer retention gets expensive quickly for large databases.

For workloads with unpredictable spiky traffic, Aurora Serverless v2 can be cheaper than provisioned Aurora because it scales down during quiet periods. But it can also be more expensive at steady-state high load. Model both options with your actual traffic pattern before committing. Our API and backend team runs this analysis for every RDS migration we do.

CloudWatch and observability costs

CloudWatch is often a top-5 line item on AWS bills and it is one of the easiest to reduce. Log ingestion, custom metrics, and Contributor Insights all charge by volume. Teams often log everything at high verbosity and then wonder why the bill is thousands of dollars a month for logs nobody reads.

Set log retention aggressively. 30 days of hot logs in CloudWatch is enough for most operational needs. Anything older gets archived to S3 or Glacier at a fraction of the cost. Cut log volume by dropping DEBUG and INFO logs in production and only emitting WARNING and ERROR by default. Sample high-volume events instead of logging every single one.

For custom metrics, batch and aggregate before sending. Every custom metric costs 0.30 dollars per month, and it adds up fast when applications emit metrics per-request. Aggregate to per-minute or per-hour rollups before sending to CloudWatch. Or use a purpose-built metrics tool like Prometheus that charges per storage rather than per metric.

Networking optimizations that cut real dollars

VPC endpoints reduce data transfer costs for traffic between your workloads and AWS services like S3, DynamoDB, and Secrets Manager. Without endpoints, this traffic goes through NAT gateways at 4.5 cents per GB. With endpoints, it stays inside AWS at no data transfer cost. For teams with heavy S3 traffic, VPC endpoints alone can save hundreds of dollars a month.

Review NAT gateway placement. NAT gateways cost 32 dollars per month per AZ plus 4.5 cents per GB processed. For dev environments, a single NAT gateway across all AZs is often fine. For production, evaluate whether the redundancy of per-AZ NAT gateways is worth the cost compared to using NAT instances or VPC endpoints. See our API and backend playbook for typical network topology recommendations.

The 45-day cost optimization sprint

When we take on cost optimization work, we run it as a focused 45-day sprint. Week 1: visibility, tagging, and baseline metrics. Week 2: right-size compute and databases. Week 3: buy Savings Plans and Reserved Instances. Week 4: S3 lifecycle policies, zombie audit, and environment cleanup. Week 5: data transfer optimization and CloudFront caching. Week 6: measure impact, document changes, and set up ongoing cost governance.

Typical savings on a mid-size AWS bill: 30 to 50 percent within 60 days, sustained through ongoing governance. Larger accounts sometimes see 60 percent or more because there is more waste to find. Smaller accounts see 20 to 30 percent because there is less low-hanging fruit but also less complexity to hide waste behind. Every engagement is different because every architecture is different, and the biggest wins usually come from patterns that are specific to how the business uses AWS. See our projects library for examples of cost optimization engagements and their measured outcomes.

Cost optimization is not a one-time project. It is an ongoing discipline. Set up monthly cost reviews with your team, alerts for cost anomalies, and quarterly zombie audits. Without ongoing attention, waste creeps back within a year and you end up running the same optimization sprint again.

The other habit worth building: every new service or feature should have a cost estimate attached to the design doc before implementation. This shifts cost thinking left, before waste gets baked into the architecture. Teams that adopt this discipline consistently ship more cost-efficient systems and avoid the surprise cost spikes that follow major feature launches. If you want us to run the initial sprint or set up ongoing cost governance for your AWS account, reach out for a scoping call.