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

# マルチアカウントアーキテクチャへ移行するための ID 管理とアクセス制御
<a name="identity-management"></a>

マルチアカウントアーキテクチャに移行する際に最初に行うのは、組織内で新しいアカウント構造を設定することです。その次に、ユーザーを追加し、アカウントへのアクセスを設定します。このセクションでは、複数の AWS アカウントへのアクセスを管理する方法について説明します。

**Topics**
+ [組織を設定する](set-up-organization.md)
+ [ランディングゾーンを作成する](create-landing-zone.md)
+ [組織単位を追加する](add-organizational-units.md)
+ [初期ユーザーを追加する](add-initial-users.md)
+ [メンバーアカウントを管理する](manage-member-accounts.md)

# 組織を設定する
<a name="set-up-organization"></a>

複数の がある場合は AWS アカウント、 の組織を通じてそれらのアカウントを論理的に管理できます[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)。の*アカウント* AWS Organizations は、 AWS リソースと AWS アカウント 、それらのリソースにアクセスできる ID を含む標準です。*組織は*、単一のユニットとして管理 AWS アカウント できるように を統合するエンティティです。

アカウントを使用して組織を作成すると、そのアカウントが組織の管理アカウント (支払い者アカウントまたはルートアカウントとも言います) になります。組織が持つことのできる管理アカウントは 1 つだけです。 AWS アカウント 組織に を追加すると、*メンバーアカウント*になります。

**注記**  
各 には、*ルートユーザー*と呼ばれる単一の ID AWS アカウント もあります。アカウントの作成に使用したメールアドレスとパスワードを使用して、ルートユーザーとしてサインインできます。ただし、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことを強くお勧めします。詳細については、「[AWS アカウント のルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)」を参照してください。  
また、[メンバーアカウントのルートアクセスを一元化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)し、組織内のメンバーアカウントからルートユーザーの認証情報を削除することをお勧めします。

