← Agent Frameworks 🕐 25 min read
Agent Frameworks

Bedrock Marketplace Third-Party Models — Cost, CUR Attribution, and Enterprise Governance (2026)

Executive Summary · March 2026

Amazon Bedrock Marketplace hosts 100+ third-party foundation models from providers including Mistral AI, Meta, Cohere, AI21, Stability AI, DeepSeek, Writer, Qwen, and others.

Amazon Bedrock Marketplace hosts 100+ third-party foundation models from providers including Mistral AI, Meta, Cohere, AI21, Stability AI, DeepSeek, Writer, Qwen, and others. From a FinOps perspective the critical distinction is architectural: core Bedrock models (Anthropic Claude, Amazon Nova, base Llama/Mistral on-demand) are serverless and bill as AmazonBedrock in the CUR; Bedrock Marketplace models are deployed onto SageMaker-managed endpoints and their infrastructure costs appear under AmazonSageMaker as a separate line item. This creates a systematic blind spot in Bedrock cost dashboards that look only at the AmazonBedrock product code. A complete view requires querying across both product codes plus the Marketplace software subscription charges.

The per-token premium for using third-party models through Bedrock rather than directly through provider APIs ranges from 20% (Cohere) to 50% (Mistral Large 2 vintage). The premium narrows significantly or disappears for newer model generations where providers repriced on Bedrock (Mistral Large 3 at $0.50/$1.50 vs $2.00/$6.00 for Large 2). Whether the premium is justified depends on whether the workload can absorb it in exchange for consolidated billing, no separate vendor contract, unified IAM governance, and eligibility for AWS EDP commitment burn.

1. Bedrock Marketplace Architecture and Model Catalog

1.1 Two Distinct Model Access Paths

Amazon Bedrock presents a unified API surface but routes inference through two operationally distinct backends:

Path A — Native Bedrock Serverless (on-demand) Models accessed directly through bedrock-runtime InvokeModel or Converse APIs without endpoint provisioning. The full model weights run on AWS-managed shared infrastructure. Billing is per-token, metered to the second, billed under AmazonBedrock product code in CUR. Models in this category include all Anthropic Claude variants, Amazon Nova (Micro/Lite/Pro/Premier), Meta Llama (on-demand token tiers), and Mistral models enabled through the model access page.

Path B — Bedrock Marketplace Deployed Endpoints Models from the Marketplace catalog are deployed to a SageMaker-managed endpoint after subscription. The customer specifies instance type and instance count. The endpoint runs persistently until explicitly deleted. Billing has two components: (1) a software fee to the model provider (can be zero for open-weight models), plus (2) SageMaker ML instance hosting fees billed per-hour for the lifetime of the endpoint. Infrastructure costs appear under AmazonSageMaker in the CUR, not AmazonBedrock. Model invocation goes through the Bedrock API, but the underlying execution plane is SageMaker.

This architectural split is the source of the most common enterprise FinOps gap with Bedrock: teams that build Bedrock spend dashboards filtering on product_code = 'AmazonBedrock' will miss all Marketplace endpoint costs entirely.

1.2 Catalog Coverage (June 2026)

The Bedrock model catalog includes 18+ providers with 110+ models. Key third-party families:

Provider Representative Models Access Path
Anthropic Claude Opus 4.7, Sonnet 4.6, Haiku 4.5 Native Bedrock
Amazon Nova Micro, Nova Lite, Nova Pro, Nova Premier Native Bedrock
Meta Llama 3.3 70B, Llama 3.1 8B, Llama 3.1 405B Native + Marketplace
Mistral AI Large 3, Devstral 2, Magistral Small, Ministral 3B/8B/14B, Voxtral Native (on-demand token)
Cohere Command R+, Command R, Embed 3 (English/Multilingual) Native + Marketplace
AI21 Labs Jamba Large 1.7, Jamba Mini Native (on-demand)
Stability AI Stable Diffusion 3.5, SDXL variants Marketplace (image generation)
DeepSeek DeepSeek-R1, V3 variants Marketplace endpoint
Writer Palmyra X5, X4 Marketplace
Qwen Qwen 2.5 variants Marketplace
Luma AI Dream Machine (video generation) Marketplace
TwelveLabs Marengo (multimodal embedding) Marketplace

Note: The distinction between “Native Bedrock” and “Marketplace” for a given provider can vary by specific model variant and region. Meta Llama 3.3 70B is available on-demand at serverless rates in most regions; Llama 3.1 405B typically requires a Marketplace endpoint due to model size. Always verify the model detail page to confirm the access path before building cost models.

1.3 Marketplace Subscription Workflow

Marketplace model access involves an explicit subscription step distinct from the model access enablement used for core Bedrock models:

  1. Navigate to Model Catalog → filter by Model Collection = Bedrock Marketplace
  2. Select model card → View Subscription Options
  3. Review provider pricing (software fee component) and EULA
  4. Subscribe — process completes in 10–15 minutes
  5. Deploy model to endpoint (instance type selection required)
  6. Register endpoint with Bedrock: bedrock:RegisterMarketplaceModelEndpoint
  7. Invoke via bedrock-runtime InvokeModel using the registered endpoint ARN

Auto-enablement note: For models where AWS has streamlined access, the subscription may be initiated automatically in the background on first InvokeModel call. However, if subscription fails (e.g., blocked by SCP), subsequent calls will fail. Do not rely on auto-enablement in production — pre-provision subscriptions through your standard change management process.

2. CUR Attribution for Marketplace Models

2.1 The Product Code Split

This is the most operationally significant FinOps issue with Bedrock Marketplace. Costs appear in two separate product codes:

Cost Component CUR product_code line_item_usage_type Pattern
Native Bedrock inference (Claude, Nova, Mistral on-demand) AmazonBedrock {region}-{model}-input-tokens
Marketplace endpoint ML instance hosting AmazonSageMaker {region}:HostingBedrock-{instance-type}
Marketplace software subscription fee AWSMarketplace varies by provider ASIN
Custom Model Import inference (CMU billing) AmazonBedrock {region}-CustomModelUnit-{version}

