SAP-C03 Cost Allocation and Visibility: Tagging Enforcement, CUR 2.0, Cost Categories, Split Costs, Bedrock Chargeback, Budgets and Anomaly Detection

You design a tagging strategy for cost allocation by choosing a small set of mandatory tag keys that answer "who pays for this?" (for example CostCenter, BusinessUnit, Project, Environment, Application), fixing one spelling, case and list of allowed values for each, and then activating those keys as cost allocation tags in the organization's management (payer) account. A tag that exists on resources but has not been activated does not appear in AWS Cost Explorer, AWS Budgets filters or the Cost and Usage Report.

Activation rules

• Who activates: only the management account of an organization (or a standalone account) can activate cost allocation tags. Member accounts have no access to the cost allocation tags page, and one activation applies to every member account.
• Timing: a new tag key can take up to 24 hours to appear on the cost allocation tags page, and activation can take up to another 24 hours to take effect.
• Not retroactive by itself: activation labels cost data from the time it is activated. To label earlier months, the management account requests a backfill, which applies the current activation status to up to 12 previous months. A backfill only helps if the resources actually carried the tag during those months; it never invents tags.
• Tag keys are case-sensitive: CostCenter, costcenter and Cost-Center are three different keys and three different columns in reports. Standardization (next sections) prevents this rather than cleaning it up.

User-defined, AWS-generated and account tags

A practical strategy combines them: if accounts already map one-to-one to owners, account tags carry ownership; resource tags then split costs inside shared accounts (by application, project or environment). aws:createdBy answers "who launched this?", not "which business unit pays?", and because it is forward-only and limited to certain resource types it should be activated early and never relied on as the only allocation key.

Organizations account tags matter because they are the only tag that reaches charges which have no taggable resource. When you tag accounts in AWS Organizations (for example BusinessUnit applied by the account vending pipeline) and activate that key as a cost allocation tag, every line item of the account carries the value: all metered usage in the account, including credits, refunds and service charges that have no taggable resource. Resource-tag reports show those charges under "No tag key".

• Account tags can be used as filters and dimensions in Cost Explorer, CUR 2.0, AWS Budgets, cost categories and Cost Anomaly Detection.
• Because the pipeline already maintains them, they avoid a second account-to-owner mapping that someone must keep in sync.
• A budget filtered on an account tag value picks up new accounts automatically when the pipeline tags them, whereas a budget filtered on a list of linked accounts must be edited each time an account is added.

Account tags cannot split a shared account between owners. For that you need resource tags, split charges or split cost allocation data, covered below.

You enforce cost allocation tags with three layered controls, each of which does one job: an SCP makes a tag key mandatory when a resource is created, an Organizations tag policy defines and (optionally) enforces the key's exact spelling and allowed values and reports noncompliance, and an AWS Config required-tags rule finds existing resources that are missing the key and can remediate them. None of them alone covers all three needs.

Tag policy details that decide scenarios

• Untagged resources are not evaluated by tag policy compliance. A compliance report that looks clean can coexist with large unallocated costs from resources that have no key at all.
• enforced_for rejects tagging operations that would create a noncompliant value; it does not require the key to exist.
• The report_required_tag_for setting marks a key as required, but that requirement is enforced only through infrastructure-as-code integrations (an AWS CloudFormation hook, Terraform, Pulumi). Creates from the console or CLI are not blocked by it.

The SCP condition

To require a key at creation, the SCP denies the create action (for example ec2:RunInstances on the instance resource) with "Null": {"aws:RequestTag/CostCenter": "true"}. The keys to tell apart:

• aws:RequestTag/key is the tag sent in the request; it is the right key for creation. aws:ResourceTag/key refers to tags already on an existing resource, so a new resource has none at launch and a deny on it would block every launch.
• Null true matches when the key is absent; false matches when it is present.
• aws:TagKeys lists all keys in the request; a null check on it only catches requests with no tags at all.

The SCP checks presence; a tag policy with enforced_for then restricts the value to the approved list, so the two together make a tag both mandatory and valid. SCPs apply to every principal in the member accounts they are attached to (never the management account), which is what makes them an organization-wide guardrail rather than a per-role setting.

Cleaning up what already exists

Resources created before the controls existed are found with the Config required-tags rule (case-sensitive, so it also flags spelling variants), deployed to all member accounts with an organization conformance pack. Conformance packs and Config rules are Regional, so deploy them in every Region where workloads run. Add automatic remediation to tag with a default or looked-up value instead of asking owners by email.

