At a Series A startup I worked at, we were spending $18,000/month on AWS. We had 12 engineers, one product, and a few thousand users. When the board started asking about burn rate, we finally looked at the bill closely.

Within three weeks, we cut it to $7,200/month. We didn’t remove a single feature. We didn’t degrade performance. We didn’t even do anything particularly clever.

We just stopped paying for things we weren’t using.

This is the guide I wish someone had handed me when we were setting up our infrastructure. It’s organized by startup stage because the right level of cost optimization depends entirely on where you are.

The Mistakes Almost Every Startup Makes

Before we get into stage-specific advice, here are the patterns I’ve seen repeatedly across dozens of startups:

Over-Provisioning “Just in Case”

A founding engineer provisions a db.r6g.xlarge RDS instance for a database with 2 GB of data and 50 queries per second. “We’ll need the headroom when we scale.” That instance costs $438/month. A db.t4g.medium handles that load comfortably at $98/month.

The “just in case” instinct is strong in engineers, and it makes sense in a world where provisioning takes weeks. In the cloud, you can resize an RDS instance with 5 minutes of downtime. You can change an EC2 instance type in under a minute. Over-provisioning for hypothetical future load is paying a premium for capacity you don’t need and can add on-demand when you do.

Running Production-Like Staging 24/7

Your staging environment does not need to be a mirror of production. Not at the startup stage. Your staging environment is used by engineers during working hours, maybe 10 hours a day, 5 days a week. That’s 50 hours out of 730 hours in a month — 7% utilization.

If your staging environment costs $3,000/month running 24/7, scheduling it to run only during business hours (with a generous buffer) brings that to roughly $700/month. Same environment, same configuration, $2,300/month saved.

Ignoring the Free Tier

AWS Free Tier is legitimately generous for early-stage startups, and most teams leave value on the table:

• 750 hours/month of t2.micro or t3.micro for the first 12 months. That’s one instance running 24/7. Use it for your staging API or a utility service.
• 25 GB of DynamoDB storage with enough read/write capacity for a small application. Perpetually free, not just the first 12 months.
• 1 million Lambda invocations/month. Also perpetual. If your workload fits Lambda, this is effectively free compute.
• 5 GB of S3 standard storage for 12 months.
• 750 hours of RDS db.t2.micro or db.t3.micro for 12 months.

I’ve seen pre-seed startups paying $400/month for infrastructure that could have been $50/month if they’d paid attention to free tier eligibility.

Not Setting Billing Alerts

This one is baffling in its frequency. At least 40% of early-stage startups I’ve talked to have no billing alerts configured. They find out their bill spiked when the credit card charge hits, sometimes weeks after the cost was incurred.

Setting up AWS Budgets takes 5 minutes and can prevent thousands in unexpected charges. There’s no excuse for not having at least a threshold alert at 80% and 100% of your expected monthly spend.

Pre-Seed / Bootstrapped: Don’t Over-Optimize, But Don’t Be Wasteful

At this stage, your cloud bill should be under $500/month. If it’s significantly more, something is wrong.

What to focus on:

• Use the smallest instance types that work. t3.small or t3.medium for most workloads. Burstable instances are perfect for early-stage apps with low, spiky traffic.
• Use managed services over self-hosted. Don’t run your own PostgreSQL on EC2 — use RDS. Don’t manage your own Redis — use ElastiCache or even a hosted service like Upstash that charges per-request. Your time is worth more than the cost difference at this scale.
• Single-AZ is fine for non-critical workloads. Multi-AZ RDS doubles your database cost. If your startup can tolerate 5 minutes of downtime during a rare AZ failure, save the money.
• Use S3 Intelligent-Tiering from day one. It automatically moves objects to cheaper storage tiers based on access patterns, with no retrieval fees. Set it and forget it.

What NOT to focus on:

• Reserved Instances or Savings Plans. You don’t know what your infrastructure will look like in 3 months. Don’t commit.
• Complex architectures for cost efficiency. Don’t rewrite a simple Express API as Lambda functions to save $20/month. Ship features.
• Granular cost allocation. You have 3 engineers. Everyone knows what’s running. You don’t need a tagging strategy yet.

Budget target: $200–$500/month for a typical SaaS application with low traffic.

Post-Seed / Pre-Series A: Start Paying Attention

You’ve raised some money. You have 5–15 engineers. Your infrastructure is growing. Your cloud bill is probably $2,000–$8,000/month and climbing.

This is the stage where bad habits start costing real money. You’re not big enough for formal FinOps, but you need someone — probably a senior engineer or the CTO — spending 2–3 hours per month looking at the bill.

What to focus on:

Set Up AWS Budgets Properly

Go beyond a single threshold alert. Create budgets for:

• Total account spend: Alert at 80%, 100%, and 120% of expected monthly spend
• Per-service budgets for your top 3 services (usually EC2, RDS, and one other)
• A forecasted budget: AWS can alert you if your projected end-of-month spend will exceed your target, based on current usage patterns

