cloudcostdown.euSaaS Cost Optimization · AWS Guide
AWS Cost Optimization for SaaS: Know What Each Customer Costs You
Most SaaS teams know their AWS bill. Almost none know their AWS bill per customer. Without that number, you’re pricing on instinct, tiering by guess, and discovering margin problems at Series C instead of Series A.
This guide covers the mechanics specific to SaaS on AWS: silo vs pool architecture trade-offs, building cost-per-customer visibility across multi-tenant infrastructure, aligning cloud spend with usage-based billing, and the unit economics benchmarks your investors will eventually ask about.
Why SaaS AWS Cost Optimization Is Different
A single-product startup has one workload. Costs are directly attributable to the product. SaaS has multiple tenants sharing the same infrastructure - which means standard AWS tagging, the approach that works fine for a single-product startup, breaks down immediately.
The attribution problem
A shared RDS instance serves 200 tenants. One DynamoDB table holds all tenant data. One EKS cluster runs all tenant workloads. You can't tag your way to per-tenant costs without application-layer instrumentation.
Pricing tier misalignment
Your lowest-revenue tier is almost always your most expensive to serve. Without per-tier cost data, you won't catch this until your gross margin starts compressing - often 12–18 months after the problem begins.
Invisible floor costs
Even a tenant who isn't actively using your product generates baseline costs: idle ECS tasks kept warm, S3 data at rest, CloudWatch log retention. In pooled architectures, these are invisible without active metering.
Multi-Tenant Architecture Cost Patterns
Architecture choices at the tenancy layer are the single biggest determinant of cost structure and attribution complexity. Here are the three models and their cost trade-offs.
One account (or VPC) per tenant
Advantages
- Cost attribution is trivial - linked accounts give you per-tenant breakdowns in Cost Explorer
- Compliance boundaries are clean, useful for enterprise and regulated tiers
- No noisy-neighbour risk - one tenant's burst doesn't affect others
Cost risks
- · Provisioning overhead per tenant: EKS clusters, RDS instances, NAT Gateways all multiply
- · Reserved Instance and Savings Plans utilisation drops - commitments are per-account
- · Minimum floor per tenant is high - unprofitable below a certain ACV
Best for: High-ACV enterprise tiers, regulated workloads (healthcare, fintech)
All tenants share infrastructure
Advantages
- Best unit economics at scale - shared EKS nodes, shared RDS, one NAT Gateway
- Reserved Instances and Savings Plans are fully utilised across tenants
- Marginal cost per new tenant is low once base infrastructure is paid for
Cost risks
- · Cost attribution requires instrumentation - you must tag or meter at the application layer
- · Noisy-neighbour risk requires throttling and fair-use policies
- · Pricing model misalignment risk - what you charge vs what each tenant actually costs can diverge silently
Best for: SMB and self-serve tiers, early-stage (pre-$5M ARR), usage-based pricing models
Silo at the tier boundary, pool within each tier
Advantages
- Enterprise tenants get isolated accounts; SMB tenants share pooled infrastructure
- Savings Plans and RIs can be optimised per-tier account
- Cost-per-customer calculation is scoped to tier, simplifying unit economics
Cost risks
- · More operational complexity - multiple account structures and tagging strategies to maintain
- · Attribution within the shared pool still requires application instrumentation
Best for: Series B–C with mixed tiers: a few large enterprise accounts + a long tail of SMB
Building Cost-Per-Customer Visibility
The goal isn’t perfect accounting. It’s a good-enough approximation that lets you make pricing and architecture decisions with data instead of intuition. Start with the approach that fits your current tenancy model, then evolve it.
AWS Application Cost Profiler, which previously automated some of this, was discontinued in September 2024. The current approach is either linked accounts (silo model) or manual instrumentation with the Cost and Usage Report (CUR).
Silo model: use AWS linked accounts
Low complexityEach tenant or tenant group maps to an AWS account under AWS Organizations. Cost Explorer's linked account dimension gives you a per-tenant breakdown with zero instrumentation. Savings Plans and RIs still apply at the payer level. This is the only approach that gives you exact attribution without application-layer work.
Pool model: tag at the resource level
Medium complexityEffective for dedicated-per-tenant resources (e.g., one RDS instance per tenant in a partially-isolated pool). Tag resources with tenant-id and activate the tag in the Billing console. AWS Cost Explorer will surface per-tenant costs for tagged resources. Shared resources (EKS nodes, NAT Gateways) still need a second-pass allocation.
Pool model: application-layer metering
High complexityFor fully shared infrastructure, instrument your services to capture per-tenant activity: API request counts, Lambda invocations, DynamoDB consumed capacity units, S3 operations. Store this in a data store (DynamoDB, S3 + Athena) and correlate with the Cost and Usage Report (CUR) to calculate each tenant's proportional share.
Proxy metric allocation
Medium complexityWhen full instrumentation isn't feasible, use a proxy: API call frequency per tenant, transaction volume, or seat count to apportion shared costs. This won't be exact, but it's accurate enough for pricing decisions and tier profitability analysis. AWS X-Ray traces can surface per-tenant latency and call volumes cheaply.
Practical starting point for pooled architectures
Enable Cost and Usage Reports (CUR 2.0) at hourly granularity. Add a tenant-id tag to any resource that’s dedicated to a single tenant (even in a mostly-pooled setup). For shared resources, pick one proxy metric - API call frequency per tenant via Lambda authorizer logs, or DynamoDB consumed capacity units per tenant partition key prefix - and use it to apportion shared costs. Publish both to Athena. A single SQL query gives you monthly CPC by tenant.
SaaS Cloud Unit Economics: Metrics and Benchmarks
These are the metrics that matter and the benchmarks from public SaaS data and 10-K filings that give you a calibration point.
Cloud cost as % of revenue - stage benchmarks
Sub-$10M ARR
15–25%
Common and acceptable, but you need a path to efficiency before Series B diligence.
$10M–$50M ARR
10–20%
Optimization should be underway. RI/SP coverage, rightsizing, and per-tenant attribution expected.
$50M+ ARR
Under 10%
Expected by investors and acquirers. Infrastructure-heavy platforms (video, ML) may justify higher with explanation.
Source: Public SaaS 10-K filings and attrb.io benchmarking data, 2026. Infrastructure-heavy platforms (video streaming, ML inference) typically run 5–10pp higher.
Cost per customer (CPC)
Total AWS COGS ÷ active customersThe headline metric. If CPC is rising faster than ARPU, your margin is compressing. Track it monthly.
Cloud cost as % of revenue
Monthly AWS spend ÷ MRRThe benchmark number VCs and acquirers use. Target varies by infra intensity (see benchmarks below).
Cost per tier
AWS COGS attributable to each pricing tier ÷ customers in that tierIdentifies which tiers are subsidising others. The most common finding: the lowest-priced tier is the most expensive to serve.
Marginal cost per new customer
Incremental AWS cost when adding one customerTells you whether your architecture scales sub-linearly (good) or linearly/super-linearly (needs fixing).
Cost per feature (advanced)
AWS spend attributable to a feature ÷ customers using itFinds features that drive disproportionate cost relative to adoption or revenue. A 2% adoption feature consuming 20% of costs is a candidate for re-architecture or tier restriction.
The gross margin connection: AWS COGS sits directly in gross margin. For SaaS, industry median gross margin runs 70–80%. If cloud costs are 20% of revenue, that alone drags gross margin 10–15pp below median. Investors know this number. If you don’t know your CPC, you’ll be explaining your gross margin from a position of uncertainty.
Aligning AWS Spend With Usage-Based Billing
The most common SaaS cost problem isn’t total AWS spend - it’s misalignment between what you charge and what you actually spend to serve each customer. Here are the common billing model patterns and where the cost-revenue alignment breaks.
Per-seat billing with pooled compute
High misalignment riskSeat count doesn't predict compute load. A 10-seat customer running batch jobs at 2AM can cost more than a 50-seat customer using only the UI. Attribution needs to be activity-based, not seat-based.
Fix: Add per-tenant Lambda invocation and ECS CPU metrics. Use seat count as a floor check, not the primary allocation key.
Usage-based billing (API calls, events, records)
Low misalignment riskWhen billing dimensions align with infrastructure consumption drivers (e.g., billing per API call and the API call drives Lambda + DynamoDB), cost and revenue move together. This is the ideal SaaS model for infrastructure cost alignment.
Fix: Verify your billing metric actually drives infrastructure cost. If billing is per API call but the expensive operation is storage (not calls), the alignment breaks.
Flat-rate tiers with unlimited usage
Very high misalignment riskA fixed $99/month tier with unlimited usage is a cost liability if tenant behavior is heterogeneous. One heavy user in a flat-rate tier can consume 10× the average. Without per-tenant cost visibility, you won't see this until margins deteriorate.
Fix: Instrument cost per customer within the flat-rate tier. Add soft limits or throttling policies. Use cost data to redesign tier boundaries around actual usage patterns.
Freemium / free tier
Highest risk tierFree tier tenants generate real AWS costs with zero revenue. The math only works if conversion rates and free-to-paid upgrade economics justify the cost. Without per-tenant attribution, free tier cost is invisible until it compounds.
Fix: Set hard resource limits on free tier tenants at the infrastructure level (Lambda concurrency limits, DynamoDB on-demand caps, S3 lifecycle policies). Measure free tier CPC monthly.
SaaS-Specific AWS Waste Patterns
Beyond the standard startup waste (oversized EC2, missing Savings Plans), SaaS architectures accumulate specific waste that only shows up when you look at the per-tenant or per-tier level.
Idle warm pools per tenant
Keeping one ECS task per tenant warm for latency means N idle containers. At 200 tenants, that's 200× the baseline compute cost.
Per-tenant RDS instances in silo models
Silo deployments with db.t3.medium per tenant rarely utilise more than 5% CPU. But you can't consolidate without re-architecting. This is the most expensive silo model trade-off.
Uncontrolled free-tier data accumulation
Free tenants generate S3 objects, CloudWatch logs, and DynamoDB records indefinitely. Without lifecycle policies scoped to the free tier, storage costs compound silently.
NAT Gateway multiplied by silo VPCs
One NAT Gateway per tenant VPC at $0.065/hour is $1.56/day per tenant. At 100 tenants, that's $5,700/month in NAT baseline fees before any data processing charges.
Missing cross-account Savings Plans
In silo (multi-account) architectures, Savings Plans purchased in the management account apply across all member accounts. Teams that buy per-account lose the consolidated discount benefit.
Over-instrumented observability per tenant
Detailed CloudWatch custom metrics, per-tenant dashboards, and X-Ray traces per tenant add up. CloudWatch charges $0.30/metric/month. At 50 metrics × 500 tenants, that's $7,500/month before any logging costs.