翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# GAMEOPS02-BP01 マルチアカウント戦略を採用して、さまざまなゲームやアプリケーションを自分のアカウントに分離する
各環境のセキュリティ、分離、運用上のニーズに合わせてインフラストラクチャのデプロイをガイドするアカウント構造を設計します。環境へのアクセスを制限し、必要な AWS サービスのみの使用を許可することで環境を分離することは不可欠です。本番環境はロックダウンされ、開発環境とテスト環境は実験を許可する寛容です。各環境の主要なサブシステムと、複数の環境で独自のホストおよび管理に使用される一般的なサービスをさらに分離することを強くお勧めします AWS アカウント 。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
さまざまな環境 (開発、テスト、ステージング、本番稼働、共有サービスなど) を個々の に分離 AWS することで、 にマルチアカウント戦略を採用することで AWS アカウント、インシデントの範囲を縮小します。オペレーションをさらに簡素化し、アカウントレベルおよび組織単位レベル (OU レベル) ポリシーを選択的に定義して適用 AWS アカウント するには、 の階層を一元管理 AWS Organizations することを検討してください。開発および本番ワークフローのニーズに合わせた適切な OU と AWS アカウント 構造を設計することで、コストを最適化し、スケーラビリティを向上させることができます。
+ **マルチアカウント戦略を採用する:** 環境を分離してインシデントの半径を減らし、運用を簡素化します。
+ **使用 AWS Organizations:** アカウントを階層的に管理し、ポリシーを適用し、一元化されたガバナンスを有効にします。
+ **スケーラビリティの計画:** きめ細かなアカウント構造を設計し、将来の成長のためのコスト削減策を実装します。
### 実装手順
にデプロイされるゲームシステムは、論理的に整理された複数のアカウントを使用して適切な分離を提供する AWS 必要があります。これにより、ゲームインフラストラクチャのスケールに応じて問題の発生範囲が軽減され、操作が簡素化されます。ゲームインフラストラクチャをホスト AWS アカウント する は通常、次の論理環境にグループ化されます。
+ **ゲーム開発環境**は、開発者がゲーム用のソフトウェアとシステムを開発するために使用します。
+ **テスト環境または品質保証 (QA) 環境**は、統合テスト、手動 QA、およびその他の自動テストを実行するために使用されます。
+ **ステージング環境または本番稼働前環境**は、完成したソフトウェアのホスティングに使用されるため、本番稼働を開始する前に負荷テストと煙テストを実施できます。
+ **ライブ環境または本番環境**は、ライブソフトウェアとインフラストラクチャをホストし、プレイヤーからの本番トラフィックを処理するために使用されます。
+ **共有サービスまたはツール環境**は、多くの異なるチームが使用する一般的なシステム、ソフトウェア、ツールへのアクセスを提供します。たとえば、中央のセルフホスト型ソースコントロールリポジトリとゲームビルドファームが共有サービスアカウントでホストされている場合があります。
+ **セキュリティ環境**は、クラウドセキュリティに重点を置くチームが使用する一元化されたログとセキュリティテクノロジーを統合するために使用されます。
のゲームインフラストラクチャでは AWS、ゲーム環境 (開発、テスト、ステージング、本番稼働) ごとに個別のアカウントを作成し、セキュリティ、ログ記録、中央共有サービス用のアカウントを作成することをお勧めします。
通常、限られた数のインフラストラクチャリソース、通常は数百台以下のサーバーを管理する小規模なゲーム開発スタジオでは、これらの環境 AWS アカウント (1 つの本稼働アカウント、1 つの開発アカウント、1 つのステージングアカウントなど) ごとに 1 つの を作成できます。ただし、ゲームインフラストラクチャやチームサイズが時間の経過とともに大きくなるにつれて、この簡略化されたモデルはうまくスケーリングされない可能性があります。
これらの環境を設定するときは、多くの 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 一元的に管理および管理します。プログラムで新しいアカウントを作成し、リソースを割り当て、アカウントをグループ化してワークフローを整理し、ガバナンスのためにポリシーをアカウントまたはグループに適用し、アカウントに 1 つの支払い方法を使用することで請求 を簡素化できます。さらに、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 アカウント 用の個別の があります。各 で実行されるリソース AWS アカウント は、それぞれのサブシステムに関連しています。通常、この種の開発パイプラインを使用する個々のゲームは、この構造または同様の構造をレプリケートします AWS アカウント。
これらのゲーム中心の環境 OUs に加えて、共有サービス OU とセキュリティ OU もあります。これらの OUs は、個々のゲームではなく、組織全体にする必要があります。これにより、ゲームは、この例のように、開発ツールとデータと分析の共有サービスを消費します。次に、アプリケーションログとシステムログをセキュリティ OU のログ用に AWS アカウント セットアップされた に送信します。