Example budget structure:
- Total: $6,000/month → alerts at $4,800, $6,000, $7,200
- EC2: $2,500/month → alert at $3,000
- RDS: $1,200/month → alert at $1,500
- Forecasted total: $6,000 → alert if projected to exceed

Schedule Non-Production Environments

This is the single highest-ROI optimization for startups at this stage.

Your dev and staging environments should shut down outside business hours. Use AWS Instance Scheduler, a simple Lambda function, or even a cron job that stops instances at 8 PM and starts them at 7 AM.

For Kubernetes-based setups, scale non-production cluster node groups to zero overnight and on weekends.

Typical savings: 65–70% of non-production compute costs.

If your staging environment costs $3,000/month, scheduling it to business hours saves ~$2,000/month. For most startups, this is the largest single optimization available.

Right-Size Your Database

RDS is typically the #2 line item for startups. Check your database’s CloudWatch metrics:

• CPU utilization: If average is below 20%, you’re over-provisioned by at least one instance size
• FreeableMemory: If you consistently have 60%+ free memory, you’re over-provisioned
• DatabaseConnections: If you’re using 10% of max connections, you might be a tier too high

Downsizing from db.r6g.xlarge ($438/mo) to db.r6g.large ($219/mo) or even db.t4g.large ($196/mo for burstable) is common at this stage.

Use Spot Instances for CI/CD

Your CI/CD pipeline doesn’t need on-demand instances. CI workloads are:

• Interruptible (a retry is fine)
• Short-lived (minutes, not hours)
• Stateless (no data loss if the instance is reclaimed)

This is the perfect spot instance use case. Spot pricing for common CI instance types is 60–80% below on-demand.

If you’re using GitHub Actions, consider self-hosted runners on spot instances for your heavy jobs. A team running 4 hours/day of CI on m5.xlarge on-demand pays ~$140/month. On spot, that’s ~$40/month.

If you use AWS CodeBuild, it already supports reserved capacity pricing for similar savings.

Budget target: $3,000–$8,000/month for a team of 5–15 engineers with moderate traffic.

Post-Series A: FinOps Lite

You’ve raised a Series A. You have 15–40 engineers. Cloud spend is $10,000–$40,000/month and growing 10–20% month-over-month. The board is asking about gross margins. Your cloud bill is now a meaningful percentage of your burn rate.

Time to get structured.

What to focus on:

Assign a Cost Owner

Someone — ideally a senior infrastructure or platform engineer — should own cloud costs. Not as their full-time job, but as an explicit responsibility. They:

• Review the bill weekly (15 minutes)
• Run a monthly cost review with engineering leads (30 minutes)
• Maintain a backlog of optimization opportunities
• Set up basic cost visibility dashboards

Implement Basic Tagging

You need tags now. Not a complex taxonomy — just enough to answer “which team or service is this resource for?”

Three required tags:

• team: Which engineering team owns this
• environment: prod, staging, dev
• service: Which application or service this supports

Enforce these via Terraform modules (add required tags to your shared resource modules) or AWS SCPs. Backfill existing resources with a one-time script.

Evaluate Savings Plans

If you’ve been running for 6+ months with consistent compute usage, a 1-year Compute Savings Plan is worth evaluating. Compute Savings Plans are flexible — they apply to any EC2 instance type, Lambda, or Fargate in any region.

Look at your last 6 months of compute spend. If the floor (the lowest month) is $8,000, a Savings Plan covering $6,000 of that (75% of the floor) gives you a 30% discount on that committed amount with minimal risk.

Don’t buy 3-year commitments yet. Your infrastructure will look very different in 3 years. Stick to 1-year No Upfront.

The Series A Cost Audit

Run this exercise once:

1. Export your bill by service and sort by cost
2. For each of the top 10 line items, answer: “Do we know why this costs this much?”
3. For anything you can’t explain, dig in

This audit consistently uncovers $2,000–$5,000/month in waste for Series A startups. Common findings:

• Multiple staging environments (one per developer) running 24/7
• EBS volumes attached to stopped instances
• An old prototype still running in a separate AWS account
• RDS Multi-AZ enabled for the staging database
• CloudWatch Logs retention set to “never expire” with 6 months of debug logs accumulated

Budget target: $10,000–$30,000/month, with a clear month-over-month trend that correlates to business growth, not infrastructure sprawl.

Post-Series B: Formalize FinOps

At this point you have 40–100+ engineers, cloud spend is $50,000–$200,000+/month, and it’s a real line item in your P&L. Time to treat cloud costs as a first-class operational concern.

What to focus on:

Hire or Assign a Dedicated FinOps Person

Not a committee. Not a shared responsibility. One person whose primary job is cloud cost optimization. This person should be technical (an engineer, not a finance analyst) and should:

