Video summary

Bedrock Cost Allocation | The Keys to AWS Optimization | S17 E7

Main summary

Key takeaways

Technology

Summary (Bedrock Cost Allocation + AWS Optimization)

The video “The Keys to AWS Optimization” (S17 E7) explains how to optimize and allocate Amazon Bedrock spend—primarily metered in tokens and recorded via API calls (e.g., InvokeModel / Converse / batch). Because of this, traditional resource tagging is often insufficient.

1) Why Bedrock cost allocation is tricky

  • Bedrock pricing is based on tokens, not provisioned/taggable infrastructure.
  • Most usage shows up as API invocation line items, so cost allocation must rely on data export + tags rather than EC2/EBS-style resource tagging.

2) New/updated capability: IM Principal Allocation Tags

The core feature enables cost allocation using identity-based tags that map into CUR (Cost and Usage Report) / Cost Explorer.

Tag sources now include:

  • Bedrock inference profiles (existing concept; still useful for some dashboards/separation)
  • IAM Principal (roles/users) tags (new tag propagation path)
  • IAM session tags (critical for multi-tenant SaaS / ISV patterns)

Benefit: scalable allocation without creating many inference profiles just to tag per team/customer.

3) Key concepts: “IM Principal” and “inference profiles”

  • Inference profile: a reusable Bedrock connection configuration (e.g., model selection). Tagging it can flow into cost data.
  • IM principal (per subtitles): the identity entity (typically an IAM role) under which API calls are made; its tags can be propagated into cost allocation.
  • IM sessions: tags passed during STS AssumeRole that add extra dimensions (e.g., tenant, department, application), even if the underlying role is shared.

4) What to enable so tags appear in cost exports

To get the new columns/tags into CUR:

  • Ensure you are using CUR 2.0 (older CUR versions don’t have the required data).
  • When editing/creating the CUR export, enable “IM principal allocation data” to get the new columns.
  • In Cost Allocation Tags, enable the correct tag type:
    • Specifically add “IM principal” (even if resource tag type is already enabled).

Important: tags begin appearing only after the principal/session has incurred Bedrock usage.

Additional notes mentioned:

  • You can now edit existing CUR reports (not only create new ones).
  • For IaC setups (e.g., CloudFormation for CUR exports), update templates so the new tag propagation is included.
  • Assumed roles are supported, and session tags flow through.

5) Sending tags from application code (demo pattern)

A demo pattern shows:

  1. Call STS AssumeRole
  2. Provide:
    • role identifier
    • session name containing contextual info
    • session tags (e.g., department, application)
  3. Call Bedrock Converse API using the assumed-role credentials

Result: those tags/identity context propagate into:

  • Cost Explorer
  • Cost and Usage Report (CUR) line items

6) Where the data appears: Cost Explorer + CUR columns

Cost Explorer

New grouping dimensions include:

  • IM principal tag dimensions (e.g., environment, application, department)
  • Tag-based cost breakdowns

Cost and Usage Report (CUR 2.0)

The video highlights new/expanded columns and the “tags” consolidation:

  • CUR includes:
    • a Line item “IM principal” column (role/session identity context; may include session string context)
    • a “tags” column (a consolidated structure)

Column differences:

  • resource_tags: only resource tags
  • cost categories: separate map
  • tags column: unified/expanded map including resource tags + cost categories + account tags + IM principal tags + user attributes tags

Recommendation: migrate queries/dashboards toward the unified tags column for easier extraction.

7) Query example (Athena-style reasoning)

Sample queries compute:

  • Spend per department/application by summing unblended cost grouped by tag values extracted from the CUR tags structure.

8) IAM Identity Center / SSO behavior (not fully automatic)

  • SSO identity appears in the IM principal column context.
  • Session tags (key/value dimensions) still depend on the application sending tags (e.g., via assume role / session tagging).
  • “Auto-tagging” without manual/application tagging is discussed as a feature request, not current behavior.

9) Common mistakes and operational guidance

Pitfalls mentioned:

  • Forgetting to activate the relevant tagging in Cost Allocation settings.
  • Using tags without a consistent taxonomy (e.g., ops vs operations, casing differences).
  • Tagging too late or inconsistently.

Operational advice:

  • Use IaC defaults (Terraform / CloudFormation) so tagging is enforced consistently.

Other note:

  • Tags are historical snapshots; if department names change, old values remain in past CUR results. Prefer stable IDs when reconciling over time.

10) Prompting/RAG considerations

  • Tagging applies to Bedrock API calls.
  • For RAG, ensure other RAG-related resources are also tagged appropriately (not only the Bedrock call).
  • Bedrock invocation logging can support retroactive splitting for cost attribution strategies.

11) Kudos dashboard integration (native visibility)

They describe Kudos dashboard v5.8 adding native Bedrock visuals using these tags:

  • Cost per:
    • application
    • department
    • environment
    • IM principle
    • roles/sessions (with caution due to combinatorics)
  • Token efficiency insights:
    • input vs output token costs
    • cost per 1M tokens
    • correlation with model usage changes
    • prompt caching visibility (example indicates prompt caching wasn’t used)

12) Model lifecycle use case: why tracking matters

A key analysis point:

  • Bedrock models undergo lifecycle changes (end of support / end of support pricing changes).
  • Knowing which teams/apps/users/roles use which models helps identify:
    • who is still on legacy models
    • where cost spikes occur due to lifecycle transitions

They reference a blog/article about tracking model usage as models age.

13) Budget/guardrails discussion (limits)

  • Budgets/alerts were discussed as possible, but not as a strict “hard cap” per IM principal tag for Bedrock in the same way.
  • Suggested alternatives include alarms/CloudWatch patterns and focusing on application-level guardrails.

Main speakers / sources

  • Seth Guuch — Senior Solutions/AWS advocate (host/intro)
  • Yuri — Principal Technical Account Manager; leads Cloud Intelligence Dashboards
  • Justin Marks — Principal TAM; PHOps specialist; owns the CUR query library
  • AWS / Kudos / AWS Cost and Usage Report (CUR 2.0) documentation and related dashboard tooling (referenced as sources)

Original video