了解 Salesforce 和 AWS 之間的依賴關係：究竟是什麼相互依賴？

您在開啟 Salesforce 時發現某個功能運作緩慢、無法使用或傳回錯誤。同時，您注意到有 AWS 問題報告。您很容易得出結論：「Salesforce 運行在 AWS 上，所以肯定是 AWS 導致的。」 有時這種想法方向正確，但實際的依賴關係更為複雜。 Salesforce 廣泛使用 AWS，尤其是在Hyperforce方面，但某些 Salesforce 環境和服務使用其他基礎架構。因此，AWS 事件可能會影響部分 Salesforce 工作負載，但未必會導致所有 Salesforce 客戶或所有 Salesforce 產品都無法運作。

實際問題並非僅僅是 Salesforce 是否使用 AWS。答案是肯定的。真正重要的問題是：Salesforce 服務的哪些部分託管在哪裡？它依賴哪個 AWS 區域或服務？問題究竟出在 Salesforce、AWS、您自身的集成，還是它們之間的網路路徑？本指南將從最簡單的檢查入手，逐步深入到更深層的架構細節，解釋這種依賴關係，並展示如何驗證您自身的情況。

首先，要了解 Salesforce 所說的 Hyperforce 是什麼意思。

Hyperforce是 Salesforce 的公有雲基礎架構，用於在區域雲端環境中交付 Salesforce 應用程式。 Salesforce 將 Hyperforce 描述為 Customer 360 背後的基礎架構，並利用公有雲供應商來擴展區域可用性、資料駐留、安全控制和可擴充性。

截至 2026 年 9 月，Salesforce 表示 Hyperforce 已在多個國家的 Amazon Web Services (AWS) 上可用，並且正在擴展到 Google Cloud Platform。這一點很重要：「Salesforce 使用 AWS」是事實，但「每個 Salesforce 組織都只運行在 AWS 上」則不然。 Salesforce 仍然經營著一些 Salesforce 管理的第一方基礎設施，並且各個服務可以運行在與核心組織分離的基礎設施上。

Salesforce 目前的架構位置指南可在Salesforce 說明中心的「我的 Salesforce 實例位於何處？」頁面找到。 Salesforce 也在其Hyperforce 常規資訊和常見問題解答頁面中解釋了更廣泛的 Hyperforce 模型。

Salesforce 與 AWS 之間的依賴程度有多高？

這種依賴十分密切，但又錯綜複雜。多年來，AWS一直是Salesforce的主要策略雲端服務供應商，AWS稱兩家公司建立了全球策略合作夥伴關係。 Salesforce使用AWS基礎架構部署Hyperforce，並且已將Salesforce產品與AWS服務（例如Amazon Connect和Amazon Bedrock）整合。

對客戶而言，將客戶關係分為三個層次很有幫助：

這種分層模型是故障排除的關鍵。狀態頁面顯示「Salesforce 運作正常」並不能證明您託管在 AWS 上的整合運作良好。反之，AWS 的大規模事件也無法證明您的特定 Salesforce 執行個體受到影響。

為什麼 AWS 服務中斷不一定代表 Salesforce 也宕機

Salesforce 表示，Hyperforce 實例在相關區域內的三個可用區中使用雙活模型。可用區 (AZ) 是 AWS 區域內的一個獨立位置。在雙活設計中，應用程式容量跨多個可用區運行，而不是將一個可用區閒置作為冷備。 Salesforce 表示，流量會分佈在所有三個可用區中的活動應用程式伺服器上，資料庫複製可確保跨可用區的一致性。

這種架構旨在降低對任何單一可用區的依賴。如果某個可用區出現局部問題，該設計可以幫助服務透過其他可用區繼續運作。但多可用區架構並不能消除所有可能的故障模式。區域性服務問題、控制平面問題、網路中斷、軟體故障、相依性故障或應用層事件仍可能影響可用性。

因此，正確的思維模式是：AWS 上的 Salesforce 旨在在 AWS 區域內具有彈性，但它仍然具有基礎設施依賴性，這在較大的 AWS 事件期間可能會產生影響。

