[文字]
本指引示範如何部署自訂、輕量且可擴展的跨平台遊戲身分元件，以及如何使用這些身分對 AWS 上的自訂遊戲後端元件進行驗證的步驟。本指引支援訪客身分和各種遊戲平台身分系統。透過將現有整合作為範本，它還可以擴展到任何其他遊戲平台，例如遊戲主機。
此外，本指引還提供了適用於 Unreal Engine 5、Unity 2021 (及更高版本) 和 Godot 4 遊戲引擎的軟體開發套件 (SDK) 和範例程式碼。這些 SDK 與本指引的身分元件和自訂後端功能整合。
請注意：[免責聲明]
架構圖
[架構圖說明]
步驟 1
AWS Lambda 函數 generate-keys 每 7 天調用一次。
步驟 2
Generate-keys 從 Amazon Simple Storage Service (Amazon S3) 取得最新的公有 jwks.json 檔案，產生新的公鑰 (JSON Web Key Set (JWKS )) 和私有金鑰，並使用新的公鑰和先前的金鑰更新 Amazon S3。
步驟 3
Generate-keys 將用於產生 JSON Web Token (JWT) 的私有金鑰更新到 AWS Secrets Manager。
步驟 4
遊戲用戶端使用提供的軟體開發套件 (SDK) 來請求新的訪客身分。或者，遊戲用戶端可以藉助 Amazon API Gateway 傳送 guest_secret，使用其現有訪客身分登入，而這受 AWS WAF 規則的保護。
步驟 5
login-as-guestLambda 函數驗證訪客身分，或在 Amazon DynamoDB 中的 UserTable 中建立一個新身分。
步驟 6
Lambda 函數從 Secrets Manager 請求私有金鑰，為用戶端產生簽署的 JWT 權杖，然後將其發回。
步驟 7
遊戲用戶端現在可以使用 SDK 傳送在 Authorization 標頭中帶有 JWT 權杖的請求來呼叫自訂後端元件。
步驟 8
後端元件透過 Amazon CloudFront (從 Amazon S3 取得檔案) 從公有端點請求 JWKS 公鑰來驗證權杖。
步驟 9
SDK 透過 API Gateway 呼叫 Lambda 函數 refresh-access-token，自動重新整理 JWT 存取權杖。該函數使用 Secrets Manager 中的私有金鑰產生新權杖。
步驟 10
此外，遊戲用戶端可以從遊戲平台特定的身分提供者傳送存取權杖以連結到現有帳戶，或建立新帳戶。
Lambda 函數驗證權杖，並在特定的 DynamoDB 表中建立指向使用者帳戶的連結。然後，它使用 Secrets Manager 中的私有金鑰為用戶端產生一個 JWT 權杖。
步驟 1
AWS Lambda 函數 generate-keys 每 7 天調用一次。
步驟 2
Generate-keys 從 Amazon Simple Storage Service (Amazon S3) 取得最新的公有 jwks.json 檔案，產生新的公鑰 (JSON Web Key Set (JWKS )) 和私有金鑰，並使用新的公鑰和先前的金鑰更新 Amazon S3。
步驟 3
Generate-keys 將用於產生 JSON Web Token (JWT) 的私有金鑰更新到 AWS Secrets Manager。
步驟 4
遊戲用戶端使用提供的軟體開發套件 (SDK) 來請求新的訪客身分。或者，遊戲用戶端可以藉助 Amazon API Gateway 傳送 guest_secret，使用其現有訪客身分登入，而這受 AWS WAF 規則的保護。
步驟 5
login-as-guestLambda 函數驗證訪客身分，或在 Amazon DynamoDB 中的 UserTable 中建立一個新身分。
步驟 6
Lambda 函數從 Secrets Manager 請求私有金鑰，為用戶端產生簽署的 JWT 權杖，然後將其發回。
步驟 7
遊戲用戶端現在可以使用 SDK 傳送在 Authorization 標頭中帶有 JWT 權杖的請求來呼叫自訂後端元件。
步驟 8
後端元件透過 Amazon CloudFront (從 Amazon S3 取得檔案) 從公有端點請求 JWKS 公鑰來驗證權杖。
步驟 9
SDK 透過 API Gateway 呼叫 Lambda 函數 refresh-access-token，自動重新整理 JWT 存取權杖。該函數使用 Secrets Manager 中的私有金鑰產生新權杖。
步驟 10
此外，遊戲用戶端可以從遊戲平台特定的身分提供者傳送存取權杖以連結到現有帳戶，或建立新帳戶。
Lambda 函數驗證權杖，並在特定的 DynamoDB 表中建立指向使用者帳戶的連結。然後，它使用 Secrets Manager 中的私有金鑰為用戶端產生一個 JWT 權杖。
Well-Architected 支柱
AWS Well-Architected Framework 可協助您了解在雲端建立系統時所做決策的利弊。該架構的六根支柱讓您能夠學習設計和操作可靠、安全、高效、經濟高效且永續的系統的架構最佳實務。使用 AWS Well-Architected Tool (在 AWS 管理主控台中免費提供)，您可以透過回答每根支柱的一組問題來針對這些最佳實務審查您的工作負載。
上方的架構圖是一個考量到 Well-Architected 最佳實務而建立的的解決方案的範例。若要完全實現 Well-Architected，您應該盡可能地多遵循 Well-Architected 的最佳實務。
-
卓越營運閱讀卓越營運白皮書
本指引中的自訂身分識別元件利用 AWS X-Ray 來追蹤使用者請求，並利用 Lambda Powertools 在後端邏輯中提供詳細資訊。此外，本指引的所有元件均使用 Amazon CloudWatch 追蹤 Virtual Private Cloud (VPC) 流程、API Gateway 存取、Amazon S3 存取、Lambda 完成和 AWS Fargate 任務的日誌。最後，AWS CDK 允許跨環境進行受控變更和一致組態，可協助您滿足安全和合規需求。
-
安全性閱讀安全白皮書
為了強化身分管理，本指引中的玩家身分和身分驗證管理由自訂身分元件實現。本指引的所有其他功能透過根據身分元件提供的公鑰驗證 JSON Web 權杖來確儲存取安全。該自訂身分識別元件受 AWS WAF 保護，這是一種 Web 應用程式防火牆，可保護應用程式免受常見 Web 攻擊。此外，所有資料在靜態和傳輸過程中都經過加密。
-
可靠性閱讀可靠性白皮書
本指引主要利用預設在 AWS 區域內的多個可用區域 (AZ) 中高度可用的全受管服務。對於 Fargate，利用多可用區域組態來實現高可用性，並且 DynamoDB 中的所有資料表都受到時間點復原的保護。
-
效能達成效率閱讀效能達成效率白皮書
本指引結合了許多不同的方法，以允許使用各種功能來提高效能。首先，本指引選取的服務旨在透過利用無伺服器服務的自動擴展元件，實現大規模執行，從而順利應對遊戲發表和其他流量尖峰。接下來，自訂身分識別元件提供的 X-Ray 資料，使開發人員能夠發現擁塞之處，並根據自己的需求調整本指引以最佳化效能。最後，透過 CloudFront 提供用於驗證 JSON Web 權杖的公鑰，從而最佳化後端元件的延遲。
-
成本最佳化閱讀成本最佳化白皮書
本指引盡可能利用無伺服器元件，讓您只需為您使用的資源付費。若要進一步降低成本，請考慮使用 AWS Savings Plans 最佳化 Lambda 和 Fargate 的成本。 此外，從隨需 DynamoDB 資料表遷移到自動擴展預設容量後，您可以在已知基準流量的情況下使用 DynamoDB 預留容量來降低成本。
本指引中使用的所有服務均設定為根據需求進行擴展，以儘量減少資源用量。這些服務包括 API Gateway、Lambda、DynamoDB、Amazon S3、 Fargate、Secrets Manager 和 AWS WAF。
-
永續發展閱讀永續發展白皮書
本指引中的無伺服器服務元件會自動擴展，從而時刻在滿足負載需求的情況下儘可能減少資源用量。這樣可以避免佈建過多的容量，減少基礎設施對環境的影響。
免責聲明
範例程式碼、軟體庫、命令列工具、概念驗證、範本或其他相關技術 (包括我們的人員提供的任何上述技術) 依據 AWS 客戶協議或您與 AWS 之間的相關書面協議 (以適用者為準) 作為 AWS 內容提供給您。您不得在您的生產帳戶、生產或其他關鍵資料中使用此 AWS 內容。您有責任根據您的特定品質控制實務和標準，依生產級用途來測試、保護和最佳化 AWS 內容 (如範例程式碼)。部署 AWS 內容可能會因建立或使用 AWS 收費資源 (如執行 Amazon EC2 執行個體或使用 Amazon S3 儲存) 而產生 AWS 費用。
本指引中對第三方服務或組織的參考並不意味著 Amazon 或 AWS 與第三方之間的認可、贊助或聯繫。AWS 的指引是技術起點，您可以在部署架構時自訂與第三方服務的整合。