1 decision

Paying for it

Where the money goes before a single request arrives, and when that's worth it.

Every service has a cost shape: what it costs doing nothing, and what each unit of work adds. Most surprises on a cloud bill come from a floor nobody noticed, or a slope that looked cheap at small volume.

The first decision is whether each part of a system should cost nothing when it's idle, or run all the time so it's always ready.

The decisions, in order

01 Pay for the work, or pay to be ready? Should this part of the system cost nothing when it's idle, or run all the time so it's always ready? Every service has a cost shape: a floor (what it costs doing nothing) and a slope (what each unit of work adds). Scale-to-zero has no floor and the steepest slope, plus a wait after a quiet spell. Always-on has a floor and a flatter slope. A commitment discounts the floor for years. Read two numbers, the load at 3 am and the average against the peak: near zero at night means pay per use; high all day means pay to be ready, then commit to the floor once it's proven.

If you chose this, use this

Pay for the work: Lambda, Fargate scheduled tasks, Neon: Lambda, Fargate or EC2?
Pay to be ready: A Fargate service for a steady HTTP core, Aurora for heavy steady load
Pay to be ready, in advance: Savings Plans, bought for the floor once three months of usage show it

Other areas

Moving data between services
Events, messages and records travelling from the code that knows to the code that acts.
Putting AI into software
Which kind of intelligence each step of a feature needs, and what happens when it's unsure.
Security, access and residency
Where the data may go, who can reach it, and what runs where it can't do harm.

Want this stack in your AWS account?

Cloudless Labs is a Sydney consultancy. We migrate on-premises systems to AWS, build serverless apps on this stack, and coach teams to ship with Claude Code and Codex.

Talk to us