翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチアカウントアーキテクチャのネットワーク接続
## VPC の接続
多くの企業で、Amazon Virtual Private Cloud (Amazon VPC) の VPC ピアリングを使用して、開発用 VPC と本番稼働用 VPC に接続しています。VPC ピアリング接続を使用すると、プライベート IP アドレスを使用して 2 つの VPC 間でトラフィックをルーティングできます。接続VPCs は、異なる AWS アカウント と異なる にすることができます AWS リージョン。詳細については、「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」(Amazon VPCドキュメント) を参照してください。企業が成長し、VPC の数が増えるにつれて、すべての VPC 間のピアリング接続を維持することがメンテナンスの負担になることがあります。VPC あたりの VPC ピアリング接続の最大数によって制限がある場合もあります。詳細については、「[VPC ピアリング接続クォータ](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering)」(Amazon VPC ドキュメント) を参照してください。
複数の にまたがって非本番稼働データをホストする複数の開発、テスト、ステージング環境がある場合は AWS アカウント、それらのすべての VPCs 間でネットワーク接続を提供するが、本番稼働環境へのアクセスは許可しないことをお勧めします。[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) を使用して複数のアカウントにまたがる VPC を複数接続できます。ルートテーブルを分離することで、集中型ルーターとして機能するトランジットゲートウェイを介して開発用 VPC が本番稼働用 VPC と通信するのを防ぐことができます。詳細については、「[集中型ルーター](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html)」(Transit Gateway ドキュメント) を参照してください。
Transit Gateway は、 AWS アカウント や AWS リージョンが異なるものも含め、他のトランジットゲートウェイとのピアリングもサポートしています Transit Gateway はフルマネージド型の可用性の高いサービスであるため、リージョンごとにプロビジョニングする必要があるトランジットゲートウェイは 1 つだけです。
詳細および詳細なネットワークアーキテクチャについては、[「スケーラブルで安全なマルチ VPC AWS ネットワークインフラストラクチャの構築](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)」(AWS ホワイトペーパー) を参照してください。
## アプリケーションの接続
同じ環境 (本番環境など) 内の異なる AWS アカウント のアプリケーション間で通信を確立する必要がある場合は、次のいずれかのオプションを使用できます。
+ [VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)や [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は、複数の IP アドレスやポートに幅広くアクセスする場合に、ネットワークレベルで接続を提供できます。
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、VPC のプライベートサブネットにエンドポイントを作成し、これらのエンドポイントは [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) に DNS エントリとして登録されます。DNS を使用することにより、アプリケーションは、VPC に NAT ゲートウェイやインターネットゲートウェイを必要とせずに、エンドポイントを解決して登録済みのサービスに接続できます。
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) は、複数のアカウントと VPC にまたがるアプリケーションなどのサービスを関連付け、サービスネットワークにまとめます。サービスネットワークに関連付けられた VPC 内のクライアントは、同じアカウントに属しているかどうかに関係なく、サービスネットワークに関連する他のすべてのサービスにリクエストを送信できます。VPC Lattice は AWS Resource Access Manager (AWS RAM) と統合されているため、他のアカウントや を通じてリソースを共有できます AWS Organizations。VPC は、1 つのサービスネットワークにのみ関連付けることができます。このソリューションでは VPC ピアリングや AWS Transit Gateway を使用してアカウント間の通信を行う必要がありません。
## ネットワーク接続のベストプラクティス
+ 一元化 AWS アカウント されたネットワークに使用する を作成します。このアカウントに **network-prod** という名前を付け、 AWS Transit Gateway と [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) (IPAM) に使用します。このアカウントを **Infrastructure\$1Prod** の組織単位に追加します。
+ [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) を使用して、トランジットゲートウェイ、VPC Lattice サービスネットワーク、IPAM プールを組織の他のメンバーと共有します。これにより、組織 AWS アカウント 内のすべての がこれらのサービスとやり取りできるようになります。
+ IPAM プールを使用して IPv4 と IPv6 のアドレス割り当てを一元管理することで、エンドユーザーが [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) を使用して VPC を自分でプロビジョニングできるようになります。これにより、VPC のサイズを適切に設定し、IP アドレス空間の重複を防ぐことができます。
+ インターネットへのトラフィックにはエグレスの一元化アプローチを使用し、インターネットから環境に入るトラフィックにはイングレスの分散化アプローチを使用します。詳細については、「[エグレスの一元化](centralized-egress.md)」および「[イングレスの分散化](decentralized-ingress.md)」を参照してください。
# エグレスの一元化
*一元的な出力*は、インターネット宛てのすべてのネットワークトラフィックに 1 つの共通のエントリポイントを使用する原則です。このエントリポイントで検査を設定し、指定したドメインへのトラフィックのみを許可するか、指定したポートまたはプロトコルを介してのみトラフィックを許可できます。また、エグレスを一元化することで、インターネットに到達するために各 VPC に NAT ゲートウェイをデプロイする必要がなくなるため、コスト削減にも役立ちます。これにより、マルウェアのコマンドアンドコントロール (C&C) インフラストラクチャなど、外部からアクセス可能な悪意のあるリソースへの露出が制限されるため、セキュリティの観点からはメリットがあります。一元的な出力の詳細とアーキテクチャオプションについては、[「インターネットへの一元的な出力](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html)」(AWS ホワイトペーパー) を参照してください。
ステートフルでマネージド型のネットワークファイアウォールであり、侵入検知と防止のサービスである [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) を、送信トラフィックの一元化された検査ポイントとして使用できます。このファイアウォールは、送信トラフィック専用の VPC で設定します。Network Firewall は、インターネットアクセスを特定のドメインに制限するのに使用できるステートフルルールをサポートしています。詳細については、Network Firewall ドキュメントの「[Domain filtering](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering)」を参照してください。
[Amazon Route 53 Resolver DNS ファイアウォール](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)を使用して、特定のドメイン名への送信トラフィックを制限することもできます。主な目的は、データの不正流出を防ぐことです。DNS ファイアウォールルールでは[ドメインリスト](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (Route 53 ドキュメント) を適用して指定したドメインへのアクセスを許可または拒否することができます。悪意のあるアクティビティやその他の潜在的な脅威に関連付けられているドメイン名を含む AWS マネージドドメインリストを使用することも、カスタムドメインリストを作成することもできます。DNS ファイアウォールルールグループを作成して VPC に適用します。アウトバウンド DNS リクエストは VPC のリゾルバーを経由してドメイン名を解決し、DNS ファイアウォールは VPC に適用されたルールグループに基づいてリクエストをフィルタリングします。リゾルバーに送られる再帰的な DNS リクエストは、トランジットゲートウェイと Network Firewall パスを経由しません。Route 53 Resolver と DNS ファイアウォールは VPC からの独立したエグレスパスと見なす必要があります。
次の図は、エグレスの一元化を示すサンプルアーキテクチャです。ネットワーク通信が開始される前に、DNS リクエストが Route 53 Resolver に送信され、DNS ファイアウォールが通信に使用される IP アドレスの解決を許可または拒否します。インターネットに向かうトラフィックは、一元化されたネットワークアカウントのトランジットゲートウェイにルーティングされます。トランジットゲートウェイは、検査のためにトラフィックを Network Firewall に転送します。ファイアウォールポリシーで送信トラフィックが許可されている場合、トラフィックは NAT ゲートウェイ、インターネットゲートウェイを経由して、インターネットに送信されます。を使用して AWS Firewall Manager 、マルチアカウントインフラストラクチャ全体で DNS Firewall ルールグループと Network Firewall ポリシーを一元管理できます。
![\[他のアカウントからネットワークアカウントを経由してインターネットへ送信するトラフィックルーティング。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## 送信トラフィックを保護するためのベストプラクティス
+ [ログ記録専用モード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (Route 53 ドキュメント) で開始します。正当なトラフィックが影響を受けないことを確認したら、ブロックモードに変更します。
+ [AWS Firewall Manager ネットワークアクセスコントロールリストのポリシー](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html)を使用するか、 を使用して、インターネットへの DNS トラフィックをブロックします AWS Network Firewall。すべての DNS クエリは Route 53 Resolver を経由する必要があります。ここでは、Amazon GuardDuty でモニタリングし (有効になっている場合）、[Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) でフィルタリングできます (有効になっている場合）。詳細については、「[VPC とネットワークの間における DNS クエリの解決](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)」(Route 53 ドキュメント) を参照してください。
+ DNS ファイアウォールと Network Firewall の [AWS マネージドドメインリスト](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) (Route 53 ドキュメント) を使用します。
+ .info、.top、.xyz など、リスクが高く、あまり使われないトップレベルドメインや、一部の国コードドメインをブロックすることを検討してください。
+ ポート 1389、4444、3333、445、135、139、53 など、リスクが高く、あまり使われないポートをブロックすることを検討してください。
+ 開始点として、 AWS マネージドルールを含む拒否リストを使用できます。その後、時間の経過とともに許可リストモデルの実装に取り組むことができます。たとえば、許可リストに完全修飾ドメイン名の厳密なリストのみを含める代わりに、*\$1.example.com* などのいくつかのワイルドカードを使用して開始します。予想される最上位ドメインのみを許可し、他のすべてのドメインをブロックすることもできます。次に、時間の経過とともに、これらも絞り込みます。
+ [Route 53 プロファイル](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (Route 53 ドキュメント) を使用して、DNS 関連の Route 53 設定を多くの VPCsと異なる に適用します AWS アカウント。
+ これらのベストプラクティスの例外を処理するプロセスを定義します。
# イングレスの分散化
イングレスの分散化とは、インターネットからのトラフィックがアカウントのワークロードに到達する方法を、個々のアカウントレベルで定義する原則のことです。マルチアカウントアーキテクチャにおいて、イングレス分散化の利点の 1 つは、各アカウントがワークロードに最適なイングレスサービスまたはリソース (Application Load Balancer、Amazon API Gateway、Network Load Balancer など) を使用できることです。
イングレスが分散されていると、各アカウントを個別に管理する必要がありますが、[AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) から構成を一元的に管理、維持することができます。Firewall Manager は、[AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) や [Amazon VPC セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)などの保護をサポートしています。Application Load Balancer、Amazon CloudFront、API Gateway、または AWS WAF に関連付けることができます AWS AppSync。エグレス VPC とトランジットゲートウェイを使用している場合、[エグレスの一元化](centralized-egress.md) で説明されているように、各スポーク VPC にはパブリックサブネットとプライベートサブネットが含まれます。ただし、トラフィックはネットワークアカウントのエグレス VPC を経由するため、NAT ゲートウェイをデプロイする必要はありません。
次の図は、インターネットにアクセス可能なワークロードを含む単一の VPC AWS アカウント を持つ個人の例を示しています。インターネットからのトラフィックは、インターネットゲートウェイを経由して VPC にアクセスし、パブリックサブネットでホストされている負荷分散サービスとセキュリティサービスに到達します。(パブリックサブネットには、インターネットゲートウェイへのデフォルトルートがあります)。ロードバランサーをパブリックサブネットにデプロイし、 AWS WAF アクセスコントロールリスト (ACLs) をアタッチして、クロスサイトスクリプティングなどの悪意のあるトラフィックから保護します。アプリケーションをホストするワークロードをプライベートサブネットにデプロイします。プライベートサブネットは、インターネットと直接アクセスすることはできません。
![\[インターネットゲートウェイ、 AWS WAFおよびロードバランサーを介して VPC にアクセスするインターネットからのトラフィック。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
組織に VPC が多数ある場合は、専用の AWS アカウントと共有のアカウントにインターフェイス VPC エンドポイント、またはプライベートホストゾーンを作成することで、一般的な AWS のサービス を共有できます。詳細については、[「インターフェイス VPC エンドポイント AWS のサービス を使用した へのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink ドキュメント）」および[「プライベートホストゾーンの使用](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (Route 53 ドキュメント）」を参照してください。
次の図は、組織全体で共有できるリソース AWS アカウント をホストする の例を示しています。VPC エンドポイントは、専用 VPC で作成すると複数のアカウントで共有できます。VPC エンドポイントを作成する場合、オプションで、エンドポイントの DNS エントリを AWS に管理させることができます。エンドポイントを共有するには、このオプションをオフにし、別の Route 53 プライベートホストゾーン (PHZ) に DNS エントリを作成します。その後、PHZ を組織内のすべての VPC に関連付けると、VPC エンドポイントの一元的な DNS 解決を行うことができます。また、トランジットゲートウェイのルートテーブルに、共有 VPC から他の VPC へのルートが含まれていることを確認する必要があります。詳細については、[「インターフェイス VPC エンドポイントへの集中アクセス](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints)」(AWS ホワイトペーパー) を参照してください。
![\[他のメンバーアカウントと共有するためのサービスエンドポイントとリソースをホストする共有アカウント。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
共有 AWS アカウント は、 AWS Service Catalog ポートフォリオをホストするのにも最適な場所です。*ポートフォリオ*は、デプロイに使用する IT サービスのコレクションであり AWS、ポートフォリオにはそれらのサービスの設定情報が含まれています。共有アカウントでポートフォリオを作成し、組織と共有できます。その後、各メンバーアカウントはポートフォリオを独自のリージョン Service Catalog インスタンスにインポートします。詳細については、「[AWS Organizationsとの共有](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations)」(Service Catalog ドキュメント) を参照してください。
同様に、Amazon VPC Lattice では、共有アカウントを使用して環境テンプレートとサービステンプレートをエンティティとして一元管理し、組織メンバーアカウントとのアカウント接続を設定できます。詳細については、[「VPC Lattice エンティティを共有する](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html)」(VPC Lattice ドキュメント) を参照してください。