If you’re building B2B SaaS platforms on AWS, how worried should you be about your cloud costs?
The Venture Capitalist view
Back in May, venture capital firm Andreessen Horowitz published an article entitled “The Cost of Cloud, a Trillion Dollar Paradox”. They present a thesis that adopting cloud makes perfect sense for startups but that, for companies much later in their journey, cloud spend represents such a significant line item that it might be worth “repatriating” some or all of those workloads by bringing them back in-house.
Well known cloud economist and platypus botherer Corey Quinn presents a typically thoughtful rebuttal in his newsletter, pointing out that some of the assumptions made by the original authors are likely flawed. I’m not going to dissect either side of the argument in any depth here, but for what it’s worth, I mainly agree with Corey’s assessment.
The Scale Factory view
The idea of taking a mature SaaS platform running happily on AWS, and stuffing it into a data centre, throwing away years of operational experience just to keep shareholders happy seems farcical to me.
However, through our work reviewing over 350 AWS workloads, we do know that 70% of teams don’t do a good job of monitoring usage and cost, as determined by the AWS Well-Architected review framework.
AWS provides tooling for reporting on cost usage, but this is often overlooked during the early stages of a business: it’s arguably “too financial” for technical teams, and “too technical” for financial teams.
The thing we recommend is to build a culture where your development teams are thinking about incorporating cost monitoring and attribution as a first class product concern, as early in your business journey as possible.
AWS Cost Management for B2B SaaS companies
In a B2B SaaS company, your finance team can usually tell you how much revenue they see from an individual tenant pretty easily. Can you provide information about how much of your AWS bill that tenant contributes to?
Much of this will depend on how your tenancy model is designed. Some of our B2B SaaS customers have a small number of large tenants. In those cases, the “silo” tenancy model makes sense, where each tenant’s resources live under their own AWS account. Attributing spend by tenant is then as straightforward as looking at the bill for their account.
For designs where accounts contain resources for multiple tenants (the “pool” model), things get a bit more involved.
If resources are allocated on a per-tenant basis (for example, an autoscaled group of EC2 instances per customer), you can tag these resources with a tenant id. The AWS cost tools are all tag aware, including the Cost Explorer, and the Cost and Usage Report, both of which can then be used to analyse per-tenant spend.
If you have resources shared between tenants, this is going to need some more work. For storage services you can calculate the total amount of stored data per tenant, and derive a cost from that. For example an RDS cluster might have a schema per tenant - you’ll need to ask questions of the database to get to the numbers you’re looking for.
It doesn’t even have to be quite as granular as that. Imagine an API service used by all of your tenants. Perhaps it’s backed by a number of other AWS resources, which you can tag to indicate which service they relate to. Now you can calculate a total monthly cost across all users of that service. Instrumenting your API code, so that it logs a tenant ID for each request, will give you the raw data you need to calculate percentage usage by each tenant. You can then divide the total service cost by each tenant’s usage to arrive at a per-tenant cost.
If you think in these terms as you build your solution, you’ll be able to easily answer questions about cost as your business scales.
If you’d like some help thinking about costs, get in touch. The Scale Factory is an experienced AWS Consulting Partner with a strong track record helping B2B SaaS customers scale their businesses.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.