アカウントは、組織ルート、組織単位 (OU)、メンバーアカウントから成る階層ツリー構造に整理されます。ルートとは、組織のすべてのアカウントが設定された親コンテナのことです。組織単位 (OU) とは、[ルート](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root)内にある[アカウント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)のコンテナのことです。OU には他の OU やメンバーアカウントを含めることができます。OU は、親を 1 つだけ持つことができ、各アカウントは 1 つの OU にのみ属することができます。詳細については、[「用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations ドキュメント）」を参照してください。

[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) は、ユーザーとロールが使用できるサービスとアクションを指定します。SCPsは、アクセス許可を付与しない点を除いて、 AWS Identity and Access Management (IAM) アクセス許可ポリシーに似ています。その代わりとして、SCP はアクセス許可の最大数を定義します。ポリシーを階層内のノードのどれかにアタッチすると、そのポリシーは、ノード内のすべての OU とアカウントに適用されます。例えば、ポリシーをルートに適用した場合、そのポリシーは組織内のすべての [OU](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit) と[アカウント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)に適用されます。またポリシーを OU に適用した場合、そのポリシーは、ターゲット OU の OU とアカウントにのみ適用されます。

[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) は、組織内のリソースに対して使用可能なアクセス許可の最大数を一元的に制御します。RCPsは、アカウント内のリソースが組織のアクセスコントロールガイドラインの範囲内に収まるようにするのに役立ちます。

 AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織を利用する利点の 1 つは、管理アカウントとメンバーアカウントに関連するすべての料金が記載された一括請求書を受け取ることができることです。詳細については、[「一括請求](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations ドキュメント）」を参照してください。

## ベストプラクティス
<a name="organization-best-practices"></a>
+ 既存の を使用して組織 AWS アカウント を作成しないでください。新しいアカウントを作成します。これが組織の管理アカウントになります。特権オペレーションは組織の管理アカウント内で実行でき、SCPs と RCPs管理アカウントには適用されません。そのため、管理アカウントに含まれるクラウドリソースとデータは、管理アカウントで管理する必要があるものだけに制限する必要があります。
+ 管理アカウントへのアクセスを、新しい をプロビジョニング AWS アカウント し、組織を管理する必要がある個人のみに制限します。
+ SCP を使用して、ルート、組織単位、メンバーアカウントにアクセス許可の最大数を定義します。SCP を管理アカウントに直接適用することはできません。
+ RCPs を使用して、メンバーアカウントのリソースの最大アクセス許可を定義します。RCPsを管理アカウントに直接適用することはできません。
+ (AWS Organizations ドキュメント) の[ベストプラクティス AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html)に従ってください。

# ランディングゾーンを作成する
<a name="create-landing-zone"></a>

*ランディングゾーン*は、ワークロードとアプリケーションをデプロイするための出発点となる、適切に設計されたマルチアカウント AWS 環境です。マルチアカウントアーキテクチャ、ID とアクセスの管理、ガバナンス、データセキュリティ、ネットワーク設計、ログ記録を開始するためのベースラインとなります。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、自動化されたガードレールを提供することで、マルチアカウント環境の保守とガバナンスを簡素化するサービスです。通常、アカウント AWS のサービス 内の他のランディングゾーンをオーケストレーションすることで、all AWS リージョン. AWS Control Tower works 全体で環境を管理する単一の AWS Control Tower ランディングゾーンをプロビジョニングします。詳細については、[「ランディングゾーンをセットアップするとどうなるか](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower ドキュメント）」を参照してください。

でランディングゾーンを設定するときは AWS Control Tower、管理アカウント、ログアーカイブアカウント、監査アカウントの 3 つの共有アカウントを識別します。詳細については、[「共有アカウントとは](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower ドキュメント）」を参照してください。管理アカウントの場合、ワークロードをホストしていない既存のアカウントを使用してランディングゾーンをセットアップする必要があります。ログアーカイブアカウントと監査アカウントでは、既存のアカウントを再利用するか AWS アカウント、自分で作成 AWS Control Tower するかを選択できます。

 AWS Control Tower ランディングゾーンを設定する方法については、[「開始](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)方法 (AWS Control Tower ドキュメント）」を参照してください。

## ベストプラクティス
<a name="landing-zone-best-practices"></a>
+ [マルチアカウント戦略の設計原則](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS ホワイトペーパー) のベストプラクティスに従ってください。
+ [管理者向けの AWS Control Tower ベストプラクティス](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower ドキュメント) に従ってください。
+ ワークロードの大部分をホスト AWS リージョン する にランディングゾーンを作成します。
**重要**  
ランディングゾーンをデプロイした後にこのリージョンを変更する場合は、 の支援が必要であり AWS サポート、ランディングゾーンを廃止する必要があります。この方法は推奨されません。
+ 管理するリージョンを決定するときは AWS Control Tower 、ワークロードをすぐにデプロイする予定のリージョンのみを選択します。このリージョンは後で変更または追加することができます。がリージョン AWS Control Tower を管理する場合、検出ガードレールは としてそのリージョンにデプロイされます[AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)。
+ 管理するリージョンを決定したら AWS Control Tower 、管理されていないすべてのリージョンへのアクセスを拒否します。これにより、ワークロードと開発者は承認された AWS リージョンしか使用できないようになります。これは組織内のサービスコントロールポリシー (SCP) として実装されます。詳細については、[AWS リージョン 「拒否コントロールの設定](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) (AWS Control Tower ドキュメント）」を参照してください。
+ でランディングゾーンを設定するときは AWS Control Tower、次の OUs とアカウントの名前を変更することをお勧めします。
  + **セキュリティ** OU を **Security\$1Prod** に変更することをお勧めします。この OU が本番稼働用セキュリティ関連 AWS アカウントに使用されることを示すためです。
  +  AWS Control Tower 追加の OU を作成してから、**サンドボックス**から**ワークロード**に名前を変更することを に許可することをお勧めします。次のセクションでは、**ワークロード** OU 内部に追加の OU を作成し、これを AWS アカウントの整理に使用します。
  + 集中ロギングの名前を **Log Archive** AWS アカウント から **log-archive-prod** に変更することをお勧めします。
  + 監査アカウントの名前は、**監査**から **security-tooling-prod** に変更することをお勧めします。
+ 不正を防ぐために、ラン AWS Control Tower ディングゾーンに追加する前に使用履歴 AWS アカウント がある AWS が必要です。使用履歴 AWS アカウント のない新しい を使用している場合は、新しいアカウントで、 AWS 無料利用枠にない Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動できます。インスタンスを数分間実行してから終了します。

# 組織単位を追加する
<a name="add-organizational-units"></a>

マルチアカウント環境を設定するには、適切な組織構造を確立することが重要です。サービスコントロールポリシー (SCP) を使用して OU と OU 内のアカウントに対してアクセス許可の最大数を定義するため、管理、権限、財務報告の観点から組織構造は論理的でなければなりません。組織単位 (OUs[「用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations ドキュメント）」を参照してください。

このセクションでは、本番環境と非本番環境などの環境のセグメント化と構造化に役立つネストされた OU を作成して、ランディングゾーンをカスタマイズします。これらの推奨ベストプラクティスは、ランディングゾーンを分割して本番環境と非本番環境のリソースを分離し、インフラストラクチャをワークロードから分離することを目的としています。

OUs[「組織単位の管理](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations ドキュメント）」を参照してください。

## ベストプラクティス
<a name="ou-best-practices"></a>
+ [ランディングゾーンを作成する](create-landing-zone.md) に作成した**ワークロード** OU 内に、次のネストされた OU を作成します。
  + **Prod** — この OU は、顧客データを含む本番稼働用データを保存し、そこにアクセスする AWS アカウント に使用します。
  + **NonProd** — この OU は、開発環境、ステージング環境、テスト環境などの本番稼働用以外のデータを保存する AWS アカウント に使用します。

組織ルートの下に **Infrastructure\$1Prod** OU を作成します。この OU を使用して、一元化されたネットワークアカウントをホストします。

# 初期ユーザーを追加する
<a name="add-initial-users"></a>

ユーザーに AWS アカウントアクセスを許可するには、2 つの方法があります。
+ IAM ID (ユーザー、グループ、ロール)
+ の使用などによる ID フェデレーション AWS IAM アイデンティティセンター

小規模な企業やシングルアカウント環境では、新しい人が入社したときに管理者が IAM ユーザーを作成するのが一般的です。IAM ユーザーに関連付けられたアクセスキーとシークレットキーの認証情報は、有効期限がないため、長期認証情報と呼ばれます。ただし、攻撃者がこれらの認証情報を侵害した場合、そのユーザー用に新しい認証情報を生成する必要があるため、セキュリティのベストプラクティスとして推奨されていません。にアクセスするもう 1 つの方法は、[IAM ロール](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/)を使用すること AWS アカウント です。[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) を使用して、設定した時間が経過すると有効期限が切れる短期認証情報を一時的にリクエストすることもできます。

[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) AWS アカウント を使用して、 へのユーザーアクセスを管理できます。従業員や契約社員ごとに個別のユーザーアカウントを作成したり、各自のパスワードや多要素認証 (MFA) ソリューションを管理したり、グループ化してアクセスを管理したりできます。MFA を設定するときは、認証アプリケーションなどのソフトウェアトークンを使用するか、YubiKey デバイスなどのハードウェアトークンを使用できます。

IAM アイデンティティセンターは、Okta、JumpCloud、Ping ID などの外部 ID プロバイダー (IdP) からのフェデレーションもサポートしています。詳細については、「[Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。外部 IdP とフェデレーションすることで、アプリケーション全体のユーザー認証を管理し、IAM アイデンティティセンターを使用して特定の AWS アカウントへのアクセスを認可できます。

## ベストプラクティス
<a name="users-best-practices"></a>
+ ユーザーアクセスの設定は、「[セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」(IAM ドキュメント) を順守します。
+ アカウントアクセスを個々のユーザーではなくグループごとに管理します。IAM アイデンティティセンターに、各ビジネス機能を代表する新しいグループを作成します。例えば、エンジニアリング、財務、営業、製品管理のグループなどです。
+ 多くの場合、すべての AWS アカウント にアクセス (多くは読み取り専用アクセス) する必要のあるユーザーと、1 つの AWS アカウントへのアクセス権を必要とするユーザーを分けることで、グループを定義します。グループに関連付けられた AWS アカウント および アクセス許可を簡単に識別できるように、 グループには次の命名規則を使用することをお勧めします。

  `<prefix>-<account name>-<permission set>`
+ 例えば、`AWS-A-dev-nonprod-DeveloperAccess` グループの場合、`AWS-A` が 1 つのアカウントへのアクセスを示すプレフィックスです。`dev-nonprod` がアカウント名で、`DeveloperAccess` がグループに割り当てられた許可セットです。`AWS-O-BillingAccess` グループの場合、`AWS-O` が組織全体へのアクセスを示すプレフィックスで、`BillingAccess` がグループの許可セットを示しています。この例では、グループは組織全体にアクセスできるため、グループ名にはアカウント名が含まれていません。
+ 外部の SAML ベースの IdP で IAM アイデンティティセンターを使用していて、MFA が必要な場合は、属性ベースのアクセス制御 (ABAC) を使用して、認証方法を IdP から IAM アイデンティティセンターに渡すことができます。属性は SAML アサーションを通じて送信されます。詳細については、「[Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。

  Microsoft Azure Active Directory や Okta などの多くの IdP は、SAML アサーション内で認証方法リファレンス (`amr`) クレームを使用して、ユーザーの MFA ステータスを IAM アイデンティティセンターに渡すことができます。MFA ステータスのアサートに使用されるクレームとその形式は IdP によって異なります。詳細については、IdP のドキュメントを参照してください。

  IAM Identity Center では、 AWS リソースにアクセスできるユーザーを決定するアクセス許可セットポリシーを作成できます。ABAC を有効にして属性を指定すると、IAM アイデンティティセンターは認証されたユーザーの属性値を IAM に渡し、ポリシー評価で使用できるようにします。詳細については、「[Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。次の例に示すように、`aws:PrincipalTag` 条件キーを使用して MFA のアクセス制御ルールを作成します。

  ```
  "Condition": {
    "StringLike": { "aws:PrincipalTag/amr": "mfa" }
  }
  ```

# メンバーアカウントを管理する
<a name="manage-member-accounts"></a>

このセクションでは、既存のアカウントを組織に招待し、組織内に新しいアカウントを作成します。このプロセスで重要な点は、新しいアカウントをプロビジョニングする必要があるかどうかの判断基準を定義することです。

**Topics**
+ [既存のアカウントを招待する](#invite-account)
+ [で VPC 設定をカスタマイズする AWS Control Tower](#customize-vpc-settings)
+ [スコーピングの基準を定義する](#define-scoping-criteria)

## 既存のアカウントを招待する
<a name="invite-account"></a>

では AWS Organizations、会社の既存のアカウントを新しい組織に招待できます。他のアカウントを招待できるのは、組織内の管理アカウントだけです。招待されたアカウントを管理者が承認すると、そのアカウントはすぐに組織に加わり、組織の管理アカウントが、新しいメンバーアカウントで発生するすべての料金を負担することになります。詳細については、「[組織への AWS アカウント の招待](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)」および「[組織からの招待の承諾または拒否](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite)」(AWS Organizations ドキュメント) を参照してください。

**注記**  
アカウントを組織に招待できるのは、そのアカウントが現在別の組織に所属していない場合のみです。アカウントが既存の組織のメンバーである場合は、アカウントをその組織から削除する必要があります。アカウントが誤って作成された別の組織の管理アカウントである場合は、その組織を削除する必要があります。

**重要**  
既存のアカウントからコストまたは使用状況の履歴情報にアクセスする必要がある場合は、 AWS Cost and Usage Report を使用してその情報を Amazon Simple Storage Service (Amazon S3) バケットにエクスポートできます。組織への加入を承認する前に、これを行ってください。アカウントが組織に追加されると、このアカウントの履歴データにはアクセスできなくなります。詳細については、「[Setting up an Amazon S3 bucket for Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html)」(AWS Cost and Usage Report ドキュメント) を参照してください。

*ベストプラクティス*
+ 本番ワークロードを含んでいる可能性が高い既存のアカウントを、[組織単位を追加する](add-organizational-units.md) で作成した**ワークロード** > **Prod** の組織単位に追加することをお勧めします。
+ デフォルトでは、組織の管理アカウントには、組織に招待されたメンバーアカウントに対する管理アクセス権がありません。管理アカウントに管理制御をさせる場合は、メンバーアカウント内に **OrganizationAccountAccessRole** の IAM ロールを作成して、そのロールを引き受けるアクセス許可を管理アカウントに付与する必要があります。詳細については、[「招待されたメンバーアカウントでの OrganizationAccountAccessRole の作成](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations ドキュメント）」を参照してください。
+ 組織に招待した既存のアカウントについては、[メンバーアカウントのベストプラクティス](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations ドキュメント) を確認し、アカウントがこれらの推奨事項に従っていることを確認します。

## で VPC 設定をカスタマイズする AWS Control Tower
<a name="customize-vpc-settings"></a>

Account [Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) AWS アカウント を使用して新しい をプロビジョニングすることをお勧めします AWS Control Tower。Account Factory を使用すると、Amazon EventBridge との統合を使用して AWS Control Tower 、アカウントが作成され AWS アカウント るとすぐに新しい にリソースをプロビジョニングできます。

新しい を設定すると AWS アカウント、[デフォルトの Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) が自動的にプロビジョニングされます。ただし、Account Factory から新しいアカウントをセットアップすると、 AWS Control Tower で追加の VPC が自動的にプロビジョニングされます。詳細については、[「 AWS Control Tower と VPC の概要 VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower ドキュメント）」を参照してください。つまり、デフォルトでは AWS Control Tower が新しいアカウントごとに 2 つのデフォルト VPC をプロビジョニングします。

企業がアカウント内の VPC をより細かく制御しようとするのはよくあることです。多くの は、 AWS CloudFormation Hashicorp Terraform や Pulumi などの他のサービスを使用して VPCs。 AWS Control Towerによりプロビジョニングされる追加の VPC が作成されないように、Account Factory の設定をカスタマイズする必要があります。手順については、[「Amazon VPC 設定](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html)の構成 (AWS Control Tower ドキュメント）」を参照して、次の設定を適用します。

1. **インターネットアクセス可能なサブネット**のオプションを無効にします。

1. **プライベートサブネットの最大数**は、**0** を選択します。

1. **VPC 作成のリージョン**では、すべてのリージョンをクリアします。

1. **アベイラビリティゾーン**は、**3** を選択します。

*ベストプラクティス*
+ 新しいアカウントごとに自動的にプロビジョニングされるデフォルト VPC を削除します。これにより、ユーザーは専用の VPC を明示的に作成しなければ、アカウントでパブリック EC2 インスタンスを起動できなくなります。詳細については、「[デフォルトサブネットとデフォルト VPC の削除](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc)」(Amazon Virtual Private Cloud ドキュメント) を参照してください。[AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) を設定して、新しく作成されたアカウントのデフォルト VPC を自動的に削除することもできます。
+ **dev-nonprod** AWS アカウント という新しい を**ワークロード** > **NonProd** 組織単位にプロビジョニングします。このアカウントは開発環境に使用してください。手順については、「(AWS Control Tower ドキュメント) [を使用して Account Factory アカウントをプロビジョニング AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)する」を参照してください。

## スコーピングの基準を定義する
<a name="define-scoping-criteria"></a>

新しい をプロビジョニングするかどうかを決定する際に、会社が使用する基準を選択する必要があります AWS アカウント。ビジネスユニットごとにアカウントをプロビジョニングすることも、本番、テスト、QA などの環境に基づいてアカウントをプロビジョニングすることもできます。各企業には、それぞれの規模について独自の要件 AWS アカウント があります。通常、アカウントの規模を決定する際には、次の 3 つの要素を評価します。
+ **サービスクォータのバランス** — *サービスクォータ*は、 AWS のサービス 内の各 のリソース、アクション、および項目の最大値です AWS アカウント。多数のワークロードが同じアカウントを共有していて、1 つのワークロードがサービスクォータのほとんどまたはすべてを消費している場合、同じアカウントの別のワークロードに悪影響を及ぼす可能性があります。その場合は、そのようなワークロードを他のアカウントに分ける必要があるかもしれません。詳細については、 「[AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」(AWS 全般のリファレンス) を参照してください。
+ **コストレポート** - ワークロードを個別のアカウントに分離することで、コストと使用状況のレポートでコストをアカウントレベルで確認できます。同じアカウントを複数のワークロードに使用する場合、タグをリソースの管理と識別に使用することができます。タグ付けの詳細については、「 [AWS リソースのタグ付け ()](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)」を参照してくださいAWS 全般のリファレンス。
+ **アクセス制御** - ワークロードがアカウントを共有する場合、ユーザーが必要のないワークロードにアクセスできないように、アカウントリソースへのアクセスを制限する IAM ポリシーをどのように設定するかを検討する必要があります。別の方法としては、複数のアカウントや IAM アイデンティティセンターで[許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)を使用して、個々のアカウントへのアクセスを管理することができます。

*ベストプラクティス*
+ [AWSAWS Control Tower ランディングゾーンのマルチアカウント戦略](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)のベストプラクティスに従ってください (AWS Control Tower ドキュメント）。
+  AWS リソースの識別と管理に役立つ効果的なタグ付け戦略を確立します。タグを使用し、リソースを目的、事業ユニット、環境などの基準別に分類できます。詳細については、[「タグ付けのベストプラクティス](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (AWS 全般のリファレンス ドキュメント）」を参照してください。
+ ワークロードが多すぎるアカウントに負荷をかけすぎないようにします。ワークロードの需要がサービスクォータを超えると、パフォーマンスの問題が発生する可能性があります。競合するワークロードを別のワークロードに分割 AWS アカウント することも、サービスクォータの引き上げをリクエストすることもできます。クォータ引き上げのリクエストの詳細については、Service Quotas ドキュメントの「[Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。