Cost of Running a SaaS on AWS: Per Customer, Not Month
Orkosi Team · · 12 min read
Most founders can tell you their AWS bill to the dollar and have no idea what their next customer costs. That is the wrong number to know. The cost of running a SaaS on AWS is not a monthly figure, it is a slope: a fixed base you pay whether you have 5 customers or 500, plus a marginal cost that attaches to each new tenant. If you cannot state what customer #51 costs you within about $2, you cannot price confidently, you cannot answer an investor's gross margin question, and you cannot tell whether that enterprise pilot is profitable or charity.
Stop asking what AWS costs. Ask what customer #51 costs
Why the monthly total hides the decision
"We spend $280 a month on AWS" is a sentence with no decision attached to it. It does not tell you whether to raise prices, whether to accept a customer who will upload 400 GB of video, or whether your free tier is a marketing expense or a leak. The total is dominated by things that do not care how many customers you have — a NAT Gateway costs the same at 10 tenants as at 1,000. Division teaches you something; staring at the gross number just makes you anxious.
The only two numbers that matter: fixed base and marginal cost
Fixed base is what AWS charges to keep the lights on with zero paying customers: load balancer, NAT, minimum compute tasks, the smallest production database you are willing to run, monitoring, DNS.
Marginal cost per customer is the extra spend caused by adding one more tenant of typical size: their rows, files, background jobs, bytes out and log lines.
Gross margin on hosting is (revenue minus the AWS cost attributable to serving it) divided by revenue. Bessemer's benchmarks for scaling SaaS companies put healthy software gross margins in the 70 to 80 percent range and above, and hosting is only part of cost of goods sold — support, payment processing and third-party APIs live there too.
The thesis of this article: for the overwhelming majority of early SaaS products, the fixed base is the bill and the marginal customer is close to free. Founders panicking about hosting at 20 customers are usually panicking about a $200 base they would pay anyway.
The fixed/variable split: what actually moves when you add a customer
Costs that don't move: NAT, load balancer, baseline compute, domains, monitoring
A NAT Gateway bills roughly $0.045 per hour just to exist, before a single byte crosses it. An Application Load Balancer bills hourly too. Your minimum two container tasks for availability, your smallest managed Postgres instance, your Route 53 zones, certificate automation and baseline CloudWatch metrics are all simply the price of being in production.
Several of these are step functions rather than smooth curves. Your database does not get 2 percent more expensive with each tenant; it stays flat and then jumps when you move from a db.t4g.small to a db.t4g.medium. Budget for steps, not slopes.
Costs that move: storage, egress, queues, background jobs, AI tokens, per-tenant environments
| Behaves as fixed | Behaves as variable |
|---|---|
| NAT Gateway, ALB hourly charges | S3 object storage per GB-month |
| Minimum container tasks / idle EC2 | Data transfer out and CloudFront delivery |
| Base RDS instance hours | RDS allocated storage growth and backups |
| Route 53, ACM, Secrets Manager | SQS messages, Lambda invocations, worker scaling |
| Baseline CloudWatch metrics and dashboards | Log ingestion volume (grows with traffic) |
| CI/CD minimums | AI model tokens per tenant action |
| Dedicated per-tenant stacks |
For a pre-product-market-fit SaaS, the fixed side is typically 80 percent or more of the bill. That is why average cost per customer collapses so fast: the same $200 base is $10 each over 20 customers and $1 each over 200, while the marginal cost barely moves.
How to measure the cost of running a SaaS on AWS per customer in a week, not a quarter
Tag everything before you need to
Cost allocation tags are key-value labels on AWS resources that let you split the bill by environment, feature or tenant. They are not retroactive. Tags applied today shape next month's data, which is the best argument for doing it now rather than during a board-prep panic.
Use a small, boring schema: env (prod/staging/preview), service, tenant where per-tenant resources exist, and component. Then activate them as user-defined cost allocation tags in the billing console — a separate step people forget, per AWS's cost allocation tag documentation.
Better still, separate environments by AWS account. Account-level separation gives clean totals with zero tagging discipline and makes "how much is staging costing us" a one-click question.
Cost Explorer, grouped the right way
Pull the last 30 days in Cost Explorer at daily granularity, grouped by service. That gives you the shape. Then regroup by your env tag to strip out non-production noise, usually 15 to 30 percent of an early bill.
Mark the production total as your starting figure, then split it: anything billed hourly regardless of traffic goes in the fixed column, anything billed per GB, per request or per invocation goes in the variable column.
Divide by a usage metric, not just headcount
Tenant count is a decent first denominator but a poor second one. Pick the unit that actually drives spend: documents processed, minutes transcoded, seats active in the last 30 days, API calls. The AWS Well-Architected SaaS Lens is explicit that measuring per-tenant consumption is a design requirement, not an afterthought.
Compute two numbers: the mean cost per tenant and the cost of your 90th-percentile tenant. The gap between them is your pricing risk. If your heaviest customer costs 15 times your median one and pays the same, you do not have a hosting problem, you have a packaging problem.
A worked example: a 50-customer B2B SaaS, line by line
The numbers below are an illustrative model, not a quote. Build your own in the AWS Pricing Calculator before you trust anyone's blog post, including this one.
The bill
A document-workflow B2B app: containers on Fargate, managed Postgres, S3 for files, CloudFront in front, SQS plus workers for background jobs, CloudWatch for logs.
| Line item | Monthly | Nature |
|---|---|---|
| Fargate baseline (2 tasks) | $72 | Fixed |
| RDS Postgres (small, single AZ) + base storage | $31 | Fixed |
| NAT Gateway (hours) | $33 | Fixed |
| Application Load Balancer | $18 | Fixed |
| CloudWatch logs, metrics, alarms | $26 | Mixed |
| Route 53, ACM, Secrets Manager, ECR | $11 | Fixed |
| S3 storage (100 GB across tenants) | $3 | Variable |
| CloudFront + data transfer out (150 GB) | $14 | Variable |
| SQS, Lambda, scaling tasks | $17 | Variable |
| Backups and snapshots | $8 | Variable |
| Total | $233 |
Fixed share: roughly $191, or 82 percent. Average cost per customer: $4.66.
The marginal customer
Customer #51 adds about 2 GB of S3 objects ($0.05), 0.5 GB of database storage plus backups ($0.09), 3 GB of delivery out ($0.26), a slice of worker compute and queue traffic ($0.35), and 0.4 GB of log ingestion ($0.20).
Marginal cost: roughly $0.95. Not $4.66. The average is four and a half times the truth, which is exactly why averages make bad pricing decisions.
The margin at $49 and at $9
| Price per customer/month | Revenue at 50 | AWS cost | Hosting gross margin |
|---|---|---|---|
| $49 | $2,450 | $233 | 90.5% |
| $19 | $950 | $233 | 75.5% |
| $9 | $450 | $233 | 48.2% |
At $49 the AWS bill is a rounding error and your attention belongs on acquisition. At $9 you run a 48 percent hosting margin at 50 customers, which is uncomfortable until you grow: at 300 customers the same architecture (with one database step up, call it $320 fixed) costs roughly $605 and the margin recovers to around 78 percent.
Your price point, not AWS, decides whether hosting is a problem. Cheap plans need volume to dilute the fixed base — a go-to-market decision dressed up as an infrastructure one.
The four line items that quietly eat SaaS margin
Data egress and media delivery
Bytes out of AWS are billed per GB with no free scaling. A product that serves video, generated images, exports or large PDFs can flip from 5 percent of the bill to 40 percent in one feature release.
Mitigation: put CloudFront in front of anything repeatedly downloaded and set real cache headers. Trade-off: caching adds invalidation complexity, and personalised assets cache badly.
Storage that never shrinks
S3 and database storage are monotonic in most startups because nothing is ever deleted. Churned tenants from 2023 are still costing you in 2025, with backups multiplying the footprint.
Mitigation: lifecycle rules to Infrequent Access or Glacier, plus a documented deletion policy for churned accounts. Trade-off: archive retrieval is slow and chargeable, and deletion policies need legal and contractual care.
Logs and observability
Log ingestion is priced per GB and default retention is often "forever". A chatty debug logger in a hot path is one of the fastest ways to turn a $230 bill into a $600 one with no customer growth at all.
Mitigation: set retention explicitly (30 days for application logs, longer for audit trails) and sample high-volume events. Trade-off: shorter retention genuinely hurts when debugging an intermittent bug reported three weeks late.
Per-tenant AI tokens and idle preview environments
If your product calls a model per user action, you have converted a fixed-cost business into a variable-cost one: token spend scales with usage, not revenue, unless you meter it. Separately, preview and staging environments bill 24 hours a day while being used maybe 20 hours a month.
Mitigation: per-tenant token budgets and scheduled shutdown of non-production resources. Trade-off: hard caps create support tickets, and overnight shutdowns annoy distributed teams.
Single-tenant vs multi-tenant: the honest cost trade-off
The multi-tenant vs single-tenant question has a clean arithmetic answer: siloing multiplies the fixed base. In the model above, a dedicated stack per tenant costs somewhere between $120 and $190 per month even with shared NAT and shared CI, against $0.95 for a pooled tenant.
When a tenant per stack is worth paying for
Silo when compliance requirements make shared storage a dealbreaker, when a tenant's load genuinely threatens noisy-neighbour behaviour in the pool, or when a contract pays enough to absorb the duplicated base plus the toil of N deployments.
Know your silo premium before the sales call. If a dedicated stack costs $170 of AWS plus an hour of engineering attention a month, your floor is meaningfully above $500, not $99.
The pooled default and its isolation debt
Pooled multi-tenancy is the right default because it maximises dilution of fixed cost, which is where almost all of your early money goes. The cost is isolation debt: one bad query can degrade everyone, and a tenant-filtering bug becomes a data breach.
Pay that debt down with row-level security, tenant IDs enforced at the data layer rather than in application code, and per-tenant rate limits. The SaaS Lens covers the pooled, siloed and bridge models in detail and is worth reading before you commit to either extreme.
When margin is thin, fix pricing before architecture
The order of operations matters because the levers are wildly unequal. Raising price by 20 percent takes a week and moves gross margin more than a quarter of re-architecture.
- Change price or packaging. Fastest, largest effect, no engineering risk.
- Meter the expensive action. Medium effort, aligns cost with revenue permanently.
- Re-architect. Slow, risky, occasionally necessary.
- Commit to reserved capacity. Last, and only once usage is stable.
Usage caps and fair-use clauses are not hostile
Every infrastructure provider you use has limits. Including "10,000 documents per month, then $0.004 each" in your plan is normal commercial behaviour, not punishment. Customers who object to caps are frequently the ones who were going to make you unprofitable.
Metering the expensive action
Find the single action that drives most variable spend — a render, an export, a model call — and attach a counter to it. You do not have to bill for it immediately. Measuring it lets you see margin by tenant and gives you an honest basis for a future usage tier.
Reserved capacity and savings plans: the commitment trap for early startups
Savings Plans and Reserved Instances can cut compute costs substantially, but they lock you into a usage shape for one or three years. Early products change shape constantly: you move from EC2 to Fargate, change instance families, or discover your workload is memory-bound.
A one-year commitment to save $60 a month on a $230 bill is a bad trade when there is a realistic chance you delete that service in six months. a16z's analysis of cloud costs is right that cloud spend becomes a material margin drag at scale — and clear that the scale in question is hundreds of millions in revenue, not your first hundred customers.
Where this fits when agents run your stack
If an AI agent is writing and deploying your application, the cost model should be part of the spec: cost allocation tags applied at provisioning time, explicit log retention, S3 lifecycle rules, and a per-tenant usage counter on the expensive action from the first deploy.
Orkosi builds and deploys products on AWS and keeps iterating through tasks, which makes a monthly "review cost per tenant and tighten retention" task a normal part of the backlog rather than an emergency triggered by a billing alert. Other builders and PaaS platforms can get you deployed too, often with less configurability and less visibility into the underlying AWS resources; the trade-off is that abstraction hides exactly the line items discussed above. For the mechanics, see the Orkosi docs and the comparison with other builders.
One point to be explicit about: Orkosi plans are credit-based and cover the agent work, hosting and tooling described on the pricing page. Your AWS consumption for a production workload is a separate matter with its own economics — precisely why you should be measuring it per customer.
FAQ
What is a typical cost of running a SaaS on AWS per customer?
For a lightweight B2B SaaS with modest storage and no media, marginal cost per tenant commonly lands between $0.50 and $5 per month once you are past 50 customers, while average cost per customer is far higher at low volumes because of a $150 to $400 fixed base. Media-heavy or AI-heavy products can run $5 to $50 or more per tenant. Model your own in the AWS Pricing Calculator.
What gross margin should a SaaS aim for on hosting?
Most benchmarks put overall SaaS gross margin at 70 to 80 percent or better, with hosting ideally consuming no more than 10 to 15 percent of revenue at any reasonable scale. Early on, 40 to 60 percent hosting margin is survivable because the fixed base dominates. If it has not improved by a few hundred customers, the problem is pricing or architecture, not growth.
Should I use AWS or a simpler PaaS for my first 100 customers?
Either works, and the difference is rarely decisive at that scale. A PaaS costs more per unit but saves engineering time; AWS costs less per unit and demands more configuration. Choose based on who maintains it: if nobody on the team enjoys infrastructure, pay the abstraction tax, or use a platform that handles the AWS layer for you.
How do I stop a single heavy customer from blowing up my AWS bill?
Meter the expensive action per tenant, set a plan limit with overage pricing, and add per-tenant rate limits at the API layer. Set AWS Budgets alerts at 120 and 150 percent of expected monthly spend so you find out in days rather than on the invoice. For genuinely outsized tenants, move them to a priced dedicated tier.
Ready to see how it works in practice? Start free and ship something small enough to measure. Then check the plans and credit pricing against the cost model you just built.