# COST02-BP03 アカウント構造を実装する
組織にマッピングされるアカウントの構造を実装します。これは組織全体でのコストの割り当てと管理に役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS は 1 つの親アカウントと複数の子アカウントからなる構造です。このアカウント構造は、一般に管理 (親、旧称は支払者) アカウント、メンバー (子、旧称はリンク) アカウントと呼ばれます。ベストプラクティスは、組織の規模や使用量にかかわらず、1 つのメンバーアカウントを持つマスターを少なくとも常に 1 つ持つことです。すべてのワークロードリソースが存在するのは、メンバーアカウント内のみとする必要があります。
AWS アカウントの最適な数は状況に応じて異なります。現在と将来の運用モデルとコストモデルを見積もり、AWS アカウントの構造が組織の目標を反映するようにします。ビジネス上の理由から複数の AWS アカウントを作成する企業もあります。次に例を示します。
+ 組織単位、コストセンター、特定のワークロード間で、管理、会計、請求の職務機能を切り離す必要がある場合。
+ AWS のサービスの制限が特定のワークロードのみに設定される場合。
+ ワークロードとリソース間の隔離と分離には要件があります。
では [AWS Organizations](https://aws.amazon.com/organizations/)io1[一括請求 (コンソリデーティッドビリング)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) により、1 つ以上のメンバーアカウントと管理アカウントとの間に構造が作成されます。メンバーアカウントを使用すると、コストと使用量をグループ別に区別できます。一般的には、各組織単位 (財務、マーケティング、営業など)、各環境ライフサイクル (開発、テスト、本番など)、各ワークロード (ワークロード a、b、c) にメンバーアカウントをいったん分離したうえで、一括請求 (コンソリデーティッドビリング) を使用してこれらのアカウントを集約します。
一括請求 (コンソリデーティッドビリング) 機能を使用すると、複数のメンバー AWS アカウントの支払いを単一の管理アカウントにまとめつつ、各リンクアカウントのアクティビティの可視性も維持できます。コストと使用量が管理アカウントに集計されると、サービスの従量制割引とコミットメント割引 (Savings Plans とリザーブドインスタンス) を最大限に活用し、割引額を最大化できます。
[AWS Control Tower](https://aws.amazon.com/controltower/) では、複数の AWS アカウントのセットアップと構成をすばやく行い、ガバナンスが組織の要件に適合していることを確認できます。
**実装手順**
+ **分離要件を定義する: **分離の要件は、セキュリティ、信頼性、財務構造など、複数の要因の組み合わせです。各要因を順番に確認し、ワークロードまたはワークロード環境を他のワークロードから分離するかどうかを指定します。セキュリティは、アクセスとデータ要件を確実に守るものです。信頼性は、環境やワークロードが他の環境に影響を与えないように制限を確実に管理するものです。財務構造は、厳格な財務分離と説明責任を確保するものです。分離の一般的な例としては、本番稼働用ワークロードとテストワークロードが別々のアカウントで実行されることや、請求書と請求データをサードパーティー組織に提供できるように別のアカウントを使用することが挙げられます。
+ **グループ化要件を定義する:** グループ化要件は分離要件を上書きしませんが、管理を支援するために使用されます。分離を必要としない同様の環境またはワークロードをグループ化します。この例としては、1 つ以上のワークロードから複数のテスト環境または開発環境をグループ化することが挙げられます。
+ **アカウント構造を定義する: **これらの分離およびグループ化を使用して、各グループのアカウントを指定し、分離要件が維持されるようにします。これらのアカウントは、メンバーアカウントまたは連結アカウントです。これらのメンバーアカウントを単一の管理アカウントまたは支払者アカウントでグループ化することで、使用量が合算されるので、すべてのアカウントでの従量制割引がより大きくなり、すべてのアカウントに対して単一の請求書が提供されます。請求データを分離し、各メンバーアカウントに請求データの個別のビューを提供することができます。メンバーアカウントが使用量や請求データを他のアカウントに表示してはならない場合、または AWS から別々の請求書を必要とする場合は、複数の管理アカウントまたは支払者アカウントを定義します。この場合、各メンバーアカウントは独自の管理アカウントまたは支払者アカウントを持つことになります。リソースは常にメンバーアカウントまたは連結アカウントに配置する必要があります。管理アカウントまたは支払者アカウントは、管理のためにのみ使用してください。
## リソース
**関連するドキュメント:**
+ [AWS ジョブ機能の管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Control Tower](https://aws.amazon.com/controltower/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [一括請求](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
**関連する例:**
+ [CUR の分割とアクセスの共有](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html)