The SageMaker hosting component is billed against the SageMaker endpoint, not the Bedrock model invocation. The line_item_resource_id will reference the SageMaker endpoint ARN (arn:aws:sagemaker:{region}:{account}:endpoint/{endpoint-name}), not a Bedrock model ARN. This means:

  • A Bedrock cost dashboard looking at AmazonBedrock product code captures zero of the Marketplace endpoint infrastructure cost.
  • The SageMaker cost dashboard shows these costs but lacks the Bedrock model context needed to attribute them correctly.
  • A FinOps engineer reviewing “SageMaker costs” may not recognize Bedrock-Marketplace endpoints as AI inference spend.

2.2 Identifying Marketplace Endpoints in CUR

AWS applies a tag set to Marketplace endpoints at provisioning time. These tags appear on the SageMaker endpoint resources and flow into CUR if cost allocation tags are activated:

Tag Key Value Pattern Meaning
sagemaker-sdk:bedrock compatible Resource is a Bedrock-registered endpoint
bedrock:marketplace-registration-status registered Endpoint registered with Bedrock
sagemaker-studio:hub-content-arn arn:aws:sagemaker:*:aws:hub-content/SageMakerPublicHub/Model/{model-id}/* Source model from SageMaker Public Hub

Activate sagemaker-sdk:bedrock and sagemaker-studio:hub-content-arn as cost allocation tags in the Billing console to enable filtering. Allow up to 24 hours after activation for tag data to appear in CUR.

2.3 CUR Usage Type Patterns: Native vs. Marketplace

Native Bedrock on-demand (AmazonBedrock product code):

USE1-mistral.mistral-large-2402-v1:0-input-tokens
USE1-mistral.mistral-large-2402-v1:0-output-tokens
USE1-meta.llama3-70b-instruct-v1:0-input-tokens
USE1-meta.llama3-70b-instruct-v1:0-output-tokens
USE1-cohere.command-r-plus-v1:0-input-tokens
USE1-cohere.command-r-plus-v1:0-output-tokens
USE1-ai21.jamba-instruct-v1:0-input-tokens
USE1-ai21.jamba-instruct-v1:0-output-tokens
USE1-Nova2.0Lite-input-tokens
USE1-Nova2.0Lite-output-tokens

Bedrock Marketplace endpoint hosting (AmazonSageMaker product code):

USE1:HostingBedrock-ml.g5.48xlarge
USE1:HostingBedrock-ml.g5.12xlarge
USE1:HostingBedrock-ml.p4d.24xlarge

Note: The HostingBedrock- prefix in SageMaker usage types is the key signal that distinguishes Bedrock Marketplace endpoint hosting from general SageMaker workloads. Not all SageMaker spend with this prefix will have the sagemaker-sdk:bedrock tag applied (particularly for endpoints provisioned before the tag policy was enforced), so filter on both.

2.4 Athena Queries for Complete Bedrock Spend

The following queries work against CUR 2.0 exported to S3 and crawled by Glue/Athena. Replace your_cur_database and your_cur_table with your actual Glue catalog names.

Query 1: Full Bedrock spend including Marketplace (last 30 days)

SELECT
  DATE_TRUNC('day', line_item_usage_start_date)    AS usage_date,
  line_item_product_code,
  line_item_usage_type,
  line_item_operation,
  resource_tags_sagemaker_sdk_bedrock              AS bedrock_marketplace_tag,
  resource_tags_sagemaker_studio_hub_content_arn   AS source_model_arn,
  SUM(line_item_unblended_cost)                    AS total_cost_usd,
  SUM(line_item_usage_amount)                      AS usage_amount
FROM your_cur_database.your_cur_table
WHERE
  line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
  AND (
    line_item_product_code = 'AmazonBedrock'
    OR (
      line_item_product_code = 'AmazonSageMaker'
      AND (
        line_item_usage_type LIKE '%HostingBedrock%'
        OR resource_tags_sagemaker_sdk_bedrock = 'compatible'
      )
    )
    OR line_item_product_code = 'AWSMarketplace'
  )
GROUP BY 1, 2, 3, 4, 5, 6
ORDER BY 1 DESC, 7 DESC;

Query 2: Marketplace model cost rollup by endpoint (identify runaway endpoints)

SELECT
  line_item_resource_id                            AS endpoint_arn,
  resource_tags_sagemaker_studio_hub_content_arn   AS model_source,
  SUM(line_item_unblended_cost)                    AS total_cost_usd,
  MIN(line_item_usage_start_date)                  AS first_seen,
  MAX(line_item_usage_end_date)                    AS last_seen,
  COUNT(DISTINCT DATE_TRUNC('day', line_item_usage_start_date)) AS active_days
FROM your_cur_database.your_cur_table
WHERE
  line_item_product_code = 'AmazonSageMaker'
  AND line_item_usage_type LIKE '%HostingBedrock%'
  AND line_item_usage_start_date >= DATE_ADD('day', -90, CURRENT_DATE)
GROUP BY 1, 2
ORDER BY 3 DESC;

Query 3: CUR 2.0 with IAM principal attribution (identify which teams use which Marketplace models)

SELECT
  split_part(iam_principal_arn, '/', 3)            AS role_session,
  split_part(iam_principal_arn, '/', 2)            AS assumed_role,
  line_item_product_code,
  line_item_usage_type,
  resource_tags_sagemaker_studio_hub_content_arn   AS model_arn,
  SUM(line_item_unblended_cost)                    AS cost_usd
FROM your_cur_database.your_cur_table
WHERE
  line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
  AND (
    line_item_product_code = 'AmazonBedrock'
    OR (line_item_product_code = 'AmazonSageMaker'
        AND resource_tags_sagemaker_sdk_bedrock = 'compatible')
  )
  AND iam_principal_arn IS NOT NULL
GROUP BY 1, 2, 3, 4, 5
ORDER BY 6 DESC
LIMIT 100;

Note: iam_principal_arn requires CUR 2.0 with “Include caller identity (IAM principal) allocation data” enabled. It is not available in legacy CUR format.

Query 4: Compare native Bedrock vs. Marketplace spend ratio

SELECT
  DATE_TRUNC('month', line_item_usage_start_date) AS month,
  CASE
    WHEN line_item_product_code = 'AmazonBedrock'
         AND line_item_usage_type NOT LIKE '%CustomModelUnit%'
      THEN 'native_bedrock_serverless'
    WHEN line_item_product_code = 'AmazonBedrock'
         AND line_item_usage_type LIKE '%CustomModelUnit%'
      THEN 'custom_model_import_cmu'
    WHEN line_item_product_code = 'AmazonSageMaker'
         AND line_item_usage_type LIKE '%HostingBedrock%'
      THEN 'marketplace_endpoint_hosting'
    WHEN line_item_product_code = 'AWSMarketplace'
      THEN 'marketplace_software_fee'
    ELSE 'other'
  END AS cost_category,
  SUM(line_item_unblended_cost) AS total_usd
FROM your_cur_database.your_cur_table
WHERE
  line_item_usage_start_date >= DATE_ADD('month', -6, CURRENT_DATE)
  AND (
    line_item_product_code IN ('AmazonBedrock', 'AWSMarketplace')
    OR (line_item_product_code = 'AmazonSageMaker'
        AND line_item_usage_type LIKE '%HostingBedrock%')
  )
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

3. Cost Comparison: Bedrock Marketplace vs. Direct Provider APIs

3.1 Mistral on Bedrock vs. Mistral API Direct

Mistral is available both as on-demand serverless inference on native Bedrock and through the direct Mistral API (La Plateforme). The pricing history shows a significant price break between generations.

Mistral on AWS Bedrock (on-demand, US East, June 2026):

Model Input ($/1M tokens) Output ($/1M tokens) Context Window
Mistral Large 3 $0.50 $1.50 128K
Devstral 2 123B (coding) $0.40 $2.00 128K
Magistral Small 1.2 $0.50 $1.50 256K
Ministral 14B 3.0 $0.20 $0.20 128K
Ministral 8B 3.0 $0.15 $0.15 128K
Ministral 3B 3.0 $0.10 $0.10 32K
Voxtral Small 1.0 (audio) $0.10 $0.30 —
Voxtral Mini 1.0 (audio) $0.04 $0.04 —
Mistral Large 2 (legacy) $3.00 $9.00 128K

Mistral La Plateforme API direct (June 2026):

Model Input ($/1M tokens) Output ($/1M tokens)
Mistral Large 2 $2.00 $6.00
Mistral Small 3.1 $0.10 $0.30

Key finding: Mistral Large 2 on Bedrock carried a 50% markup over the direct API ($3/$9 vs $2/$6). Mistral Large 3 on Bedrock is priced at $0.50/$1.50 — a 75% reduction from Large 2 — and the direct API parity gap has narrowed substantially. For workloads still on Large 2, migrating to Large 3 and staying on Bedrock is cheaper than staying on Large 2 through the direct API.

Break-even analysis: At current prices, the Bedrock Marketplace premium on Mistral Large 2 costs $1.00/M input tokens and $3.00/M output tokens. If your workload generates 10M output tokens/month, the direct API saves $30/month per million output tokens — but requires a separate Mistral account, separate billing reconciliation, separate security review, and loses AWS EDP commitment burn (see Section 6).

3.2 Meta Llama on Bedrock vs. Groq vs. Together AI

Meta Llama 3.3 70B is the current price/performance reference point for open-weight models. The cost structure varies dramatically across providers.

Llama 3.3 70B pricing comparison (June 2026):

Provider Input ($/1M tokens) Output ($/1M tokens) Notes
AWS Bedrock (on-demand) $0.72 $0.72 Serverless, no endpoint management
Groq (batch/cached) ~$0.30 ~$0.40 LPU hardware, ~10x faster than GPU
Groq (standard) $0.59 $0.79 Near-instant inference
Together AI $0.88 $0.88 Standard on-demand
Self-hosting (g5.48xlarge) ~$0.10–0.20* ~$0.10–0.20* Estimate; varies with utilization

*Self-hosting estimate: g5.48xlarge at $16.29/hr spot, Llama 3.3 70B at ~60K tokens/sec throughput, ~70% utilization → roughly $0.12–0.20/M tokens fully loaded. Does not include operational overhead, patching, scaling, reliability engineering.

Assessment: Bedrock on-demand at $0.72/$0.72 is cheaper than Together AI and structurally comparable to Groq for non-latency-critical workloads. Groq holds a decisive advantage for real-time applications requiring sub-200ms TTFT. For batch inference pipelines with no latency requirement, Bedrock’s 50% batch discount ($0.36/$0.36) makes it competitive with Groq standard pricing while providing full AWS native integration.

Llama 3.1 405B: This model requires a Marketplace endpoint due to its size. A single ml.p4d.24xlarge endpoint costs approximately $32/hr (on-demand), giving a floor of ~$23K/month even at zero inference volume. The endpoint must run persistently to serve requests. This is appropriate for high-volume, latency-sensitive internal workloads but economically irrational for low-volume use cases. At 405B scale, self-hosting on AWS with Provisioned Throughput or using a specialized inference provider (Fireworks AI, Nebius) is often more economical.

3.3 Cohere on Bedrock vs. Cohere Direct API

Cohere’s Command family is positioned primarily for RAG and enterprise search workloads due to its native tool use and retrieval optimization.

Command R+ pricing comparison (June 2026):

Access Path Input ($/1M tokens) Output ($/1M tokens)
Cohere direct API $2.50 $10.00
AWS Bedrock on-demand $3.00 $15.00
AWS Bedrock Provisioned Throughput ~$49.50/hr per model unit ~$49.50/hr per model unit

The direct Cohere API is approximately 20% cheaper on input and 33% cheaper on output for Command R+. The Bedrock premium is relatively modest compared to Mistral Large 2’s historic 50% gap.

Cohere Embed 3 on Bedrock: $0.10/1M tokens (input only, embedding model). Direct Cohere API parity is near-identical. For embedding workloads the cost case is neutral; the integration case favors Bedrock if you are already running RAG Knowledge Bases with Bedrock.

Provisioned Throughput note: Cohere Command family on Bedrock also supports Provisioned Throughput at approximately $49.50/hr per model unit with no commitment, scaling to lower rates with 1-month or 6-month commitments. This is the preferred option when Command R+ throughput exceeds ~50K tokens/minute consistently.

3.4 When the Bedrock Marketplace Premium Is Justified

The Bedrock premium over direct provider APIs is typically 20–50% on per-token rates for equivalent models. The premium earns its cost when:

  1. Consolidated billing matters. A single AWS invoice vs. separate Mistral, Cohere, AI21, and Meta billing relationships. For enterprises with strict vendor onboarding (legal review, DPA, security questionnaire), each new AI vendor relationship carries a 4–12 week onboarding cost. Bedrock collapses this to a single AWS relationship.

  2. EDP commitment burn. Bedrock inference (including native third-party models) counts toward AWS Enterprise Discount Program commitments (see Section 6). If your organization has an uncommitted EDP balance, routing inference through Bedrock may cost less net-of-EDP than paying a lower list price directly to the provider.

  3. IAM-native access control. Bedrock enforces AWS IAM on all model access. Direct provider APIs require separate API key management, rotation policies, and audit trails. For FedRAMP or SOC 2 environments, keeping all model access within the IAM trust boundary is often a hard requirement.

  4. AWS native features. Bedrock Guardrails, Knowledge Bases, Agents, and Prompt Management work natively with all models (native and Marketplace) through the Bedrock Converse API. Replicating equivalent functionality against direct provider APIs requires custom middleware.

  5. No SaaS infrastructure to manage. For Marketplace models accessed via Bedrock Converse (not dedicated endpoints), AWS manages the inference infrastructure. The alternative for specialized models is often either a Marketplace endpoint (same billing overhead) or self-managed deployment.

4. Marketplace Model Governance

4.1 IAM Permission Architecture

Bedrock Marketplace model governance requires permissions across three distinct service namespaces: bedrock, sagemaker, and aws-marketplace. This creates a permission surface that is wider than native Bedrock and requires careful IAM decomposition.

Layer 1: Subscription permissions (account-level, human principals)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMarketplaceSubscription",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:Subscribe",
        "aws-marketplace:Unsubscribe",
        "aws-marketplace:ViewSubscriptions"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws-marketplace:ProductId": [
            "prod-*"
          ]
        }
      }
    }
  ]
}

Restrict this to a small set of identities (cloud platform team, AI governance committee) using an SCP or IAM boundary. The aws-marketplace:Subscribe action should not be available to application service roles.

Layer 2: Endpoint lifecycle permissions (platform/ops principals)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockMarketplaceEndpointLifecycle",
      "Effect": "Allow",
      "Action": [
        "bedrock:CreateMarketplaceModelEndpoint",
        "bedrock:DeleteMarketplaceModelEndpoint",
        "bedrock:RegisterMarketplaceModelEndpoint",
        "bedrock:DeregisterMarketplaceModelEndpoint",
        "bedrock:UpdateMarketplaceModelEndpoint",
        "bedrock:GetMarketplaceModelEndpoint",
        "bedrock:ListMarketplaceModelEndpoints"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SageMakerEndpointMutationsViaBedrock",
      "Effect": "Allow",
      "Action": [
        "sagemaker:CreateEndpoint",
        "sagemaker:CreateEndpointConfig",
        "sagemaker:CreateModel",
        "sagemaker:DeleteEndpoint",
        "sagemaker:UpdateEndpoint"
      ],
      "Resource": [
        "arn:aws:sagemaker:*:*:endpoint/*",
        "arn:aws:sagemaker:*:*:endpoint-config/*",
        "arn:aws:sagemaker:*:*:model/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:CalledViaLast": "bedrock.amazonaws.com",
          "aws:ResourceTag/sagemaker-sdk:bedrock": "compatible"
        }
      }
    }
  ]
}

The aws:CalledViaLast: bedrock.amazonaws.com condition is critical — it prevents application roles from calling SageMaker endpoint APIs directly and routes all lifecycle management through the Bedrock control plane.

Layer 3: Inference permissions (application service roles)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockMarketplaceInference",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1:111122223333:marketplace/model-endpoint/all-access"
      ]
    },
    {
      "Sid": "SageMakerInvokeViaBedrock",
      "Effect": "Allow",
      "Action": [
        "sagemaker:InvokeEndpoint",
        "sagemaker:InvokeEndpointWithResponseStream"
      ],
      "Resource": "arn:aws:sagemaker:*:*:endpoint/*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
      }
    }
  ]
}

Scope the Bedrock resource ARN to specific endpoint ARNs rather than all-access where possible.

4.2 AWS Managed Policy: AmazonBedrockMarketplaceAccess

AWS ships a managed policy arn:aws:iam::aws:policy/AmazonBedrockMarketplaceAccess (created June 2025, updated February 2026, currently at v3) that covers endpoint lifecycle and inference operations. The policy grants:

  • bedrock:Create/Delete/Register/Deregister/UpdateMarketplaceModelEndpoint
  • sagemaker:CreateEndpoint/Config/Model, DeleteEndpoint, UpdateEndpoint (conditioned on aws:CalledViaLast: bedrock.amazonaws.com and sagemaker-sdk:bedrock: compatible tag)
  • sagemaker:InvokeEndpoint/InvokeEndpointWithResponseStream (same conditions)
  • sagemaker:DescribeHubContent on SageMakerPublicHub
  • sagemaker:ListHubContents on SageMakerPublicHub
  • iam:PassRole scoped to *SageMaker*ForBedrock* and *AmazonBedrock* role name patterns
  • license-manager:ListReceivedLicenses for subscription verification

This policy does not grant aws-marketplace:Subscribe — subscription is a separate action that must be explicitly granted and is intentionally excluded from this managed policy.

4.3 SCPs to Restrict Marketplace Model Subscriptions

Deny all Marketplace subscriptions except approved products:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnauthorizedMarketplaceSubscription",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws-marketplace:ProductId": [
            "prod-MISTRAL-APPROVED-ID",
            "prod-META-LLAMA-APPROVED-ID",
            "prod-COHERE-APPROVED-ID"
          ]
        }
      }
    }
  ]
}

Deny creation of Bedrock Marketplace endpoints outside approved regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockMarketplaceOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": [
        "bedrock:CreateMarketplaceModelEndpoint",
        "bedrock:RegisterMarketplaceModelEndpoint"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

Deny access to specific model by hub content ARN tag:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySpecificMarketplaceModel",
      "Effect": "Deny",
      "Action": [
        "sagemaker:*",
        "bedrock:*"
      ],
      "Resource": [
        "arn:aws:sagemaker:*:*:endpoint/*",
        "arn:aws:sagemaker:*:*:endpoint-config/*",
        "arn:aws:sagemaker:*:*:model/*"
      ],
      "Condition": {
        "StringLike": {
          "aws:ResourceTag/sagemaker-studio:hub-content-arn": "arn:aws:sagemaker:*:aws:hub-content/SageMakerPublicHub/Model/deepseek-r1/*"
        }
      }
    }
  ]
}

4.4 Approval Workflow for New Subscriptions

AWS does not provide a native approval gate for Marketplace subscriptions. Enterprise governance typically implements one of three patterns:

Pattern A: AWS Service Catalog (recommended for regulated industries) Create a Service Catalog product that wraps the Marketplace subscription and endpoint provisioning steps. End users request the product through Service Catalog. The request triggers a human approval workflow (via SNS → Lambda → ticketing system). Service Catalog provisions the subscription and endpoint only upon approval. The end user never needs aws-marketplace:Subscribe directly — that permission lives in the Service Catalog launch role. Tag the resulting endpoint with the ticket number and approver identity for audit trail.

Pattern B: SCPs + IAM Boundary Grant aws-marketplace:Subscribe only to identities in a dedicated ai-governance IAM role. Remove the action from all developer and service roles via SCP. New model requests go through your standard IAM role request process (typically Jira → infra-as-code PR → approval). The governance role runs the subscription. This is operationally simple but creates a bottleneck at the governance role.

Pattern C: AWS Config Rule + Reactive Remediation Allow subscriptions, but deploy an AWS Config rule that evaluates all SageMaker endpoints for the sagemaker-sdk:bedrock: compatible tag and compares against an approved allowlist stored in Systems Manager Parameter Store. Non-compliant endpoints trigger a Lambda that terminates the endpoint and notifies the requester. This is a detective control, not preventive — endpoints run briefly before remediation. Appropriate for mature teams with low risk of data exfiltration during the remediation window.

4.5 License Compliance Tracking

Commercial Marketplace models (e.g., Mistral commercial license, Cohere enterprise tier) have EULAs that restrict use cases (typically: no resale, no model distillation, no fine-tuning outputs for competing model training). AWS License Manager tracks entitlements:

# List all active Bedrock Marketplace license entitlements
aws license-manager list-received-licenses \
  --filters Name=ProductSKU,Values=bedrock-marketplace \
  --query 'Licenses[*].{Product:ProductName,Issuer:Issuer.Name,Status:Status,Expiry:Validity.End}' \
  --output table

For models that auto-renew subscriptions annually, set a calendar reminder 60 days before expiry to review whether usage justifies renewal. Bedrock Marketplace subscriptions with a software fee component auto-renew at the subscription anniversary unless explicitly cancelled.

5. Bedrock Custom Model Import

5.1 Architecture and Availability (GA October 2024)

Custom Model Import (CMI) allows importing externally trained model weights into Bedrock for serverless on-demand inference without managing ML instances. This is distinct from Marketplace endpoints: CMI models run on AWS-managed shared infrastructure and bill per inference unit (CMU), not per instance-hour.

Supported architectures at GA (October 2024):

  • Meta Llama 3.2 family (1B, 3B, 11B, 90B)
  • Mistral / Mixtral (7B, 8x7B)
  • Meta Llama 3.1 (8B, 70B) — added post-GA

Weight formats accepted: Hugging Face safetensors, PyTorch .pt/.bin. Weights are stored in S3; Bedrock loads and manages inference infrastructure.

5.2 CMU Billing Model

Custom Model Import uses Custom Model Units (CMUs) as the billing dimension. A CMU is an abstract compute resource unit. The number of CMUs required per model copy is determined at import time based on model architecture and quantization, not configurable by the customer.

Billing formula:

Total cost = (Running model copies) × (CMUs per copy) × (CMU rate/min) × (5-min windows / 60)

Billing occurs in 5-minute windows from the first successful inference call. If no inference occurs, no charge accrues (unlike Marketplace endpoints which bill continuously while running).

Key CMU cost inputs:

  • Running model copies — get from CloudWatch metric ModelCopy in the AWS/Bedrock namespace, dimension ModelId = arn:aws:bedrock:{region}:{account}:imported-model/{model-id}
  • CMUs per copy — get from GetImportedModel API response field customModelUnitsPerModelCopy
  • CMU version — get from GetImportedModel API response field customModelUnitsVersion; use this to look up the billing rate on the CMI section of the Bedrock pricing page

CMU rates are versioned — AWS may publish new CMU version rates as hardware generations evolve. Models imported with an older CMU version retain their rate until re-imported.

5.3 CUR Representation of CMI Inference

Custom Model Import inference appears under the AmazonBedrock product code with a CustomModelUnit usage type pattern:

{region}-CustomModelUnit-{cmu-version}-per-min

Example:

USE1-CustomModelUnit-v1-per-min

This means CMI costs are visible in standard Bedrock cost dashboards (unlike Marketplace endpoint hosting which appears under SageMaker). However, the CMU billing model — continuous compute charges measured in 5-minute windows — is fundamentally different from per-token billing. CMI costs cannot be compared directly to native Bedrock per-token costs without accounting for the throughput of the workload.

When CMI is more economical than Marketplace endpoints: CMI has no endpoint-running cost when idle — billing starts only when inference is invoked. A Marketplace endpoint on ml.g5.48xlarge ($16.29/hr) running at 5% utilization costs $1,170/month regardless of actual inference volume. CMI at equivalent scale would cost nothing at zero inference and scales with actual load.

When Marketplace endpoints beat CMI: High-throughput, latency-critical workloads where constant endpoint availability is required, and the model architecture requires a custom variant not yet supported by CMI’s architecture list (405B Llama, proprietary commercial models).

5.4 CMI vs. Marketplace: Decision Matrix

Dimension Custom Model Import Marketplace Endpoint
Idle cost Zero Full instance-hour charge
Billing unit CMU per 5-min window ML instance per hour
Model source Your own trained weights AWS Marketplace catalog
Architecture support Limited (Llama, Mixtral) Any model in catalog
Fine-tuning Own weights = full control Provider EULA restrictions
CUR product code AmazonBedrock AmazonSageMaker (hosting)
Provisioning time Minutes (S3 weights) 10–30 min (endpoint provisioning)
Scaling Automatic (AWS manages) Manual instance count adjustment

6. AWS EDP and Marketplace Model Discounts

6.1 What Counts Toward AWS EDP

The AWS Enterprise Discount Program (EDP) — now sometimes called the Private Pricing Agreement (PPA) — commits a customer to a minimum AWS spend over 1–5 years in exchange for a percentage discount applied to eligible services.

Native Bedrock inference (AmazonBedrock product code) counts toward EDP commitment. This includes all Claude, Nova, Llama, Mistral, Cohere, and AI21 models accessed via the native Bedrock on-demand or batch APIs.

Bedrock Marketplace endpoint infrastructure (AmazonSageMaker product code via HostingBedrock) counts toward EDP in the same way that general SageMaker ML instance usage counts — it is a first-party AWS infrastructure charge.

AWS Marketplace software subscription fees (AWSMarketplace product code) count toward EDP up to the cap negotiated in the agreement. Historically, Marketplace third-party purchases could retire up to 25% of the annual EDP commitment. Under the May 2025 policy update, only SaaS products fully deployed on AWS infrastructure qualify for commitment retirement — this covers Bedrock Marketplace model software fees (the inference runs on AWS), but products running on non-AWS infrastructure no longer qualify.

EDP discount does not apply to the software fee component of a Marketplace model at the AWS discount level. The discount is applied to the SageMaker hosting charge (first-party AWS infrastructure), not to the model provider’s software fee, which is a separate line item negotiated directly with the provider or accepted at list price through the Marketplace.

6.2 EDP Structuring for Bedrock-Heavy Workloads

If your projected Bedrock spend is substantial, negotiating EDP terms that explicitly include Bedrock inference is worth the effort. Specific guidance:

  1. Get Bedrock listed as an EDP-eligible service in the contract addendum. The default EDP eligible service list may not explicitly enumerate Bedrock. Request that bedrock:InvokeModel API calls be eligible.

  2. Model the split between native and Marketplace inference. Marketplace endpoint hosting (SageMaker) and native Bedrock inference are separate line items. Negotiate both as eligible services. The negotiated discount percentage can differ between SageMaker and Bedrock product codes.

  3. Marketplace software fees: negotiate a higher Marketplace cap. If you are running multiple commercial third-party models through Marketplace, the 25% cap on Marketplace commitment retirement may constrain your ability to burn EDP on software fees. Negotiate a higher cap (40–60% of annual commit) if Marketplace usage dominates your AI budget.

  4. Batch inference for EDP optimization. Bedrock Batch Inference pricing is 50% of on-demand rates and still counts toward EDP. For workloads that tolerate latency (evaluation pipelines, overnight batch processing, dataset annotation), routing through Batch API doubles the EDP dollar burn efficiency.

  5. Custom Model Import CMU charges count toward EDP under the AmazonBedrock product code. For organizations running extensively customized fine-tuned models at scale, CMI combined with EDP can yield effective token costs well below direct provider API list prices.

6.3 Which Models Qualify for EDP Discounts

Model / Service Product Code EDP Eligible? Notes
Claude Sonnet 4.6 (native Bedrock) AmazonBedrock Yes Counts at full negotiated Bedrock discount
Amazon Nova Pro AmazonBedrock Yes First-party, full discount applies
Mistral Large 3 (native on-demand) AmazonBedrock Yes Third-party via native Bedrock
Meta Llama 3.3 70B (native on-demand) AmazonBedrock Yes
Cohere Command R+ (native on-demand) AmazonBedrock Yes
Marketplace endpoint hosting (SageMaker) AmazonSageMaker Yes Infrastructure discount applies
Marketplace model software fee AWSMarketplace Up to cap Subject to 25% Marketplace cap
CMI inference (CMU billing) AmazonBedrock Yes Counts like native Bedrock
Bedrock Knowledge Base (OpenSearch) AmazonOpenSearch Depends Negotiate separately

7. Monitoring Marketplace Model Usage

7.1 CloudWatch Metrics: Native vs. Marketplace

Native Bedrock models: Metrics publish to the AWS/Bedrock namespace with the ModelId dimension. ModelId uses the provider/model format:

  • anthropic.claude-sonnet-4-6-v1:0
  • meta.llama3-70b-instruct-v1:0
  • mistral.mistral-large-2402-v1:0
  • amazon.nova-pro-v1:0

Available metrics in AWS/Bedrock:

  • Invocations — count of successful model invocations
  • InvocationLatency — end-to-end response time (ms)
  • InputTokenCount — tokens in prompt
  • OutputTokenCount — tokens in response
  • InvocationThrottles — throttle events (useful for quota monitoring)
  • InvocationClientErrors — 4xx errors
  • InvocationServerErrors — 5xx errors

Bedrock Marketplace models (SageMaker endpoint): The SageMaker endpoint metrics publish to the AWS/SageMaker namespace with EndpointName dimension. These metrics capture infrastructure performance, not model-level semantics:

  • Invocations — HTTP calls to the endpoint
  • InvocationLatency
  • InvocationsPerInstance
  • ModelLatency
  • OverheadLatency

For Marketplace models, there is no AWS/Bedrock namespace metric for InputTokenCount or OutputTokenCount — those are SageMaker endpoint metrics and do not carry token-level information. Token counting for Marketplace models requires application-level instrumentation (log the token counts returned in the Bedrock API response and push to CloudWatch custom metrics or your observability platform).

Custom Model Import: CMI inference metrics appear in AWS/Bedrock with ModelId set to the imported model ARN:

  • arn:aws:bedrock:{region}:{account}:imported-model/{model-id}

The ModelCopy metric is specific to CMI — it tracks the number of currently running model copies. Monitor this to understand CMU billing accumulation.

7.2 CloudWatch Alarms for Marketplace Cost Anomalies

Alarm: Unexpected Marketplace endpoint running (new endpoint detected)

import boto3

cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_alarm(
    AlarmName='BedrockMarketplace-UnexpectedEndpoint',
    AlarmDescription='SageMaker endpoint with bedrock marketplace tag detected',
    Namespace='AWS/SageMaker',
    MetricName='Invocations',
    Dimensions=[
        {'Name': 'EndpointName', 'Value': '*'},
    ],
    Statistic='Sum',
    Period=300,
    EvaluationPeriods=1,
    Threshold=1,
    ComparisonOperator='GreaterThanThreshold',
    TreatMissingData='notBreaching',
    AlarmActions=['arn:aws:sns:us-east-1:111122223333:ai-cost-alerts'],
)

A more reliable approach: AWS Config rule that triggers on SageMaker endpoint creation and checks for the sagemaker-sdk:bedrock: compatible tag. Use SNS notification to alert the AI governance team on any new Bedrock Marketplace endpoint creation.

Alarm: Idle Marketplace endpoint (running but no traffic)

cloudwatch.put_metric_alarm(
    AlarmName='BedrockMarketplace-IdleEndpoint-{endpoint_name}',
    AlarmDescription='Marketplace endpoint running with zero invocations for 4 hours',
    Namespace='AWS/SageMaker',
    MetricName='Invocations',
    Dimensions=[
        {'Name': 'EndpointName', 'Value': '{endpoint_name}'},
    ],
    Statistic='Sum',
    Period=3600,
    EvaluationPeriods=4,
    Threshold=0,
    ComparisonOperator='LessThanOrEqualToThreshold',
    TreatMissingData='breaching',
    AlarmActions=['arn:aws:sns:us-east-1:111122223333:ai-cost-alerts'],
)

Set this alarm for every Marketplace endpoint at provisioning time. An idle Marketplace endpoint on a large instance (ml.p4d.24xlarge) costs $32/hr. Four hours idle = $128 unintentional spend.

7.3 LiteLLM Routing to Marketplace Models

LiteLLM supports Bedrock Marketplace models with a specific model ID format that differs from native Bedrock models:

Native Bedrock models in LiteLLM:

# Format: bedrock/{model-id}
model = "bedrock/anthropic.claude-sonnet-4-6-v1:0"
model = "bedrock/meta.llama3-70b-instruct-v1:0"
model = "bedrock/mistral.mistral-large-2402-v1:0"

Bedrock Marketplace models in LiteLLM:

# Format: bedrock/bedrock/marketplace/{endpoint-arn} or the registered endpoint ARN
# The Marketplace endpoint ARN format:
model = "bedrock/arn:aws:bedrock:us-east-1:111122223333:marketplace/model-endpoint/{endpoint-name}"

Alternatively, use the Bedrock Converse API directly with the endpoint ARN as the modelId:

response = bedrock_runtime.converse(
    modelId="arn:aws:bedrock:us-east-1:111122223333:marketplace/model-endpoint/my-deepseek-endpoint",
    messages=[{"role": "user", "content": [{"text": "Hello"}]}]
)

LiteLLM cost tracking for Marketplace models requires manual price configuration — LiteLLM’s built-in token cost lookup table covers native Bedrock model IDs but not Marketplace endpoint ARNs. Configure a custom pricing entry:

# litellm_config.yaml
model_list:
  - model_name: bedrock-marketplace-deepseek
    litellm_params:
      model: "bedrock/arn:aws:bedrock:us-east-1:111122223333:marketplace/model-endpoint/deepseek-r1"
      input_cost_per_token: 0.0000014  # $1.40 per 1M input tokens (example)
      output_cost_per_token: 0.0000028 # $2.80 per 1M output tokens (example)

8. Model Provider Comparison for Enterprise Selection

8.1 Mistral Large 3 on Bedrock

Pricing (June 2026, US East): $0.50 input / $1.50 output per 1M tokens
Context window: 128K tokens
Release: December 2025 (Large 3 generation)

Mistral Large 3 on Bedrock is positioned as a mid-tier reasoning model for tasks where Claude Sonnet 4.6 ($3.00/$15.00) is price-prohibitive but Nova Pro ($0.80/$3.20) is insufficient in instruction-following fidelity. The 3x output cost advantage over Claude Sonnet makes it attractive for high-output generation tasks (code generation, document drafting) where the quality delta is acceptable.

When to use Mistral Large 3 over Claude Sonnet 4.6:

  • High-volume API calls where output token volume dominates cost
  • Multilingual generation (French, Spanish, Italian, German — Mistral’s native training strengths)
  • Code generation pipelines where Claude’s higher reasoning is not required
  • Workloads that were previously on Mistral Large 2 and can benefit from the 75% price reduction at similar capability

When to use Claude Sonnet 4.6 over Mistral Large 3:

  • Complex multi-step reasoning or tool use chains
  • Tasks requiring extended thinking / chain-of-thought at depth
  • Agentic workflows where reliability under distribution shift matters
  • Any context requiring tight alignment with specific format/style instructions

CUR usage type for Mistral Large 3 on Bedrock:

USE1-mistral.mistral-large-2502-v1:0-input-tokens
USE1-mistral.mistral-large-2502-v1:0-output-tokens

8.2 Meta Llama 3.3 70B on Bedrock

Pricing (June 2026, US East): $0.72 input / $0.72 output per 1M tokens (symmetric)
Context window: 128K tokens
Open weights: Yes (Meta Llama 3 Community License)

The symmetric input/output pricing makes Llama 3.3 70B predictable for budgeting — workloads with high output-to-input ratios (summarization, generation) benefit relative to asymmetrically priced models.

Batch inference pricing: $0.36/$0.36 per 1M tokens (50% reduction). For evaluation and annotation pipelines this is the strongest cost argument for routing open-weight inference through Bedrock rather than self-hosting.

Open weights advantage: The Meta Llama 3 Community License permits fine-tuning and commercial use for organizations under 700M monthly active users. Fine-tuned variants can be imported via Custom Model Import and run at CMU rates — potentially at significantly lower cost than native on-demand pricing for high-throughput workloads.

Fine-tuning path on Bedrock:

  1. Fine-tune on SageMaker Training Jobs or locally
  2. Export weights to S3 in safetensors format
  3. Import via bedrock:CreateModelImportJob
  4. Invoke via CMU-billed serverless inference

CUR usage type:

USE1-meta.llama3-3-70b-instruct-v1:0-input-tokens
USE1-meta.llama3-3-70b-instruct-v1:0-output-tokens

8.3 Amazon Nova Models: Pro/Lite/Micro Tier Guide

Nova models are first-party Amazon models with the most favorable EDP treatment (no Marketplace overhead, no software fee component) and the lowest per-token cost in the Bedrock catalog for their capability tier.

Nova pricing (June 2026):

Model Input ($/1M) Output ($/1M) Cache Read ($/1M) Best For
Nova Micro $0.035 $0.14 ~$0.009 High-volume classification, extraction, routing
Nova Lite $0.06 $0.24 ~$0.015 Multimodal (image + text), document processing
Nova Pro $0.80 $3.20 ~$0.20 Complex reasoning, agent orchestration
Nova Premier Contact AWS Contact AWS — Very large context, enterprise reasoning

Nova vs. Claude positioning:

  • Nova Micro at $0.035 input vs. Claude Haiku 4.5 at $1.00 input: 28x cheaper for equivalent simple tasks. Route classification and slot-filling to Nova Micro.
  • Nova Pro at $0.80 input vs. Claude Sonnet 4.6 at $3.00 input: 3.75x cheaper. Suitable for structured output generation where Claude’s superior instruction following is not required.
  • Nova Pro vs. Claude Opus 4.7 ($5.00 input): 6x cheaper. Only route to Opus when benchmark performance is a hard requirement.

Prompt caching for Nova: Nova models support prompt caching at ~75% reduction on cache read tokens. For agentic workflows with large system prompts or document contexts repeated across many calls, enabling prompt caching on Nova can reduce effective input costs to below $0.01/1M tokens.

8.4 Cohere Command R+ on Bedrock: RAG-Optimized Positioning

Pricing (June 2026, Bedrock on-demand): $3.00 input / $15.00 output per 1M tokens
Direct Cohere API pricing: $2.50 input / $10.00 output per 1M tokens
Context window: 128K tokens
Provisioned Throughput: ~$49.50/hr per model unit (no commitment)

Command R+ is specifically optimized for Retrieval-Augmented Generation: its training includes a documents parameter in the Cohere API that structures retrieved document chunks in a format the model understands for grounded generation. On Bedrock, this is accessed through the Converse API with a system prompt structure that replicates document grounding.

When Command R+ beats Claude or Nova for RAG:

  • Workloads where citation accuracy (attributing output to specific retrieved chunks) is a hard requirement
  • Enterprise search with heterogeneous document formats (the model was trained on varied document types)
  • Multilingual RAG where document language may differ from query language
  • High-throughput RAG with Provisioned Throughput to avoid on-demand price variability

When to use Claude or Nova instead:

  • RAG workloads where generation quality beyond accuracy is important (tone, nuance)
  • Agent-based RAG requiring complex tool use chains (Claude has a stronger tool use track record)
  • Cost-sensitive applications where Nova Pro at $0.80/$3.20 is sufficient

Cohere Embed 3 for vector embeddings:

  • Bedrock on-demand: $0.10 per 1M tokens (same as Cohere direct API)
  • Supports both English and Multilingual variants
  • For organizations already running Bedrock Knowledge Bases, Cohere Embed 3 is available natively without a separate Cohere account

CUR usage types for Cohere:

USE1-cohere.command-r-plus-v1:0-input-tokens
USE1-cohere.command-r-plus-v1:0-output-tokens
USE1-cohere.embed-english-v3-input-tokens

9. AI21 Labs on Bedrock

Jamba Large 1.7 pricing (Bedrock, June 2026): ~$2.00 input / $8.00 output per 1M tokens
Context window: 256K tokens (one of the largest in the Bedrock catalog)

AI21’s Jamba architecture is a hybrid SSM/transformer model that delivers faster inference and lower memory footprint than pure transformer models at equivalent parameter counts. The 256K context window is a meaningful differentiator for document analysis tasks.

Use case fit:

  • Very long document processing where context exceeds 128K (legal contracts, technical specifications, research reports)
  • Cost-competitive with Mistral Large 3 for generation tasks
  • Alternatives: Claude Sonnet 4.6 for superior quality at higher price, Amazon Nova Pro for lower cost at shorter context

10. Summary Reference Tables

10.1 Complete Provider Cost Comparison (Native Bedrock, June 2026)

Provider Model Input $/1M Output $/1M Context EDP Native
Amazon Nova Micro $0.035 $0.14 128K Yes
Amazon Nova Lite $0.06 $0.24 300K Yes
Amazon Nova Pro $0.80 $3.20 300K Yes
Anthropic Claude Haiku 4.5 $1.00 $5.00 200K Yes
Anthropic Claude Sonnet 4.6 $3.00 $15.00 200K Yes
Anthropic Claude Opus 4.7 $5.00 $25.00 200K Yes
Meta Llama 3.3 70B $0.72 $0.72 128K Yes
Mistral AI Mistral Large 3 $0.50 $1.50 128K Yes
Mistral AI Ministral 14B $0.20 $0.20 128K Yes
Mistral AI Devstral 2 123B $0.40 $2.00 128K Yes
Cohere Command R+ $3.00 $15.00 128K Yes
Cohere Embed 3 English $0.10 — — Yes
AI21 Jamba Large 1.7 ~$2.00 ~$8.00 256K Yes

10.2 Bedrock vs. Direct Provider API Price Delta

Model Bedrock $/1M Out Direct API $/1M Out Delta Verdict
Mistral Large 2 (legacy) $9.00 $6.00 +50% Migrate to Large 3
Mistral Large 3 $1.50 ~$1.50 ~0% Parity
Cohere Command R+ $15.00 $10.00 +50% Direct if no EDP gap
Meta Llama 3.3 70B $0.72 N/A (open weights) — Bedrock vs. Groq ($0.79) ~parity
AI21 Jamba Large ~$8.00 ~$8.00 ~0% Parity

10.3 CUR Product Code Reference

Spend Category product_code How to Identify
Native Bedrock inference AmazonBedrock line_item_usage_type LIKE '%-input-tokens'
Custom Model Import (CMU) AmazonBedrock line_item_usage_type LIKE '%CustomModelUnit%'
Marketplace endpoint hosting AmazonSageMaker line_item_usage_type LIKE '%HostingBedrock%'
Marketplace endpoint hosting (alt) AmazonSageMaker tag sagemaker-sdk:bedrock = compatible
Marketplace software fee AWSMarketplace line_item_product_code = 'AWSMarketplace'
Knowledge Base (OpenSearch) AmazonES Separate from model inference
Prompt caching (cache write) AmazonBedrock line_item_usage_type LIKE '%cache-write%'
Cross-region inference AmazonBedrock line_item_usage_type LIKE '%cross-region%'

Sources and References