翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

GAMEOPS02-BP01 マルチアカウント戦略を採用して、さまざまなゲームやアプリケーションを自分のアカウントに分離する

各環境のセキュリティ、分離、運用上のニーズに合わせてインフラストラクチャのデプロイをガイドするアカウント構造を設計します。アクセスを制限し、必要な AWS サービスのみの使用を許可することで環境を分離することは不可欠です。本番環境はロックダウンされ、開発環境とテスト環境は実験を許可する寛容です。各環境の主要なサブシステムと、複数の環境で使用され、独自の AWS アカウント 環境でホストおよび管理される一般的なサービスをさらに分離することを強くお勧めします。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

さまざまな環境 (開発、テスト、ステージング、本番稼働、共有サービスなど) を個々の に分離 AWS することで、 にマルチアカウント戦略を採用し AWS アカウント、インシデントの範囲を縮小します。オペレーションをさらに簡素化し、アカウントレベルおよび組織単位レベル (OU レベル) ポリシーを選択的に定義して適用 AWS アカウント するには、 の階層を一元管理 AWS Organizations することを検討してください。開発および本番ワークフローのニーズに合わせた適切な OU と AWS アカウント 構造を設計することで、コストを最適化し、スケーラビリティを向上させることができます。

実装手順

にデプロイされるゲームシステムは、論理的に整理された複数のアカウントを使用して適切な分離を提供する AWS 必要があります。これにより、ゲームインフラストラクチャのスケールに応じて問題の発生範囲が軽減され、操作が簡素化されます。ゲームインフラストラクチャをホスト AWS アカウント する は通常、次の論理環境にグループ化されます。

のゲームインフラストラクチャでは AWS、ゲーム環境 (開発、テスト、ステージング、本番稼働) ごとに個別のアカウントを作成し、セキュリティ、ログ記録、中央共有サービス用のアカウントを作成することをお勧めします。

通常、限られた数のインフラストラクチャリソース、通常は数百台以下のサーバーを管理する小規模なゲーム開発スタジオでは、これらの環境 AWS アカウント (1 つの本稼働アカウント、1 つの開発アカウント、1 つのステージングアカウントなど) ごとに 1 つの を作成できます。ただし、ゲームインフラストラクチャやチームサイズが時間の経過とともに増加するにつれて、この簡略化されたモデルはうまくスケーリングされない可能性があります。

これらの環境を設定するときは、多くの AWS サービスが特定のリージョン内のアカウント全体のリソースと API レベルの Service Quotas を共有することを検討してください。これは、アカウントを論理的に整理する方法を決定する際に考慮する必要があります。 では、アカウントにデプロイされたサービスを消費するためのコスト AWS アカウント のみが発生します。したがって、これにより、特にゲームが大きくなり、より多くのデベロッパーがリソースを構築および管理するためのアクセスを必要とするにつれて、リソースの競合とサービスクォータを効果的に減らすことができます。

通常、数百人の開発者がリソースにアクセスする数千台のサーバーを運用する大規模なゲーム開発スタジオでの経験に基づいて、ゲームをサポートする個々のアプリケーションが独自の開発、テスト、ステージング、本番稼働アカウントを持つ、よりきめ細かなアカウント構造を設計することをお勧めします。ライブシステムの計画と移行が複雑なため、ゲームの開始後に AWS マルチアカウント戦略を再設計するのは難しく、時間がかかるため、適切なマルチアカウント構造を決定する際には、将来のスケーリングのニーズを考慮してください。 

AWS Organizations を使用して階層とグループ化を設定し AWS アカウント、組織単位 (OUs) を定義して、サービスコントロールポリシー (SCPs) を通じて共通の OU レベルのポリシーを適用できます。 は、リソースの拡大とスケーリングに合わせて環境を AWS Organizations 一元的に管理および管理します。プログラムで新しいアカウントを作成し、リソースを割り当て、アカウントをグループ化してワークフローを整理し、ガバナンスのためにポリシーをアカウントまたはグループに適用し、アカウントに 1 つの支払い方法を使用することで請求を簡素化できます。さらに、Organizations は他の サービスと統合されているため、組織内のアカウント間での一元的な設定、セキュリティメカニズム、監査要件、リソース共有を定義できます。

AWS Control Tower では、ランディングゾーンと呼ばれる安全なマルチアカウント環境を簡単にセットアップして管理できます。Control Tower は を使用してランディングゾーンを作成し AWS Organizations、継続的なアカウント管理とガバナンス、および何千人もの顧客とのクラウドへの移行 AWS経験に基づく実装のベストプラクティスを提供します。AWS Config、AWS Trusted Advisor、 AWS Security Hub CSPMは、アカウントの衛生状況を集約または一元的に把握できるサービスです。

この分離は、各ゲーム環境にカスタムまたは個々のアクセス許可とガードレールを設定するのに役立ちます。本番稼働用アカウントには必要なガードレール、アクセス制限、モニタリングとアラート、セキュリティツールが必要ですが、非本番稼働用アカウントには同じレベルのガードレールとアクセス許可を必要としない場合があります。非本番環境を自動化して、数時間後にリソースをシャットダウンし、コストを削減できます。この詳細レベルでアカウントを分離すると、ゲームをサポートする各環境のインフラストラクチャコストを簡単にモニタリングできます。

以下は、 AWS Organizations と組織単位 (OUs) を使用して、別々の環境とスタジオ AWS アカウント に論理的にグループ化するゲーム会社のマルチアカウント構造の例です。この例では、OUs を使用して、環境に基づいてアカウントをグループ化し、次に環境を運用するスタジオに基づいてアカウントをグループ化します。これは、ネストされた階層を作成して、環境内の独自のアカウント (OUs と表記) に個別のアプリケーションとゲームをデプロイできるようにする方法を示しています。これは、複数のゲームを開発して運用する場合に便利です。この柱のリソースセクションで提供されているドキュメントとホワイトペーパーを参照して、マルチアカウント戦略を整理するために検討できる追加の戦略を確認してください。

上記の説明に基づいて、以下のサンプル図は、4 つのステージ (開発、テスト、ステージング、本番稼働) で構成される開発パイプラインを持つゲームスタジオ (組織) を想定しています。特定のゲーム (game1) では、各環境 (OU) にゲームサービス、専用ゲームサーバー、ソーシャルサービス、ウェブサーバー AWS アカウント 用の個別の があります。各 で実行されるリソース AWS アカウント は、それぞれのサブシステムに関連しています。通常、この種の開発パイプラインを使用する個々のゲームは、この構造または同様の構造をレプリケートします AWS アカウント。

これらのゲーム中心の環境 OUs に加えて、共有サービス OU とセキュリティ OU もあります。これらの OUs は、個々のゲームではなく、組織全体にする必要があります。これにより、ゲームは、この例のように、開発ツールとデータと分析の共有サービスを消費します。次に、アプリケーションログとシステムログをセキュリティ OU のログ用に AWS アカウント セットアップされた に送信します。