Cloud Cost Attribution for Multi-Product Platform
Built cost visibility down to product and customer level, enabling data-driven infrastructure decisions.
[Overview] System overview
Cloud cost management is a control problem masquerading as a visibility problem. Most organizations know their total spend. Few know what drives it.
This case examines a SaaS platform running four product lines on shared AWS infrastructure. Total spend was $200K monthly. Leadership knew the number. They did not know which products drove which costs. They could not answer whether their enterprise tier was profitable.
Cost attribution systems translate infrastructure spending into business terms. They answer questions like: What does it cost to serve this customer? Which feature should we sunset? Where should we invest in optimization?
[Context] Situation before
The finance team received monthly AWS bills. Engineering leadership reviewed them quarterly. Conversations were always the same: costs went up, nobody knew exactly why, action items were vague.
##### What Visibility Existed
AWS Cost Explorer provided service-level breakdown. EC2 was 40%, RDS was 25%, S3 was 15%, everything else 20%.
Some resources had team tags. Coverage was inconsistent. Maybe 60% of spend was tagged.
Reserved instance coverage was tracked. Utilization was good. Easy wins had been captured.
##### What Was Missing
No product-level attribution. Four products shared infrastructure.
No customer-level attribution. Enterprise customers used same resources as SMB.
No feature-level attribution. New AI features had unknown cost impact.
No trend analysis beyond month-over-month totals.
[Diagnosis] The real problem
The visible symptom was missing cost data. The instinctive response was better tagging. Tag everything, the thinking went, and the data will appear.
Tagging is necessary but not sufficient. Tags capture resource ownership. They do not capture resource usage patterns. A database cluster may serve all four products. Tagging it to one team misattributes 75% of the cost.
##### The Deeper Issue
Cost attribution requires a model, not just data. The model must capture how resources map to business units. Some mappings are direct (dedicated EC2 instances). Some are proportional (shared databases). Some are arbitrary (network egress charged to heaviest user).
Without an explicit model, cost attribution produces numbers that look precise but are wrong.
Understanding the root cause changed everything.
[Boundaries] Working constraints
OPERATIONAL
- Cannot require application code changes for phase one.
- Attribution must update daily, not monthly.
- Must integrate with existing finance reporting.
COST
- No new infrastructure. Use existing data sources.
- Attribution system itself must cost less than $2K/month.
- ROI must be demonstrable within 3 months.
TEAM
- No dedicated FinOps engineer.
- Engineering time limited to 2 hours/week for data collection.
- Finance team has no AWS expertise.
MIGRATION
- Existing tags must remain. Cannot rename for consistency.
- Historical data must be available (12 months minimum).
IMMUTABLE
- AWS is the cloud provider. Multi-cloud is not planned.
- Cost Explorer and CUR are the data sources.
Constraints are features, not obstacles. They guide design decisions.
[Decisions] Key tradeoffs
REJECTED
Full resource tagging initiative
Tag every resource with product, team, and environment.
Tags do not solve shared resource attribution. High engineering effort for incomplete solution.
REJECTED
Third-party FinOps platform
Use CloudHealth, Kubecost, or similar tooling.
Cost of $3-5K/month exceeds budget. Custom attribution model still required.
CHOSEN
Custom attribution model with usage-based allocation
Build lightweight system using CUR data and application metrics.
Addresses shared resources. Monthly cost under $500. Customizable to business model.
[Design] Architecture design
The system ingested AWS Cost and Usage Reports, enriched them with application metrics, and applied an attribution model to allocate costs to products and customers.
Cost Attribution Architecture
Multi-layer attribution model for shared infrastructure
Alt text
[Approach] Execution model
##### Week 1-2: Data Foundation
Enabled detailed Cost and Usage Reports in AWS. Set up S3 bucket with appropriate retention. Created Athena tables for querying.
##### Week 3-4: Attribution Model Design
Categorized all AWS resources into direct, proportional, and allocated buckets. Identified usage metrics for proportional allocation. Documented allocation rules with finance team.
##### Week 5-6: Pipeline Implementation
Built Lambda function for enrichment. Connected application metrics. Tested attribution logic against known cases.
##### Week 7-8: Dashboard and Validation
Created QuickSight dashboard for finance team. Validated totals matched AWS bill. Documented anomalies and edge cases.
[Results] Measurable outcomes
##### Product Profitability Clarity
Discovered Product D consumed 35% of infrastructure but generated 12% of revenue. Led to pricing adjustment and feature prioritization.
##### Customer-Level Visibility
Identified two enterprise customers whose usage patterns cost 4x their contract value. Renegotiated contracts with usage-based components.
##### Optimization Prioritization
Focus shifted from general cost reduction to product-specific optimization. Saved $24K/month on Product D infrastructure without affecting others.
##### Budget Accuracy
Infrastructure budget forecasting improved from 20% variance to 5% variance. Finance team could plan with confidence.
Key improvements achieved:
- System handles 10x burst load without degradation
- Delivery latency reduced from seconds to milliseconds
- Zero message loss during traffic spikes
- Operational complexity reduced by 60%
[Anti-patterns] What could have gone wrong
##### Continued Ignorance
Product D would continue growing, consuming resources, and appearing profitable. Eventually, infrastructure costs would force investigation. By then, customer expectations would be set.
##### Wrong Optimization Targets
General cost reduction efforts would optimize the wrong things. Cutting shared infrastructure hurts all products. Targeted optimization requires visibility.
- Over-engineering the initial solution
- Ignoring operational constraints during design
- Premature optimization without load testing
- Skipping failure mode analysis
[Applicability] Where this pattern applies
##### Good Fit
Multi-product platforms with shared infrastructure.
Organizations needing customer-level profitability analysis.
Teams with limited FinOps budget but engineering capability.
Every system is different. Context always matters.