Most AWS cost optimization advice focuses on the basics:
- Delete unused snapshots
- Clean up old EBS volumes
- Purchase Savings Plans
- Remove idle resources
These are important — and should absolutely be part of every team's cost strategy. But when we started working with one of our startup clients, they had already done all of this.
They still thought their AWS environment was fully optimized. It wasn't.
After a deep-dive audit, we identified architectural decisions that were silently costing them hundreds every month. Here's exactly what we found and fixed.
The Client
An early-stage B2B SaaS startup running on AWS. They had a small engineering team, were using EKS with around 80 nodes, and their monthly AWS bill was growing faster than their revenue.
They came to us asking: "We've already cleaned up unused resources — what else can we do?"
Problem 1: Kubernetes Adopted Too Early
The team had adopted EKS long before they actually needed Kubernetes. It was driven by future-proofing — planning for scale that hadn't arrived yet.
What we found:
- Higher infrastructure costs from running the EKS control plane + node groups
- Increased operational complexity eating up engineering time
- Cluster maintenance overhead that a small team couldn't sustain
Our recommendation:
For many startups at this stage, ECS is sufficient for years. We helped them evaluate whether migrating critical workloads to ECS Fargate would reduce both cost and operational burden.
Problem 2: Production-Grade Architecture in Every Environment
Their dev and staging environments mirrored production exactly:
- NAT Gateways in every environment
- Multi-AZ RDS databases for staging
- Oversized instance types for dev workloads
None of this was necessary for non-production use.
We right-sized their non-production environments — replacing NAT Gateways with NAT Instances where appropriate, switching to single-AZ databases for staging, and downsizing instance types.
Problem 3: Non-Production Running 24/7
Their staging and dev infrastructure was running continuously — nights, weekends, holidays — even though the team only used it during business hours (Monday–Friday, 9am–7pm).
Our fix:
We introduced automated start/stop schedules using AWS Lambda and EventBridge. The environments spin up at 9am and shut down at 7pm IST, Monday through Friday.
Result: ~25% reduction in non-production compute costs with zero impact on developer productivity.
Services we scheduled:
- EC2 Instances
- ECS Services
- RDS Instances
Problem 4: $550/Month Wasted on NAT Gateway Data Processing
During our cost review, we noticed higher-than-expected NAT Gateway data processing charges. After investigating, we discovered that EKS pods were pulling container images from ECR through the NAT Gateway.
Since Amazon ECR stores image layers in S3, every image pull was routing through NAT — and AWS charges $0.045/GB for NAT Gateway data processing.
The math:
- 80 worker nodes pulling ~2GB of data from ECR per day
- 80 × 2 GB = 160 GB/day
- 160 GB × 30 days = 4,800 GB/month
- 4,800 × $0.045 = ~$216/month — just for image pulls
Combined with other traffic flowing through NAT (S3 access, API calls, logging), the total NAT Gateway data processing bill came to roughly $550/month.
Our fix:
We introduced three VPC Endpoints:
- ECR API Endpoint
- ECR DKR Endpoint
- S3 Gateway Endpoint
After deploying, image pulls and S3 traffic no longer touched the NAT Gateway. $550/month saved — without changing a single line of application code.
Problem 5: Managed Services Without Cost-Benefit Analysis
The team was using several managed services where the "convenience tax" wasn't justified for their scale. We helped them evaluate each one:
- Which services were they actually benefiting from?
- Where was self-managed infrastructure more cost-effective?
- What was the engineering time tradeoff?
In some cases, the managed service made sense. In others, a simpler alternative saved 30-40%.
Problem 6: Overprovisioned Databases
Their RDS instances were sized for traffic they expected in 12 months — not traffic they had today. We right-sized their databases to current needs and set up CloudWatch alarms to trigger scaling when actual load increased.
Paying for unused database capacity rarely makes sense for startups.
Results Summary
| Optimization | Monthly Savings |
|---|---|
| Non-production scheduling | ~25% compute reduction |
| VPC Endpoints (NAT bypass) | $550/month |
| Environment right-sizing | ~20% per environment |
| Database right-sizing | ~15% on RDS costs |
Total impact: ~30% reduction in their overall AWS bill.
Key Takeaway
Most teams approach AWS cost optimization by looking for discounts. We start by questioning decisions:
- Do you really need Kubernetes at this stage?
- Does this environment need production-grade reliability?
- Should this workload be running 24/7?
- Is your traffic actually routing efficiently?
That's the difference between operating infrastructure and engineering infrastructure.
Operations teams optimize resources. Great platform teams optimize decisions.
Overspending on AWS? We'll tell you exactly where. Book a free cloud cost audit with SmartDevops — no commitments, just actionable insights you can implement right away.