為什麼要在 AWS Bedrock 上用 Claude？模型家族與請求流程一次看懂

如果你的系統已經整套跑在 AWS 上，想把 Claude 接進產品，最順的一條路通常不是另外開一個帳號申請金鑰，而是直接走 AWS Bedrock。最有感的一點是：它把「接 AI」變成一件跟接其他 AWS 服務沒兩樣的事。

這一篇先不寫程式，帶你把兩件事看懂：Claude 的三個模型家族各自的定位與取捨，以及一個請求從使用者按下送出，到回應出現在畫面上，中間到底經過哪些站。看懂這兩件事，後面動手設定環境時你會清楚自己每一步在做什麼。

Bedrock 是什麼，為什麼企業會選它

Bedrock 是 AWS 的代管 AI 服務：你不用自己架設模型，也不用另外跟模型供應商開帳號，就能在自己的 AWS 帳號裡呼叫 Claude。對企業來說，這代表幾件很實際的事：權限沿用既有的 IAM 機制、費用併進原本的 AWS 帳單、請求走的是你們已經熟悉的 AWS 基礎設施。

導入 AI 這件事，從「評估一家新供應商」變成「多開一個 AWS 服務」。

有一個觀念貫穿全場，先放在最前面講：永遠透過自己的伺服器呼叫模型。使用者在瀏覽器輸入訊息，先送到你的伺服器，再由伺服器用 Bedrock 客戶端發出請求。憑證留在伺服器上，前端永遠碰不到。

Claude 的三個模型家族

Claude 提供三個模型家族，核心能力相同：都能生成文字、寫程式、分析圖片。差別在於智力、速度、成本三者之間的平衡。

特別留意 Haiku 的限制：它不支援 Opus 與 Sonnet 具備的推理能力。這讓它很適合面向使用者的即時互動，但不適合需要深度思考的複雜問題。另外一個安心點：三個家族共用同一套呼叫方式，之後想換模型，通常改個模型 ID 就能切換，一開始選得保守一點也沒關係。

怎麼選：三條準則與多模型併用

• 智力優先，選 Opus：任務複雜、需要強推理能力，你願意用速度與成本換品質。
• 速度優先，選 Haiku：即時互動或大量處理，回應速度是第一要求。
• 要平衡，選 Sonnet：大多數應用的預設起點。

實務上，很多團隊不會從頭到尾只用一個模型，而是在同一個應用裡讓模型分工：Haiku 負責面向使用者、講求速度的互動，Sonnet 跑主要的商業邏輯，Opus 留給需要深度推理的關鍵任務。每個環節都用最合適的成本，拿到最合適的能力。

一個請求的旅程

想像一個最簡單的聊天介面：使用者輸入「什麼是量子運算」按下送出。畫面上看起來只是一問一答，背後其實是一整條接力賽。

1. 使用者透過網頁介面送出訊息。
2. 你的伺服器收到請求，取出裡面的文字。
3. 伺服器用 Bedrock 客戶端向 AWS Bedrock 發出請求，附上使用者訊息與模型 ID。
4. 指定的模型處理請求、生成文字。
5. Bedrock 回傳一則 assistant 訊息，伺服器再把內容轉發回使用者的瀏覽器。

看懂這條路徑之後，你會發現整個架構裡沒有任何魔法：Bedrock 只是接力賽的其中一棒，而你的伺服器是掌控全場的那一棒。回傳的 assistant 訊息跟你送出的 user 訊息格式一致，這個一致性讓後面串接多輪對話變得非常自然，下一篇會實際用到。

這條路適合誰

把前面的內容收攏一下，這條路最適合三種團隊：

• 系統已經在 AWS 上：把 Claude 當成另一個 AWS 服務接進來，學習與導入成本最低。
• 有權限與稽核要求：IAM 與既有的安控流程直接沿用，不必為一家新供應商另立規矩。
• 想統一帳務：AI 用量併進既有的雲端帳單，不用多養一條付款與請購流程。

反過來說，如果你只是想快速做個原型、跟雲端平台沒有綁定，直接用 Anthropic API 會更輕。系列的下一篇，我會帶你實際設定 Bedrock 環境，用 boto3 打出第一個呼叫。