The infrastructure cost allocation decision record: why the tagging taxonomy you chose determines your cost visibility surface and your shared resource attribution failure

A 42-person SaaS company set up their AWS organization in the year they reached product-market fit. The infrastructure team was three engineers, the deployment model was a handful of ECS services and an RDS cluster, and the cost structure was simple enough that the monthly AWS bill was self-explanatory. The tagging standard they adopted reflected that simplicity: tag every resource with service=<service-name>. The service tag was sufficient for filtering Cost Explorer reports by workload, and the team had no need for team-level or cost-center-level attribution because the entire engineering org was one team with one budget. The decision to use service-level tagging was not documented anywhere — it was a pragmatic choice made during the initial Terraform setup, visible only in the resource configurations that set the service tag on every resource.

Eighteen months later, the company had grown to 42 engineers organized into six product teams and a shared platform team. The engineering org had gone through two reorgs. Three acquisitions had added services with entirely different tagging conventions. The monthly AWS bill had grown from $8,000 to $71,000. The CFO asked for a breakdown of AWS costs by team to inform the next round of headcount planning. The request seemed routine. The engineering leads estimated the exercise would take two to three days.

The exercise took three weeks and produced numbers nobody trusted. The service tag was present on 91% of resources, but the mapping from service names to owning teams existed only in a Notion page that had not been updated since the second reorg. Fourteen service names in the Notion page corresponded to teams that no longer existed, or had been renamed, or had absorbed other teams' responsibilities. Eleven services in the AWS account had no entry in the Notion page at all — they had been created during the reorgs by engineers who were no longer at the company. The three acquired companies' resources used different tag keys entirely: one used app, one used component, and one used no tags at all. The 9% of untagged resources included the largest EC2 instances — the ones that had been running longest and had the most historical cost data, all of which was now unattributable.

The attribution exercise ultimately required: reconstructing the service-to-team mapping from git blame on the Terraform files (which worked for 73% of services and failed for the rest where the original authors had left), assigning the remaining services by interviewing current team leads about which services their teams operated (which took five days of calendar coordination), and making judgment calls for the acquired companies' resources based on which team had access to those AWS accounts. The numbers produced were presented to the CFO with a confidence interval caveat — "approximately right, with ±15% uncertainty for the untagged and ambiguously-mapped resources" — that the CFO found insufficient for the headcount planning exercise. The CFO's response was to commission a proper tagging project before the next quarterly planning cycle. The re-tagging project took six weeks, required touching 847 resources across 12 AWS accounts, and produced a taxonomy of four required tag dimensions: service, team, environment, and cost-center. The founding session that established the original tagging standard documented nothing — it was embedded in the Terraform resource configurations as a pattern rather than a policy. It did not specify the required tag dimensions, the distinction between mandatory and optional dimensions, the enforcement mechanism that would prevent resource creation without mandatory tags, or the remediation process for legacy resources. The six-week re-tagging project was the cost of that omission, paid 18 months after the fact.

A 58-person company implemented team-level cost visibility using AWS Cost Explorer filtered by the team tag. After three months of stable tagging compliance following a re-tagging project, they had reliable data and decided to implement monthly showback reports — cost transparency reports sent to each team lead showing their team's AWS spend for the month. The intent was to build cost awareness without the organizational friction of making teams accountable for costs they didn't fully control. Showback, not chargeback: visibility without budget consequences. The implementation took two days — a Lambda function querying the Cost Explorer API, filtering by the team tag, and emailing a formatted report to each team lead at the end of each month. The founding session that decided the showback model documented "monthly showback reports by team via Cost Explorer." That documentation was accurate. What it did not document was the allocation methodology for resources that served multiple teams.

The platform team consisted of seven engineers responsible for the shared infrastructure that every other team depended on: the Kubernetes cluster where all services ran, the API gateway that routed all external traffic, the CI/CD runner pool that executed every team's pipelines, the centralized logging pipeline that collected and stored logs from all services, and the secrets management infrastructure. All of these resources were tagged team=platform, because the platform team owned and operated them. The first showback report showed the platform team's AWS spend at $52,000 for the month — a number that appeared in the same table as product team costs of $6,000 to $11,000 per team. The engineering leads reviewed the table at the monthly engineering review. The VP of Engineering noted that the platform team's cost was 4.5 times the average product team cost for a team that was slightly smaller than the average product team. The CFO, who attended the monthly engineering review, flagged the platform team's cost for follow-up.

