To document cost decisions is to record them so that someone months later understands what was decided, why, with which expected effect and on which data, and so that the decision can be linked to the cost data and to the provider's audit log. Many lines of a cloud invoice go back to decisions made long ago: a commitment with a three-year term, an exception to the cost policy, an architecture with heavy data transfer. Without a record, the next variance reopens the same question, or someone reverses a decision whose reason nobody remembers.
How it works
The proven format is the architecture decision record (ADR). In AWS's Prescriptive Guidance, an ADR covers one decision: the situation that led to it, what was chosen and what follows from it. Each record carries a status, and all records together make up the decision log. Once accepted, a record stays as written; a changed decision gets a record of its own that replaces the earlier one, which remains in the log marked superseded. As a central place for the records AWS names a Git repository, which helps with versioning, or a wiki. Microsoft's Well-Architected Framework also treats the log as append-only and adds the options ruled out, the important trade-offs and how confident the team was in the decision; the log belongs with the workload's documentation, which Microsoft wants used as the common reference for audits and incident response as well. The ADR organisation on GitHub notes that the format also serves design and other decisions, not only architecture. Among the risk categories of its Governance, Policy & Risk capability (CC BY 4.0), the FinOps Foundation names Decision Transparency Risk: leadership deciding without seeing what has been planned, spent or committed.
What a cost decision record contains
A record for a cost decision is an ADR with a few more required fields:
| Field | Content | Purpose |
|---|---|---|
| Date and status | proposed, accepted, superseded, with dates | match a cost movement to the day of the decision |
| Decision and alternatives | what was chosen, what was ruled out, how certain the assumptions are | tell whether the reasons still hold |
| Scope | account, subscription, project, tag value or rule | filter the report to exactly that afterwards |
| Expected effect | amount or unit cost per month, cost basis, from when it shows | prove the effect later |
| Data used | report or saved view, data cut-off, prices with their date | reproduce the calculation of the day |
| Accountable | the cost owner and whoever approved | know whom to ask |
| Review date | when the effect or the decision is checked again | not let renewals and exceptions lapse |
| Evidence | event IDs from the audit log, order or ticket number | link the decision to its execution |
Saved views are covered in cost reports and saved views; how an expected effect becomes a proven one is in from estimated to realised savings.
Commitments and exceptions
Two kinds of decision need the record most, because they end on a date. A commitment binds for years; its record states the term, payment option, scope, the expected coverage and the date on which renewal or expiry is decided (exchange, cancellation and expiry of commitments). An exception to the policy names the resource, the reason, the owner and an end date; how Azure Policy models exemptions with an expiry date is covered in cost governance policy: content and enforcement. In both cases the end date is also the review date.
Linking to the audit log
The record says why something was decided; the provider's audit log shows who executed what and when.
| Provider | What is recorded | By default | For longer |
|---|---|---|---|
| AWS | CloudTrail captures all Savings Plans API calls, all EC2 API calls including the purchase of Reserved Instances, and actions in Billing and Cost Management, each with identity, time and source IP. | event history of the last 90 days per Region, immutable | a trail into an S3 bucket; CloudTrail Lake has been closed to new customers since 31 May 2026 |
| Azure | The activity log records management operations on resources, such as creating a VM. Reservation purchases and refunds appear under reservation transactions at billing scope and in an API; an exchange shows as a refund and a purchase. | 90 days | a diagnostic setting, for example into a Log Analytics workspace with up to twelve years of retention |
| Google Cloud | Admin Activity audit logs record, for example, the creation of resource-based commitments in Compute Engine and changes to the billing account; for entries at billing account level, Google's audit log overview names only the gcloud CLI and the Logging API. | 400 days in the project's _Required bucket, not configurable | a sink into a log bucket of your own with up to 3,650 days |
Microsoft points out that only the activity log records who created a resource, and names this as one of the most common reasons to keep it longer. In the other direction, a tag carrying the decision's identifier ties a cost line to the record; AWS advises against putting sensitive information in tags, and an identifier is enough.
Retention
The decision log itself is best kept versioned in the repository and never deleted. For audit logs and purchase evidence, the providers' default periods of 90 to 400 days do not reach far. Statutory record-keeping periods come from the law, not from the provider (history of billing data); whether a decision record, a purchase confirmation or a log entry falls under them is a question for your tax adviser or auditor.
What it means for your cost
A decision with an expected effect and a review date gets checked; one without either gets forgotten. Commitments then expire or renew without anyone reassessing their utilisation, and exceptions outlive their reason. When a variance appears, the record leads quickly to the cause, because date and scope narrow the search; change management for cloud cost covers how such a change is handled before that. Whatever stands out without a record is found by anomaly detection, but then without a reason.
Where it goes wrong
- No expected effect. Symptom: nobody can say whether a decision worked. Cause: the record names neither amount nor cost basis nor scope.
- Records overwritten. Symptom: the log now says something different from what it said at the last review. Cause: accepted records were edited instead of superseded.
- The audit log has expired. Symptom: who bought a Reserved Instance or a Savings Plan can no longer be established. Cause: no trail was set up, and CloudTrail's event history keeps only 90 days.
- Billing logs not found. Symptom: the Logs Explorer shows no changes to the billing account. Cause: those entries sit at billing account level, and Google's audit log overview names only the gcloud CLI and the Logging API for reading them.
- An exception without an end. Symptom: an exception still applies years after its occasion. Cause: no end date and no review date in the record.
- Figures no longer match. Symptom: the amounts in the record differ from today's report. Cause: cost basis and data cut-off are missing, and the provider has restated the data since.
Sources
Read on 2026-10-16. FinOps Foundation Governance, Policy & Risk (CC BY 4.0); AWS using architectural decision records, the ADR process, best practices for ADRs, CloudTrail event history, CloudTrail Lake, logging Savings Plans API calls with CloudTrail, logging EC2 API calls with CloudTrail, PurchaseReservedInstancesOffering, logging Billing and Cost Management API calls with CloudTrail and cost allocation tags; Microsoft maintain an architecture decision record, activity log in Azure Monitor and view reservation purchase and refund transactions; Google Cloud Cloud Audit Logs, Cloud Billing audit logging, Compute Engine audit logging and logs retention periods; ADR organisation adr.github.io.