翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ネットワーク **Topics** + [を使用したリージョン間ピアリングの設定を自動化する AWS Transit Gateway](automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.md) + [AWS Transit Gateway を使用してネットワーク接続を一元化](centralize-network-connectivity-using-aws-transit-gateway.md) + [Application Load Balancer を使用して Oracle WebLogic 上の Oracle JD Edwards EnterpriseOne の HTTPS 暗号化を設定します](configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.md) + [プライベートネットワーク経由でアプリケーション移行サービスのデータプレーンをコントロールプレーンに接続](connect-to-application-migration-service-data-and-control-planes-over-a-private-network.md) + [AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成します。](create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.md) + [Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する](multi-region-ipam-architecture.md) + [の Amazon CloudWatch アラートをカスタマイズする AWS Network Firewall](customize-amazon-cloudwatch-alerts-for-aws-network-firewall.md) + [Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする](deploy-resources-wavelength-zone-using-terraform.md) + [DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する](migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.md) + [F5 から AWS のApplication Load Balancer に移行するときの HTTP ヘッダーを変更](modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.md) + [複数の でインバウンドインターネットアクセスに関する Network Access Analyzer の検出結果のレポートを作成する AWS アカウント](create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.md) + [マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する](set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.md) + [ELB ロードバランサーに TLS 終了が必要であることを確認](verify-that-elb-load-balancers-require-tls-termination.md) + [Splunk を使用して AWS Network Firewall のログとメトリクスを表示する](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md) + [その他のパターン](networking-more-patterns-pattern-list.md) # を使用したリージョン間ピアリングの設定を自動化する AWS Transit Gateway *Ram Kandaswamy (Amazon Web Services)* ## 概要 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は、中央ハブを介して仮想プライベートクラウド (VPCs) とオンプレミスネットワークを接続します。Transit Gateway トラフィックはパブリックインターネットを経由しないため、一般的なエクスプロイトや分散型サービス拒否 (DDoS) 攻撃などの脅威ベクトルが軽減されます。 2 つ以上の 間で通信する必要がある場合は AWS リージョン、リージョン間 Transit Gateway ピアリングを使用して、異なるリージョンの Transit Gateway 間でピアリング接続を確立できます。ただし、Transit Gateway とのリージョン間ピアリングを手動で設定すると、複雑で時間がかかる場合があります。このパターンは、Infrastructure as Code (IaC) を使用してピアリングをセットアップするためのガイダンスを提供します。このアプローチは、複数のリージョンを繰り返し設定する必要がある場合や、マルチリージョンの組織設定 AWS アカウント に使用することができます。 このパターンは、Amazon CloudWatch Logs の AWS Step Functions [ワークフロー](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html)、関数、 AWS Identity and Access Management (IAM) [ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)、[ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)を含む [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)スタックを設定します。 AWS Lambda [https://docs.aws.amazon.com/lambda/latest/dg/concepts-basics.html#gettingstarted-concepts-function](https://docs.aws.amazon.com/lambda/latest/dg/concepts-basics.html#gettingstarted-concepts-function)次に、Step Functions ワークフローを実行して、トランジットゲートウェイのリージョン間ピアリング接続を作成します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + [Kiro](https://kiro.dev/#what-is-kiro) などのコード生成機能を持つ IDE。 + Amazon Simple Storage Service (Amazon S3) バケットとそのバケットにオブジェクトをアップロードするためのアクセス許可。 + リクエスト元のリージョンと受け入れ先のリージョンで作成されたトランジットゲートウェイ。 + リクエスト元のリージョンと受け入れ先のリージョンで作成された VPCs。VPCsを持つ `addToTransitGateway`キーをタグ付けします`true`。 + 要件に従って VPCs 用に設定された[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)。 + 要件に従って VPCs 用に設定された[ネットワークアクセスコントロールリスト (ACLs)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)。 **制限事項** + 一部の のみがリージョン間ピアリング AWS リージョン をサポートしています。リージョン間ピアリングをサポートするリージョンの完全なリストについては、[AWS Transit Gateway FAQs](https://aws.amazon.com/transit-gateway/faqs/)を参照してください。 ## アーキテクチャ このパターンで説明されているエージェント AI 開発アプローチには、次のステップが含まれます。 1. **自動化プロンプトを定義する** – Kiro は、ピアリング要件の詳細を示す自然言語プロンプトを受け取ります。 1. **自動化スクリプトの生成** – Kiro は、提供されたプロンプトに基づいて CloudFormation スクリプトと Lambda スクリプトを生成します。 1. **スタックをデプロイ**する – Kiro は CloudFormation を使用して必要なリソースをデプロイします。 1. **ピアリングの設定** – Kiro は Step Functions ワークフローを実行します。このワークフローは Lambda 関数を呼び出してピアリング接続を作成し、ルートテーブルを変更します。 次の図は、Step Functions ワークフローを示しています。 ![\[トランジットゲートウェイピアリング用の Lambda 関数を呼び出すための Step Function ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b678bb87-c7b9-4f7b-b26e-eaac650e5d1b/images/2f235f47-5d68-492c-b954-7dc170939cae.png) ワークフローの主なステップは、次のとおりです。 1. Step Functions ワークフローは、Transit Gateway ピアリングの Lambda 関数を呼び出します。  1. ワークフローは 1 分間待機します。 1. ワークフローはピアリングステータスを取得し、条件ブロックに送信します。ブロックがルーピングを実行します。  1. 成功条件が満たされない場合、ワークフローはタイマーステージに移行するようにコーディングされます。  1. 成功条件が満たされた場合、Lambda 関数はルートテーブルを変更します。 1. Step Functions ワークフローは終了します。 ## ツール + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。  + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[ (](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)[)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、リソースの使用を認証および認可されたユーザーを制御することで、 AWS リソースへのアクセスを安全に管理できます。 + [Kiro](https://kiro.dev/#what-is-kiro) は、スペック駆動型開発を通じて本番環境対応のアプリケーションを構築するのに役立つエージェント AI 開発ツールです。  + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。   ## エピック ### Lambda および Step Functions コードを生成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロンプトプレースホルダーに特定の詳細を入力する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html)または、ファイルをコンテキストにアタッチせずに、上記の変数を参照するインラインプロンプトとして追加することもできます。 | AWS 全般、ネットワーク管理者 | | ピアリングアタッチメントを作成する Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者、プロンプトエンジニアリング | | ピアリングアタッチメントのステータスをポーリングする Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者、プロンプトエンジニアリング | | 両方のリージョンに静的ルートを追加する Lambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般、ネットワーク管理者 | | CloudFormation テンプレートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS DevOps、AWS 全般、プロンプトエンジニアリング | ### AWS リソースをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロンプトを使用して CloudFormation スタックをデプロイします。 | 次のプロンプトを入力します。
Using the outputs from Prompts 1-4, package and deploy the full stack. Steps:

1. For each of the three Python files from Prompts 1-3, create a zip named after the file (e.g. peer-transit-gateway.zip that contains peer-transit-gateway.py).
2. Upload all three zips to S3_BUCKET.
3. Deploy the CloudFormation template from Prompt 4 to ACTIVE_REGION with S3BucketName=S3_BUCKET and CAPABILITY_NAMED_IAM.
4. Initiate the Step Function from the deployed stack.

Zip file names must match the S3Key values in the template exactly.
| AWS DevOps、クラウド管理者、AWS 全般、プロンプトエンジニアリング | | デプロイを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-setup-of-inter-region-peering-with-aws-transit-gateway.html) | AWS 全般 | ## 関連リソース + [Step Functions でステートマシンの実行を開始する](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-state-machine-executions.html) + [Transit Gateway ピアリングアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html) + [AWS リージョン を使用した 間の VPCs相互接続 AWS Transit Gateway](https://www.youtube.com/watch?v=cj1rQqLxXU8) (ビデオ) # AWS Transit Gateway を使用してネットワーク接続を一元化 *Mydhili Palagummi、Nikhil Marrapu (Amazon Web Services)* ## 概要 このパターンでは、AWS Transit Gateway を使用して、オンプレミスネットワークを AWS リージョン内の複数の AWS アカウントの仮想プライベートクラウド (VPC) に接続できる最も単純な構成を示しています。この設定を使用して、リージョン内の複数の VPC ネットワークとオンプレミスネットワークを接続するハイブリッドネットワークを確立できます。これは、トランジットゲートウェイと、オンプレミスネットワークへの仮想プライベートネットワーク (VPN) 接続を使用することで達成されます。 ## 前提条件と制限事項 **前提条件 ** + AWS Organizations の組織のメンバーアカウントとして管理される、ネットワークサービスをホストするためのアカウント + Classless Inter-Domain Routing (CIDR) ブロックが重複しない、複数の AWS アカウントの VPC **制限事項** このパターンでは、特定の VPC 間またはオンプレミスネットワーク間のトラフィックの分離をサポートしません。トランジットゲートウェイに接続されているすべてのネットワークは、相互にアクセスできるようになります。トラフィックを分離するには、トランジットゲートウェイでカスタムルートテーブルを使用する必要があります。このパターンでは、最も単純な構成である単一のデフォルトトランジットゲートウェイルートテーブルを使用して、VPC とオンプレミスネットワークのみを接続します。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Transit Gateway + AWS Site-to-Site VPN + VPC + AWS Resource Access Manager (AWS RAM) **ターゲットアーキテクチャ** ![\[AWS Transit Gateway はオンプレミスネットワークを、リージョン内の複数の AWS アカウントにある VPC に接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e23f5faf-e75e-42a3-80e3-142516a2db4e/images/1ecf7e04-bbf8-4304-88c8-6aceb7271d1e.jpeg) ## ツール **AWS サービス** + 「[AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)」 は、AWS アカウント、組織単位、または AWS Organizations の組織全体でリソースを安全に共有するのに役立ちます。 + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを接続する中央ハブです。 ## エピック ### ネットワークサービスアカウントでのトランジットゲートウェイの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | transit gateway を作成します。 | ネットワークサービスをホストする AWS アカウントで、ターゲット AWS リージョンにトランジットゲートウェイを作成します。手順については、「[トランジットゲートウェイの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#create-tgw)」を参照してください。次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-network-connectivity-using-aws-transit-gateway.html) | ネットワーク管理者 | ### オンプレミスネットワークをトランジットゲートウェイに接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPN 接続のカスタマーゲートウェイデバイスを設定します。 | カスタマーゲートウェイデバイスは、トランジットゲートウェイとオンプレミスネットワーク間の、Site-to-Site VPN 接続のオンプレミス側に接続されています。詳細については、AWS Site-to-Site VPN ユーザーガイドの「[カスタマーゲートウェイデバイス](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html)」を参照してください。適用されるオンプレミスの顧客デバイスを特定または起動し、そのパブリック IP アドレスを書き留めます。VPN の設定は、このエピックの後半で完了します。 | ネットワーク管理者 | | ネットワークサービスアカウントで、トランジットゲートウェイへの VPN アタッチメントを作成します。 | 接続をセットアップするには、トランジットゲートウェイの VPN アタッチメントを作成します。手順については、「[トランジットゲートウェイ VPN アタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html)」を参照してください。 | ネットワーク管理者 | | オンプレミスネットワークのカスタマーゲートウェイデバイスに、VPN を設定します。 | トランジットゲートウェイに関連付けられているSite-to-Site VPN 接続の設定ファイルをダウンロードして、カスタマーゲートウェイデバイスの VPN セッティングを設定します。手順については、「[設定ファイルをダウンロード](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html#vpn-download-config)」を参照してください。 | ネットワーク管理者 | ### ネットワークサービスアカウントのトランジットゲートウェイを、他の AWS アカウントまたは組織と共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations 管理アカウントで、共有をオンにします。 | トランジットゲートウェイを組織する、または特定の組織単位と共有するには、AWS Organizations で共有をオンにします。そうしないと、アカウントごとにトランジットゲートウェイを個別に共有する必要性がでてきます。手順については、「[AWS Organizations 内のリソース共有の有効化](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」 を参照してください。 | AWS システム管理者 | | ネットワークサービスアカウントにトランジットゲートウェイリソースシェアを作成します。 | 組織の他の AWS アカウントの VPC がトランジットゲートウェイに接続できるようにするには、ネットワークサービスアカウントで AWS RAM コンソールを使用してトランジットゲートウェイリソースを共有します。手順については、「[リソース共有の作成](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create)」 を参照してください。 | AWS システム管理者 | ### Transit Gateway に VPC を接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 個別のアカウントで VPC アタッチメントを作成します。 | トランジットゲートウェイが共有されているアカウントで、トランジットゲートウェイ VPC アタッチメントを作成します。手順については、「[VPC へのトランジットゲートウェイアタッチメントの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment)」を参照してください。 | ネットワーク管理者 | | VPC アタッチリクエストを受け入れます。 | ネットワークサービスアカウントで、トランジットゲートウェイの VPC アタッチメントリクエストを受け入れます。手順については、「[共有アタッチメントの承認](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-accept-shared-attachment)」 を参照してください。 | ネットワーク管理者 | ### ルーティングを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 個々のアカウント VPC にルートを設定します。 | 個々のアカウント VPC に、Transit Gateway をターゲットとして使用して、オンプレミスのネットワークと他の VPC ネットワークへのルートを追加します。手順については、「[ルートテーブルからのルートの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」 を参照してください。 | ネットワーク管理者 | | トランジットゲートウェイのルートテーブル内のルート。 | VPC と VPN 接続からのルートは伝達され、トランジットゲートウェイのデフォルトルートテーブルに表示されるはずです。必要に応じて、トランジットゲートウェイのデフォルトルートテーブルに静的ルート (静的 VPN 接続のための静的ルートが一例) を作成します。手順については、「[静的ルートの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#tgw-create-static-route)」 を参照してください。 | ネットワーク管理者 | | セキュリティグループとネットワークをアクセスコントロールリスト (ACL)ルールに加えます。 | EC2 インスタンスと VPC 内のその他のリソースについては、セキュリティグループルールルールとネットワーク ACL ルールが 、VPC とオンプレミスネットワーク間のトラフィックを許可していることを確認します。手順については、「[セキュリティグループを使用してリソースへのトラフィックを制御](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」 と「[ACL にルールを追加または削除](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)」 を参照してください。 | ネットワーク管理者 | ### 接続テスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC 間の接続をテストします。 | ネットワーク ACL とセキュリティグループが、インターネット制御メッセージプロトコル (ICMP) トラフィックを許可することを確認し、次にVPC 内のインスタンスから、同じくトランジットゲートウェイに接続されている別の VPCへのネットワーク接続を確認します。 | ネットワーク管理者 | | VPC とオンプレミスネットワーク間の接続をテストします。 | ネットワーク ACL ルール、セキュリティグループルール、およびファイアウォールが ICMP トラフィックを許可することを確認し、オンプレミスネットワークと VPC の EC2 インスタンス間の接続を確認します。VPNを `UP` ステータスに接続させるには、まずオンプレミスネットワークからネットワーク通信を開始する必要があります。 | ネットワーク管理者 | ## 関連リソース + [スケーラブルでセキュアなマルチ VPC の AWS ネットワークインフラストラクチャを構築する](https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf) (AWS ホワイトペーパー） + 「[共有リソースの使用](https://docs.aws.amazon.com/ram/latest/userguide/working-with.html)」 (AWS RAM ドキュメント) + 「[トランジットゲートウェイの操作](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html)」 (AWS Transit Gateway ドキュメント) # Application Load Balancer を使用して Oracle WebLogic 上の Oracle JD Edwards EnterpriseOne の HTTPS 暗号化を設定します *Amazon Web Services、Thanigaivel Thirumalai* ## 概要 このパターンは、Oracle WebLogic ワークロード上の Oracle JD Edwards EnterpriseOne で SSL オフロード用に HTTPS 暗号化を設定する方法を説明しています。この方法では、ユーザーのブラウザとロードバランサー間のトラフィックを暗号化して、EnterpriseOne サーバーにかかる暗号化の負担を軽減します。 多くのユーザーは、「[AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」を使用して EnterpriseOne JAVA 仮想マシン (JVM) 階層を水平方向にスケーリングしています。ロードバランサーは、クライアントの単一窓口として機能し、複数の JVM に受信トラフィックを分散する。オプションで、ロードバランサーはトラフィックを複数のアベイラビリティーゾーンに分散し、EnterpriseOne の可用性を高めることができます。 このパターンで説明するプロセスでは、ロードバランサーと EnterpriseOne JVM 間のトラフィックを暗号化する代わりに、ブラウザとロードバランサー間の暗号化を設定します。このアプローチは *SSL オフロード*と呼ばれます。SSL 復号化プロセスを EnterpriseOne ウェブサーバーまたはアプリケーションサーバーからApplication Load Balancer にオフロードすることで、アプリケーション側の負担が軽減されます。ロードバランサーで SSL が終了すると、暗号化されていないトラフィックは AWS 上のアプリケーションにルーティングされます。 「[Oracle JD Edwards EnterpriseOne](https://www.oracle.com/applications/jd-edwards-enterpriseone/)」は、製品や物理的資産の製造、建設、流通、サービス、管理を行う組織向けのエンタープライズ・リソース・プランニング (ERP) ソリューションです。JD Edwards EnterpriseOne は、さまざまなハードウェア、オペレーティングシステム、データベースプラットフォームをサポートしています。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + AWS Identity and Access Management (IAM) ロール。AWS サービスコールを実行し、AWS リソースを管理します。 + SSL 証明書 **製品バージョン** + このパターンは Oracle WebLogic 12c でテストされていますが、他のバージョンを使用することもできます。 ## アーキテクチャ SSL オフロードを実行するには複数の方法があります。このパターンでは、次の図に示すように、Application Load Balancer と Oracle HTTP Server (OHS) を使用します。 ![\[ロードバランサーと OHS による SSL オフロード\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/2ae2d0eb-b9f3-41f8-ad86-9af3aade7072.png) 次の図は、JD Edwards EnterpriseOne、Application Load Balancer、および Java アプリケーションサーバー (JAS) JVM レイアウトを示しています。 ![\[エンタープライズワン、ロードバランサー、および JAS JVM レイアウト\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c62b976b-31e4-42ca-b7e8-13f7c9d9a187/images/72ea35b0-2907-48b3-aeb7-0c5d9a3b831b.png) ## ツール **AWS サービス** + 「[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)」は、複数のアベイラビリティゾーンにある Amazon Elastic Compute Cloud (Amazon EC2 インスタンス) などの複数のターゲットに、受信するアプリケーショントラフィックを分散する。 + 「[AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)」は、AWS ウェブサイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 ## ベストプラクティス + ACM のベストプラクティスについては、「[ACM のドキュメント](https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html)」を参照してください。 ## エピック ### WebLogic と OHS をセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle コンポーネントのインストールと設定。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | | WebLogic プラグインの名前を、ドメインレベルで有効にします。 | 負荷分散には WebLogic プラグインが必要です。プラグインを有効にするには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | | 設定ファイルを編集します。 | `mod_wl_ohs.conf` ファイルでは OHS から WebLogic へのプロキシリクエストを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)


