Google Cloud 產品由特定區域性故障網域提供，並完全適用服務水準協議，確保您在 Google Cloud架構內設計應用程式架構。
Google Cloud 基礎架構服務據點遍布北美洲、南美洲、歐洲、亞洲、中東和澳洲各地。這些位置進一步細分為「區域」和「可用區」。您可以根據延遲時間、可用性和耐用性方面的需求，選擇應用程式的部署位置。
區域和可用區
「區域」是獨立的地理區域，由多個「可用區」組成。可用區和區域都是底層實體資源的邏輯抽象化概念。區域包含至少三個可用區，這些可用區分布於三座以上的實體資料中心。斯德哥爾摩、大阪和蒙特婁區域有三個可用區，分別位於一或兩座實體資料中心。這些區域目前正在擴展規模，達到至少三座實體資料中心。在Google Cloud架構解決方案時，請參考「雲端位置」、「Google Cloud 平台服務等級協議」和適當的Google Cloud 產品說明文件。這些資料中心可能由 Google 擁有，並列於Google Cloud 位置資訊頁面，也可能向第三方資料中心供應商租用。如要查看 Google Cloud的完整資料中心位置清單，請參閱我們的 ISO/IEC 27001 認證。無論資料中心是自有或租用， Google Cloud 都會選擇資料中心並設計基礎架構，以提供一致的效能、安全性和可靠性。
「可用區」是區域內 Google Cloud 資源的部署範圍。 您應將可用區視為區域內的單一故障網域。如要部署高可用性的容錯應用程式，並防範非預期的故障情形，請在區域內的多個可用區部署應用程式。 Google Cloud 也提供專門的 AI 可用區，為 AI 和機器學習工作負載提供高容量的 GPU 和 TPU。詳情請參閱「AI 可用區」一文。
為防範天災導致整個區域中斷服務，請制定災難復原計畫，並瞭解在主要區域中斷服務時，如何啟動應用程式。詳情請參閱應用程式部署作業注意事項。
如要進一步瞭解各個位置選項提供的特定資源，請參閱「Cloud 據點」。
Google Cloud的服務和資源可以是可用區、區域，或由 Google 跨多個區域管理。如要進一步瞭解這些選項對資料的影響，請參閱「資料的地理位置管理」。
Google Cloud 打算在每個一般用途區域中，提供至少三個可用區 (實體和邏輯上不同的區域)。
可用區資源
可用區資源是在單一可用區中運作，可用區中斷可能會影響該可用區的部分或所有資源。可用區資源的例子包括位於特定可用區的 Compute Engine 虛擬機器 (VM) 執行個體。
地區資源
區域性資源是指在區域內多個可用區備援部署的資源，例如 App Engine 應用程式或區域性代管執行個體群組。因此相較於可用區資源，區域資源的可用性更高。
多地區資源
Google 會管理多項 Google Cloud 服務，確保服務在不同區域內具有備援機制，並分布於不同區域。這些服務可最佳化可用性、效能與資源效率，因此，這些服務需要在延遲或一致性模型之間做出取捨。我們會根據具體產品說明這些妥協內容。
除了區域位置外，下列服務也提供一或多個多區域位置：
- Artifact Registry
- Assured Workloads
- 備份和災難復原
- BigQuery
- Cloud EKM
- Firestore
- Cloud Healthcare API
- Cloud HSM
- Cloud KMS
- Natural Language API
- Cloud Storage
- Container Registry
- Document AI
- Gemini Enterprise for Customer Experience
- GKE Enterprise
- Payment Gateway
- Security Command Center
- Sensitive Data Protection
- Spanner
- Speech-to-Text
- Storage 移轉服務
這些多區域服務的設計宗旨，是為了在單一區域發生故障時仍能正常運作。
詳情請參閱「各個地點提供的產品」和各產品的說明文件。
全球服務
Google Cloud 從一開始就以全球運作為目標設計，並持續進行維護和升級，全年無休，不會造成您的不便。我們的全球骨幹網路提供極大的負載平衡彈性，並透過靠近您的互連點，縮短使用者延遲時間。我們的全球雲端管理平台可簡化多區域開發作業的管理。
內部服務
許多面向客戶的服務都以一組經過驗證的內部服務為基礎，例如 Spanner、Colossus、Borg 和 Chubby。 Google Cloud
這些內部服務會跨多個區域進行全域負載平衡，或專用於服務所在的每個區域。如果服務的負載平衡機制涵蓋多個區域，我們會逐一更新各區域的服務，以便在不影響服務使用的情況下，偵測及解決問題。這些內部服務都不會僅限於單一邏輯資料中心或單一區域。
全域內部服務可在下列雲端區域中執行或複製：
美洲
- southamerica-west1
- us-central1
- us-east1
- us-east4
- us-west1
- us-west4
歐洲
- europe-north1
- europe-west1
- europe-west4
亞洲
- asia-east1
- asia-southeast1
服務依附元件
一般來說，對於 Google Cloud 服務，如果單一區域發生故障，只有該區域的客戶會受到影響；如果客戶使用多區域產品，則不會受到影響。 Google Cloud 已建置完善的架構，目標是防止區域間發生相關故障。
所有 Google Cloud 服務都依賴核心內部工具提供基本服務，例如網路 (資料中心內外)、資料中心存取權和身分授權系統。這些工具可抵禦區域性服務中斷，目標是確保一個區域發生服務中斷時，其他區域不會受到影響。
Google Cloud 提供明確指引，說明客戶如何在公開網站上架構應用程式，達到所需的韌性等級，特別是針對 Compute Engine、BigQuery、Pub/Sub 等常用 Google Cloud 產品和其他服務。
下方列出主要依附元件，首先是所有服務共用的依附元件，但低層級實作詳細資料可能會變更。
所有服務的常見依附元件
- 用於驗證和授權的身分資料平面
- 提供記錄、中繼資料儲存空間和工作流程管理功能的內部服務
- API Google Cloud 存取權取決於 DNS、全球分散式負載平衡器和存在點 (PoP)。
- 全域資源的設定：舉例來說，IAM 政策、全域防火牆規則、全域負載平衡器設定和 Pub/Sub 主題會儲存在複寫的資料庫中。
- 當 Google Cloud 服務向客戶控管的端點提出要求時 (例如 Cloud EKM 擷取客戶金鑰，或 Pub/Sub 傳送訊息)，這些要求會依賴我們的全球網路基礎架構，才能存取客戶控管的端點。
具有其他依附元件的服務
- Compute Engine 服務
- Google Cloud VM 和永久磁碟資料平面取決於較低層級的 Compute Engine 和 Cloud Storage 服務，例如 Borg 和 Colossus。
- Google Cloud 和基礎架構儲存服務 (例如 Spanner、Bigtable 和 Cloud Storage) 依賴：
- 客戶的加密和金鑰管理基礎架構 (Cloud KMS / Cloud EKM)，以及 Google 自有金鑰的內部基礎架構
- 內部服務，可記錄及稽核資料存取權
- 內部資料複寫服務，資料預計會在多個區域提供
- 明確設定備份和複製到其他區域的作業，取決於跨區域網路
- 訊息服務
- Pub/Sub 依賴我們的全球網路基礎架構，存取客戶控管的端點
- 網路服務
- 全域負載平衡、DNS 和區域間容錯移轉功能，全都仰賴實體網路基礎架構。
- 防範分散式阻斷服務攻擊等行為，取決於較低層級的 Compute Engine 基礎架構。
- GKE 和 Cloud SQL 等代管及託管服務
- 依賴 Compute Engine 和 Container Registry 或 Artifact Registry (VM 映像檔)。
- 自給自足的底層基礎架構
- 我們的內部叢集層級控制層，包括 Borg 和網路結構
- 叢集層級的儲存空間，例如 Colossus
- 加密和金鑰管理基礎架構
維護及提升可用性和韌性
網站可靠性工程 (SRE) 是 Google 內部專責機構，致力於提升可用性、縮短延遲時間、改善效能及擴充容量。服務中斷和無法使用的情況，與新程式碼的部署作業或環境變更有關。SRE 會採用業界最佳做法，在瞭解必要變更可能會導致停機的情況下，平衡發布新軟體的需求，並確保環境安全。
與客戶攜手打造彈性服務
如果您有業務關鍵需求，需要建構彈性和災害復原架構，我們的 SRE/CRE 和 PSO 團隊可以與您合作，建構應用程式來橋接多個區域和可用區，並進一步協助您設計高可用性 (HA) 系統。
如果您在特定日期 (例如黑色星期五和網購星期一) 有更高的可用性需求， Google Cloud 提供合作夥伴計畫，可協助您檢查及驗證在Google Cloud 上執行的特定應用程式，並找出應用程式與我們服務之間任何非預期的服務依附元件。
網路連接點 (POP)
Google 營運全球對接點連接點網路，這表示客戶流量可以在 Google 網路中傳輸，直到接近目的地為止，為使用者提供更優質的體驗和安全性。詳情請參閱「網路邊緣位置」。
資料的地理區域管理
Google Cloud 服務的資料所在地受《服務條款》規範，包括《服務專屬條款》。Google 瞭解每位客戶可能都有獨特的安全性與法規遵循需求。Google Cloud 銷售團隊可協助您滿足需求。
使用區域或可用區儲存空間資源時，強烈建議您將資料複製到其他區域，或將資料快照到多區域儲存空間資源，以利災難復原。
應用程式部署作業注意事項
- 建構高可用性服務和應用程式，確保區域無法使用時仍可正常運作
請使用下列項目：
- 區域資源，例如 App Engine 應用程式、區域代管執行個體群組，或代管多區域資源，例如 Cloud Storage、Datastore、Firestore 或 Spanner。
- 可用區資源 (例如 Compute Engine 虛擬機器)，但您要自行管理跨可用區或跨區域的運算和儲存空間備援。
- 如要建構可承受整個地區服務中斷的損失，從災難復原的應用程式
針對資料，執行下列一或多個策略：
- 使用代管的多區域儲存空間服務，例如 Cloud Storage、Datastore、Firestore 或 Spanner。
- 使用可用區或區域資源，但將快照資料儲存至多區域資源，例如 Cloud Storage、Datastore、Firestore 或 Spanner。
- 使用區域或地區資源，但管理您自己的資料，將資料複製到一或多個其他地區。
針對運算，使用下列策略：
- 使用可用區或區域資源 (例如 Compute Engine 或 App Engine)，但如果資料尚未儲存在受管理的多區域資源中，請在另一個區域 (發生區域故障時) 手動或自動啟動應用程式，並參照主要資料副本。
如要進一步瞭解服務依附元件，請與銷售人員聯絡。
其他解決方案與教學課程
下列解決方案和教學課程提供相關指引，確保應用程式具備高可用性，且能承受中斷：
可擴充及具有韌性的應用程式模式
瞭解如何使用 Google Cloud ，運用適用於任何網頁應用程式的模式和做法，建構可擴充且具備復原能力的應用程式架構。
建立 HTTPS 負載平衡器
在不同地區設定 Compute Engine 執行個體，然後使用 HTTP 負載平衡功能跨地區分散流量，以提高各地區的可用性並在服務中斷時進行容錯移轉。
設計穩健的系統
在 Compute Engine 服務上設計應用程式時，請確保應用程式能抵禦故障、網路中斷和意外災害。
使用 Cloud Storage 備份及還原 Cassandra
瞭解如何將資料備份至 Cloud Storage，以及從 Cloud Storage 還原資料，為 Cassandra 安裝作業新增基本災難復原功能。
災難復原規劃指南
使用 Google Cloud設計及測試災難復原計畫的一般原則。