Cloud cost is an architecture problem

The easy money, once

Removing idle resources, rightsizing instances and buying commitments such as Savings Plans are worth doing. They are also one-off gains: the bill drops, then starts growing again at the same rate as before. They lower the level of the cost line; they do not change its slope.

The reason is simple. Those actions correct how resources are bought and sized today. They do not change how the system uses resources as it grows: how much data it copies, how much it moves between zones and services, how much it logs, and whether it scales with real demand or sits sized for the peak.

One-off savings and lasting savings

The savings that last

• Workloads sized for their real pattern, not for the peak every day. Payments volume has daily, weekly and month-end peaks. Autoscaling on the real driver, scheduled scaling for known peaks and serverless for spiky components keep cost close to demand. For commerce platforms, our peak readiness guide shows how to prepare for the busiest days without paying for them all year.
• Data that stops being copied between systems and teams. Every extra copy of transaction data is stored, processed, backed up and secured again. One governed copy, read by every consumer, removes cost and removes disagreements about which copy is right.
• Service designs that avoid unnecessary data transfer. Cross-Availability Zone traffic, cross-Region replication and NAT gateway processing are all charged per gigabyte. VPC endpoints for AWS services, compression and keeping chatty services close together where resilience allows reduce them.
• Logging that matches its value. Verbose logs on the transaction path grow with every request. Log levels by environment, sampling and shorter retention keep observability without paying for noise.
• Ownership tags that let every team see its own bill. Accounts per workload and a small set of mandatory tags make cost visible to the people who can change it.

Why ownership matters most

When each team sees its own cost and its unit cost every month, architecture decisions start to include cost by default. A design review asks "what does this do to cost per transaction?" in the same breath as "what does this do to latency?". That habit is worth more than any single optimization.

The best measure is a unit cost, such as cost per 1,000 transactions, tracked monthly against volume. If it is flat or falling while the business grows, the architecture is scaling well. If it rises, the reason is usually one of the patterns above. Our guide on cost per transaction on AWS explains how to measure it, and the calculator gives a first estimate in a minute.

A quick way to see whether ownership exists today: activate a team tag as a cost allocation tag in the Billing console, then ask Cost Explorer for monthly cost by that tag. Whatever lands in the "No tag key" group is spend nobody owns yet.

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-11-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=TAG,Key=team

Cost allocation tags only apply from the day you activate them, so start now even if the tagging is incomplete.

A worked example

Consider a payments platform spending $85,000 a month on AWS, with volume growing 25% a year and spend growing 40%. These are the default values in our cost per transaction calculator.

• A rightsizing and commitments exercise cuts the bill by, say, 15% in the first quarter. The level drops to about $72,000.
• Nothing about the architecture has changed, so spend keeps growing faster than volume. Within a year, the bill is back above where it started, and cost per transaction is rising again.
• If, in parallel, the team fixes the two largest architectural drivers, such as capacity sized for month-end and duplicated transaction data, spend grows closer to volume. The level drops and the slope flattens.

The figures are illustrative, but the shape is the one we see repeatedly: one-off savings buy time, and architecture decides what happens with it.

Questions for every design review

Cost becomes part of architecture when it is part of the conversation where architecture is decided. Five questions are enough:

1. How does this component's cost grow with transaction volume: flat, linear or faster?
2. Does it create another copy of data that already exists?
3. How much data will it move across Availability Zones, Regions or the internet?
4. What does it log, and for how long do we keep it?
5. Who owns its cost, and where will they see it?

A 90-day start

1. Month 1: take the one-off savings, and put account and tag boundaries in place so each team's cost is visible.
2. Month 2: define the unit cost, allocate shared costs with a written rule, and run the first monthly review with owners.
3. Month 3: pick the two largest architectural drivers and plan changes with an expected effect on unit cost.

That is why our cloud health reviews end with owners and an operating cadence, not with a list of instances.

Questions we hear