WLSRequest On
SetHandler weblogic-handler
WebLogicHost localhost
WebLogicPort 8000
WLProxySSL On
WLProxySSLPassThrough On

| JDE CNC、WebLogic 管理者 | | エンタープライズマネージャーを使用して OHS を起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | JDE CNC、WebLogic 管理者 | ### Application Load Balancer の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットグループを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)詳細な手順については、「[Elastic Load Balancing のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」を参照してください。 | AWS 管理者 | | ロードバランサーの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html) | AWS 管理者 | | Route 53 (DNS) レコードを追加します。 | (オプション) サブドメインに Amazon Route 53 DNS レコードを追加できます。このレコードは、Application Load Balancer を指します。手順については、「[Route 53 ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」を参照してください。 | AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | HTTP サーバーは表示されません。 | Enterprise Manager コンソールの **[ターゲットナビゲーション]** リストに **[HTTP サーバー]** が表示されない場合は、以下の手順に従ってください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-https-encryption-for-oracle-jd-edwards-enterpriseone-on-oracle-weblogic-by-using-an-application-load-balancer.html)インスタンスが作成され、変更が有効になると、**[ターゲットナビゲーションパネル]** に HTTP サーバーが表示されます。 | ## 関連リソース **AWS ドキュメント** + [アプリケーション ロード バランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + 「[パブリックホストゾーンの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html)」 + 「[プライベートホストゾーンの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)」 Oracle ドキュメンテーション: + 「[Oracle WebLogic サーバープロキシープラグインの概要](https://docs.oracle.com/middleware/1221/webtier/develop-plugin/overview.htm#PLGWL391)」 + 「[インフラストラクチャー・インストーラを使用した WebLogic Server のインストール](https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/02-01-004-InstallWLSInfrastructure/installweblogicinfrastructure.html)」 + 「[Oracle HTTP サーバーのインストールと設定](https://docs.oracle.com/middleware/1221/core/install-ohs/toc.htm)」 # プライベートネットワーク経由でアプリケーション移行サービスのデータプレーンをコントロールプレーンに接続 *Dipin Jain、Mike Kuznetsov (Amazon Web Services)* ## 概要 このパターンでは、インターフェイス VPC エンドポイントを使用して、プライベートで保護されたネットワーク上の AWS Application Migration Service データプレーンとコントロールプレーンに接続する方法について説明します。 Application Migration Service は、アプリケーションの移行を簡素化、迅速化、削減する高度に自動化されたlift-and-shift (リホスト) ソリューションです AWS。企業はこのサービスを使用することで、互換性の問題、パフォーマンスの中断、または長いカットオーバー期間に悩まされることなく、数多くの物理サーバー、仮想サーバー、またはクラウドサーバーをリホストできるようになります。アプリケーション移行サービスは、 AWS マネジメントコンソールから使用できます。これにより AWS のサービス、Amazon CloudWatch AWS CloudTrailや AWS Identity and Access Management (IAM) などの他の とシームレスに統合できます。 Site-to-Site VPN サービス、または Application Migration Service の VPC ピアリングを使用して AWS Direct Connect、プライベート接続を介して、ソースデータセンターからデータプレーン、つまり宛先 VPC 内のデータレプリケーションのステージングエリアとして機能するサブネットに接続できます。また、 を搭載した[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)を使用して AWS PrivateLink 、プライベートネットワーク経由で Application Migration Service コントロールプレーンに接続することもできます。  ## 前提条件と制限事項 **前提条件** + **ステージングエリアサブネット** – Application Migration Service を設定する前に、ソースサーバーから AWS (つまり、データプレーン) にレプリケートされるデータのステージングエリアとして使用するサブネットを作成します。アプリケーション移行サービスコンソールに初めてアクセスする場合、[レプリケーション設定テンプレート](https://docs.aws.amazon.com/mgn/latest/ug/template-vs-server.html)でこのサブネットを指定する必要があります。レプリケーション設定テンプレートで、特定のソースサーバーのこのサブネットをオーバーライドできます。で既存のサブネットを使用できますが AWS アカウント、この目的のために新しい専用サブネットを作成することをお勧めします。 + **ネットワーク要件** – ステージングエリアサブネットで Application Migration Service によって起動されるレプリケーションサーバーは、 で Application Migration Service API エンドポイントにデータを送信できる必要があります。ここで`https://mgn..amazonaws.com/`、 AWS リージョン ``はレプリケート先の のコードです (例: `https://mgn.us-east-1.amazonaws.com`)。アプリケーション移行サービスソフトウェアをダウンロードするには、Amazon Simple Storage Service (Amazon S3) のサービス URL が必要となります。 + AWS レプリケーションエージェントのインストーラは、Application Migration Service AWS リージョン で使用している の Amazon Simple Storage Service (Amazon S3) バケット URL にアクセスできる必要があります。 + ステージングエリアのサブネットは、Amazon S3 にアクセスできる必要があります。 + AWS レプリケーションエージェントがインストールされているソースサーバーは、ステージングエリアサブネットのレプリケーションサーバーと の Application Migration Service API エンドポイントにデータを送信できる必要があります`https://mgn..amazonaws.com/`。 以下の表では、必要なポートを示しています。 | | | ソース | 目的地 | ポート | 詳細については、以下を参照 | | --- |--- |--- |--- | | ソースデータセンター | Amazon S3 サービスの URL | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | | ソースデータセンター | アプリケーション移行サービスのAWS リージョン固有のコンソールアドレス | 443 (TCP) | [TCP ポート 443 を介したソースサーバーとアプリケーション移行サービス間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Source-Manager-TCP-443) | | ソースデータセンター | ステージングエリアのサブネット | 1500 (TCP) | [TCP ポート 1500 を介したソースサーバーとステージングエリアサブネット間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-1500) | | ステージングエリアのサブネット | アプリケーション移行サービスのAWS リージョン固有のコンソールアドレス | 443 (TCP) | [TCP ポート 443 を介したステージングエリアサブネットとアプリケーション移行サービス間の通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#Communication-TCP-443-Staging) | | ステージングエリアのサブネット | Amazon S3 サービスの URL | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | | ステージングエリアのサブネット | サブネットの Amazon Elastic Compute Cloud (Amazon EC2) エンドポイント AWS リージョン | 443 (TCP) | [TCP ポート 443 を介した通信](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html#TCP-443) | **制限** Application Migration Service は現在、すべての AWS リージョン およびオペレーティングシステムで利用できるわけではありません。 + [サポート AWS リージョン](https://docs.aws.amazon.com/mgn/latest/ug/supported-regions.html) + [サポートされるオペレーティングシステム](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html) ## アーキテクチャ 次の図表は、一般的な移行のネットワークアーキテクチャを示しています。このアーキテクチャの詳細については、「[アプリケーション移行サービスのドキュメント](https://docs.aws.amazon.com/mgn/latest/ug/Network-Settings-Video.html)」 と「[アプリケーション移行サービスのサービスのアーキテクチャおよびネットワークアーキテクチャのビデオ](https://youtu.be/ao8geVzmmRo)」 を参照してください。 ![\[一般的な移行のためのアプリケーション移行サービスのネットワークアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/546598b2-8026-4849-a441-eaa2bc2bf6bb.png) 次の詳細ビューは、Amazon S3 とアプリケーション移行サービスを接続するためのステージングエリア VPC のインターフェイス VPC エンドポイントの設定を示しています。 ![\[一般的な移行のアプリケーション移行サービスのネットワークアーキテクチャ — 詳細図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/21346c0f-0643-4f4f-b21f-fdfe24fc6a8f/images/bd0dfd42-4ab0-466f-b696-804dedcf4513.png) ## ツール + [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) は、 でのアプリケーションのリホストを簡素化、迅速化し、コストを削減します AWS。 + [インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)を使用すると、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要と AWS PrivateLink せずに、 を使用するサービスに接続できます。VPC のインスタンスは、サービスのリソースと通信するためにパブリック IP アドレスを必要としません。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れません。 ## エピック ### アプリケーション移行サービス、Amazon EC2、Amazon S3 のエンドポイントを作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーション移行サービスのインターフェイスエンドポイントを設定します。 | ソースデータセンターとステージングエリア VPC は、ターゲットステージングエリア VPC で作成したインターフェイスエンドポイントを介して、アプリケーション移行サービスコントロールプレーンにプライベートに接続します。エンドポイントを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)詳細については、[Amazon VPC ドキュメントの「インターフェイス VPC エンドポイント AWS のサービス を使用して にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)」を参照してください。 | 移行リード | | Amazon EC2 のインターフェイスエンドポイントを設定します。 | ステージングエリア VPC は、ターゲットのステージングエリア VPC で作成したインターフェイスエンドポイントを介して Amazon EC2 API にプライベートに接続します。エンドポイントを作成するには、前のストーリーで説明した手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html) | 移行リード | | Amazon S3 のインターフェイスエンドポイントを設定します。 | ソースデータセンターとステージングエリア VPC は、ターゲットステージングエリア VPC で作成したインターフェイスエンドポイントを介して Amazon S3 API にプライベートに接続します。エンドポイントを作成するには、最初のストーリーの手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)ゲートウェイエンドポイントの接続を VPC の外に延長することはできないため、インターフェイスエンドポイントを使用します。(詳細については [AWS PrivateLink ドキュメント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html)を参照)。 | 移行リード | | Amazon S3ゲートウェイエンドポイントの設定 | 設定フェーズでは、レプリケーションサーバーは S3 バケットに接続して AWS 、レプリケーションサーバーのソフトウェア更新をダウンロードする必要があります。ただし、Amazon S3 インターフェイスエンドポイントはプライベート DNS 名をサポートしていないため*、*Amazon S3 エンドポイント DNS 名をレプリケーションサーバーに提供する方法はありません。 この問題を軽減するには、ステージングエリアサブネットが属する VPC で Amazon S3 ゲートウェイエンドポイントを作成し、ステージングサブネットのルートテーブルを関連するルートで更新します。詳細については、 AWS PrivateLink ドキュメントの[「ゲートウェイエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3)」を参照してください。 | クラウド管理者 | | エンドポイントのプライベート DNS 名を解決するために、オンプレミス DNS を設定する | アプリケーション移行サービスと Amazon EC2 のインターフェイスエンドポイントには、VPC で解決できるプライベート DNS 名があります。ただし、これらのインターフェイスエンドポイントのプライベート DNS 名を解決するように、オンプレミスサーバーを設定する必要もあります。これらのサーバーを設定するには、複数の方法があります。このパターンでは、オンプレミスの DNS クエリをステージングエリア VPC の Amazon Route 53 Resolver インバウンドエンドポイントに転送することで、この機能をテストしました。詳細については、Route 53 ドキュメントの「[Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html)」を参照してください。 | 移行エンジニア | ### プライベートリンクを介してアプリケーション移行サービスのコントロールプレーンに接続 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | を使用して AWS レプリケーションエージェントをインストールします AWS PrivateLink。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)以下は、Linux の例です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-to-application-migration-service-data-and-control-planes-over-a-private-network.html)Application Migration Service との接続を確立し、 AWS レプリケーションエージェントをインストールしたら、[Application Migration Service ドキュメント](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)の指示に従って、ソースサーバーをターゲット VPC とサブネットに移行します。 | 移行エンジニア | ## 関連リソース 「**アプリケーション移行サービスドキュメント**」 + 「[概念](https://docs.aws.amazon.com/mgn/latest/ug/CloudEndure-Concepts.html)」 + 「[移行ワークフロー](https://docs.aws.amazon.com/mgn/latest/ug/migration-workflow-gs.html)」 + 「[クイックスタートガイド](https://docs.aws.amazon.com/mgn/latest/ug/quick-start-guide-gs.html)」 + [よくある質問](https://docs.aws.amazon.com/mgn/latest/ug/FAQ.html) + [トラブルシューティング](https://docs.aws.amazon.com/mgn/latest/ug/troubleshooting.html) **追加リソース** + [VPC インターフェイスエンドポイント AWS を使用した のマルチアカウントアーキテクチャでのアプリケーションのリホスト](https://docs.aws.amazon.com/prescriptive-guidance/latest/rehost-multi-account-architecture-interface-endpoints/) (AWS 規範ガイダンスガイド) + [AWS Application Migration Service – 技術的な概要](https://www.aws.training/Details/eLearning?id=71732) (AWS トレーニングと認定のチュートリアル) + [AWS Application Migration Service アーキテクチャとネットワークアーキテクチャ](https://youtu.be/ao8geVzmmRo) (ビデオ) ## 追加情報 **Linux サーバーでのレプリケーションエージェントのインストールの****トラブルシューティング ***AWS * Amazon Linux サーバーで **gcc** エラーが発生した場合は、パッケージリポジトリを設定し、次のコマンドを使用します。 ``` ## sudo yum groupinstall "Development Tools" ``` # AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成します。 *Amazon Web Services、Tim Sutton* ## 概要 **注意**: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/) Infoblox ドメインネームシステム (DNS)、Dynamic Host Configuration Protocol (DHCP)、IP アドレス管理 ([Infoblox DDI](https://www.infoblox.com/products/ddi/)) により、複雑なハイブリッド環境を一元化し、効率的に制御できます。Infoblox DDIを使用すると、すべてのネットワーク資産を検出して1つの信頼できるIPアドレス管理（IPAM）データベースに記録できます。また、同じアプライアンスを使用してオンプレミスとAmazon Web Services（AWS）クラウドでDNSを管理できます。 このパターンでは、AWS CloudFormation カスタムリソースを使用して Infoblox WAPI API を呼び出して Infoblox オブジェクト (DNS レコードや IP アドレス管理オブジェクトなど) を作成する方法を説明します。Infoblox WAPI の詳細については、Infoblox ドキュメントの「[WAPI ドキュメント](https://www.infoblox.com/wp-content/uploads/infoblox-deployment-infoblox-rest-api.pdf)」を参照してください。 このパターンのアプローチを使用すると、レコードを作成してネットワークをプロビジョニングする手動プロセスを排除できるだけでなく、AWS 環境とオンプレミス環境のDNSレコードとIPAM構成を一元的に把握できます。このパターンのアプローチは、以下のユースケースに使用できます。 + Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成した後で A レコードを追加する  + Application Load Balancer の作成後の CNAME レコードの追加 + 仮想プライベートクラウド (VPC) 作成後のネットワークオブジェクトの追加 + 次のネットワーク範囲を指定し、その範囲を使用してサブネットを作成する このパターンを拡張して、さまざまな DNS レコードタイプの追加や Infoblox vDiscovery の設定など、Infoblox デバイスの他の機能を使用することもできます。  このパターンでは、ハブが AWS クラウドまたはオンプレミスの Infoblox アプライアンスへの接続を必要とし、AWS Lambda を使用して Infoblox API を呼び出すハブアンドスポーク設計を採用しています。スポークは AWS Organizationsの同じまたは別のアカウントにあり、AWS CloudFormation カスタムリソースを使用して Lambda 関数を呼び出します。 ## 前提条件と制限事項 **前提条件** + AWS クラウド、オンプレミス、またはその両方にインストールされ、IPAM と DNS アクションを管理できる管理者ユーザーで構成された既存の Infoblox アプライアンスまたはグリッド。詳細については、Infoblox ドキュメントの「[管理者アカウントについて](https://docs.infoblox.com/display/nios86/About+Admin+Accounts)」を参照してください。  + Infoblox アプライアンスにレコードを追加したい既存の DNS 権限ゾーン。詳細については、Infoblox ドキュメントの「[権限のあるゾーンの設定](https://docs.infoblox.com/display/nios86/Configuring+Authoritative+Zones)」を参照してください。  + AWS Organizations 内の 2 つのアクティブな AWS アカウント。1 つのアカウントはハブアカウントで、もう 1 つのアカウントはスポークアカウントです。 + このハブとスポークアカウントは同じ AWS リージョンに存在する必要があります。  + ハブアカウントの VPC は、たとえば AWS Transit Gateway や VPC ピアリングを使用して Infoblox アプライアンスに接続する必要があります。 + 「[AWS サーバーレスアプリケーションモデル (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)」を、ローカルにインストールし、AWS Cloud9 または AWS CloudShell で設定します。 + `Infoblox-Hub.zip`および`ClientTest.yaml`ファイル（添付）は、AWS SAM を含むローカル環境にダウンロードされます。 **制限事項** + AWS CloudFormation カスタムリソースのサービストークンは、作成しているスタックと同じリージョンのものである必要があります。あるリージョンで Amazon Simple Notification Service (Amazon SNS) トピックを作成し、別のリージョンで Lambda 関数を呼び出す代わりに、各リージョンでハブアカウントを使用することをお勧めします。 **製品バージョン** + Infoblox API バージョン 2.7 ## アーキテクチャ 以下の図表に、このパターンのワークフローを示しています。  ![\[AWS CloudFormation カスタムリソースと Amazon SNS を使用して Infoblox オブジェクトを作成する。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d609d3f-6f5e-4084-849f-ca191db8055e/images/3594a064-e103-4211-84b7-da67c41ebb15.png) この図は、このパターンのソリューションを構成する以下のコンポーネントを示しています。 1. AWS CloudFormation カスタムリソースを使用すると、テンプレートにカスタムのプロビジョニングロジックを記述し、ユーザーがスタックを作成、更新、削除するたびに AWS CloudFormation がそれを実行します。スタックを作成するときに、AWS CloudFormation によって、EC2 インスタンスで実行しているアプリケーションが監視する SNS トピックに `create` リクエストを送信できます。 1. AWS CloudFormation カスタムリソースからの Amazon SNS 通知は、特定の AWS Key Management Service (AWS KMS) キーによって暗号化され、アクセスはOrganizations 内の組織内のアカウントに制限されます。SNS トピックは、Infoblox WAPI API を呼び出すLambda リソースを開始します。 1. Amazon SNS は、Infoblox WAPI URL、ユーザー名、およびパスワード AWS Secrets Manager Amazon リソースネーム (ARN) を環境変数として使用する次の Lambda 関数を呼び出します。  + `dnsapi.lambda_handler`— AWS CloudFormation カスタムリソースから`DNSName`、`DNSType`、`DNSValue`の値を受け取り、それらを使用して DNS A レコードと CNAME を作成します。 + `ipaddr.lambda_handler`— AWS CloudFormation カスタムリソースから`VPCCIDR`、`Type`、`SubnetPrefix`、`Network Name`の値を受け取り、それらを使用してネットワークデータを Infoblox IP アドレス管理データベースに追加したり、新しいサブネットの作成に使用できる次に使用可能なネットワークをカスタムリソースに提供したりします。 + `describeprefixes.lambda_handler`— `"com.amazonaws."+Region+".s3"`フィルタを使用して`describe_managed_prefix_lists` AWS API を呼び出し、必要な`prefix ID`を取得します。 **重要** これらの Lambda 関数は Python で記述されており、互いに似ていますが、呼び出す API が異なります。 1. Infoblox グリッドは、物理、仮想、またはクラウドベースのネットワークアプライアンスとしてデプロイできます。 オンプレミスで導入することも、VMware ESXi、Microsoft Hyper-V、Linux KVM、Xenなどのさまざまなハイパーバイザーを使用して仮想アプライアンスとして導入することもできます。Amazon マシンイメージ (AMI) を使用して Infoblox グリッドを AWS クラウドにデプロイすることもできます。 1. この図は、AWS クラウドとオンプレミスのリソースに DNS と IPAM を提供する Infoblox グリッドのハイブリッドソリューションを示しています。 **テクノロジースタック** + AWS CloudFormation + IAM + AWS KMS + AWS Lambda + AWS SAM + AWS Secrets Manager + Amazon SNS + Amazon VPC  ## ツール + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)」は、複数の AWS アカウントを 1 つの組織に統合し、作成と一元管理するためのアカウント管理サービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。 + 「[AWS サーバーレスアプリケーションモデル (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)」 は、 AWS クラウドのサーバーレスアプリケーションを構築するために支援するオープンソースフレームワークです。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 **Code** `ClientTest.yaml`サンプル AWS CloudFormation テンプレート (添付) を使用して Infoblox ハブをテストできます。AWS CloudFormation テンプレートをカスタマイズして、次の表のカスタムリソースを含めることができます。 | | | --- | | Infoblox スポークカスタムリソースを使用して A レコードを作成します。 | 戻り値： `infobloxref `— Infoblox のリファレンスリソースの例： ``` ARECORDCustomResource: Type: "Custom::InfobloxAPI" Properties: ServiceToken: !Sub arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxDNSFunction DNSName: 'arecordtest.company.com' DNSType: 'ARecord' DNSValue: '10.0.0.1' ``` | | --- |--- | | Infoblox スポークカスタムリソースを使用して CNAME レコードを作成します。 | **戻り値**： `infobloxref `— Infoblox のリファレンス**リソースの例**：
CNAMECustomResource:

  Type: "Custom::InfobloxAPI"

  Properties:

    ServiceToken: !Sub arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfoblox    

    DNSFunction

    DNSName: 'cnametest.company.com'

    DNSType: 'cname' 

    DNSValue: 'aws.amazon.com'