The platform team lead spent the next two weeks preparing a cost decomposition that explained the $52,000: $18,000 for the Kubernetes cluster running 23 product services across 6 product teams, $12,000 for the CI runner pool executing 340 pipeline runs per day across all teams, $9,000 for the logging pipeline ingesting logs from every service, $7,000 for the API gateway processing 2.1 million requests per day on behalf of the six product services that faced external traffic, and $6,000 for everything else the platform team owned directly. The cost decomposition was accurate. It also demonstrated that $46,000 of the platform team's $52,000 monthly cost was infrastructure that every other team depended on — costs that were not visible in the product teams' showback reports because those teams were tagged with their respective team tags, not with team=platform. The product teams' reports showed only the costs of the specific workloads those teams owned directly, excluding the shared infrastructure those workloads ran on.

The problem was structural. The showback model tagged resources by the team that operated them, not by the teams that consumed them. Platform-operated resources were tagged team=platform regardless of which product teams depended on them. The result was a monthly report that made the platform team look expensive relative to product teams, without surfacing the platform dependency costs that explained the difference. The platform team lead spent approximately 40% of time over the following three months defending the team's costs in quarterly reviews and in ad-hoc discussions triggered by the showback reports. Two product team leads proposed moving specific shared services from platform operation to self-management — not because self-management was technically better, but because the showback reports created an incentive to not appear in the platform team's cost column. The founding session that designed the showback model documented "monthly showback reports by team via Cost Explorer." It did not specify the allocation methodology for shared infrastructure — whether shared costs would be attributed to the platform team, distributed to consuming teams by a usage metric, or excluded from team-level reports as an unallocated organizational overhead. The absence of that specification produced a cost model that created organizational friction, misaligned incentives, and a recurring quarterly defense exercise instead of the cost awareness the showback model was intended to build.

A 75-person company migrated from showback to chargeback two years after implementing team-level cost visibility. The motivation was sound: showback had built cost awareness, but teams had no financial incentive to right-size workloads or challenge their infrastructure assumptions, because the costs appeared in a report but did not affect any budget they were responsible for. Chargeback changed that — each team's infrastructure spend would be deducted from their team budget quarterly, and teams that exceeded their infrastructure budget would need to request additional funding through the standard out-of-cycle budget process. The migration was straightforward to implement: the Cost Explorer tags were already in place, and the finance team needed only to add an infrastructure cost line item to each team's quarterly budget and a process for deducting the actual spend at the end of each quarter. The founding session that designed the chargeback model documented "chargeback model where teams own their quarterly infrastructure budgets." That documentation was accurate. What it did not document was the budget structure for teams whose infrastructure costs were inherently bursty rather than steady-state.

The ML platform team ran the model training infrastructure for the company's recommendation system. Most of their monthly spend was predictable: SageMaker endpoint costs for hosting the production models, S3 storage for training data and model artifacts, and a small amount of SageMaker processing for the weekly incremental retraining jobs. The quarterly budget was set at $11,000 per month — comfortably above the historical steady-state spend of $8,500 per month, with a margin for growth. Six months into the chargeback model, the recommendation team completed a major algorithm redesign that required retraining the model from scratch on the full two-year training corpus rather than the six-month rolling window used for incremental retraining. The full retraining job required 22 days of continuous compute on a SageMaker training cluster at a cost of $1,870 per day. Total cost: $41,140 for a single job.

No one had modeled the cost of the full retrain before starting it. The ML platform team lead knew the job would be expensive — more expensive than a normal month — but had no process for estimating the cost before execution or for seeking pre-approval for a workload that would exceed the team's budget. The job ran for 22 days. The chargeback system deducted $41,140 from the ML platform team's Q3 infrastructure budget. The team's monthly budget of $11,000 was consumed in the first month of Q3 at 373% — $41,140 against an $11,000 monthly allocation, or approximately 125% of the team's entire quarterly budget allocation consumed in 22 days. The team's remaining Q3 infrastructure budget was exhausted before August.

