What's New

Amazon Bedrock now supports request-level usage attribution on the InvokeModel and InvokeModelWithResponseStream APIs, allowing customers to attach arbitrary key-value metadata tags to individual inference calls. These tags are captured in model invocation logs, enabling fine-grained visibility into how AI usage is distributed across teams, applications, environments, and experiments. This extends a capability previously available only on the Converse and ConverseStream APIs, bringing consistent per-request tagging across the entire bedrock-runtime endpoint.

How It Works

• HTTP Header Injection: For InvokeModel and InvokeModelWithResponseStream, metadata is passed via the X-Amzn-Bedrock-Request-Metadata HTTP header as a JSON object of string key-value pairs (e.g., {"team": "orchestrator", "environment": "production"}).
• Request Body for Converse APIs: The Converse and ConverseStream APIs use the requestMetadata field in the request body instead of an HTTP header, maintaining their existing behavior.
• SigV4 Signing Requirement: When using AWS Signature Version 4 authentication, the X-Amzn-Bedrock-Request-Metadata header must be explicitly included in the SignedHeaders list; omitting it results in an InvalidSignatureException. AWS SDKs handle this automatically when metadata is passed as a parameter.
• Logging Dependency: Tags are recorded only in model invocation logs, which must be explicitly enabled in the target AWS Region (via CloudWatch Logs or Amazon S3) before metadata will be captured.
• No Pre-provisioning Required: There is no resource to create or configure in advance — each individual request can carry a completely different set of tags, making the system fully dynamic.
• Log-Based Analysis: Once captured, tags appear in invocation log records and can be queried or aggregated using standard log analytics tools to slice usage by any tagged dimension.

Why It's Important

• Unified Cost Attribution: Organizations running multiple teams or products on shared AWS accounts can now attribute token consumption and inference costs to specific owners at the request level, enabling accurate internal chargeback and showback reporting.
• Operational Observability: Tagging by environment (dev/staging/prod) or experiment ID allows teams to isolate usage spikes, debug runaway processes, and understand consumption patterns without relying on coarse-grained account or IAM-level signals.
• No Infrastructure Overhead: Unlike application inference profiles or workspaces, this feature requires zero pre-provisioning — teams can start tagging immediately by modifying request headers, lowering the barrier to adoption.
• Consistency Across APIs: Bringing the same metadata capability to InvokeModel and InvokeModelWithResponseStream closes a gap for teams using raw model invocations (e.g., for models not supported by the Converse API), ensuring a uniform attribution strategy across all Bedrock runtime APIs.
• Experiment Tracking: Data science and ML engineering teams can tag individual inference calls with experiment or run IDs, enabling post-hoc analysis of model usage and cost per experiment without external instrumentation.

How It's Different

• vs. Application Inference Profiles: Inference profiles provide resource-level attribution that flows directly into AWS Cost Explorer and Cost and Usage Reports as cost allocation tags; request metadata is more granular (per-call) but surfaces only in invocation logs, not billing dashboards.
• vs. IAM Principal-Based Attribution: IAM attribution ties usage to the identity making the call, which is coarse when many teams share a single role or service account; request metadata allows arbitrary, call-specific dimensions independent of IAM identity.
• vs. Project-Level Tracking (bedrock-mantle): Project tracking on the OpenAI-compatible bedrock-mantle endpoint operates at the project level and is not per-request; notably, request metadata is explicitly not supported on bedrock-mantle, making these complementary rather than overlapping.
• vs. Converse API Metadata: The Converse/ConverseStream APIs use a request body field (requestMetadata), while InvokeModel/InvokeModelWithResponseStream use an HTTP header — the semantics are equivalent, but the implementation differs by API surface.
• vs. External Tagging Solutions: Custom middleware or proxy-based tagging solutions add latency and operational complexity; native header-based tagging is zero-latency and handled entirely within the Bedrock service.

When to Prefer It

• Multi-Team Shared Accounts: Use request metadata when multiple teams share a single AWS account or IAM role and you need to attribute inference costs and usage back to individual teams without restructuring your AWS account hierarchy.
• A/B Testing and Experimentation: Tag inference calls with experiment IDs or variant labels when running model comparisons or prompt experiments, enabling precise cost and performance analysis per experiment run.
• Environment Segmentation: Apply environment: production vs. environment: staging tags to distinguish live traffic from test traffic in invocation logs, especially when both environments share the same model endpoints.
• Application-Level Breakdown: When a single service calls multiple models for different features (e.g., summarization, classification, code generation), tag each call with a feature or use_case key to understand per-feature AI spend.
• Raw API Users: Prefer this approach when using InvokeModel directly (e.g., for models or request formats not supported by the Converse API) and you need the same attribution granularity previously only available via Converse.
• Lightweight Attribution Without Billing Integration: When you need operational visibility in logs but do not require tags to appear in AWS Cost Explorer or CUR, request metadata is the simplest path with no resource setup required.

Availability

• GA Status: Generally available as of May 20, 2026.
• Supported APIs: InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream on the bedrock-runtime endpoint; explicitly not supported on the bedrock-mantle (OpenAI-compatible) endpoint.
• Regional Availability: Available in all AWS commercial Regions where Amazon Bedrock is available.
• Prerequisite: Model invocation logging must be enabled in the target AWS Region (CloudWatch Logs or Amazon S3) for metadata to be captured; tags are not recorded if logging is disabled.
• Pricing: No additional charge for adding request metadata; standard model inference and logging costs apply.
• Limitations: Tag values must be strings; metadata appears only in invocation logs and does not flow into AWS Cost Explorer or Cost and Usage Reports as cost allocation tags (use inference profiles, projects, or workspaces for billing-level attribution).

Related Resources

• https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-request-metadata.html