| | Infoblox スポークカスタムリソースを使用してネットワークオブジェクトを作成します。 | **戻り値**：`infobloxref `— Infoblox のリファレンス`network`— ネットワーク範囲 (と同じ) `VPCCIDR`**リソースの例**：
VPCCustomResource:

  Type: 'Custom::InfobloxAPI'

  Properties:

    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction

    VPCCIDR: !Ref VpcCIDR

    Type: VPC

    NetworkName: My-VPC
| | Infoblox スポークカスタムリソースを使用して、次に使用可能なサブネットを取得します。 | **戻り値**：`infobloxref`— Infoblox のリファレンス`network `— サブネットのネットワーク範囲**リソースの例**：
Subnet1CustomResource:

  Type: 'Custom::InfobloxAPI'

  DependsOn: VPCCustomResource

  Properties:

    ServiceToken: !Sub  arn:aws:sns:${AWS::Region}:${HubAccountID}:RunInfobloxNextSubnetFunction

    VPCCIDR: !Ref VpcCIDR

    Type: Subnet

    SubnetPrefix: !Ref SubnetPrefix

NetworkName: My-Subnet
| ## エピック ### ハブアカウントの VPC を作成して設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Infoblox アプライアンスに接続する VPC を作成します。 | ハブアカウントの AWS マネジメントコンソールにサインインし、AWS クイックスタートの「[AWS クラウドクイックスタートリファレンスデプロイの Amazon VPC ](https://aws-quickstart.github.io/quickstart-aws-vpc/)」の手順に従って VPC を作成します。VPC には Infoblox アプライアンスへの HTTPS 接続が必要です。この接続にはプライベートサブネットを使用することをお勧めします。 | ネットワーク管理者、システム管理者 | | (オプション) プライベートサブネット用の VPC エンドポイントを作成します。 | VPC エンドポイントは、プライベートサブネットのパブリックサービスへの接続を提供します。次のエンドポイントが必要です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html)プライベートサブネット用のエンドポイント作成の詳細については、Amazon VPC ドキュメントの「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html)」を参照してください。 | ネットワーク管理者、システム管理者 | ### Infoblox ハブをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS SAM テンプレートをビルドします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-infoblox-objects-using-aws-cloudformation-custom-resources-and-amazon-sns.html) | 開発者、システム管理者 | | AWS SAM テンプレートをデプロイします。 | `sam deploy`コマンドは、必要なパラメータを取得して`samconfig.toml`ファイルに保存し、AWS CloudFormation テンプレートと Lambda 関数を S3 バケットに保存し、次に AWS CloudFormation テンプレートをハブアカウントにデプロイします。 次のサンプルコードは、AWS SAM テンプレートをデプロイする方法を示しています。
$ sam deploy --guided

Configuring SAM deploy
======================
        Looking for config file [samconfig.toml] :  Found
        Reading default arguments  :  Success
        Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [Infoblox-Hub]:
        AWS Region [eu-west-1]:
        Parameter InfobloxUsername:
        Parameter InfobloxPassword:
        Parameter InfobloxIPAddress [xxx.xxx.xx.xxx]:
        Parameter AWSOrganisationID [o-xxxxxxxxx]:
        Parameter VPCID [vpc-xxxxxxxxx]:
        Parameter VPCCIDR [xxx.xxx.xxx.xxx/16]:
        Parameter VPCSubnetID1 [subnet-xxx]:
        Parameter VPCSubnetID2 [subnet-xxx]:
        Parameter VPCSubnetID3 [subnet-xxx]:
        Parameter VPCSubnetID4 []: 
        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
        Confirm changes before deploy [Y/n]: y
        #SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]: n
Capabilities [['CAPABILITY_NAMED_IAM']]:
        Save arguments to configuration file [Y/n]: y
        SAM configuration file [samconfig.toml]:
        SAM configuration environment [default]:
Infoblox のサインイン認証情報は `samconfig.toml` ファイルに保存されないため、`--guided` オプションは毎回使用する必要があります。 | 開発者、システム管理者 | ## 関連リソース + [Postman を使用して API を使い始める](https://blogs.infoblox.com/community/getting-started-with-wapis-using-postman/) (Infoblox ブログ) + [BYOL モデルを使用した AWS 向けの VNIO のプロビジョニング](https://docs.infoblox.com/display/NAIG/Provisioning+vNIOS+for+AWS+Using+the+BYOL+Model) (Infoblox ドキュメント) + [クイックスタート-AWS-VPC](https://github.com/aws-quickstart/quickstart-aws-vpc) (GitHub リポジトリ) + [describe\$1managed\$1prefix\$1lists](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_managed_prefix_lists) (AWS SDK for Python) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/8d609d3f-6f5e-4084-849f-ca191db8055e/attachments/attachment.zip)」 # Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する *Amazon Web Services、Donny Schreiber* ## 概要 *IP Address Manager (IPAM)* はネットワーク管理における重要なコンポーネントであり、組織がクラウドインフラストラクチャをスケールするにつれて、その複雑性は増加します。適切な IPAM が欠けている状態では、組織は IP アドレスの競合やアドレススペースの浪費、複雑なトラブルシューティングのリスクにさらされ、停止やアプリケーションのダウンタイムにつながる可能性があります。このパターンは、HashiCorp Terraform を使用して AWS エンタープライズ環境に包括的な IPAM ソリューションを実装する方法を示しています。これにより、組織は組織内のすべての AWS アカウント で一元化された IP アドレス管理を容易にする階層型のマルチリージョン IPAM アーキテクチャを作成できます[AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organization-structure)。 このパターンは、最上位プール、リージョンプール、ビジネスユニットプール、環境固有のプールという高度な 4 層プール階層を持つ [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) の実装に活用できます。この構造により、適切な IP アドレスガバナンスをサポートし、組織内の適切なチームに IP 管理を委任できるようになります。このソリューションは AWS Resource Access Manager (AWS RAM) を使用して、IP Address Manager プールを組織全体でシームレスに共有します。 は IPAM 仕様を AWS RAM 一元化および標準化します。この仕様は、チームがすべてのマネージドアカウントで構築できます。 このパターンを活用することで、以下の操作が可能です。 + 、ビジネスユニット AWS リージョン、環境間の IP アドレスの割り当てを自動化します。 + プログラム検証により、組織のネットワークポリシーを適用します。 + 業務ニーズに合わせてネットワークのインフラストラクチャを効率的にスケールします。 + IP アドレススペースを一元管理することで、運用上のオーバーヘッドを削減します。 + セルフサービス CIDR 範囲の割り当てにより、クラウドネイティブワークロードのデプロイを高速化します。 + ポリシーベースの制御と検証を実施することで、アドレスの競合を防ぎます。 ## 前提条件と制限 **前提条件** + 組織として管理される AWS アカウント 1 つ以上の AWS Organizations。 + IP Address Manager の委任管理者として機能するネットワークハブまたはネットワーク管理アカウント。 + AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み。 + [インストール済み](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)の Terraform、バージョン 1.5.0 以降。 + AWS Terraform のプロバイダー、[設定](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)済み。 + AWS Identity and Access Management (IAM) で設定された [IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)、[AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/security-iam.html)、および Virtual Private Cloud (VPC) を管理するためのアクセス許可。 [VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/security-iam.html) **制限事項** + IP Address Manager には [Service Quotas](https://docs.aws.amazon.com/vpc/latest/ipam/quotas-ipam.html) が適用されます。プールのデフォルトの Service Quotas は、スコープあたり 50 です。このデプロイを 6 つのリージョン、2 つのビジネスユニット、4 つの環境で実行すると、67 のプールが作成されます。したがって、クォータの引き上げが必要になる場合があります。 + リソースの割り当て後に IP Address Manager プールを変更または削除すると、依存関係の問題が発生する可能性があります。プールを削除するには、最初に[割り当てを解除](https://docs.aws.amazon.com/vpc/latest/ipam/release-alloc-ipam.html)する必要があります。 + IP Address Manager では、[リソースのモニタリング](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)でリソースの変更が反映されるのにわずかな遅延が発生する可能性があります。この遅延は約 20 分です。 + IP Address Manager は、異なるスコープにわたって IP アドレスの一意性を自動的に適用することはできません。 + カスタムタグは 「[AWS tagging best practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」に従って作成してください。例えば、各キーは一意である必要があり、`aws:` で始めることはできません。 + IP Address Manager を組織外のアカウントと統合する際には、必ず「[考慮事項と制限](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam-outside-org-considerations.html)」をご確認ください。 ## アーキテクチャ **ターゲットアーキテクチャ** *IP Address Manager の設定とプール階層* ターゲットアーキテクチャの理論コンストラクトを以下の図に示します。*スコープ*は、IP Address Manager の最上位コンテナです。それぞれのスコープは、単一ネットワークの IP アドレススペースを表します。*プール*とは、スコープ内の連続した IP アドレス範囲 (または CIDR 範囲) のコレクションです。プールを使用すると、ルーティングとセキュリティのニーズに応じて IP アドレスを整理できます。この図は、最上位プール、リージョンプール、ビジネスユニットプール、環境プールの 4 つの階層レベルのプールを示しています。 ![\[ネットワークアカウントの単一の AWS リージョン内のプライベートスコープと 4 レベルのプール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/1e23b2a7-a274-4a19-9097-61d8a31dfbf8.png) このソリューションは、IP Address Manager プールの明確な階層を確立します。 1. 最上位プールには、`10.176.0.0/12` などの組織の IP アドレススペース全体が含まれます。 1. リージョンプールは、`us-east-1` に対しての `10.176.0.0/15` といった、リージョン固有の割り当てを行う際に機能します。 1. ビジネスユニットプールは、各 内のドメイン固有の割り当てです AWS リージョン。例えば、`us-east-1` リージョンの財務ビジネスユニットでは `10.176.0.0/16` を保有している場合があります。 1. 環境プールは、さまざまな環境に対する目的固有の割り当てです。例えば、`us-east-1` リージョンの財務ビジネスユニットでは、本番環境用に `10.176.0.0/18` を保有している場合があります。 このデプロイトポロジは、一元化された制御を維持しながら、IP Address Manager リソースを地理的に分散します。以下はその機能です。 + IP Address Manager は 1 つのプライマリにデプロイされます AWS リージョン。 + 追加のリージョンは、IP Address Manager がリソースを管理できる[運用リージョン](https://docs.aws.amazon.com/vpc/latest/ipam/mod-ipam-region.html)として登録されます。 + 各運用リージョンは、最上位プールから専用アドレスプールを受け取ります。 + すべての運用リージョンのリソースは、プライマリリージョンの IP Address Manager を通じて一元管理されます。 + 各リージョンプールには、リソースの適切な割り当てに役立つロケールプロパティがリージョンに関連付けられています。 *高度な CIDR 範囲の検証* このソリューションは、無効な設定のデプロイを防ぐように設計されています。Terraform を介してプールをデプロイすると、Terraform 計画フェーズ中に以下が検証されます。 + すべての環境 CIDR 範囲が親ビジネスユニットの CIDR 範囲に含まれていることを検証します + すべてのビジネスユニット CIDR 範囲が親リージョンの CIDR 範囲内に含まれていることを確認します + すべてのリージョンの CIDR 範囲が最上位 CIDR 範囲に含まれていることを確認します + 同じ階層レベル内で重複する CIDR 範囲をチェックします + 環境とそれぞれのビジネスユニットの適切なマッピングを検証します *CIDR 範囲の割り当て* 次の図は、開発者または管理者が新規 VPC を作成し、プールレベルから IP アドレスを割り当てる手法のサンプルを示しています。 ![\[ネットワークアカウントの単一の AWS リージョン内のプライベートスコープと 4 レベルのプール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780e344e-37f7-4b70-8d7c-94ec67a29305/images/7c3de2e3-e71b-4fc0-abcd-7e88cfab5c87.png) この図表は、次のワークフローを示しています: 1. 開発者または管理者は AWS マネジメントコンソール、、 AWS CLI、またはInfrastructure as Code (IaC) を通じて、`AY3`環境プールで次に使用可能な CIDR 範囲をリクエストします。 1. IP Address Manager は、そのプールで次に使用可能な CIDR 範囲を `AY3-4` VPC に割り当てます。この CIDR 範囲は使用できなくなりました。 **自動化とスケール** このソリューションは、次のようにスケーラビリティを実現するように設計されています。 + **リージョン拡張** – リージョンプールエントリを追加して Terraform 設定を拡張することで、新しいリージョンを追加します。 + **ビジネスユニットの成長** – BU 設定マップに追加することで、新しいビジネスユニットをサポートします。 + **環境の柔軟性** – 組織のニーズに基づいて、開発や本番環境などのさまざまな環境タイプを設定します。 + **マルチアカウントサポート** – を通じて組織内のすべてのアカウント間でプールを共有します AWS RAM。 + **自動 VPC プロビジョニング** – VPC プロビジョニングワークフローと統合して、CIDR 範囲の割り当てを自動化します。 階層構造では、次のようなさまざまな委任と制御のスケールも許可されます。 + ネットワーク管理者は、最上位プールとリージョンプールを管理する場合があります。 + ビジネスユニットの IT チームは、それぞれのプールの管理を委任している可能性があります。 + アプリケーションチームは、指定された環境プールの IP アドレスを使用する場合があります。 **注記** このソリューションを [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) と統合することもできます。詳しくは、本パターンの「[追加情報](#multi-region-ipam-architecture-additional)」セクションの「*AFT との統合*」をご確認ください。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) は、 間でリソースを安全に共有 AWS アカウント し、運用オーバーヘッドを削減し、可視性と監査性を提供します。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。[IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) は Amazon VPC の機能です。 AWS ワークロードの IP アドレスを計画、追跡、モニタリングするのに役立ちます。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのを支援する Infrastructure as Code (IaC) ツールです。 **コードリポジトリ** このパターンのコードは、GitHub の「[Sample Terraform Implementation for Hierarchical IPAM on AWS](https://github.com/aws-samples/sample-amazon-vpc-ipam-terraform)** **repository」から入手できます。リポジトリ構造には以下が含まれます。 + **ルートモジュール** – デプロイオーケストレーション変数と入力変数。 + **IPAM モジュール** – このパターンで説明されているアーキテクチャのコア実装。 + **タグモジュール** – すべてのリソースに標準化されたタグ。 ## ベストプラクティス ネットワークの計画時は、以下のベストプラクティスを参照してください。 + **最初に計画する** – デプロイ前に IP アドレススペースを慎重に計画します。詳しくは「[IP アドレスのプロビジョニング計画](https://docs.aws.amazon.com/vpc/latest/ipam/planning-ipam.html)」をご確認ください。 + **CIDR 範囲の重複を避ける** – 各レベルの CIDR 範囲が重複しないようにしてください。 + **バッファスペースを確保する** – 増加に対応できるよう、CIDR 範囲は常に広めに割り当てるようにしましょう。 + **IP アドレス割り当てのドキュメント** – IP アドレス割り当て戦略のドキュメントを管理します。 デプロイにおけるベストプラクティスを以下からご確認ください。 + **非本番環境から始める** – まず非本番環境にデプロイします。 + **Terraform 状態管理を活用する** – リモート状態ストレージとロックを実装します。詳しくは Terraform ドキュメントの「[State storage and locking](https://developer.hashicorp.com/terraform/language/state/backends)」をご確認ください。 + **バージョン管理の実装** – Terraform コードのバージョンをすべて管理します。 + **CI/CD 統合の実装** – 反復可能なデプロイには、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用します。 オペレーションにおいては以下のベストプラクティスを参考にしてください。 + **自動インポートを有効にする** – 既存のリソースを自動的に検出してインポートするように IP Address Manager プールを設定します。「[IPAM プールを編集する](https://docs.aws.amazon.com/vpc/latest/ipam/mod-pool-ipam.html)」に記載の手順に従って、自動インポートを有効にします。 + **IP アドレス使用率のモニタリング** – IP アドレス使用率のしきい値のアラームを設定します。詳しくは「[Amazon CloudWatch で IPAM をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html)」をご確認ください。 + **定期的な監査** — IP アドレスの使用状況とコンプライアンスを定期的に監査します。詳しくは「[IPAM での IP アドレス使用状況の追跡](https://docs.aws.amazon.com/vpc/latest/ipam/tracking-ip-addresses-ipam.html)」をご確認ください。 + **使用していない割り当てを削除する** – リソースが廃止された際には IP アドレス割り当てを解放しましょう。詳しくは「[プールから CIDR のプロビジョニングを解除するには](https://docs.aws.amazon.com/vpc/latest/ipam/depro-pool-cidr-ipam.html)」をご確認ください。 セキュリティ面では以下のベストプラクティスを参考にしてください。 + **最小特権を実装する** – 必要最低限のアクセス権を付与した IAM ロールを使用します。詳しくは「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」および「[IPAM での Identity and Access Management](https://docs.aws.amazon.com/vpc/latest/ipam/iam-ipam.html)」をご確認ください。 + **サービスコントロールポリシーを使用する** – サービスコントロールポリシー (SCP) を実装して、組織で IP Address Manager の使用を強制します。詳しくは「[SCP を使用して VPC 作成に IPAM の使用を強制する](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html)」をご確認ください。 + **リソース共有の制御** – で IP Address Manager リソース共有の範囲を慎重に管理します AWS RAM。詳細については、「 [を使用して IPAM プールを共有する AWS RAM](https://docs.aws.amazon.com/vpc/latest/ipam/share-pool-ipam.html)」を参照してください。 + **タグ付けを強制する** – IP Address Manager に関連するすべてのリソースに必須のタグ付けを実装します。詳しくは「[追加情報](#multi-region-ipam-architecture-additional)」セクションの「*タグ付け戦略*」をご確認ください。 ## エピック ### IP Address Manager の委任管理者アカウントを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Organizations 機能を有効にします。 | AWS Organizations ですべての機能が有効になっていることを確認します。手順については、 AWS Organizations ドキュメントの「 [を使用して組織のすべての機能を有効にする AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)」を参照してください。 | AWS 管理者 | | でリソース共有を有効にします AWS RAM。 | を使用して AWS CLI、次のコマンドを入力して、組織の AWS RAM リソース共有を有効にします。
aws ram enable-sharing-with-aws-organization
詳細については、 AWS RAM ドキュメントの「 [内でリソース共有を有効にする AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」を参照してください。 | AWS 管理者 | | IP Address Manager の管理者を指定します。 | 組織の管理アカウントから、 を使用して AWS CLI次のコマンドを入力します。ここで、 `123456789012` は IP Address Manager を管理するアカウントの ID です。
aws ec2 enable-ipam-organization-admin-account \
    --delegated-admin-account-id 123456789012
通常、ネットワークまたはネットワークハブアカウントは、IP Address Manager の委任管理者として使用されます。詳細については、[「IP Address Manager ドキュメント」の「Integrate IPAM with accounts in an AWS Organization](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html)」を参照してください。 | AWS 管理者 | ### インフラストラクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ネットワークアーキテクチャを定義します。 | リージョン、ビジネスユニット、環境の CIDR 範囲など、ネットワークアーキテクチャを定義して文書化します。詳しくは IP Address Manager ドキュメントの「[IP アドレスのプロビジョニング計画](https://docs.aws.amazon.com/vpc/latest/ipam/planning-ipam.html)」をご確認ください。 | ネットワークエンジニア | | リポジトリのクローン作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | DevOps エンジニア | | 変数を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | ネットワークエンジニア、Terraform | | IP Address Manager リソースをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | Terraform | | デプロイを検証する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | AWS 全般、ネットワークエンジニア | ### VPC を作成してモニタリングを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | Amazon VPC ドキュメントの「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」の手順に従ってください。VPC の CIDR 範囲を選択するステップに到達したら、リージョン、ビジネスユニット、環境プールのいずれかから利用可能な範囲を割り当てます。 | AWS 全般、ネットワーク管理者、ネットワークエンジニア | | CIDR 範囲の割り当てを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-region-ipam-architecture.html) | AWS 全般、ネットワーク管理者、ネットワークエンジニア | | IP Address Manager をモニタリングします。 | IP Address Manager リソースの割り当てに関連するモニタリングとアラームを設定します。手順について、詳しくは IP Address Manager ドキュメントの「[Amazon CloudWatch で IPAM をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/cloudwatch-ipam.html)」および「[リソースごとに CIDR の使用状況をモニタリングする](https://docs.aws.amazon.com/vpc/latest/ipam/monitor-cidr-compliance-ipam.html)」をご確認ください。 | AWS 全般 | | IP Address Manager の使用を強制します。 | 組織内のメンバーが VPC を作成するときに IP Address Manager を使用すること AWS Organizations を要求するサービスコントロールポリシー (SCP) を に作成します。手順については IP Address Manager ドキュメントの「[SCP を使用して VPC 作成に IPAM の使用を強制する](https://docs.aws.amazon.com/vpc/latest/ipam/scp-ipam.html)」を参照してください。 | 一般的な AWS、AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Terraform が失敗し、「IP Address Manager リソースが見つかりません」という表示が出る | IP Address Manager 管理者アカウントが適切に委任され、 AWS プロバイダーがそのアカウントに認証されていることを確認します。 | | CIDR 範囲の割り当てが失敗する | リクエストされた CIDR 範囲が IP Address Manager プールの使用可能な範囲内に収まり、既存の割り当てと重複していないことを確認します。 | | AWS RAM 問題の共有 | Organization でリソース共有が有効になっていることを確認します AWS 。正しいプリンシパルである組織の Amazon リソースネーム (ARN) が AWS RAM 共有で使用されていることを確認します。 | | プール階層の検証エラー | 子プール CIDR 範囲が親プール CIDR 範囲内に適切に含まれており、兄弟プールと重複していないことを確認します。 | | IP Address Manager のクォータ制限を超過した | IP Address Manager プールのクォータ引き上げをリクエストしてください。詳細については、「*Service Quotas ユーザーガイド*」の「[クォータの引き上げのリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。 | ## 関連リソース **AWS のサービス ドキュメント** + [Amazon VPC IP Address Manager ドキュメント](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) + [AWS Resource Access Manager ドキュメント](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) + [AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) **AWS ブログ投稿** + [Managing IP pools across VPCs and Regions using Amazon VPC IP Address Manager](https://aws.amazon.com/blogs/networking-and-content-delivery/managing-ip-pools-across-vpcs-and-regions-using-amazon-vpc-ip-address-manager/) + [Network address management and auditing at scale with Amazon VPC IP Address Manager](https://aws.amazon.com/blogs/aws/network-address-management-and-auditing-at-scale-with-amazon-vpc-ip-address-manager/) **動画とチュートリアル** + [AWS re:Invent 2022: Amazon VPC 設計と IPAM のベストプラクティス (NET310)](https://www.youtube.com/watch?v=XrEHsy_8RYs) + [AWS re:Invent 2022: 高度な VPC 設計と新機能 (NET401)](https://www.youtube.com/watch?v=tbXTVpwx87o) ## 追加情報 **AFT との統合** このソリューションを AWS Control Tower Account Factory for Terraform (AFT) と統合して、新しくプロビジョニングされたアカウントが適切なネットワーク設定を自動的に受信するようにできます。この IPAM ソリューションをネットワークハブアカウントにデプロイすることで、AFT を介して作成された新アカウントが、共有の IP Address Manager プールを VPC 作成時に参照できるようになります。 次のコードサンプルは、Parameter Store を使用したアカウントカスタマイズでの AFT AWS Systems Manager 統合を示しています。 ``` # Get the IP Address Manager pool ID from Parameter Store data "aws_ssm_parameter" "dev_ipam_pool_id" { name = "/org/network/ipam/finance/dev/pool-id" } # Create a VPC using the IP Address Manager pool resource "aws_vpc" "this" { ipv4_ipam_pool_id = data.aws_ssm_parameter.dev_ipam_pool_id.value ipv4_netmask_length = 24 tags = { Name = "aft-account-vpc" } } ``` **タグ付け戦略** このソリューションは、包括的なタグ付け戦略を実装して、リソース管理を容易にします。以下にサンプルコードの活用例を示します。 ``` # Example tag configuration module "tags" { source = "./modules/tags" # Required tags product_name = "enterprise-network" feature_name = "ipam" org_id = "finance" business_unit = "network-operations" owner = "network-team" environment = "prod" repo = "https://github.com/myorg/ipam-terraform" branch = "main" cost_center = "123456" dr_tier = "tier1" # Optional tags optional_tags = { "project" = "network-modernization" "stack_role" = "infrastructure" } } ``` これらのタグは、すべての IP Address Manager リソースに自動的に適用されます。これにより、安定したガバナンスとコスト配分、リソース管理を実現します。 # の Amazon CloudWatch アラートをカスタマイズする AWS Network Firewall *Amazon Web Services、Jason Owens* ## 概要 このパターンは、 によって生成される Amazon CloudWatch アラートをカスタマイズするのに役立ちます AWS Network Firewall。事前定義されたルールを使用するか、アラートのメッセージ、メタデータ、重要度を決定するカスタムルールを作成できます。その後、これらのアラートに対応するか、Amazon EventBridge などの他のAmazonサービスによる対応を自動化することができます。 このパターンでは、Suricata 互換のファイアウォールルールを生成します。「[Suricata](https://suricata.io/)」はオープンソースの脅威検出エンジンです。まず簡単なルールを作成し、次にそれらをテストして CloudWatch アラートが生成され、記録されていることを確認します。ルールを正常にテストしたら、ルールを変更してカスタムメッセージ、メタデータ、重要度を定義し、もう一度テストして更新を確認します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI) を Linux、macOS、または Windows ワークステーションにインストールして設定します。詳細については、「[Installing or updating the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 + AWS Network Firewall CloudWatch Logs を使用するようにインストールおよび設定されている。詳細については、「 [からのネットワークトラフィックのログ記録 AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)」を参照してください。 + Network Firewall に保護された仮想プライベートクラウド (VPC) のプライベートサブネット内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス。 **製品バージョン** + のバージョン 1 では AWS CLI、1.18.180 以降を使用します。のバージョン 2 では AWS CLI、2.1.2 以降を使用します。 + Suricata バージョン 5.0.2 の分類.config ファイル。この設定ファイルのコピーについては、「[追加情報](#customize-amazon-cloudwatch-alerts-for-aws-network-firewall-additional)」セクションを参照してください。 ## アーキテクチャ ![\[EC2 インスタンスリクエストは Network Firewall でアラートを生成し、アラートを CloudWatch に転送します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da6087a9-e942-4cfe-85e3-3b08de6f3ba5/images/778d85cd-bc87-4ed0-a161-d35eb5daa694.png) 以下は、アーキテクチャ図を示しています。 1. プライベートサブネットの Amazon EC2 インスタンスは [curl](https://curl.se/) または [Wget](https://www.gnu.org/software/wget/) を使用してリクエストを行います。 1. Network Firewall はトラフィックを処理し、アラートを生成します。 1. Network Firewall は、ログに記録されたアラートを CloudWatch Logs に送信します。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行するアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、 AWS クラウドの仮想プライベートクラウド (VPC) にステートフルなマネージドネットワークファイアウォールを形成する、侵入検知および防止サービスです。  **その他のツール** + [curl](https://curl.se/) はオープンソースのコマンドラインツールとライブラリです。 + [GNU Wget](https://www.gnu.org/software/wget/) は無料のコマンドラインツールです。 ## エピック ### ファイアウォールルールとルールグループを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者、ネットワーク管理者 | | ルールグループを作成する | で AWS CLI、次のコマンドを入力します。これにより、ルールグループが作成されます。
❯ aws network-firewall create-rule-group \
        --rule-group-name custom --type STATEFUL \
        --capacity 10 --rules file://custom.rules \
        --tags Key=environment,Value=development
以下に出力例を示します。後のステップで必要になるので、 `RuleGroupArn` を書き留めておきます。
{
    "UpdateToken": "4f998d72-973c-490a-bed2-fc3460547e23",
    "RuleGroupResponse": {
        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",
        "RuleGroupName": "custom",
        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",
        "Type": "STATEFUL",
        "Capacity": 10,
        "RuleGroupStatus": "ACTIVE",
        "Tags": [
            {
                "Key": "environment",
                "Value": "development"
            }
        ]
    }
| AWS システム管理者 | ### ファイアウォールポリシーを更新 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ファイアウォールポリシーの ARN を取得します。 | で AWS CLI、次のコマンドを入力します。ポリシーの Amazon リソースネーム (ARN) を返します。後のパターンで使用するために ARN を記録します。
❯ aws network-firewall describe-firewall \
    --firewall-name aws-network-firewall-anfw \
    --query 'Firewall.FirewallPolicyArn'
以下はこのコマンドによって返される ARN の例を示しています。
"arn:aws:network-firewall:us-east-2:1234567890:firewall-policy/firewall-policy-anfw"
| AWS システム管理者 | | ファイアウォールポリシーを更新 | テキストエディターで、次のコードを貼り付けます。前のエピックで記録した値に `` を置き換えてください。`firewall-policy-anfw.json` という名前でファイルを保存します。
{
    "StatelessDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatelessFragmentDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatefulRuleGroupReferences": [
        {
            "ResourceArn": ""
        }
    ]
}
AWS CLIで、次のコマンドを入力します。このコマンドには、新しいルールを追加するための[「更新トークン」](https://docs.aws.amazon.com/cli/latest/reference/network-firewall/update-firewall-policy.html)が必要です。このトークンは、ポリシーを最後に取得してから変更されていないことを確認するために使用されます。
UPDATETOKEN=(`aws network-firewall describe-firewall-policy \
              --firewall-policy-name firewall-policy-anfw \
              --output text --query UpdateToken`)
 
 aws network-firewall update-firewall-policy \
 --update-token $UPDATETOKEN \
 --firewall-policy-name firewall-policy-anfw \
 --firewall-policy file://firewall-policy-anfw.json
| AWS システム管理者 | | ポリシーの更新を確認します。 | (オプション) ルールが追加されたことを確認して、ポリシー形式を表示する場合は、 AWS CLIで次のコマンドを入力します。
❯ aws network-firewall describe-firewall-policy \
  --firewall-policy-name firewall-policy-anfw \
  --query FirewallPolicy
以下に出力例を示します。
{
    "StatelessDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatelessFragmentDefaultActions": [
        "aws:forward_to_sfe"
    ],
    "StatefulRuleGroupReferences": [
        {
            "ResourceArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom"
        }
    ]
}
| AWS システム管理者 | ### テストアラート機能 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト用のアラートを生成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | アラートが記録されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | ### ファイアウォールルールとルールグループを更新します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ファイアウォールルールを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | ルールグループを更新します。 | で AWS CLI、次のコマンドを実行します。ファイアウォールポリシーの ARN のを使用します。これらのコマンドは更新トークンを取得し、ルールを変更してルールグループを更新します。
❯ UPDATETOKEN=(`aws network-firewall \
                describe-rule-group \
--rule-group-arn arn:aws:network-firewall:us-east-2:123457890:stateful-rulegroup/custom \
--output text --query UpdateToken`)
 ❯ aws network-firewall update-rule-group \
  --rule-group-arn arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom \
--rules file://custom.rules \
--update-token $UPDATETOKEN
以下に出力例を示します。
{
    "UpdateToken": "7536939f-6a1d-414c-96d1-bb28110996ed",
    "RuleGroupResponse": {
        "RuleGroupArn": "arn:aws:network-firewall:us-east-2:1234567890:stateful-rulegroup/custom",
        "RuleGroupName": "custom",
        "RuleGroupId": "238a8259-9eaf-48bb-90af-5e690cf8c48b",
        "Type": "STATEFUL",
        "Capacity": 10,
        "RuleGroupStatus": "ACTIVE",
        "Tags": [
            {
                "Key": "environment",
                "Value": "development"
            }
        ]
    }
}
| AWS システム管理者 | ### 更新されたアラート機能のテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト用のアラートを生成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | | アラートが変更されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-amazon-cloudwatch-alerts-for-aws-network-firewall.html) | AWS システム管理者 | ## 関連リソース **リファレンス** + [から Slack チャネル AWS Network Firewall にアラートを送信する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/send-alerts-from-aws-network-firewall-to-a-slack-channel.html) (AWS 規範ガイダンス) + [Suricata AWS を使用した での脅威防止のスケーリング](https://aws.amazon.com/blogs/opensource/scaling-threat-prevention-on-aws-with-suricata/) (AWS ブログ記事) + [のデプロイモデル AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) (AWS ブログ記事) + 「[スリカタメタキーワーク](https://suricata.readthedocs.io/en/suricata-6.0.1/rules/meta.html)」 (Suricata のドキュメント) **チュートリアルと動画** + [AWS Network Firewall ワークショップ](https://networkfirewall.workshop.aws/) ## 追加情報 以下は Suricata 5.0.2 の分類設定ファイルです。これらの分類はファイアウォールルールを作成するときに使用されます。 ``` # config classification:shortname,short description,priority config classification: not-suspicious,Not Suspicious Traffic,3 config classification: unknown,Unknown Traffic,3 config classification: bad-unknown,Potentially Bad Traffic, 2 config classification: attempted-recon,Attempted Information Leak,2 config classification: successful-recon-limited,Information Leak,2 config classification: successful-recon-largescale,Large Scale Information Leak,2 config classification: attempted-dos,Attempted Denial of Service,2 config classification: successful-dos,Denial of Service,2 config classification: attempted-user,Attempted User Privilege Gain,1 config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1 config classification: successful-user,Successful User Privilege Gain,1 config classification: attempted-admin,Attempted Administrator Privilege Gain,1 config classification: successful-admin,Successful Administrator Privilege Gain,1 # NEW CLASSIFICATIONS config classification: rpc-portmap-decode,Decode of an RPC Query,2 config classification: shellcode-detect,Executable code was detected,1 config classification: string-detect,A suspicious string was detected,3 config classification: suspicious-filename-detect,A suspicious filename was detected,2 config classification: suspicious-login,An attempted login using a suspicious username was detected,2 config classification: system-call-detect,A system call was detected,2 config classification: tcp-connection,A TCP connection was detected,4 config classification: trojan-activity,A Network Trojan was detected, 1 config classification: unusual-client-port-connection,A client was using an unusual port,2 config classification: network-scan,Detection of a Network Scan,3 config classification: denial-of-service,Detection of a Denial of Service Attack,2 config classification: non-standard-protocol,Detection of a non-standard protocol or event,2 config classification: protocol-command-decode,Generic Protocol Command Decode,3 config classification: web-application-activity,access to a potentially vulnerable web application,2 config classification: web-application-attack,Web Application Attack,1 config classification: misc-activity,Misc activity,3 config classification: misc-attack,Misc Attack,2 config classification: icmp-event,Generic ICMP event,3 config classification: inappropriate-content,Inappropriate Content was Detected,1 config classification: policy-violation,Potential Corporate Privacy Violation,1 config classification: default-login-attempt,Attempt to login by a default username and password,2 # Update config classification: targeted-activity,Targeted Malicious Activity was Detected,1 config classification: exploit-kit,Exploit Kit Activity Detected,1 config classification: external-ip-check,Device Retrieving External IP Address Detected,2 config classification: domain-c2,Domain Observed Used for C2 Detected,1 config classification: pup-activity,Possibly Unwanted Program Detected,2 config classification: credential-theft,Successful Credential Theft Detected,1 config classification: social-engineering,Possible Social Engineering Attempted,2 config classification: coin-mining,Crypto Currency Mining Activity Detected,2 config classification: command-and-control,Malware Command and Control Activity Detected,1 ``` # Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする *Zahoor Chaudhrey と Luca Iannario、Amazon Web Services* ## 概要 [AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) は、マルチアクセスエッジコンピューティング (MEC) アプリケーション用に最適化されたインフラストラクチャの構築に役立ちます。*Wavelength Zones* は、通信サービスプロバイダー (CSP) の 5G ネットワーク内に AWS コンピューティングおよびストレージサービスを埋め込む AWS インフラストラクチャデプロイです。5G デバイスからのアプリケーショントラフィックは、通信ネットワークを離れることなく、Wavelength Zone で動作しているアプリケーションサーバーに到達します。以下は、Wavelength を介したネットワーク接続を容易にします。 + **仮想プライベートクラウド (VPCs)** – VPCs は、Wavelength Zones を含む複数のアベイラビリティーゾーンにまたがるように拡張 AWS アカウント できます。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスおよび関連サービスは、リージョン VPC の一部として表示されます。VPC は [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) で作成および管理されます。 + **キャリアゲートウェイ** – キャリアゲートウェイは、Wavelength Zone のサブネットから CSP ネットワーク、インターネット、または への CSP のネットワーク AWS リージョン を介した接続を可能にします。キャリアゲートウェイには 2 つの目的があります。特定の場所にある CSP ネットワークからのインバウンドトラフィックを許可し、通信ネットワークおよびインターネットへのアウトバウンドトラフィックを許可します。 このパターンとそれに関連する Terraform コードは、Amazon EC2 インスタンス、Amazon Elastic Block Store (Amazon EBS) ボリューム、VPC、サブネット、キャリアゲートウェイなどのリソースを Wavelength Zone で起動するのに役立ちます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + 統合開発環境 (IDE) + ターゲット Wavelength Zone に[オプトイン](https://docs.aws.amazon.com/wavelength/latest/developerguide/get-started-wavelength.html#enable-zone-group)する + AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み + Terraform バージョン 1.8.4 以降、[インストール済み](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) (Terraform ドキュメント) + Terraform AWS プロバイダーバージョン 5.32.1 以降、[設定](https://hashicorp.github.io/terraform-provider-aws/)済み (Terraform ドキュメント) + Git、[インストール済み](https://github.com/git-guides/install-git) (GitHub) + Amazon VPC、Wavelength、Amazon EC2 リソースを作成するための[アクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) **制限事項** すべての が Wavelength Zones AWS リージョン をサポートしているわけではありません。詳細については、Wavelength ドキュメントの「[利用可能な Wavelength ゾーン](https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html)」を参照してください。 ## アーキテクチャ 次の図は、Wavelength Zone にサブネットと AWS リソースを作成する方法を示しています。Wavelength Zone にサブネットが含まれる VPC は、キャリアゲートウェイに接続できます。キャリアゲートウェイを使用すると、次のリソースに接続できます。 + 通信事業者のネットワーク上の 4G/LTE および 5G デバイス。 + 一部の Wavelength Zone パートナー用の固定ワイヤレスアクセス。詳細については、[「マルチアクセス AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/multi-access.html)」を参照してください。 + パブリックインターネットリソースへのアウトバウンドトラフィック。 ![\[キャリアゲートウェイは、Wavelength Zone の AWS リソースを CSP ネットワークに接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8c507de1-208c-4563-bb58-52388ab2fa6d/images/a4cc0699-0cbc-4f15-ab14-3ae569ced7f4.png) ## ツール **AWS のサービス** + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 + [AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) は AWS クラウド 、インフラストラクチャを通信プロバイダーの 5G ネットワークに拡張します。これにより、モバイルデバイスおよびエンドユーザー向けに、非常にレイテンシーが低いアプリケーションを構築できます。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub の[「Terraform AWS Wavelength を使用したインフラストラクチャの作成](https://github.com/aws-samples/terraform-wavelength-infrastructure)」リポジトリで入手できます。Terraform コードは、次のインフラストラクチャとリソースをデプロイします。 + VPC + Wavelength Zone + Wavelength Zone のパブリックサブネット + Wavelength Zone のキャリアゲートウェイ + Wavelength Zone の Amazon EC2 インスタンス ## ベストプラクティス + デプロイする前に、最新バージョンの Terraform と AWS CLIを使用していることを確認します。 + 継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して IaC をデプロイします。詳細については、[「Best practices for managing Terraform State files in AWS CI/CD Pipeline](https://aws.amazon.com/blogs/devops/best-practices-for-managing-terraform-state-files-in-aws-ci-cd-pipeline/) on AWS Blogs」を参照してください。 ## エピック ### インフラストラクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを入力して、[Terraform AWS Wavelength を使用してインフラストラクチャを作成する](https://github.com/aws-samples/terraform-wavelength-infrastructure)リポジトリを環境にクローンします。`git clone git@github.com:aws-samples/terraform-wavelength-infrastructure.git` | DevOps エンジニア | | 変数を更新してください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | | 設定を初期化します。 | 次のコマンドを入力して、作業ディレクトリを初期化します。
terraform init
| DevOps エンジニア、Terraform | | Terraform プランをプレビューしてください。 | 次のコマンドを入力して、ターゲットの状態を AWS 環境の現在の状態と比較します。このコマンドは、設定されるリソースのプレビューを生成します。
terraform plan
| DevOps エンジニア、Terraform | | 確認してデプロイする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | ### 検証とクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャのデプロイを検証する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | AWS DevOps、DevOps エンジニア | | (オプション) インフラストラクチャをクリーンアップします。 | Terraform によってプロビジョニングされたすべてのリソースを削除する必要がある場合は、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | DevOps エンジニア、Terraform | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | の Amazon EC2 インスタンスへの接続 AWS リージョン。 | 「[Linux インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)」または「[Windows インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/troubleshooting-windows-instances.html)」を参照してください。 | | Wavelength Zone の Amazon EC2 インスタンスへの接続。 | 「[Wavelength ゾーンで起動した EC2 インスタンスへの SSH または RDP の接続をトラブルシューティングする](https://repost.aws/knowledge-center/ec2-wavelength-zone-connection-errors)」を参照してください。 | | Wavelength Zone の容量。 | 「[Wavelength ゾーンのクォータと考慮事項](https://docs.aws.amazon.com/wavelength/latest/developerguide/wavelength-quotas.html)」を参照してください。 | | キャリアネットワークから AWS リージョンへのモバイルまたはキャリア接続。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-resources-wavelength-zone-using-terraform.html) | ## 関連リソース + [とは AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/what-is-wavelength.html) + [の AWS Wavelength 仕組み](https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html) + [の耐障害性 AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/disaster-recovery-resiliency.html) # DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する *Ram Kandaswamy、Amazon Web Services* ## 概要 ネットワークエンジニアやクラウド管理者は、ドメインネームシステム (DNS) レコードを Amazon Route 53 のプライベートホストゾーンに追加する効率的で簡単な方法を必要としていました。Microsoft Excel ワークシートのエントリを Route 53 コンソールの適切な場所に手動でコピーする方法は、手間がかかり、エラーが発生しやすくなります。このパターンは、複数のレコードを追加するのに必要な時間と労力を削減する自動化されたアプローチについて説明します。また、複数のホストゾーンを作成する手順を繰り返すこともできます。　 このパターンでは、レコードの保存に Amazon Simple Storage Service (Amazon S3) を使用します。データを効率的に操作するため、このパターンでは JSON 形式が使用されます。これは、シンプルさと Python ディクショナリ (`dict` データ型) のサポート機能が理由です。 **注記** システムからゾーンファイルを生成できる場合は、代わりに [Route 53 インポート機能](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html)の使用をご検討ください。 ## 前提条件と制限事項 **前提条件** + プライベートホストゾーンのレコードを含む Excel ワークシート　 + A レコード、 名前付け権限ポインタ (NAPTR) レコード、SRV レコードなど、さまざまな種類の DNS レコードを理解していること (「[サポートされる DNS レコードタイプ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)」を参照) + Python 言語とそのライブラリを理解していること **制限事項** + このパターンは、すべてのユースケースシナリオを網羅しているわけではありません。例えば、[change\$1resource\$1record\$1sets](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets) 呼び出しでは API の使用可能なプロパティがすべて使用されるわけではありません。 + Excel ワークシートでは、各行の値は固有であると想定されます。各完全修飾ドメイン名 (FQDN) の複数の値が同じ行に表示されることが予想されます。　 そうでない場合は、このパターンで提供されるコードを修正して、必要な連結を実行する必要があります。 + このパターンでは、AWS SDK for Python (Boto3) を使用して、Route 53 サービスを直接呼び出します。コードを拡張して、`create_stack` および `update_stack` コマンドに AWS CloudFormation ラッパーを使用し、JSON 値を使用してテンプレートリソースを設定することができます。 ## アーキテクチャ **テクノロジースタック** + トラフィックをルーティングするための Route 53 プライベートホストゾーン + 出力 JSON ファイルを保存するための Amazon S3 ![\[DNS レコードを Route 53 プライベートホストゾーンに一括移行します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a81c29ea-f0c5-4d4a-ba87-93111a0f1ee9/images/2ada844b-4147-4f9f-8883-d22605aa42d8.png) このワークフローは、前の図と「*エピック*」セクションで説明したように、以下のステップで構成されています。 1. レコードセット情報を含む Excel ワークシートを S3 バケットにアップロードします。 1. Excel データを JSON 形式に変換する Python スクリプトを作成して実行します。 1. S3 バケットのレコードを読み取り、データをクリーンアップします。 1. プライベートホストゾーンにレコードセットを作成します。 ## ツール + [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) — Amazon Route 53 は、ドメイン登録、DNS ルーティング、ヘルスチェックを処理する、可用性が高くスケーラブルな DNS ウェブサービスです。 + [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) — Amazon Simple Storage Service (Amazon S3) は、オブジェクトストレージサービスです。Simple Storage Service (Amazon S3) を使用すると、いつでもウェブ上の任意の場所から任意の量のデータを保存および取得できます。 ## エピック ### データ自動化の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レコード用の Excel ファイルを作成します。 | 現在のシステムからエクスポートしたレコードを使用して、完全修飾ドメイン名 (FQDN)、レコードタイプ、有効期間 (TTL)、値など、レコードに必要な列を含む Excel ワークシートを作成します。　 NAPTR レコードと SRV レコードの場合、値は複数のプロパティの組み合わせなので、Excel の `concat` メソッドを使用してこれらのプロパティを組み合わせてください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.html) | データエンジニア、Excel のスキル | | 作業環境を確認します。 | IDE で Python ファイルを作成し、Excel 入力ワークシートを JSON 形式に変換します。(IDE の代わりに、Amazon SageMaker ノートブックを使用して Python コードを編集することもできます。)Python のバージョン 3.7 以降を使用していることを確認してください。
 python3 --version
**pandas** パッケージをインストールします。
 pip3 install pandas --user
| AWS 全般 | | Excel ワークシートのデータを JSON に変換します。　 | Excel から JSON に変換し、次のコードを含む Python ファイルを作成します。
import pandas as pd
data=pd.read_excel('./Book1.xls')
data.to_json(path_or_buf='my.json',orient='records')
ここで `Book1` は Excel ワークシートの名前、`my.json` は出力 JSON ファイルの名前です。 | データエンジニア、Python スキル | | S3 バケットに JSON ファイルをアップロードします。 | S3 バケットに `my.json` ファイルをアップロードします。詳細については、Amazon S3 ドキュメントの「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」を参照してください。 | アプリ開発者 | | FQDNName | RecordType | 値 | TTL | | something.example.org | A | 1.1.1.1 | 900 | ### レコードを挿入します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライベートホストゾーンを作成します。 | [create\$1hosted\$1zone](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone) API と次の Python サンプルコードを使用して、プライベートホストゾーンを作成します。パラメータ `hostedZoneName`、`vpcRegion`、および `vpcId` をユーザー自身の値に置き換えてください。
import boto3
import random
hostedZoneName ="xxx"
vpcRegion = "us-east-1"
vpcId="vpc-xxxx"
route53_client = boto3.client('route53')
response = route53_client.create_hosted_zone(
        Name= hostedZoneName,
        VPC={
            'VPCRegion: vpcRegion,
            'VPCId': vpcId
        },
        CallerReference=str(random.random()*100000),
        HostedZoneConfig={
            'Comment': "private hosted zone created by automation",
            'PrivateZone': True
        }
    )
 print(response)
AWS CloudFormation などの Infrastructure as Code (IaC) ツールを使用すれば、適切なリソースとプロパティを含むスタックを作成するテンプレートでこれらの手順を置き換えることもできます。 | クラウドアーキテクト、ネットワーク管理者、Python のスキル | | Amazon S3 から詳細をディクショナリとして取得します。 | 以下のコードを使用して S3 バケットから読み取り、JSON 値を Python ディクショナリとして取得します。 
fileobj = s3_client.get_object(
        Bucket=bucket_name,
        Key='my.json'
        )
    filedata = fileobj['Body'].read()
    contents = filedata.decode('utf-8')
    json_content=json.loads(contents)
    print(json_content)
`json_content` には、Pythonディクショナリが含まれます。 | アプリ開発者、Python のスキル | | スペースと Unicode 文字のデータ値を消去します。 | データが正しいことを確認するための安全対策として、`json_content` コードを使用して値を削除してください。このコードでは、各文字列の先頭と末尾のスペース文字が削除されます。　 また、`replace` メソッドを使用して (改行しない) ハードスペース (`\xa0` 文字) を削除します。
for item in json_content:
    fqn_name = unicodedata.normalize("NFKD",item["FqdnName"].replace("u'", "'").replace('\xa0', '').strip())
    rec_type = item["RecordType"].replace('\xa0', '').strip()
    res_rec = {
                 'Value': item["Value"].replace('\xa0', '').strip()
                }
| アプリ開発者、Python のスキル | | レコードを挿入します | `for` ループの一部として次のコードを使用します。
change_response = route53_client.change_resource_record_sets(
            HostedZoneId="xxxxxxxx",
            ChangeBatch={
                'Comment': 'Created by automation',
                'Changes': [
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': fqn_name,
                            'Type': rec_type,
                            'TTL': item["TTL"],
                            'ResourceRecords': res_rec
                        }
                    }
                ]
            }
    )
ここで `xxxxxxx` は、このエピックの最初のステップであるホストゾーン ID です。 | アプリ開発者、Python のスキル | ## 関連リソース **リファレンス** + 「[ゾーンファイルをインポートしてレコードを作成する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating-import.html)」 (Amazon Route 53 ドキュメント) + 「[create\$1hosted\$1zone メソッド](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.create_hosted_zone)」 (Boto3 ドキュメント) + 「[change\$1resource\$1record\$1sets メソッド](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/route53.html#Route53.Client.change_resource_record_sets)」 (Boto3 ドキュメント) **チュートリアルと動画** + 「[Python チュートリアル](https://docs.python.org/3/tutorial/)」 (Python ドキュメント) + 「[Amazon Route 53 を使用した DNS 設計](https://www.youtube.com/watch?v=2y_RBjDkRgY)」 (YouTube ビデオ、*AWS オンライン Tech Talks*) # F5 から AWS のApplication Load Balancer に移行するときの HTTP ヘッダーを変更 *Amazon Web Services、Sachin Trivedi* ## 概要 F5 ロードバランサーを使用するアプリケーションをAmazon Web Services (AWS) に移行し、AWS でApplication Load Balancer を使用したい場合、ヘッダー変更の F5 ルールを移行することがよくある問題です。Application Load Balancer はヘッダーの変更をサポートしていませんが、Amazon CloudFront をコンテンツ配信ネットワーク (CDN) として使用し、Lambda @Edge により、ヘッダーを変更できます。 このパターンは、必要なインテグレーションを説明し、AWS CloudFront と Lambda @Edge により、ヘッダーを変更するためのサンプルコードを提供します。 ## 前提条件と制限事項 **前提条件** + F5 ロードバランサーを使用するオンプレミスアプリケーションで、HTTP ヘッダー値を `if, else` により、置き換える設定になっています。この設定の詳細については、F5 製品ドキュメントの「[HTTP:: header](https://clouddocs.f5.com/api/irules/HTTP__header.html)」を参照してください。  **制限事項** + このパターンは F5 ロードバランサーのヘッダーのカスタマイズに適用されます。他の第三者ロードバランサーについては、ロードバランサーのドキュメントでサポート情報を確認してください。 + Lambda@Edge に使用する Lambda 関数は、米国東部 (バージニア北部) リージョンにある必要があります。 ## アーキテクチャ 次の図は、CDN と他の AWS コンポーネント間の統合フローを含む AWS のアーキテクチャを示しています。 ![\[Amazon CloudFront と Lambda @Edge により、ヘッダーを変更するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/00abbe3c-2453-4291-9b24-b488dced4868/images/4ee9a19e-6da2-4c5a-a8bc-19d3918a166e.png) ## ツール **AWS サービス** + 「[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」─ Application Load Balancer は、開放型システム間相互接続 (OSI) モデルの第 7 層で機能する AWS フルマネージド型負荷分散サービスです。複数のターゲット間でトラフィックを分散し、HTTP ヘッダーとメソッド、クエリ文字列、ホストベースまたはパスベースのルーティングに基づく高度なルーティングリクエストをサポートします。 + 「[Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)」— Amazon CloudFront は、ユーザーへの静的および動的なウェブコンテンツ (.html、.css、.js、イメージファイルなど) の配信を高速化するウェブサービスです。CloudFront では、エッジロケーションというデータセンターの世界的ネットワークを経由してコンテンツを配信し、レイテンシーを短縮し、パフォーマンスを向上させます。 + 「[Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)」— Lambda@Edge は、CloudFront が配信するコンテンツをカスタマイズする関数を実行できる AWS Lambda の拡張機能です。米国東部 (バージニア北部) リージョンで作成した関数を CloudFront ディストリビューションに関連付けると、サーバーのプロビジョニングや管理の必要もなく、コードを世界中に自動的に複製できます。これにより、待ち時間が短縮され、ユーザーエクスペリエンスが向上します。 **Code** 次のサンプルコードは、CloudFront レスポンスヘッダーを変更するためのブループリントを提供します。*[エピック]* セクションの指示に従い、コードをデプロイします。 ``` exports.handler = async (event, context) => {     const response = event.Records[0].cf.response;     const headers = response.headers;     const headerNameSrc = 'content-security-policy';     const headerNameValue = '*.xyz.com';     if (headers[headerNameSrc.toLowerCase()]) {         headers[headerNameSrc.toLowerCase()] = [{             key: headerNameSrc,             value: headerNameValue,         }];         console.log(`Response header "${headerNameSrc}" was set to ` +                     `"${headers[headerNameSrc.toLowerCase()][0].value}"`);     }     else {             headers[headerNameSrc.toLowerCase()] = [{             key: headerNameSrc,             value: headerNameValue,             }];     }     return response; }; ``` ## エピック ### CDN ディストリビューションの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFront ウェブディストリビューションを作成します。 | このステップでは、CloudFront ディストリビューションを作成して、コンテンツの配信元とコンテンツ配信の追跡および管理方法の詳細を CloudFront に伝えます。コンソールを使用してディストリビューションを作成するには、AWS マネジメントコンソールにサインインし、「[CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v3/home)」を開き、「[CloudFront のドキュメント](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html)」の手順に従います。 | クラウド管理者 | ### Lambda@Edge 関数の作成とデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda@Edge 関数の作成とデプロイ | CloudFront レスポンスヘッダーを変更するためのブループリントを使用して Lambda @Edge 関数を作成できます。(他のブループリントもさまざまなユースケースで利用できます。詳細については、「CloudFront のドキュメント」の「[Lambda @Edge サンプル関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)」を参照してください。) Lambda@Edge 関数を作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.html) | AWS 管理者 | | Lambda@Edge 関数をデプロイします。 | Amazon CloudFront ドキュメント「*チュートリアル: 基本的な Lambda@Edge 関数 (コンソール) を作成する*」の[ステップ 4](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-add-trigger) の手順に従い、CloudFront トリガーを設定し、関数をデプロイします。 | AWS 管理者 | ## 関連リソース CloudFront のドキュメント + 「[カスタムオリジンのリクエストとレスポンスの動作](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html)」  + 「[ディストリビューションの使用](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html)」  + 「[Lambda@Edge 関数の例](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html)」  + 「[Lambda@Edge を使用したエッジでのカスタマイズ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)」 + 「[チュートリアル:シンプルな Lambda@Edge 関数の作成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html)」 # 複数の でインバウンドインターネットアクセスに関する Network Access Analyzer の検出結果のレポートを作成する AWS アカウント *Amazon Web Services、Mike Virgilio* ## 概要 AWS リソースへの意図しないインバウンドインターネットアクセスは、組織のデータ境界にリスクをもたらす可能性があります。[Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) は、Amazon Virtual Private Cloud (Amazon VPC) の機能の一つで、Amazon Web Services (AWS) のリソースへの意図しないネットワークアクセスを識別できます。Network Access Analyzer を使用してネットワークアクセス要件を指定し、指定した要件を満たさない可能性のあるネットワークパスを特定できます。Network Access Analyzer を使用すると、次の操作を実行できます。 1. インターネットゲートウェイを介してインターネットにアクセスできる AWS リソースを特定します。 1. 運用環境と開発環境を分離し、またはトランザクションワークロードを分離するなど、仮想プライベートクラウド (VPC) が適切にセグメント化されていることを確認します。 Network Access Analyzer は、単一のコンポーネントだけでなく、エンドツーエンドのネットワーク到達可能性条件を分析します。リソースがインターネットにアクセスできるかどうかを判断するために、Network Access Analyzer はインターネットゲートウェイ、VPC ルートテーブル、ネットワークアクセスコントロールリスト (ACL)、Elastic Network Interface の公開 IP アドレスとセキュリティグループを評価します。これらのコンポーネントのいずれかがインターネットアクセスを妨げている場合、Network Access Analyzer は検出結果を生成しません。たとえば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに、`0/0` からのトラフィックを許可するオープンセキュリティグループがあっても、そのインスタンスがどのインターネットゲートウェイからもルーティングできないプライベートサブネットにある場合、Network Access Analyzer は検出結果を生成しません。これにより精度の高い結果が得られるため、インターネットから本当にアクセスできるリソースを特定できます。 Network Access Analyzerを実行するときには、「[ネットワークアクセススコープ](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html#concepts)」を使用してネットワークアクセス要件を指定します。このソリューションは、インターネットゲートウェイとエラスティックネットワークインターフェース間のネットワークパスを識別します。このパターンでは、 が管理する組織 AWS アカウント 内の一元化された にソリューションをデプロイし AWS Organizations、組織 AWS リージョン内のすべてのアカウントを分析します。 このソリューションは、以下を念頭に置いて設計されました。 + AWS CloudFormation テンプレートは、このパターンで AWS リソースをデプロイするために必要な労力を削減します。 + デプロイ時に CloudFormation テンプレートのパラメータと **naa-script.sh** スクリプトのパラメータを調整することで、環境に合わせてカスタマイズできます。 + Bash スクリプトは、複数のアカウントのネットワークアクセススコープをパラレルで自動的にプロビジョニングして分析します。 + Python スクリプトは検出結果を処理し、データを抽出し、結果を統合します。Network Access Analyzer 検出結果の統合レポートを CSV 形式で確認するか、 AWS Security Hub CSPMで確認するかを選択できます。CSV レポートの例はこのパターンの「[追加情報](#create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts-additional)」セクションにあります。 + 検出結果を修正することも、**naa-exclusions.csv** ファイルに追加して今後の分析から除外することもできます。 ## 前提条件と制限 **前提条件** + 組織のメンバーアカウントとして管理されるセキュリティサービスとツールをホスト AWS アカウント するための AWS Organizations。このパターンでは、このアカウントはセキュリティアカウントと呼ばれています。 + セキュリティアカウントには、アウトバウンドのインターネットにアクセスできるプライベートサブネットが必要です。手順については、「Amazon VPC のドキュメント」の「[サブネットの作成](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)」を参照してください。「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」または「[インターフェイスVPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を使用してインターネットアクセスを確立できます。 + CloudFormation の管理者権限を委任された AWS Organizations 管理アカウントまたはアカウントへのアクセス。手順については、「CloudFormation のドキュメント」の「[委任管理者の登録](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html)」を参照してください。 + AWS Organizations と CloudFormation 間の信頼されたアクセスを有効にします。手順については、「CloudFormation ドキュメント」の「[ 信頼できるアクセスを有効にする AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)」を参照してください。 + Security Hub CSPM に結果をアップロードする場合は、アカウントと Amazon EC2 インスタンスがプロビジョニングされている AWS リージョン 場所で Security Hub CSPM を有効にする必要があります。詳細については、「[セットアップ AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)」を参照してください。 **制限事項** + Network Access Analyzer 機能の制限により、クロスアカウントネットワークパスは現在分析されていません。 + ターゲットは の組織として管理 AWS アカウント する必要があります AWS Organizations。を使用していない場合は AWS Organizations、環境の **naa-execrole.yaml** CloudFormation テンプレートと **naa-script.sh** スクリプトを更新できます。代わりに、スクリプトを実行する AWS アカウント IDs とリージョンのリストを指定します。 + CloudFormation テンプレートは、アウトバウンドインターネットアクセスを持つプライベートサブネットに Amazon EC2 インスタンスをデプロイするように設計されています。 AWS Systems Manager エージェント (SSM エージェント) は、Systems Manager サービスエンドポイントに到達するためにアウトバウンドアクセスを必要とし、コードリポジトリのクローンを作成して依存関係をインストールするにはアウトバウンドアクセスが必要です。パブリックサブネットを使用する場合は、**naa-resources.yaml** テンプレートを変更して [Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)を Amazon EC2 インスタンスに関連付ける必要があります。 ## アーキテクチャ **ターゲットアーキテクチャ** オプション 1: Amazon S3 バケットの検出結果にアクセス ![\[Amazon S3 バケット内のNetwork Access Analyzerの検出結果レポートにアクセスするためのアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/d0b08437-e5b0-47a1-abdd-040c67b5da8f.png) 図表に示す内容は以下のステップです。 1. ソリューションを手動で実行する場合、ユーザーは Session Manager を使用して Amazon EC2 インスタンスへの認証を行い、次に **naa-script.sh** スクリプトを実行します。このシェルスクリプトはステップ 2～7 を実行します。 ソリューションを自動的に実行する場合、**naa-script.sh** スクリプトは cron 式で定義したスケジュールで自動的に開始されます。このシェルスクリプトはステップ 2 ～ 7 を実行します。詳細については、このセクションの最後にある「*自動化とスケール*」を参照してください。 1. Amazon EC2 インスタンスは Amazon S3 バケットから最新の **naa-exception.csv** ファイルをダウンロードします。このファイルは、プロセスの後半で Python スクリプトが除外を処理するときに使用されます。 1. Amazon EC2 インスタンスは `NAAEC2Role` AWS Identity and Access Management (IAM) ロールを引き受けます。これにより、Amazon S3 バケットにアクセスし、組織内の他のアカウントの `NAAExecRole` IAM ロールを引き受けるアクセス許可が付与されます。 1. Amazon EC2 インスタンスは、組織の管理アカウントの `NAAExecRole` IAM ロールを引き受け、組織内のアカウントのリストを生成します。 1. Amazon EC2 インスタンスは、組織のメンバーアカウント (アーキテクチャ図では*ワークロードアカウント*と記載) の `NAAExecRole` IAM ロールを引き受け、各アカウントのセキュリティ評価を実行します。検出結果は Amazon EC2 インスタンスに JSON ファイルとして保存されます。 1. Amazon EC2 インスタンスは Python スクリプトを使用して JSON ファイルを処理、データフィールドを抽出し、CSV レポートを作成します。 1. Amazon EC2 インスタンスは、Amazon S3 バケットに CSV ファイルをアップロードします。 1. Amazon EventBridge ルールはファイルのアップロードを検出し、Amazon SNS トピックを使用して、レポートが完了したことをユーザーに通知メールを送信します。 1. ユーザーは Amazon S3 バケットから CSV ファイルをダウンロードします。ユーザーはその結果を Excel テンプレートにインポートし、結果を確認します。 *オプション 2: で検出結果にアクセスする AWS Security Hub CSPM* ![\[AWS Security Hub からNetwork Access Analyzerの検出結果にアクセスするアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/9cb4f059-dfb6-4a33-9f8d-159fe5df0d64.png) 図に示す内容は以下のとおりです。 1. ソリューションを手動で実行する場合、ユーザーは Session Manager を使用して Amazon EC2 インスタンスへの認証を行い、次に **naa-script.sh** スクリプトを実行します。このシェルスクリプトはステップ 2～7 を実行します。 ソリューションを自動的に実行する場合、**naa-script.sh** スクリプトは cron 式で定義したスケジュールで自動的に開始されます。このシェルスクリプトはステップ 2 ～ 7 を実行します。詳細については、このセクションの最後にある「*自動化とスケール*」を参照してください。 1. Amazon EC2 インスタンスは Amazon S3 バケットから最新の **naa-exception.csv** ファイルをダウンロードします。このファイルは、プロセスの後半で Python スクリプトが除外を処理するときに使用されます。 1. Amazon EC2 インスタンスは `NAAEC2Role` IAM ロールを引き受け、Amazon S3 バケットにアクセスし、組織内の他のアカウントの `NAAExecRole` IAM 役割を引き受ける権限を付与します。 1. Amazon EC2 インスタンスは、組織の管理アカウントの `NAAExecRole` IAM ロールを引き受け、組織内のアカウントのリストを生成します。 1. Amazon EC2 インスタンスは、組織のメンバーアカウント (アーキテクチャ図では*ワークロードアカウント*と記載) の `NAAExecRole` IAM ロールを引き受け、各アカウントのセキュリティ評価を実行します。検出結果は Amazon EC2 インスタンスに JSON ファイルとして保存されます。 1. Amazon EC2 インスタンスは Python スクリプトを使用して JSON ファイルを処理し、Security Hub CSPM にインポートするためのデータフィールドを抽出します。 1. Amazon EC2 インスタンスは、Network Access Analyzer の検出結果を Security Hub CSPM にインポートします。 1. Amazon EventBridge ルールはインポートを検出し、Amazon SNS トピックで処理が完了したことをユーザーに通知メールを送信します。 1. ユーザーは Security Hub CSPM で検出結果を表示します。 **自動化とスケール** **naa-script.sh** スクリプトをカスタムスケジュールで自動的に実行するように、このソリューションをスケジュールできます。カスタムスケジュールを設定するには、**naa-resources.yaml** の CloudFormation テンプレートで `CronScheduleExpression` パラメータを変更します。たとえば、`0 0 * * 0` のデフォルト値は、ソリューションを毎週日曜日の深夜0時に実行します。 の値は、ソリューションを毎月第 1 日曜日の午前 0 時に実行します。`0 0 * 1-12 0`cron 式の使用に関する詳細は、「Systems Manager のドキュメント」の「[cron 式とrate 式](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)」を参照してください。 `NAA-Resources` スタックのデプロイ後にスケジュールを調整したい場合は、`/etc/cron.d/naa-schedule` で cron スケジュールを手動で編集できます。 ## ツール **AWS のサービス** + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) は、 のセキュリティ状態の包括的なビューを提供します AWS。また、セキュリティ業界標準とベストプラクティスに照らして AWS 環境を確認するのにも役立ちます。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。このパターンは、システムマネージャーの機能である「Session Manager」 を使用します。 コードリポジトリ このパターンのコードは、GitHub 内の「[Network Access Analyzer マルチアカウント分析](https://github.com/aws-samples/network-access-analyzer-multi-account-analysis)」リポジトリで利用できます。コードリポジトリには、以下のファイルが含まれます。 + **naa-script.sh** – この bash スクリプトは AWS アカウント、複数の Network Access Analyzer 分析を並行して開始するために使用されます。**naa-resources.yaml** の CloudFormation テンプレートで定義されているように、このスクリプトは Amazon EC2 インスタンスの `/usr/local/naa` フォルダに自動的にデプロイされます。 + **naa-resources.yaml** – この CloudFormation テンプレートを使用して、組織のセキュリティアカウントにスタックを作成します。このテンプレートは、ソリューションをサポートするためにこのアカウントに必要なリソースをすべてデプロイします。このスタックは **naa-execrole.yaml** テンプレートの前にデプロイする必要があります。 **注記** このスタックを削除して再デプロイした場合、IAM ロール間のクロスアカウント依存関係を再構築するために `NAAExecRole` スタックセットを再構築する必要があります。 + **naa-execrole.yaml** – この CloudFormation テンプレートを使用して、管理アカウントを含む組織内のすべてのアカウントに `NAAExecRole` IAM ロールをデプロイするスタックセットを作成します。 + **naa-processfindings.py** – **naa-script.sh **スクリプトは、この Python スクリプトを自動的に呼び出して Network Access Analyzer JSON 出力を処理し、**naa-exclusions.csv** ファイル内の既知の正常なリソースを除外してから、統合結果の CSV ファイルを生成するか、結果を Security Hub CSPM にインポートします。 ## エピック ### デプロイの準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | テンプレートを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### CloudFormation スタックの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | セキュリティアカウントにリソースをプロビジョニングします。 | **naa-resources.yaml** テンプレートを使用して、セキュリティアカウントに必要なすべてのリソースをデプロイする CloudFormation スタックを作成します。手順については、「CloudFormation のドキュメント」の「[スタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | メンバーアカウントで IAM ロールをプロビジョニングします。 | AWS Organizations 管理アカウントまたは CloudFormation の委任管理者権限を持つアカウントで、**naa-execrole.yaml** テンプレートを使用して CloudFormation スタックセットを作成します。スタックセットは、組織内のすべてのメンバーアカウントに `NAAExecRole` IAM ロールをデポロイします。手順については、CloudFormation ドキュメントの「[サービスマネージド型のアクセス許可を持つスタックセットの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#stacksets-orgs-associate-stackset-with-org)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | 管理アカウントで IAM ロールをプロビジョニングします。 | **naa-execrole.yaml** テンプレートを使用して、組織の管理アカウントに `NAAExecRole` IAM ロールをデプロイする CloudFormation スタックを作成します。以前に作成したスタックセットでは、管理アカウントに IAM ロールはデプロイされません。手順については、「CloudFormation ドキュメント」の「[スタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。このテンプレートを展開する際には、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### 分析の実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | シェルスクリプトをカスタマイズします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | ターゲットアカウントを分析します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | オプション 1 – Amazon S3 バケットから結果を取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | | オプション 2 – Security Hub CSPM の結果を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### 検出結果の修正と除外 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 検出結果を修正します。 | 組織の管理アカウントにIAMロールをデプロイするCloudFormationスタックを作成しました。 AWS ID、リソース、ネットワークの周囲に境界を作成する方法の詳細とベストプラクティスについては、「 [でのデータ境界の構築 AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) (AWS ホワイトペーパー）」を参照してください。 | AWS DevOps | | ネットワークパスが正常であることがわかっているリソースを除きます。 | Network Access Analyzer がインターネットからアクセスできるはずのリソースに関する検出結果を生成した場合、それらのリソースを除外リストに追加できます。今度、Network Access Analyzerを実行しても、そのリソースの検出結果は生成されません。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### (オプション)［naa-script.sh］スクリプトを更新します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | [naa-script.sh] スクリプトを更新します。 | **naa-script.sh** スクリプトをリポジトリ内の最新バージョンに更新するには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ### (オプション) クリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイされたリソースをすべて削除します。 | リソースはアカウントにデプロイしたままにしておくことができます。すべてのリソースのプロビジョニングを解除する場合は、以下のように実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Session Manager を使用して Amazon EC2 インスタンスに接続できません。 | SSM エージェントは、Systems Manager エンドポイントと通信できる必要があります。以下の操作を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-report-of-network-access-analyzer-findings-for-inbound-internet-access-in-multiple-aws-accounts.html) | | スタックセットをデプロイすると、CloudFormation コンソールに `Enable trusted access with AWS Organizations to use service-managed permissions` を求めるメッセージが表示されます。 | これは、 AWS Organizations と CloudFormation の間で信頼されたアクセスが有効になっていないことを示します。サービスマネージド型のスタックセットをデプロイするには、信頼されたアクセスが必要です。このボタンを選択すると、信頼されたアクセスは有効になります。詳細については、「CloudFormation ドキュメント」の「[信頼されたアクセスの有効化](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)」を参照してください。 | ## 関連リソース + [新規 – Amazon VPC Network Access Analyzer](https://aws.amazon.com/blogs/aws/new-amazon-vpc-network-access-analyzer/) (AWS ブログ記事) + [AWS re:Inforce 2022 - での効果的なネットワークアクセスコントロールの検証 AWS (NIS202)](https://youtu.be/aN2P2zeQek0) (ビデオ) + 「[デモ- Network Access Analyzer を使用した組織全体のインターネット進入データパス分析](https://youtu.be/1IFNZWy4iy0)」 (ビデオ) ## 追加情報 コンソール出力の例 次のサンプルは、ターゲットアカウントのリストを生成し、ターゲットアカウントを分析した出力を示しています。 ``` [root@ip-10-10-43-82 naa]# ./naa-script.sh download: s3://naa--us-east-1/naa-exclusions.csv to ./naa-exclusions.csv AWS Management Account: AWS Accounts being processed... Assessing AWS Account: , using Role: NAAExecRole Assessing AWS Account: , using Role: NAAExecRole Assessing AWS Account: , using Role: NAAExecRole Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Processing account: / Region: us-east-1 Account: / Region: us-east-1 – Detecting Network Analyzer scope... Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour Account: / Region: us-east-1 – Network Access Analyzer scope detected. Account: / Region: us-east-1 – Continuing analyses with Scope ID. Accounts with many resources may take up to one hour ``` CSV レポートの例 以下の画像は CSV 出力の例です。 ![\[このソリューションにより生成された CSV レポートの例 1。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/55e02e61-054e-4da6-aaae-c9a8b6f4f272.png) ![\[このソリューションにより生成された CSV レポートの例 2。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eda6abba-632a-4e3d-92b9-31848fa6dead/images/95f980ad-92c1-4392-92d4-9c742755aab2.png) # マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する *Anvesh Koganti、Amazon Web Services* ## 概要 このパターンは、複数の Amazon Web Services (AWS) アカウントを含むハイブリッドネットワーク環境で DNS 解決を設定するための包括的なソリューションを提供します。これにより、エンドポイントを介してオンプレミスネットワークと AWS 環境間の双方向 DNS 解決が可能になります Amazon Route 53 Resolver 。このパターンは、[マルチアカウントで一元化されたアーキテクチャ](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html#multi-account-centralized)で DNS 解決を可能にする 2 つのソリューションを示しています。 + *基本セットアップ*では Route 53 プロファイルを使用しません。これにより、あまり複雑でない中小規模のデプロイのコストを最適化できます。 + *高度なセットアップ*では、Route 53 プロファイルを使用してオペレーションを簡素化します。より大規模な、または複雑な DNS デプロイに最適です。 **注記** 実装する前に、「*制限事項*」セクションでサービスの制限とクォータを確認してください。決定するときは、管理のオーバーヘッド、コスト、運用の複雑さ、チームの専門知識などの要因を考慮してください。 ## 前提条件と制限事項 **前提条件** + 共有サービスとワークロードアカウント全体にデプロイされた Amazon Virtual Private Cloud (Amazon VPC) を使用する AWS マルチアカウント環境 (アカウント構造の[AWS ベストプラクティスに従って AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) を介してセットアップすることをお勧めします）。 + オンプレミスネットワークと AWS 環境間の既存のハイブリッド接続 (AWS Direct Connect または AWS Site-to-Site VPN)。 + Amazon VPC ピアリング AWS Transit Gateway、または VPCs AWS クラウド 間のレイヤー 3 ネットワーク接続用の WAN。(この接続はアプリケーショントラフィックに必要です。DNS 解決が機能するためには必要ありません。DNS 解決は VPC 間のネットワーク接続を独立して操作します。) + オンプレミス環境で実行されている DNS サーバー。 **制限事項** + Route 53 Resolver のエンドポイント、ルール、プロファイルはリージョン構造であり、グローバル組織 AWS リージョン では複数の でレプリケーションが必要になる場合があります。 + Route 53 Resolver、プライベートホストゾーン、およびプロファイルの Service Quotas の包括的なリストについては、Route 53 ドキュメントの「[クォータ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Route 53 アウトバウンドエンドポイントとインバウンドエンドポイント + 条件付き転送用の Route 53 Resolver ルール + AWS Resource Access Manager (AWS RAM) + Route 53 プライベートホストゾーン **ターゲットアーキテクチャ** **アウトバウンドエンドポイントとインバウンドエンドポイント** 次の図は、 からオンプレミス AWS への DNS 解決フローを示しています。これは、ドメインがオンプレミスでホストされているアウトバウンド解決の接続設定です。この設定に関連するプロセスの概要を次に示します。詳細については、「[エピック](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics)」セクションを参照してください。 1. アウトバウンド Route 53 Resolver エンドポイントを共有サービス VPC にデプロイします。 1. オンプレミスでホストされているドメインの共有サービスアカウントに Route 53 Resolver ルール (転送ルール) を作成します。 1. オンプレミスのホストドメインを解決する必要があるリソースをホストする他のアカウントの VPC とルールを共有して関連付けます。これは、このセクションで後述するように、ユースケースに応じてさまざまな方法で行うことができます。 ![\[AWS のインバウンドエンドポイントとアウトバウンドエンドポイントからオンプレミス DNS 解決へのフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/d69d4cad-5e2c-4481-9370-2708e8a4f8c1.png) 接続を設定した後の、アウトバウンド解決に関連するステップは次のとおりです。 1. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、`db.onprem.example.com` の DNS 解決リクエストを VPC\$12 アドレスの VPC の Route 53 Resolver に送信します。 1. Route 53 Resolver は Resolver ルールをチェックし、アウトバウンドエンドポイントを使用してリクエストをオンプレミス DNS サーバー IP に転送します。 1. アウトバウンドエンドポイントは、リクエストをオンプレミス DNS IP に転送します。トラフィックは、共有サービス VPC とオンプレミスデータセンター間の確立されたハイブリッドネットワーク接続を経由します。 1. オンプレミス DNS サーバーはアウトバウンドエンドポイントに応答し、VPC の Route 53 Resolver に応答を転送します。Resolver は EC2 インスタンスに応答を返します。 次の図は、オンプレミス環境から への DNS 解決フローを示しています AWS。これは、ドメインが AWSでホストされているインバウンド解決の接続設定です。この設定に関連するプロセスの概要を次に示します。詳細については、「[エピック](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-epics)」セクションを参照してください。 1. インバウンド Resolver エンドポイントを共有サービス VPC にデプロイします。 1. 共有サービスアカウントにプライベートホストゾーンを作成します (一元的アプローチ)。 1. プライベートホストゾーンを共有サービス VPC に関連付けます。これらのゾーンを共有し、VPC 間の DNS 解決用のクロスアカウント VPC と関連付けます。これは、このセクションで後述するように、ユースケースに応じてさまざまな方法で行うことができます。 ![\[オンプレミスのインバウンドエンドポイントとアウトバウンドエンドポイントから AWS DNS 解決へのフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/a6f5348c-2041-453e-8939-2b4ee0b7ebd8.png) 接続を設定した後の、インバウンド解決に関連するステップは次のとおりです。 1. オンプレミスリソースは、`ec2.prod.aws.example.com` の DNS 解決リクエストをオンプレミス DNS サーバーに送信します。 1. オンプレミス DNS サーバーは、ハイブリッドネットワーク接続を介して共有サービス VPC 内のインバウンド Resolver エンドポイントにリクエストを転送します。 1. インバウンド Resolver エンドポイントは、VPC Route 53 Resolver による解決によって、関連するプライベートホストゾーンでリクエストを検索し、適切な IP アドレスを取得します。 1. これらの IP アドレスはオンプレミス DNS サーバーに返され、オンプレミスリソースに応答が返されます。 この設定により、オンプレミスリソースは、インバウンドエンドポイントを介して適切な AWS プライベートホストゾーンにクエリをルーティングすることで、プライベートドメイン名を解決できます。このアーキテクチャでは、プライベートホストゾーンは共有サービス VPC に一元化されるため、単一のチームによる一元的な DNS 管理が可能になります。これらのゾーンは、VPC 間の DNS 解決のユースケースに対応するために、多くの VPC に関連付けることができます。または、それぞれに DNS ドメインの所有権と管理を委任することもできます AWS アカウント。この場合、各アカウントは独自のプライベートホストゾーンを管理し、各ゾーンを中央共有サービス VPC に関連付けて、オンプレミス環境との統合解決を行います。この分散型アプローチは、このパターンの範囲外です。詳細については、「*Hybrid Cloud DNS Options for Amazon VPC*」ホワイトペーパーの「[Scaling DNS management across multiple accounts and VPCs](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/scaling-dns-management-across-multiple-accounts-and-vpcs.html)」を参照してください。 Resolver エンドポイントを使用して基本的な DNS 解決フローを確立する場合は、 AWS アカウント全体で Resolver ルールとプライベートホストゾーンの共有と関連付けを管理する方法を決定する必要があります。これは 2 つの方法でアプローチできます。*基本セットアップ*セクションで説明されているように、 AWS RAM を使用してリゾルバールールを共有し、プライベートホストゾーンの関連付けをダイレクトすることでセルフマネージド共有する方法と、*拡張セットアップ*セクションで説明されているように Route 53 プロファイルする方法です。どちらを選択するかは、組織の DNS 管理設定と運用要件によって異なります。次のアーキテクチャ図は、異なるアカウントにまたがる複数の VPC を含むスケーリングされた環境を示しています。これは、一般的なエンタープライズデプロイを表しています。 **基本的なセットアップ** 基本的なセットアップでは、マルチアカウント AWS 環境でのハイブリッド DNS 解決の実装では、 を使用して Resolver 転送ルールとプライベートホストゾーンの関連付け AWS RAM を共有し、オンプレミスと AWS リソース間の DNS クエリを管理します。この方法では、オンプレミスネットワークに接続された共有サービス VPC 内の一元化された Route 53 Resolver エンドポイントを使用して、インバウンドとアウトバウンド両方の DNS 解決を効率的に処理します。 + アウトバウンド解決の場合、リゾルバー転送ルールは共有サービスアカウントで作成され、 を使用して他の と共有 AWS アカウント されます AWS RAM。この共有は、同じリージョン内のアカウントに限定されます。その後、ターゲットアカウントはこれらのルールを VPC に関連付け、それらの VPC 内のリソースを有効にしてオンプレミスドメイン名を解決できます。 + インバウンド解決の場合、プライベートホストゾーンは共有サービスアカウントに作成され、共有サービス VPC に関連付けられます。これらのゾーンは、Route 53 API、 AWS SDKs、または AWS Command Line Interface () を使用して、他のアカウントの VPCs に関連付けることができますAWS CLI。関連付けられた VPCs のリソースは、プライベートホストゾーンで定義された DNS レコードを解決できます。これにより、 AWS 環境全体で統一された DNS ビューが作成されます。 次の図は、この基本セットアップの DNS 解決フローを示しています。 ![\[マルチアカウントの AWS 環境でハイブリッド DNS 解決に基本セットアップを使用します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/258e4bcd-e9c6-43b5-bab8-856ca22206b9.png) この設定は、限られた規模で DNS インフラストラクチャを操作する場合に適しています。ただし、環境が大きくなるにつれて、管理が難しくなる可能性があります。プライベートホストゾーンと Resolver ルールを共有し、VPC と個別に関連付ける方法を管理する際に発生する運用オーバーヘッドは、スケールとともに大幅に増加します。さらに、プライベートホストゾーンあたり 300 VPC の関連付け制限などの Service Quotas は、大規模なデプロイで制約要因になる可能性があります。高度なセットアップは、これらの課題に対処します。 **高度なセットアップ** Route 53 プロファイルは、複数の AWS アカウントにまたがるハイブリッドネットワークの DNS 解決を管理するために合理化されたソリューションを提供します。プライベートホストゾーンと Resolver ルールを個別に管理する代わりに、DNS 設定を 1 つのコンテナにグループ化します。これは、リージョン内の複数の VPC とアカウント間で簡単に共有および適用できます。このセットアップでは、DNS 設定の管理を大幅に簡素化しながら、一元化された Resolver エンドポイントアーキテクチャを共有サービス VPC で維持します。 次の図は、高度なセットアップの DNS 解決フローを示しています。 ![\[マルチアカウントの AWS 環境でハイブリッド DNS 解決に Route 53 プロファイルを使用する高度なセットアップを使用します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01e700cd-be8c-4a5d-bc89-b901a260d045/images/55b9681d-ddb4-4a55-b4ec-fc9afa9870fa.png) Route 53 プロファイルを使用すると、プライベートホストゾーンの関連付け、Resolver 転送ルール、DNS ファイアウォールルールを 1 つの共有可能なユニットにパッケージ化できます。共有サービスアカウントでプロファイルを作成し、 を使用してメンバーアカウントと共有できます AWS RAM。プロファイルを共有してターゲット VPC に適用すると、必要なすべての関連付けと設定がサービスによって自動的に処理されます。これにより、DNS 管理の運用オーバーヘッドが大幅に削減され、拡大する環境に優れたスケーラビリティが提供されます。 **自動化とスケール** CloudFormation や Terraform などの Infrastructure as Code (IaC) ツールを使用して、Route 53 Resolver エンドポイント、ルール、プライベートホストゾーン、プロファイルを自動的にプロビジョニングおよび管理します。DNS 設定を継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと統合して、一貫性、再現性、迅速な更新を実現します。 ## ツール **AWS のサービス** + [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) は、 間でリソースを安全に共有 AWS アカウント し、運用オーバーヘッドを削減し、可視性と監査性を提供します。 + [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) はリソースからの DNS クエリに再帰的に応答 AWS し、デフォルトですべての VPCsで使用できます。Resolver エンドポイントと条件付き転送ルールを作成して、オンプレミスデータセンターと VPC の間の DNS 名前空間を解決できます。 + [Amazon Route 53 プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)は、ドメインとそのサブドメインへの DNS クエリに対し、Route 53 がどのように応答するかに関する情報を保持するコンテナです。 + [Amazon Route 53 プロファイル](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html)を使用すると、DNS 関連の Route 53 設定 AWS アカウント を多くの VPCsおよび管理できます。 ## ベストプラクティス このセクションでは、Route 53 Resolver を最適化するためのベストプラクティスについていくつか説明します。これらは Route 53 のベストプラクティスのサブセットを表します。包括的なリストについては、「[Amazon Route 53 のベストプラクティス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices.html)」を参照してください。 **Resolver エンドポイントでのループ設定の回避** + 再帰的なルーティングを防ぐため、VPC の関連付けを慎重に計画して DNS アーキテクチャを設計してください。VPC がインバウンドエンドポイントをホストする場合は、循環参照を作成できる Resolver ルールに関連付けないでください。 + アカウント間で DNS リソースを共有する場合は、クリーンルーティングパスを維持するために AWS RAM 戦略的に を使用します。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントを使用した設定のループを回避する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoints.html)」を参照してください。 **Resolver エンドポイントのスケーリング** + 1 秒あたりのクエリ数 (QPS) が多い環境では、エンドポイントで ENI あたり 10,000 QPS の制限があることに注意してください。DNS QPS をスケールするために、エンドポイントにさらに ENI を追加できます。 + Amazon CloudWatch は `InboundQueryVolume` および `OutboundQueryVolume` メトリクスを提供します ([CloudWatch ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)を参照してください)。しきい値が特定の値 (10,000 QPS の 80% など) を超えた場合に警告するモニタリングルールを設定することをお勧めします。 + Resolver エンドポイントのステートフルセキュリティグループルールを設定して、大量のトラフィックが発生している最中に接続追跡制限によって DNS クエリスロットリングが発生しないようにします。セキュリティグループでの接続追跡の仕組みに関する詳細は、Amazon EC2 ドキュメントの「[Amazon EC2 セキュリティグループの接続の追跡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)」を参照してください。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントのスケーリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-scaling.html)」を参照してください。 **Resolver エンドポイントの高可用性を提供する** + 冗長性を確保するために、少なくとも 2 つのアベイラビリティーゾーンに IP アドレスを持つインバウンドエンドポイントを指定します。 + メンテナンスやトラフィックの急増時に可用性を確保するための追加のネットワークインターフェイスをプロビジョニングします。 詳細については、Route 53 ドキュメントの「[Resolver エンドポイントの高可用性](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver-endpoint-high-availability.html)」を参照してください。 ## エピック ### Route 53 Resolver エンドポイントをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インバウンドエンドポイントをデプロイします。 | Route 53 Resolverはインバウンド エンドポイントを使用して、DNS クエリをオンプレミスネットワークから Route 53 Resolver に転送します。手順については、Route 53 ドキュメントの「[VPC へのインバウンド DNS クエリの転送](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html)」 を参照してください。受信エンドポイント IP アドレスをメモしておきます。 | AWS 管理者、クラウド管理者 | | アウトバウンドエンドポイントをデプロイします。 | Route 53 Resolver は、アウトバウンドエンドポイントを使用して DNS クエリをオンプレミスの DNS レゾルバ に送信します。手順については、Route 53 ドキュメントの「[アウトバウンド DNS クエリのネットワークへの転送](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html)」 を参照してください。出力エンドポイント ID を書きとめておきます。 | AWS 管理者、クラウド管理者 | ### Route 53 プライベートホストゾーンを設定および共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWSでホストされているドメインのプライベートホストゾーンを作成します。 | このゾーンは、オンプレミス環境から解決する必要がある AWSホストドメイン ( など`prod.aws.example.com`) 内のリソースの DNS レコードを保持します。手順については、Route 53 ドキュメントの「[プライベートホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)」を参照してください。プライベートホストゾーンを作成するときは、VPC を同じアカウントが所有するホストゾーンに関連付ける必要があります。このために共有サービス VPC を選択します。 | AWS 管理者、クラウド管理者 | | 基本セットアップ: プライベートホストゾーンを他のアカウントの VPC に関連付けます。 | 基本セットアップを使用している場合 (「[アーキテクチャ](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture)」セクションを参照):メンバーアカウント VPC のリソースが、このプライベートホストゾーンの DNS レコードを解決できるようにするには、VPC をホストゾーンに関連付ける必要があります。関連付けを承認してから、プログラムで関連付けを作成する必要があります。手順については、Route 53 ドキュメントの「[Amazon VPC を異なる AWS アカウントで作成したプライベートホストゾーンに関連付ける](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html)」を参照してください。 | AWS 管理者、クラウド管理者 | | 高度なセットアップ: Route 53 プロファイルを設定および共有します。 | 高度なセットアップを使用している場合 (「[アーキテクチャ](#set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment-architecture)」セクションを参照):[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)組織の構造と DNS 要件によっては、異なるアカウントまたはワークロードに対して複数のプロファイルを作成および管理する必要がある場合があります。 | AWS 管理者、クラウド管理者 | ### Route 53 Resolver 転送ルールを設定して共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスでホストされているドメインの転送ルールを作成します。 | このルールは、オンプレミスドメイン (`onprem.example.com` など) の DNS クエリを、すべてオンプレミスの DNS Resolver に転送するよう Route 53 Resolver に指示します。このルールを作成するには、オンプレミスの DNS Resolver の IP アドレスとアウトバウンドエンドポイント ID が必要です。手順については、Route 53 ドキュメントの 「[転送ルールの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-creating-rules.html)」 を参照してください。 | AWS 管理者、クラウド管理者 | | 基本セットアップ: 転送ルールを共有し、他のアカウントの VPC に関連付けます。 | 基本セットアップを使用している場合:転送ルールを有効にするには、ルールを共有して、他のアカウントの VPC に関連付ける必要があります。その後、Route 53 Resolver はドメインを解決する際にルールを考慮します。手順については、Route 53 ドキュメントの「[Resolver ルール AWS アカウント を他の と共有ルールを使用する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-sharing.html)[」および「転送ルールを VPC に関連付ける](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing-associating-rules.html)」を参照してください。 | AWS 管理者、クラウド管理者 | | 高度なセットアップ: Route 53 プロファイルを設定および共有します。 | 高度なセットアップを使用している場合:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)組織の構造と DNS 要件によっては、異なるアカウントまたはワークロードに対して複数のプロファイルを作成および管理する必要がある場合があります。 | AWS 管理者、クラウド管理者 | ### AWS 統合用にオンプレミス DNS リゾルバーを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスの DNS Resolver で条件付き転送を設定します。 | 解決のためにオンプレミス環境 AWS から に DNS クエリを送信するには、インバウンドエンドポイント IP アドレスを指すようにオンプレミス DNS リゾルバーで条件付き転送を設定する必要があります。これにより、DNS リゾルバーは、Route AWS 53 Resolver による解決のために、ホストされたドメインのすべての DNS クエリ ( の場合など`prod.aws.example.com`) をインバウンドエンドポイント IP アドレスに転送するように指示されます。 | ネットワーク管理者 | ### ハイブリッド環境でエンドツーエンドの DNS 解決を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | からオンプレミス環境 AWS への DNS 解決をテストします。 | 転送ルールが関連付けられている VPC 内のインスタンスから、オンプレミスホストドメイン (`db.onprem.example.com` の場合など) の DNS クエリを実行します。 | ネットワーク管理者 | | オンプレミス環境から への DNS 解決をテストします AWS。 | オンプレミスサーバーから、ホストされたドメイン ( の場合は など`ec2.prod.aws.example.com`) AWSの DNS 解決を実行します。 | ネットワーク管理者 | ## 関連リソース + [Amazon VPC のハイブリッドクラウド DNS オプション](https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.html) (AWS ホワイトペーパー) + [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (Route 53 ドキュメント) + [Getting started with Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html) (Route 53 ドキュメント) + [Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を簡素化](https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/)する (AWS ブログ記事) + [Amazon Route 53 Profiles と複数の VPCs を使用して DNS 管理を統合する ( AWS アカウント](https://aws.amazon.com/blogs/aws/unify-dns-management-using-amazon-route-53-profiles-with-multiple-vpcs-and-aws-accounts/)AWS ブログ記事) + [マルチアカウント DNS 環境を Amazon Route 53 Profiles に移行する](https://aws.amazon.com/blogs/networking-and-content-delivery/migrating-your-multi-account-dns-environment-to-amazon-route-53-profiles/) (AWS ブログ記事) + [スケーラブルなマルチアカウント AWS 環境での Amazon Route 53 プロファイルの使用](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-route-53-profiles-for-scalable-multi-account-aws-environments/) (AWS ブログ記事)   # ELB ロードバランサーに TLS 終了が必要であることを確認 *Amazon Web Services、Priyanka Chaudhary* ## 概要 Amazon Web Services (AWS) クラウドでは、Elastic Load Balancing (ELB) が、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、IP アドレス、AWS Lambda 関数などの複数のターゲットにわたって受信したアプリケーショントラフィックを自動的に分散します。ロードバランサーはリスナーを使用して、ユーザーからトラフィックを受け入れるために、ロードバランサーが使用するポートとプロトコルを定義します。Application Load Balancer はアプリケーションレイヤーでルーティングを決定し、HTTP/HTTPS プロトコルを使用します。Classic Load Balancer は、TCP または Secure Sockets Layer (SSL) プロトコルを使用するトランスポート層、または HTTP/HTTPS を使用してアプリケーション層でルーティングを決定します。 パターンは、Application Load Balance と Classic Load Balancerの複数のイベントタイプを検査する、セキュリティ制御を提供します。関数が呼び出される場合、AWS Lambda はイベントを検査し、ロードバランサーが準拠していることを確認します。 この関数は、次のAPI呼び出しでAmazon CloudWatch Eventsを初期化します: 「[CreateLoadBalancer](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancer.html)」 、「[CreateLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerListeners.html)」 、「[DeleteLoadBalancerListeners](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_DeleteLoadBalancerListeners.html)」 、「[CreateLoadBalancerPolicy](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_CreateLoadBalancerPolicy.html)」 、「[SetLoadBalancerPoliciesOfListener](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_SetLoadBalancerPoliciesOfListener.html)」 、「[CreateListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_CreateListener.html)」 、「[DeleteListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_DeleteListener.html)」 、及び「[ModifyListener](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ModifyListener.html)」 。イベントが3つの API のいずれかを検出する場合、Python スクリプトを実行する AWS Lambda を呼び出します。Python スクリプトは、リスナーに SSL 証明書が含まれているか、および適用されるポリシーがTransport Layer Security (TLS) を使用しているかを評価します。SSL ポリシーが TLS 以外であると判断された場合、関数から Amazon Simple Notification Service (Amazon SNS) 通知が関連の情報を持つユーザーに送信されます。  ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント **機能制限 ** + このセキュリティコントロールでは、ロードバランサーリスナーが更新されない限り、既存のロードバランサーをチェックしません。 + このセキュリティ制御はリージョンごとに行われます。監視する AWS リージョンごとにデプロイする必要があります。 ## アーキテクチャ **ターゲットアーキテクチャ** ![\[ロードバランサーに TLS 終了が必要であることの確認。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da99cda2-ac34-4791-a2bd-d37264d8d3d9/images/af92b3c8-32bb-45eb-a2a8-d8276fb3e824.png) **自動化とスケール** + [AWS Organizations](https://aws.amazon.com/organizations/) を使用している場合は、[AWS Cloudformation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) を使用して、モニタリングする複数のアカウントにこのテンプレートをデプロイできます。 ## ツール **AWS サービス** + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」 を使用することで、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクルの最初から最後までリソースを管理できます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。 + [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – Amazon CloudWatch Events は、AWS リソースの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。 + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)」 — Amazon Simple Storage Service (Amazon S3) は、拡張性の高いオブジェクトストレージサービスで、ウェブサイト、モバイルアプリケーション、バックアップ、データレイクなど、幅広いストレージソリューションに使用できます。 + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) — Amazon Simple Notification Service (Amazon SNS) は、ウェブサーバーや E メールアドレスなど、パブリッシャーとクライアント間のメッセージ配信や送信を調整および管理します。サブスクライバーは、サブスクライブしているトピックに対して発行されたすべてのメッセージを受信します。また、同じトピックのサブスクライバーはすべて同じメッセージを受信します。 **コード** このパターンには、以下の添付ファイルが含まれます。 + `ELBRequirestlstermination.zip` — セキュリティコントロール用の Lambda コード。 + `ELBRequirestlstermination.yml` — イベントとLambda 関数をセットアップする CloudFormation テンプレート。 ## エピック ### S3 バケットのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを定義します。 | 「[Amazon S3 コンソール](https://console.aws.amazon.com/s3/)」 で、Lambda コードの .zip ファイルをホストする S3 バケットを選択、または作成します。この S3 バケットは、評価したいロードバランサーと同じ AWS リージョンに存在する必要があります。S3 バケット名はグローバルに一意であり、名前空間はすべての AWS アカウントによって共有されます。S3 バケット名には、先頭にスラッシュを含めることはできません。 | クラウドアーキテクト | | Lambda コードをアップロードします。 | *添付ファイル*セクションで提供されている Lambda コード (`ELBRequirestlstermination.zip` ファイル) を S3 バケットにアップロードします。 | クラウドアーキテクト | ### CloudFormation のテンプレートを入手するには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation のテンプレートを起動します。 | S3 バケットと同じ 「[AWS リージョンで AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)」を開き、添付のテンプレート `ELBRequirestlstermination.yml` をデプロイします。AWS CloudFormation テンプレートのデプロイに関する詳細については、CloudFormation ドキュメントの「[AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。 | クラウドアーキテクト | | テンプレートのパラメータを入力します。 | テンプレートを起動すると、次の情報の入力を求められます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/verify-that-elb-load-balancers-require-tls-termination.html) | クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションを確認します。 | CloudFormation テンプレートが正常にデプロイされると、指定したメールアドレスにサブスクリプションメールが送信されます。違反通知の受信を開始するには、このメールサブスクリプションを確認する必要があります。 | クラウドアーキテクト | ## 関連リソース + 「[AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」 (AWS CloudFormation ドキュメント) + 「[AWS Lambda とは?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 (AWS Lambda ドキュメント） + 「[Classic Load Balancer とは？](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html)」 (ELB ドキュメント) + 「[Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」 (ELB ドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/da99cda2-ac34-4791-a2bd-d37264d8d3d9/attachments/attachment.zip)」 # Splunk を使用して AWS Network Firewall のログとメトリクスを表示する *Amazon Web Services、Ivo Pinto* ## 概要 多くの組織は、さまざまなソースからのログとメトリクスを一元的に集約して可視化するツールとして [Splunk Enterprise](https://www.splunk.com/en_us/products/splunk-enterprise.html) を使用しています。このパターンは、Splunk Add-On for AWS を使用して [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) から [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) ログとメトリクスを取得するように Splunk を設定するのに役立ちます。  これを実現するには、読み取り専用の AWS Identity and Access Management (IAM) ロールを作成します。Splunk Add-On for AWS は、このロールを使用して CloudWatch にアクセスします。CloudWatch からメトリクスとログを取得するように Splunk Add-On for AWS を設定します。最後に、取得したログデータとメトリクスから Splunk で視覚化を作成します。 ## 前提条件と制限 **前提条件** + [Splunk](https://www.splunk.com/) アカウント + Splunk Enterprise インスタンス (バージョン 8.2.2 以降)  + アクティブな AWS アカウント + Network Firewall (CloudWatch Logs にログを送信するように[セットアップ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html)および[設定](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-cw-logs.html)済み) **制限事項** + Splunk Enterprise は、AWS クラウド内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターとしてデプロイする必要があります。 + 自動的に検出された Amazon EC2 の IAM ロールを使用したデータの収集は、AWS 中国リージョンではサポートされていません。 ## アーキテクチャ ![\[AWS Network Firewall と Splunk のロギングアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c6ce254a-841f-4bed-8f9f-b35e99f22e56/images/3dd420e9-70af-4a42-b24d-c54872c55e0b.png) この図表は、以下を示すものです: 1. Network Firewall は CloudWatch Logs にログを公開します。 1. Splunk Enterprise は CloudWatch からメトリクスとログを取得します。 このアーキテクチャのサンプルメトリクスとサンプルログを入力するために、ワークロードは Network Firewall エンドポイントを通過するトラフィックを生成してインターネットに移動します。これは、[ルートテーブル](https://docs.aws.amazon.com/network-firewall/latest/developerguide/vpc-config.html#vpc-config-route-tables)の使用によって実現されます。このパターンではワークロードとして単一の Amazon EC2 インスタンスを使用しますが、Network Firewall が CloudWatch Logs にログを送信するように設定されていれば、このパターンは任意のアーキテクチャに適用できます。 このアーキテクチャでは、別の仮想プライベートクラウド (VPC) の Splunk Enterprise インスタンスも使用します。ただし、Splunk インスタンスは、CloudWatch API に到達できる限り、ワークロードと同じ VPC など、別の場所に配置することもできます。 ## ツール **AWS サービス** + 「[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」は、すべてのシステム、アプリケーション、 AWS からのログを一元化することを支援して、ログを監視して安全にアーカイブできるようにします。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、ステートフルでマネージド型のネットワークファイアウォールならびに侵入検知および防止サービスです。 その他のツール + 「[Splunk](https://www.splunk.com/)」 はログデータのモニタリング、視覚化、分析に役立ちます。 ## エピック ### IAM ロールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ポリシーを作成します。 | 「[JSON エディタを使用してポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」の手順に従って、CloudWatch Logs データおよび CloudWatch メトリクスへの読み取り専用アクセスを許可する IAM ポリシーを作成します。以下の ポリシーを JSON エディタに貼り付けます。
{
    "Statement": [
        {
            "Action": [
                "cloudwatch:List*",
                "cloudwatch:Get*",
                "network-firewall:List*",
                "logs:Describe*",
                "logs:Get*",
                "logs:List*",
                "logs:StartQuery",
                "logs:StopQuery",
                "logs:TestMetricFilter",
                "logs:FilterLogEvents",
                "network-firewall:Describe*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}
| AWS 管理者 | | 新しい IAM ロールを作成します。 | 「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」の手順に従って、Splunk Add-On for AWS が CloudWatch へのアクセスに使用する IAM ロールを作成します。**[アクセス許可ポリシー]** で、以前に作成したポリシーを選択します。 | AWS 管理者 | | Splunk クラスターの EC2 インスタンスに IAM ロールを割り当てます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | AWS 管理者 | ### Splunk Add-On for AWS をインストールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アドオンをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | AWS 認証情報を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)詳細については、Splunk ドキュメントの「[Find an IAM role within your Splunk platform instance](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Find_an_IAM_role_within_your_Splunk_platform_instance)」を参照してください。 | Splunk 管理者 | ### CloudWatch への Splunk アクセスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch Logs からの Network Firewall ログの取得を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)デフォルトでは、Splunk は 10 分ごとにログデータを取得します。これは、**[Advanced Settings]**で設定可能なパラメータです。詳細については、Splunk ドキュメントの「[Configure a CloudWatch Logs input using Splunk Web](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_Logs_input_using_Splunk_Web)」を参照してください。 | Splunk 管理者 | | CloudWatch からの Network Firewall メトリクスの取得を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html)デフォルトでは、Splunk は 5 分ごとにメトリクスデータを取得します。これは、**[Advanced Settings]**で設定可能なパラメータです。詳細については、Splunk ドキュメントの「[Configure a CloudWatch input using Splunk Web](https://splunk.github.io/splunk-add-on-for-amazon-web-services/#Configure_a_CloudWatch_input_using_Splunk_Web)」を参照してください。 | Splunk 管理者 | ### クエリを使用して Splunk 可視化を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 上位の送信元 IP アドレスを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | パケット統計を表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | | 最も使用されている送信元ポートを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/view-aws-network-firewall-logs-and-metrics-by-using-splunk.html) | Splunk 管理者 | ## 関連リソース **AWS ドキュメント** + [AWS サービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) (IAM ドキュメント) + [IAM ポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-start) (IAM ドキュメント) + [AWS Network Firewall でのロギングとモニタリング](https://docs.aws.amazon.com/network-firewall/latest/developerguide/logging-monitoring.html) (Network Firewall ドキュメント) + [AWS Network Firewall のルートテーブル設定](https://docs.aws.amazon.com/network-firewall/latest/developerguide/route-tables.html) (Network Firewall ドキュメント) **AWS ブログ投稿** + [AWS Network Firewall デプロイモデル](https://aws.amazon.com/pt/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) 「**AWS Marketplace**」 + [Splunk Enterprise Amazon マシンイメージ (AMI)](https://aws.amazon.com/marketplace/pp/prodview-l6oos72bsyaks) # その他のパターン **Topics** + [Session Manager と Amazon EC2 Instance Connect により踏み台ホストにアクセス](access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.md) + [AWS Fargate、AWS PrivateLink、Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします。](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md) + [AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md) + [AWS Managed Microsoft AD とオンプレミスの Microsoft Active Directory を使用して DNS 解決を一元化する](centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.md) + [、Angular AWS Amplify、および Module Federation を使用してマイクロフロントエンド用のポータルを作成する](create-amplify-micro-frontend-portal.md) + [プライベートエンドポイントと Application Load Balancer を使用して、Amazon API Gateway API を内部 Web サイトにデプロイする](deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.md) + [を使用してパブリックサブネットの検出属性ベースのアクセスコントロールをデプロイする AWS Config](deploy-detective-attribute-based-access-controls-for-public-subnets-by-using-aws-config.md) + [パブリックサブネットのための属性ベースの予防的アクセスコントロールをデプロイする](deploy-preventative-attribute-based-access-controls-for-public-subnets.md) + [Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする](enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.md) + [AWS Transit Gateway Connect を使用して VRF を AWS に拡張する](extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.md) + [で F5 BIG-IP ワークロードを F5 BIG-IP VE に移行する AWS クラウド](migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.md) + [Amazon EKS Auto Mode を有効化する際に NGINX Ingress Controller を移行する](migrate-nginx-ingress-controller-eks-auto-mode.md) + [非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md) + [サービスコントロールポリシーを使用して、アカウントレベルでのインターネットアクセスを防止する](prevent-internet-access-at-the-account-level-by-using-a-service-control-policy.md) + [AWS Network Firewall から Slack チャネルにアラートを送信](send-alerts-from-aws-network-firewall-to-a-slack-channel.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [AWS Elastic Disaster Recoveryで Oracle JD Edwards EnterpriseOne のディザスタリカバリをセットアップする](set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.md) + [BMC ディスカバリークエリを使用して移行計画のために移行データを抽出](use-bmc-discovery-queries-to-extract-migration-data-for-migration-planning.md) + [Network Firewall を使用して、アウトバウンドトラフィックのサーバー名表示から DNS ドメイン名をキャプチャする](use-network-firewall-to-capture-the-dns-domain-names-from-the-server-name-indication-sni-for-outbound-traffic.md)