What a small SaaS really costs on AWS

The bill is not the instance

When people estimate a cloud bill, they usually price the servers. For a small SaaS, the servers are often a minority of the total. The rest is made of things that run all the time whether or not you have users: control planes, gateways, load balancers, storage, logs, and environments nobody remembered to turn off.

This guide lists the line items that tend to surprise teams on AWS, explains how to estimate before you provision, and how to keep spend from drifting. It does not quote prices: they change, and they vary by region. Check the current AWS pricing pages and use the AWS Pricing Calculator for numbers.

The usual suspects

Managed Kubernetes control plane

Amazon EKS charges per cluster per hour for the control plane, independently of the nodes. One cluster per environment multiplies that fixed cost. Consider whether development and preview environments can share a cluster, separated by namespaces, while production gets its own.

NAT gateways

Workloads in private subnets reach the internet (to pull images, call APIs, send email) through a NAT gateway. NAT gateways are charged per hour and per gigabyte processed. One per availability zone is the resilient default and also multiplies the hourly cost. Heavy outbound traffic, such as pulling large images on every deploy, shows up here.

Mitigations: VPC endpoints for AWS services such as S3 and ECR, image caching, and a deliberate choice about how many zones non-production environments need.

Load balancers

Each Application or Network Load Balancer has an hourly charge plus a usage component. A pattern of one load balancer per service, per environment, adds up quickly. Route several services through one load balancer or ingress where possible.

Data transfer

Traffic out to the internet is charged per gigabyte. So is traffic between availability zones and between regions. Chatty services spread across zones, cross-region replication and large downloads served directly from your origin all appear here. A CDN in front of static assets usually pays for itself.

Idle preview and staging environments

An environment created for a pull request and never deleted keeps its nodes, databases, volumes and load balancers. Staging environments sized like production and running around the clock are often the second-largest line in a small team’s bill.

Set an owner and an end date for every non-production environment. See Design a preview environment that has an end date.

Storage that outlives its purpose

• EBS volumes left behind after instances or nodes are removed.
• Snapshots retained indefinitely.
• S3 buckets full of build artifacts, logs and old uploads, in the most expensive storage class.

Use lifecycle rules on buckets and retention policies on snapshots.

Logs and metrics

Log ingestion and retention are charged by volume. Debug-level logging in production, verbose access logs and long default retention periods can make observability one of the larger items on the bill. Decide retention per log group, and keep debug logging out of production by default.

Managed databases

A managed database is worth it, but its cost has several parts: instance hours, storage, provisioned IOPS, backups beyond the free allowance, and a standby instance if you enable multi-AZ. Size from evidence, not from fear. The Postgres checklist covers the decisions.

Estimate before you provision

For each environment, write down:

1. Fixed costs: cluster control plane, NAT gateways, load balancers, minimum database size. These run at zero traffic.
2. Variable costs: nodes as traffic grows, data transfer, log volume, storage growth.
3. Multipliers: number of environments, number of availability zones, number of regions.

Price each line from current provider pricing for your region. Then add a margin, because the first month always includes something you forgot.

The fixed costs matter most at the start. For a small SaaS with modest traffic, they can be most of the bill.

Keep it from drifting

• Tag everything with project, environment and owner, so the bill can be broken down by the people who can act on it.
• Set budgets and alerts in AWS Budgets, per environment if you can.
• Review monthly. Sort by service and by environment; look at what grew.
• Turn off what is not in use: scale non-production environments down outside working hours, delete previews when the pull request closes.
• Rightsize based on real utilisation. Oversized nodes and databases are common after a launch that was planned for more traffic than arrived.
• Commit only once usage is stable. Savings Plans and reserved capacity reduce costs for predictable workloads; do not commit for workloads that are still changing shape.

How Purser helps

The Purser is the cost specialist in Kapten’s crew:

• Before you provision, it prices every plan line by line and shows the total against the environment’s budget. A plan that exceeds its cap is not offered for approval until the cap is raised.
• After you provision, it reads spend by environment and service from your cloud bill. Kapten does not resell infrastructure, so the bill is yours and so is the data.
• On a schedule, it looks for idle environments, oversized nodes and databases, orphaned volumes and old snapshots, and suggests a cleanup or rightsizing plan with the expected saving.
• It never deletes anything on its own. Cleanup is a plan like any other, approved by a person.

Run the cost review workflow on an existing environment to see what it finds. Cost features are part of early access; providers and data sources are confirmed during onboarding.

A one-page checklist

• Every resource is tagged with project, environment and owner.
• Each environment has a budget and an alert.
• Non-production environments share infrastructure where safe, and scale down when idle.
• Previews have an end date.
• VPC endpoints for heavy AWS-service traffic; a CDN for static assets.
• Log retention is set deliberately; no debug logging in production by default.
• Snapshots and buckets have lifecycle rules.
• A monthly review with someone who can act on it.