AWS Cost Optimization for SaaS: Protect Your Margins

For a growing SaaS company, the AWS bill is the wrong thing to optimise. It should grow - the question is whether it grows more slowly than revenue. When cloud spend rises faster than the customer base, gross margin erodes quietly, one deployment at a time, and nobody notices until a board meeting or a due diligence request asks for the numbers.

This guide walks through a typical B2B SaaS case: the two metrics I use, how to attribute shared infrastructure to customers, and the changes that tend to matter most.

Short answer: measure cloud cost as a percentage of revenue and infrastructure cost per active customer, using the Cost and Usage Report, cost allocation tags and an agreed method for shared infrastructure. Then fix the architecture where capacity, traffic or managed services cost more than they deliver - and make cost visible to the engineers who create it. The goal is a sustainable cost to serve each additional customer, not the lowest possible bill.

The case: cloud spend growing faster than revenue

An illustrative case, representative of the companies I work with: a B2B SaaS company with around 50 employees, several hundred business customers and a growing AWS footprint. As the business scaled, cloud spend was rising faster than revenue - cloud infrastructure was running at roughly 12-15% of revenue.

The challenge wasn't simply to reduce the bill. It was to find out whether infrastructure costs were growing efficiently with the customer base, and to bring that percentage down without compromising performance, availability or the ability to scale.

The two metrics that matter

• Cloud cost as a percentage of revenue - AWS cost divided by revenue for the same period, with a clearly defined cost scope. It shows how infrastructure spend relates to business growth.
• Infrastructure cost per customer - monthly infrastructure spend divided by active customers, ideally segmented by customer tier or workload. It shows whether serving each customer is getting cheaper or more expensive.

They answer different questions, which is why you need both. The percentage can improve simply because prices went up; cost per customer only improves if the platform does. As arithmetic, not client data:

Production AWS cost:  $45,000 / month
Revenue (MRR):        $330,000
Active customers:     450

Cloud cost as % of revenue = 45,000 / 330,000 = 13.6%
Cost per customer          = 45,000 / 450     = $100 / month

Define the scope before you calculate. Production infrastructure that serves customers belongs in cost of goods sold; staging, CI runners and developer sandboxes are R&D. Mixing them understates gross margin and makes the trend meaningless. The fundraising guide covers how to present the split to investors.

How to measure cost per customer

Start with the AWS Cost and Usage Report, with cost allocation tags and workload-level attribution wherever possible. The steps:

1. Tag resources by application, environment and product where practical, and activate the tags for cost allocation.
2. Break costs down in CUR by service, account and resource where supported.
3. Attribute shared infrastructure using an agreed method - usage, request volume or compute consumption.
4. Track monthly cost per active customer and, where useful, per transaction or unit of workload.

A first cut by product tag, in Athena over CUR 2.0 (tag keys appear as user_<tag>):

SELECT COALESCE(NULLIF(resource_tags['user_product'], ''), 'untagged') AS product,
       SUM(line_item_unblended_cost) AS cost
FROM cur
WHERE date(bill_billing_period_start_date) = DATE '2026-09-01'
GROUP BY 1
ORDER BY cost DESC;

The untagged row is the first number to bring down: spend nobody can attribute is spend nobody owns.

Shared infrastructure needs an allocation model

In a multi-tenant platform, most resources serve every customer at once, so you can't assume each one maps to a single tenant. The model doesn't have to be perfect; it has to be defensible, agreed in advance and applied consistently, so that month-to-month changes reflect the platform rather than the method.

On EKS, split cost allocation data brings pod-level CPU and memory costs into CUR, which makes the compute row far less of a guess when tenants or teams map to namespaces.

The changes that matter most

1. Fix the architecture where cost exceeds value

Find the workloads paying for unnecessary capacity, excessive cross-AZ traffic, or managed services that cost more than the value they deliver. Depending on the workload, the changes include:

• Rightsizing compute from real utilisation - see EC2 rightsizing.
• Reducing NAT Gateway and cross-AZ traffic - see data transfer costs.
• Optimising database capacity - see RDS right-sizing.
• Moving suitable services from EKS to ECS or Fargate where that simplifies operations and lowers total cost. For a small platform team, the EKS cluster fee is the small part; the engineering time to run Kubernetes well is the large one.

2. Make cost ownership visible to engineering

Regular cost reviews, workload-level dashboards and alerts for unexpected increases. The aim is to catch inefficient resource usage before it becomes a permanent part of the cost base. Engineers should see the financial impact of their architectural decisions alongside CPU and latency - not discover it in a quarterly finance review. The reporting side is covered in what FinOps actually reports.

Reporting the outcome

Report verified changes in three numbers: infrastructure spend, cost per customer, and cloud cost as a percentage of revenue - measured from the bill, not from estimates. Track reliability and performance alongside them, so it's clear the savings didn't come out of the product.

The objective isn't the lowest possible AWS bill. It's an infrastructure platform where the cost of serving each additional customer stays economically sustainable as the business grows.

Mistakes that distort SaaS cost metrics

• Counting R&D environments as cost of goods sold. It understates gross margin and hides production efficiency.
• Changing the allocation method mid-stream. The trend then measures the method, not the platform.
• One blended cost per customer. An enterprise tenant and a self-serve account rarely cost the same to serve; segment by tier.
• Chasing the lowest bill. Cutting redundancy or headroom to improve a percentage shows up later as an incident, a churned customer or a failed due diligence question.

FAQ

What is a good cloud cost as a percentage of revenue for SaaS?

There is no universal number - it depends on how compute-heavy the product is. What investors and boards look at is the trend: cloud cost as a share of revenue flat or falling while revenue grows, and gross margin holding up against the levels commonly expected of software businesses.

How do I calculate infrastructure cost per customer?

Take production infrastructure cost for the month - directly attributed costs plus an agreed share of shared infrastructure - and divide by active customers. Segment by tier or plan where the cost to serve differs.

Do I need to attribute every AWS resource to a customer?

No. Attribute directly where you can, allocate shared infrastructure with a consistent key such as requests or compute time, and keep the untagged remainder small and visible.

Is ECS or Fargate cheaper than EKS?

Sometimes, mostly in operational cost rather than the bill. For a small team running a handful of services, ECS or Fargate removes cluster management work; for a large platform already invested in Kubernetes, EKS usually remains the better fit.

When should a SaaS company start tracking cost per customer?

Once cloud spend is material against revenue or more than one team deploys to production - and well before a fundraise, because diligence teams ask for it.

Want your unit economics measured properly?

Cost attribution, cost per customer and the architecture changes behind them are part of every AWS cost optimization engagement I run. The overall order of work is in the AWS cost optimization guide.

Sources

• AWS Cost and Usage Reports and the CUR 2.0 data dictionary
• AWS cost allocation tags
• Split cost allocation data for Amazon EKS
• Amazon EKS pricing and AWS Fargate pricing