Claudeの利用経路について整理してみた
こんにちは、クラスメソッドの長澤です。
2026年に入ってからAWSとAnthropicの提携が拡大し、Claudeの利用経路が増えてきました。「Bedrock経由」「Claude Platform on AWS」「Anthropic直契約」「AWS Marketplace」……と選択肢が並ぶと、「結局どれを使えばいいの？」と迷ってしまいます。
本記事では、Claudeを利用する経路について、公開情報をもとに判断軸を絞って整理します。
前提：2026年8月時点の公開情報に基づく机上整理です
本記事の内容は、2026年8月時点でAWS・Anthropicが公開しているドキュメントに基づいています。実機での検証は行っておらず、あくまで公開情報の突き合わせによる机上の整理です。
料金体系やサービス内容は変更される可能性があるため、実際の導入検討の際は必ず各公式ドキュメントで最新情報をご確認ください。
選択肢は「4経路」ではなく「3経路＋契約レイヤー」
Claudeの利用経路というと「Bedrock」「Claude Platform on AWS」「Anthropic直契約」「AWS Marketplace」の4つが並列に語られがちです。
ただし、調べていくとAWS Marketplaceは他の3つと少し性質が異なることが分かります。Claude Platform on AWSの請求自体がAWS Marketplace経由ですし、Bedrockの大口契約もAWS Marketplaceのプライベートオファーという形を取ります。
つまりAWS Marketplaceは、独立した「経路」というより、他の経路に横串で関わる契約・請求の器と捉えた方が実態に近そうです。
次のとおりです。
| 経路 | APIの入口 | 推論の運用者 | 請求先 |
|---|---|---|---|
| Amazon Bedrock | bedrock-runtime または bedrock-mantle |
AWS | AWS |
| Claude Platform on AWS | Claude Platform on AWSエンドポイント | Anthropic | AWS（Marketplace経由） |
| Anthropic直契約 | Anthropic API / claude.ai | Anthropic | Anthropic |
請求先だけを見るとBedrockとClaude Platform on AWSはどちらも「AWSに支払う」形になりますが、推論を実際に運用しているのはBedrockがAWS、Claude Platform on AWSがAnthropicと異なります。請求先が同じでも、データが誰の管理下で処理されるかは別問題という点は、後述の判断軸1で効いてきます。
AWS Marketplaceのプライベートオファーは、BedrockとClaude Platform on AWSの2経路に横串で関わる契約形態として、後ほど軸3でまとめて扱います。なおAnthropic直契約にも、後述のとおり大口向けの個別交渉自体は存在します。
判断軸は3つに絞れる
3経路を比較する際の観点はいろいろ挙げられますが、実務上は次の3つの判断軸に絞れそうです。
- データを誰が処理するか（データプロセッサとコンプライアンス認定範囲）
- 必要な機能がそのエンドポイントで使えるか
- 実効コストと調達をどう最適化するか
この3つは順番にも意味があります。軸1は規制要件による足切り、軸2は機能要件による絞り込み、軸3はそこから先のコスト最適化です。
多くの組織は軸1の時点である程度決着し、そこで決まらない場合だけ軸2・軸3に進むことになりそうです。
軸1：データを誰が処理するか
データプロセッサはBedrockがAWS、Claude Platform on AWSはAnthropic
まず大前提として、3経路でデータを処理する主体（データプロセッサ）が異なります。
BedrockはAWSがデータプロセッサとなり、AWSの責任範囲内で処理が完結します。一方Claude Platform on AWSは、AWSのWhat's Newに次のように明記されています。
Claude Platform on AWS is operated by Anthropic, and customer data is processed outside the AWS security boundary.
Claude Platform on AWSはAnthropicが運用しており、データはAWSのセキュリティ境界の外で処理されるということです。AWSアカウントで認証・請求は完結しますが、推論そのものはAnthropic側で行われます。
Anthropic直契約はそのままAnthropicがデータプロセッサです。
ゼロデータ保持の扱いは直感と逆になっている
「Anthropicのネイティブなプラットフォームなのだから、Anthropicのデータ保護プログラムも使いやすいはず」と考えたくなりますが、ゼロデータ保持（ZDR）についてはむしろ逆の構造になっています。
Bedrockは、AWSがデータプロセッサとしてAnthropicの推論入出力を保持しない構成のため、ZDRプログラムへの申請自体が不要です。Claude Opus 5はBedrock上でZDRがデフォルトで有効になっています。
一方Claude Platform on AWSでは、Anthropicが独立したデータプロセッサとなるため、ZDRは申請ベースのオプトインという扱いです。
「AnthropicネイティブなプラットフォームだからAnthropic寄りのデータ保護が手厚い」という直感は、ここでは当てはまらないようです。
コンプライアンス認定は「対象サービス」と「対象モデル」が別
規制要件が絡む場合、サービス単位の認定とモデル単位の対象範囲は別物という点に注意が必要です。
AWSのFedRAMP HighやDoD CC SRG IL4/IL5の対象モデル一覧を確認すると、Claude Opus 4.8やClaude Sonnet 5は含まれていますが、Claude Opus 5はこの一覧に入っていません。Claude Opus 5がAWS GovCloud (US)で利用可能になったというアナウンスは別途ありますが、GovCloudで動くことと、FedRAMP High／IL4/IL5の認定範囲に入っていることは別の話と考えられます。
HIPAA対象サービスの一覧でも、Bedrockは次のような注記付きで掲載されています。
Amazon Bedrock [excluding Fable and Mythos models]
つまりClaude Fable 5とClaude Mythos 5はHIPAA対象から除外されています。「Bedrockだから規制対応も一律に大丈夫」ではなく、利用するモデル単位で対象範囲を確認する必要がありそうです。
なお、Anthropic公式ドキュメントでは、Bedrockを選ぶべきケースとして次のように述べられています。
Organizations in regulated industries that require FedRAMP High, IL4, IL5, or HIPAA-ready compliance, or that need AWS to be the sole data processor, should use Claude in Amazon Bedrock.
規制要件が厳しい組織や、AWSを唯一のデータプロセッサにしたい組織は、まずBedrockを検討するのが素直な選択と言えそうです。ただしその場合も、前述のとおり対象モデルの確認は欠かせません。
PrivateLinkはどちらも利用できる
VPCからの接続についても確認しました。Anthropic公式ドキュメントには次の記載があります。
AWS PrivateLink is supported for connecting your VPC to the Claude Platform on AWS endpoint.
Claude Platform on AWSのエンドポイントへのAWS PrivateLink接続は、公式に対応が明記されています。Bedrock側も従来からVPCエンドポイントに対応しているため、通信経路を閉域化できるかという点ではBedrockとClaude Platform on AWSの間に大きな差はなさそうです。
ただし、これは「通信経路を閉域化できるか」の話であり、前述の「データを誰が・どこで処理するか」という論点とは別物です。PrivateLinkで接続を閉域化しても、Claude Platform on AWSではデータ処理そのものがAWSセキュリティ境界の外で行われる点は変わりません。
表：データ処理とコンプライアンスの比較
ここまでの内容を整理すると、次のとおりです。
| 観点 | Bedrock | Claude Platform on AWS | Anthropic直契約 |
|---|---|---|---|
| データプロセッサ | AWS | Anthropic | Anthropic |
| PrivateLink（VPCからの接続） | ○ | ○ | × |
| ゼロデータ保持（ZDR） | 申請不要（Opus 5はデフォルト有効） | 申請ベースのオプトイン | プランによる |
| FedRAMP High・IL4/IL5 | △（モデルにより対象外あり） | × | × |
| HIPAA対応 | △（Fable/Mythosは対象外） | ×（非対応と明記） | プランによる |
| 学習利用 | なし | なし | なし（有料プラン・API） |
△は「対象ではあるものの、モデル単位で範囲外がある」ことを意味します。学習利用の行だけは「なし」が望ましい状態なので、誤読を避けるためにあえて記号ではなく文字で書いています。
この表を見る限り、規制要件が厳しい場合はBedrockが有力な選択肢になりますが、「Bedrockだから安心」で終わらせず、利用するモデル単位での確認が欠かせないと考えられます。
軸2：必要な機能がそのエンドポイントで使えるか
Claude Platform on AWSで使えない機能がある
「Anthropicの最新機能をいち早く使いたいならClaude Platform on AWS」というイメージを持たれがちですが、Anthropic公式ドキュメントには、Claude Platform on AWSで使えない機能として次が明記されています。
- HIPAA対応プログラム
- computer toolset・browser toolset
- Fast mode
新機能へのアクセスは速い一方で、一部の機能はそもそも対象外という点は見落とされやすいポイントだと感じました。
表：経路別の機能可用性
Bedrockについても、実は内部に2つのエンドポイントがあります。ConverseやInvokeModelを使う従来のbedrock-runtimeと、Anthropic Messages API互換のbedrock-mantleです。
この2つでも使える機能に差があります。
次のとおりです。
| 機能 | bedrock-runtime | bedrock-mantle | Claude Platform on AWS | Anthropic直API |
|---|---|---|---|---|
| Guardrails・Knowledge Bases・Agents・Flows | ○ | × | × | × |
| Anthropic Messages API互換 | × | ○ | ○ | ○ |
Count tokens（Anthropic互換の/v1/messages/count_tokens） |
× | ○ | ○ | ○ |
| Structured outputs | × | × | ○ | ○ |
| computer・browser toolset | 未確認 | 未確認 | × | ○ |
| Fast mode | 未確認 | 未確認 | × | ○ |
| Claude以外のモデル | ○ | × | × | × |
| 新機能の提供速度 | △ | △ | ○ | ◎ |
一次情報で対応状況を確認できなかったセルは、推測で埋めず「未確認」としています。
なおbedrock-runtimeには、上記とは別にネイティブのCountTokens API（AWS公式リファレンス）が用意されています。表の行はAnthropic Messages API互換の/v1/messages/count_tokensに対応しているかどうかを指しており、bedrock-runtime独自のトークン計数機能がないという意味ではありません。
この表から分かるのは、どの列も全部○にはならない、つまりどれか1つの経路がすべての機能で上位互換になっているわけではないということです。「Bedrockを選べば機能面で困らない」わけでも、「Claude Platform on AWSを選べば最新機能に全部アクセスできる」わけでもなく、必要な機能から逆算して経路を選ぶ必要がありそうです。
また、「Bedrockなら Guardrails や Knowledge Bases が使える」という理解も、正確には**bedrock-runtimeを使う場合に限った話**です。Anthropic Messages API互換のbedrock-mantleを使う場合、これらの機能は使えません。
Bedrockを選んだつもりでも、どちらのエンドポイントを使うかで機能が変わる点には注意が必要です。
軸3：実効コストと調達をどう最適化するか
トークン単価は概ね同水準だが同額とは言い切れない
「どの経路でもトークン単価は同じ」という理解をよく見かけますが、調べてみると、無条件に断定できるものではなさそうです。
理由は3つあります。
- Bedrockのリージョナル／マルチリージョンエンドポイントには、グローバルエンドポイントに対して10%のプレミアムがかかります（Claude Sonnet 4.5以降）
- 最新世代のClaudeは、BedrockでもAWS Marketplace経由の第三者モデル課金に移行しており、AWSのBedrock Pricingページ自体にClaude Opus 5・Sonnet 5・Opus 4.8・Haiku 4.5の単価が掲載されていません
- 後述するSonnet 5の恒久価格が、Bedrock側にもそのまま適用されるのか、AWSの一次情報では確認できませんでした
このため、「Bedrock・Claude Platform on AWS・Anthropic直契約のトークン単価はグローバルエンドポイント同士であれば概ね同水準」というくらいの表現に留めるのが、現時点では正確そうです。AWSによる明確なマークアップがあるとは確認できませんでしたが、「同額でマークアップなし」と断定できる一次情報も見当たりませんでした。
Sonnet 5の値上げは撤回されている
Anthropic直契約（第一者API）の料金は、次のとおりです。
| モデル | 入力（/1Mトークン） | 出力（/1Mトークン） |
|---|---|---|
| Claude Fable 5 | $10.00 | $50.00 |
| Claude Opus 5 | $5.00 | $25.00 |
| Claude Opus 4.8 | $5.00 | $25.00 |
| Claude Sonnet 5 | $2.00 | $10.00 |
| Claude Haiku 4.5 | $1.00 | $5.00 |
Claude Sonnet 5は当初、$2/$10を導入価格として、2026年9月1日から$3/$15に値上げされる予定でした。しかしAnthropic公式のPricingドキュメントには、次の注記が追加されています。
The $2/$10 per million input/output token pricing for Claude Sonnet 5 ... is now the standard price. The previously scheduled increase to $3/$15 per million input/output tokens on September 1, 2026 will not occur.
つまり、この値上げは撤回され、$2/$10が恒久価格になっています。もし2026年前半の時点で「9月から値上げされる」という前提でコスト試算をしていた場合は、見直しておいた方がよさそうです。
なお、この表はAnthropic第一者APIの料金です。BedrockやClaude Platform on AWSでこの単価がそのまま適用されるかどうかは、前述のとおり確認できていません。
割引の効き方はバッチ・キャッシュ・コミットの3系統
コストを抑える仕組みは、大きく3系統に分けられそうです。
- バッチ推論：入力・出力とも50%割引。Anthropic直APIとBedrockの両方で提供
- プロンプトキャッシュ：5分キャッシュの書き込みは1.25倍、1時間キャッシュの書き込みは2倍のコストがかかる一方、キャッシュヒット時は0.1倍（90%割引）
- コミットメント契約：AWSのEDP/MACC消化やAWS Marketplaceのプライベートオファー
バッチとキャッシュは併用でき、割引は乗算で効きます。ただし、Claude Managed Agentsのようなステートフルなセッションには、バッチ割引が適用されない点は覚えておいた方がよさそうです。
Sonnet 5はBedrockのバッチ推論に対応していない
割引の仕組みを使う際に、1点注意が必要な事実がありました。AWSのバッチ推論対応モデル一覧に、Claude Sonnet 5は含まれていません。
対応しているのはClaude Opus 5・Opus 4.6・Opus 4.5・Sonnet 4.6・Sonnet 4.5・Haiku 4.5などです。
「Bedrockならバッチ推論で半額」という前提でSonnet 5のコストを試算すると、その前提自体が成立しないことになります。利用するモデルとバッチ推論の対応状況は、セットで確認する必要がありそうです。
新トークナイザで同一テキストのトークン数が増えている
単価だけを比較する際に見落としやすい点として、トークナイザの変更があります。Claude 4.7以降のモデルでは新しいトークナイザが採用されており、Sonnet 4.6以前の旧トークナイザと比べて、同じテキストでも約30%多くのトークン数になるとされています。
つまり、モデル世代をまたいだ移行では、単価の比較だけでなく、同じ処理に必要なトークン数自体が変わる可能性を考慮しないと、実効コストを見誤ることになりそうです。
Claude Platform on AWSの課金単位はCCU
Claude Platform on AWSの課金は、トークン単価そのものではなく、**CCU（Claude Consumption Unit）**という単位を介して行われます。CCU単価は$0.01固定で、次の流れでメータリングされます。
- トークン使用量をAnthropicが定める標準レートでUSD換算（個々のモデルについてAnthropic直APIの単価と完全に一致するかは、前述のとおり一次情報では確認できていません）
- 割引を適用
- USD金額をCCUに変換
- 毎時、AWS Marketplaceにメータリング
ここで押さえておきたいのは、割引はCCU単価そのものを下げるのではなく、メータリングするCCU数を減らす形で効くという点です。請求書上はCCUの明細として見えるため、トークン単価ベースの試算と突き合わせる際は変換の手順を意識しておく必要があります。
既存のプライベートオファーは自動では引き継がれない
すでにBedrockでAWS Marketplaceのプライベートオファーを結んでいる組織がClaude Platform on AWSへの移行を検討する場合、1点注意が必要です。Anthropic公式ドキュメントには、既存のプライベートオファーはClaude Platform on AWSへ自動的には引き継がれないと明記されています。
Claude Platform on AWSにサインアップする前にAWS・Anthropic双方の担当者に連絡する必要があり、割引はオファーが承諾された時点から適用され、遡及はされません。先にサインアップしてしまってから交渉すると、その間の利用分は割引対象外になる可能性があるということです。
順序を間違えると、そのまま金額差になりかねません。
利用上限はレート制限と月次スペンドキャップのセットになっている
もう1点、運用面での違いとして、Claude Platform on AWSではAnthropic直APIの使用量ティアによる自動昇格が適用されないという記載がありました。
Anthropicの利用上限は「Usage tier」という階段状の仕組みで管理されており、各ティアにはレート上限（RPM/TPM）と月次のスペンドキャップ（その月にAPIへ使ってよい金額の上限）がセットで紐づいています。ティアが上がれば両方が同時に上がる、という構造です。
次のとおりです。
| Usage tier | 月次スペンドキャップ |
|---|---|
| Start | $500 |
| Build | $1,000 |
| Scale | $200,000 |
| Customer | 個別交渉（上限なし） |
Claude Platform on AWSの新規組織は、まずStartティア（月次$500）に配置されます。第一者APIであれば使用実績に応じて自動的にBuild・Scaleへ昇格しますが、Claude Platform on AWSではこの自動昇格が適用されないため、Startティアの$500に張り付いたままになります。
引き上げたい場合はAnthropic担当者・サポートへの連絡が必要で、第一者API側にあるConsoleのセルフサービス申請フローは提供されていません。
スペンドキャップは暦月ベースで管理され、到達すると翌月まで新規リクエストが止まります。なお利用量の集計には数時間の反映遅延があり、キャップ到達の直前に通ったリクエスト分はそのまま課金される点にも注意が必要です。
なお、これとは別に、組織やワークスペース単位で任意に設定するスペンドリミットという機能もあります。こちらについてはAWSの公式ドキュメントとAnthropicの公式ドキュメントで「利用できる」「利用できない」という正反対の記載があり、食い違いが解決できていません。
強制的なティアキャップ（Startなら$500）とは別の機能なので、混同しないよう注意が必要です。
Bedrockについては、同種の月次金額キャップに関する記載を一次情報の範囲では見つけられませんでした。BedrockはAWS Service Quotasでレート・トークン数のクォータを管理しており、少なくとも公開ドキュメント上は金額ベースの上限という形では説明されていないようです。
PoCから本番運用へスケールする際、Claude Platform on AWSではこのStartティアの$500という上限がボトルネックになりやすいため、早い段階でAnthropic担当者へ相談しておいた方がよさそうです。
表：コストと調達に関わる要素の比較
ここまでの内容を整理すると、次のとおりです。
| 観点 | Bedrock | Claude Platform on AWS | Anthropic直契約 |
|---|---|---|---|
| EDP/MACC消化 | ○ | ○ | × |
| バッチ割引 | △（モデルにより対象外） | 未確認 | ○ |
| プロンプトキャッシュ | ○ | ○ | ○ |
| エンドポイント種別による価格差 | あり（リージョナルは10%プレミアム） | CCU換算を経由 | なし |
| 割引の交渉 | Marketplaceプライベートオファー | Marketplaceプライベートオファー | 個別交渉（Anthropicセールス） |
| 月次利用上限（スペンドキャップ） | 金額キャップの記載を確認できず | あり（Startティア＝$500/月から開始、自動昇格なし） | あり（同額のティア制、使用実績で自動昇格） |
| レート上限の引き上げ | AWSのクォータ申請 | セルフサービス不可（担当者経由） | 使用量に応じ自動昇格 |
Marketplaceのプライベートオファーによる割引率については、AWS・Anthropicいずれの公式ドキュメントにも具体的な割引率や取引額の目安は記載されていませんでした。「個別交渉」という以上の定量的な情報は、現時点では確認できていません。
サブスクリプションはAPIとは別軸で考える
ここまではAPI経由の利用を前提に整理してきましたが、claude.aiやClaude Codeの利用は、API経路の議論とは別軸で考えた方が整理しやすそうです。
Anthropic直契約には、従量課金のAPIとは別に、次のようなサブスクリプションプランがあります。
| プラン | 月払い | 年払い時（月あたり） | 概要 |
|---|---|---|---|
| Free | $0 | - | 基本的な利用。レート制限あり |
| Pro | $20 | $17（$200を一括前払い） | 5倍の利用量、全モデルへのアクセス |
| Max 5x | $100 | - | Proの5倍の利用枠 |
| Max 20x | $200 | - | Proの20倍の利用枠 |
| Team（Standard seat） | $25/席 | $20/席 | 組織管理、共有ワークスペース |
| Team（Premium seat） | $125/席 | $100/席 | 高い利用枠、Claude Code込み |
| Enterprise | カスタム | - | SSO、SCIM、監査ログ、SLA |
Proプランは月払いだと$20ですが、公式サイトでは年払い時の$17（$200前払い）が先に案内されています。単純に「Pro=$20/月」と見てしまうと、実際の想定額と差が出るかもしれません。
Teamプランには、Standard seatとPremium seatの2種類があり、Premium seatにはClaude Codeが含まれるという違いがあります。組織でClaude Codeをチーム利用したい場合は、Premium seat以上を検討することになりそうです。
ケース別：どの経路を選ぶか
ここまでの3軸を踏まえて、ケース別に整理すると次のとおりです。
| こういう場合 | おすすめ | 決め手 |
|---|---|---|
| FedRAMP High・IL4/IL5・HIPAA対応が要件 | Bedrock（対象モデルを確認のうえ） | 軸1 |
| AWSを唯一のデータプロセッサにしたい | Bedrock | 軸1 |
| Guardrails・Knowledge Basesと組み合わせたい | Bedrock（bedrock-runtime） |
軸2 |
| Claude以外のモデルも併用したい | Bedrock（bedrock-runtime） |
軸2 |
| 既存のAnthropic API実装をAWS請求に載せ替えたい | Bedrock（bedrock-mantle）またはClaude Platform on AWS |
軸2・軸3 |
| Structured outputsなどAnthropicの新機能を早く使いたい | Claude Platform on AWS | 軸2 |
| computer・browser toolsetやFast modeを使いたい | Anthropic直API（Bedrock側は未確認のため暫定） | 軸2 |
| EDP/MACCを消化したい | BedrockまたはClaude Platform on AWS | 軸3 |
| AWSを使っていない、小規模で早く始めたい | Anthropic直契約 | 軸3 |
| Claude Codeをチームで使いたい | Team Premium seatまたはEnterprise | 軸3 |
| 年間利用額が大きく、個別条件を詰めたい | AWS請求に寄せる・EDP/MACCを消化するならAWS Marketplaceプライベートオファー（契約レイヤー）、Anthropicとの取引を軸にするなら個別交渉 | 軸3 |
多くの組織は軸1の時点で候補が絞られ、規制要件で決着が付かない場合に限って軸2・軸3の検討に進む、という読み方ができそうです。
このうち、特に迷いやすいと感じたケースを3つ補足します。
Bedrockを選んだ後にもう一段の選択が残る
「Bedrockを使う」と決めても、bedrock-runtimeとbedrock-mantleのどちらを使うかという選択がもう一段残ります。Guardrailsなど従来のBedrock機能が必要ならbedrock-runtime、Anthropic API互換のコード資産を活かしたいならbedrock-mantleという使い分けになりそうです。
両方を用途ごとに併用する構成もあり得るかもしれません。
規制要件がある場合はモデル単位で確認する
経路のレベルで要件を満たしていても、モデルのレベルでは対象外になっているケースがあります。前述のとおり、Claude Opus 5はFedRAMP High・IL4/IL5の対象リストに入っていません。
規制要件がある場合は、経路とモデルの両方を確認する必要があります。
既にBedrockのプライベートオファーがある場合は先に相談する
既存のBedrockプライベートオファーがある組織がClaude Platform on AWSへの移行を検討する場合は、サインアップの前にAWS・Anthropic双方の担当者に相談することをおすすめします。割引は遡及されないため、順序を間違えると損をする可能性があります。
まとめ
Claudeを利用する経路は、「4つを並べて比較する」よりも、判断軸を3つに絞って、上から順に当てはめていく方が選びやすそうです。
ポイントは以下の3つです。
- 軸1（データを誰が処理するか）：規制要件が厳しい場合や、AWSを唯一のデータプロセッサにしたい場合はBedrockが有力。ただしモデル単位での対象範囲確認は必須
- 軸2（機能の可用性）：どの経路もすべての機能をカバーする上位互換にはなっておらず、必要な機能から逆算して選ぶ必要がある
- 軸3（コストと調達）：トークン単価は概ね同水準だが同額と言い切れる根拠はなく、バッチ対応やトークナイザの変更、CCU換算の仕組みまで含めて実効コストを見る必要がある
ただし、本記事は公開情報に基づく机上の整理であり、実機での検証は行っていません。実際の導入にあたっては、利用するモデルとエンドポイントの組み合わせで、各公式ドキュメントを必ず確認することをおすすめします。
自組織の要件に合わせて、最適な経路を選んでいただければ幸いです。
参考
- Pricing - Claude Platform Docs
- Claude Platform on AWS - Claude Platform Docs
- Claude Platform on AWS is now generally available - AWS
- Claude Sonnet 5 model card - Amazon Bedrock User Guide
- Supported Regions and models for batch inference - Amazon Bedrock
- Amazon Bedrock Pricing
- Amazon Bedrock models – FedRAMP and DoD CSP SRG (IL4/IL5) certification status
- AWS HIPAA Eligible Services Reference
- Private offers - AWS Marketplace User Guide
- CountTokens - Amazon Bedrock API Reference
- Rate limits - Claude Platform Docs
- Rate limits and quotas - Claude Platform on AWS User Guide
- Plans & Pricing
- What is the Max plan? - Anthropic Help Center
- Claude Platform on AWSとBedrockは何が違う？Platform経由でClaude Code使ってみた（DevelopersIO）
