The $47 Billion Problem: How Startups Unknowingly Burn 40% of Their AWS Budget

Many startups spend more on AWS than they need to. In most cases, it is not because of poor engineering. It happens because teams move quickly, infrastructure grows over time, and no one has enough visibility into where the money is going.

After reviewing more than 100 AWS accounts, we often found that 35% to 45% of spend could be reduced without affecting performance. The causes were usually the same: over-provisioned compute, unused resources, network charges, old storage, and pricing choices that had not been revisited.

The good news is that most of this can be fixed with a structured review.

Why AWS Spend Gets Out of Hand

Startups usually optimize for speed first. That is the right choice early on, but it often creates infrastructure debt.

Teams over-provision services to avoid outages. Kubernetes clusters run with low utilization. NAT Gateway costs grow quietly. Storage volumes and snapshots get left behind. On-demand instances stay in place even when usage becomes predictable. These issues are common, and they are usually fixable.

1. Kubernetes Resource Requests

Kubernetes schedules workloads based on requested CPU and memory, not actual usage.

If a pod requests 2GB of memory but only uses 200MB, Kubernetes still reserves the full 2GB. Across many workloads, this can make a cluster look full even when real utilization is low.

Common findings include:

• Memory requests set much higher than needed**
• CPU requests set much higher than needed**
• Low actual utilization across nodes**
• More nodes running than the workloads require**

In one environment, a team was running 47 nodes but only needed 12 after requests were adjusted. That change removed a large amount of unused capacity.

How Karpenter Helps

For teams using EKS, Karpenter can help match compute capacity to workload needs.

• Spot instances
• ARM and Graviton nodes
• Multiple instance families
• Node consolidation

Karpenter is most useful when paired with realistic resource requests and clear scheduling rules.

2. NAT Gateway Costs

NAT Gateways can become expensive because costs include more than the hourly charge. Data processing fees and cross-AZ traffic often make up a large part of the bill.

Some traffic does not need to go through NAT. AWS services such as S3, DynamoDB, ECR, and SSM support VPC Endpoints, which can reduce NAT usage.

• Checking which services are using NAT
• Adding VPC Endpoints where appropriate
• Reducing unnecessary cross-AZ traffic
• Reviewing NAT Gateway placement by AZ

In one case, a client reduced network costs from $3,100 per month to $890 after adding endpoints and cleaning up traffic patterns.

3. Storage Cleanup

Storage waste builds up slowly.

• Unattached EBS volumes
• Old snapshots
• CloudWatch log groups with no retention policy
• GP2 volumes that could be moved to GP3

These items are easy to overlook because each one may seem small. Together, they can add meaningful monthly cost.

A basic cleanup should include setting log retention policies, deleting unused volumes, reviewing snapshots, and migrating eligible GP2 volumes to GP3.

4. On-Demand Instance Usage

On-demand instances are useful because they are flexible. But once workloads become stable, it is worth reviewing whether some usage should move to a lower-cost pricing model.

• Savings Plans
• Reserved Instances
• Spot Instances for fault-tolerant workloads

The safest approach is to start with baseline usage. Commit only to capacity that is consistently used, and keep variable workloads flexible. This helps reduce cost without overcommitting.

5. Duplicated Infrastructure

As teams and services grow, infrastructure often gets duplicated.

• Multiple ALBs for related services
• Several RDS instances with similar workloads
• Redundant monitoring tools
• Orphaned Elastic IPs
• Separate caches that could be consolidated

This does not mean every service should be merged. It means shared infrastructure should be considered where it makes sense.

For example, some teams can reduce ALB costs by using shared ingress controllers instead of creating a separate load balancer for every service.

Common examples include: Multiple ALBs for related services Several RDS instances with similar workloads Redundant monitoring tools Orphaned Elastic IPs Separate caches that could be consolidated

This does not mean every service should be merged. It means shared infrastructure should be considered where it makes sense.

For example, some teams can reduce ALB costs by using shared ingress controllers instead of creating a separate load balancer for every service.

Making Cost Awareness Part of Engineering

Cost optimization works best when it becomes part of normal engineering practice.

• Giving teams visibility into the services they own
• Reviewing cost impact during architecture decisions
• Adding basic guardrails
• Setting retention and lifecycle policies by default
• Checking usage regularly

Engineers do not need to think about cost every minute. But they should have enough information to make practical decisions.

Where to Start

If you want to reduce AWS spend, start with these checks:

1. Review Kubernetes CPU and memory requests

2. Check NAT Gateway usage and add VPC Endpoints where useful

3. Remove unattached EBS volumes and old snapshots

4. Set CloudWatch log retention policies

5. Review baseline usage for Savings Plans

Most teams do not need a large optimization project to make progress. A focused review of the biggest cost areas is usually enough to find meaningful savings.

About CosmosGrid

CosmosGrid helps startups simplify AWS, reduce unnecessary cloud spend, and build scalable infrastructure.

We help teams understand where their AWS budget is going, identify practical savings opportunities, and make their cloud environment easier to operate.