Two model updates that the recommendation team had scheduled for Q3 required new SageMaker endpoint deployments: updating the serving infrastructure to support a new feature set, and deploying a shadow endpoint for A/B testing a new model variant. Both required ML platform team infrastructure work that would cost between $800 and $2,200 per deployment — well within the normal monthly budget, but impossible to execute in Q3 without an out-of-cycle budget request. The out-of-cycle budget request process required VP-level approval, a written justification, and a finance review cycle that took 3 to 5 weeks. The two model updates were delayed by 4 weeks each, waiting for budget approval for infrastructure spend that would have been routine in any prior quarter. The recommendation system continued running the old model during the delay. The algorithm redesign that motivated the full retrain — which the recommendation team had completed and validated — could not be deployed until the infrastructure budget was approved. The founding session that designed the chargeback model documented "chargeback model where teams own their quarterly infrastructure budgets." It did not specify the pre-approval threshold for workloads expected to exceed a budget multiple, a budget reserve pool for approved overruns, or the cost forecast requirement for large one-time jobs. The 4-week model update delay was the operational consequence of that omission — chargeback's correct incentive (cost ownership) producing a correct behavior (the team will now cost-estimate large jobs before running them) via the wrong mechanism (blocking a product delivery while the budget process ran its course).

Structural properties set by the infrastructure cost allocation decision

Three structural properties are determined when a team decides how to implement cloud infrastructure cost attribution across an engineering organization. None appear explicitly in the session that establishes the initial tagging convention, the session that designs the showback model, or the session that migrates to chargeback — they are the operational consequences of design choices made under the assumption that tagging resources, generating reports, and making teams budget-accountable together constitute a complete cost management implementation.

