本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# GAMEOPS02-BP01 採用多帳戶策略，將不同的遊戲和應用程式隔離到自己的帳戶中
設計可引導基礎設施部署的帳戶結構，以符合每個環境的安全、隔離和操作需求。透過限制存取環境並只允許在其中使用必要的 AWS 服務來進行環境隔離至關重要，因為生產環境會遭到鎖定，而開發和測試環境則足以允許實驗。強烈建議進一步隔離每個環境中的主要子系統，以及由多個環境用來託管 AWS 帳戶 和管理的常見服務。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
將不同環境 （例如開發、測試、預備、生產和共用服務） AWS 隔離到個別環境，藉此在 上採用多帳戶策略 AWS 帳戶，進而減少事件範圍。請考慮 AWS Organizations 集中管理 的階層 AWS 帳戶 ，以進一步簡化操作，以及選擇性地定義和套用帳戶層級和組織單位層級 (OU 層級） 政策。透過設計符合您開發和生產工作流程需求的適當 OU 和 AWS 帳戶 結構，您可以最佳化成本並增強可擴展性。
+ **採用多帳戶策略：**隔離環境以減少事件半徑並簡化操作。
+ **使用 AWS Organizations：**以階層方式管理帳戶、套用政策，以及啟用集中式控管。
+ **針對可擴展性進行規劃：**設計精細的帳戶結構，並實作節省成本的措施，以因應未來的成長。
### 實作步驟
部署於 的遊戲系統 AWS 應使用多個邏輯組織的帳戶來提供適當的隔離，這可降低問題的爆量半徑，並在您的遊戲基礎設施擴展時簡化操作。 AWS 帳戶 該主機遊戲基礎設施通常會分組為下列邏輯環境：
+ 開發人員使用**遊戲開發環境**來開發遊戲的軟體和系統。
+ **測試或品質保證 (QA) 環境**用於執行整合測試、手動 QA 和其他必須執行的自動化測試。
+ **預備或生產前環境**用於託管已完成的軟體，以便在啟動生產之前執行負載和煙霧測試。
+ **即時或生產環境**用於託管即時軟體和基礎設施，並為來自玩家的生產流量提供服務。
+ **共用服務或工具環境**可讓您存取許多不同團隊所使用的常用系統、軟體和工具。例如，中央自我託管來源控制儲存庫和遊戲建置陣列可能託管在共用服務帳戶中。
+ **安全環境**用於整合集中式日誌和安全技術，供專注於雲端安全的團隊使用。
對於 上的遊戲基礎設施 AWS，建議為每個遊戲環境 （開發、測試、預備和生產） 建立單獨的帳戶，以及安全、記錄和中央共用服務的帳戶。
一般而言，管理有限數量基礎設施資源的較小遊戲開發工作室，通常為數百部伺服器或更少，可以 AWS 帳戶 為每個環境建立一個 （例如一個生產帳戶、一個開發帳戶和一個預備帳戶）。不過，隨著您的遊戲基礎設施或團隊大小隨時間增加，這個簡化的模型可能無法妥善擴展。
設定這些環境時，請考慮許多 AWS 服務會為特定區域內的整個帳戶共用資源和 API 層級 [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)。判斷如何以邏輯方式組織帳戶時，必須考量這一點。 AWS 帳戶 只會產生使用部署到其中之服務的成本。因此，這提供了一種有效減少資源爭用和服務配額的方法，特別是隨著您的遊戲增長，並且更多開發人員需要建立和管理資源的存取權。
根據我們使用大型遊戲開發工作室的經驗，這些工作室通常操作數千部伺服器，讓數百名開發人員存取 資源，我們建議您設計更精細的帳戶結構，其中支援遊戲的個別應用程式擁有自己的開發、測試、預備和生產帳戶。由於由於規劃和遷移即時系統的複雜性，在您啟動遊戲後重新設計 AWS 多帳戶策略既困難又耗時，因此在決定正確的多帳戶結構時，請考慮您未來的擴展需求。
您可以使用 [AWS Organizations](https://aws.amazon.com/organizations/)來設定階層和分組 AWS 帳戶，並定義 [組織單位](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (OUs)，以透過[服務控制政策 ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCPs) 將常見的 OU 層級政策套用至這些政策。隨著資源的成長和擴展， 會 AWS Organizations 集中管理和控管您的環境。您可以以程式設計方式建立新帳戶並配置資源、將帳戶分組以組織您的工作流程、將政策套用至帳戶或群組以進行控管，以及使用您帳戶的單一付款方式 簡化帳單。此外，Organizations 已與其他 服務整合，因此您可以定義組織中帳戶間的中央組態、安全機制、稽核需求和資源共用。
[AWS Control Tower](https://aws.amazon.com/controltower/) 提供直接的方式來設定和管理安全、多帳戶的環境，稱為*登陸區域*。Control Tower 使用 建立您的登陸區域 AWS Organizations，根據數千位客戶在遷移至雲端時 AWS的經驗，提供持續的帳戶管理和控管，以及實作最佳實務。 [AWS Config](https://aws.amazon.com/config/)、 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)和 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)是提供帳戶衛生彙總或集中檢視的服務。
此隔離可協助您設定每個遊戲環境的自訂或個別許可和護欄。生產帳戶應具有必要的護欄、存取限制、監控和提醒，以及安全工具，而非生產帳戶可能不需要相同層級的護欄和許可。非生產環境可以在數小時後自動關閉資源並節省成本。以這種精細程度分隔帳戶，可以直接監控支援遊戲的每個環境的基礎設施成本。
以下是遊戲公司使用 AWS Organizations 和組織單位 (OUs) 以邏輯方式分組 AWS 帳戶 到不同環境和工作室的多帳戶結構範例。在此範例中，OUs 用於根據帳戶的環境分組，然後根據操作環境的工作室分組帳戶。這示範了如何建立巢狀階層，以允許將個別應用程式和遊戲部署到其環境中自己的帳戶 （顯示為 OUs)，這在您開發和操作多個遊戲時非常有用。請參閱本支柱資源一節所提供的文件和白皮書，以了解您可以考慮用於組織多帳戶策略的其他策略。
根據上述討論，以下範例圖表假設遊戲工作室 （組織） 具有由 4 個階段 （開發、測試、預備和生產） 組成的開發管道。對於指定的遊戲 (game1)，每個環境 (OU) 都有個別 AWS 帳戶 的遊戲服務、專用遊戲伺服器、社交服務和 Web 伺服器。每個 中執行的資源 AWS 帳戶 都與個別子系統相關。一般而言，每個使用這種開發管道的個別遊戲都會為其複寫此結構或類似結構 AWS 帳戶。
除了這些以遊戲為中心的環境 OUs 之外，還有共用的服務 OU 和安全 OU。這些 OUs 應該是整個組織的，而不是針對每個個別遊戲。如此一來，遊戲就會取用開發工具、資料和分析的共用服務，如本範例所示。然後，將應用程式和系統日誌傳送至安全 OU 中為日誌 AWS 帳戶 設定的 。
