When AI Access Becomes an Exercise in Irony: Navigating Anthropic's Partner Gating on AWS Bedrock

How a well-intentioned reseller programme accidentally became the best argument for creative cloud architecture

---

If you’re an AWS partner who’s recently tried to enable Anthropic models on Bedrock for a customer, you might have encountered a peculiar situation: the models that promise to make everything easier have become surprisingly difficult to access. Welcome to the club. Pull up a chair. We’ve been here since November.

The Setup

In October 2025, AWS announced that Amazon Bedrock was now available for partner resale. Excellent news, you’d think — more routes to market, more flexibility for customers, everyone wins. Except there was a catch. For Anthropic models specifically, partners must now apply to the Anthropic Authorized Reseller Program, a process reviewed directly by Anthropic on a “rolling basis.”

Rolling, in this context, appears to mean “when they get around to it, depending on the size of your pipeline.”

The result? Customers who could previously enable Claude models with a few clicks in their own AWS accounts now face an indefinite wait if they happen to be transacting through a partner. The same models. The same AWS account. The same use case. But add a partner to the billing relationship and suddenly you need approval from a company that, somewhat ironically, built its reputation on making AI more accessible to everyone.

The Real-World Impact

Let me paint you a picture that’s probably familiar if you’re reading this.

A customer builds a proof of concept using Anthropic models on Bedrock. It works brilliantly. They’re excited. They want to move to UAT, then production. They’ve done the work, validated the approach, and have genuine business demand.

Then they discover they can’t enable the models in their production account because it’s billed through their partner. The development account? That was set up before the policy change, so it works fine. The production account?

The customer now has three options:

1. Wait for an approval process with no SLA, no transparency, and no clear timeline
2. Move to direct billing with AWS — or worse, set up an entirely separate account outside the Organisation — abandoning the commercial relationship that probably includes committed spend discounts, consolidated billing, and support arrangements. Either way, you’re defeating the entire purpose of centralised billing and governance
3. Get creative with their architecture

We chose door number three.

The Workaround: Cross-Account Inference

Right, enough complaining. Here’s where this becomes actually useful.

If you have Anthropic models working in one AWS account within your Organisation but not another, you don’t have to wait for Anthropic to notice your existence. You can use cross-account inference to access Bedrock from workload accounts that can’t enable models directly.

The Silver Lining: Is This Actually Better Architecture?

Here’s the thing — what started as a workaround could be considered a genuinely superior pattern. Centralising Bedrock access in a dedicated account isn’t just a hack around a business process problem; it’s arguably how you should be doing this anyway.

Security Benefits:

Aspect	Distributed (Per-Account)	Centralised (Cross-Account)
Model Access Control	Enabled in every account — larger attack surface	Single account — one place to manage
IAM Governance	Bedrock permissions scattered across accounts	Centralised role with explicit trust relationships
Audit Trail	CloudTrail logs spread across accounts	All inference calls logged in one account
Cost Visibility	Usage buried in individual account bills	Clear, consolidated view of AI spend
Prompt Logging	Configure per-account	Single configuration, consistent policy
Data Exfiltration Risk	Any account with model access could be compromised	Only the Bedrock account needs hardening

Principle of Least Privilege:

With the distributed model, you’re granting bedrock:InvokeModel permissions to roles across your entire Organisation. With the centralised model, workload accounts only get sts:AssumeRole to a single, purpose-built role. The Bedrock permissions themselves are isolated in one account with explicit, auditable trust relationships.

If a workload account is compromised, the attacker can only access Bedrock if they can also satisfy the trust policy conditions — Organisation ID, specific role ARNs, and any additional conditions you’ve added. It’s defence in depth, delivered accidentally by a bureaucratic inconvenience.

Guardrails and Governance:

Centralising Bedrock access gives you a natural chokepoint for implementing guardrails:

• Bedrock Guardrails configured once, applied to all inference
• Prompt logging to S3 or CloudWatch in a single, secured location
• Cost controls and usage quotas in one place
• Model access decisions made centrally rather than per-account

You can even implement a service control policy (SCP) that prevents workload accounts from enabling Bedrock directly, ensuring all access flows through your governed, centralised account. Combine this with VPC endpoints and PrivateLink, and you’ve got all your AI inference traffic staying entirely within the AWS network — no internet egress, no data leaving your controlled environment.

More on this to come in a future post…maybe.

The Architecture

┌─────────────────────────────────────────────────────────────────┐
│                      AWS Organisation                           │
│                                                                 │
│  ┌─────────────────────┐        ┌─────────────────────────┐    │
│  │  Workload Account   │        │  Bedrock Account        │    │
│  │  (Models blocked)   │        │  (Models working)       │    │
│  │                     │        │                         │    │
│  │  ┌───────────────┐  │  STS   │  ┌───────────────────┐  │    │
│  │  │ Application   │──┼────────┼─▶│ Cross-Account     │  │    │
│  │  │               │  │        │  │ Bedrock Role      │  │    │
│  │  └───────────────┘  │        │  └─────────┬─────────┘  │    │
│  │                     │        │            │            │    │
│  └─────────────────────┘        │            ▼            │    │
│                                 │  ┌───────────────────┐  │    │
│                                 │  │ Anthropic Models  │  │    │
│                                 │  │ (Claude, etc.)    │  │    │
│                                 │  └───────────────────┘  │    │
│                                 │                         │    │
│                                 └─────────────────────────┘    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The workload account assumes a role in the account where Bedrock is enabled, then makes inference calls using those temporary credentials. Billing still flows correctly, CloudTrail logs are maintained, and your customer can actually use the service they’re paying for.

The Technical Implementation