AWS Cost Explorer answers interactive, aggregated questions (trend, group by account, service, tag or cost category, forecast), while the Cost and Usage Report 2.0 (CUR 2.0) answers line-item questions (which resource, which hour, which tag, which discount) over the full history you keep. Both are fed by the same billing data; they differ in granularity, retention and who can use them.

Cost Explorer limits that drive answers

• "No resource ID" when grouping by resource means resource-level daily data is not enabled for that service. It is enabled per service in Cost Management preferences in the management account, can take up to 48 hours to appear, and covers the last 14 days only.
• Multi-year data is monthly only, so it lengthens history without adding resource detail.
• A member account's own Cost Explorer shows only that account; organization-wide views come from the management account or a shared billing view (see showback below).
• For anything older than 14 days at resource level (for example tracing which resource drove last quarter's increase), query CUR 2.0 with resource IDs in Amazon Athena, grouping by line_item_resource_id.

AWS Data Exports

AWS Data Exports is how you create CUR 2.0 today. Each standard export picks a table (CUR 2.0, FOCUS, cost optimization recommendations, carbon emissions), writes recurring files (Parquet or CSV) to an S3 bucket and can be queried in place with Amazon Athena. The export definition is a basic SQL statement, so it can select only the columns you need (for example omitting columns a downstream consumer should not receive) and filter rows (for example to one business unit's accounts). Filtering in the export avoids building a Glue job to strip data afterwards; an S3 bucket policy cannot do this because it controls access to whole objects, not columns or rows. The legacy Cost and Usage Report still exists but uses the older AWS-specific schema; it is neither CUR 2.0 nor FOCUS.

Cost categories map costs to business values (business unit, team, product, environment) using rules over dimensions such as linked account, cost allocation tag, service, charge type and other cost categories. Each cost category becomes a dimension you can filter and group by in Cost Explorer, AWS Budgets, CUR 2.0 and Cost Anomaly Detection, so a business mapping defined once is reused everywhere. A cost category is a billing construct; operational groupings of resources do not by themselves create a billing dimension.

Rule mechanics

• Regular rules map listed values (account IDs, tag values, services) to a fixed cost category value.
• Inherited value rules create values dynamically from a cost allocation tag key or from the account dimension. On a tag key, every tag value becomes a cost category value, including values created later. On the account dimension, values come from account names, not from account tags.
• Rule order matters: rules are evaluated top to bottom and the first match wins. Put specific overrides (for example "everything in the shared platform account is Shared") above general rules (inherit from the team tag), or tagged resources in the override account will be captured by the general rule.
• Default value: costs that match no rule get the default value (for example Unallocated), which makes allocation gaps visible instead of silent.
• Effective date: rules can be applied from an earlier month, so a corrected mapping restates past months. Changes can take up to 24 hours to process.
• Cost categories are created and managed in the management account.

Cost categories relabel costs in reports. They do not fix the tags on resources: merging prod, Prod and PRD into one value hides the problem for reporting but neither blocks new variants nor reports which resources carry them. That is the tag policy's job.

Split charge rules allocate the cost of one cost category value (the source, such as a SharedPlatform value for central logging and security tooling accounts) to other values of the same cost category (the targets, such as the business units that use it). There are three methods:

The critical limitation: split charge results appear only on the cost category details page (and its downloadable CSV). They are not written into CUR, CUR 2.0, FOCUS exports or Cost Explorer, whatever method or effective date you choose. If a chargeback pipeline reads CUR in Athena and must match the details page, the pipeline has to apply the same allocation itself.

Tags on shared infrastructure label only the charges those resources generate; they cannot apportion a shared service's cost in line with each consumer's use. Split charges, or the equivalent allocation in your own reporting, do that.

Split cost allocation data allocates the cost of shared Amazon EC2 instances to the Amazon ECS tasks or Amazon EKS pods running on them, so teams sharing one cluster can be charged for their own containers without splitting the cluster into per-team node groups. Tagging an instance with one team cannot work when many teams' tasks share it.

• Opt in from Cost Management preferences in the management (payer) account, separately for ECS and for EKS.
• Where it appears: only in CUR and CUR 2.0 (you include split cost allocation data in the export). It is not available in Cost Explorer, so per-task or per-pod grouping is done in Athena or a BI tool over CUR.
• How costs are attributed: each instance's amortized cost is divided by the CPU and memory the containers reserve or use; capacity no container claims shows as unused instance cost. Task and pod labels such as aws:eks:namespace, cluster and deployment, plus ECS service and task tags, become columns you can group by.

EKS: requests only vs Prometheus

Accelerated (GPU) instance costs are split by resource requests. Allocation is a billing question, separate from rightsizing: making nodes smaller changes the cost to divide, not who it is charged to.

Amazon Bedrock spend is charged back by giving each team's or application's model calls a taggable identity that billing data can group by. There are two native mechanisms, and which one fits depends on whether the callers can change the model identifier they send:

Usage types alone cannot separate teams that call the same model, because every team generates the same input-token and output-token usage types. Likewise, the Bedrock runtime metrics in Amazon CloudWatch (InputTokenCount, OutputTokenCount) are dimensioned by model ID, not by caller.

Near-real-time token visibility

Billing data arrives with billing latency, which is fine for monthly chargeback but too slow to catch a runaway prompt during the day. For per-application token usage within minutes, enable Bedrock model invocation logging (disabled by default, configured per account and Region, delivered to CloudWatch Logs and/or Amazon S3). Each log record carries the caller's identity.arn, the modelId and the input and output token counts, so a CloudWatch Logs Insights query that sums tokens grouped by identity.arn shows usage per IAM role with no application change. Joining logs with prices yourself to build a bill is possible but is a custom pipeline to maintain; use the native allocation mechanisms for money and logs for operational visibility.

Showback reports each owner's costs to them for visibility; chargeback actually bills those costs to the owner's budget or cost center. Both rest on the same allocation (account tags, resource tags, cost categories, split charges, split cost allocation data); chargeback adds an agreed allocation of shared costs and usually a CUR-based pipeline that finance trusts.

The common showback problem is access: owners of many accounts want one view of their costs, but security does not allow them into the management account, and each member account's Cost Explorer shows only itself. Custom billing views solve this. A billing view is a shareable resource representing a filtered slice of cost management data, filtered by accounts or by cost allocation tags, and it can combine data from multiple organizations (for example where a group runs more than one organization). Shared with another account, the view is used directly in Cost Explorer and AWS Budgets there, with no sign-in to any management account.

AWS Budgets alerts when spend or usage crosses an amount you set; AWS Cost Anomaly Detection alerts when spend departs from the pattern it has learned for that account, service, tag or cost category. Use Budgets for known allowances and targets, and Cost Anomaly Detection for "something unusual is happening" without maintaining a fixed limit per owner.

AWS Budgets

• Budget types: cost, usage, and Savings Plans or Reserved Instance utilization (how much of the commitment is being used) and coverage (how much eligible usage the commitment covers). Utilization falling below a target is a utilization budget, not a coverage budget.
• Filters: linked account, cost allocation tag, account tag, cost category value, service and more, so one budget can follow a project, team or business unit.
• Thresholds: actual (fires once spend has crossed the threshold) or forecasted (fires when spend is on course to cross it before the period ends, which is how you warn before overspending).
• Notifications: email addresses and an Amazon SNS topic (and chat channels through SNS).
• Budget actions: automatically or after approval, apply an IAM policy, apply an SCP, or stop specific EC2 or RDS instances. Only the SCP action reaches another account, and only from a budget in the management account. EC2 and RDS targets must be in the budget's own account, and stopping instances acts on those existing instances only.

A CloudWatch billing alarm on EstimatedCharges needs a static threshold and has no tag dimension, so it cannot follow a single project or learn normal spend.

AWS Cost Anomaly Detection

• Use an AWS managed monitor for breadth with one threshold, and add customer managed monitors only for exceptions that need a different threshold. A monitor per value has to be edited every time a team appears.
• Alert subscriptions: individual alerts are sent as soon as an anomaly is detected and require an SNS topic (relay to Slack or Microsoft Teams with Amazon Q Developer in chat applications); daily or weekly summaries go by email and arrive after the period.
• Thresholds are on the anomaly's cost impact (absolute dollars or percentage), not on total spend against an allowance.
• Root cause analysis names the service, account, Region and usage type. It does not name individual resources; find the resource in CUR with resource IDs (or in Cost Explorer if it is within the 14-day resource-level window).