5 AWS Cost Wins You Can Implement in One Afternoon (With Real Numbers)

AWS cost optimization for startups is where I start every engagement - because it funds everything else. Across 50+ cloud audits, the pattern is identical: a startup spending $8,000/month on AWS could spend $4,500–$5,000 with one afternoon of focused work. No architecture changes. No downtime. No new tools. Here are the 5 fixes I run through first.

If you'd rather I run this audit for you: see how the AWS cost optimization engagement works, or book a free 30-min review →

How Do I Find Every Wasted Dollar in My AWS Account Right Now?

Before touching anything, get a full picture. Two free tools do this in under 20 minutes:

AWS Cost Explorer - go to Cost Explorer → Group by Service → change time range to last 3 months. Sort by cost descending. You're looking for:

• EC2 spend above $500/month (almost always has right-sizing opportunity)
• NAT Gateway appearing at all (high signal for NAT cost problem - covered below)
• Data Transfer as a line item (often $200–$800/month that can be eliminated)

AWS Compute Optimizer - enable it (free, 2 minutes), wait 24 hours, then check the dashboard. It analyses 14 days of CloudWatch CPU/memory metrics and shows exactly which instances are oversized - with specific downsizing recommendations and projected savings per instance.

Run both before doing anything else. They tell you exactly where your afternoon should go.

How Do I Right-Size EC2 Instances Without Breaking My Application?

This is consistently the largest single saving in startup accounts. The pattern I see most often: a team provisioned m5.2xlarge (8 vCPU, 32 GB RAM) "to be safe" during a launch, the app never scaled to need it, and it's been running at 12% CPU for two years. At ~$280/month vs an m5.large at ~$70/month, that's $2,500/year on one instance. Most startups have 3–6 of these.

Step 1: Find candidates. In AWS Compute Optimizer, filter for "Over-provisioned" status. Each row shows: current instance type, recommended instance type, projected CPU utilisation after change, and estimated monthly savings. Export to CSV if you have more than 10 instances.

If Compute Optimizer isn't enabled yet, pull CPU metrics directly:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=YOUR_INSTANCE_ID \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Average Maximum \
  --output table

If Average is below 20% and Maximum is below 60% over 14 days, the instance is a right-sizing candidate.

Step 2: Test before cutting production. Right-size staging first. Run it for a week. If no performance complaints, right-size production in a maintenance window - with the old instance stopped (not terminated) for 48 hours as a rollback option.

Critical warning about memory: CloudWatch doesn't collect memory utilisation by default. If your app is memory-bound (Node.js, Java, in-memory caches), install the CloudWatch agent first to collect memory metrics - skipping this is how right-sizing goes wrong.

# Install CloudWatch agent on Amazon Linux 2
sudo yum install -y amazon-cloudwatch-agent
# Configure /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
# to include mem_used_percent metric, then restart agent

Real numbers: One Series A SaaS client (~$6K/month AWS spend) saved $1,400/month from right-sizing 8 instances - average drop of 1–2 instance sizes each. Total time: one afternoon to identify, one week to validate in staging, one maintenance window to apply.

How Do I Find and Delete Orphaned AWS Resources Without Missing Anything?

Orphaned resources are small individually but they multiply. The most expensive categories I find:

Unattached EBS volumes - created when EC2 instances launch, not deleted when they terminate (unless DeleteOnTermination is set, which is not the default on volumes added post-launch). At $0.10/GB-month, a handful of 200–500 GB orphaned volumes easily costs $100–$500/month.

# Find all unattached EBS volumes with sizes and creation dates
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,AZ:AvailabilityZone,Created:CreateTime}' \
  --output table

For each volume: check its tags. If no tags or tags reference a terminated instance, snapshot first, then delete:

aws ec2 create-snapshot \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --description "Orphan backup before delete - $(date +%Y-%m-%d)"

aws ec2 delete-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx

Unused Elastic IPs - $3.65/month per unattached EIP. Trivial per item, but accounts accumulate them from old experiments and temporary setups.

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' \
  --output table

Idle load balancers - an ALB costs ~$16/month minimum even with zero traffic. Find them in EC2 → Load Balancers. Check CloudWatch metric RequestCount = 0 over 14 days. Also look for target groups with no healthy targets - that's another signal of an abandoned LB.

Old manual RDS snapshots - automated RDS snapshots are cleaned up per retention policy. Manual snapshots are never auto-deleted and accumulate at $0.095/GB-month. RDS → Snapshots → Manual → sort by date → delete anything older than your retention policy requires.

Real numbers: One client had 23 unattached EBS volumes, 8 unused EIPs, and 2 idle load balancers from a deprecated staging environment. Total monthly waste: $380. Time to clean up: 45 minutes.

Why Is My NAT Gateway Bill So High and How Do I Fix It?