• Own all cost visibility tooling and dashboards
• Run monthly cost reviews with every engineering team
• Proactively identify optimization opportunities
• Partner with finance on budgeting and forecasting
• Report on unit economics (cost per customer, cost per transaction)

A good FinOps engineer pays for themselves many times over. At $50K+/month in cloud spend, even a 10% optimization saves $60K+/year.

Unit Economics, Not Just Total Spend

Stop talking about total cloud spend. Start talking about:

• Cost per active user: Total cloud spend / monthly active users
• Cost per transaction: Infrastructure cost / number of transactions processed
• Cost per customer: Infrastructure cost attributable to each customer tier

These metrics tell you whether your infrastructure costs are scaling efficiently with your business. Total spend going up is fine if cost per customer is going down.

Example: If you’re spending $80,000/month on cloud for 10,000 active users ($8/user/month), and after optimization you’re spending $85,000/month for 15,000 users ($5.67/user/month), your spend went UP but your unit economics improved by 29%.

This is the language that resonates with your board.

Multi-Cloud Visibility

By Series B, many startups are running workloads across two or more cloud providers — maybe AWS for core infrastructure, GCP for ML workloads, and a handful of SaaS tools with their own billing. Consolidating cost visibility across all of these into a single view becomes essential.

This is where a tool like Xplorr fits naturally. Instead of switching between AWS Cost Explorer, GCP Billing, and Azure Cost Management, you get a single pane of glass with anomaly detection across all providers. For a FinOps person managing $100K+/month across multiple clouds, the time savings alone justifies the tool.

Reserved Capacity Strategy

At this scale, your reservation strategy should be methodical:

1. Analyze 6 months of usage data
2. Identify the stable baseline (workloads that run consistently)
3. Cover 70–80% of baseline with 1-year Savings Plans (No Upfront)
4. Use spot instances for variable workloads (CI/CD, batch processing, dev environments)
5. Keep 20–30% on-demand for flexibility and new workloads
6. Review quarterly and adjust

This blended approach typically achieves 25–35% savings on compute spend compared to all on-demand pricing.

The Cost-Saving Roadmap: Day 1 to Scale

Here’s the practical sequence, regardless of your current stage:

Week 1: Visibility

• Enable Cost Explorer (AWS) or Billing Export (GCP/Azure)
• Set up billing alerts at 80%, 100%, 120% of current spend
• Identify your top 5 cost line items

Week 2: Quick Wins

• Schedule non-production environments (save 60–70% of non-prod compute)
• Delete idle resources: unattached EBS volumes, unused Elastic IPs, empty load balancers
• Right-size your most over-provisioned instance (check CloudWatch CPU/memory metrics)

Month 2: Structural Changes

• Implement VPC endpoints to reduce NAT Gateway costs
• Move CI/CD to spot instances
• Set up basic tagging and enforce on new resources
• Review and reduce CloudWatch Logs retention periods

Month 3: Process

• Run your first monthly cost review
• Establish per-team budgets based on current spend + 10% growth margin
• Create a cost optimization backlog in your project tracker

Month 6: Commitments

• Evaluate 1-year Savings Plans based on 6 months of usage data
• Cover 60–70% of stable baseline compute
• Set up quarterly reservation reviews

Ongoing

• Monthly cost reviews with engineering leads
• Quarterly deep-dive on hidden costs (data transfer, NAT Gateway, idle resources)
• Update unit economics metrics monthly
• Revisit reservation strategy every 6 months

The Real Series A Story

Back to the startup I mentioned at the beginning. Here’s exactly where the $10,800/month in savings came from:

Change	Monthly savings
Scheduled staging environment (24/7 → business hours)	$3,200
Right-sized RDS from r6g.xlarge to r6g.large	$2,628
Deleted 4 unused staging databases from old features	$1,720
Moved CI from on-demand to spot instances	$890
Switched from NAT Gateway to VPC endpoints for S3/ECR	$680
Removed Multi-AZ from staging RDS	$1,314
Deleted 12 orphaned EBS volumes	$168
Reduced CloudWatch Logs retention from infinite to 30 days	$200

Total: $10,800/month saved. From $18,000 to $7,200.

None of these changes took more than a day to implement. Most took less than an hour. The hard part wasn’t the execution — it was taking the time to look at the bill and ask “why?”

That’s the real message here. Cloud cost optimization for startups isn’t about complex financial engineering or building a FinOps team. It’s about building the habit of looking at what you’re paying for, questioning whether you need it, and acting on what you find.

Start this week. Open your cloud billing console. Sort by service. Pick the top item you can’t immediately explain.

That’s your first optimization.

---

Keep reading

• How to Cut Your AWS Bill by 30% in One Week
• Hidden Cloud Costs You’re Probably Missing Right Now
• Building a FinOps Practice That Engineers Actually Follow

See how Xplorr helps → Features

---

Xplorr finds an average of 23% in unnecessary cloud spend. Get started free.