Cloud-native architecture and cost
Most systems now run on someone else's infrastructure, billed by the hour, the request and the gigabyte. That changes the architect's job in two ways. Applications must be built to be started, stopped, copied and moved by a platform at any moment. And cost stops being a fixed budget line: every design decision, from a cache to a cross-zone call, shows up on a monthly bill. Cost becomes an architecture characteristic like any other.
1. The idea
The twelve-factor app
Written by engineers at Heroku in 2011, the Twelve-Factor App is still the shortest checklist for software that a platform can run, scale and replace freely.
| Factor | Rule | Why the platform needs it |
|---|---|---|
| Config | Store config in the environment | The same build runs in every environment |
| Backing services | Treat databases, queues and caches as attached resources | Swap them by changing a URL |
| Build, release, run | Strictly separate the stages | Any release can be rolled back exactly |
| Processes | Run as stateless processes | Any instance can serve any request (Module 08 of System design) |
| Disposability | Start fast, shut down gracefully | The platform kills and moves instances at will |
| Dev/prod parity | Keep environments as similar as possible | Fewer "works on my machine" surprises |
| Logs | Treat logs as event streams to standard output | The platform collects and routes them |
The other five (one codebase, declared dependencies, port binding, scaling out through processes, one-off admin tasks) complete the list on 12factor.net.
Well-Architected frameworks
Each big cloud publishes a review framework. AWS's has six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Azure and Google Cloud have their own with similar pillars. They're useful as a checklist of architecture characteristics (Module 04) with each cloud's specific practices attached.
Multi-tenancy: silo, pool and bridge
A software-as-a-service product serves many customers (tenants) from one system. AWS's SaaS guidance names three models: silo (each tenant gets dedicated resources, such as its own database or whole stack), pool (tenants share resources, separated by a tenant ID) and bridge (a mix: some parts siloed, others pooled, decided service by service). Silos isolate failures, noisy neighbours and data; pools are cheaper and simpler to operate.
Cost as an architecture characteristic
The FinOps Foundation describes cloud cost management in three repeating phases: inform (see who spends what), optimise (use less, and pay less for what you use) and operate (make the changes, continuously). For an architect the key number is unit cost: the bill divided by something the business sells, such as cost per order or per active user. A bill that grows is fine if unit cost falls.
2. How it works
A noisy neighbour in a pooled database
A SaaS invoicing product pools 400 tenants in one database. One large tenant starts a bulk import on Monday morning.
Bringing down the cost per order
An online shop's cloud bill is $42,000 a month for a million orders. The finance director asks why it grew faster than sales. Watch where the money goes and what the architecture changes.
3. Try it yourself
Choose a tenancy model
A SaaS product. Pick a model and the number of tenants. Assumed prices, to show the shape: a whole silo stack is $400 a month per tenant; a pooled platform is $3,000 a month plus $8 per tenant; the bridge here pools compute ($2,000) and gives each tenant its own small database ($60).
Serverless, Kubernetes or virtual machines?
One API service, three ways to run it. Set the average traffic and how spiky it is, and choose whether to count the engineers each option needs. Infrastructure is cheap to see on a bill; people are the larger cost until traffic is high.
Assumed figures, to show the shape (AWS us-east-1 list prices, checked October 2026): serverless is a function with 512 MB running 100 ms per request ($0.0000166667 per GB-second plus $0.20 per million requests) behind an HTTP API ($1.00 per million), about $2.03 per million requests. One 4-vCPU node costs about $120 a month on demand and handles 400 requests a second. Kubernetes adds $73 a month for the control plane, autoscales between 3 nodes and 1.5× the average load, and needs half an engineer for the platform. Virtual machines are sized for the peak (at least 2), bought with a three-year commitment at 40% off, and also need half an engineer. Serverless needs a tenth of one. An engineer costs $250,000 a year.
4. Trade-offs
Isolation vs cost
Silos contain failures and satisfy strict data rules, at a cost per tenant and one deployment per tenant. Pools share everything cheaply, and need tenant-aware throttling, quotas and data filters everywhere.
Managed services vs portability
Managed databases, queues and functions remove operations work and tie you to one provider's interfaces. Isolate them behind ports (Module 07a) where switching is a realistic prospect, not everywhere.
Commitments vs flexibility
Reserved capacity and savings plans cut compute prices substantially for steady load, in exchange for a one- or three-year commitment. Commit for the baseline, pay on demand for the peaks.
Optimise vs build features
Every hour spent cutting the bill is an hour not spent on the product. Track unit cost; act when it rises or when a single change has a clear payback.
5. In real projects
Tag everything by owner and product, so the bill can be split by team and feature. Without that, cost can't be anyone's responsibility.
Look for architecture-shaped costs. Chatty calls between availability zones or regions are billed per gigabyte; logs and metrics can cost as much as the application; idle non-production environments run all weekend; over-provisioned instances run at 10% CPU. These are design decisions, not accounting ones.
Put cost in the fitness functions. Alert when unit cost moves more than a set percentage, or when a new deployment raises cost per request (Module 26).
Estimating cost before you build
At design time nobody has a bill, but an architect can still project one. List the cost drivers per user (requests, stored data, data sent out), multiply by users and unit prices, and add the fixed floor that any production system pays: two zones for availability, a database with a standby, backups, monitoring, support. An example for a consumer app, assuming 600 API requests, 50 MB of stored data and 200 MB of downloads per monthly active user:
| Monthly | 1,000 users | 10,000 | 100,000 | 1,000,000 |
|---|---|---|---|---|
| API requests | 0.6M | 6M | 60M | 600M |
| Compute | $150 | $150 | $400 | $2,500 |
| Database | $200 | $200 | $900 | $6,000 |
| Storage ($0.023/GB) | $1 | $12 | $115 | $1,150 |
| Data out ($0.09/GB) | $18 | $180 | $1,800 | $18,000 |
| Monitoring, backups, support | $300 | $400 | $1,200 | $5,000 |
| Total | ≈ $670 | ≈ $940 | ≈ $4,400 | ≈ $32,700 |
| Per user | $0.67 | $0.09 | $0.04 | $0.03 |
The shape matters more than the figures. Below about 10,000 users the fixed floor is most of the bill, so cost per user is high and falls fast. At a million users the per-user drivers dominate, and here one of them, data sent to the internet, is over half the total: serving media through a CDN, compressing responses or caching on the device changes the projection more than any compute choice. The cost also moves in steps, not a line: a database tier upgrade, a second region, an enterprise support plan. Put the projection in the design doc, and track the real unit cost against it once the system runs.
Where cloud bills run away
| Area | The trap | The fix |
|---|---|---|
| Compute | Instances sized for a peak that lasts two hours; everything bought on demand; test environments on all weekend | Right-size and autoscale; commit to the steady baseline with savings plans or reserved instances (AWS quotes up to 72% off); run interruptible batch work on spot capacity (up to 90% off); schedule non-production off |
| Storage | Every object kept forever in the hottest tier; old snapshots and unattached volumes; logs kept 90 days by default | Lifecycle rules that move data to cheaper tiers as it ages (S3 Standard about $0.023 per GB-month, Infrequent Access about $0.0125, Glacier Deep Archive about $0.001), mindful of retrieval fees and minimum storage periods; short retention for debug logs |
| Data transfer | Internet egress (about $0.09 per GB), cross-zone calls (about $0.01 per GB each way), and NAT gateways charging $0.045 per GB processed, for example when containers pull images or reach S3 through NAT | A CDN for downloads; zone-aware routing; VPC endpoints for cloud services; keeping chatty services and their data in one zone or region; checking what observability agents ship out |
| Managed services | Per-request pricing that's cheap at launch and dominant at scale; idle provisioned capacity | Re-run the cost model at each order-of-magnitude of growth; the lab above shows where the curves cross |
Two choices sit behind all of these. Cloud turns capital expenditure (buying servers up front, depreciated over years) into operating expenditure (a monthly bill that follows usage): finance teams see the bill grow with the business, and you pay a premium for not having to plan capacity. And every saving trades against something else: commitments against flexibility, cheaper tiers against retrieval time, one zone against availability. Module 33a covers the wider build-or-buy economics.
Say it in the interview
- "How would you make this cloud-ready?" Stateless processes with config in the environment, managed backing services attached by URL, fast start-up and graceful shutdown, logs to standard output: the twelve-factor rules.
- "Silo or pool for tenants?" Pool by default for cost and simplicity, with per-tenant quotas; silo the parts that regulation or large customers need isolated, which is the bridge model.
- "Serverless or Kubernetes?" Serverless for spiky or modest traffic and small teams: no idle cost and almost no operations. At high, steady load, per-request pricing overtakes a cluster's cost including the engineers who run it, so re-check the numbers as traffic grows.
- "How do you control cloud cost?" Make it visible by team, track cost per order as a characteristic, and fix the architecture-shaped costs first: idle capacity, cross-zone chatter, log volume.
- Local file storage or in-memory sessions on instances the platform can replace.
- A pooled multi-tenant database with no per-tenant limits.
- No idea what the system costs per user or per transaction.
6. Remember it
How this hook works: what "any taxi, meter running" means
What the slogan means, phrase by phrase
- "Any taxi"
- Disposable, stateless instances that the platform can start, stop and replace: the twelve-factor rules.
- "meter running"
- Every resource is billed by use, so cost is an architecture characteristic measured as unit cost.
Why this picture fits: you leave nothing in a taxi you'll need later, and you don't keep it waiting outside with the meter on.
The story → the concept
| Taxis | Cloud-native |
|---|---|
| Any car will do | Stateless, disposable instances |
| Nothing left in the boot | No local state; backing services hold it |
| The meter | Pay-per-use billing |
| Cost per journey | Unit cost per order or user |
The trap it saves you from
Lifting a server-era design into the cloud and paying for idle capacity and lost sessions.
7. Common mistakes
8. Design exercise (30 minutes)
- Twelve-factor audit (10 min). Take a service you know and mark each factor met, partly met or not met.
- Unit cost (10 min). Estimate its monthly cost and divide by the business unit it serves. Which three items make up most of it?
- One change (10 min). Propose one architecture change that lowers unit cost, with its payback and its effect on other characteristics.
9. Self-check quiz
The platform may kill an instance at any moment. Which twelve-factor rule prepares for that?
Tenants share compute, but each tenant's data lives in its own database. Which model?
What is unit cost?
Which of these is one of the six pillars of the AWS Well-Architected Framework?
One tenant's bulk import slows every other tenant in a pooled database. What fixes it?
A cluster in private subnets pulls container images and reads S3 through a NAT gateway, and the NAT line on the bill is large. What fixes it?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| The Twelve-Factor App | 30 min | All twelve factors with explanations. |
| AWS Well-Architected: the pillars | reference | The six pillars and their design principles. |
| Silo, pool and bridge models (AWS SaaS Lens) | 15 min | The tenancy models defined. |
| Amazon S3 storage classes | 15 min | Storage tiers, retrieval times and minimum durations. |
| AWS Lambda pricing | reference | Per-request and per-GB-second prices used in the compute lab. |
| FinOps phases (FinOps Foundation) | 15 min | Inform, optimise, operate. |