NAT Gateway is the cost that catches startups completely off guard. Pricing: $0.045/hour per gateway + $0.045/GB of data processed. That second number is the killer.

A startup with Lambda functions in a VPC calling external APIs at scale can easily push 5,000–20,000 GB/month through a NAT Gateway. At $0.045/GB: $225–$900/month - just for data processing. Add the hourly charge ($32/month per NAT) and multi-AZ setups (one NAT per AZ = 3× the cost), and teams routinely see $500–$2,000/month in NAT costs they don't fully understand.

Step 1: Find what's generating the traffic. Enable VPC Flow Logs, then query CloudWatch Logs Insights:

fields srcAddr, dstAddr, bytes, action
| filter action = "ACCEPT" and dstAddr not like /^10\./
| stats sum(bytes) as totalBytes by srcAddr
| sort totalBytes desc
| limit 20

This shows which private IPs in your VPC generate the most outbound traffic through NAT. Nine times out of ten it's Lambda functions or ECS tasks, not EC2.

Step 2: Apply fixes in order of impact:

VPC Endpoints for S3 and DynamoDB - free. If any workloads access S3 or DynamoDB from within a VPC, they're routing through NAT by default. Gateway VPC Endpoints have no hourly charge and no data charge - and they can eliminate 30–60% of NAT data processing for data-heavy workloads.

# Create S3 VPC Endpoint (replace vpc-id and route-table-id)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxxxxxxxxxxxxxxx

Move Lambda out of VPC if it doesn't genuinely need access to VPC-only resources (RDS in a private subnet, ElastiCache, etc.). Many Lambda functions are put in VPCs "for security" when they only call external APIs - they get all the NAT cost with none of the security benefit.

Collapse to single NAT for non-prod. If you're running one NAT per AZ in staging/dev, use a single NAT. Non-production traffic doesn't need AZ-level redundancy.

Real numbers: One client reduced NAT spend from $1,100/month to $180/month. Fix: created S3 and DynamoDB VPC endpoints (saving ~$600/month on data processing) and moved 4 Lambda functions out of VPC (saving ~$320/month). Total implementation time: 3 hours including testing.

When Should a Startup Buy AWS Savings Plans - and How Much?

Savings Plans offer 30–66% off On-Demand rates in exchange for a $/hour commitment over 1 or 3 years. This is the fix with the highest ceiling - and the most common mistake: buying too early or committing to the wrong amount.

Two types matter for startups:

• Compute Savings Plans - flexible, apply to EC2, Lambda, and Fargate across all regions, instance families, and sizes. Up to 66% discount. Recommended because startup architectures change.
• EC2 Instance Savings Plans - higher discount (up to 72%) but locked to a specific instance family in a specific region. Only buy if a workload is stable and won't change for 12 months.

The rule: don't buy before month 4 of stable workloads. Savings Plans are a commitment. Buy a $1,000/month plan, then scale down or migrate to Fargate - you still pay the committed rate. Buy only what you're confident will run continuously for 12 months.

How to buy correctly: Cost Explorer → Savings Plans → Recommendations. Set type to Compute, term to 1 year, payment to No Upfront (best for startup cash flow). AWS shows your current on-demand spend, recommended commitment, projected savings, and break-even - before you commit.

One critical detail: recommendations are based on your last 7 or 30 days of usage. If you recently scaled up or had a traffic spike, the recommendation will be inflated. Always set "Based on past" to 30 days and look at the trend before committing. Commit 70–80% of the recommendation to leave headroom for scaling down.

Real numbers: A startup spending $3,200/month on EC2 and Fargate bought a $1,800/month Compute Savings Plan (1 year, No Upfront). Net savings: $780/month = $9,360/year. No changes to infrastructure whatsoever.

What's the Combined Saving Potential?

Running all five fixes on a typical Series A startup ($5,000–$10,000/month AWS spend):

• Right-sizing EC2: $400–$1,400/month
• Orphaned resource cleanup: $100–$500/month
• NAT Gateway optimisation: $200–$1,100/month
• Savings Plans: $600–$1,500/month

Total: $1,300–$4,500/month, or 25–45% of AWS spend. None of these require downtime, a new platform, or a migration. They require one focused afternoon, the right tooling lens, and the discipline to act on what the data shows.

The one thing they do require: someone who's done it before knows which Compute Optimizer recommendations to skip (it gets memory-bound apps wrong without the CloudWatch agent), which NAT fixes apply to which workload types, and how to set Savings Plan commitments without overcommitting. That's what the free review is for.

Book a Free AWS Cost Review

I look at your account directly, run through these five areas, and give you a prioritised list of what to fix - at no cost or commitment. I've helped startups recover over $500K in cloud spend using this process.

Learn more about the AWS cost optimization engagement →
Book your free 30-min AWS cost review →