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

# マルチアカウント環境におけるベストプラクティス
<a name="orgs_best-practices"></a>

マルチアカウント環境のセットアップと管理については、以下の推奨事項に従ってください AWS Organizations。

**Topics**
+ [アカウントと認証情報](#orgs_best-practices-account-management)
+ [組織構造とワークロード](#orgs_best-practices-organization-structure)
+ [サービスとコスト管理](#orgs_best-practices-service-cost-management)

## アカウントと認証情報
<a name="orgs_best-practices-account-management"></a>

### ルートアクセス管理の有効化による、メンバーアカウントのルートユーザー認証情報の管理の簡素化
<a name="bp_root-access-management"></a>

メンバーアカウントのルートユーザー認証情報のモニタリングと削除を簡素化するため、ルートアクセス管理を有効にすることをお勧めします。ルートアクセス管理は、ルートユーザー認証情報のリカバリを防ぎ、組織内のアカウントセキュリティを向上させます。
+ ルートユーザーへのサインインを防ぐには、メンバーアカウントのルートユーザー認証情報を削除します。これにより、メンバーアカウントによるルートユーザーのリカバリも防ぐことができます。
+ 特権セッションを引き受けて、メンバーアカウントに対して以下のタスクを実行します。
  + すべてのプリンシパルが Amazon S3 バケットにアクセスすることを拒否する、誤って設定されたバケットポリシーを削除します。
  + すべてのプリンシパルによる Amazon SQS キューへのアクセスを拒否する Amazon Simple Queue Service リソースベースのポリシーを削除します。
  + メンバーアカウントにルートユーザー認証情報のリカバリを許可します。メンバーアカウントのルートユーザー E メール 受信トレイにアクセスできるユーザーは、ルートユーザーパスワードをリセットし、メンバーアカウントのルートユーザーにサインインすることができます。

ルートアクセス管理を有効にすることで、新しく作成されるメンバーアカウントはルートユーザー認証情報がないため「セキュアバイデフォルト」となり、プロビジョニング後の MFA などの追加のセキュリティが不要になります。

詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[メンバーアカウントのルートアクセスを一元化する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user-access-management)」を参照してください。

### 連絡先の電話番号を最新の状態に保つ
<a name="bp_multi-acct_keep-contact"></a>

へのアクセスを回復するには AWS アカウント、テキストメッセージや通話を受信できる有効でアクティブな連絡先電話番号を用意することが重要です。アカウントのサポートと復旧の目的で AWS がお客様に連絡できるように、専用の電話番号を使用することをお勧めします。または Account Management APIs を使用して、 AWS マネジメントコンソール アカウントの電話番号を簡単に表示および管理できます。

がお客様に AWS 確実に連絡できるように、専用の電話番号を取得するにはさまざまな方法があります。専用の SIM カードと電話機を入手することを強くおすすめします。電話番号をアカウントの復旧に使用できるように、電話機と SIM を長期間安全に保管します。また、携帯電話料金の請求処理を担当するチームが、この番号が長期間使用されない場合でも重要な番号であることを理解していることを確認してください。この電話番号は、さらなる保護のために、組織内で秘密にしておくことが不可欠です。

 AWS 連絡先情報コンソールページに電話番号を記録し、その詳細を組織内で知っておく必要がある特定のチームと共有します。このアプローチは、電話番号を別の SIM に転送する際に生じるリスクを最小限に抑えるのに役立ちます。電話は、既存の情報セキュリティポリシーに従って保管します。ただし、保管場所は、関連する他の認証情報と同じにしてはなりません。電話機とその保存場所へのアクセスはすべてログに記録し、モニタリングする必要があります。アカウントに関連付けられている電話番号が変更された場合は、既存のドキュメントに記載の電話番号を更新するプロセスを実施してください。

### ルートアカウントにグループメールアドレスを使用する
<a name="bp_multi-acct_use-group"></a>

会社が管理するメールアドレスを使用します。受信したメッセージをユーザーのグループに直接転送するメールアドレスを使用します。がアクセスを確認するためにアカウントの所有者に連絡 AWS する必要がある場合、E メールメッセージは複数の当事者に配信されます。こうすることで、誰かが休暇中や病欠であるか、あるいはすでに退職している場合でも、応答の遅延のリスクを軽減できます。

## 組織構造とワークロード
<a name="orgs_best-practices-organization-structure"></a>

### アカウントを 1 つの組織内で管理する
<a name="bp_multi-acct_single-org"></a>

1 つの組織を作成し、その組織内ですべてのアカウントを管理することをおすすめします。組織は、環境のアカウント間の一貫性を維持するためのセキュリティ境界です。組織のアカウントに対し、ポリシーやサービスレベルの設定を一元的に適用できます。マルチアカウント環境全体で一貫したポリシー、一元的な可視性、プログラムによる制御を実現したい場合は、単一の組織内で実現するのが最適です。

### 報告体制ではなく、ビジネス目的に基づいてワークロードをグループ化する
<a name="bp_multi-acct_group-workloads"></a>

本番環境のワークロード環境とデータを、最上位のワークロード指向の OU に分離することをおすすめします。OU は、会社の報告体制を反映するのではなく、共通のコントロールセットに基づいて作成する必要があります。本番環境の OU とは別に、ワークロードの開発とテストに使用されるアカウントとワークロード環境を含む非本番環境の OU を 1 つ以上定義することがおすすめです。追加のガイダンスについては、「[ワークロード指向の OU を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-workload-oriented-ous.html)」を参照してください。

### 複数のアカウントを使用してワークロードを整理する
<a name="bp_multi-acct_use-multiple"></a>

 AWS アカウント は、 AWS リソースの自然なセキュリティ、アクセス、請求の境界を提供します。複数のアカウントを使用することには、アカウントレベルのクォータと API リクエストレートの制限を分散できるというメリットがあります。その他にも、こちらに記載されているような[メリット](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html)があります。セキュリティ、ログ、インフラストラクチャ用のアカウントなど、[組織全体の基本アカウント](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html)を複数使用することをおすすめします。ワークロードアカウントの場合、[本番用ワークロードとテスト/開発用ワークロードを別々のアカウントに分ける必要があります](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html#separate-production-from-non-production-workloads)。

## サービスとコスト管理
<a name="orgs_best-practices-service-cost-management"></a>

### AWS サービスコンソールまたは API/CLI オペレーションを使用して組織レベルでサービスを有効にする
<a name="bp_multi-acct_enable-aws"></a>

ベストプラクティスとして、そのサービスのコンソール、または API オペレーション/CLI コマンドに相当するもの AWS Organizations を使用して、 と統合するサービスを 全体で有効または無効にすることをお勧めします。この方法を使用すると、 AWS サービスを無効にするときに、必要なリソースの作成やリソースのクリーンアップなど、組織に必要な初期化手順をすべて実行できます。 AWS アカウント管理 は、 AWS Organizations コンソールまたは APIs を使用して有効にする必要がある唯一のサービスです。と統合されているサービスのリストを確認するには AWS Organizations、「」を参照してください[AWS のサービス で使用できる AWS Organizations](orgs_integrate_services_list.md)。

### 請求ツールを使用してコストを追跡し、リソースの使用を最適化する
<a name="bp_multi-acct_use-billing"></a>

組織を管理する場合、組織内のアカウントのすべての料金が網羅的にまとめられた一括請求書が届きます。コストを可視化する必要のあるビジネスユーザーには、請求ツールやコストツールを確認するために、読み取り専用の制限つき権限ロールを管理アカウントに割り当てることができます。たとえば、請求レポートへのアクセスを許可する[権限セットを作成したり](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html)、 AWS Cost Explorer Service (経時的なコスト傾向を表示するツール)を使用したり、[Amazon S3 ストレージレンズ](https://aws.amazon.com/blogs/aws/s3-storage-lens/)、[AWS  Compute Optimizer](https://aws.amazon.com/compute-optimizer/) などのコスト効率化サービスを使用したりできます。

### 組織リソース全体でのタグ付け戦略とタグの適用を計画する
<a name="bp_multi-acct_plan-tagging"></a>

アカウントやワークロードがスケールしてくると、コスト追跡、アクセス制御、リソースの整理にタグが役立ちます。タグ付けの命名戦略については、「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」のガイダンスに従ってください。リソースの他にも、組織のルート、アカウント、OU、およびポリシーにタグを作成することができます。詳しくは、「[タグ付け戦略の構築](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/building-your-tagging-strategy.html)」を参照してください。