本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

GAMEPERF02-BP02 設計一種方法，可支援將延遲敏感的遊戲基礎設施放置在玩家附近，以改善效能

遊戲伺服器等延遲敏感基礎設施的個別配置，可將長時間網路路由的影響降至最低。可重複的部署可讓您輕鬆維護多個位置，這些位置對於您的玩家效能更佳。Ping 是在遊戲 UI 中呈現的常見指標，而低 ping 可以是差異化功能。

未建立此最佳實務時的曝險等級：高

實作指引

第一次啟動遊戲時，您可能還沒有關於玩家基礎的足夠資訊，無法充分了解部署最接近最有興趣玩遊戲之玩家的基礎設施的位置。這是常見的挑戰，您應該透過設計可讓您快速調整託管置放策略的架構來部署需要更靠近玩家的伺服器，為此案例做好準備。遊戲開發人員通常會定期將其遊戲基礎設施部署評估為經常性啟動後分析，以反覆方法逐步投資於隨著時間的改進。

最佳實務是使用infrastructure-as-code範本，例如 AWS CloudFormation 或 Hashicorp 的 Terraform，用於啟動關鍵遊戲服務所需的基礎設施組態，例如 VPCs、子網路組態和相依性，以便您可以參考這些範本、視需要快速自訂範本，並將其部署到需要額外基礎設施以支援玩家的位置。

您也應該確保了解目前的部署策略如何發展，以允許未來的擴展。IaC 範本是可重複的，但不能取代網路規劃。IPAM 會管理您的 VPCs。子網路大小、可用區域選擇，以及 IP 清查和跨帳戶可用區域對齊。網路很重要，需要考慮，變更時可能會對玩家造成干擾。跨多個地理位置部署的遊戲伺服器將連接到您的遊戲後端，這在單一或多個主區域中較常見，這可能需要額外的組態來支援私有連線。隨著時間的推移，應該持續評估這些考量，以便您可以隨著遊戲需求的變化或玩家需求變更，對遊戲託管策略進行變更。

判斷遊戲要使用多少遊戲託管位置時，請考慮下列因素：

當您決定新增或移除遊戲託管位置時，應評估這些考量。例如，您可以選擇優先改善遊戲體驗表現最差地理位置的玩家體驗，或是表達最聲音公開意見回饋的玩家體驗。您也可以選擇將玩家獲利納入您的優先順序，例如，專注於改善地理位置中的玩家體驗，這些玩家為您的遊戲產生重大收入來源，或者如果您引進效能提升，則有可能產生增量收入。

除了在 中託管基礎設施之外 AWS 區域，您還可以使用 Local Zones，這是 的延伸，來託管遊戲伺服器和其他延遲敏感應用程式 AWS 區域，例如更接近玩家的語音聊天伺服器。您也可以選擇在 Local Zones 中執行遊戲開發基礎設施，以改善遊戲開發團隊的體驗。例如，您可以使用 Local Zones 來解決使用案例，例如託管更靠近遊戲開發人員的自我管理來源控制伺服器的複本，以及使用 Amazon EC2 執行個體、EBS 磁碟區和部署到開發工作室附近一或多個 Local Zones 中的 Amazon FSx 檔案系統，為使用者提供遊戲開發虛擬工作站和內容儲存體，而無需您託管內部部署基礎設施。

在相同地理區域無法使用區域或本地區域時，Outpost 是不錯的選擇。 AWS 應考量從資料中心到 的連線能力，讓遊戲伺服器能夠後端系統可靠性。 AWS Outposts 和 Outpost 伺服器專為 AWS 在資料中心使用相同的服務和 APIs，無論您在何處執行遊戲，都能協助建立一致的部署模型。多個機架可以合併為邏輯 Outpost，而且基礎設施可以跨其共用 AWS 帳戶。硬體生命週期由 管理 AWS ，且前置時間最短可達 3 個月。

如果您要使用容器建置遊戲，並希望能夠靈活地使用可在您自己的內部部署基礎設施上部署的開放原始碼軟體來採用混合部署架構，您可以使用 ECS Anywhere 或 EKS Anywhere 作為 AWS Outposts 或 Local Zones 的替代方案。如果您使用 Amazon GameLift 託管；Amazon GameLift Anywhere 可用於在本機硬體上執行伺服器建置，以加速開發程序，讓您能夠使用 Local Zones 或將自己的金屬註冊為機群的一部分。

實作步驟