Bedrock Cross-Account Invocation: Access Authority, Billing Attribution, and Trust Policies

Choose between centralized caller, cross-account inference profiles, and per-account Bedrock access patterns. Understand which account receives billing charges per...

Understanding What You Own and What AWS Owns

Before discussing cross-account Bedrock access, one point of architecture clarity is essential: Bedrock foundation models are AWS-managed services. When you call bedrock:InvokeModel, you are consuming a service endpoint. You do not own, deploy, or manage the model instances. The underlying compute and model weights are owned and operated by AWS.

This matters for cross-account design because "sharing Bedrock access across accounts" is not about sharing model deployments. It is about controlling which IAM principals have permission to call the Bedrock API and which AWS account receives the billing charge for each API call. Provisioned Throughput commitments are per-account financial commitments for reserved capacity -- they are not model ownership.

With that framing, there are three distinct patterns for cross-account Bedrock access, each with different billing attribution and IAM trust requirements.

Pattern 1: Centralized Caller Account

In this pattern, one platform team account holds all Bedrock invocation permissions. Product team accounts do not have direct Bedrock access. Instead, they call an internal API (hosted on API Gateway, Lambda, or a service endpoint) in the platform account, which calls Bedrock on their behalf.

Billing attribution: All Bedrock charges accrue to the platform account. Product teams are billed internally via cost allocation tags or showback mechanisms that the platform team implements separately.

IAM design: Product team accounts need no Bedrock IAM permissions. They need permission to call the platform team's internal API (which uses standard API Gateway or Lambda authorization). The platform account's Lambda or ECS service role holds bedrock:InvokeModel permission. The platform account manages the Bedrock IAM configuration entirely.

Advantages: Centralized control over which models can be invoked, consistent guardrails, single Provisioned Throughput commitment if one is used. Product teams do not need to understand Bedrock IAM configuration.

Disadvantages: The platform API is a single point of failure and a potential bottleneck. All Bedrock traffic routes through one account's service. The platform team must build and maintain the internal API, versioning, and authentication. Cost transparency to product teams requires additional instrumentation.

Trust policy design: No cross-account Bedrock trust policy is required. The platform account's execution role needs only bedrock:InvokeModel. Product team access is controlled by the internal API's authentication layer, not IAM trust policies on Bedrock.

Pattern 2: Cross-Account Inference Profiles

Bedrock cross-account inference profiles allow one account (the caller account) to invoke Bedrock using a profile that is defined in and billed to a different account (the profile owner account). This is the native Bedrock mechanism for cross-account invocation authority with separated billing attribution.

Billing attribution: The account that owns the inference profile receives the billing charge for invocations made through the profile, regardless of which account made the API call. This is the key distinction from Pattern 1: in Pattern 1, the caller account pays; in Pattern 2, the profile owner account pays for invocations through the profile.

As of the current API, cross-account inference profile functionality should be verified in the primary source documentation (https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-cross-account.html) for exact setup steps, as the feature set for cross-account profiles was expanding in mid-2025.

IAM trust policy design for cross-account profile invocation:

The profile owner account creates the inference profile and grants the calling account permission to use it via a resource-based policy. The calling account's IAM role must have bedrock:InvokeModel (or the profile-specific action) on the profile ARN.

Profile owner account resource-based policy (attached to the profile):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCallerAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<caller-account-id>:root"
      },
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:<region>:<profile-owner-account-id>:inference-profile/<profile-id>"
    }
  ]
}

Calling account IAM role policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:<region>:<profile-owner-account-id>:inference-profile/<profile-id>"
    }
  ]
}

Advantages: Native Bedrock billing separation. The profile owner can maintain Provisioned Throughput commitments that apply to all callers using the profile. Callers do not need a Provisioned Throughput commitment in their own accounts.

Disadvantages: More complex IAM configuration than Pattern 1. Billing accrues to the profile owner account, requiring charge-back arrangements. The profile owner must manage the profile's model configuration and capacity.

Pattern 3: Per-Account Direct Bedrock Access

Each product team account has its own direct bedrock:InvokeModel IAM permissions. Each account invokes Bedrock independently and each account receives its own Bedrock billing charge.

Billing attribution: Each account pays for its own Bedrock usage. Billing is naturally separated by AWS account, which shows up directly in each account's AWS bill and in AWS Cost Explorer with no additional instrumentation required.

IAM design: Each account needs IAM roles with bedrock:InvokeModel for the models it is permitted to invoke. Use SCPs (see B15) to enforce a model allowlist at the organization level if you need to restrict which models each account can access.