某些 Salesforce 服務可能會獨立於核心組織而發生故障。

很多事件調查都因此失敗。 Salesforce明確指出，某些服務可以在與客戶組織整合的同時，運作在獨立的基礎架構上。例如，Salesforce關於Sales Engagement、Einstein Activity Capture、Salesforce Inbox和Einstein Conversation Insights的文件就明確指出，這些服務託管在與客戶組織Salesforce核心基礎架構分離的AWS基礎架構上。

這意味著用戶可能會遇到以下情況：

• Salesforce登入及核心CRM記錄功能正常。
• 特定的生產力或與愛因斯坦相關的服務表現下降。
• 問題出在獨立的底層架構上，而不是Salesforce核心組織。

Salesforce 在其 Hyperforce 遷移指南中記錄了銷售互動、Einstein 活動擷取、Salesforce 收件匣和 Einstein 對話洞察的分離情況。

從最簡單的檢查開始檢查故障

1. 在假定 AWS 負責之前，請先檢查 Salesforce Trust。

首先查看 Salesforce 的官方狀態和信任資訊。尋找您特定 Salesforce 執行個體的狀態，而不是依賴「Salesforce 服務中斷」之類的通用報表。 Salesforce 在「檢視 Salesforce 組織的實例資訊」中解釋如何辨識組織的實例。

在 Salesforce 設定中，使用「快速尋找」方塊尋找「公司資訊」，然後尋找「實例」欄位。 Salesforce 指出，兩個字母的實例前綴（例如 AP0）表示 Salesforce 管理的第一方基礎架構，而三個字母的前綴（例如 GBR10）則表示 Hyperforce 基礎架構。

2. 確定您的 Hyperforce 組織是否位於 AWS 上

Hyperforce 執行個體並非永遠等同於 AWS。 Salesforce 表示 Hyperforce 目前可在 AWS 上使用，並且正在擴展到 Google Cloud Platform (GCP)。其文件建議，如果需要確定特定 Hyperforce 執行個體是在 AWS 還是 GCP 上，請聯絡 Salesforce 客戶支援。

這對於事件關聯而言越來越重要。您不應僅憑「Hyp​​erforce」這個字本身就將其對應到「AWS」。

3. 僅當相關時才檢查特定的 AWS 區域

如果您已確認您的組織或受影響的 Salesforce 服務運行在 AWS 上，請確定其所在區域。 Salesforce 目前的文件列出了 Hyperforce 區域及其公有雲供應商。例如，Salesforce 列出的 AWS 支援的 Hyperforce 區域包括雪梨、孟買、東京、新加坡、倫敦、法蘭克福、加拿大中部以及美國多個區域。

然後將 Salesforce 事件與該區域和服務相關的官方 AWS 健康資訊進行比較。避免將一個 AWS 區域中的問題視為與 Salesforce 區域無關的證據。

4. 將 Salesforce 託管與您自己的 AWS 整合分開

如果 Salesforce 本身運作正常，請檢查您的整合路徑。典型的客戶端相依性包括 API 閘道、Lambda 函數、Amazon Connect、資料庫、佇列、私有端點、VPN、DNS 和企業網路控制。這些元件中的任何一個故障都可能被使用者誤認為是“Salesforce 問題”，因為錯誤發生在 Salesforce 工作流程內部。

一個有用的測試方法是：如果不呼叫我們的 AWS 服務，同樣的 Salesforce 操作能否成功？如果可以，則核心組織可能運作正常，而問題出在整合路徑上。

AWS Direct Connect 怎麼樣？

有些組織使用AWS Direct Connect（一種連接到 AWS 的專用網路連線）來滿足 AWS 上 Hyperforce 的網路需求。 Salesforce 文件中記錄了一個用例，說明如何透過 AWS Direct Connect 為具有專用連線、合規性或資料駐留需求的組織路由某些 Hyperforce 電子郵件流量。

這就引入了另一個依賴層。當涉及私有連線時，事件可能發生在使用者和 Salesforce 之間，而不是 Salesforce 內部。相關的 Salesforce 文件是《透過 AWS Direct Connect for Hyperforce 路由電子郵件》。