Property 1: The required tag taxonomy and the enforcement surface. The cost attribution system's ability to answer any question about cost ownership is exactly as complete as the tag taxonomy's completeness on every resource. A tag dimension present on 85% of resources produces cost attribution that is 15% wrong — and the missing 15% is not randomly distributed across resources. It concentrates in the resources created earliest (before the tagging standard existed), in resources created during periods of deployment pressure (where tagging was skipped to meet a deadline), in resources created by third-party integrations and autoscaling mechanisms that do not inherit tags automatically, and in resources created by teams that have since left or been reorganized. These are precisely the resources most likely to be expensive: long-running instances accumulate cost over their entire lifetime, and the resources that predate the tagging standard are often the highest-utilization ones. The tag taxonomy must therefore specify: every required dimension (service, team, environment, and cost-center at minimum — because Cost Explorer can filter by any one of these, and answering "what does our production environment cost across all teams?" requires the environment tag in addition to the team tag), the mandatory versus optional distinction for each dimension, the enforcement mechanism for each resource provisioning path (Terraform provider validation that fails the plan if any billable resource is missing a mandatory tag, AWS Config rules that flag non-compliant resources with auto-remediation that tags the resource from the creating role's context, Service Control Policies that deny resource creation API calls missing mandatory tags), and the canonical list of valid values for each dimension (because free-text tag values produce every spelling variation of every team name). The infrastructure-as-code decision record documents the Terraform provider configuration and Sentinel policy structure that makes tagging requirements a plan-time gate rather than a post-creation audit — the enforcement model that catches missing tags before the resource is created rather than discovering the gap in a quarterly cost attribution exercise. The CI/CD pipeline decision record documents the pipeline gate configuration that blocks infrastructure deployments when the tagging compliance check fails — the organizational enforcement mechanism that makes the tagging policy operational rather than advisory.

Property 2: The shared resource allocation methodology and the behavioral incentive surface. Every engineering organization with a platform team has the same structural problem: the platform team operates shared infrastructure that product teams depend on, but the cost of that infrastructure is tagged to the team that operates it, not the teams that consume it. The allocation decision — how to distribute shared infrastructure costs — determines which teams receive a cost signal for the infrastructure they consume, and therefore which teams have an incentive to reduce that consumption. Full attribution to the platform team produces no consumption incentive for product teams: product teams see only their direct workload costs in their reports, and the platform team's report shows costs that include the entire shared infrastructure regardless of which teams drove that consumption. Proportional distribution to consuming teams produces a consumption signal: a product team that increases its service's compute footprint sees a corresponding increase in its share of the Kubernetes cluster cost, creating an incentive to right-size. The allocation basis determines the incentive's accuracy: CPU seconds consumed creates an incentive to reduce compute usage; request volume creates an incentive to reduce call frequency; flat per-team shares create no reduction incentive but simplify the calculation. The allocation methodology must be specified, documented, and agreed to by all consuming team leads before chargeback goes live — because changing the allocation methodology after chargeback starts disrupts budget planning for every team simultaneously. The allocation methodology must also specify the review cadence: team composition changes (a new team formed from a split, two teams merged) and major consumption pattern changes (a product team migrates a workload off the shared cluster) require updating the allocation formula, and the decision record must specify who triggers the review and when. The platform engineering decision record documents the platform team's service ownership model and the service catalog structure — the artifact that makes shared infrastructure dependencies explicit and provides the consumption data needed to calculate proportional allocation. The container orchestration decision record documents the Kubernetes resource request and limit configuration that makes per-team CPU and memory consumption measurable at the namespace level — the instrumentation prerequisite for CPU-based allocation without requiring additional telemetry from consuming teams.

Property 3: The budget structure and the bursty workload reconciliation surface. A chargeback model maps infrastructure costs to team budgets. The mapping works correctly for teams with predictable, steady-state consumption profiles: a team whose monthly infrastructure spend varies by less than 20% from month to month can be given a budget with a reasonable margin, and the chargeback deduction at the end of each quarter will fall within the budget without surprises. The mapping breaks for teams whose workloads are inherently bursty: ML teams running model training jobs that consume 300% of the monthly budget in 3 weeks, data engineering teams running quarterly backfill jobs that process years of historical data, platform teams running one-time database migration jobs that transfer terabytes across regions. For these teams, the correct budget structure is not a higher steady-state budget (which would be permanently over-allocated 11 months of the year to absorb 1 month of burst), but a structured exception process. The exception process requires three components: a pre-approval threshold (any single workload forecasted to cost more than a defined percentage of the team's monthly budget requires a cost estimate and explicit approval before execution — the threshold must be low enough to catch the genuinely expensive jobs but high enough to not require approval for every incremental experiment), a budget reserve pool at the organizational level that covers approved overruns without triggering the out-of-cycle budget process (the reserve is sized at 10-15% of the total infrastructure budget and replenished monthly, making the approval process fast because the funding source is pre-approved), and a cost forecast format that makes the pre-approval actionable (the team submits the job type, service tier, expected duration, expected data volume, and a worst-case estimate at 1.5x the nominal figure — the reviewer approves the worst-case figure, and the reserve is debited by the actual spend up to that ceiling). The capacity planning decision record documents the workload sizing methodology that makes cost forecasting tractable before a job runs — the cloud provider pricing calculator inputs that translate job parameters (instance type, duration, data volume) into a cost estimate with a confidence interval. The data pipeline decision record documents the batch job cost patterns specific to data engineering workloads — the Spark executor configuration, the EMR cluster sizing, and the data scan cost structures that make data engineering the team most likely to produce the first chargeback overrun in any engineering organization that migrates from showback to chargeback. The ML model serving decision record documents the SageMaker training and inference cost structures, the training-to-serving cost ratio for different model architectures, and the full-retrain versus incremental-retrain cost differential — the cost model that the ML platform team needs to produce an accurate pre-approval estimate for a training run.

What the founding session records and what it omits

The founding infrastructure cost allocation session typically records the cloud provider selected, the initial tagging standard adopted (usually a service tag and an environment tag), the billing account structure (single account versus multi-account organization), and the cost reporting tool chosen (AWS Cost Explorer, Google Cloud Billing, Azure Cost Management, or a third-party tool such as CloudHealth or Apptio Cloudability). It may record the rationale for a single-account versus multi-account structure — the tradeoffs between blast radius isolation and cross-account cost attribution complexity. What it does not record is the required tag taxonomy beyond the tags already in use: the team and cost-center dimensions that are not needed when the engineering org is one team but become essential when the org grows to six teams across two product lines and a platform function. It does not record the enforcement mechanism: whether the tagging standard is enforced at resource creation time by policy or audited after creation by a compliance report, and what happens to resources that fail the compliance check. It does not record the allocation methodology for shared resources: whether the cost of a shared Kubernetes cluster is attributed to the platform team that operates it, distributed to the product teams that run workloads on it, or split between platform and product using a formula that accounts for both the fixed overhead cost and the variable consumption cost.

The tag taxonomy omission produces a failure that compounds with organizational growth. When the engineering org is small, the gap between the tagging standard and the reporting need is invisible — a single team with a single budget has no need for team-level attribution. The gap becomes visible only when the organization grows to a size where team-level cost attribution is needed for headcount planning, budget setting, or performance reviews — at which point the legacy resources that predate the expanded tagging standard have accumulated significant cost history that is now unattributable. The re-tagging project required to close the gap is proportional to the number of resources created during the period of incomplete tagging, and the cost history during that period is permanently unrecoverable: Cost Explorer can show current tags but not historical tags, so any resource re-tagged after the fact loses the ability to attribute its historical cost to the new tag value. The correct time to specify the complete required tag taxonomy is at the first infrastructure session — not when the organization grows to need it, because by that point the cost of the remediation project grows with the resource count that has accumulated. The observability strategy decision record documents the unit economics instrumentation that makes the cost-to-output relationship visible — the denominator metrics (API requests per second, active users, models trained per month) that convert raw AWS cost into cost-per-unit-of-output and enable the cost-reduction conversations that chargeback is supposed to motivate. Without unit economics tracking, cost visibility produces the question "why does the platform team cost $52,000?" but not the answer "the platform team costs $0.025 per API request processed, down from $0.031 three months ago." The second framing is the one that makes cost management a performance conversation rather than a budget defense exercise.

The shared resource allocation omission produces a failure that is specific to organizations with a platform team or shared service layer — which is to say, most engineering organizations at or above 20 people. The failure has two dimensions: an information dimension (product teams cannot see the full cost of the infrastructure they depend on, making it impossible for them to reason about cost-performance tradeoffs for decisions they make) and an incentive dimension (product teams have no financial signal from the shared infrastructure they consume, so they have no reason to right-size or challenge their assumptions about shared resource usage). The information failure is correctible by distributing shared costs in the showback report — a product team's showback report that includes their proportional share of the shared Kubernetes cluster cost is more complete than one that does not, even if the product team has no direct control over that cost. The incentive failure requires chargeback rather than showback to correct: a product team that pays for its share of the Kubernetes cluster through its budget has an incentive to understand what drives its share and how to reduce it. The founding session that designs the showback model typically focuses on the implementation mechanics — how to filter Cost Explorer by the team tag, how to schedule the report delivery — without working through the allocation question for shared resources, because the question is only visible once the showback reports are live and someone notices that the platform team's report looks expensive relative to product teams. Specifying the allocation methodology before the first report goes out avoids the organizational friction that results from retroactively changing the attribution model after team leads have already anchored to the initial numbers. The multi-region deployment decision record documents the cost attribution complexity specific to multi-region infrastructure — where shared services run in multiple regions and their cost must be allocated across consuming teams by region of consumption rather than just by team, adding a dimension to the allocation problem that significantly increases the complexity of any proportional distribution formula.

The bursty workload budget omission produces a failure that is specific to the first large one-time job that runs after chargeback goes live. Every engineering organization has teams with bursty cost profiles: the data engineering team has quarterly backfill runs, the ML team has full model retrains, the platform team has one-time migration jobs. The chargeback model that works for steady-state teams fails for these teams because the budget-setting process implicitly assumes that monthly cost will be roughly constant across the quarter. When a single job consumes 100%+ of the monthly budget, the budget structure has no mechanism to accommodate it without blocking execution or triggering an out-of-cycle approval process. The out-of-cycle approval process is the correct outcome — spending 380% of a monthly budget on a single job should require approval — but the process must be designed before the first overrun occurs. A process designed in response to an overrun tends to be retroactive (approving spend that has already happened), slow (because the approvers have no prior context for the request), and organizationally disruptive (because the team whose budget is overrun is also the team blocked from doing other work while the approval is pending). The multi-cloud strategy decision record documents the cost attribution complexity that arises when bursty workloads span cloud providers — a training run on AWS and a serving deployment on GCP require coordinated cost tracking across two billing systems, and the pre-approval process must include estimates from both providers to produce an accurate total cost picture.

The WhyChose decision extractor finds the founding cost allocation sessions in your ChatGPT and Claude export — the "how should we tag our AWS resources?" infrastructure setup session, the "let's implement cost reporting by team" showback design session, the "we're moving to chargeback this quarter" budget accountability session, the "what do we do about the platform team's cost report?" quarterly review follow-up session. It extracts the attribution model selected and the options considered, the tag taxonomy specified and the enforcement mechanism documented, and the allocation methodology for shared resources — and surfaces the specifications the session documented versus the ones it omitted. The database sharding decision record documents the per-shard cost attribution challenge specific to sharded databases — where compute and storage costs must be attributed to the tenants or workloads assigned to each shard, adding a third attribution dimension (tenant) on top of the team and environment dimensions, and making the tag taxonomy specification a prerequisite for the sharding cost model rather than a downstream concern.

The five ADR sections for an infrastructure cost allocation decision

Section 1: Cost attribution model selection. Specify the attribution model chosen (showback, chargeback, or unallocated overhead), the granularity of attribution (team, cost-center, product line, or individual service), and the reporting cadence (monthly, quarterly, or real-time dashboard). Document the rationale for the chosen model and the organization's current readiness for each alternative: showback requires only consistent tagging and a report delivery mechanism; chargeback additionally requires team-level budget line items in the finance system and a budget reconciliation process that integrates with the quarterly budget cycle; unallocated overhead is appropriate only for organizations where cost differences between teams are not meaningful for budget planning or performance management. Specify the transition plan if the chosen model is expected to evolve — showback is commonly used for 6-12 months before transitioning to chargeback to build cost awareness before adding accountability, and the decision record must specify the criteria that trigger the transition (target tagging compliance rate, target team budget maturity, target quarterly budget cycle integration) rather than leaving the transition as an open-ended future decision. Specify what the model excludes: which costs are not allocated to teams (third-party SaaS subscriptions purchased at the organizational level, enterprise support contracts, reserved instance or committed use discount line items that benefit multiple teams) and how those are handled in the organizational budget. The observability strategy decision record documents the unit economics tracking that converts raw cost into cost-per-unit-of-output — the instrumentation that makes cost attribution useful for decision-making rather than just accounting, and the metric format that makes a cost reduction visible as a performance improvement rather than just a budget number decreasing.

Section 2: Required tag taxonomy and enforcement mechanism. Specify every required tag dimension (at minimum: service, team, environment, cost-center), the mandatory versus optional designation for each dimension, the canonical list of valid values for each dimension, and the process for adding new valid values as the organization grows. Specify the enforcement mechanism for each resource provisioning path: for Terraform-managed resources, a Terraform provider validation or a Sentinel policy that fails the plan if any billable resource is missing a mandatory tag; for AWS native resource creation (console, CLI, SDK calls from application code), an AWS Service Control Policy that denies CreateInstance, RunInstances, CreateBucket, and equivalent calls if the mandatory tags are absent from the request; for resources created by autoscaling groups, CDK constructs, or third-party integrations, an AWS Config rule with auto-remediation that tags the resource immediately after creation using the creating role's context to determine the team and service attribution. Specify the compliance reporting cadence and the remediation SLA: resources identified as non-compliant by the Config rules must be remediated or explicitly excluded (with documented justification) within a specified number of business days. Specify the legacy resource remediation process: for resources that predate the mandatory tag policy and cannot be reliably attributed, the process for assigning a best-effort tag based on access logs, Terraform state history, and team lead confirmation — with a documented uncertainty flag for resources whose attribution is assigned rather than verified. The infrastructure-as-code decision record documents the Terraform module structure and provider configuration that makes mandatory tag validation part of every resource module's interface rather than a post-creation audit, ensuring that new resources are always created with complete tags regardless of which team's engineer writes the Terraform.

Section 3: Shared resource allocation methodology. For each shared service or infrastructure component operated by the platform team (or equivalent), specify the allocation method: full attribution to the operating team, proportional distribution to consuming teams, hybrid (fixed base to operating team, variable component to consuming teams), or exclusion from team-level reports as organizational overhead. For each component where proportional distribution is chosen, specify the allocation metric: CPU seconds consumed (for compute-intensive workloads like Kubernetes nodes), request volume (for gateway and load balancer costs), data egress bytes (for CDN and transfer costs), or active-user count (for services where cost scales with user count rather than request volume). Specify the measurement mechanism for the allocation metric: namespace-level resource metrics from Kubernetes for CPU and memory, access log volume counts for request-based allocation, or billing-tagged sub-resource attribution where the cloud provider supports it. Specify the allocation review cadence and the change triggers: team composition changes of greater than one team (merger or split), consumption pattern changes greater than 30% month-over-month for any consuming team, or addition of a new shared service to the allocation model. Specify the transition process for changing the allocation methodology: a 90-day notice period before any change to the allocation formula takes effect, with the new allocation run in parallel for two months before the old allocation is retired, so that consuming team leads can see the impact before it affects their budget. The platform engineering decision record documents the service catalog structure that makes shared infrastructure dependencies visible — the consumption data source that enables proportional allocation calculations and the service dependency graph that identifies which teams consume which shared services.

Section 4: Budget structure for bursty workloads and the pre-approval threshold. Specify the pre-approval threshold: the forecasted cost above which a single workload requires a cost estimate and explicit approval before execution. Express the threshold as a percentage of the team's monthly infrastructure budget (commonly 50%) and as an absolute dollar floor (commonly $5,000) — whichever is lower triggers the pre-approval requirement. Specify the cost estimate format required for pre-approval submissions: workload type, cloud service tier, expected duration in hours, expected data volume processed in terabytes, nominal cost estimate, and a worst-case estimate at 1.5x the nominal figure with the assumptions behind the multiplier documented. Specify the approval process: the designated approver for estimates under the organizational reserve threshold (commonly the engineering director for the submitting team's org), the approval timeline SLA (24 hours for standard approval, 4 hours for an expedited approval needed for time-sensitive jobs), and the escalation path when the designated approver is unavailable. Specify the organizational budget reserve pool: the pool size (10-15% of the total infrastructure budget), the replenishment schedule (monthly, from the infrastructure budget line item), the eligibility criteria (the reserve covers only workloads that have received pre-approval — steady-state overruns are not eligible), and the reserve depletion process (when the reserve falls below 25% of its target size, the approval threshold drops to 25% of monthly budget and the approver escalates to VP level until the reserve is replenished). Specify the post-job cost reconciliation: within two weeks of completing a pre-approved job, the team submits the actual cost against the approved estimate, and any variance greater than 20% of the approved estimate triggers a retrospective on the estimation methodology. The capacity planning decision record documents the cloud provider pricing calculator methodology for translating job parameters into cost estimates with the confidence interval that the pre-approval process requires — the input format (instance type, count, duration) that produces an estimate comparable to the actual Cost Explorer output.

Section 5: Cost anomaly detection, alerting, and unit economics tracking. Specify the anomaly detection configuration: the percentage change in daily cost that triggers an alert (commonly 50% day-over-day increase or 3 standard deviations above the 30-day rolling mean), the team that receives the alert (the team tagged in the anomalous resource, plus the FinOps function if one exists), and the response SLA (the tagged team must confirm whether the anomaly is expected within 4 business hours of the alert, and must submit a root cause explanation within 24 hours if the anomaly was not expected). Specify the forecasting cadence: the cloud provider's cost forecast tool is run at the beginning of each month to produce a monthly spend projection by team, and each team lead receives the forecast alongside their prior-month actuals — enabling the team lead to flag workloads scheduled for the current month that will materially exceed the forecast before they execute rather than after. Specify the unit economics metrics that supplement raw cost reporting: cost per active user (total infrastructure cost divided by monthly active users, trended weekly), cost per request (API infrastructure cost divided by request volume, trended weekly), and cost per unit of output for teams with a primary output metric (cost per model trained for ML teams, cost per pipeline run for data engineering teams, cost per deployment for CI teams). Unit economics metrics convert cost reduction into a performance conversation — a team that reduces its cost-per-request by 15% has improved operational efficiency, while a team that reduces its absolute cost by 15% may have simply shed traffic. Specify the annual cost review process: the cost allocation model, tag taxonomy, and shared resource allocation methodology are reviewed annually with all team leads, and the decision record is updated to reflect any changes agreed upon — because organizational structure, team composition, and consumption patterns change materially over 12 months, and a cost model that was agreed to 18 months ago may be allocating costs in ways that no longer reflect actual dependencies. The multi-cloud strategy decision record documents the cross-provider cost aggregation required when anomaly detection must span multiple billing systems — the normalization format that makes AWS Cost Explorer output and GCP Billing export comparable in a unified cost dashboard.