In the Bedrock-enabled account, create a role with a trust policy allowing your workload account to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "*" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-yourorgid"
        },
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::WORKLOAD_ACCOUNT:role/YourAppRole"
        }
      }
    }
  ]
}

And a permissions policy for Bedrock access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeInferenceProfile",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*:BEDROCK_ACCOUNT:inference-profile/*"
      ]
    },
    {
      "Sid": "InvokeFoundationModels",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/*"
      ]
    }
  ]
}

In the workload account, grant your application role permission to assume the cross-account role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::BEDROCK_ACCOUNT:role/BedrockCrossAccountRole"
    }
  ]
}

In your application code, assume the role before making Bedrock calls:

import boto3
import json

def get_bedrock_client(bedrock_account_id, role_name, region):
    sts = boto3.client('sts')
    assumed = sts.assume_role(
        RoleArn=f"arn:aws:iam::{bedrock_account_id}:role/{role_name}",
        RoleSessionName="BedrockInference"
    )
    creds = assumed['Credentials']
    return boto3.client(
        'bedrock-runtime',
        region_name=region,
        aws_access_key_id=creds['AccessKeyId'],
        aws_secret_access_key=creds['SecretAccessKey'],
        aws_session_token=creds['SessionToken']
    )

client = get_bedrock_client("123456789012", "BedrockCrossAccountRole", "eu-west-2")

A Word on Inference Profiles

If you’re using inference profiles for cross-region resilience, here’s a lesson I learned the hard way: use regional profiles, not global ones.

Profile Type	Example	Behaviour
Regional (eu.*)	eu.anthropic.claude-sonnet-4-5-*	Routes within EU regions — predictable and reliable
Regional (us.*)	us.anthropic.claude-sonnet-4-5-*	Routes within US regions — predictable and reliable
Global (global.*)	global.anthropic.claude-sonnet-4-5-*	Routes anywhere — can fail intermittently if model isn’t available in the selected region

I spent a pleasant evening debugging why requests worked sometimes and failed other times with misleading error messages about AWS Marketplace permissions. The culprit? A global inference profile routing some requests to regions where the model wasn’t fully available.

CloudTrail is your friend here. Successful requests show an inferenceRegion in the event data; failed requests don’t even get that far.

The Broader Point

Let’s step back from the technical solution and address the elephant in the room.

This shouldn’t be necessary.

AWS partners aren’t nessessarily trying to resell inferences or monetise Anthropic models independently. We’re trying to help customers use AWS services for their business and customers. The goal is enablement, not exploitation.

The current process requires partners to:

1. Submit an application to Anthropic’s reseller programme
2. Wait for review on a “rolling basis” (translation: indefinitely)
3. For blocked opportunities, raise ACE opportunities and submit escalation forms
4. Hope someone notices

Meanwhile, customers wonder why they can’t use a service that works perfectly fine when they’re not transacting through a partner. They start questioning the value of the partnership. They consider alternative models.

The competitive risk isn’t hypothetical. When you tell a customer “we need to wait for Anthropic to approve us before you can use Claude in production,” they don’t think “what a reasonable governance process.” They think “maybe I should just use a different model.”

And here’s the irony that really stings: Anthropic’s stated mission is to develop AI that is safe, beneficial, and understandable. Gating access through a bureaucratic process that provides no timeline, no transparency, and no apparent logic doesn’t make AI safer — it just makes it harder to use legitimately while doing nothing to prevent misuse.

What Would Actually Help

If anyone from Anthropic happens to read this (hello!), here are some suggestions:

1. Provide timelines. “Rolling basis” isn’t a timeline. Partners need to set expectations with customers.

2. Differentiate use cases. A partner enabling a customer’s own AWS account to use Bedrock is fundamentally different from a partner reselling inference API calls. The current process treats them identically.

3. Consider the customer impact. The partners aren’t the ones being hurt here — it’s the end customers who chose to work with AWS partners for good reasons and are now penalised for that choice.

4. Trust the AWS relationship. If a customer has an AWS account, has agreed to AWS terms, and wants to use a service available on AWS, additional gating through a third party adds friction without obvious benefit.

5. Consider the innovation barrier. This process is hindering innovation for customers who just want to try the model to determine their use case. If this were for an AI-specialised partner looking to resell a tonne of inference, or a customer seeking reserved capacity for an already-validated MVP — fair enough. But it seems to be penalising the very customers and partners who aren’t already doing millions of tokens and racking up massive Bedrock bills. You’re making it hardest for the people at the beginning of their AI journey, when friction matters most.

Conclusion

Cross-account inference is a legitimate architectural pattern I haven’t read about or considered until now which happens to also solve a problem it was never designed for. It lets customers continue their cloud journey while the partnership approval process does… whatever it’s doing.

But here’s the twist: what started as a workaround could actually be a better pattern. Centralised Bedrock access gives you improved security posture, consolidated governance, cleaner audit trails, and easier cost management. We’ve accidentally architected ourselves into what might just be a more secure, more manageable solution?

Is it ideal that we had to do this? No. Should customers have to architect around business process limitations? Also no. But sometimes constraints breed innovation, and this particular constraint pushed us toward a pattern I’ll be building on more regardless of whether the partner approval process ever gets sorted.

If you’re a partner in the same situation, I hope this helps. If you’re at Anthropic, I hope this provides some perspective on how the current process affects the ecosystem — and maybe a small acknowledgment that your partners are pretty good at solving problems, even the ones you create for them. And if you’re a customer caught in the middle of this, I’m sorry — you deserve better, but at least you’re getting better architecture out of it.

In the meantime, we’ll keep building workarounds. It’s what partners do.

---

Have you encountered similar challenges with Bedrock partner access? Found other creative solutions? Implemented cross-account inference for the security benefits rather than just necessity? I’d love to hear about it.