Building SaaS Products Efficiently on AWS

The easiest way to realize efficiencies in tenancy is to leverage infrastructure as code. If deploying your entire application stack is as simple as a terraform apply or cdk deploy you can automate onboarding, even for large enterprise customers that require their own silo. For pooled tenants, you can continue to maintain a simplified onboarding process and for bridge tenants, you can set up cells each one could map to.

Networking

Networking is another area SaaS applications can realize efficiencies. The first core networking service to consider is Amazon Route53, for DNS. Within Route53 you can leverage a number of features to improve performance and availability. Starting as simply as latency-aware or geo-aware routing or moving all the way up to extremely available solutions like Amazon Application Recovery Controller. If you couple solid and configurable DNS settings with a CDN like Amazon CloudFront, you should be able to meet most of the latency demands your customers have.

In some cases, DNS can become a part of your SaaS product strategy. You can offer custom domains or custom subdomains as a feature of your solution. With AWS Certificate Manager (ACM) you can even automatically provision and vend TLS certificates on behalf of those customers.

Looking beyond DNS, in the past, some AWS-based SaaS providers had to come up with creative networking constructs to fit their service into a customer’s existing networking. SaaS providers would offer VPNs or cross-account VPC peering to make accessing their services easier or more secure. While those methods still have valid use-cases for most workloads, you can now leverage AWS PrivateLink to offer connectivity directly into your customer’s VPCs – across AWS’s own network backbone. This is mutually beneficial because it gives you the opportunity to colocate your resources to the region or availability zone closest to the customer, minimizing networking costs. AWS Transit Gateway has also made it significantly easier to deliver complex networking stacks. Combining these two services is a killer feature for a large number of SaaS solutions.

One last networking concern that bears mentioning is IPv6. It’s now 2022 and IPv4-dependent solutions don’t have the longevity they used to. If you’re building a new SaaS platform that deals with low-level networking it absolutely must work with IPv6.

Economics Interlude

We interrupt this technical discussion to bring you some important advice on how to make informed cost decisions in your infrastructure. Work Backwards. There’s a common business metric called Cost(s) of Goods Sold (COGS). To build a successful SaaS business you must understand your COGS, add a healthy margin, and then use those metrics to drive your infrastructure decisions. Math doesn’t lie. By breaking down your delivery costs into unit economics, whether that unit is a user or a gigabyte, you uncover truths about your infrastructure that no amount of VC funding or growth metrics can overshadow. When we’ve worked with customers to build efficient SaaS applications, understanding their margins has unlocked deep thinking about product and infrastructure.

Now that we understand the economics of building SaaS applications let’s hop back over to the technical discussion.

Compute

For most, but not all, applications, compute is the dominating cost. AWS offers several different compute platforms that each scale and behave in various ways. At the lowest level, we have Amazon Elastic Compute Cloud (EC2) with some 400+ instance types and sizes for virtually any workload. EC2 is a fantastic platform for many solutions, and it has the best margin of any other compute offering from AWS, but there’s a DevOps tax to pay to be able to scale and operate on EC2.

Next, we have the container-based services Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Containerization has a number of advantages over raw application deployments on EC2. First, containers are typically quite a bit easier to test and work with for your development teams. Second, containers often allow you to achieve higher utilization of your underlying compute resources. Finally, containers give you some composability and separation of concerns that are harder to realize when deploying applications directly on EC2. ECS doesn’t have any significant additional costs and works well for many workloads. EKS leverages Kubernetes to provide another useful abstraction layer, at the cost of some fixed infrastructure to support that abstraction. EKS has the additional benefit of the extremely large Kubernetes ecosystem. Deciding between ECS or EKS is a topic that warrants a deep dive of its own, so we’ll save that for another time.

Continuing along the spectrum of compute options we arrive at AWS Fargate. Fargate lets you run containers without having to manage the underlying compute instances. You provision a task by specifying the desired vCPUs, RAM, and container images – and AWS manages the underlying compute. Both ECS and EKS can use Fargate. While pricing varies by region, Fargate typically has a 20-40% cost premium relative to EC2. What does that extra spend get you? You can subtract the entire DevOps tax of EC2 from your application infrastructure. Whether this makes sense or not really depends on the application. Fargate can reduce your operational overhead but if it adds too much to your costs it may not be worth it. That’s why having a good understanding of your margins is so important.

At the end of the compute spectrum, we have one of my favorite AWS products, AWS Lambda. With Lambda we take away yet another configuration concern and only focus on RAM, provisioned and billed in “gigabyte seconds”. The concept of “serverless” didn’t really exist prior to Lambda. Serverless has absolutely transformed our industry since it came into practice in 2014. In the years since its release, Lambda has enabled companies to build SaaS solutions that have generated billions of dollars in revenue. These companies literally could not have been built on other compute platforms.

The advantage of serverless-based SaaS solutions is that the costs tend to scale linearly with the workload. If you’re building a greenfield solution, serverless compute options tend to be an excellent choice. There are a few exceptions around particularly compute-intensive workloads, long-running workloads, or systems that might sit in idle IO_WAIT states for long periods of time. The disadvantage of serverless is that the compute comes at a premium. However, you also get to realize 100% utilization rates of your serverless resources. Understanding this tradeoff is an important step in your infrastructure maturity.