Your teams are already using Claude. Moving to Amazon Bedrock gives your organization 3 things at once: unified visibility into every dollar spent on AI, 1 consistent policy for who can use what, and the security posture your IT and compliance teams require.
Claude Team and Enterprise plans work alongside Amazon Bedrock - not as a replacement, but as a complementary governance layer. Here's exactly what connects to Bedrock and what stays on Anthropic's infrastructure.
Team plan gives your organization centralized billing, admin controls, and usage visibility within Anthropic's platform. All Standard and Premium seats include Claude Code, which can route inference directly through your AWS Bedrock account - keeping sensitive code and context inside your AWS boundary.
Enterprise unlocks the full Bedrock integration story. Claude Code and Cowork both route inference through your AWS account - keeping all model traffic inside your security perimeter. Usage is billed at API rates on top of the seat fee, giving you complete visibility into what each team actually consumes.
Moving Claude to Bedrock isn't just a billing change - it's a shift in visibility and control across your entire organization.
See exactly how much each department, project, or application spends on Claude - broken out, reportable, and actionable.
Set per-team or per-application spending limits with automatic alerts before budgets are exceeded.
Decide which teams can access which Claude models. Enforce policies using the same identity system you already run.
Every request is captured and searchable - exportable and ready for your next security or compliance review.
Prompts, files, and responses never leave your AWS environment and are never used to train models.
Claude spend consolidates onto your AWS bill alongside every other service - no separate vendor contracts.
01—Cost Attribution
When AI usage is spread across individual subscriptions, finance can't report on it and managers can't manage it. With Claude on Bedrock, every dollar of AI spend is tied to a department, project, or application.
02—Spending Monitoring
AI usage can spike fast. ASCENDING deploys a spending monitoring agent in your environment that watches budget in real time, alerts your team before costs run over, and answers plain-English questions about spend.
03—Model Control
A support team answering FAQs does not need the same AI capability as an engineering team writing production code. Bedrock lets you align model access to actual need and eliminate unnecessary spend.
04—Governance Foundation
A Bedrock governance foundation gives every user the same policy framework: who can access AI, what they can do with it, and what it costs - managed by IT and operations without touching individual accounts.
05—Data Security & Privacy
Running Claude on Bedrock means AI processing happens inside your AWS account under your security policies. Sensitive prompts, files, and responses stay within your business boundary.
06—Best Practices
ASCENDING establishes the right foundation from day one: secure architecture patterns, internal data connectivity, Infrastructure as Code, and operational enablement for your teams.
ASCENDING uses automation and Infrastructure as Code to spin up your entire Bedrock governance framework within 3 business days - no lengthy professional services engagement, no manual configuration, no disruption to your teams in the process.
Our automated IaC templates deploy the complete governance framework into your AWS environment - wiring up your identity system, configuring team access policies, and activating cost attribution so every team's spend is visible from hour one.
We review your internal data sources and current application integrations, validate your security architecture to ensure all AI workloads stay inside your AWS boundary, and deploy the spending monitoring agent that watches your budget continuously.
Your operations team receives everything needed to manage the environment independently - runbooks, escalation paths, and a clear understanding of how to adjust policies and budgets as your AI usage evolves over time.
Because ASCENDING is both an AWS Premier Consulting Partner and an Anthropic partner, we can help unlock volume discount tiers tied directly to your monthly inference spending on Bedrock.
ASCENDING handles the full setup from your current Claude subscriptions to a governed, cost-attributed deployment on Amazon Bedrock.
Running Claude on Amazon Bedrock keeps model inference inside your AWS account, but it does not by itself answer who may use which model, what leaves the boundary, or what the spend is attributable to. These 6 rows summarise where governance has to be added.
| Governance question | What Jarvis adds on top of Bedrock |
|---|---|
| Who may call which model? | Azure EntraID identity mapped to per-model ACL entries, rather than a shared account-level Bedrock permission. |
| What data reaches the model? | Guardrails apply PII redaction and denied-topic filtering before the request leaves your boundary. |
| Where does spend come from? | Usage is attributed per identity and per team, so model cost is traceable to the workload that produced it. |
| What is retained? | Prompts, responses, and decisions are logged inside your own account for audit and SIEM ingestion. |
| Which clients are covered? | Any MCP-compatible client, so the same policy applies whether the caller is a copilot, an agent, or Jarvis Chat. |
| How is it procured? | Bedrock is consumed through your existing AWS account; Jarvis is licensed through AWS Marketplace alongside it. |
Governing Claude subscriptions is an identity and accounting problem more than an infrastructure one. These rows separate what Amazon Bedrock provides from what the governance layer in front of it adds, with every source named.
| Specification | Value |
|---|---|
| Model runtime | Amazon Bedrock, inference inside the customer AWS account |
| Data leaving the account | 0 bytes of prompt or response content |
| Caller identity | Azure EntraID via OpenID Connect Core 1.0; SAML 2.0 also supported |
| Authorization | OAuth 2.0 (RFC 6749), Bearer usage per RFC 6750 |
| Token format | JSON Web Token (RFC 7519) |
| Access granularity | 1 ACL entry per model, evaluated on every request |
| Cost attribution | Per identity and per team rather than 1 account-level total |
| Guardrails | 100+ prebuilt policies across 4 control layers, applied before the model call |
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred (RFC 8446) |
| Denial responses | HTTP 401 unauthenticated, HTTP 403 policy denial |
| Audit retention | Held in the customer account under existing retention policy — 0 vendor copies |
| Client coverage | Any MCP client; 6 named copilots supported out of the box |
| Zero-trust model | NIST SP 800-207 (2020) |
| AI governance model | NIST AI RMF 1.0 (2023) |
| Runtimes | 3 managed Kubernetes services — Amazon EKS, Azure AKS, Google GKE |
| Procurement | AWS Marketplace, 3 standard tiers, USD 18,000–60,000, plus private offers |
The governance model behind the table above, explained end to end: identity at the edge, policy at authorisation, and telemetry across every model and tool call in the estate.
The sequence below assumes Bedrock access already exists and the gap is control rather than connectivity. Each step is additive, so an existing Bedrock workload keeps working while governance is layered on.
Establish identity first. Connect Azure EntraID so every model call carries a real user or service identity rather than a shared key.
Scope model access. Write per-model ACL entries so teams reach only the Claude and Bedrock models their work requires.
Turn on guardrails. Enable PII redaction and denied topics so sensitive content is filtered before a request reaches the model.
Attribute usage. Route calls through the gateway so token consumption is recorded per identity and per team, not per account.
Review the trail. Feed the audit log into your existing SIEM and use it to tune policy before widening access.
The controls that matter for a regulated deployment are the ones applied before the request leaves your environment and the record kept after it returns.
These questions come up whenever a team compares consuming Claude directly against consuming it through Amazon Bedrock with a governance layer in front.
Bedrock keeps inference inside your AWS account, which solves the data-boundary question. It does not decide which employee may use which model, filter what is sent, or attribute spend to a team.
Those are identity and policy problems rather than infrastructure problems, which is why they are usually solved by a gateway in front of Bedrock rather than by Bedrock configuration.
Calls carry the caller’s identity, so token consumption is recorded per user and per team rather than aggregated at the account level.
That is normally the first reporting requirement finance asks for once more than 1 department is using the same model access.
Guardrails inspect the request before it leaves your environment, applying PII redaction and denied-topic filtering according to the policy in force for that caller.
Because the check runs on the way out rather than at the model, the same policy covers every client — copilots, agents, and chat alike.
Yes. The gateway fronts multiple model providers, so a team can use Claude on Bedrock for one workload and a different model for another without changing how access is governed.
Policy is written against identities and models, not against a single provider, so adding a model is a configuration change rather than a re-architecture.
Model governance sits inside the wider platform. These pages cover the layers it depends on.
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. The primary sources below cover the model runtime and the control frameworks referenced above.
