Cost per transaction on AWS: how to measure it and why it drifts

Why the total bill is the wrong number

A growing payments business should see its AWS bill grow. The useful question is whether it grows in proportion to volume, faster or slower. A total hides that answer; a unit cost exposes it.

When spend rises 40% in a year and transactions rise 25%, the platform is getting less efficient, even if nobody did anything visibly wrong. The bill looks like growth. The unit cost shows that each transaction now costs about 12% more to process.

Unit cost is also the number other people will ask for. A CFO uses it to model margins at the next volume tier. A sponsor bank or a large merchant may ask how cost behaves at peak. An acquirer's technical due diligence will try to rebuild it from your bill. It is better to have your own number, with your own definition, before someone else builds theirs.

The method below takes four steps. None of them needs a new tool: AWS billing data, a query engine and a spreadsheet are enough to start.

Step 1: define the transaction, once

Pick one unit and keep it stable. Different definitions produce very different numbers from the same bill, and a definition that changes between quarters makes the trend meaningless.

Most payments companies end up with one primary unit and one secondary unit. For example, captured payments for the margin view and authorization requests for the engineering view. Write each definition down next to the metric, with the system it is counted from, so that the number means the same thing in a year.

Step 2: separate the transaction path from everything else

Not every dollar of AWS spend serves transactions. Analytics, development environments and back-office tools are real costs, but they do not scale with volume in the same way. Mixing them in makes the unit cost noisy and hard to act on.

Accounts give the cleanest boundary because nothing can be untagged inside them. Tags give finer detail within an account. In practice you need both: accounts per environment and per major workload, and a small set of mandatory tags such as workload, component and owner.

Two practical details matter here. First, a tag only appears in billing data after it has been activated as a cost allocation tag in the Billing console, so activate the tags early. Second, an untagged resource is a cost nobody owns. Track the share of spend that is untagged and treat it as a number to drive down, not a footnote.

For containers, enable split cost allocation data for Amazon ECS or Amazon EKS. It breaks shared cluster cost down to the task or pod, so a cluster that runs both payment services and reporting jobs can be divided correctly.

The billing source is the AWS Cost and Usage Report, delivered as a Data Export to Amazon S3 and queried with Amazon Athena. A first query only needs to group cost by month and by workload tag:

-- Monthly cost by workload tag (CUR 2.0 export queried in Athena)
SELECT date_trunc('month', line_item_usage_start_date) AS month,
       coalesce(resource_tags['user_workload'], 'untagged') AS workload,
       round(sum(line_item_unblended_cost), 2) AS cost_usd
FROM   cur2
WHERE  line_item_line_item_type NOT IN ('Tax', 'Credit', 'Refund')
GROUP  BY 1, 2
ORDER  BY 1, 3 DESC;

Unblended cost is fine for a first look. For the real metric, switch to amortized cost, which spreads upfront Savings Plan and Reserved Instance payments across the months they cover. The AWS CUR Query Library has a ready-made amortized cost expression. Credits are excluded on purpose: a one-off credit makes a month look efficient when nothing changed.

Step 3: allocate shared costs with an explicit rule

Networking, observability, security tooling, data transfer and support are shared by every workload. They still belong in the unit cost, because the transaction path could not run without them. What matters is that the allocation rule is written down and applied the same way every month.

AWS Cost Categories can apply these rules for you. A cost category groups accounts and tags into business-level buckets, and its split charge rules can distribute a shared bucket proportionally, evenly or by fixed percentages. The result appears in Cost Explorer and in the Cost and Usage Report, so finance and engineering see the same allocation.

A simple rule applied consistently beats a precise rule nobody trusts. Start with proportional allocation, move the two or three largest shared items to usage-based rules once you can measure their drivers, and record every change to the rules with its date.

Step 4: measure it monthly against volume

The metric itself is simple:

Cost per 1,000 transactions = transaction-path AWS cost (amortized, incl. allocated shared cost) ÷ transactions × 1,000

Per 1,000 rather than per transaction keeps the number readable: $4.25 per 1,000 is easier to discuss than $0.00425 per transaction.

Plot it monthly next to volume. Flat or falling unit cost while volume grows is the healthy pattern. Rising unit cost is a signal to look at architecture, not only at discounts. Three habits make the trend reliable:

• Use the same month boundaries for cost and volume. Billing data is in UTC; make sure the transaction count is too.
• Keep a rolling three-month average beside the monthly value. Month-end batches, holidays and a single incident can move one month a lot.
• Split fixed and variable cost once a quarter. Plot monthly cost against monthly volume. The point where the line meets zero volume is your fixed cost; the slope is the cost of each additional 1,000 transactions. A high fixed share means unit cost will fall naturally with growth. A steep slope means each new customer costs almost as much as the last.

A worked example

Take a payments platform processing 12 million captured payments a month, with an AWS bill of $85,000 a month. These are the default values in our cost per transaction calculator, so you can follow along and then replace them with your own.

Volume grows 25% but spend grows 40%, so each payment costs 12% more to process a year from now. At 15 million payments a month, that difference is about $7,650 a month, or roughly $92,000 a year, compared with holding unit cost flat at $4.25.

The finding is not "spend less". It is "find out why each payment got more expensive". The next section lists the usual reasons.

Why unit cost drifts upward

In our experience the same few causes explain most of the drift. Each one leaves a recognizable trace in the billing data.

Discount instruments such as Savings Plans and Reserved Instances recover part of the cost once. They are worth having for the stable base. But they lower the level of the line, not its slope. Sustained improvement comes from architecture: workloads sized for their real pattern, fewer copies of data, and owners who see their unit cost every month.

Running the monthly review

The metric only changes behavior if someone looks at it on a fixed date and acts on it. A 30-minute review in the first week of each month is enough:

1. Refresh the numbers. Last month's cost by workload and component, the transaction count, the unit cost and the three-month average.
2. Compare against the target. Agree a target for the year, for example "flat or falling cost per 1,000 payments while volume grows 25%".
3. Look at the three biggest movers. The components whose cost per 1,000 rose most since last month, with their owners in the room.
4. Agree one or two actions. Each with an owner, an expected effect on unit cost and a date.
5. Check last month's actions. Did the unit cost move as expected? If not, why not?

Keep the output in one place, such as a shared page with the chart and a short action log. Over a year it becomes the history a CFO, a board or an acquirer will ask to see.

What good looks like

Most teams move through three stages. You do not need the third to get value from the first.

The FinOps Foundation describes the same idea as unit economics: connecting cloud spend to the business value it produces. For a payments company, the transaction is the natural unit to start with.

Questions we hear