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

# メンバーアカウントを管理する
<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)」を参照してください。