Cost visibility
You cannot optimise what you cannot attribute. Cost visibility is the prerequisite for every FinOps conversation — right-sizing, commitment planning, and the decision about whether an architecture is worth its bill.
Why it is a delivery concern
Cost is an architectural property. Instance sizing, data transfer paths, storage class, retention and idle capacity are all decided during design. A cost review after launch finds the decisions that were expensive; a cost practice during design avoids them.
Cost visibility supports four questions:
- What are we spending? By service, account, environment and tag.
- Who owns it? Chargeback or showback to the team that can change it.
- What is waste? Idle, oversized, orphaned, or retained past usefulness.
- What is the trend? Growth that will breach the budget before it does.
Data foundation
| Layer | Requirement |
|---|---|
| Cost and Usage Report | CUR 2.0 delivered through AWS Data Exports to a dedicated data collection account |
| Tagging | Project, Environment, Owner, CostCenter enforced by policy |
| Cost allocation tags | Activated in the billing console |
| Account structure | Separate accounts per environment and workload where attribution matters |
| Budgets | Budget per account and per project with alerts at 80% and 100% |
Dashboards
Cloud Intelligence Dashboards provide three views from the same CUR data:
| Dashboard | Audience | Answers |
|---|---|---|
| CUDOS | Engineering and finance | Service-by-service spend, usage, savings opportunities, optimisation recommendations |
| Cost Intelligence | Executives and finance | High-level spend, chargeback, trend against forecast |
| KPI Dashboard | Platform and FinOps | Coverage of Savings Plans and Reserved Instances, Graviton and Spot adoption, storage tiering |
Deployment shape
Management / Payer account
└── CUR 2.0 export ──────────────┐
▼
Data collection account
├── S3 (CUR data)
├── Glue (catalogue)
├── Athena (queries)
└── QuickSight (dashboards)
The data collection account is separate from the payer account so that the people who need to query cost data do not need access to billing.
Attributing cost
Tagging
| Tag | Purpose | Enforcement |
|---|---|---|
Project | Workload identity | SCP denies creation without it on billable resources |
Environment | dev / stage / prod | SCP |
Owner | Accountable team | Config rule |
CostCenter | Finance allocation | Config rule |
DataClassification | Informs retention cost | Config rule |
Untagged spend is reported weekly and assigned to the platform team until the owner is identified. That creates pressure to tag rather than pressure to explain.
Shared cost
Cost that cannot be attributed directly — network egress, shared services, support — is allocated by a documented rule:
| Cost | Allocation rule |
|---|---|
| Support | Proportionally by account spend |
| Shared network | Proportionally by data transfer |
| Shared platform services | Evenly across workloads, or by a stated weighting |
| Unallocated | Held centrally and reported, not hidden |
Waste review
Run monthly. The categories are consistent across estates:
| Waste type | Detection | Typical fix |
|---|---|---|
| Idle instances | CPU < 5% for 14 days | Stop, terminate or downsize |
| Oversized instances | p95 CPU < 30%, memory headroom large | Right-size; test under load |
| Orphaned volumes | EBS not attached | Snapshot then delete |
| Old snapshots | Beyond retention policy | Lifecycle policy |
| Unattached elastic IPs | Not associated | Release |
| Idle load balancers | Zero requests | Remove |
| Oversized logs | High ingest, low query use | Retention and filtering |
| NAT gateway egress | High data processing | VPC endpoints, same-region paths |
| Non-production running 24×7 | No schedule | Schedule shutdown outside working hours |
| Storage class | Standard on cold data | Lifecycle to infrequent access or Glacier |
Commitment planning
| Instrument | Best for | Risk |
|---|---|---|
| Savings Plans (compute) | Steady-state compute across instance families | Commits to spend, not to a specific instance type |
| Reserved Instances | Stable RDS and specific instance needs | Less flexible than Savings Plans |
| Spot | Interruption-tolerant batch and CI | Capacity can disappear with two minutes' notice |
| Graviton | Anything that is not architecture-specific | Requires an arm64 build |
Commitments are made against a measured baseline with headroom, not against a forecast alone. An over-committed estate locks in the cost of an architecture that may change.
Budgets and anomaly detection
- A budget per account, with alerts at 80% and 100% of the monthly forecast.
- AWS Cost Anomaly Detection on each service that has variable spend.
- A weekly cost review in the delivery cadence for active engagements.
- A monthly report to the customer with spend, trend, waste actions and forecast.
Evidence
- CUR export configuration.
- Dashboard screenshots by audience.
- Cost allocation tag activation.
- Budget and anomaly alert configuration.
- A waste review with actions and owners.
- A TCO model for the workload, if one was produced.