Salesforce 為何轉向多雲 Hyperforce 模型

Salesforce 將 Hyperforce 描述為可在多個公有雲供應商上執行。這降低了架構上的固有假設，即所有 Salesforce 工作負載必須永久託管在單一超大規模雲端平台上。 Salesforce 的 2026 年文件指出，Hyperforce 已在 AWS 上可用，並且正在部分地區引入對 Google Cloud Platform 的支持，具體情況取決於 Salesforce 的路線圖。

對客戶而言，這並不代表現有的 Salesforce 組織會在 AWS 服務中斷期間自動從 AWS 故障轉移到 Google Cloud。多雲支援主要是指 Salesforce 可以在哪些雲端平台上部署和運行其平台。除非 Salesforce 明確針對您使用的服務提供了相關文檔，否則您不應假定跨雲端故障轉移。

Salesforce 和 AWS 的合作遠不止於託管

雙方的合作關係不僅限於基礎設施託管。 AWS 和 Salesforce 也建立了更廣泛的策略合作夥伴關係，涵蓋資料、人工智慧、聯絡中心功能、整合和採購等領域。 AWS 的官方合作夥伴關係頁面重點介紹了 Salesforce 產品與 AWS 技術的集成，包括生成式人工智慧和資料管理功能。您可以在AWS 和 Salesforce 的官方合作夥伴關係頁面上查看相關資訊。

這在架構評審中至關重要，因為這裡涉及兩個不同的依賴關係問題：

• Salesforce本身運行在哪裡？這取決於託管服務。
• 您選擇將哪些 AWS 服務連接到 Salesforce？這是您可以控制的整合依賴項。

這兩個依賴項有不同的擁有者、監控路徑、復原程序和支援團隊。

一份實用的事故檢查清單

當使用者回報 Salesforce 無法使用或部分功能失效時，請依照下列順序進行檢查：

1. 請確認受影響的 Salesforce 功能的具體名稱，而不僅僅是「Salesforce」。
2. 尋找您的 Salesforce 實例並檢查其官方 Salesforce Trust 狀態。
3. 確定組織使用的是 Salesforce 管理的基礎架構還是 Hyperforce。
4. 如果是 Hyperforce，請確認相關部署是否使用了 AWS。
5. 只有在確定相關的情況下才確定要使用 AWS 區域。
6. 檢查失敗的函數是否是獨立於核心組織所託管的單獨 Salesforce 服務。
7. 測試您自己的 AWS 整合、私有網路、DNS、API 或呼叫中心服務是否是實際故障的依賴項。
8. 記錄時間戳記和請求 ID，以便 Salesforce 支援或 AWS 支援能夠關聯故障。

如何驗證你的結論

當各層面的證據相互吻合時，表示你的診斷越來越可靠。如果 Salesforce Trust 報告了與你的實例完全一致的事件，並且受影響的功能與症狀相符，那麼 Salesforce 端很可能存在問題。如果 Salesforce 運作正常，但你的 AWS 整合測試在同一時間段內失敗，那麼客戶端的 AWS 相依性更有可能是問題所在。如果只有一個 Salesforce 外掛程式受到影響，而核心 CRM 功能保持正常，則需要調查該服務的獨立基礎架構和狀態。

不要只停留在「AWS 服務中斷」或「Salesforce 服務宕機」的層面。可靠的答案來自於將你的實例、產品、區域和整合路徑進行配對。

結論

Salesforce 對 AWS 有著深厚的依賴性，尤其因為許多 Hyperforce 部署和支援服務都運行在 AWS 基礎架構上。但這種依賴性並非普遍或單一的。 Salesforce 也經營自己的基礎設施，正在將 Hyperforce 擴展到多個公有雲供應商，並且可以將各個服務與客戶的核心組織分開託管。

對維運團隊而言，最佳方法是將 Salesforce 和 AWS 視為依賴關係圖，而非單一堆堆疊。明確核心組織的運作位置，繪製獨立託管的 Salesforce 服務，記錄每個客戶管理的 AWS 集成，並獨立監控每一層。這樣可以更快地從「Salesforce 故障」找到真正需要關注的特定元件。