Advantages: Simplest IAM design. Natural billing separation. No dependency on a shared platform API or profile owner account. Each team has direct control over their Bedrock configuration.

Disadvantages: No centralized guardrails without SCPs. If you want consistent Guardrails, Knowledge Base configurations, or Provisioned Throughput commitments across accounts, each account must configure these independently. Quota management is per-account.

Worked Example: Platform Team Serving Three Product Teams

A platform team runs in account platform-123. Three product teams run in accounts product-a-456, product-b-789, and product-c-012. The platform team wants to provide Bedrock invocation capability to the product teams.

Scenario A: Centralized API (Pattern 1)

The platform team deploys an internal Bedrock proxy API on API Gateway + Lambda in platform-123. Product teams authenticate to this API using AWS SigV4 signed requests from their own IAM roles (cross-account invocation of an API Gateway private REST API). The Lambda in platform-123 calls bedrock:InvokeModel with its own execution role.

Billing account: platform-123 for all Bedrock invocations. The platform team tags each invocation with the calling product team's identifier for cost allocation.

IAM trust: product-a-456, product-b-789, and product-c-012 roles have execute-api:Invoke on the API Gateway resource policy in platform-123. The API Gateway resource policy grants access from specific account IDs or IAM role ARNs.

Scenario B: Cross-Account Inference Profile (Pattern 2)

The platform team creates an inference profile in platform-123 covering Claude 3 Sonnet with Provisioned Throughput. The platform team grants each product account permission to invoke via the profile resource-based policy. Each product account's role references the cross-account inference profile ARN directly in their bedrock:InvokeModel calls.

Billing account: platform-123 pays for all Provisioned Throughput capacity; on-demand invocations via the profile also bill to platform-123. Product teams charge back through internal cost allocation.

Scenario C: Per-Account Direct Access (Pattern 3)

Each product account has its own IAM roles with bedrock:InvokeModel. An SCP at the ai-sandbox OU level (see B15) enforces the approved model allowlist. Each product team manages its own Bedrock quotas, Guardrails, and Knowledge Base configurations.

Billing account: each product account pays its own Bedrock bill. Billing is visible directly in each account's Cost Explorer under the Bedrock service.

Choosing between patterns: Use Pattern 1 (centralized API) when you need maximum control and consistent middleware (audit logging, PII redaction, content filtering) applied to all Bedrock traffic, and when the platform team has capacity to maintain the proxy API. Use Pattern 2 (inference profiles) when the goal is billing separation with a shared Provisioned Throughput commitment and native Bedrock invocation from product accounts. Use Pattern 3 (per-account) when product teams are autonomous, billing separation is a first-class requirement, and centralized guardrails are enforced via SCPs and Bedrock Guardrails configured independently per account.

Failure Modes

Assuming cross-account means shared model instances. Platform engineers sometimes expect that sharing a "Bedrock access" across accounts means multiple teams share one model deployment. Bedrock foundation models are AWS-managed and multi-tenant by nature. Cross-account patterns control invocation authority and billing attribution, not instance sharing.

Provisioned Throughput commitment applying to wrong account. A Provisioned Throughput commitment is per-account. If platform-123 holds the commitment but product teams invoke directly from their own accounts (Pattern 3), the product team invocations use on-demand pricing, not the committed capacity. The commitment only applies to invocations from the account that purchased it (or via inference profiles in Pattern 2 that reference that account's committed capacity).

Resource-based policy on inference profile not granting sufficient scope. If the profile resource-based policy grants access to arn:aws:iam::<caller-account-id>:root, any IAM principal in the caller account with the correct IAM permission can use the profile. If you need to restrict to specific roles, replace :root with the specific role ARN. Test with an IAM Policy Simulator after configuration to confirm the effective permissions.

Diagnostic Signals

CloudTrail in the profile owner account records every invocation made through a cross-account profile, including the calling account's principal ARN in the userIdentity field. This is the billing and audit source for Pattern 2: the profile owner can query CloudTrail to see which caller accounts and roles used the profile and how much capacity each consumed.

For Pattern 1 (centralized API), instrument the Lambda with an x-caller-account custom header or request attribute and emit it as a CloudWatch metric dimension for cost attribution.

Next Steps

For multi-account AWS architecture decisions including Bedrock access design, the Ampity AWS Consulting service [/ai/amazon-bedrock-consulting] covers pattern selection, trust policy design, and cost attribution implementation. Verify cross-account inference profile feature availability and resource-based policy syntax against the primary source documentation for your AWS region before implementing Pattern 2.

Primary Sources

• Bedrock Cross-Account Inference Profiles, source checked 2026-11-05
• Bedrock Security and IAM, source checked 2026-11-05