翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # インフラストラクチャ **Topics** + [Session Manager と Amazon EC2 Instance Connect により踏み台ホストにアクセス](access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.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) + [Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化](centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.md) + [起動時に EC2 インスタンスに必須タグが欠けていないか確認する](check-ec2-instances-for-mandatory-tags-at-launch.md) + [ステートファイルが失われた後、 AWS Account Factory for Terraform (AFT) リソースを安全にクリーンアップする](clean-up-aft-resources-safely-after-state-file-loss.md) + [AWS CodePipeline に適用されない AWS リージョンにパイプラインを作成](create-a-pipeline-in-aws-regions-that-don-t-support-aws-codepipeline.md) + [AWS CDK アスペクトとエスケープハッチを使用してデフォルトのロール名をカスタマイズする](customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.md) + [Amazon EC2 にプライベート静的 IP を使用して Cassandra クラスターをデプロイしてリバランスを回避する](deploy-a-cassandra-cluster-on-amazon-ec2-with-private-static-ips-to-avoid-rebalancing.md) + [AWS Transit Gateway Connect を使用して VRF を AWS に拡張する](extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.md) + [AWS KMS キーのキーの状態が変更されたときに Amazon SNS 通知を受け取る](get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.md) + [非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md) + [コードリポジトリ AWS Service Catalog を使用して で Terraform 製品をプロビジョニングする](provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.md) + [Amazon SES を使用して 1 つの E メールアドレス AWS アカウント に複数の を登録する](register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.md) + [単一アカウントの AWS 環境でハイブリッドネットワークの DNS 解決を設定](set-up-dns-resolution-for-hybrid-networks-in-a-single-account-aws-environment.md) + [AWS CloudFormation を使用して Amazon EC2 に UiPath RPA ボットを自動的にセットアップする](set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.md) + [AWS で可用性の高い PeopleSoft アーキテクチャを設定する](set-up-a-highly-available-peoplesoft-architecture-on-aws.md) + [AWS Elastic Disaster Recoveryで Oracle JD Edwards EnterpriseOne のディザスタリカバリをセットアップする](set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.md) + [マルチリージョン、マルチアカウント組織で CloudFormation ドリフト検出を設定する](set-up-aws-cloudformation-drift-detection-in-a-multi-region-multi-account-organization.md) + [S3 バケットを AWS CloudFormation スタックとして正常にインポートしました](successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.md) + [AWS DataSync を使用して、異なる AWS リージョンの Amazon EFS ファイルシステム間でデータを同期する](synchronize-data-between-amazon-efs-file-systems-in-different-aws-regions-by-using-aws-datasync.md) + [LocalStack および Terraform テストを使用して AWS インフラストラクチャをテストする](test-aws-infra-localstack-terraform.md) + [SAP ペースメーカークラスターを ENSA1 から ENSA2 にアップグレード](upgrade-sap-pacemaker-clusters-from-ensa1-to-ensa2.md) + [異なる AWS アカウント間の VPC で一貫したアベイラビリティーゾーンを使用する](use-consistent-availability-zones-in-vpcs-across-different-aws-accounts.md) + [アクセスコントロールと自動化に IAM ポリシーのユーザー ID を使用する](use-user-ids-iam-policies-access-control-automation.md) + [Account Factory for Terraform (AFT) のコードをローカルで検証する](validate-account-factory-for-terraform-aft-code-locally.md) + [その他のパターン](infrastructure-more-patterns-pattern-list.md) # Session Manager と Amazon EC2 Instance Connect により踏み台ホストにアクセス *Amazon Web Services、Piotr Chotkowski、Witold Kowalik* ## 概要 *踏み台ホスト*は、別名*ジャンプボックス*と呼ばれる、外部ネットワークからプライベートネットワークにあるリソースへの単一アクセスポイントを提供するサーバーです。インターネットなどの外部のパブリックネットワークに公開されているサーバーは、不正アクセスによる潜在的なセキュリティリスクをもたらします。これらのサーバーへのアクセスを保護し、制御することは重要です。 このパターンでは、[Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) と [Amazon EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) を使って、 AWS アカウントにデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) の踏み台ホストに安全に接続する方法について説明します。Session Manager は の一機能です AWS Systems Manager。このパターンには次のようなメリットがあります。 + デプロイされた踏み台ホストには、パブリックインターネットに公開されているオープンなインバウンドポートはありません。これにより、潜在的なアタックサーフェスが減少します。 + に長期 Secure Shell (SSH) キーを保存して維持する必要はありません AWS アカウント。代わりに、各ユーザーは踏み台ホストに接続するたびに新しい SSH キーペアを生成します。 AWS Identity and Access Management (IAM) ポリシーは、ユーザーの AWS 認証情報にアタッチされ、踏み台ホストへのアクセスを制御します。 **対象者** このパターンは、Amazon EC2、Amazon Virtual Private Cloud (Amazon VPC) および Hashicorp Terraform の基本知識がある閲覧者を対象としています。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + AWS Command Line Interface (AWS CLI) バージョン 2、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)済み + 用の Session Manager プラグイン AWS CLI、[インストール済み](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html) + 「[インストール済み](https://developer.hashicorp.com/terraform/cli)」のテラフォーム CLI + Amazon Simple Storage Service (Amazon S3) バケットやAmazon DynamoDB テーブルなどTerraform ステータスを格納するリモートバックエンドとしてのTerraform「[ステータス](https://developer.hashicorp.com/terraform/language/state)」の格納 Terraform ステータスにリモートバックエンドを使用する方法の詳細については、「[Amazon S3 のバックエンド](https://www.terraform.io/language/settings/backends/s3)」(Terraform のドキュメント) を参照してください。Amazon S3 バックエンドでリモートステート管理をセットアップするコードサンプルについては、「[remote-state-s3-backend](https://registry.terraform.io/modules/nozaq/remote-state-s3-backend/aws/latest)」 (Terraform レジストリ) を参照してください。次の要件に注意してください。 + Amazon S3 バケットと DynamoDB テーブルは同じ AWS リージョンにある必要があります。 + DynamoDB テーブルを作成する場合、パーティションキーは `LockID` (大文字と小文字を区別)、パーティションキータイプは `String` である必要があります。他の設定はすべてデフォルト値のままにしておきます。詳細については、「DynamoDB のドキュメント」の「[プライマリキーについて](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey)」と「[テーブルの作成](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html)」を参照してください。 + SSH クライアント、インストール済み **制限事項** + このパターンは、概念実証 (PoC) として、または今後の開発の基礎となることを目的としています。本稼働環境では、現行の形式を使用しないでください。デプロイする前に、要件とユースケースに合うようにリポジトリ内のサンプルコードを見直してください。 + このパターンは、ターゲットの踏み台ホストがオペレーティングシステムとして Amazon Linux 2 を使用していることを前提としています。他の Amazon マシンイメージ (AMI) を使用することもできますが、他のオペレーティングシステムはこのパターンの対象外です。 **注記** Amazon Linux 2 のサポートは間もなく終了します。詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください。 + このパターンでは、踏み台ホストは NAT ゲートウェイとインターネットゲートウェイのないプライベートサブネットに配置されます。この設計により、Amazon EC2 インスタンスは公共のインターネットから隔離されます。インターネットと通信できるようにする特定のネットワーク設定を追加できます。詳細については、「Amazon VPC のドキュメント」の「[仮想プライベートクラウド (VPC) を他のネットワークに接続](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)」を参照してください。同様に、[最小特権の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)に従って、明示的にアクセス許可を付与 AWS アカウント しない限り、踏み台ホストは 内の他のリソースにアクセスできません。詳細については、IAM ドキュメントの「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」を参照してください **製品バージョン** + AWS CLI バージョン 2 + Terraform バージョン 1.3.9 ## アーキテクチャ **ターゲットテクノロジースタック** + シングルパブリックサブネットを持つ VPC + 以下の「[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」： + `amazonaws..ssm` – AWS Systems Manager サービスのエンドポイント。 + `amazonaws..ec2messages` — Systems Manager は、このエンドポイントを使用して、SSM Agent から Systems Manager サービスへの呼び出しを行います。 + `amazonaws..ssmmessages` — Session Manager はこのエンドポイントで、安全なデータチャネルを介して Amazon EC2 インスタンスに接続します。 + Amazon Linux 2 を実行する `t3.nano` Amazon EC2 インスタンスを起動します。 + IAM ロールとインスタンス プロファイル + エンドポイントと Amazon EC2 インスタンスの Amazon VPC セキュリティグループとセキュリティグループルール **ターゲットアーキテクチャ** ![\[Session Manager により、踏み台ホストにアクセスするアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a02aed20-1852-4c91-902f-f553795006e2/images/819c503b-7eec-4a9c-862b-b87107d50dc1.png) 図に示す内容は以下のとおりです。 1. ユーザーが割り当てられている IAM ロールには、次の操作を実行する権限があります。 + Amazon EC2 インスタンスを認証および認可し、接続する + Session Management (IAM) でセッションを開始 1. ユーザーは Session Manager から SSH セッションを開始します。 1. Session Manager はユーザーを認証し、関連する IAM ポリシーの権限を検証し、設定を確認し、SSM エージェントにメッセージを送信して双方向接続を開きます。 1. ユーザーは Amazon EC2 メタデータを介して SSH パブリックキーを踏み台ホストにプッシュします。これは各接続の前に行う必要があります。SSH 公開鍵は 60 秒間使用可能です。 1. 踏み台ホストは、Systems Manager と Amazon EC2 のインターフェイス VPC エンドポイントと通信します。 1. ユーザーは TLS 1.2 で暗号化された双方向通信チャネルにより、Session Manager を通じて踏み台ホストにアクセスします。 **自動化とスケール** このアーキテクチャを自動的にデプロイしまたは拡張するには、次のオプションを使用します。 + 継続的な統合および継続的な提供 (CI/CD) パイプラインで、アーキテクチャをデプロイできます。 + コードを変更して、踏み台ホストのインスタンスタイプを変更できます。 + コードを変更して複数の踏み台ホストをデプロイできます。`bastion-host/main.tf` ファイルの `aws_instance` リソースブロックに、`count` メタ引数を追加します。詳細については、「[Terraform のドキュメント](https://developer.hashicorp.com/terraform/language/meta-arguments/count)」を参照してください。 ## ツール **AWS のサービス** + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰が認証され、誰に使用を許可するかを制御することで、 AWS リソースへのアクセスを安全に管理できます。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。このパターンは、システムマネージャーの機能である「[Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)」 を使用します。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ infrastructure as code (IaC) ツールです。このパターンは「[Terraform CLI](https://developer.hashicorp.com/terraform/cli)」を使用しています。 **コードリポジトリ** このパターンのコードは、GitHub·内の「[Session Manager と Amazon EC2 Instance Connectを使用して踏み台ホストにアクセスする](https://github.com/aws-samples/secured-bastion-host-terraform)」リポジトリで利用できます。 ## ベストプラクティス + コードのセキュリティと品質を向上させるために、自動コードスキャンツールの使用をお勧めします。このパターンは、IaC 用の静的コード分析ツールである「[Checkov](https://www.checkov.io/)」を使用してスキャンされました。最低でも、`terraform validate` と `terraform fmt -check -recursive` Terraform コマンドを使用して基本的な検証とフォーマットのチェックを行うことをお勧めします。 + IaC の自動テストを追加することは良い習慣です。Terraform コードをテストするさまざまな方法の詳細については、「[HashiCorp Terraform のテスト](https://www.hashicorp.com/blog/testing-hashicorp-terraform)」(Terraform ブログ記事) を参照してください。 + デプロイ中、新しいバージョンの「[Amazon Linux 2 AMI](https://aws.amazon.com/marketplace/pp/prodview-zc4x2k7vt6rpu?sr=0-1&ref_=beagle&applicationId=AWSMPContessa)」が検出されるたびに、Terraform は置換 Amazon EC2 インスタンスを使用します。これにより、パッチやアップグレードを含む新しいバージョンのオペレーティングシステムがデプロイされます。デプロイスケジュールの頻度が低い場合、インスタンスに最新のパッチが適用されないため、セキュリティ上のリスクが生じる可能性があります。デプロイされた Amazon EC2 インスタンスには、セキュリティパッチを頻繁に更新して適用することが重要です。詳細については、「[Amazon EC2 での更新管理](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/update-management.html)」を参照してください。 + このパターンは概念実証であるため、 AWS などの 管理ポリシーを使用します`AmazonSSMManagedInstanceCore`。 AWS 管理ポリシーは一般的なユースケースを対象としますが、最小特権のアクセス許可は付与しません。ユースケースに応じて、このアーキテクチャにデプロイされたリソースに最小特権のアクセス権限を付与するカスタムポリシーを作成することをお勧めします。詳細については、[「 AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies)」を参照してください。 + SSH キーへのアクセスを保護し、キーを安全な場所に保存するにはパスワードを使用してください。 + 踏み台ホストのロギングとモニタリングを設定します。記録とモニタリングは、運用面とセキュリティ面の両方の観点から、システムを保守する上で重要な部分です。踏み台ホストの接続とアクティビティをモニタリングする方法は複数あります。詳細については、Systems Manager ドキュメントの次のトピックを参照してください。 + [モニタリング AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring.html) + [でのログ記録とモニタリング AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/logging-and-monitoring.html) + 「[セッションアクティビティの監査](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-auditing.html)」 + 「[セッションアクティビティのログ記録](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html)」 ## エピック ### リソースのデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | DevOps エンジニア、開発者 | | ディレクトリから Terraform を開始します。 | このステップは最初のデプロイにのみ必要です。このパターンをレデプロイする場合、次の手順に進んでください。クローンしたリポジトリのルートディレクトリに、以下のコマンドを入力します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html)
terraform init \
    -backend-config="bucket=$S3_STATE_BUCKET" \
    -backend-config="key=$PATH_TO_STATE_FILE" \
    -backend-config="region=$AWS_REGION
別の方法として、**config.tf** ファイルを開き、`terraform` セクションでこれらの値を手動で指定することもできます。 | DevOps エンジニア、開発者、Terraform | | リソースのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | DevOps エンジニア、開発者、Terraform | ### ローカル環境の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSH 接続を設定します。 | SSH 設定を更新して、Session Manager を介して SSH 接続を有効にします。手順については、「[Session Manager の SSH 接続を許可](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html#ssh-connections-enable)」を参照してください。これにより、許可されたユーザーは、プロキシコマンドを入力し、Session Manager セッションを開始し、双方向接続を介してすべてのデータを転送することができます。 | DevOps エンジニア | | SSH キーを生成します。 | 次のコマンドを入力して、ローカルで非公開と公開 SSH キーペアを生成します。このキーペアで踏み台ホストに接続します。
ssh-keygen -t rsa -f my_key
| DevOps エンジニア、開発者 | ### Session Manager で踏み台ホストに接続 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インスタンスの ID を取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | AWS 全般 | | SSH パブリックキーを送信します。 | このセクションでは、踏み台ホストの[インスタンスメタデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)にパブリックキーをアップロードします。キーがアップロードされたら、60 秒以内に踏み台ホストとの接続を開始してください。60 秒後、パブリックキーは削除されます。詳細については、このパターンの「[トラブルシューティング](#access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect-troubleshooting)」セクションを参照してください。踏み台ホストに接続する前にキーが削除されないように、次の手順をすぐに実行してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | AWS 全般 | | 踏み台ホストに接続します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html)踏み台ホストとの SSH 接続を開く方法は他にもあります。詳細については、このパターンの「[追加情報](#access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect-additional)」セクションの「*踏み台ホストとの SSH 接続を確立するための代替方法*」を参照してください。 | AWS 全般 | ### (オプション) クリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイされたリソースを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | DevOps エンジニア、開発者、Terraform | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 踏み台ホストに接続しようと試みる時の `TargetNotConnected` エラー | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) | | 踏み台ホストに接続しようと試みる時の `Permission denied` エラー | パブリックキーが踏み台ホストにアップロードされたら、60 秒以内に接続を開始してください。60 秒が経過すると、そのキーは自動的に削除され、そのキーを使用してインスタンスに接続できなくなります。その場合は、手順を繰り返してそのキーをインスタンスに再送信できます。 | ## 関連リソース **AWS ドキュメント** + [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) (Systems Manager のドキュメント) + 「[AWS CLI用の Session Manager プラグインをインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)」(Systems Manager のドキュメント) + 「[Session Manager の SSH 接続を許可](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html#ssh-connections-enable)」(Systems Manager のドキュメント) + 「[EC2 Instance Connect の使用について](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html)」(Amazon EC2 のドキュメント) + 「[EC2 Instance Connect で接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html)」(Amazon EC2 のドキュメント) + 「[Amazon EC2 の Identity and Access Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-iam.html)」(Amazon EC2 のドキュメント) + 「[IAM ロールを使用して、Amazon EC2 インスタンスで実行されているアプリケーションにアクセス許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」(IAM ドキュメント) + [IAM におけるセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」(IAM のドキュメント) + 「[セキュリティグループを使用してリソースへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)」(Amazon VPC ドキュメント) **その他のリソース** + 「[Terraform 開発者向けウェブページ](https://developer.hashicorp.com/terraform)」 + 「[コマンド：検証](https://developer.hashicorp.com/terraform/cli/commands/validate)」(Terraform のドキュメント) + 「[コマンド：fmt](https://developer.hashicorp.com/terraform/cli/commands/fmt)」(Terraform のドキュメント) + 「[HashiCorp Terraform のテスト](https://www.hashicorp.com/blog/testing-hashicorp-terraform)」(HashiCorp ブログ記事） + 「[Checkov webpage](https://www.checkov.io/)」 ## 追加情報 踏み台ホストとの SSH 接続を確立するための代替方法 *ポート転送* この `-D 8888` オプションを使用して、動的ポートフォワーディングで SSH 接続を開くことができます。詳細については、explainshell.com の「[説明](https://explainshell.com/explain?cmd=ssh+-i+%24PRIVATE_KEY_FILE+-D+8888+ec2-user%40%24INSTANCE_ID)」を参照してください。以下は、ポート転送を使用して SSH 接続を開くコマンドの例です。 ``` ssh -i $PRIVATE_KEY_FILE -D 8888 ec2-user@$INSTANCE_ID ``` この接続は、ローカルブラウザからのトラフィックを踏み台ホスト経由で転送できる SOCKS プロキシを開くようなものです。Linux または MacOS をご使用の場合、すべてのオプションを表示するには、`man ssh` を入力します。SSH リファレンスマニュアルが表示されます。 提供されたスクリプトを使用 「[エピック](#access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect-epics)」セクションの「*Session Manager を使って踏み台ホストに接続する*」に説明されている手順を手動で実行する代わりに、コードリポジトリに含まれている **connect.sh** スクリプトを使用することができます。このスクリプトは SSH キーペアを生成し、パブリックキーを Amazon EC2 インスタンスにプッシュして、踏み台ホストとの接続を開始します。コマンドを実行すると、タグとキー名を引数として渡します。以下はスクリプトを実行するコマンドの例です。 ``` ./connect.sh sandbox-dev-bastion-host my_key ``` # AWS Managed Microsoft AD とオンプレミスの Microsoft Active Directory を使用して DNS 解決を一元化する *Amazon Web Services、Brian Westmoreland* ## 概要 このパターンは、 AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) と Amazon Route 53 の両方を使用して、 AWS マルチアカウント環境内で DNS 解決を一元化するためのガイダンスを提供します。このパターンでは AWS 、DNS 名前空間はオンプレミス DNS 名前空間のサブドメインです。このパターンでは、オンプレミスの DNS ソリューションが Microsoft Active Directory を使用する AWS ときにクエリを に転送するようにオンプレミスの DNS サーバーを設定する方法についても説明します。  ## 前提条件と制限事項 **前提条件** + を使用して設定された AWS マルチアカウント環境 AWS Organizations。 + ネットワーク接続が確立されました AWS アカウント。 + AWS とオンプレミス環境との間で確立されたネットワーク接続 ( AWS Direct Connect または任意のタイプの VPN 接続を使用）。 + AWS Command Line Interface (AWS CLI) ローカルワークステーションで設定されます。 + AWS Resource Access Manager (AWS RAM) アカウント間で Route 53 ルールを共有するために使用されます。したがって、エ[ピック](#centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory-epics)セクションで説明されているように、 AWS Organizations 環境内で共有を有効にする必要があります。 **制限事項** + AWS Managed Microsoft AD Standard Edition には 5 つの共有の制限があります。 + AWS Managed Microsoft AD Enterprise Edition には 125 共有の制限があります。 + このパターンのソリューションは、共有 AWS リージョン をサポートする に限定されます AWS RAM。 **製品バージョン** + Windows Server 2008、2012、2012 R2、または 2016 で実行されている Microsoft Active Directory ## アーキテクチャ **ターゲットアーキテクチャ** ![\[AWS 上で一元化された DNS 解決のアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/91430e2a-f7f6-4dbe-9fe7-8abed1f764a7/images/9b5fc51d-590b-468f-80f7-1949f3b3b258.png) この設計では、 AWS Managed Microsoft AD は共有サービスにインストールされます AWS アカウント。これは必須ではありませんが、本パターンではこの設定が前提となっています。別の AWS Managed Microsoft AD で を設定する場合は AWS アカウント、エ[ピック](#centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory-epics)セクションのステップを適宜変更する必要がある場合があります。 この設計では、Route 53 Resolver を使用して、Route 53 ルールによる名前解決案が適用されます。オンプレミスの DNS ソリューションが Microsoft DNS を使用する場合、会社の DNS 名前空間( `aws.company.com` ) のサブドメインである AWS 名前空間( `company.com` )の条件付き転送ルールを作成するのは簡単ではありません。従来の条件付きフォワーダーを作成しようとすると、エラーになります。これは、Microsoft アクティブディレクトリが、 `company.com` のどのサブドメインに対してもすでに権限があると見なされているためです。このエラーを回避するには、まずその名前空間の権限を委任するために、 `aws.company.com` の委任を作成する必要があります。作成後には、条件付きフォワーダーを作成できます。 各スポークアカウントの Virtual Private Cloud (VPC) は、ルート名前空間に基づいて独自の DNS AWS 名前空間を持つことができます。この設計では、各スポークアカウントが、ベースの AWS 名前空間にアカウント名の省略形を追加します。スポークアカウントのプライベートホストゾーンが作成されると、ゾーンはスポークアカウントのローカル VPC と中央 AWS ネットワークアカウントの VPC に関連付けられます。これにより、中央 AWS ネットワークアカウントはスポークアカウントに関連する DNS クエリに応答できます。これにより、Route 53 と の両方 AWS Managed Microsoft AD が協力して、 AWS 名前空間を管理する責任を共有します (`aws.company.com`)。 **自動化とスケール** この設計では、Route 53 Resolver エンドポイントを使用して、 AWS とオンプレミス環境の間で DNS クエリをスケーリングします。Route 53 Resolver の各エンドポイントは、複数のエラスティックネットワークインターフェイス (複数のアベイラビリティーゾーンにわたって分散している) で構成され、各ネットワークインターフェースは 1 秒あたり最大 10,000 件のクエリを処理できます。Route 53 Resolver は、エンドポイントあたり最大 6 つの IP アドレスが適用されるため、この設計は複数のアベイラビリティーゾーンにまたがって 1 秒あたり最大 60,000 件の DNS クエリが適用され、高い可用性を実現します。  さらに、このパターンでは、 AWS内の将来の拡張が自動的に考慮されます。オンプレミスで設定した DNS 転送ルールを変更しなくても、 AWSに追加された新しい VPC と、これに関連するプライベートホストゾーンが自動的にサポートされます。  ## ツール **AWS サービス** + [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) は、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できるようにします 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 Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS ウェブサービスです。 **ツール** + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。このパターンでは、 AWS CLI を使用して Route 53 認可を設定します。 ## エピック ### AWS Managed Microsoft AD ディレクトリを作成して共有する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイします AWS Managed Microsoft AD。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html) | AWS 管理者 | | ディレクトリの共有 | ディレクトリを構築したら、 AWS 組織 AWS アカウント 内の他の と共有します。手順については、*AWS Directory Service 管理ガイド*の「[Share your directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step2_share_directory.html)」を参照してください。 AWS Managed Microsoft AD Standard Edition には 5 共有の制限があります。Enterprise Edition には 125 共有の制限があります。 | AWS 管理者 | ### Route 53 を設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Route 53 Resolvers の作成 | Route 53 Resolver は、 AWS とオンプレミスデータセンター間の DNS クエリ解決を容易にします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html)中央 AWS ネットワークアカウント VPC の使用は必須ではありませんが、残りのステップではこの設定を前提としています。 | AWS 管理者 | | Route 53 ルールの作成 | 特定のユースケースでは多数の Route 53 ルールが必要になる場合がありますが、ベースラインとして以下のルールを設定する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html)詳細については、*Route 53 開発者ガイド*の「[転送ルールの管理](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html)」 を参照してください。 | AWS 管理者 | | Route 53 プロファイルの設定 | Route 53 プロファイルは、スポークアカウントとルールを共有するために使用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html) | AWS 管理者 | ### オンプレミスの Active Directory DNS を設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 委任を作成します。 | Microsoft DNS スナップイン (`dnsmgmt.msc`) を使用して、Active Directory の名前空間の `company.com` に対して、新しい委任を作成します。委任されたドメインの名前は `aws` であるはずです。これにより、委任 `aws.company.com` の完全に指定されたドメイン名 (FQDN) が作成されます。ネームサーバーの IP 値には AWS Managed Microsoft AD ドメインコントローラーの IP アドレスを使用し、名前`server.aws.company.com`には を使用します。(この委任は冗長性の確保のみを目的としています。これは、この名前空間に対して、委任よりも優先される条件付きフォワーダーが作成されるためです。) | Active Directory | | 条件付きフォワーダーの作成 | Microsoft DNS スナップイン (`dnsmgmt.msc`) を使用して、`aws.company.com` の新しい条件付きフォワーダーを作成します。 条件付きフォワーダーのターゲット AWS アカウント に対して、中央 DNS の AWS インバウンド Route 53 リゾルバーの IP アドレスを使用します。   | Active Directory | ### スポーク用の Route 53 プライベートホストゾーンを作成する AWS アカウント | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Route 53 プライベートホストゾーンを作成します。 | Route 53 プライベートホストゾーンを各スポークアカウントで作成します。このプライベートホストゾーンをスポークアカウント VPC に関連付けます。詳細な手順については*、Route 53 開発者ガイド*の「[プライベートホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)」 を参照してください。 | AWS 管理者 | | 許可の作成 | を使用して AWS CLI 、中央 AWS ネットワークアカウント VPC の認可を作成します。各スポークの AWS アカウントのコンテキストから、次のコマンドを実行します。
aws route53 create-vpc-association-authorization --hosted-zone-id  \
   --vpc VPCRegion=,VPCId=
各パラメータの意味は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html) | AWS 管理者 | | 関連付けの作成 | を使用して、中央 AWS ネットワークアカウント VPC の Route 53 プライベートホストゾーンの関連付けを作成します AWS CLI。中央 AWS ネットワークアカウントのコンテキストから次のコマンドを実行します。
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id  \
   --vpc VPCRegion=,VPCId=
各パラメータの意味は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.html) | AWS 管理者 | ## 関連リソース + [Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を簡素化](https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/)する (AWS ブログ記事) + [の作成 AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) (AWS Directory Service ドキュメント) + [AWS Managed Microsoft AD ディレクトリの共有](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step2_share_directory.html) (AWS Directory Service ドキュメント) + [とは Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) (Amazon Route 53 ドキュメント) + [Creating a private hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html) (Amazon Route 53 ドキュメント) + [What are Amazon Route 53 Profiles?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (Amazon Route 53 ドキュメント) # Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化 *Amazon Web Services、Anand Krishna Varanasi、JAGDISH KOMAKULA、Ashish Kumar、Jimmy Morgan、Sarat Chandra Pothula、Vivek Thangamuthu、Balaji Vedagiri* ## 概要 オブザーバビリティは、アプリケーションのモニタリング、理解、トラブルシューティングに不可欠です。 AWS Control Tower またはランディングゾーンの実装と同様に、複数のアカウントにまたがるアプリケーションは、多数のログとトレースデータを生成します。問題の迅速なトラブルシューティングを行ったり、ユーザー分析やビジネス分析を理解したりするには、すべてのアカウントにまたがる共通のオブザーバビリティプラットフォームが必要です。Amazon CloudWatch オブザーバビリティアクセスマネージャーは、複数のアカウントログに一元的にアクセスし制御できます。 オブザーバビリティアクセスマネージャーを使用して、ソースアカウントによって生成されたオブザーバビリティデータログを表示および管理できます。ソースアカウントは AWS アカウント 、リソースのオブザーバビリティデータを生成する個々のアカウントです。オブザーバビリティデータは、ソースアカウントとモニタリングアカウントの間で共有されます。共有されるオブザーバビリティデータには、Amazon CloudWatch のメトリクス、Amazon CloudWatch Logs、 AWS X-Rayのトレースを含めることができます。詳細については、「[オブザーバビリティアクセスマネージャー 文書](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html)」を参照してください。 このパターンは、複数の で実行され AWS アカウント 、ログを表示するために共通の場所を必要とするアプリケーションまたはインフラストラクチャを持つユーザーを対象としています。これらのアプリケーションやインフラストラクチャの状態や状態を監視するために、Terraform を使用して オブザーバビリティアクセスマネージャーをセットアップする方法を説明します。このソリューションは、複数の方法でインストールできます。 + 手動で設定したスタンドアロンの Terraform モジュールとして + 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用 + [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) などの他のソリューションと統合 「[エピック](#centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager-epics)」セクションの手順では、手動による実装についても説明しています。AFT のインストール手順については、GitHub [オブザーバビリティアクセスマネージャー](https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform)リポジトリの README ファイルを参照してください。 ## 前提条件と制限 **前提条件** + [Terraform](https://www.terraform.io/) は、システムまたは自動パイプラインにインストールまたは参照されています ([最新バージョン](https://releases.hashicorp.com/terraform/)の使用をお勧めします)。 + 中央監視アカウントとして使用できるアカウント。他のアカウントは、ログを表示するために、中央監視アカウントへのリンクを作成します。 + (オプション) GitHub、 AWS CodeCommit Atlassian Bitbucket、または同様のシステムなどのソースコードリポジトリ。自動化された CI/CD パイプラインを使用する場合、ソースコードリポジトリは必要ありません。 + (オプション) GitHub でコードレビューとコードコラボレーションのためのプルリクエスト (PR) を作成する権限。 **制限事項** オブザーバビリティアクセスマネージャーには、以下のサービスクォータがあります。これらのクォータは変更できません。この特徴量を導入する前に、これらのクォータを検討します。詳細については、「CloudWatch ドキュメント」の「[CloudWatch Service Quotas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html)」を参照してください。 + **ソースアカウントリンク**: 各ソースアカウントを最大 5 つの監視アカウントにリンクできます。 + **シンク**: アカウントに対して複数のシンクを構築できますが、 あたり 1 つのシンクのみが許可され AWS リージョン ます。 加えて: + シンクとリンクは同じ で作成する必要があります AWS リージョン。クロスリージョンにすることはできません。 **クロスリージョンとクロスアカウントのモニタリング** クロスリージョンとクロスアカウントモニタリングでは、次のいずれかのオプションを選択できます。 + アラームとメトリクスを使用するための、[クロスアカウントおよびクロスリージョン CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)を作成します。このオプションでは、ログとトレースはサポートされません。 + Amazon OpenSearch Service を使用して、[一元的なログ記録](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)を実装します。 + すべてのテナントアカウントから、リージョンごとに 1 つのシンクを作成します。一元化されたモニタリングアカウントにメトリクスをプッシュし (このパターンで説明)、[CloudWatch メトリクスストリーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html)を使用して、共通の外部宛先またはサードパーティーのモニタリング製品 (Datadog、Dynatrace、Sumo Logic、Splunk、New Relic など) にデータを送信します。 ## アーキテクチャ **コンポーネント** CloudWatch オブザーバビリティアクセスマネージャーは、クロスアカウントオブザーバビリティを可能にする、次の 2 つの主要コンポーネントで構成されています。 + *シンク*は、ソースアカウントがオブザーバビリティデータを中央モニタリングアカウントに送信できるようにします。シンクは基本的に、ソースアカウントが接続するためのゲートウェイジャンクションを提供します。シンクゲートウェイまたは接続は 1 つしかありませんが、複数のアカウントが接続できます。 + 各ソースアカウントには、シンクゲートウェイジャンクションへの*リンク*があり、オブザーバビリティデータはこのリンクを介して送信されます。各ソースアカウントからリンクを作成する前に、シンクを作成する必要があります。 **アーキテクチャ** 次の図表は、オブザーバビリティアクセスマネージャーとそのコンポーネントの説明です。 ![\[シンクとリンクを使用したクロスアカウントオブザーバビリティのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/00603763-4f99-456e-85e7-a80d803b087d/images/5188caf9-348b-4d91-b560-2b3d6ea81191.png) ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 **ツール** + 「[Terraform](https://www.terraform.io/)」は、HashiCorpのinfrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。オプションで AFT を使用して、複数のアカウントにまたがるオブザーバビリティアクセスマネージャーを大規模にセットアップできます。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[オブザーバビリティアクセス マネージャー](https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform)」リポジトリで利用できます。 ## ベストプラクティス + AWS Control Tower 環境では、ログ記録アカウントを中央モニタリングアカウント (シンク) としてマークします。 + に複数のアカウントを持つ複数の組織がある場合は AWS Organizations、個々のアカウントではなく組織を設定ポリシーに含めることをお勧めします。アカウントの数が少ない場合や、アカウントがシンク設定ポリシーの組織に含まれていない場合は、代わりに個別のアカウントを含めることを決定できます。 ## エピック ### シンクモジュールをセットアップします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | GitHub オブザーバビリティアクセスマネージャーのリポジトリをクローニングします：
git clone https://github.com/aws-samples/cloudwatch-obervability-access-manager-terraform
| AWS DevOps、クラウド管理者、AWS 管理者 | | シンクモジュールのプロパティ値を指定します。 | `main.tf` ファイル (リポジトリの `deployments/aft-account-customizations/LOGGING/terraform/`** **フォルダー内)で、以下のプロパティの値を指定します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、 CloudFormation ドキュメントの[AWS::Oam::Sink](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-oam-sink.html)」を参照してください。 | AWS DevOps、クラウド管理者、AWS 管理者 | | シンクモジュールをインストールします。 | モニタリングアカウントとして AWS アカウント 選択した の認証情報をエクスポートし、オブザーバビリティアクセスマネージャーシンクモジュールをインストールします。
Terraform Init
Terrafom Plan
Terraform Apply
| AWS DevOps、クラウド管理者、AWS 管理者 | ### リンクモジュールをセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リンクモジュールのプロパティ値を指定します。 | `main.tf ` ファイル (リポジトリの `deployments/aft-account-customizations/LOGGING/terraform/`** **フォルダー内) で、以下のプロパティの値を指定します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、 CloudFormation ドキュメントの[AWS::Oam::Link](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-oam-link.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | | 個々のアカウントにリンクモジュールをインストールします。 | 個々のアカウントの認証情報をエクスポートし、オブザーバビリティアクセスマネージャーリンクモジュールをインストールします
Terraform Plan
Terraform Apply
リンクモジュールはアカウントごとに個別に設定することも、[AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) を使用してこのモジュールを多数のアカウントに自動的にインストールすることもできます。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### シンクからリンクへの接続を承認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ステータスメッセージ。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)右側に、緑色のチェックマークが付いた**「監視アカウントの有効化」**というステータスメッセージが表示されます。つまり、モニタリングアカウントには、他のアカウントのリンクが接続されるオブザーバビリティアクセスマネージャーシンクがあることを意味します。 | | | リンクとシンク間の接続を承認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)詳細については、CloudWatch ドキュメントの「[モニタリングアカウントをソースアカウントにリンクする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### クロスアカウントオブザーバビリティデータを検証 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クロスアカウントデータを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html) | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### (オプション) ソースアカウントがモニタリングアカウントを信頼できるようにする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 他のアカウントのメトリクス、ダッシュボード、ログ、ウィジェット、アラームを表示します。 | 追加の特徴量として、** ** CloudWatch メトリクス、ダッシュボード、ログ、ウィジェット、アラームを他のアカウントと共有できます。各アカウントは、**CloudWatch-CrossAccountSharingRole** と呼ばれる IAM ロールを使用して、このデータにアクセスします。中央モニタリングアカウントと信頼関係にあるソースアカウントは、このロールを引き受け、モニタリングアカウントのデータを表示できます。CloudWatch には、ロールを作成するためのサンプル CloudFormation スクリプトが用意されています。［**IAM でロールを管理する**］を選択し、データを表示したいアカウントでこのスクリプトを実行します。
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root",
                    "arn:aws:iam::XXXXXXXXX:root"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
詳細については、CloudWatch ドキュメントの「[CloudWatch でのクロスアカウントクロスリージョン機能の有効化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html#enable-cross-account-cross-Region)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ### (オプション) モニタリングアカウントから、クロスアカウント/クロスリージョンを表示 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クロスアカウント、クロスリージョンアクセスを設定します。 | 中央監視アカウントでは、オプションでアカウントセレクターを追加して、認証なしで簡単にアカウントを切り替えたり、そのデータを表示したりできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.html)ステップや情報については、CloudWatch ユーザーガイドの「[クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)」を参照してください。 | AWS DevOps、クラウド管理者、クラウドアーキテクト | ## 関連リソース + 「[CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)」 (Amazon CloudWatch ドキュメント) + 「[Amazon CloudWatch オブザーバビリティアクセスマネージャー API リファレンス」](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html) (Amazon CloudWatch ドキュメント) + 「[リソース:aws\$1oam\$1sink](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/oam_sink)」 (テラフォームドキュメント) + 「[データソース: aws\$1oam\$1link](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/oam_link)」 (テラフォームドキュメンテーション) + [CloudWatchObservabilityAccessManager](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/oam.html) (AWS Boto3 ドキュメント) # 起動時に EC2 インスタンスに必須タグが欠けていないか確認する *Amazon Web Services、Susanne Kangnoh、Archit Mathur* ## 概要 Amazon Elastic Compute Cloud (Amazon EC2) は、Amazon Web Services (AWS) クラウドでスケーラブルなコンピューティングキャパシティーを提供します。Amazon EC2 の使用により、ハードウェアに事前投資する必要がなくなり、アプリケーションをより速く開発およびデプロイできます。 タグを使用して、さまざまな方法で AWS リソースを分類できます。EC2 インスタンスのタグ付けは、アカウントに多数のリソースがあり、タグに基づいて特定のリソースをすばやく識別する場合に役立ちます。タグを使用すると、EC2 インスタンスにカスタムメタデータを割り当てることができます。各タグは、ユーザー定義のキーと値で構成されます。組織の要件に適合する一連の一貫したタグを作成することをお勧めします。  このパターンは、EC2 インスタンスで特定のタグをモニタリングするのに役立つ AWS CloudFormation テンプレートを提供します。このテンプレートは、AWS CloudTrail の **TagResource** イベントまたは **UntagResource** イベントを監視する Amazon CloudWatch Events イベントを作成して、新しい EC2 インスタンスのタグ付けまたはタグの削除を検出します。定義済みのタグが欠けている場合、AWS Lambda 関数を呼び出し、Amazon Simple Notification Service (Amazon SNS) を使用して指定のメールアドレスに違反メッセージを送信します。  ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + 提供される Lambda コードをアップロードする Amazon Simple Storage Service (Amazon S3) バケット。 + 違反の通知を受信する E メールアドレス **制限事項** + このソリューションは、CloudTrail **TagResource** イベントまたは **UntagResource** イベントをサポートします。他のイベントの通知は作成されません。 + このソリューションはタグキーのみをチェックします。キー値はモニタリングしません。 ## アーキテクチャ **ワークフロー****アーキテクチャ** ![\[Workflow diagram showing AWS のサービス interaction for EC2 instance monitoring and notification.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9cd74141-a87f-419e-94b3-0b28fd04a018/images/b48fd21b-a86b-4ec7-b9f6-4f1a64999437.png) **自動化とスケール** + AWS CloudFormation テンプレートは、さまざまな AWS リージョンとアカウントに複数回使用できます。各リージョンまたはアカウントで、テンプレートを 1 回実行するだけで済みます。 ## ツール ** サービス** + [Amazon EC2](https://aws.amazon.com/ec2/) – Amazon Elastic Compute Cloud (Amazon EC2) は、クラウド内で安全で再サイズを変更できるコンピューティング性能を提供するウェブサービスです。ウェブスケールのクラウドコンピューティングを開発者が簡単に利用できるように設計されています。 + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) - CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、および運用とリスクの監査に役立つ AWS のサービスです。ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。  + [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – Amazon CloudWatch Events は、AWS リソースの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。CloudWatch Events は、運用上の変更が生じると同時にそれらを認識し、環境に応答するためのメッセージを送信する、機能をアクティブ化する、変更を行う、および状態情報を収集することによって、必要に即した是正措置を講じます。  + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) – Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。  + 「[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)は、アプリケーション、エンドユーザー、およびデバイスでクラウドから通知を瞬時に送受信できるようにするウェブサービスです。 **コード** このパターンでは、次の 2 つのファイルを含む添付ファイルを使用します。 + `index.zip`は、このパターンの Lambda コードを含む圧縮ファイルです。 + `ec2-require-tags.yaml` は、Lambda コードをデプロイする CloudFormation テンプレートです。 これらのファイルの使用方法については、「*エピック*」セクションを参照してください。 ## エピック ### Lambda コードをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットにコードをアップロードします。 | 新しい S3 バケットを作成するか、既存の S3 バケットを使用して、添付 `index.zip` ファイル (Lambda コード) をアップロードします。このバケットは、モニタリング対象のリソース (EC2 インスタンス) と同じ AWS リージョンに存在する必要があります。 | クラウドアーキテクト | | CloudFormation テンプレートをデプロイする。 | S3 バケットと同じ AWS リージョンで Cloudformation コンソールを開き、添付ファイルで提供されている `ec2-require-tags.yaml` ファイルをデプロイします。次のエピックでは、テンプレートパラメータの値を指定します。  | クラウドアーキテクト | ### CloudFormation テンプレートのパラメータを入力します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケット名を入力します。 | 最初のエピックで作成または選択した S3 バケットの名前を入力します。この S3 バケットには Lambda コードの .zip ファイルが含まれており、CloudFormation のテンプレートおよびモニタリング対象のリソースと同じ AWS リージョンに存在する必要があります。 | クラウドアーキテクト | | S3 キーを入力します。 | S3 バケット内の Lambda コードの.zip ファイルの場所を、先頭にスラッシュを付けずに指定します (例えば、`index.zip`、`controls/index.zip`)。 | クラウドアーキテクト | | メールアドレスを入力します。 | 違反の通知を受信するメールアドレスを入力します。 | クラウドアーキテクト | | ロギングレベルを定義する。 | ロギングレベルと冗長性を指定します。`Info` はアプリケーションの進行状況に関する詳細な情報メッセージを指定するもので、デバッグにのみ使用してください。`Error` は、アプリケーションの実行を継続できるエラーイベントを指定します。`Warning` は潜在的に有害な状況を示します。 | クラウドアーキテクト | | 必要なタグキーを入力します。 | 確認するタグキーを入力します。複数のキーを指定する場合は、スペースを入れずにカンマで区切ります。(たとえば、`ApplicationId,CreatedBy,Environment,Organization` は 4 つのキーを検索します)。CloudWatch Events イベントはこれらのタグキーを検索し、見つからない場合は通知を送信します。 | クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メールサブスクリプションを確認します。 | CloudFormation テンプレートが正常にデプロイされると、指定した E メールアドレスにサブスクリプション E メールメッセージが送信されます。通知を受信するには、この E メールのサブスクリプションを確認する必要があります。  | クラウドアーキテクト | ## 関連リソース + 「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)」 (Amazon S3 ドキュメント) + 「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/upload-objects.html)」 (Amazon S3 ドキュメント) + 「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」(Amazon EC2 ドキュメント) + [AWS CloudTrail を使用して API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) (Amazon CloudWatchドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/9cd74141-a87f-419e-94b3-0b28fd04a018/attachments/attachment.zip)」 # ステートファイルが失われた後、 AWS Account Factory for Terraform (AFT) リソースを安全にクリーンアップする *Gokendra Malviya (Amazon Web Services)* ## 概要 AWS Account Factory for Terraform (AFT) を使用して AWS Control Tower 環境を管理すると、AFT は Terraform 状態ファイルを生成して、Terraform によって作成されたリソースの状態と設定を追跡します。Terraform ステートファイルが失われると、リソース管理とクリーンアップに大きな課題が生じる可能性があります。このパターンは、 AWS Control Tower 環境の整合性を維持しながら、AFT 関連のリソースを安全に識別および削除する体系的なアプローチを提供します。 このプロセスは、元のステートファイルへの参照がない場合でも、すべての AFT コンポーネントを適切に削除できるように設計されています。このプロセスは、 AWS Control Tower オペレーションの中断を最小限に抑えるために、環境で AFT を正常に再確立および再設定するための明確な道筋を提供します。 AFT の詳細については、[AWS Control Tower のドキュメント](https://docs.aws.amazon.com/controltower/latest/userguide/taf-account-provisioning.html)を参照してください。 ## 前提条件と制限 **前提条件** + [AFT アーキテクチャ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-architecture.html)についての十分な理解。 + 次のアカウントへの管理者アクセス: + AFT 管理アカウント + AWS Control Tower 管理アカウント + ログアーカイブアカウント + 監査アカウント + AFT 関連リソースの削除をブロックする制約や制限がサービスコントロールポリシー (SCP) に含まれていないことを確認します。 **制限事項** + このプロセスではリソースを効果的にクリーンアップできますが、失われたステートファイルを復元することはできません。また、一部のリソースは手動で識別しなければならない場合があります。 + クリーンアッププロセスの所要時間は、環境の複雑さによって異なり、数時間かかる場合もあります。 + このパターンは AFT バージョン 1.12.2 でテストされており、次のリソースを削除します。別のバージョンの AFT を使用している場合は、追加リソースの削除が必要になる場合があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) **重要** このパターンの各ステップで削除されたリソースは復元できません。これらのステップを実行する前に、リソース名を慎重に確認し、それらが AFT によって作成されていることを確認してください。 ## アーキテクチャ 次の図は、AFT の各コンポーネントと高レベルのワークフローを示します。AFT は、 AWS Control Towerでアカウントのプロビジョニングとカスタマイズを支援する Terraform パイプラインを設定します。AFT は GitOps モデルに従って、アカウントプロビジョニングのプロセスを自動化します AWS Control Tower。ここで、ユーザーはアカウントリクエストの Terraform ファイルを作成し、リポジトリにコミットします。このファイルは、アカウントプロビジョニングの AFT ワークフローをトリガーするための入力となります。アカウントプロビジョニングが完了すると、AFT は追加のカスタマイズ手順を自動的に実行できます。 ![\[AFT コンポーネントと高レベルのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1342c0a6-4b07-46df-a063-ceab2e2f83c8/images/3e0cae87-20ef-4fcc-aacf-bb450844ac56.png) このアーキテクチャの詳細は以下のとおりです。 + **AWS Control Tower 管理アカウント**は AWS アカウント 、 AWS Control Tower サービス専用の です。これは通常、*AWS 支払者アカウント*または *AWS Organizations 管理アカウント*とも呼ばれます。 + **AFT 管理アカウント**は AWS アカウント 、AFT 管理オペレーション専用の です。これは、組織の管理アカウントとは異なります。 + **販売済みアカウント**は、選択したすべてのベースラインコンポーネントとコントロール AWS アカウント を含む です。AFT は AWS Control Tower を使用して新しいアカウントを提供します。 このアーキテクチャの詳細については、 AWS Control Tower ワークショップの[「AFT の概要](https://catalog.workshops.aws/control-tower/en-US/customization/aft)」を参照してください。 ## ツール **AWS のサービス** + [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、規範的なベストプラクティスに従って、 AWS マルチアカウント環境のセットアップと管理に役立ちます。 + [AWS Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/taf-account-provisioning.html) は、アカウントとリソースのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、 AWS リソースの拡大とスケーリングに合わせて環境を一元的に管理および管理するのに役立ちます。Organizations を使用すると、アカウントの作成、リソースの割り当て、ワークロードを整理するためのアカウントのグループ化、ガバナンスポリシーの適用、すべてのアカウントに単一の支払い方法を使用した請求の簡素化が可能になります。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。このパターンには、IAM ロールとアクセス許可が必要です。 **その他のツール** + [Terraform](https://www.terraform.io/) は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 ## ベストプラクティス + については AWS Control Tower、 AWS Control Tower ドキュメントの[AWS Control Tower 「管理者向けのベストプラクティス](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html)」を参照してください。 + IAM については、IAM ドキュメントの「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### AFT 管理アカウントで AFT リソースを削除する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AFT タグで識別されるリソースを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | IAM ロールを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | AWS Backup バックアップボールトを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | Amazon CloudWatch リソースの削除 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | AWS KMS リソースを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | ### ログアーカイブアカウントで AFT リソースを削除する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | IAM ロールを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | ### 監査アカウントで AFT リソースを削除する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | ### AWS Control Tower 管理アカウントで AFT リソースを削除する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | | EventBridge ルールを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | AWS 管理者、AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | インターネットゲートウェイのデタッチに失敗した | **AFT** タグで識別されるリソースを削除しようとして、インターネットゲートウェイをデタッチまたは削除するときにこの問題が発生した場合は、まず VPC エンドポイントを削除する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | | 指定した CloudWatch クエリが見つからない | AFT によって作成された CloudWatch クエリが見つからない場合は、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/clean-up-aft-resources-safely-after-state-file-loss.html) | ## 関連リソース + AFT + [GitHub リポジトリ](https://github.com/aws-ia/terraform-aws-control_tower_account_factory) + [ワークショップ](https://catalog.workshops.aws/control-tower/en-US/customization/aft) + [ドキュメント](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html) + [AWS Control Tower ドキュメント](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) ## 追加情報 CloudWatch のログのインサイトダッシュボードで AFT クエリを表示するには、次のスクリーンショットに示すように、画面右上隅の **[保存済みクエリとサンプルクエリ]** アイコンを選択します。 ![\[CloudWatch のログのインサイトダッシュボードでの AFT クエリへのアクセス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1342c0a6-4b07-46df-a063-ceab2e2f83c8/images/255d4032-738b-4600-9084-9684d2e9a328.png) # AWS CodePipeline に適用されない AWS リージョンにパイプラインを作成 *Amazon Web Services、Anand Krishna Varanasi* ## 概要 **注意**: AWS CodeCommit は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/) AWS CodePipeline は、Amazon Web Services (AWS) の一連の DevOps ツールの一部である継続的デリバリー (CD) オーケストレーションサービスです。さまざまなソース (バージョン管理システムやストレージソリューションなど)、AWS や AWS パートナーの継続的インテグレーション (CI) 製品およびサービス、オープンソース製品と統合して、アプリケーションとインフラストラクチャを迅速にデプロイするためのエンドツーエンドのワークフローサービスを提供します。 ただし、CodePipeline はすべての AWS リージョンに適用されなく、AWS CI/CD サービスを接続する目に見えないオーケストレーターがあると便利です。このパターンでは、CodePipeline がまだ適用されない AWS リージョンで AWS CodeCommit、AWS CodeBuild、AWS CodeDeploy などの AWS CI/CD サービスを使用してエンドツーエンドのワークフローパイプラインを実装する方法を示しています。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + AWS Cloud Development Kit (AWS CDK) CLI バージョン 2.28 以降 ## アーキテクチャ **ターゲットテクノロジースタック** 次の図表では、アフリカ (ケープタウン) リージョンなど、CodePipeline が適用されないリージョンで作成されたパイプラインを示しています。開発者は CodeDeploy 設定ファイル (*デプロイライフサイクルフックスクリプト*)とも呼ばれる) を CodeCommit がホストする Git リポジトリにプッシュします。(このパターンで提供されている [GitHub リポジトリ](https://github.com/aws-samples/invisible-codepipeline-unsupported-regions) を参照してください。) Amazon EventBridge ルールは、CodeBuild を自動で開始します。 CodeDeploy 設定ファイルは、パイプラインのソースステージの一部として CodeCommit から取得され、CodeBuild に転送されます。  次のフェーズで、CodeBuild は次のタスクを実行します。  1. アプリケーションのソースコードの TAR ファイルをダウンロードします。AWS Systems Manager のキャパシティとしての パラメータストアを使用して、このファイルの名前を設定できます。 1. CodeDeploy 設定ファイルをダウンロードします。 1. アプリケーションソースコードと、アプリケーションタイプに固有の CodeDeploy 設定ファイルを組み合わせたアーカイブを作成します。 1. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに対する CodeDeploy デプロイをセットアップします。 ![\[適用されない AWS リージョンでのパイプライン作成\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e27750de-b597-424e-b5bf-4d58dc9b60cc/images/95fc815e-a762-4142-b0fd-2a716823e498.png) ## ツール **AWS サービス** + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon EC2 またはオンプレミスインスタンス、AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) に対するデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 **コード** このパターンのコードは、GitHub 内の「[CodePipeline 適用されないリージョン](https://github.com/aws-samples/invisible-codepipeline-unsupported-regions)」リポジトリで利用できます。 ## エピック ### 開発者ワークステーションをセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CLI のインストール。 | 手順については、[AWS CDKのドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_prerequisites)を参照してください。 | AWS DevOps | | SQL クライアントをインストールします。 | ローカルコンピュータにインストールされた Git クライアントを使用してコミットを作成してから、それらのコミットを CodeCommit リポジトリにプッシュできます。Git クライアントで CodeCommit をセットアップするには、[CodeCommit のドキュメント](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-commit.html) を参照してください。 | AWS DevOps | | npm をインストールします。 | **npm ** のパッケージマネージャーをインストールします。詳細については、[npmドキュメント](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)を参照してください。 | AWS DevOps | ### パイプラインのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | 以下のコマンドを実行して、GitHub [CodePipeline 適用されないリージョン](https://github.com/aws-samples/invisible-codepipeline-unsupported-regions) のリポジトリをローカルマシンにクローンします。
git clone https://github.com/aws-samples/invisible-codepipeline-unsupported-regions
| DevOps エンジニア | | cdk.json にパラメーターを設定します。 | `cdk.json` セクションで、次のパラメーターの値を指定します。
"pipeline_account":"XXXXXXXXXXXX",
"pipeline_region":"us-west-2",
"repo_name": "app-dev-repo",
"ec2_tag_key": "test-vm",
"configName" : "cbdeployconfig",
"deploymentGroupName": "cbdeploygroup",
"applicationName" : "cbdeployapplication",
"projectName" : "CodeBuildProject"
各パラメータの意味は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-pipeline-in-aws-regions-that-don-t-support-aws-codepipeline.html) | AWS DevOps | | AWS CDK コンストラクトライブラリをセットアップします。 | 複製された GitHub リポジトリで、次のコマンドを使用して AWS CDK 構築ライブラリをインストールし、アプリケーションをビルドし、合成してアプリケーションの AWS CloudFormation テンプレートを生成します。
npm i aws-cdk-lib
npm run build
cdk synth
| AWS DevOps | | サンプルアプリケーションをデプロイするには | 適用されないリージョン (`af-south-1` など)で次のコマンドを実行してコードをデプロイします。
cdk deploy
| AWS DevOps | ### CodeDeploy の CodeCommit リポジトリをセットアップします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションの CI/CD をセットアップします。 | `cdk.json` ファイルに指定された CodeCommit リポジトリを複製して (デフォルトで `app-dev-repo` と呼ばれ)、アプリケーションの CI/CD パイプラインを設定します。
git clone https://git-codecommit.us-west-2.amazonaws.com/v1/repos/app-dev-repo
リポジトリ名とリージョンは、`cdk.json` ファイルに入力した値によって異なります。 | AWS DevOps | ### パイプラインを削除します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイインストラクションを使用してパイプラインをテストします。 | GitHub [CodePipelineサポートされていないリージョン](https://github.com/aws-samples/invisible-codepipeline-unsupported-regions) リポジトリの `CodeDeploy_Files` フォルダには、CodeDeploy にアプリケーションをデプロイするように指示するサンプルファイルが含まれています。`appspec.yml` ファイルは、アプリケーションデプロイのフローを制御するフックを含む CodeDeploy 設定ファイルです。サンプルファイル `index.html`、`start_server.sh`、`stop_server.sh`、及び `install_dependencies.sh` を使用して、Apache でホストされているウェブサイトを更新します。これらは例です。GitHub リポジトリのコードを使用して、あらゆるタイプのアプリケーションをデプロイします。ファイルが CodeCommit リポジトリにプッシュされる場合、非表示のパイプラインが自動的に開始されます。デプロイ結果については、CodeBuild コンソールと CodeDeploy コンソールの個々のフェーズの結果を確認します。 | AWS DevOps | ## 関連リソース + [開始方法](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_prerequisites) (AWS CDK ドキュメント) + [Cloud Development Kit (CDK) の紹介](https://catalog.us-east-1.prod.workshops.aws/workshops/5962a836-b214-4fbf-9462-fedba7edcc9b/en-US) (AWS Workshop Studio) + [AWS CDK ワークショップ](https://cdkworkshop.com/) # AWS CDK アスペクトとエスケープハッチを使用してデフォルトのロール名をカスタマイズする *Amazon Web Services、SANDEEP SINGH、James Jacob* ## 概要 このパターンは、 AWS Cloud Development Kit (AWS CDK) コンストラクトによって作成されるロールのデフォルト名をカスタマイズする方法を示しています。組織の命名規則に基づいて特定の制約がある場合、多くの場面でロール名のカスタマイズが必要になります。たとえば、組織では、ロール名に特定のプレフィックスを必要とする AWS Identity and Access Management (IAM) アクセス[許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)または[サービスコントロールポリシー (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を設定できます。このような場合、 AWS CDK コンストラクトによって生成されるデフォルトのロール名は、これらの規則を満たさない場合があり、変更する必要がある場合があります。このパターンは、 AWS CDKで[エスケープハッチ](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html)と[アスペクト](https://docs.aws.amazon.com/cdk/v2/guide/aspects.html)を使用して、これらの要件に対処します。エスケープハッチを使用してカスタムロール名を定義し、アスペクトを使用して、組織のポリシーと制約を確実に順守するために、すべてのロールにカスタム名を適用します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + [AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_prerequisites)で指定されている必須要件 **制限事項** + アスペクトはリソースタイプに基づいてリソースをフィルタリングするため、すべてのロールが同じ接頭語を共有します。ロールごとに異なる接頭語が必要な場合は、他のプロパティに基づく追加のフィルタリングが必要です。たとえば、 AWS Lambda 関数に関連付けられたロールに異なるプレフィックスを割り当てるには、特定のロール属性またはタグでフィルタリングし、Lambda 関連のロールには 1 つのプレフィックスを、他のロールには別のプレフィックスを適用できます。 + IAM ロール名の最大長は 64 文字であるため、この制限を満たすには、変更されたロール名を切り取る必要があります。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS CDK + AWS CloudFormation **ターゲット アーキテクチャ** ![\[エスケープハッチとアスペクトを使用して AWS CDK が割り当てたロール名をカスタマイズするためのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c149d8d2-1da6-4680-ab0b-e5051b69688c/images/15e56ca5-f150-4522-b374-8ee2dcc655a9.png) + AWS CDK アプリは 1 つ以上の CloudFormation スタックで構成され、 AWS リソースを管理するために合成およびデプロイされます。 + レイヤー 2 (L2) コンストラクトによって公開されていない AWS CDKマネージドリソースのプロパティを変更するには、エスケープハッチを使用して基盤となる CloudFormation プロパティ (この場合はロール名) を上書きし、 の側面を使用して AWS CDK スタック合成プロセス中に AWS CDK アプリケーション内のすべてのリソースにロールを適用します。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CDK コマンドラインインターフェイス (AWS CDK CLI)](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) ( AWS CDK ツールキットとも呼ばれます) は、 AWS CDK アプリの操作に役立つコマンドラインクラウド開発キットです。CLI `cdk` コマンドは、 AWS CDK アプリを操作するための主要なツールです。アプリケーションを実行し、定義したアプリケーションモデルを調査し、 AWS CDKによって生成された CloudFormation テンプレートを作成して展開します。 + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 **コードリポジトリ** このパターンのソースコードとテンプレートは GitHub 「[CDK-Aspects-Override](https://github.com/aws-samples/cdk-aspects-override)」リポジトリから入手可能です。 ## ベストプラクティス ** **AWS 規範ガイダンスウェブサイトの[TypeScript AWS CDK で を使用して IaC プロジェクトを作成するためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/introduction.html)」を参照してください。 ## エピック ### CLI AWS CDK のインストール | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CLI AWS CDK をインストールします。 | CLI AWS CDK をグローバルにインストールするには、 コマンドを実行します。
npm install -g aws-cdk
| AWS DevOps | | バージョンを確認します。 | コマンドを実行します。
cdk --version
CLI のバージョン 2 AWS CDK を使用していることを確認します。 | AWS DevOps | | AWS CDK 環境をブートストラップします。 | CloudFormation テンプレートをデプロイする前に、使用する アカウントと AWS リージョン を準備します。コマンドを実行します。
cdk bootstrap /
詳細については、 AWS ドキュメントの[AWS CDK 「ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。 | AWS DevOps | ### AWS CDK アプリをデプロイして側面の使用をデモンストレーションする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトを準備する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.html) | AWS DevOps | | AWS CDKによって指定されたデフォルトのロール名を使用してスタックを展開する。 | Lambda 関数とそれに関連するロールを含む 2 つの CloudFormation スタック (`ExampleStack1` および `ExampleStack2`) を展開します。
npm run deploy:ExampleAppWithoutAspects
コードはロールプロパティを明示的に渡さないため、ロール名は AWS CDKによって作成されます。出力の事例については、「[追加情報](#customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches-additional)」セクションを参照してください。 | AWS DevOps | | アスペクトでスタックを展開する。 | このステップでは、 AWS CDK プロジェクトにデプロイされているすべての IAM ロールにプレフィックスを追加して、ロール名の規則を適用する側面を適用します。アスペクトは、`lib/aspects.ts` ファイルに定義されています。このアスペクトは、エスケープハッチを使用して、接頭語を追加してロール名をオーバーライドします。アスペクトは、`bin/app-with-aspects.ts` ファイル内のスタックに適用されます。この例では、ロール名の接頭語は `dev-unicorn` です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.html)出力の事例については、「[追加情報](#customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches-additional)」セクションを参照してください。 | AWS DevOps | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックを削除します。 | このパターンの使用が完了したら、次のコマンドを実行してリソースを削除し、追加コストが発生しないようにします。
cdk destroy --all -f && cdk --app npx ts-node bin/app-with-aspects.ts' destroy --all -f
| AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | を使用して問題が発生する AWS CDK。 | AWS CDK ドキュメントの「一般的な[AWS CDK 問題のトラブルシューティング](https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html)」を参照してください。 | ## 関連リソース + [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) + [AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/) + [AWS CDK GitHub の](https://github.com/aws/aws-cdk) + 「[エスケープハッチ](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html)」 + [側面と AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/aspects.html) ## 追加情報 **側面 CloudFormation なしで によって作成されたロール名** ``` Outputs: ExampleStack1WithoutAspects.Function1RoleName = example-stack1-without-as-Function1LambdaFunctionSe-y7FYTY6FXJXA ExampleStack1WithoutAspects.Function2RoleName = example-stack1-without-as-Function2LambdaFunctionSe-dDZV4rkWqWnI ... Outputs: ExampleStack2WithoutAspects.Function3RoleName = example-stack2-without-as-Function3LambdaFunctionSe-ygMv49iTyMq0 ``` **側面 CloudFormation を持つ によって作成されたロール名** ``` Outputs: ExampleStack1WithAspects.Function1RoleName = dev-unicorn-Function1LambdaFunctionServiceRole783660DC ExampleStack1WithAspects.Function2RoleName = dev-unicorn-Function2LambdaFunctionServiceRole2C391181 ... Outputs: ExampleStack2WithAspects.Function3RoleName = dev-unicorn-Function3LambdaFunctionServiceRole4CAA721C ``` # Amazon EC2 にプライベート静的 IP を使用して Cassandra クラスターをデプロイしてリバランスを回避する *Amazon Web Services、Dipin Jain* ## 概要 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのプライベート IP は、そのライフサイクルを通じて保持されます。ただし、プライベート IP は、Amazon マシンイメージ (AMI) のアップグレード中など、計画的または予期しないシステムクラッシュ時に変更される可能性があります。シナリオによっては、プライベートの静的 IP を保持することで、ワークロードのパフォーマンスと復旧時間を向上させることができます。たとえば、Apache Cassandra シードノードに静的 IP を使用すると、クラスターにリバランスのオーバーヘッドが発生するのを防ぐことができます。  Amazon EC2 インスタンスの Cassandra クラスターにセカンダリのelastic network interface をアタッチして、リホスト中に IP を静的に保つ方法。このパターンは Cassandra クラスターに焦点を当てていますが、この実装はプライベートの静的 IP の利点を活用するあらゆるアーキテクチャに使用できます。 ## 前提条件と制限事項 **前提条件** + Amazon Web Services (AWS) アカウント。 **製品バージョン** + DataStax バージョン 5.11.1 + オペレーティングシステム： (Ubuntu 18.04 LTS) ## アーキテクチャ **ソースアーキテクチャ** ソースは、オンプレミスの仮想マシン (VM) 上の Cassandra クラスターでも、AWS クラウドの EC2 インスタンスでもかまいません。このシナリオを以下に図表で示します。この例には、3 つのシードノードと 1 つの管理ノードの 4 つのクラスターノードが含まれています。ソースアーキテクチャでは、各ノードに 1 つのネットワークインターフェースが接続されています。 ![\[それぞれに単一のネットワークインターフェイスが取り付けられた 4 つの Amazon EC2 クラスターノード。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/47ca4dbc-0922-4e65-b66c-4db5122fc4ac/images/5d80cfc9-4b72-4c72-aefd-b77cc0fb58e3.png) **ターゲット アーキテクチャ** デスティネーションクラスターは、次の図に示すように、各ノードにセカンダリ elastic network interface がアタッチされた EC2 インスタンスでホストされます。 ![\[それぞれにセカンダリ Elastic ネットワークインターフェイスが取り付けられた 4 つの Amazon EC2 クラスターノード。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/47ca4dbc-0922-4e65-b66c-4db5122fc4ac/images/d1e22017-f041-426b-9204-31ac158a407d.png) **自動化とスケール** [AWS Knowledge Center のビデオ](https://www.youtube.com/watch?v=RmwGYXchb4E) で説明されているように、2 つ目のelastic network interface を EC2 Auto Scaling グループに自動的にアタッチすることもできます。 ## エピック ### Amazon EC2上のカサンドラクラスターを設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EC2 ノードを起動して Cassandra クラスターをホストします。 | [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/) で、AWS アカウントの Ubuntu ノード用に 4 つの EC2 インスタンスを起動します。Cassandraクラスターには3つの (シード) ノードが使用され、4番目のノードはDataStax Enterprise (DSE) OpsCenterをインストールするクラスター管理ノードとして機能します。手順については、[Amazon EC2 のドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance)を参照してください。 | クラウドエンジニア | | ノード通信を確認する。 | 4 つのノードがデータベースとクラスター管理ポートを介して相互に通信できることを確認します。 | ネットワークエンジニア | | DSE OpsCenterを管理ノードにインストールします。 | 管理ノードのDebianパッケージからDSE OpsCenter 6.1をインストールします。手順については、[DataStax のドキュメント](https://docs.datastax.com/en/opscenter/6.1/opsc/install/opscInstallDeb_t.html)を参照してください。 | DBA | | セカンダリネットワークインターフェイスを設定する | Cassandra は、そのノードの EC2 インスタンスの IP アドレスに基づいて、各ノードの汎用固有識別子 (UUID) を生成します。この UUID はリング上の仮想ノード (vnode) を配布するために使用されます。Cassandra を EC2 インスタンスにデプロイすると、インスタンスが作成されると自動的に IP アドレスが割り当てられます。 計画的または予期しない停止が発生した場合、新しい EC2 インスタンスの IP アドレスとデータ配信が変更され、リング全体のバランスを調整する必要があります。これは望ましくありません。割り当てられた IP アドレスを保持するには、固定 IP アドレスの [セカンダリ elastic network interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#scenarios-enis) を使用してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-cassandra-cluster-on-amazon-ec2-with-private-static-ips-to-avoid-rebalancing.html)ネットワークインターフェイスの作成に関する詳細については、[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#create_eni) を参照してください。 | クラウドエンジニア | | セカンダリネットワークインターフェースをクラスターノードにアタッチします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-cassandra-cluster-on-amazon-ec2-with-private-static-ips-to-avoid-rebalancing.html)ネットワークインターフェイスの作成に関する詳細については、[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#attach_eni) を参照してください。 | クラウドエンジニア | | Amazon EC2 にルートを追加して、非対称ルーティングに対処します。 | 2 つ目のネットワークインターフェースをアタッチすると、ネットワークは非対称ルーティングを実行する可能性が非常に高くなります。これを回避するには、新しいネットワークインターフェースにルートを追加します。非対称ルーティングの詳細な説明と修正方法については、[AWS ナレッジセンターのビデオ](https://www.youtube.com/watch?v=RmwGYXchb4E)、または[マルチホームサーバーでの非対称ルーティングの克服](http://www.linuxjournal.com/article/7291) (Patrick McManus による *Linux Journal* の記事、2004 年 4 月 5 日) を参照してください。 | ネットワークエンジニア | | セカンダリネットワークインターフェイス IP を指すように DNS エントリを更新します。 | ノードの完全修飾ドメイン名 (FQDN) をセカンダリネットワークインターフェイスの IP に設定します。 | ネットワークエンジニア | | DSE OpsCenterを使用してCassandraクラスターをインストールして構成します。 | クラスター・ノードにセカンダリ・ネットワーク・インターフェースが用意できたら、Cassandra クラスターをインストールして構成できます。 | DBA | ### ノード障害からクラスターを回復する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターシードノード用の AMI を作成します。 | ノードに障害が発生した場合にデータベースバイナリで復元できるように、ノードのバックアップを作成します。手順については、Amazon EC2 のドキュメントの[AMIの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami.html)を参照してください。 | バックアップ管理者 | | ノード障害から回復します。 | 障害が発生したノードを AMI から起動した新しい EC2 インスタンスと交換し、障害が発生したノードのセカンダリネットワークインターフェイスを接続します。 | バックアップ管理者 | | Cassandra クラスターが正常であることを確認します。 | 交換用ノードが起動したら、DSE OpsCenterでクラスターの状態を確認します。 | DBA | ## 関連リソース + [DebianパッケージからのDSE OpsCenter 6.1のインストール](https://docs.datastax.com/en/opscenter/6.1/opsc/install/opscInstallDeb_t.html) (DataStaxドキュメント) + [Ubuntu EC2 インスタンスでセカンダリネットワークインターフェイスを機能させる方法](https://www.youtube.com/watch?v=RmwGYXchb4E) (AWS ナレッジセンターの動画) + [Amazon EC2 で Apache カサンドラを実行するためのベストプラクティス](https://aws.amazon.com/blogs/big-data/best-practices-for-running-apache-cassandra-on-amazon-ec2/) (AWS ブログ記事) # AWS Transit Gateway Connect を使用して VRF を AWS に拡張する *Amazon Web Services、Adam Till、Yashar Araghi、Vikas Dewangan、Mohideen HajaMohideen* ## 概要 仮想ルーティングと転送 (VRF) は従来のネットワークの機能です。分離された論理ルーティングドメインをルートテーブル形式で使用して、同じ物理インフラストラクチャ内のネットワークトラフィックを分離します。オンプレミスネットワークを AWS に接続するときに VRF 分離をサポートするように AWS Transit Gateway を構成できます。このパターンでは、サンプルアーキテクチャを使用してオンプレミスの VRF をさまざまなトランジットゲートウェイルートテーブルに接続します。 このパターンは、AWS Direct Connect のトランジット仮想インターフェイス (VIF) と Transit Gateway の Connect アタッチメントを使用して VRF を拡張します。[トランジット VIF](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html) は、Direct Connect ゲートウェイに関連付けられた 1 つまたは複数の Amazon VPC トランジットゲートウェイにアクセスするために使用されます。[Transit Gateway Connect アタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html)は、Transit Gateway を VPC で実行しているサードパーティの仮想アプライアンスと接続します。Transit Gateway Connect アタッチメントは、総称ルーティングカプセル化 (GRE)トンネルプロトコルをサポートして高パフォーマンスを実現し、動的ルーティングのためにボーダーゲートウェイプロトコル (BGP) をサポートします。 このパターンで説明するアプローチには、以下の利点があります。 + Transit Gateway Connect を使用すると、Transit Gateway Connect ピアに最大1,000のルートをアドバタイズし、そこから最大5,000のルートを受信できます。Transit Gateway Connect なしで Direct Connect トランジット VIF 機能を使用すると、Transit Gateway あたり 20 プレフィックスに制限されます。 + 顧客が使用している IP アドレススキーマに関係なくトラフィックの分離を維持し、Transit Gateway Connect を使用して AWS でホストされたサービスを提供できます。 + VRF トラフィックはパブリック仮想インターフェイスを通過する必要はありません。これにより、多くの組織のコンプライアンス要件やセキュリティ要件を簡単に遵守できます。 + 各 GRE トンネルは最大 5 Gbps をサポートし、Transit Gateway の Connect アタッチメントごとに最大 4 つの GRE トンネルを設定できます。これは、最大 1.25 Gbps をサポートする AWS Site-to-Site VPN 接続など、他の多くの接続タイプよりも高速です。 ## 前提条件と制限 **前提条件** + 必要な AWS アカウントが作成されていること (詳細についてはアーキテクチャを参照してください) + アカウントごとに AWS Identity and Access Management (IAM) ロールを引き受ける権限。 + 各アカウントの IAM ロールには、AWS Transit Gateway と AWS Direct Connect リソースをプロビジョニングするためのアクセス権限が必要です。詳細については、「[トランジットゲートウェイの認証とアクセス制御](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-authentication-access-control.html)」および「[Direct Connect のアイデンティティとアクセス管理](https://docs.aws.amazon.com/directconnect/latest/UserGuide/security-iam.html)」を参照してください。 + Direct Connect の接続が正常に作成されている。詳細については、「[接続ウィザードを使用して接続を作成する](https://docs.aws.amazon.com/directconnect/latest/UserGuide/dedicated_connection.html#create-connection)」を参照してください。 **制限事項** + プロダクション、QA、開発アカウントの VPC への Transit Gateway アタッチメントには制限があります。詳細については、「[VPC への Transit Gateway アタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)」を参照してください。 + Direct Connect ゲートウェイの作成および使用には制限があります。詳細については、「[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html)」を参照してください。 ## アーキテクチャ **ターゲットアーキテクチャ** 以下のサンプルアーキテクチャは、Transit Gateway Connect アタッチメントを使用してトランジット VIF をデプロイするための再利用可能なソリューションを提供します。このアーキテクチャは、複数の Direct Connect ロケーションを使用することで耐障害性を実現します。詳細については、Direct Connect ドキュメントの「[最大限の耐障害性](https://docs.aws.amazon.com/directconnect/latest/UserGuide/maximum_resiliency.html)」を参照してください。オンプレミスネットワークにはプロダクション、QA、開発用の VRF があり、これらは AWS に拡張され、専用のルートテーブルを使用して分離されます。 ![\[AWS Direct Connect と AWS Transit Gateway リソースを使用して VRF を拡張するアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/db17e177-6c94-4d81-ab39-0923ecab2f1b/images/10be0625-8574-40eb-bc00-bb0a07d0dc26.png) AWS 環境では、*Direct Connect アカウント*と*ネットワークハブアカウント*の 2 つのアカウントが VRF の拡張専用です。Direct Connect アカウントには、各ルーターの接続とトランジット VIF が含まれています。トランジット VIF は Direct Connect アカウントから作成しますが、ネットワークハブアカウントにデプロイして、ネットワークハブアカウントの Direct Connect ゲートウェイに関連付けることができます。ネットワークハブアカウントは、Direct Connect ゲートウェイを所有しています。AWS リソースは次のように接続されます。 1. トランジット VIF は、Direct Connect ロケーションのルーターを、Direct Connect アカウントの AWS Direct Connect に接続します。 1. トランジット VIF は、Direct Connect をネットワークハブアカウントの Direct Connect ゲートウェイに接続します。 1. [トランジットゲートウェイアソシエーション](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html)は、Direct Connect ゲートウェイをネットワークハブアカウント内のトランジットゲートウェイに接続します。 1. [Transit Gateway Connect アタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html)は、Transit Gateway をプロダクション、QA、開発アカウントの VPC に接続します。 *トランジット VIF アーキテクチャ* 次の図は、トランジット VIF 構成の詳細を示しています。このサンプルアーキテクチャでは、トンネルソースに VLAN を使用していますが、ループバックを使用することもできます。 ![\[ルーターと AWS Direct Connect 間のトランジット VIF 接続構成の詳細\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/db17e177-6c94-4d81-ab39-0923ecab2f1b/images/e88d2546-61ef-4531-972b-089cdf44ed67.png) 以下は、トランジット VIF の AS 番号 (ASN) などの構成詳細です。 | | | [リソース] | Item | [Detail] (詳細) | | --- |--- |--- | | ルーター 01 | ASN | 65534 | | ルーター 02 | ASN | 65534 | | ルーター 03 | ASN | 65534 | | ルーター 04 | ASN | 65534 | | Direct Connect ゲートウェイ | ASN | 64601 | | トランジットゲートウェイ | ASN | 64600 | | CIDR ブロック | 10.100.254.0/24 | *Transit Gateway Connect のアーキテクチャ* 次の図と表は、Transit Gateway Connect アタッチメントを介して単一の VRF を構成する方法を示しています。VRF を追加する場合は、一意のトンネル ID、トランジットゲートウェイ GRE IP アドレス、および CIDR ブロック内の BGP を割り当てます。ピア GRE IP アドレスは、トランジット VIF のルーターピア IP アドレスと一致します。 ![\[ルーターとトランジットゲートウェイの間の GRE トンネル構成の詳細\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/db17e177-6c94-4d81-ab39-0923ecab2f1b/images/e58278e1-f3b4-442d-95d9-1dafab4aa5ac.png) 次の表には、ルーター構成の詳細が記載されています。 | | | ルーター | トンネル | IP アドレス | ソース | 目的地 | | --- |--- |--- |--- |--- | | ルーター 01 | トンネル 1 | 169.254.101.17 | VLAN 60169.254.100.1 | 10.100.254.1 | | ルーター 02 | トンネル 11 | 169.254.101.81 | VLAN 61169.254.100.5 | 10.100.254.11 | | ルーター 03 | トンネル 21 | 169.254.101.145 | VLAN 62169.254.100.9 | 10.100.254.21 | | ルーター 04 | トンネル 31 | 169.254.101.209 | VLAN 63169.254.100.13 | 10.100.254.31 | 次の表には、トランジットゲートウェイ構成の詳細が記載されています。 | | | トンネル | トランジットゲートウェイ GRE IP アドレス | ピア GRE IP アドレス | CIDR ブロック内の BGP | | --- |--- |--- |--- | | トンネル 1 | 10.100.254.1 | VLAN 60169.254.100.1 | 169.254.101.16/29 | | トンネル 11 | 10.100.254.11 | VLAN 61169.254.100.5 | 169.254.101.80/29 | | トンネル 21 | 10.100.254.21 | VLAN 62169.254.100.9 | 169.254.101.144/29 | | トンネル 31 | 10.100.254.31 | VLAN 63169.254.100.13 | 169.254.101.208/29 | **デプロイメント** 「[エピック](#extend-vrfs-to-aws-by-using-aws-transit-gateway-connect-epics)」セクションでは、**** 1 つの VRF に対する複数のカスタマールーターの構成例をデプロイする方法について説明します。ステップ 1 ～ 5 の完了後、AWS に拡張する新しい VRF ごとにステップ 6 ～ 7 を実行して、新しい Transit Gateway Connect アタッチメントを作成できます。 1. トランジットゲートウェイを作成します。 1. 各 VRF の Transit Gateway ルートテーブルを作成します。 1. トランジット仮想インターフェイスを作成します。 1. Direct Connect ゲートウェイを作成します。 1. Direct Connect ゲートウェイ仮想インターフェイスと、許可されたプレフィックスを持つゲートウェイアソシエーションを作成します。 1. Transit Gateway Connect アタッチメントを作成します。 1. Transit Gateway Connect ピアを作成します。 1. Transit Gateway Connect アタッチメントをルートテーブルに関連付けます。 1. ルートをルーターにアドバタイズします。 ## ツール ** サービス** + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) は、標準のイーサネット光ファイバーケーブルを介して内部ネットワークを Direct Connect の場所にリンクします。この接続を使用すると、ネットワークパスのインターネットサービスプロバイダーを回避してパブリック AWS サービスに対する仮想インターフェイスを直接作成できます。 + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを接続する中央ハブです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 ## エピック ### アーキテクチャを計画する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カスタムアーキテクチャ図を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | ### Transit Gateway リソースの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | トランジットゲートウェイを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | ネットワーク管理者、クラウドアーキテクト | | トランジットゲートウェイルートテーブルを作成します。 | 「[トランジットゲートウェイルートテーブルの作成](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#create-tgw-route-table)」の指示に従います。このパターンでは、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | ### トランジット仮想インターフェイスの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | トランジット仮想インターフェイスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | ### Direct Connect のリソースの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Direct Connect ゲートウェイを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | | Direct Connect ゲートウェイをトランジット VIF に接続します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | | 許可されたプレフィックスを使用して Direct Connect ゲートウェイアソシエーションを作成します。 | ネットワークハブアカウントで、「[トランジットゲートウェイを関連付ける方法](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html#associate-tgw-with-direct-connect-gateway)」の指示に従います。このパターンでは、次の点に注意してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html)このアソシエーションを作成すると、Direct Connect Gateway リソースタイプの Transit Gateway アタッチメントが自動的に作成されます。このアタッチメントは、トランジットゲートウェイのルートテーブルに関連付ける必要はありません。 | クラウドアーキテクト、ネットワーク管理者 | | Transit Gateway Connect アタッチメントを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | クラウドアーキテクト、ネットワーク管理者 | | Transit Gateway Connect ピアを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | | ### ルーターにルートをアドバタイズする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルートをアドバタイズします。 | 新しいTransit Gateway Connect アタッチメントを、この VRF 用に作成したルートテーブルに関連付けます。たとえば、プロダクション Transit Gateway Connect アタッチメントを `Production-VRF` ルートテーブルに関連付けます。ルーターにアドバタイズされるプレフィックス用の静的ルートを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/extend-vrfs-to-aws-by-using-aws-transit-gateway-connect.html) | ネットワーク管理者、クラウドアーキテクト | ## 関連リソース ** ドキュメント** + Direct Connect ドキュメント + [Direct Connect ゲートウェイの操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) + [トランジットゲートウェイの関連付け](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html) + [AWS Direct Connect 仮想インターフェイス](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html) + Transit Gateway ドキュメント + [トランジットゲートウェイの使用](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html) + [Direct Connect ゲートウェイへのトランジットゲートウェイアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-dcg-attachments.html) + [Transit Gateway Connect アタッチメントと Transit Gateway Connect ピア](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html) + [Transit Gateway の 接続 アタッチメントを作成する](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html#create-tgw-connect-attachment) ** ブログの投稿** + [AWS Transit Gateway Connect によるハイブリッドネットワークのセグメント化](https://aws.amazon.com/blogs/networking-and-content-delivery/segmenting-hybrid-networks-with-aws-transit-gateway-connect/) + [AWS Transit Gateway Connect を使用して VRF を拡張し、IP プレフィックスアドバタイズメントを増やす](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-transit-gateway-connect-to-extend-vrfs-and-increase-ip-prefix-advertisement/) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/db17e177-6c94-4d81-ab39-0923ecab2f1b/attachments/attachment.zip)」 # AWS KMS キーのキーの状態が変更されたときに Amazon SNS 通知を受け取る *Amazon Web Services、Shubham Harsora、Aromal Raj Jayarajan、Navdeep Pareek* ## 概要 AWS Key Management Service (AWS KMS) キーに関連付けられているデータとメタデータは、キーが削除されると失われます。削除は元に戻せず、失われたデータ (暗号化されたデータを含む) を回復することはできません。AWS KMS キーの「[キーステータス](https://docs.aws.amazon.com/kms/latest/developerguide/key-state.html#key-state-cmk-type)」の変更を通知する通知システムを設定することで、データ損失を防ぐことができます。 このパターンは、Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を使用して AWS KMS キーのキーの状態が `Disabled` または `PendingDeletion` に変わるたびに自動通知を発行することで、AWS KMS キーのステータス変化を監視する方法を示しています。たとえば、ユーザーが AWS KMS キーを無効化または削除しようとすると、試行されたステータス変更の詳細が記載されたメール通知が届きます。このパターンを使用して、AWS KMS キーの削除をスケジュールすることもできます。 ## 前提条件と制限 **前提条件** + AWS Identity and Access Management (IAM) ユーザーがいるアクティブな AWS アカウント + 「[AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html)」 ## アーキテクチャ テクノロジースタック + Amazon EventBridge + AWS Key Management Service (AWS KMS) + Amazon Simple Notification Service (Amazon SNS) **ターゲットアーキテクチャ** 次の図は、AWS KMS キーの状態の変化を検出するための自動モニタリングおよび通知プロセスを構築するためのアーキテクチャを示しています。 ![\[モニタリングと通知の自動化プロセスを構築するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2534df87-a6fd-4360-9b5d-4a8b1f533de3/images/0cb6a6b0-405b-4d26-ad04-2067176aa086.png) この図表は、次のワークフローを示しています: 1. ユーザーが AWS KMS キーの削除を無効化またはスケジュールします。 1. EventBridge ルールは、スケジュール `Disabled` または `PendingDeletion` イベントを評価します。 1. EventBridge ルールは Amazon SNS トピックを呼び出します。 1. Amazon SNS はユーザーに E メール通知メッセージを送信します。 **注記** E メールメッセージを組織のニーズに合わせてカスタマイズできます。AWS KMS キーが使用されているエンティティに関する情報を含めることをお勧めします。これにより、ユーザーは AWS KMS キーを削除した場合の影響を理解できます。AWS KMS キーが削除される 1 日または 2 日前に送信されるリマインダーメール通知をスケジュールすることもできます。 **自動化とスケール** AWS CloudFormation スタックは、このパターンが機能するために必要なすべてのリソースとサービスをデプロイします。このパターンは、1 つのアカウントに個別に実装することも、「[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」を使用して AWS Organizations の複数の独立したアカウントまたは「[組織単位](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)」に実装することもできます。 ## ツール + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントと AWS リージョンにわたってライフサイクル全体にわたってリソースを管理できます。このパターンの CloudFormation テンプレートは、必要なすべての AWS リソースを記述し、CloudFormation はそれらのリソースをプロビジョニングして構成してくれる。 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。EventBridge は、お客様独自のアプリケーション、AWS のサービスからリアルタイムデータのストリームを配信し、そのデータを AWS Lambda などのターゲットにルーティングします。EventBridge は、イベント駆動型アーキテクチャを構築するプロセスを簡素化します。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 **Code** このパターンのコードは、GitHub 内の「[Monitor の AWS KMS キー無効化および予定削除](https://github.com/aws-samples/aws-kms-deletion-notification)」リポジトリで利用できます。 ## エピック ### CloudFormation テンプレートをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 以下のコマンドを実行して、GitHub「[Monitor AWS KMS キー無効化およびスケジュール削除](https://github.com/aws-samples/aws-kms-deletion-notification)」リポジトリをローカルマシンに複製します。`git clone https://github.com/aws-samples/aws-kms-deletion-notification` | AWS 管理者、クラウドアーキテクト | | テンプレートのパラメータを更新します。 | コードエディターで、リポジトリから複製した `Alerting-KMS-Events.yaml` CloudFormation テンプレートを開き、次のパラメーターを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.html) | AWS 管理者、クラウドアーキテクト | | CloudFormation のテンプレートをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.html) | AWS 管理者、クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションメールを確認します。 | CloudFormation のテンプレートが正常にデプロイされると、Amazon SNS は CloudFormation テンプレートで指定されたメールアドレスにサブスクリプションの確認メッセージを送信します。通知を受信するには、このメールのサブスクリプションを確認する必要があります。詳細については、Amazon SNS 開発者ガイドの「[サブスクリプションの確認](https://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.confirm.html)」を参照してください。 | AWS 管理者、クラウドアーキテクト | ### サブスクリプション通知をテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS KMS キーを無効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.html) | AWS 管理者 | | サブスクリプションを検証します。 | Amazon SNS の通知メールが届いたことを確認します。 | AWS 管理者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.html) | AWS 管理者 | ## 関連リソース + 「[AWS CloudFormation](https://aws.amazon.com/cloudformation/)」(AWS ドキュメント) + 「[AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」(AWS CloudFormation ドキュメント) + 「[AWS でのイベント駆動型アーキテクチャの構築](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US)」(AWS Workshop Studio ドキュメント) + 「[AWS Key Management Service ベストプラクティス](https://d1.awsstatic.com/whitepapers/aws-kms-best-practices.pdf)」(AWS ホワイトペーパー) + 「[AWS Key Management Service のセキュリティベストプラクティス](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html)」(AWS KMS 開発者ガイド) ## 追加情報 Amazon SQS は、デフォルトで送信中の暗号化を提供します。キュリティのベストプラクティスに合わせて、AWS KMS カスタマーマネージドキーを使用して Amazon SNS のサーバー側の暗号化を有効にすることもできます。 # 非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約 *Amazon Web Services、Adam Spicer* ## 概要 Amazon Web Services(AWS)は、[トランジットゲートウェイアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)と[ロードバランサーエンドポイント](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) ([AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-high-level-steps.html) またはサードパーティアプライアンスをサポートするため) の両方に仮想プライベートクラウド(VPC)の専用サブネットを使用することを推奨するベストプラクティスを公開しています。これらのサブネットは、これらのサービスのエラスティックネットワークインターフェイスを格納するために使用されます。AWS Transit Gateway とゲートウェイロードバランサーの両方を使用する場合、VPC の各アベイラビリティーゾーンに 2 つのサブネットが作成されます。VPC の設計方法により、このような余分なサブネットは [/28 マスクより小さくすることはできず](https://docs---aws.amazon.com.rproxy.goskope.comvpc/latest/userguide/configure-subnets.html#subnet-sizing)、ルーティング可能なワークロードに使用できたはずの貴重なルーティング可能な IP スペースを消費する可能性があります。このパターンは、ルーティング不可能なClassless Inter-Domain Routing (CIDR) 範囲をこれらの専用サブネットに使用して、ルーティング可能な IP スペースを節約する方法を示しています。 ## 前提条件と制限事項 **前提条件** + ルーティング可能な IP [スペースのマルチ VPC 戦略](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) + 使用しているサービス ([トランジットゲートウェイアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)、[ゲートウェイロードバランサー](https://aws.amazon.com/blogs/apn/centralized-traffic-inspection-with-gateway-load-balancer-on-aws/) または [Network Firewall エンドポイント](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)) のルーティング不可能なCIDR範囲 ## アーキテクチャ **ターゲット アーキテクチャ** このパターンには 2 つのリファレンスアーキテクチャが含まれます。1 つのアーキテクチャにはトランジットゲートウェイ (TGW) アタッチメント用のサブネットと ゲートウェイ ロードバランサーエンドポイント (GWLBE) 用のサブネットがあり、もう 1 つのアーキテクチャには TGW アタッチメント専用のサブネットがあります。 **アーキテクチャ 1 ‒ アプライアンスへの入力ルーティングを備えた TGW 接続 VPC** 次の図は、2 つのアベイラビリティーゾーンにまたがる VPC のリファレンスアーキテクチャを示しています。インレスでは、VPC は [イングレスルーティングパターン](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/) を使用して、パブリックサブネット宛のトラフィックを [Bump-in-the-Wire](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) アプライアンスに転送し、ファイアウォールインスペクションを行います。TGW アタッチメントは、プライベートサブネットから別の VPC への出力をサポートします。 このパターンでは、TGW アタッチメントサブネットと GwLBe サブネットにルーティング不可能な CIDR 範囲を使用します。TGW ルートテーブルでは、このルーティング不能な CIDR は、より具体的なルートのセットを使用してブラックホール (静的) ルートに設定されています。ルートが TGW ルートテーブルに伝達される場合、これらのより具体的なブラックホールルートが適用されます。 この例では、/23 ルーティング可能な CIDR が分割され、ルーティング可能なサブネットに完全に割り当てられます。 ![\[アプライアンスへの入力ルーティングを備えた TGW 接続 VPC。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/adad1c83-cdc2-4c5e-aa35-f47fc31af384.png) **アーキテクチャ 2 — TGW 接続 VPC** 次の図は、2 つのアベイラビリティーゾーンにまたがる VPC のリファレンスアーキテクチャを示しています。TGW アタッチメントは、プライベートサブネットから別の VPC へのアウトバウンドトラフィック (下り) をサポートします。TGW アタッチメントサブネットにのみルーティング不可能な CIDR 範囲を使用します。TGW ルートテーブルでは、このルーティング不能な CIDR は、より具体的なルートのセットを使用してブラックホール (静的) ルートに設定されています。ルートが TGW ルートテーブルに伝達される場合、これらのより具体的なブラックホールルートが適用されます。 この例では、/23 ルーティング可能な CIDR が分割され、ルーティング可能なサブネットに完全に割り当てられます。 ![\[プライベートサブネットから別の VPC に出力するための TGW アタッチメントを備えた、2 つのアベイラビリティーゾーンにまたがる VPC。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/31a2a241-5be6-425e-93e9-5ff7ffeca3a9.png) ## ツール **AWS のサービスと設定されているリソース** + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンでは、VPC セカンダリ CIDR を使用して、ワークロード CIDR 内のルーティング可能な IP スペースを確保します。 + [インターネットゲートウェイのイングレスルーティング](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/) (エッジアソシエーション) は、専用の非ルーティングサブネットの ゲートウェイロードバランサーエンドポイントとともに使用できます。 + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は VPC とオンプレミスネットワークを接続する一元的ハブです。このパターンでは、VPC はトランジットゲートウェイに集中的に接続され、Transit Gateway アタッチメントはルーティングできない専用のサブネットに配置されます。 + [ゲートウェイロードバランサ―](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)を使用すると、ファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムなどの仮想アプライアンスをデプロイ、スケール、管理できます。ゲートウェイは、すべてのトラフィックの単一の入口と出口の役割を果たします。このパターンでは、ゲートウェイロードバランサーのエンドポイントは、ルーティングできない専用のサブネットで使用できます。 + [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、ステートフルでマネージド型のネットワークファイアウォールならびに侵入検知および防止サービスです。このパターンでは、ゲートウェイロードバランサーのエンドポイントは、ルーティングできない専用のサブネットで使用できます。 **コードリポジトリ** このパターンのランブックと AWS CloudFormation テンプレートは、GitHub の[ルーティング不可能なセカンダリ](https://github.com/aws-samples/non-routable-secondary-vpc-cidr-patterns/) CIDR パターンリポジトリにあります。サンプルファイルを使用して、環境内に作業ラボをセットアップできます。 ## ベストプラクティス **AWS Transit Gateway** + 各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します。 + ルーティング不可能なセカンダリ CIDR 範囲から /28 サブネットを Transit Gateway アタッチメントサブネットに割り当てます。 + 各トランジットゲートウェイのルートテーブルに、ルーティングできない CIDR 範囲の静的でより具体的なルートをブラックホールとして追加します。 **ゲートウェイロードバランサーとイングレス・ルーティング** + イングレスルーティングを使用して、インターネットからのトラフィックをゲートウェイロードバランサーエンドポイントに転送します。 + 各ゲートウェイロードバランサーエンドポイントに個別のサブネットを使用します。 + ゲートウェイロードバランサーエンドポイントサブネットに、ルーティング不可能なセカンダリ CIDR 範囲から /28 サブネットを割り当てます。 ## エピック ### VPCの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルーティング不可能な CIDR 範囲を決定します。 | Transit Gateway アタッチメントサブネットと (オプションで) ゲートウェイLoad Balancer または Network Firewall エンドポイントサブネットに使用される、ルーティング不可能なCIDR範囲を決定します。この CIDR 範囲は VPC のセカンダリ CIDR として使用されます。VPC のプライマリ CIDR 範囲またはより大きなネットワークから**ルーティング可能であってはなりません**。 | クラウドアーキテクト | | VPC のルーティング可能な CIDR 範囲を決定します。 | VPC に使用されるルーティング可能な CIDR 範囲のセットを決定します。この CIDR 範囲は VPC のプライマリ CIDR として使用されます。 | クラウドアーキテクト | | VPCの作成 | VPC を作成し、トランジットゲートウェイにアタッチします。各 VPC には、前の 2 つのステップで決定した範囲に基づいて、ルーティング可能なプライマリ CIDR 範囲とルーティング不可能なセカンダリ CIDR 範囲が必要です。 | クラウドアーキテクト | ### Transit ゲートウェイ のブラックホールルートの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | より具体的なルーティング不能な CIDR をブラックホールとして作成する。 | 各トランジットゲートウェイのルートテーブルには、ルーティング不可能なCIDR用に作成されたブラックホールルートのセットが必要です。これらは、セカンダリ VPC CIDR からのトラフィックがルーティング不可能なままになり、大規模なネットワークに漏れることがないように設定されています。これらのルートは、VPC のセカンダリ CIDR として設定されているルーティング不可能な CIDR よりも具体的でなければなりません。たとえば、ルーティング不可能なセカンダリ CIDR が 100.64.0.0/26 の場合、トランジットゲートウェイのルートテーブル内のブラックホールルートは 100.64.0.0/27 と 100.64.0.32/27 である必要があります。 | クラウドアーキテクト | ## 関連リソース + [ゲートウェイロードバランサーをデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) + [ゲートウェイロードバランサーを使用した分散型検査アーキテクチャ](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/distributed-inspection-architectures-gwlb-ra.pdf?did=wp_card&trk=wp_card) + [ネットワーキングイマージョンデー](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc) ‒ [インターネットから VPC ファイアウォールラボ](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc) + [Transit Gateway 設計のベストプラクティス](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html) ## 追加情報 ルーティング不可能なセカンダリ CIDR 範囲は、大量の IP アドレスを必要とする大規模なコンテナデプロイメントを扱う場合にも役立ちます。このパターンをプライベート NAT ゲートウェイで使用すると、ルーティング不可能なサブネットを使用してコンテナデプロイメントをホストできます。詳細については、ブログ記事 [プライベート NAT ソリューションでプライベート IP の枯渇を解決する方法](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) を参照してください。 # コードリポジトリ AWS Service Catalog を使用して で Terraform 製品をプロビジョニングする *Amazon Web Services、Rahul Sharad Gaikwad 博士、Tamilselvan P* ## 概要 AWS Service Catalog は[HashiCorp Terraform ](https://developer.hashicorp.com/terraform/tutorials/aws-get-started)設定のガバナンスによるセルフサービスプロビジョニングをサポートします。Terraform を使用する場合は、Service Catalog を単一のツールとして使用して、 内の Terraform 設定を大規模 AWS に整理、管理、配布できます。Service Catalog の主な機能には、標準化および事前承認された Infrastructure as Code (IaC) テンプレートのカタログ化、アクセスコントロール、最小特権アクセスによるクラウドリソースのプロビジョニング、バージョニング、数千の共有 AWS アカウント、タグ付けなどがあります。エンジニア、データベース管理者、データサイエンティストなどのエンドユーザーは、アクセスできる製品とバージョンのリストを表示して、1 つのアクションでデプロイできます。 このパターンは、Terraform コードを使用して AWS リソースをデプロイするのに役立ちます。GitHub リポジトリの Terraform コードには、Service Catalog からアクセスできます。この手法を用いることで、製品を既存の Terraform ワークフローと統合することもできます。管理者は、Terraform を使用して Service Catalog ポートフォリオを作成し、 AWS Launch Wizard 製品を追加できます。 この方法による利点は以下のとおりです。 + Service Catalog のロールバック機能のため、デプロイ中に問題が発生した場合は、製品を以前のバージョンに戻すことができます。 + 製品バージョンの違いを簡単に特定できます。これにより、デプロイ中の問題を解決できます。 + Service Catalog で、GitHub や GitLab などとのリポジトリ接続を設定できます。製品の変更は、リポジトリから直接行うことができます。 の全体的な利点については AWS Service Catalog、[「サービスカタログとは](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)」を参照してください。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + ZIP 形式の Terraform 設定ファイルを含む GitHub、BitBucket、またはその他のリポジトリ。 + AWS Serverless Application Model コマンドラインインターフェイス (AWS SAM CLI) [がインストールされている](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)。 + 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://go.dev/doc/install)の Go。 + Python バージョン 3.9、[Installed](https://www.python.org/downloads/release/python-3913/). AWS SAM CLI には、このバージョンの Python が必要です。 + Service Catalog 製品とポートフォリオにアクセスして管理するための AWS Lambda 関数とアクセス許可を記述して実行するアクセス許可。 ## アーキテクチャ ![\[コードリポジトリから Service Catalog で Terraform 製品をプロビジョニングするアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7d0d76e8-9485-4b3f-915f-481b6a7cdcd9/images/e83fa44a-4ca6-4438-a0d1-99f09a3541bb.png) この図表は、次のワークフローを示しています: 1. Terraform 設定の準備ができたら、開発者はすべての Terraform コードを含む .zip ファイルを作成します。開発者は、Service Catalog に接続されているコードリポジトリに .zip ファイルをアップロードします。 1. 管理者は、Terraform 製品を Service Catalog のポートフォリオに関連付けます。管理者は、エンドユーザーが製品をプロビジョニングできるようにする起動制約も作成します。 1. Service Catalog では、エンドユーザーは Terraform 設定を使用して AWS リソースを起動します。デプロイする製品バージョンを選択できます。 ## ツール **AWS のサービス** + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。 **その他のサービス** + [Go](https://go.dev/doc/install) は、Google がサポートするオープンソースのプログラミング言語です。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** Service Catalog を通じてデプロイできるサンプル Terraform 設定が必要な場合は、GitHub [Amazon Macie Organization Setup Using Terraform](https://github.com/aws-samples/aws-macie-customization-terraform-samples) リポジトリから取得できます。このリポジトリでコードサンプルを使用する必要はありません。 ## ベストプラクティス + Terraform 設定ファイル (`terraform.tfvars`) で変数の値を指定する代わりに、Service Catalog を使用して製品を起動するときに変数値を設定します。 + 特定のユーザーまたは管理者にのみポートフォリオへのアクセスを許可します。 + 最小特権の原則に従い、タスクの実行に必要な最小限のアクセス許可を付与します。詳細については、 AWS Identity and Access Management (IAM) ドキュメントの[「最小特権の付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と[「セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPracticesAndUseCases.html)」を参照してください。 ## エピック ### ローカルワークステーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | (オプション) Docker をインストールします。 | 開発環境で AWS Lambda 関数を実行する場合は、Docker をインストールします。手順については、Docker ドキュメントの[「Docker Engine のインストール」](https://docs.docker.com/engine/install/)を参照してください。 | DevOps エンジニア | | Terraform 用の AWS Service Catalog エンジンをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | DevOps エンジニア、AWS 管理者 | ### GitHub リポジトリに接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリの接続を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | ### Service Catalog で Terraform 製品を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Service Catalog 製品を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | ポートフォリオを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | Terraform 製品をポートフォリオに追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | アクセスポリシーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | カスタム信頼ポリシーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | Service Catalog 製品に起動制約を追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | 製品へのアクセスを許可します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | | 製品を起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | DevOps エンジニア | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイを検証する。 | Service Catalog プロビジョニングワークフローには 2 つの AWS Step Functions ステートマシンがあります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html)`ManageProvisionedProductStateMachine` ステートマシンのログをチェックして、製品がプロビジョニングされたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | DevOps エンジニア | ### インフラストラクチャをクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロビジョニング済み製品を削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | DevOps エンジニア | | Terraform AWS Service Catalog の エンジンを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.html) | AWS 管理者 | ## 関連リソース **AWS ドキュメント** + [Terraform 製品の開始方法](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted-Terraform.html) Terraformのドキュメント + [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) + [Terraform のバックエンド設定](https://developer.hashicorp.com/terraform/language/backend) + [Terraform AWS プロバイダーのドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) ## 追加情報 **アクセスポリシー** ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/servicecatalog:provisioning": "true" } } }, { "Action": [ "s3:CreateBucket*", "s3:DeleteBucket*", "s3:Get*", "s3:List*", "s3:PutBucketTagging" ], "Resource": "arn:aws:s3:::*", "Effect": "Allow" }, { "Action": [ "resource-groups:CreateGroup", "resource-groups:ListGroupResources", "resource-groups:DeleteGroup", "resource-groups:Tag" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "tag:GetResources", "tag:GetTagKeys", "tag:GetTagValues", "tag:TagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" } ] } ``` **信頼ポリシー** ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "GivePermissionsToServiceCatalog", "Effect": "Allow", "Principal": { "Service": "servicecatalog.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::account_id:root" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "aws:PrincipalArn": [ "arn:aws:iam::accounti_id:role/TerraformEngine/TerraformExecutionRole*", "arn:aws:iam::accounti_id:role/TerraformEngine/ServiceCatalogExternalParameterParserRole*", "arn:aws:iam::accounti_id:role/TerraformEngine/ServiceCatalogTerraformOSParameterParserRole*" ] } } } ] } ``` # Amazon SES を使用して 1 つの E メールアドレス AWS アカウント に複数の を登録する *Joe Wozniak と Shubhangi Vishwakarma、Amazon Web Services* ## 概要 このパターンでは、 に関連付けられている E メールアドレスから実際の E メールアドレスを切り離す方法について説明します AWS アカウント。アカウントの作成時に一意の E メールアドレスを指定 AWS アカウント する必要があります。一部の組織では、 が管理するチームが、メッセージングチームで多くの一意の E メールアドレスを管理する負担を引き受け AWS アカウント る必要があります。これは、多くの を管理する大規模な組織では難しい場合があります AWS アカウント。さらに、メールシステムが「[Sieve Email Filtering: Subaddress Extension (RFC 5233)](https://datatracker.ietf.org/doc/html/rfc5233)」で定義されているように、*プラスアドレス*または*サブアドレス*を許可しない場合、プラス記号 (\$1) と識別子をメールアドレスのローカル部分の末尾に追加します (例: `admin+123456789123@example.com`)。このパターンは、この制限を克服するのに役立ちます。 このパターンは、 AWS アカウント 所有者が 1 つの E メールアドレスを複数の E メールアドレスに関連付けることができる、一意の E メールアドレス販売ソリューションを提供します AWS アカウント。 AWS アカウント 所有者の実際の E メールアドレスは、テーブル内のこれらの生成された E メールアドレスに関連付けられます。このソリューションは、一意のメールアカウントのすべての受信メールを処理し、各アカウントの所有者を検索して、受信したメッセージを所有者に転送します。  ## 前提条件と制限事項 **前提条件** + への管理アクセス AWS アカウント。 + 開発環境へのアクセス権。 + (オプション) AWS Cloud Development Kit (AWS CDK) ワークフローと Python プログラミング言語に精通していれば、問題のトラブルシューティングや変更に役立ちます。 **制限事項** + 全販売メールアドレスは 64 文字長です。詳細については、*AWS Organizations API リファレンス*の「[CreateAccount](https://docs.aws.amazon.com/organizations/latest/APIReference/API_CreateAccount.html)」を参照してください。 **製品バージョン** + Node.js バージョン 22.x 以降 + Python 3.13 以降 + Python パッケージ **pip** と **virtualenv** + AWS CDK CLI バージョン 2.1019.2 以降 + Docker 20.10.x 以降 ## アーキテクチャ **ターゲットテクノロジースタック** + CloudFormation スタック + AWS Lambda 関数 + Amazon Simple Email Service (Amazon SES) ルールとルールセット + AWS Identity and Access Management (IAM) ロールとポリシー + Amazon Simple Storage Service (Amazon S3) バケットとバケットポリシー + AWS Key Management Service (AWS KMS) キーとキーポリシー + Amazon Simple Notification Service (Amazon SNS) のトピックとトピックポリシー + Amazon DynamoDB テーブル **ターゲットアーキテクチャ** ![\[単一メールアドレスで複数の AWS アカウントを登録するターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1be85b92-69e5-43b2-aeed-27b9509e145e/images/c7ae9d7a-d4e0-412e-97cb-0f3073e012e7.png) この図は、以下の 2 つのフローを示しています。 + **メールアドレス販売フロー**: この図では、メールアドレス販売フロー (下のセクション) は通常、アカウント販売ソリューションまたは外部自動化で開始、または手動で呼び出されます。リクエストでは、必要なメタデータを含むペイロードで Lambda 関数が呼び出されます。この関数はこの情報を使用して一意のアカウント名とメールアドレスを生成し、DynamoDB データベースに保存して、呼び出し元に値を返します。その後、これらの値を使用して新しい AWS アカウント (通常は を使用) を作成できます AWS Organizations。 + **メール転送フロー**: このフローは、前の図の上部セクションに示されています。E メールアドレス販売フローから生成されたアカウント E メールを使用して が作成されると、 AWS アカウント はアカウント登録の確認や定期的な通知など、さまざまな E メールをその E メールアドレス AWS に送信します。このパターンのステップに従って、ドメイン全体の E メールを受信するように Amazon SES AWS アカウント で を設定します。このソリューションでは、Lambda がすべての受信メールを処理し、`TO` アドレスが DynamoDB テーブルにあるかどうかを確認し、代わりにアカウントオーナーのメールアドレスにメッセージを転送できるようにする転送ルールを設定します。このプロセスを使用すると、アカウントオーナーは複数のアカウントを単一メールアドレスに関連付けできます。 **自動化とスケール** このパターンでは AWS CDK 、 を使用してデプロイを完全に自動化します。このソリューションは、ニーズに合わせて自動的にスケールする (またはスケールするように設定できる) AWS マネージドサービスを使用します。Lambda 関数には、スケーリングのニーズを満たすために追加の設定が必要な場合があります。詳細については、Lambda ドキュメントの「[Lambda 関数のスケーリングについて](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html)」を参照してください。 ## ツール **AWS サービス** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを通じて AWS のサービスを操作するのに役立つオープンソースツールです。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [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) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Email Service (Amazon SES)](https://docs.aws.amazon.com/ses/latest/dg/Welcome.html) - ユーザー自身のメールアドレスとドメインを使用してメールを送受信する上で役立ちます。 + 「[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 CLI および への IAM アクセスを持つ開発環境 AWS アカウント。詳細については、[関連リソース](#register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses-resources)セクションのリンクを参照してください。  + 開発システムに以下をインストールします。 + Git コマンドラインツールは、[Git ダウンロードウェブサイト](https://git-scm.com/downloads)から入手できます。 + AWS CLI のアクセス認証情報を設定する AWS CDK。詳細については、[AWS CLI のドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)を参照してください。 + [Python ダウンロードウェブサイト](https://www.python.org/downloads/)で利用できる Python バージョン 3.13 以降。 + UV for Python パッケージ管理。インストールの手順については、「[UV インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)」を参照してください。 + Node.js バージョン 22.x 以降。インストール手順については、「[Node.js のドキュメント](https://nodejs.org/en/learn/getting-started/how-to-install-nodejs)」を参照してください。 + AWS CDK CLI バージョン 2.1019.2 以降。インストール手順については、「[AWS CDK のドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/getting-started.html#getting-started-install)」を参照してください。 + Docker バージョン 20.10.x 以降。インストール手順については、「[Docker のドキュメント](https://docs.docker.com/engine/install/)」を参照してください。 **コード** このパターンのコードは、GitHub 内の「[AWS アカウント Factory メール](https://github.com/aws-samples/aws-account-factory-email)」リポジトリで利用できます。 ## エピック ### ターゲットデプロイ環境を割り当てる | タスク | 説明 | 必要なスキル | | --- | --- | --- | | を特定または作成します AWS アカウント。 | E メールソリューションをデプロイするために、完全な管理アクセス権がある既存または新規の AWS アカウント を特定します。 | AWS 管理者、クラウド管理者 | | デプロイ環境を設定します。 | 次の手順に従って、使い易いデプロイ環境を構成し、依存関係を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | AWS DevOps、アプリ開発者 | ### 検証済みドメインをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドメインを特定して割り当てます。 | メール転送機能には専用ドメインが必要です。Amazon SES で検証できるドメインまたはサブドメインを特定して割り当てます。このドメインは、E メール転送ソリューションがデプロイ AWS アカウント されている 内で受信 E メールを受信できる必要があります。ドメイン要件:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | クラウド管理者、ネットワーク管理者、DNS 管理者 | | ドメインを検証します。 | 特定したドメインが受信メールの受け入れに使用できることを確認します。Amazon SES ドキュメントの [Amazon SES E メールを受信するドメインの検証](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-verification.html)の手順を実行します。これには、ドメインの DNS レコードを担当する個人またはチームとの調整が必要です。 | アプリ開発者、AWS DevOps | | MX レコードをセットアップします。 | AWS アカウント および リージョンの Amazon SES エンドポイントを指す MX レコードを使用してドメインを設定します。詳細については、Amazon SES ドキュメントの [Amazon SES E メール受信用 MX レコードの公開](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html)を参照してください。 | クラウド管理者、ネットワーク管理者、DNS 管理者 | ### メールの販売と転送ソリューションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `cdk.json` のデフォルト値を変更します。 | デプロイ後にソリューションが正しく動作するように、`cdk.json` ファイル (リポジトリのルート内) のデフォルト値の一部を編集します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | アプリ開発者、AWS DevOps | | メールの販売と転送ソリューションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | アプリ開発者、AWS DevOps | | ソリューションがデプロイされていることを確認します。 | テストを開始する前に、ソリューションが正常にデプロイされたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | アプリ開発者、AWS DevOps | ### メールの販売と転送が想定どおりに動作することを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API が動作していることを確認します。 | このステップでは、ソリューションの API にテストデータを送信し、ソリューションが期待どおりの出力を生成し、バックエンド操作が期待どおりに実行されていることを確認します。テスト入力を使用して、**販売メール**の Lambda 関数を手動で実行します。(例については、[sample\$1vend\$1request.json ファイル](https://github.com/aws-samples/aws-account-factory-email/blob/main/src/events/sample_vend_request.json)を参照してください。) `OwnerAddress` の場合は、有効なメールアドレスを使用します。API は、期待どおりの値を含むアカウント名とアカウントメールを返す必要があります。 | アプリ開発者、AWS DevOps | | メールが転送中であることを確認します。 | このステップでは、システム経由でテストメールを送信し、メールが想定される受信者に転送されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | アプリ開発者、AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | システムが期待どおりにメールを転送しません。 | 設定が正しいことを確認する[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html)ドメインの設定を検証したら、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | | AWS CDK スタックをデプロイしようとすると、次のようなエラーが表示されます。「テンプレートのフォーマットエラー: 認識されないリソースタイプ」 | ほとんどの場合、このエラーメッセージは、ターゲットにしているリージョンに利用可能なすべての AWS サービスがないことを意味します。Amazon EC2 インスタンスを使用してソリューションをデプロイする場合は、インスタンスを実行中のリージョンとは異なるリージョンをターゲットにしている場合があります。デフォルトでは、 は で設定したリージョンとアカウントに AWS CDK デプロイされます AWS CLI。考えられる解決策[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.html) | | ソリューションをデプロイすると、次のエラーメッセージが表示されます。「デプロイに失敗しました: エラー: AWSMailFWDStack: SSM パラメータ/cdk-bootstrap/hnb659fds/version が見つかりません。環境はブートストラップされていますか? 「cdk bootstrap」を実行してください。 | ターゲットとする AWS アカウント およびリージョンに AWS CDK リソースをデプロイしたことがない場合は、エラーが示すように、まず `cdk bootstrap` コマンドを実行する必要があります。bootstrapping コマンドを実行した後もこのエラーが引き続き表示される場合は、開発環境が実行されているリージョンとは異なるリージョンにソリューションをデプロイしようとしている可能性があります。この問題を解決するには、ソリューションをデプロイ AWS CLI する前に、 `AWS_DEFAULT_REGION`環境変数を設定するか、 でリージョンを設定します。または、[環境用のAWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)の指示に従って、リポジトリのルートにある `app.py` ファイルを変更して、ハードコーディングされたアカウント ID とリージョンを含めることもできます。 | ## 関連リソース + のインストールについては AWS CLI、[「 の最新バージョンのインストールまたは更新 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」を参照してください。 + IAM アクセス認証情報 AWS CLI を使用して を設定する方法については、[「 の設定 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。 + のヘルプについては AWS CDK、[「 の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html#getting_started_install)」を参照してください。 ## 追加情報 **コスト** このソリューションをデプロイすると、 AWS アカウント 所有者は次のサービスの使用に関連するコストが発生する可能性があります。 これらのサービスの請求方法を理解して、潜在的な費用を認識しておくことが重要です。価格設定情報については、次のページを参照してください。 + [Amazon SES の価格設定](https://aws.amazon.com/ses/pricing/) + [Amazon S3 の価格設定](https://aws.amazon.com/s3/pricing/) + [AWS KMS 料金](https://aws.amazon.com/kms/pricing/) + [AWS Lambda 料金](https://aws.amazon.com/lambda/pricing/) + [Amazon DynamoDB の価格設定](https://aws.amazon.com/dynamodb/pricing/) # 単一アカウントの AWS 環境でハイブリッドネットワークの DNS 解決を設定 *Abdullahi Olaoye、Amazon Web Services* ## 概要 このパターンでは、管理オーバーヘッドなしで、オンプレミスリソース、AWS リソース、インターネットDNSクエリのエンドツーエンドDNS解決を可能にする、完全なハイブリッドドメインネームシステム（DNS）アーキテクチャを設定する方法を示しています。このパターンは、ドメイン名に基づいて AWS から送信される DNS クエリの送信先を決定する、 Amazon Route 53 Resolver 転送ルールを設定する方法を示しています。オンプレミスリソースの DNS クエリは、オンプレミスの DNS レゾルバ に転送されます。AWS リソースの DNS クエリとインターネット DNS クエリは Route 53 Resolver によって解決されます。 このパターンでは、AWS シングルアカウント環境のハイブリッド DNS 解決を対象としています。AWS マルチアカウント環境でのアウトバウンド DNS クエリの設定については、「[マルチアカウント AWS 環境でのハイブリッドネットワークの DNS 解決の設定](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.html)」 パターンを参照してください。 ## 前提条件と制限事項 **前提条件** + AWS アカウント + AWS アカウントに 仮想プライベートクラウド (VPC) を作成 + AWS 仮想プライベートネットワーク (AWS VPN) または AWS Direct Connect を使用した、オンプレミスの環境とお客様の VPC 間のネットワーク接続 + オンプレミス DNS レゾルバ の IP アドレス (VPC からアクセス可能) + オンプレミスレゾルバ に転送するドメイン/サブドメイン名 (たとえば、 onprem.mydc.com) + AWS プライベートホストゾーンのドメイン/サブドメイン名 (たとえば、myvpc.cloud.com) ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Route 53 プライベートホストゾーン + Amazon Route 53 Resolver + Amazon VPC + AWS VPN または Direct Connect **ターゲットアーキテクチャ** ![\[Route 53 Resolver を使用した AWS シングルアカウント環境でのハイブリッド DNS 解決のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/120dedc8-cc6c-4aa7-be11-c70a7ee80642/images/7b75f534-1adc-4a39-86d6-5c4596ff7b6a.png) ## ツール + [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html) は、ハイブリッドクラウド全体でシームレスな DNS クエリ解決を可能にすることで、企業のお客様がハイブリッドクラウドをより簡単に利用できるようにします。DNS エンドポイントと条件付き転送ルールを作成して、オンプレミスデータセンターと VPC の間の DNS 名前空間を解決できます。 + [Amazon Route 53プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)は、Amazon VPC サービスで作成する 1 つ以上の VPC 内のドメインとそのサブドメインへの DNS クエリに対し、Amazon Route 53 がどのように応答するかに関する情報を保持するコンテナです。 ## エピック ### プライベートホストゾーンを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | myvpc.cloud.com などの AWS リザーブドドメイン名に、 Route 53 プライベートホストゾーンを作成します。 | このゾーンには、オンプレミス環境から解決する必要がある AWS リソースの DNS レコードが格納されます。手順については、Route 53 ドキュメントの「[プライベートホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)」を参照してください。 | ネットワーク管理者、システム管理者 | | プライベートホストゾーンを VPC に関連付けます。 | VPC のリソースが、このプライベートホストゾーンの DNS レコードを解決できるようにするには、VPC をホストゾーンに関連付ける必要があります。手順については、Route 53 ドキュメントの「[プライベートホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.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 アドレスをメモしておきます。 | ネットワーク管理者、システム管理者 | | アウトバウンドエンドポイントを作成します。 | Route 53 Resolver は、アウトバウンドエンドポイントを使用して DNS クエリをオンプレミスの DNS レゾルバ に送信します。手順については、Route 53 ドキュメントの「[アウトバウンド DNS クエリのネットワークへの転送](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html)」 を参照してください。出力エンドポイント ID を書きとめておきます。 | ネットワーク管理者、システム管理者 | ### 転送ルールを設定して VPC に関連付け | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスドメインのルールを作成します。 | このルールは、オンプレミスドメイン (onprem.mydc.com など) の DNS クエリを、すべてオンプレミスの DNS レゾルバ に転送するよう Route 53 Resolver に指示します。このルールを作成するには、オンプレミスの DNS レゾルバの IP アドレスと Route 53 Resolverのアウトバウンドエンドポイント ID が必要です。手順については、Route 53 ドキュメントの「[転送ルールの管理](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html)」 を参照してください。 | ネットワーク管理者、システム管理者 | | 転送ルールを VPC に関連付けます。 | 転送ルールを有効にする VPC に関連付ける必要があります。その後、Route 53 Resolver はドメインを解決する際にルールを考慮します。手順については、Route 53 ドキュメントの「[転送ルールの管理](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html)」 を参照してください。 | ネットワーク管理者、システム管理者 | ### オンプレミスの DNS レゾルバ の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オンプレミスの DNS レゾルバ で条件付き転送を設定します。 | DNS クエリをオンプレミス環境から Route 53 プライベートホストゾーンに送信するには、オンプレミスの DNS レゾルバ で条件付き転送を設定する必要があります。これにより、AWS ドメイン (myvpc.cloud.com など) のすべての DNS クエリを Route 53 Resolverのインバウンドエンドポイント IP アドレスに転送するよう DNS レゾルバに指示します。 | ネットワーク管理者、システム管理者 | ### エンドツーエンドDNS解決をテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS からオンプレミス環境への DNS解決をテストします。 | VPC のサーバーから、オンプレミスドメイン (server1.onprem.mydc.com など) の DNS クエリを実行します。 | ネットワーク管理者、システム管理者 | | オンプレミス環境から AWS への DNS 解決案をテストします。 | オンプレミスサーバーから、AWS ドメイン (server1.myvpc.cloud.com など) の DNS 解決を実行します。 | ネットワーク管理者、システム管理者 | ## 関連リソース + 「[Amazon Route 53 および AWS Transit Gateway を使用したハイブリッドクラウドの一元化 DNS 管理](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-dns-management-of-hybrid-cloud-with-amazon-route-53-and-aws-transit-gateway/)」 (AWS ネットワークおよびコンテンツ配信ブログ) + 「[Route 53 Resolverでマルチアカウント環境の DNS 管理を簡素化](https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/)」 (AWS セキュリティブログ) + 「[プライベートホストゾーンの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)」 (Route 53 ドキュメント) + 「[Route 53 Resolverの使用を開始](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html)」 (Route 53 ドキュメント) # AWS CloudFormation を使用して Amazon EC2 に UiPath RPA ボットを自動的にセットアップする *Dr. Rahul Sharad Gaikwad と Tamilselvan P、Amazon Web Services* ## 概要 このパターンでは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにロボティックプロセスオートメーション (RPA) ボットをデプロイする方法を説明しています。ここでは、[EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html) パイプラインを使用して、カスタム Amazon マシンイメージ (AMI) を作成します。AMI は、EC2 インスタンスをデプロイするためのオペレーティングシステム (OS) とプリインストールされたソフトウェアを含む事前構成された仮想マシン (VM)イメージです。このパターンでは、AWS CloudFormation テンプレートを使用して [UiPath Studio コミュニティエディション](https://www.uipath.com/product/studio)をカスタム AMI にインストールします。UiPath は、ロボットをセットアップしてタスクを自動化するのに役立つ RPA ツールです。 このソリューションの一部として、EC2 Windows インスタンスはベース AMI を使用して起動され、UiPath Studio アプリケーションがインスタンスにインストールされます。このパターンは、Microsoft システム準備 (Sysprep) ツールを使用し、のカスタマイズされた Windows インストールを重複します。その後、ホスト情報を削除し、インスタンスから最終的な AMI を作成します。これにより、独自の命名規則とモニタリング設定で最終的な AMI を使用し、インスタンスをオンデマンドで起動できます。 | | | 注: このパターンでは RPA ボットの使用に関する情報は得られません。詳細については、[UiPath ドキュメント](https://docs.uipath.com/)を参照してください。このパターンを使用して、独自の要件に基づいてインストール手順をカスタマイズすることで、他の RPA ボットアプリケーションを設定することもできます。 | | --- | このパターンには次のような自動化と利点があります。 + アプリケーションのデプロイと共有: アプリケーションのデプロイ用に Amazon EC2 AMI を構築し、EC2 Image Builder パイプラインを通じて複数のアカウントで共有できます。このパイプラインでは、AWS CloudFormation テンプレートを Infrastructure as Code (IaC) スクリプトとして使用します。 + Amazon EC2 のプロビジョニングとスケーリング: CloudFormation IaC テンプレートは、カスタムコンピュータ名シーケンスと Active Directory 参加の自動化を提供します。 + オブザーバビリティとモニタリング: このパターンは Amazon EC2 メトリクス (CPU やディスク使用量など) のモニタリングに役立つ Amazon CloudWatch ダッシュボードを設定します。 + RPA がビジネスにもたらすメリット: RPA は割り当てられたタスクをロボットが自動的かつ一貫して実行できるため、精度が向上します。また、RPA は付加価値のない業務を排除し、繰り返しの多い作業を処理するため、スピードと生産性も向上します。 ## 前提条件と制限事項 **前提条件** + アクティブな [AWS アカウント](https://aws.amazon.com/free/) + CloudFormation テンプレートをデプロイするための [ Identity and Access Management (IAM) 許可](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) + EC2 Image Builder でクロスアカウント AMI ディストリビューションをセットアップするための [IAM ポリシー](https://docs.aws.amazon.com/imagebuilder/latest/userguide/cross-account-dist.html) ## アーキテクチャ ![\[Amazon EC2 で RPA ボットをセットアップするためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5555a62d-91d4-4e81-9961-ff89faedd6ad/images/1893d2d3-8912-4473-adf1-6633b5badcd9.png) 1. 管理者は `ec2-image-builder.yaml` ファイルにベースの Windows AMI を指定し、CloudFormation コンソールにスタックをデプロイします。 1. CloudFormation スタックは、以下のリソースを含む EC2 Image Builder パイプラインをデプロイします。 + `Ec2ImageInfraConfiguration` + `Ec2ImageComponent` + `Ec2ImageRecipe` + `Ec2AMI` 1. EC2 Image Builder パイプラインは、ベース AMI を使用して一時的な Windows EC2 インスタンスを起動し、必要なコンポーネント (この場合は UiPath Studio) をインストールします。 1. EC2 Image Builder はすべてのホスト情報を削除し、Windows サーバーから AMI を作成します。 1. カスタム AMI で `ec2-provisioning yaml` ファイルを更新し、独自の要件に基づいて多数の EC2 インスタンスを起動します。 1. Count マクロは、CloudFormation テンプレートを使用してデプロイします。このマクロは CloudFormation リソースの **Count** プロパティを提供するので、同じタイプの複数のリソースを簡単に指定できます。 1. CloudFormation `ec2-provisioning.yaml` ファイル内のマクロの名前を更新し、スタックをデプロイします。 1. 管理者は要件に基づいて `ec2-provisioning.yaml` ファイルを更新し、スタックを起動します。 1. このテンプレートは UiPath Studio アプリケーションで EC2 インスタンスをデプロイします。 ## ツール **AWS サービス** + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) を使用すると、インフラストラクチャリソースを自動的かつ安全な方法でモデル化および管理できます。 + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) は、AWS、オンプレミス、その他のクラウド上のリソースとアプリケーションを観察およびモニタリングするのに役立ちます。 + [Amazon Elastic Compute Cloud (Amazon EC2](https://aws.amazon.com/ec2/)) は、AWS クラウド内で安心で再サイズを変更できるコンピューティング性能を提供するウェブサービスです。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [EC2 Image Builder](https://aws.amazon.com/image-builder/) は、AWS またはオンプレミスで使用する仮想マシンとコンテナイメージの構築、テスト、デプロイを簡素化します。 + [Amazon EventBridge](https://aws.amazon.com/eventbridge/) は、AWS、既存のシステム、または Software as a Service (SaaS) アプリケーション全体にわたって、イベント駆動型アプリケーションを大規模に構築できるよう支援します。 + [ Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、AWS リソースへのアクセスを安全にコントロールするのに役立ちます。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を集中管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。 + [AWS Lambda](https://aws.amazon.com/lambda/) は、サーバーレスのイベント駆動型のコンピューティングサービスで、サーバーのプロビジョニングや管理を行わなくても、実質あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。200 以上の AWS サービスや SaaS アプリケーションから Lambda 関数を呼び出すことができ、使用した分のみ料金が発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [AWS Systems Manager Agent (SSM Agent)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) は、Systems Manager が EC2 インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) を更新、管理、構成するのに役立ちます。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[CloudFormation を使用した UiPath RPA ボットのセットアップ](https://github.com/aws-samples/uipath-rpa-setup-ec2-windows-ami-cloudformation)」リポジトリで利用できます。このパターンでは、[AWS CloudFormation マクロリポジトリ](https://github.com/aws-cloudformation/aws-cloudformation-macros/tree/master/Count)から入手できるマクロも使用しています。 ## ベストプラクティス + AWS は毎月新しい [Windows AMI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-ami-version-history.html) をリリースしています。これには最新の OS パッチ、ドライバー、起動エージェントが含まれます。新しいインスタンスを起動する際、または独自のカスタムイメージを作成する際は、最新の AMI を使用してください。 + イメージのビルド時には、Windows または Linux で使用可能なすべてのセキュリティパッチを適用してください。 ## エピック ### ベースイメージ用のイメージパイプラインをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EC2 Image Builder パイプラインをセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | EC2 Image Builder の設定を表示します。 | EC2 Image Builder の設定には、インフラストラクチャ構成、ディストリビューション設定、セキュリティスキャン設定が含まれます。設定を表示するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html)ベストプラクティスとして、EC2 Image Builder の更新は CloudFormation テンプレートからのみ行ってください。 | AWS DevOps | | イメージパイプラインを表示します。 | デプロイされたイメージパイプラインを表示するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | Image Builder のログを表示します。 | EC2 Image Builder のログは CloudWatch ロググループに集約されます。CloudWatch コンソールでのログを表示するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html)EC2 Image Builder のログも S3 バケットに保存されます。バケット内のログを表示するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | S3 バケットに UiPath ファイルをアップロードする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | ### Count マクロのデプロイとテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Count マクロをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html)コンソールを使用する場合は、前のエピックまたは [CloudFormation ドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)の指示に従ってください。  | DevOps エンジニア | | Count マクロをテストします。 | マクロの機能をテストするには、マクロに付属しているサンプルテンプレートを起動してみてください。 
aws cloudformation deploy \
    --stack-name Count-test \
    --template-file test.yaml \
    --capabilities CAPABILITY_IAM
| DevOps エンジニア | ### CloudFormation スタックをデプロイし、カスタムイメージでインスタンスをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EC2 プロビジョニングテンプレートをデプロイする。 | CloudFormation を使用して EC2 イメージパイプラインをデプロイするには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | Amazon EC2 の設定を表示する。 | Amazon EC2 の構成には、セキュリティ、ネットワーク、ストレージ、ステータスチェック、モニタリング、タグの構成が含まれます。これらの構成を表示するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | CloudWatch ダッシュボードを表示する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html)スタックをプロビジョニングした後、ダッシュボードにメトリクスを入力するには時間がかかります。ダッシュボードには次のメトリクスが表示されます: `CPUUtilization`、`DiskUtilization`、`MemoryUtilization`、`NetworkIn`、`NetworkOut`、`StatusCheckFailed`。 | AWS DevOps | | メモリとディスクの使用状況に関するカスタムメトリックスを表示する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | メモリとディスクの使用状況に関するアラームを表示する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | | スナップショットのライフサイクルルールを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html) | AWS DevOps | ### 環境を削除する (オプション) | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スタックを削除します。 | PoC またはパイロットプロジェクトが完了したら、作成したスタックを削除して、これらのリソースに対して課金されないようにすることをお勧めします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.html)スタックの削除操作は、開始後に停止することはできません。スタックは `DELETE_IN_PROGRESS` 状態になります。削除が失敗した場合、スタックは `DELETE_FAILED` 状態になります。解決策については、AWS CloudFormation トラブルシューティングドキュメントの「[スタックの削除失敗](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-delete-stack-fails)」を参照してください。スタックが誤って削除されないように保護する方法については、AWS CloudFormation ドキュメントの「[スタックが削除されないように保護する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html)」を参照してください。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Amazon EC2 プロビジョニングテンプレートをデプロイすると、「*トランスフォーム 123xxxx:: Count から不正な形式の応答を受信しました*」というエラーが表示される。 | これは既知の問題です。([AWS CloudFormation マクロリポジトリ](https://github.com/aws-cloudformation/aws-cloudformation-macros/pull/20)のカスタムソリューションと PR を参照してください)。この問題を解決するには、AWS Lambda コンソールを開き、[GitHub リポジトリ](https://raw.githubusercontent.com/aws-cloudformation/aws-cloudformation-macros/f1629c96477dcd87278814d4063c37877602c0c8/Count/src/index.py)のコンテンツで `index.py` を更新します。  | ## 関連リソース **GitHub リポジトリ** + [CloudFormation を使用した UiPath RPA ボットのセットアップ](https://github.com/aws-samples/uipath-rpa-setup-ec2-windows-ami-cloudformation) + [Count CloudFormation Macro](https://github.com/aws-cloudformation/aws-cloudformation-macros/tree/master/Count) **AWS リファレンス** + [AWS CloudFormation コンソールでのスタックの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) (CloudFormation ドキュメント) + [CloudFormation のトラブルシューティング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html) (CloudFormation ドキュメント) + [Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) (Amazon EC2 ドキュメント) + [CloudWatch エージェントを使用して Windows サーバー上のパフォーマンスモニターのメトリクスを表示する方法を教えてください。](https://repost.aws/knowledge-center/cloudwatch-performance-monitor-windows)(AWS re: POST の記事) **その他の参考資料** + [UiPathドキュメント](https://docs.uipath.com/) + [Syspreped AMI でホスト名を設定する](https://blog.brianbeach.com/2014/07/setting-hostname-in-syspreped-ami.html) (Brian Beachによるブログ記事) + [パラメータが変更されたときに Cloudformation にマクロを使用してテンプレートを再処理させるにはどうすればよいですか?](https://stackoverflow.com/questions/59828989/how-do-i-make-cloudformation-reprocess-a-template-using-a-macro-when-parameters) (スタックオーバーフロー) # AWS で可用性の高い PeopleSoft アーキテクチャを設定する *Amazon Web Services、Ramanathan Muralidhar* ## 概要 PeopleSoft のワークロードを AWS に移行する場合、回復性は重要な目標です。これにより、PeopleSoft アプリケーションの可用性が常に高くなり、障害から迅速に回復できるようになります。 このパターンは、ネットワーク、アプリケーション、データベースの各層で高可用性 (HA) を確保するための AWS での PeopleSoft アプリケーションのアーキテクチャを設計する方法を提供します。データベース層には、[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) for Oracle、Amazon RDS for SQL Server データベースを使用します。このアーキテクチャには、[Amazon Route 53](https://aws.amazon.com/route53/)、[Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) Linux インスタンス、[Amazon Elastic Block Storage (Amazon EBS)](https://aws.amazon.com/ebs/)、[Amazon Elastic File System (Amazon EFS)](https://aws.amazon.com/efs/)、[Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer) などの AWS サービスも含まれており、スケーラブルです。 [Oracle PeopleSoft](https://www.oracle.com/applications/peoplesoft/) は、人員管理や他のビジネス運営のためのツールとアプリケーション一式を提供しています。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + AWS での設定に必要なライセンスを持つ PeopleSoft 環境 + AWS アカウントで設定された仮想プライベートクラウド (VPC) には、次のリソースがあります。 + 少なくとも 2 つのアベイラビリティーゾーン + 各アベイラビリティーゾーンに 1 つのパブリックサブネットと 3 つのプライベートサブネットがあります + NAT ゲートウェイとインターネットゲートウェイ + トラフィックをルーティングする各サブネットのルートテーブル　 + 組織の標準に従って PeopleSoft アプリケーションのセキュリティを確保するために定義されたネットワークアクセスコントロールリスト (ネットワーク ACL) とセキュリティグループ **機能制限** + このパターンは、高可用性 (HA) ソリューションを実現します。　 ディザスタリカバリ (DR) シナリオはサポートされていません。　 まれに、HA 実装の AWS リージョン全体が停止した場合、アプリケーションは使用できなくなります。 **製品バージョン** + PeopleTools 8.52 以降を実行している PeopleSoft アプリケーション ## アーキテクチャ **ターゲット アーキテクチャ** PeopleSoft 実稼働アプリケーションのダウンタイムや停止は、アプリケーションの可用性に影響を与え、ビジネスに多大な混乱をもたらします。　 PeopleSoft 実稼働アプリケーションは、常に高い可用性が得られるように設計することをお勧めします。これは、単一障害点をなくし、信頼性の高いクロスオーバーポイントまたはフェイルオーバーポイントを追加し、障害を検出することで実現できます。次の図では、PeopleSoft on AWS の HA アーキテクチャを示しています。 ![\[PeopleSoft on AWS 向けの可用性の高いアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0db96376-dadb-4545-b130-ebbe64acd4e9/images/5d585a8e-320a-495d-a049-97171633e90f.png) このアーキテクチャのデプロイでは、PeopleSoft データベースとして Amazon RDS for Oracle を使用し、Red Hat Enterprise Linux (RHEL) 上で実行される EC2 インスタンスを使用しています。　 Amazon RDS for SQL Server を Peoplesoft データベースとして使用することもできます。 このアーキテクチャには、以下のコンポーネントが含まれています。  + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、インターネットから PeopleSoft アプリケーションにリクエストをルーティングするためのドメインネームサーバー (DNS) として使用されます。 + [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) は、可用性に影響を与え、セキュリティを侵害し、過剰なリソースを消費する可能性のある一般的なウェブの脆弱性とボットからの保護に役立ちます。[AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/shield-chapter.html) (図には示されていません) は、はるかに幅広い保護を提供します。 + [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) は、ウェブサーバーをターゲットとした高度なリクエストルーティングにより、HTTP トラフィックと HTTPS トラフィックの負荷を分散します。 + PeopleSoft アプリケーションをサポートするウェブサーバー、アプリケーションサーバー、プロセススケジューラーサーバー、および Elasticsearch サーバーは、複数のアベイラビリティーゾーンで実行され、[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) を使用します。 + PeopleSoft アプリケーションが使用するデータベースは、[Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) 上でマルチ AZ 構成で動作します。 + PeopleSoft アプリケーションが使用するファイル共有は [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) で設定され、インスタンス間でファイルにアクセスするために使用されます。 + [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) は、Amazon EC2 Auto Scaling によって使用され、必要なときに PeopleSoft コンポーネントが迅速に複製されます。 + [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を使用すると、プライベートサブネット内のインスタンスは VPC 外のサービスに接続できますが、外部サービスはそれらのインスタンスとの接続を開始できません。 + [インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)は、VPC とインターネットとの間の通信を可能にする VPC コンポーネントであり、冗長性と高い可用性を備えており、水平スケーリングが可能です。 + パブリックサブネットの踏み台ホストは、インターネットや内部ネットワークなどの外部ネットワークから、オンプレミスサブネット上のサーバーへのアクセスを提供します。踏み台ホストは、プライベートサブネット内のサーバーへの制御されたセキュアなアクセスを提供します。 **アーキテクチャの詳細** PeopleSoft データベースは、マルチ AZ 設定の Amazon RDS for Oracle (または Amazon RDS for SQL Server) データベースに格納されています。　 Amazon RDS の [Amazon RDS マルチ AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) は、2 つのアベイラビリティーゾーン間でデータベース更新を複製して耐久性と可用性を高める機能です。Amazon RDS は、予定されたメンテナンスや予定外の中断に備えて、自動的にスタンバイデータベースにフェイルオーバーします。 PeopleSoft のウェブ層と中間層は EC2 インスタンスにインストールされます。これらのインスタンスは複数のアベイラビリティーゾーンに分散され、[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)によって結合されます。これにより、これらのコンポーネントでは常に高可用性が保証されます。アプリケーションが常に利用可能で、必要に応じてスケールできるように、必要最小限のインスタンス数が維持されます。 OEM EC2 インスタンスには、現行世代の EC2 インスタンスタイプを使用することをお勧めします。[AWS Nitro System で構築されたインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)などの現世代のインスタンスタイプは、ハードウェア仮想マシン (HVM) をサポートします。HVM AMI は、[拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)のメリットを活用する場合に必要であり、セキュリティも強化されています。各 Auto Scaling グループの一部である EC2 インスタンスは、インスタンスの交換またはスケールアップ時に独自の AMI を使用します。　 EC2 インスタンスタイプは、PeopleSoft アプリケーションが処理する負荷と、Oracle が PeopleSoft アプリケーションとPeopleTools のバージョンに推奨される最小値に基づいて選択することをお薦めします。ハードウェア要件とソフトウェア要件の詳細については、[Oracle サポートのウェブサイト](https://support.oracle.com)を参照してください。 PeopleSoft のウェブ層と中間層は Amazon EFS マウントを共有して、レポート、データファイル、および (必要に応じて) `PS_HOME` ディレクトリを共有します。Amazon EFS は、パフォーマンスとコストの観点から、各アベイラビリティーゾーンのマウントターゲットで設定されています。 Application Load Balancer は、PeopleSoft アプリケーションにアクセスするトラフィックをサポートするようにプロビジョニングされ、異なるアベイラビリティーゾーンにまたがるウェブサーバー間でトラフィックの負荷を分散します。Application Load Balancer は、最低 2 つのアベイラビリティーゾーンで HA を提供するネットワークデバイスです。　 ウェブサーバーは、ロードバランサー設定を使用してトラフィックを異なるアプリケーションサーバーに分散します。ウェブサーバーとアプリケーションサーバー間のロードバランシングにより、負荷がインスタンス全体に均等に分散され、インスタンスの過負荷によるボトルネックやサービスの中断を回避できます。 Amazon Route 53 は、インターネットから Application Load Balancer にトラフィックをルーティングする DNS サービスとして使用されます。Amazon Route 53 は、高可用性でスケーラブルな DNS Web サービスです。 **HA の詳細** + データベース: Amazon RDS のマルチ AZ 機能は、同期レプリケーションを使用して、複数のアベイラビリティゾーンで 2 つのデータベースを実行します。これにより、自動フェイルオーバーによる可用性の高い環境が構築されます。　 Amazon RDS にはフェイルオーバーイベント検出機能があり、イベントが発生すると自動フェイルオーバーを開始します。Amazon RDS API を使用して手動フェイルオーバーを開始することもできます。詳細な説明については、ブログ記事「[Amazon RDS Under The Hood:マルチ AZ](https://aws.amazon.com/blogs/database/amazon-rds-under-the-hood-multi-az/)」を参照してください。フェイルオーバーはシームレスで、フェイルオーバーが発生するとアプリケーションは自動的にデータベースに再接続します。ただし、フェイルオーバー中のプロセス スケジューラ ジョブはいずれもエラーが発生し、再送信する必要があります。 + PeopleSoft アプリケーションサーバー:アプリケーションサーバーは複数のアベイラビリティーゾーンに分散され、Auto Scaling グループが定義されています。　 インスタンスに障害が発生した場合、Auto Scaling グループは、アプリケーションサーバーテンプレートの AMI から複製された正常なインスタンスに、そのインスタンスを置き換えます。具体的には、*jolt プーリング*が有効になっているため、アプリケーションサーバーのインスタンスが停止すると、セッションは自動的に別のアプリケーションサーバーにフェイルオーバーされ、Auto Scaling グループは自動的に別のインスタンスを起動し、アプリケーションサーバーを起動して Amazon EFS マウントに登録します。新しく作成されたアプリケーションサーバーは、ウェブサーバー内の `PSSTRSETUP.SH` スクリプトを使用して自動的にウェブサーバーに追加されます。これにより、PeopleSoft アプリケーションの可用性が常に高く、障害から迅速に回復できるようになります。 + プロセス スケジューラー: プロセス スケジューラーサーバーは複数のアベイラビリティゾーンに分散しており、Auto Scaling グループが定義されています。インスタンスに障害が発生した場合、Auto Scaling グループは、プロセス スケジューラー サーバーテンプレートの AMI からクローンされた正常なインスタンスに、そのインスタンスを置き換えます。具体的には、プロセス スケジューラインスタンスが停止すると、Auto Scaling グループは自動的に別のインスタンスを起動し、プロセス スケジューラを起動します。インスタンスに障害が発生した場合、実行中のジョブはすべて再送信する必要があります。これにより、には、プロセス スケジューラの可用性が常に高く、障害から迅速に回復できるようになります。 + Elasticsearch サーバー: Elasticsearch サーバーには、Auto Scaling グループが定義されています。インスタンスに障害が発生した場合、Auto Scaling グループは、Elasticsearch サーバーテンプレートの AMI からクローンされた正常なインスタンスに、そのインスタンスを置き換えます。具体的には、Elasticsearch インスタンスが停止すると、リクエストを処理する Application Load Balancer がエラーを検出し、そのインスタンスへのトラフィックの送信を停止します。Auto Scaling グループは自動的に別のインスタンスを起動し、Elasticsearch インスタンスを起動します。Elasticsearch インスタンスがバックアップされると、Application Load Balancer はインスタンスが正常であることを検出し、リクエストの送信を再開します。これにより、Elasticsearch サーバーの可用性が常に高く、障害から迅速に回復できるようになります。 + ウェブサーバー: ウェブサーバーには、Auto Scaling グループが定義されています。インスタンスに障害が発生した場合、Auto Scaling グループは、ウェブサーバーテンプレートの AMI からクローンされた正常なインスタンスに、そのインスタンスを置き換えます。具体的には、ウェブサーバーのインスタンスが停止すると、リクエストを処理する Application Load Balancer がエラーを検出し、そのインスタンスへのトラフィックの送信を停止します。Auto Scaling グループは自動的に別のインスタンスを起動し、ウェブサーバーのインスタンスを起動します。ウェブサーバーのインスタンスがバックアップされると、Application Load Balancer はインスタンスが正常であることを検出し、リクエストの送信を再開します。これにより、ウェブサーバーの可用性が常に高く、障害から迅速に回復できるようになります。 ## ツール **AWS サービス** + [アプリケーションロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)は、受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの EC2 インスタンスなどの複数のターゲットに分散します。 + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで使用するブロックレベルストレージのボリュームを提供します。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) は、AWS クラウドでの共有ファイルシステムの作成と設定に役立ちます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 ## ベストプラクティス **運用のベストプラクティス** + PeopleSoft on AWS を実行する場合、Route 53 を使用してインターネットとローカルからのトラフィックをルーティングします。プライマリ DB インスタンスを使用できない場合は、[フェイルオーバーオプション](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)を使用してトラフィックをディザスタリカバリ (DR) サイトに再ルーティングします。 + Application Load Balancerは、常に PeopleSoft 環境の前で使用してください。これにより、トラフィックの負荷がウェブサーバーにセキュアに分散されます。 + Application Load Balancer のターゲットグループ設定で、ロードバランサーが生成した Cookie で[維持設定がオン](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html)になっていることを確認します。 **注記** 外部シングルサインオン (SSO) を使用する場合は、アプリケーションベースの Cookie の使用が必要になることがあります。これにより、ウェブサーバーとアプリケーションサーバー間の接続が一貫していることが保証されます。 + PeopleSoft 実稼働アプリケーションの場合、Application Load Balancer のアイドルタイムアウトは、使用するウェブ プロファイルで設定されている値と一致する必要があります。これにより、ユーザーセッションがロードバランサーのレイヤーで期限切れになるのを防止できます。 + PeopleSoft 実稼働アプリケーションの場合は、アプリケーションサーバーの「[再利用回数](https://docs.oracle.com/cd/F28299_01/pt857pbr3/eng/pt/tsvt/concept_PSAPPSRVOptions-c07f06.html?pli=ul_d96e90_tsvt)」をメモリーリークを最小限に抑える値に設定します。 + このパターンで説明されているように PeopleSoft 実稼働アプリケーションに Amazon RDS データベースを使用している場合は、[高可用性を実現するためにマルチ AZ 形式](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)で実行します。 + データベースが PeopleSoft 実稼働アプリケーションの EC2 インスタンスで実行されている場合は、[高可用性を実現するためにスタンバイデータベースが別のアベイラビリティーゾーンで実行されている](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/ec2-oracle.html#ec2-oracle-ha)ことを確認してください。 + DR では、Amazon RDS データベースまたは EC2 インスタンスに、実稼働データベースとは別の AWS リージョンにスタンバイが設定されていることを確認してください。これにより、そのリージョンで障害が発生した場合に、アプリケーションを別のリージョンに切り替えることができます。 + DR では、[Amazon Elastic ディザスタリカバリ](https://aws.amazon.com/disaster-recovery/)を使用して、実稼働コンポーネントとは別のリージョンにアプリケーションレベルのコンポーネントを設定します。これにより、そのリージョンで障害が発生した場合に、アプリケーションを別のリージョンに切り替えることができるようになります。 + PeopleSoft のレポート、添付ファイル、およびデータファイルを保存するには、Amazon EFS (中程度の I/O 要件の場合) または [Amazon FSx](https://aws.amazon.com/fsx/) (厳しい I/O 要件の場合) を使用します。これにより、コンテンツは 1 か所に保存され、インフラストラクチャ内のどこからでもアクセスできます。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) (基本および詳細) を使用して、PeopleSoft アプリケーションが使用している AWS クラウドのリソースをほぼリアルタイムでモニタリングします。これにより、問題が即座にプッシュされ、環境の可用性に影響を与える前に迅速に対処できます。 + Amazon RDS データベースを PeopleSoft データベースとして使用している場合は、[拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html)を使用してください。この機能により、CPU、メモリ、ファイルシステム I/O、ディスク I/O など、50 を超えるメトリクスにアクセスできます。 + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) を使用して、PeopleSoft アプリケーションが使用している AWS リソースでの API コールをモニタリングします。これにより、セキュリティ分析、リソース変更の追跡、およびコンプライアンスのモニタリングを行うことができます。 **セキュリティベストプラクティス** + SQL インジェクションやクロスサイトスクリプティング (XSS) 攻撃など、一般的なエクスプロイトから PeopleSoft アプリケーションを保護するには、[AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) を使用します。カスタマイズされた検出および軽減サービスには、[AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/shield-chapter.html) の使用を検討してください。 + PeopleSoft アプリケーションのセキュリティを確保するために、トラフィックを HTTP から HTTPS に自動的にリダイレクトするルールを Application Load Balancer に追加します。 + Application Load Balancer に別のセキュリティグループを設定します。このセキュリティグループは HTTPS/HTTP インバウンドトラフィックのみを許可し、アウトバウンドトラフィックは許可しません。これにより、意図したトラフィックのみが許可されるため、アプリケーションのセキュリティが確保されます。 + アプリケーションサーバー、ウェブサーバー、データベースにはプライベートサブネットを使用し、アウトバウンドのインターネットトラフィックには [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を使用します。これにより、アプリケーションをサポートするサーバーにパブリックにアクセスできないようにし、必要なサーバーにのみパブリック アクセスを提供します。 + PeopleSoft の実稼働環境と非実稼働環境では、異なる VPC を使用します。　 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/)、[VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)、[ネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)、[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)を使用して [VPC](https://aws.amazon.com/vpc/) 間で、また必要に応じてオンプレミスデータセンターとの間で、トラフィックフローを制御します。 + 最小権限の原則に従います。PeopleSoft アプリケーションが使用する AWS リソースへのアクセス権は、必ず必要なユーザーにのみ付与されます。タスクの実行に必要な最低限の権限のみを付与します。詳細については、AWS Well-Architected フレームワークの「[セキュリティの柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)」を参照してください。 + 可能な限り、[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) を使用して PeopleSoft アプリケーションが使用する EC2 インスタンスにアクセスします。 **信頼性のベストプラクティス** + Application Load Balancer を使用するときは、有効なアベイラビリティゾーンごとに ターゲットを 1 つ登録します。これにより、ロードバランサーの効率が最高になります。 + PeopleSoft の実稼働環境ごとに、アプリケーションにアクセスするための URL、統合ブローカーにサービスを提供する URL、レポートを表示するための URL 、この 3 つの異なる URL を用意することをお勧めします。可能であれば、各 URL には独自の専用ウェブサーバーとアプリケーションサーバーが必要です。この URL にはそれぞれ異なる機能があり、アクセスが制御されるため、このデザインは PeopleSoft アプリケーションのセキュリティを高めるのに役立ちます。さらに、基盤となるサービスに障害が発生した場合の影響範囲を最小限に抑えることができます。 + PeopleSoft アプリケーションの[ロードバランサーのターゲットグループに対してヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)を構成することをお勧めします。ヘルスチェックは、EC2 インスタンスではなく、ウェブサーバーで実行する必要があります。これにより、ウェブサーバーがクラッシュしたり、ウェブサーバーをホストする EC2 インスタンスがダウンした場合でも、Application Load Balancer は正確な情報を反映します。 + PeopleSoft の実稼働アプリケーションでは、ウェブサーバーを少なくとも 3 つのアベイラビリティゾーンに分散させることをお勧めします。これにより、アベイラビリティゾーンの 1 つがダウンした場合の高可用性を常に維持できます。 + PeopleSoft 実稼働アプリケーションでは、jolt プール (`joltPooling=true`) を有効にします。これにより、パッチ適用や仮想マシン障害によってサーバーが停止した場合でも、アプリケーションが別のアプリケーションサーバーに確実にフェイルオーバーされます。 + PeopleSoft 実稼働アプリケーションの場合は、`DynamicConfigReload ` を 1 に設定します。この設定は、PeopleTools バージョン 8.52 以降でサポートされています。サーバーを再起動せずに、新規アプリケーションサーバーをウェブサーバーに動的に追加します。 + PeopleTools パッチを適用するときのダウンタイムを最小限に抑えるには、ウェブサーバーとアプリケーションサーバーの Auto Scaling グループの起動設定にブルー/グリーンデプロイ方法を使用してください。詳細については、ホワイトペーパー「[AWSデプロイオプションの概要](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)」を参照してください。 + [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) を使用して、AWS 上の PeopleSoft アプリケーションをバックアップします。AWS Backup は費用対効果が高く、フルマネージド型のポリシーベースのサービスで、大規模なデータ保護を簡素化します。 **パフォーマンスに関するベストプラクティス** + ビジネスで環境全体のトラフィックを暗号化する必要がある場合を除き、PeopleSoft 環境でパフォーマンスを最適化するには、Application Load Balancer で SSL を終了します。 + [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) や [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) などの AWS サービスの[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)を作成して、トラフィックが常に内部に送られるようにします。これは費用対効果が高く、アプリケーションのセキュリティを確保します。 **コスト最適化のベストプラクティス** + PeopleSoft 環境で使用されるすべてのリソースにタグを付け、[コスト配分タグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)を有効にします。これらのタグは、リソースコストの表示と管理に役立ちます。 + PeopleSoft 実稼働アプリケーションでは、ウェブサーバーとアプリケーションサーバーに Auto Scaling グループを設定します。　 これにより、アプリケーションをサポートするための最小限のウェブサーバーとアプリケーションサーバーが維持されます。[Auto Scaling グループポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html)を使用して、必要に応じてサーバーをスケールアップまたはスケールダウンできます。 + [請求アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)を使用すると、コストが指定した予算のしきい値を超えたときにアラートを受け取ることができます。 **サステナビリティのベストプラクティス** + [Infrastructure as Code](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) (IaC) を使用して PeopleSoft 環境を維持してください。これにより、一貫性のある環境を構築し、変更管理を維持できます。　 ## エピック ### PeopleSoft データベースを Amazon RDS に移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DB サブネットグループを作成します。 | [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)のナビゲーションペインで [**サブネットグループ**] を選択し、複数のアベイラビリティゾーンにサブネットを持つ Amazon RDS DB サブネットグループを作成します。これは、Amazon RDS データベースをマルチ AZ 設定で実行する時に必要です。 | クラウド管理者 | | Amazon RDS データベースを作成します。 | PeopleSoft HA 環境用に選択した AWS リージョンのアベイラビリティゾーンに Amazon RDS データベースを作成します。Amazon RDS データベースを作成するときは、マルチ AZ オプション (**スタンバイインスタンスを作成**) と前のステップで作成したデータベースのサブネットグループを必ず選択してください。詳細については、「 [Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)」を参照してください。 | クラウド管理者、Oracle データベース管理者 | | PeopleSoft データベースを Amazon RDS に移行します。 | AWS Database Migration Service (AWS DMS) を使用して、既存の PeopleSoft データベースを Amazon RDS データベースに移行します。詳細については、「[AWS DMS ドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html)」および AWS ブログ記事「[DMS を使用してほぼゼロのダウンタイムで Oracle データベースを移行する](https://aws.amazon.com/blogs/database/migrating-oracle-databases-with-near-zero-downtime-using-aws-dms/)」参照してください。 | クラウド管理者、PeopleSoft DBA | ### Amazon EFS ファイルシステムをマウントする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ファイルシステムを作成します。 | [Amazon EFS コンソール](https://console.aws.amazon.com/efs/)で、ファイルシステムを作成し、各アベイラビリティゾーンのターゲットをマウントします。手順については、「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html#creating-using-fs-part1-console)」を参照してください。ファイルシステムを作成したら、その DNS 名を書き留めます。ファイルシステムをマウントするときに、この情報を使用します。 | クラウド管理者 | ### PeopleSoft アプリケーションとファイルシステムを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EC2 インスタンスの起動 | PeopleSoft アプリケーションの EC2 インスタンスを起動します。手順については、「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html#liw-quickly-launch-instance)」を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | | PeopleSoft をインスタンスにインストールします。 | 作成した EC2 インスタンスに PeopleSoft アプリケーションと PeopleTools をインストールします。手順については、「[Oracle ドキュメント](https://docs.oracle.com)」を参照してください。 | クラウド管理者、PeopleSoft 管理者 | | アプリケーションサーバーを作成します。 | AMI テンプレート用のアプリケーションサーバーを作成し、Amazon RDSデータベースに正常に接続していることを確認します。 | クラウド管理者、PeopleSoft 管理者 | | Amazon EFS ファイルシステムをマウントします。 | ルートユーザーとして EC2 インスタンスにログインし、次のコマンドを実行してサーバー上の `PSFTMNT` というフォルダに、Amazon EFS ファイルシステムをマウントします。
sudo su –
mkdir /psftmnt
cat /etc/fstab
次の行を `/etc/fstab` ファイルに追加します。ファイルシステムを作成した際に書き留めた DNS 名を使用します。
fs-09e064308f1145388.efs.us-east-1.amazonaws.com:/ /psftmnt nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0
mount -a
| クラウド管理者、PeopleSoft 管理者 | | アクセス許可を確認します。 | PeopleSoft ユーザーが適切にアクセスできるように、`PSFTMNT` フォルダに適切な権限があることを確認してください。 | クラウド管理者、PeopleSoft 管理者 | | 追加のインスタンスを作成します。 | このエピックの前のステップを繰り返して、プロセス スケジューラー、ウェブサーバー、Elasticsearch サーバー用のテンプレートインスタンスを作成します。　 これらのインスタンスには、`PRCS_TEMPLATE`、`WEB_TEMPLATE`、`SRCH_TEMPLATE` という名前を付けます。ウェブサーバーには、`joltPooling=true`** **と `DynamicConfigReload=1` を設定します。 | クラウド管理者、PeopleSoft 管理者 | ### スクリプトを作成してサーバーを設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションサーバーをインストールするスクリプトを作成します。 | Amazon EC2 `APP_TEMPLATE` インスタンスで、PeopleSoft ユーザーとして次のスクリプトを作成します。`appstart.sh` という名前を付け、`PS_HOME` ディレクトリに配置します。このスクリプトを使用してアプリケーションサーバーを起動し、Amazon EFS マウントにサーバー名を記録します。
#!/bin/ksh
. /usr/homes/hcmdemo/.profile.
psadmin -c configure -d HCMDEMO
psadmin -c parallelboot -d HCMDEMO
touch /psftmnt/`echo $HOSTNAME`
| PeopleSoft 管理者 | | プロセス スケジューラサーバーをインストールするスクリプトを作成します。　 | Amazon EC2 `PRCS_TEMPLATE` インスタンスで、PeopleSoft ユーザーとして次のスクリプトを作成します。`prcsstart.sh` という名前を付け、`PS_HOME` ディレクトリに配置します。このスクリプトを使用して、プロセス スケジューラサーバーを起動します。
#!/bin/ksh
. /usr/homes/hcmdemo/. profile
/* The following line ensures that the process scheduler always has a unique name during replacement or scaling activity. */ 
sed -i "s/.*PrcsServerName.*/`hostname -I | awk -F. '{print "PrcsServerName=PSUNX"$3$4}'`/" $HOME/appserv/prcs/*/psprcs.cfg
psadmin -p configure -d HCMDEMO
psadmin -p start -d HCMDEMO
| PeopleSoft 管理者 | | Elasticsearch サーバーをインストールするスクリプトを作成します。　 | Amazon EC2 `SRCH_TEMPLATE` インスタンスで、Elasticsearch ユーザーとして次のスクリプトを作成します。`srchstart.sh` という名前を付け、`HOME` ディレクトリに配置します。
#!/bin/ksh
/* The following line ensures that the correct IP is indicated in the elasticsearch.yaml file. */
sed -i "s/.*network.host.*/`hostname  -I | awk '{print "host:"$0}'`/" $ES_HOME_DIR/config/elasticsearch.yaml
nohup $ES_HOME_DIR/bin/elasticsearch &
| PeopleSoft 管理者 | | ウェブサーバーをインストールするスクリプトを作成します。 | Amazon EC2 `WEB_TEMPLATE` インスタンスで、ウェブサーバーユーザーとして、`HOME` ディレクトリに次のスクリプトを作成します。`renip.sh`: このスクリプトは、AMI からクローンした際にウェブサーバに正しい IP が割り当てられていることを確認します。
#!/bin/ksh
hn=`hostname`
/* On the following line, change the IP with the hostname with the hostname of the web template. */
for text_file in `find  *  -type f -exec grep -l '' {} \;`
do
sed -e 's//'$hn'/g' $text_file > temp
mv -f temp $text_file
done
`psstrsetup.sh`: このスクリプトは、ウェブサーバーが現在実行している正しいアプリケーションサーバー IP を使用することを確認します。jolt ポート上の各アプリケーションサーバーへの接続を試み、設定ファイルに追加します。
#!/bin/ksh
c2=""
for ctr in `ls -1 /psftmnt/*.internal`
do
c1=`echo $ctr | awk -F "/" '{print $3}'`
/* In the following lines, 9000 is the jolt port. Change it if necessary. */
if nc -z $c1 9000 2> /dev/null; then
if [[ $c2 = "" ]]; then
c2="psserver="`echo $c1`":9000"
else
c2=`echo $c2`","`echo $c1`":9000"
fi
fi
done
`webstart.sh`: このスクリプトは前の 2 つのスクリプトを実行して、ウェブサーバーを起動します。
#!/bin/ksh
/* Change the path in the following if necessary. */
cd  /usr/homes/hcmdemo 
./renip.sh
./psstrsetup.sh
webserv/peoplesoft/bin/startPIA.sh
| PeopleSoft 管理者 | | crontab エントリを追加します。 | Amazon EC2 `WEB_TEMPLATE` インスタンスで、ウェブサーバーユーザーとして、**crontab** に次のスクリプトを作成します。時間とパスを変更して、必要な値を反映させます。このエントリにより、ウェブサーバの `configuration.properties` ファイル内にあるアプリケーションサーバーエントリが常に正しいことが保証されます。　
* * * * * /usr/homes/hcmdemo/psstrsetup.sh
| PeopleSoft 管理者 | ### AMI と Auto Scaling グループテンプレートを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションサーバーテンプレート用の AMI を作成します。 | Amazon EC2 コンソールで、Amazon EC2 `APP_TEMPLATE` インスタンスの AMI イメージを作成します。AMI を `PSAPPSRV-SCG-VER1` と名付けます。手順については、「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)」を参照してください。 | クラウド管理者、PeopleSoft 管理者 | | 別サーバー用の AMI を作成します。 | このエピックの前のステップを繰り返して、プロセス スケジューラー、Elasticsearch サーバー、ウェブサーバー用のテンプレートインスタンスを作成します。　 | クラウド管理者、PeopleSoft 管理者 | | アプリケーションサーバーの Auto Scaling グループの起動テンプレートを作成します。 | アプリケーションサーバーの Auto Scaling グループの起動テンプレートを作成します。テンプレートに `PSAPPSRV_TEMPLATE.` という名前を付けます。テンプレートで、`APP_TEMPLATE` インスタンス用に作成した AMI を選択します。手順については、「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-from-instance)」を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | | プロセス スケジューラサーバーの Auto Scaling グループの起動テンプレートを作成します。 | 前のステップを繰り返して、プロセス スケジューラサーバーの Auto Scaling グループの起動テンプレートを作成します。テンプレートに `PSPRCS_TEMPLATE` という名前を付けます。テンプレートで、プロセススケジューラ用に作成した AMI を選択します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | | Elasticsearch サーバーの Auto Scaling グループの起動テンプレートを作成します。 | 前のステップを繰り返して、Elasticsearch サーバーの Auto Scaling グループの起動テンプレートを作成します。テンプレートに `SRCH_TEMPLATE` という名前を付けます。テンプレートで、検索サーバー用に作成した AMI を選択します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | | ウェブサーバーの Auto Scaling グループの起動テンプレートを作成します。 | 前のステップを繰り返して、ウェブサーバーの Auto Scaling グループの起動テンプレートを作成します。テンプレートに `WEB_TEMPLATE` という名前を付けます。テンプレートで、ウェブサーバー用に作成した AMI を選択します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | ### Auto Scaling グループを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションサーバー の Auto Scaling グループを作成します。 | Amazon EC2 コンソールで、`PSAPPSRV_TEMPLATE` テンプレートを使用して、アプリケーションサーバー用の `PSAPPSRV_ASG` という名前の Auto Scaling グループを作成します。手順については、「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html)」を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者、PeopleSoft 管理者 | | 別サーバーの Auto Scaling グループを作成します。 | このエピックの前のステップを繰り返して、プロセス スケジューラーサーバー、Elasticsearch サーバー、ウェブサーバーの Auto Scaling グループを作成します。　 | クラウド管理者、PeopleSoft 管理者 | ### ターゲットグループの作成と設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ウェブサーバーのターゲットグループを作成します。 | Amazon EC2 コンソールで、ウェブサーバーのターゲットグループを作成します。詳細については、「[Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」を参照してください。ポートをウェブサーバーがリッスンしているポート番号に設定します。 | クラウド管理者 | | ヘルスチェックを設定します。 | ヘルスチェックの値がビジネス要件を反映した正しい値になっていることを確認してください。詳細については、「[Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)」を参照してください。 | クラウド管理者 | | Elasticsearch サーバーのターゲットグループを作成します。 | 前のステップを繰り返して、Elasticsearch サーバー用に `PSFTSRCH` というターゲットグループを作成し、正しい Elasticsearch ポートを設定します。 | クラウド管理者 | | Auto Scaling グループにターゲットグループを追加します。 | 先ほど作成した `PSPIA_ASG` というウェブサーバーの Auto Scaling グループを開きます。[**ロードバランサー**] タブで [**編集**] を選択してから、`PSFTWEB` ターゲットグループを Auto Scaling グループに追加します。Elasticsearch Auto Scaling グループ `PSSRCH_ASG` に対してこのステップを繰り返し、以前に作成したターゲットグループ `PSFTSRCH`を追加します。 | クラウド管理者 | | セッションの維持設定を行います。 | ターゲットグループ `PSFTWEB` で、[**属性**] タブを選択して、[**編集**] を選択した後、セッションの維持設定を行います。維持設定タイプでは、**ロードバランサーが生成した Cookie** を選択して、期間を 1 に設定します。詳細については、「[Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html)」を参照してください。ターゲットグループ `PSFTSRCH` にも同様に、このステップを繰り返します。 | クラウド管理者 | ### Application Load Balancer を作成して設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ウェブサーバーのロードバランサーを作成します。 | `PSFTLB` という名前の Application Load Balancer を作成して、ウエブサーバーへのトラフィックの負荷を分散させます。詳細については、「[Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html#configure-load-balancer)」を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者 | | Elasticsearch サーバーのロードバランサーを作成します。 | `PSFTSCH` という名前の Application Load Balancer を作成して、Elasticsearch サーバーへのトラフィックの負荷を分散させます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html) | クラウド管理者 | | Route 53 を設定します。 | [Amazon Route 53 コンソールで](https://console.aws.amazon.com/route53/)、PeopleSoft アプリケーションにサービスを提供するホストゾーンにレコードを作成します。手順については、「[Amazon Route 53ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」を参照してください。これにより、すべてのトラフィックがロードバランサーを通過するようになります。`PSFTLB` | クラウド管理者 | ## 関連リソース + [Oracle PeopleSoftのウェブサイト](https://www.oracle.com/applications/peoplesoft/) + [AWS ドキュメント](https://docs.aws.amazon.com/) # AWS Elastic Disaster Recoveryで Oracle JD Edwards EnterpriseOne のディザスタリカバリをセットアップする *Amazon Web Services、Thanigaivel Thirumalai* ## 概要 自然災害、アプリケーション障害、またはサービスの中断による災害は、収益に悪影響を及ぼし、企業アプリケーションのダウンタイムを引き起こします。JD Edwards EnterpriseOne Enterprise Resource Planning (ERP) システムやその他のミッションクリティカルかつビジネスクリティカルなソフトウェアを導入する企業にとって、このような事象の影響を軽減するためのディザスタリカバリ (DR) 計画が不可欠です。  このパターンは、企業が JD Edwards EnterpriseOne アプリケーションの DR オプションとして AWS Elastic Disaster Recovery を使用する方法を説明しています。また、Elastic Disaster Recovery のフェイルオーバーとフェイルバックを使用して、AWS クラウドの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされているデータベースのクロスリージョン DR 戦略を構築する手順についても概説しています。 **注記** このパターンでは、クロスリージョン DR 実装のプライマリリージョンとセカンダリリージョンを AWS でホストする必要があります。 [Oracle JD Edwards EnterpriseOne](https://www.oracle.com/applications/jd-edwards-enterpriseone/) は、さまざまな業界の中規模から大規模企業を対象とした統合型 ERP ソフトウェアソリューションです。 AWS Elastic Disaster Recovery は、手頃な価格のストレージ、最小限のコンピューティング、ポイントインタイムリカバリを使用して、オンプレミスおよびクラウドベースのアプリケーションを迅速かつ確実にリカバリすることで、ダウンタイムとデータ損失を最小限に抑えます。 AWS には [4 つのコアとなる DR アーキテクチャパターン](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)があります。このドキュメントでは、[パイロットライト戦略](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)を使用したセットアップ、構成、最適化に焦点を当てています。この戦略は、ソースデータベースからデータを複製するためのレプリケーションサーバーを最初にプロビジョニングし、DR ドリルとリカバリの開始時にのみ実際のデータベースサーバーをプロビジョニングする、低コストの DR 環境を構築するのに役立ちます。この戦略により、DR リージョンでデータベースサーバーを維持する費用が不要になります。代わりに、レプリケーションサーバーとして機能する小規模な EC2 インスタンスの料金のみが発生します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + Oracle Database または Microsoft SQL Server 上で実行されている JD Edwards EnterpriseOne アプリケーション。サポートされているデータベースは、マネージド EC2 インスタンスで実行中の状態になっている必要があります。このアプリケーションには、1 つの AWS リージョンにインストールされているすべての JD Edwards EnterpriseOne 基本コンポーネント (エンタープライズサーバー、HTML サーバー、データベースサーバー) が含まれている必要があります。 + Elastic Disaster Recovery サービスをセットアップするための AWS Identity and Access Management (IAM) ロール。 + 必要な[接続構成](https://docs.aws.amazon.com/drs/latest/userguide/Network-Requirements.html)に従って構成されたElastic Disaster Recovery を実行するためのネットワーク。 **制限事項** + データベースが Amazon Relational Database Service (Amazon RDS) でホストされている場合を除き、このパターンを使用してすべての層を複製できます。その場合は、Amazon RDS の[クロスリージョンコピー機能](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)を使用することをお勧めします。 + Elastic Disaster Recovery は CloudEndure Disaster Recovery と互換性がありませんが、CloudEndure Disaster Recovery からアップグレードできます。詳細については、「Elastic Disaster Recovery ドキュメント」の「[よくある質問](https://docs.aws.amazon.com/drs/latest/userguide/cedr-to-drs.html)」を参照してください。 + Amazon Elastic Block Store (Amazon EBS) では、スナップショットを作成できるレートに制限があります。Elastic Disaster Recovery を使用すると、1つのAWS アカウントに最大300台のサーバーを複製できます。より多くのサーバーを複製するには、複数の AWS アカウントまたは複数のターゲット AWS リージョンを使用できます。(Elastic Disaster Recovery はアカウントとリージョンごとに個別に設定する必要があります)。詳細については、「Elastic Disaster Recovery ドキュメント」の「[ベストプラクティス](https://docs.aws.amazon.com/drs/latest/userguide/best_practices_drs.html)」を参照してください。 + ソースワークロード (JD Edwards EnterpriseOne アプリケーションとデータベース) は EC2 インスタンスでホストされている必要があります。このパターンは、オンプレミスや他のクラウド環境にあるワークロードをサポートしていません。 + このパターンは JD Edwards EnterpriseOne コンポーネントに焦点を当てています。完全な DR と事業継続計画 (BCP) には、次のような他のコアサービスも含める必要があります。 + ネットワーク (仮想化プライベートクラウド、サブネット、セキュリティグループ) + Active Directory + Amazon WorkSpaces + Elastic Load Balancing + Amazon Relational Database Service (Amazon RDS) などのマネージド型データベースサービス 前提条件、構成、制限に関する追加情報については、「[ElasticDisaster Recoveryドキュメント](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 」を参照してください。 **製品バージョン** + Oracle JD Edwards EnterpriseOne (Oracleの最小技術要件に基づく、Oracle と SQL Server がサポートするバージョン) ## アーキテクチャ **ターゲットテクノロジースタック** + 本番用と非本番用の単一リージョンの単一仮想プライベートクラウド (VPC)、およびDR用の2つ目のリージョン + サーバー間のレイテンシーを低く抑えるための単一のアベイラビリティーゾーン + ネットワークトラフィックを分散して、複数のアベイラビリティーゾーンにわたるアプリケーションのスケーラビリティと可用性を向上させる Application Load Balancer + ドメインネームシステム (DNS) 構成を提供する Amazon Route 53 + Amazon WorkSpaces は、ユーザーにクラウドによるデスクトップエクスペリエンスを提供します + バックアップ、ファイル、オブジェクトを保存するための Amazon Simple Storage Service (Amazon S3) + Amazon CloudWatch を使用したアプリケーションのロギング、モニタリング、およびアラーム + ディザスタリカバリのための Amazon Elastic Disaster Recovery **ターゲットアーキテクチャ** 次の図は、Elastic Disaster Recoveryを使用した JD Edwards EnterpriseOne のクロスリージョンディザスタリカバリアーキテクチャを示しています。 ![\[AWS を使用した JD Edwards EnterpriseOneのクロスリージョン DR のアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9b0de5f0-f211-4086-a044-321d081604f9/images/978b7219-e54e-4e31-b3ff-4885784e2971.png) **手順** ここでは、プロセスの概要を示します。詳細については、「*エピック*」セクションを参照ください。 + Elastic Disaster Recovery のレプリケーションは、初回同期から開始します。初回同期中に、AWS Replication Agent はソースディスクのすべてのデータをステージングエリアサブネット内の適切なリソースに複製します。 + 連続レプリケーションは、初回同期が完了した後も無期限に継続されます。 + エージェントをインストールしてレプリケーションを開始したら、サービス固有の構成と Amazon EC2 起動テンプレートを含む起動パラメータを確認します。ソースサーバーがリカバリ準備完了と表示されたら、インスタンスを起動できます。 + Elastic Disaster Recovery が起動操作を開始するために一連の API 呼び出しを発行すると、リカバリインスタンスが起動設定に従ってすぐに AWS で起動されます。このサービスはスタートアップ時に自動的に変換サーバーをスピンアップします。 + 変換が完了して使用できる状態になると、新しいインスタンスが AWS でスピンアップされます。起動時のソースサーバーの状態は、起動したインスタンスに関連付けられたボリュームによって表されます。変換プロセスでは、インスタンスが AWS でネイティブに起動するように、ドライバ、ネットワーク、オペレーティングシステムのライセンスを変更します。 + 起動後、新しく作成されたボリュームはソースサーバーと同期されなくなります。AWS Replication Agent は、引き続きソースサーバーへの変更をステージングエリアボリュームに定期的に複製しますが、起動されたインスタンスにはそれらの変更は反映されません。 + 新しいドリルインスタンスまたはリカバリインスタンスを開始すると、データは常にソースサーバーからステージングエリアのサブネットに複製された最新の状態に反映されます。 + ソースサーバーがリカバリ準備完了と表示されたら、インスタンスを起動できます。 **注記** このプロセスは、プライマリ AWS リージョンから DR リージョンへのフェイルオーバー用と、リカバリ後のプライマリサイトへのフェイルバック用の、両方の方法で機能します。完全にオーケストレーションされた方法で、ターゲットマシンからソースマシンへのデータレプリケーションの方向を逆転させることで、フェイルバックに備えることができます。 このパターンで説明されているプロセスの利点には次のようなものがあります。 + 柔軟性: レプリケーションサーバーは、データセットとレプリケーション時間に基づいてスケールアウトとスケールインを行うため、ソースワークロードやレプリケーションを中断することなく DR テストを実行できます。 + 信頼性: レプリケーションは堅牢で、無停止で、継続的です。 + 自動化: このソリューションでは、テスト、リカバリ、フェイルバックのための統一された自動化プロセスを実現します。 + コストの最適化: 必要なボリュームだけを複製して料金を支払い、DR サイトのコンピュートリソースの料金が発生するのは、それらのリソースが有効化された場合のみです。コスト最適化レプリケーションインスタンス (コンピューティング最適化インスタンスタイプの使用を推奨) は、複数のソース、または大きな EBS ボリュームを持つ単一のソースに使用できます。 **自動化とスケール** 大規模にディザスタリカバリを実行すると、JD Edwards EnterpriseOne サーバは環境内の他のサーバに依存することになります。例えば、次のようになります。 + 起動時に JD Edwards EnterpriseOne がサポートするデータベースに接続する JD Edwards EnterpriseOne アプリケーションサーバーは、そのデータベースに依存しています。 + 認証が必要で、起動時にドメインコントローラーに接続してサービスを開始する必要がある JD Edwards EnterpriseOne サーバーは、ドメインコントローラーに依存しています。 この理由から、フェイルオーバータスクを自動化することをお勧めします。たとえば、AWS Lambda または AWS Step Functions を使用して JD Edwards EnterpriseOne のスタートアップスクリプトとロードバランサーの変更を自動化することで、エンドツーエンドのフェイルオーバープロセスを自動化できます。詳細については、ブログ記事「[ Elastic Disaster Recovery によるスケーラブルなディザスタリカバリ計画の作成](https://aws.amazon.com/blogs/storage/creating-a-scalable-disaster-recovery-plan-with-aws-elastic-disaster-recovery/)」を参照してください。 ## ツール ** サービス** + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) は、EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/products/compute/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [ Elastic Disaster Recovery ](https://aws.amazon.com/disaster-recovery/)は、手頃な価格のストレージ、最小限のコンピューティング、ポイントインタイムリカバリを使用して、オンプレミスおよびクラウドベースのアプリケーションを迅速かつ確実にリカバリすることで、ダウンタイムとデータ損失を最小限に抑えます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) では、リソースの配置、接続、セキュリティなど、仮想化ネットワーク環境を完全に制御できます。 ## ベストプラクティス **一般的なベストプラクティス** + 実際にリカバリイベントが発生した場合にどうするかについて、書面による計画を立ててください。 + Elastic Disaster Recoveryを正しく構成した後、必要に応じてオンデマンドで構成を作成できる AWS CloudFormation テンプレートを作成します。サーバーとアプリケーションを起動する順序を決定し、リカバリ計画に記録します。 + 定期的にドリルを実施してください (Amazon EC2 の標準料金が適用されます)。 + Elastic Disaster Recovery コンソールまたはプログラムを使用して、進行中のレプリケーションの状態をモニタリングします。 + インスタンスを終了する前に、ポイントインタイムスナップショットを保護して確認してください。 + AWS Replication Agent をインストールするための IAM ロールを作成します。 + 実際の DR シナリオでリカバリインスタンスの終了保護を有効にします。 + 実際にリカバリイベントが発生した場合でも、リカバリインスタンスを起動したサーバーに対して Elastic Disaster Recovery コンソールの [** との接続解除**] アクションを使用しないでください。接続解除を実行すると、ポイントインタイム (PIT) リカバリポイントを含む、これらのソースサーバーに関連するすべてのレプリケーションリソースが終了します。 + PIT ポリシーを変更して、スナップショットの保存日数を変更します。 + Elastic Disaster Recovery 起動設定の起動テンプレートを編集して、ターゲットサーバーの正しいサブネット、セキュリティグループ、インスタンスタイプを設定します。 + Lambda または Step 関数を使用して JD Edwards EnterpriseOne のスタートアップスクリプトとロードバランサーの変更を自動化することで、エンドツーエンドのフェイルオーバープロセスを自動化します。 **JD Edwards EnterpriseOne の最適化と考慮事項** + **PrintQueue** をデータベースに移動します。 + **MediaObjects** をデータベースに移動します。 + ログと temp フォルダーをバッチサーバーとロジックサーバーから除外します。 + Oracle WebLogic から temp フォルダを除外します。 + フェイルオーバー後のスタートアップスクリプトを作成します。 + SQL Server 用の tempdb を除外します。 + Oracle 用の temp ファイルを除外します。 ## エピック ### 初期タスクと構成を行う | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レプリケーションネットワークをセットアップする。 | JD Edwards EnterpriseOne システムをプライマリ AWS リージョンに実装し、DR 用の AWS リージョンを特定します。「Elastic Disaster Recovery ドキュメント」の「[レプリケーションネットワーク要件](https://docs.aws.amazon.com/drs/latest/userguide/preparing-environments.html)」セクションの手順に従って、レプリケーションと DR ネットワークの計画と設定を行います。 | AWS 管理者 | | RPO と RTO を決定します。 | アプリケーションサーバーとデータベースの目標復旧時間 (RTO) と目標復旧時点 (RPO) を特定します。 | クラウドアーキテクト、DR アーキテクト | | Amazon EFS のレプリケーションを有効にします。 | 該当する場合は、AWS DataSync、**rsync**、またはその他の適切なツールを使用して、Amazon Elastic File System (Amazon EFS) などの共有ファイルシステムの AWS プライマリから DR リージョンへのレプリケーションを有効にします。 | クラウド管理者 | | DR が発生した場合は DNS を管理する。 | DRドリルまたは実際のDR中にドメインネームシステム (DNS) を更新するプロセスを特定します。 | クラウド管理者 | | 設定用の IAM ロールを作成します。 | 「Elastic Disaster Recovery ドキュメント」の「[Elastic Disaster Recovery の初期化と権限](https://docs.aws.amazon.com/drs/latest/userguide/getting-started-initializing.html)」セクションの指示に従って、AWS サービスを初期化および管理するための IAM ロールを作成します。 | クラウド管理者 | | VPC ピアリングのセットアップ | ソース VPC とターゲット VPC がピアリングされ、相互にアクセス可能であることを確認します。構成手順については、[Amazon VPC のドキュメント](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)を参照してください。 | AWS 管理者 | ### Elastic Disaster Recovery レプリケーション設定の構成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Elastic Disaster Recovery を初期化します。 | [Elastic Disaster Recovery コンソール](https://console.aws.amazon.com/drs/home)を開き、ターゲット AWS リージョン (データをレプリケートしてリカバリインスタンスを起動する場所) を選択してから、[**デフォルトのレプリケーション設定の設定**] を選択します。 | AWS 管理者 | | レプリケーションサーバーをセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html) | AWS 管理者 | | ボリュームとセキュリティグループを構成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html) | AWS 管理者 | | その他のブローカーを構成する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html) | AWS 管理者 | ### AWS レプリケーションエージェントをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールを作成します。 | `AWSElasticDisasterRecoveryAgentInstallationPolicy` ポリシーを含む IAM ロールを作成します。**[Select AWS access type]** セクションで、[Programmatic Access] を選択します。アクセスキー ID とシークレットアクセスキーを書き留めます。この情報は、AWS Replication Agentのインストール時に必要になります。 | AWS 管理者 | | 要件を確認します。 | 「Elastic Disaster Recovery ドキュメント」に記載されている、AWS Replication Agent をインストールするための[前提条件](https://docs.aws.amazon.com/drs/latest/userguide/installation-requiremets.html)を確認して完了してください。 | AWS 管理者 | | AWS レプリケーションエージェントをインストールします。 | オペレーティングシステムの[インストール手順](https://docs.aws.amazon.com/drs/latest/userguide/agent-installation-instructions.html)に従い、AWS Replication Agent をインストールします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)残りのサーバーについても同様のステップを繰り返します。 | AWS 管理者 | | レプリケーションをモニタリングします。 | Elastic Disaster Recovery の**ソースサーバー**ペインに戻り、レプリケーションの状態をモニタリングします。データ転送のサイズによっては、初回同期に時間がかかります。ソースサーバーが完全に同期されると、サーバーの状態は [**準備完了**] に更新されます。つまり、ステージングエリアにレプリケーションサーバーが作成され、EBS ボリュームがソースサーバーからステージングエリアにレプリケートされたことを意味します。 | AWS 管理者 | ### 起動設定の構成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 起動設定を編集します。 | ドリルインスタンスとリカバリインスタンスの起動設定を更新するには、[Elastic Disaster Recovery コンソール](https://console.aws.amazon.com/drs/home)でソースサーバーを選択し、[**アクション**]、[**起動設定の編集**] を選択します。または、**ソースサーバー**ページでソースマシンを選択し、次に [**起動設定**] タブを選択することもできます。このタブには、[**一般起動設定**] と [**EC2 起動テンプレート**] の 2 つのセクションがあります。 | AWS 管理者 | | 一般起動構成を行います。 | 要件に応じて、一般起動設定を修正します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)詳細については、「Elastic Disaster Recovery ドキュメント」の「[一般起動設定](https://docs.aws.amazon.com/drs/latest/userguide/launch-general-settings.html)」を参照してください。 | AWS 管理者 | | Amazon EC2 起動テンプレートを構成します。 | Elastic Disaster Recovery は、Amazon EC2 起動テンプレートを使用して、各ソースサーバーのドリルインスタンスとリカバリインスタンスを起動します。起動テンプレートは、AWS Replication Agent のインストール後、Elastic Disaster Recovery に追加するソースサーバーごとに自動的に作成されます。Elastic Disaster Recovery で使用する場合は、Amazon EC2 起動テンプレートをデフォルトの起動テンプレートとして設定する必要があります。詳細については、「Elastic Disaster Recovery ドキュメント」の「[EC2 起動テンプレート](https://docs.aws.amazon.com/drs/latest/userguide/ec2-launch.html)」を参照してください。 | AWS 管理者 | ### DR ドリルとフェイルオーバーの開始 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ドリルを開始する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)詳細については、「Elastic Disaster Recovery ドキュメント」の「[フェイルオーバーの準備](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)」を参照してください。 | AWS 管理者 | | ドリルを検証します。 | 前のステップでは、DR リージョンで新しいターゲットインスタンスを起動しました。ターゲットインスタンスは、起動を開始したときに作成されたスナップショットに基づくソースサーバーのレプリカです。この手順では、Amazon EC2 ターゲットマシンに接続して、想定どおりに動作していることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html) | | | フェイルオーバーを開始します。 | フェイルオーバーとは、プライマリシステムからセカンダリシステムにトラフィックをリダイレクトすることです。Elastic Disaster Recovery は、AWS でリカバリインスタンスを起動することでフェイルオーバーを実行するのに役立ちます。リカバリインスタンスが起動したら、プライマリシステムからのトラフィックをこれらのインスタンスにリダイレクトします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)詳細については、「Elastic Disaster Recovery ドキュメント」の「[フェイルオーバーの実行](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing-failover.html)」を参照してください。 | AWS 管理者 | | フェイルバックを開始します。 | フェイルバックを開始するプロセスは、フェイルオーバーを開始するプロセスと似ています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)詳細については、「Elastic Disaster Recovery ドキュメント」の「[フェイルバックの実行](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html)」を参照してください。 | AWS 管理者 | | JD Edwards EnterpriseOne コンポーネントを起動する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-oracle-jd-edwards-enterpriseone-with-aws-elastic-disaster-recovery.html)JD Edwards EnterpriseOne リンクが機能するためには、Route 53 とApplication Load Balancer の変更を組み込む必要があります。これらのステップは、Lambda、Step Functions、およびSystems Manager (Run Command) を使用して自動化できます。Elastic Disaster Recovery は、オペレーティングシステムとファイルシステムをホストするソース EC2 インスタンス EBS ボリュームのブロックレベルのレプリケーションを実行します。Amazon EFS を使用して作成された共有ファイルシステムは、このレプリケーションには含まれません。最初のエピックで説明したように、AWS DataSync を使用して共有ファイルシステムを DR リージョンに複製し、その複製されたファイルシステムを DR システムにマウントできます。 | JD Edwards EnterpriseOne CNC | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ソースサーバーのデータレプリケーションステータスが [**停止**] で、複製が遅延している。詳細を確認すると、データレプリケーションステータスには[**エージェントが見つかりません**] と表示される。 | 停止したソースサーバーが稼働中であることを確認してください。ソースサーバーがダウンすると、レプリケーションサーバーは自動的に終了します。遅延の問題については、「Elastic Disaster Recovery ドキュメント」の「[レプリケーション遅延の問題](https://docs.aws.amazon.com/drs/latest/userguide/Other-Troubleshooting-Topics.html#Replication-Lag-Issues)」を参照してください。 | | RHEL 8.2 でソース EC2 インスタンスに AWS Replication Agent をインストールしようとしたら、ディスクのスキャン後に失敗した。`aws_replication_agent_installer.log` を確認すると、カーネルヘッダーが見当たらないことがわかった。 | RHEL 8、CentOS 8、または Oracle Linux 8 に AWS Replication Agent をインストールする前に、以下を実行してください。
sudo yum install elfutils-libelf-devel
詳細については、「Elastic Disaster Recovery ドキュメント」の「[Linux のインストール要件](https://docs.aws.amazon.com/mgn/latest/ug/installation-requirements.html#linux-requirements)」を参照してください。 | | Elastic Disaster Recovery コンソールで、ソースサーバーが [**準備完了**] となって遅延し、データレプリケーションのステータスが [**停止中**] と表示される。AWS Replication Agent が使用できない時間によっては、ステータスに大きな遅延と表示される場合があるが、問題は変わらない。 | オペレーティングシステムコマンドを使用して、AWS Replication Agent がソース EC2 インスタンスで実行されていること、またはインスタンスが実行中であることを確認します。問題を修正すると、Elastic Disaster Recovery はスキャンを再開します。すべてのデータが同期され、レプリケーションステータスが [**正常**] になるまで待ってから DR ドリルを開始してください。 | | 初回のレプリケーションで大きい遅延が発生する。Elastic Disaster Recovery コンソールを見ると、ソースサーバーの初回同期ステータスが非常に遅い。 | 「Elastic Disaster Recovery ドキュメント」の「[レプリケーション遅延の問題](https://docs.aws.amazon.com/drs/latest/userguide/Other-Troubleshooting-Topics.html#Replication-Lag-Issues)」セクションに記載されているレプリケーション遅延の問題を確認してください。レプリケーションサーバーは、組み込み関数が原因で負荷を処理できない場合があります。その場合は、[AWS テクニカルサポートチーム](https://support.console.aws.amazon.com/support/)に相談した上でインスタンスタイプをアップグレードしてみてください。 | ## 関連リソース + [ Elastic Disaster Recoveryユーザーガイド](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) + [ Elastic Disaster Recovery によるスケーラブルなディザスタリカバリ計画の作成](https://aws.amazon.com/blogs/storage/creating-a-scalable-disaster-recovery-plan-with-aws-elastic-disaster-recovery/) (AWS ブログ記事) + [ Elastic Disaster Recovery - 技術入門](https://explore.skillbuilder.aws/learn/course/internal/view/elearning/11123/aws-elastic-disaster-recovery-a-technical-introduction) (AWS スキルビルダーコース、ログインが必要) + [ Elastic Disaster Recovery クイックスタートガイド](https://docs.aws.amazon.com/drs/latest/userguide/quick-start-guide-gs.html) # マルチリージョン、マルチアカウント組織で CloudFormation ドリフト検出を設定する *Amazon Web Services、Ram Kandaswamy* ## 概要 Amazon Web Services (AWS) ユーザーは、 AWS CloudFormation スタックのドリフトなど、リソース設定の不一致を効率的に検出し、できるだけ早く修正する方法を探すことがよくあります。これは、 AWS Control Tower が使用される場合に特に当てはまります。 このパターンは、統合されたリソース設定を変更し、結果に基づいて、問題を効率的に解決する規範的なソリューションを提供します。このソリューションは、複数の 、複数の アカウント AWS リージョン、またはその両方の組み合わせに複数の CloudFormation スタックが作成されるシナリオ向けに設計されています。このソリューションの目標は以下のとおりです。 + ドリフト検出プロセスを簡素化する + 通知と警告を設定する + 統合レポートを設定する ## 前提条件と制限事項 **前提条件** + AWS Config モニタリングする必要があるすべてのリージョンとアカウントで有効になっている **制限事項** + 生成されるレポートは、カンマ区切り値 (CSV) と JSON 出力形式のみをサポートします。 ## アーキテクチャ 次の図は、複数の accounts. AWS Config rules で AWS Organizations 設定されたアカウント間の通信を示しています。  ![\[2 つの AWS Organizations アカウントのスタックをモニタリングするための 5 段階のプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/735d0987-b953-47f8-a9bc-b02a88957ee5/images/340cee9a-5a4e-49ea-bd73-d37dcea5e098.png) このワークフローには以下のステップが含まれます。 1. AWS Config ルールはドリフトを検出します。 1. 他のアカウントで見つかったドリフト検出結果は管理アカウントに送信されます。 1. Amazon CloudWatch ルールは AWS Lambda 関数を呼び出します。 1. Lambda 関数は、集計結果について AWS Config ルールをクエリします。 1. Lambda 関数は、ドリフトの E メール通知を送信する Amazon Simple Notification Service (Amazon SNS) に通知します。 **自動化とスケール** ここで紹介するソリューションは、追加のリージョンとアカウントの両方に合わせてスケールできます。 ## ツール **AWS のサービス** + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) は、 内の AWS リソースの設定の詳細ビューを提供します AWS アカウント。これには、リソース間の関係と設定の履歴が含まれるため、時間の経過と共に設定と関係がどのように変わるかを確認できます。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行するアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 ## エピック ### のドリフト検出を自動化する CloudFormation | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アグリゲータを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-aws-cloudformation-drift-detection-in-a-multi-region-multi-account-organization.html) | クラウドアーキテクト | | AWS マネージドルールを作成します。 | `cloudformation-stack-drift-detection-check` AWS****マネージドルールを追加します。このルールには `cloudformationArn` のパラメータ値が必要です。スタックのドリフトを検出する権限を持つ IAM ロールの Amazon リソースネーム (ARN) です。ロールには、 がロールを引き受け AWS Config ることができる信頼ポリシーが必要です。 | クラウドアーキテクト | | アグリゲータの詳細なクエリセクションを作成します。 | 以下のクエリを作成して、複数のソースからドリフトスタックを取得できます。
SELECT resourceId, configuration.driftInformation.stackDriftStatus WHERE resourceType = 'AWS::CloudFormation::Stack'  AND configuration.driftInformation.stackDriftStatus IN ('DRIFTED')
| クラウドアーキテクト、開発者 | | クエリとパブリッシュを自動化します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-aws-cloudformation-drift-detection-in-a-multi-region-multi-account-organization.html) | クラウドアーキテクト、開発者 | | CloudWatch ルールを作成します。 | スケジュールベースの CloudWatch ルールを作成して、アラートを行う Lambda 関数を呼び出します。 | クラウドアーキテクト | ## 関連リソース **リソース** + [AWS Configとは](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) + 「[マルチアカウント、マルチリージョンのデータ集計](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)」 + 「[スタックとリソースに対するアンマネージド型構成変更の検出](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)」 + [IAM: IAM ロールを特定の に渡す AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) + 「[Amazon SNS とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」 ## 追加情報 **考慮事項** 各 CloudFormation スタックまたはスタックセットでドリフト検出を開始するためには、特定の間隔で API コールを含むカスタムソリューションを使用するのではなく、このパターンで示されているソリューションを使用することをお勧めします。特定の間隔で API コールを使用するカスタムソリューションを使用すると、多数の API コールが発生してパフォーマンスに影響を与える可能性があります。API コールの数が多いと、スロットリングが発生する可能性があります。もう 1 つの潜在的な問題として、リソースの変更をスケジュールのみに基づいて特定すると、検出に遅延が発生します。 スタックセットはスタックで構成されているため、このソリューションを使用できます。スタックインスタンスの詳細は、ソリューションの一部としても入手できます。 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/735d0987-b953-47f8-a9bc-b02a88957ee5/attachments/attachment.zip)」 # S3 バケットを AWS CloudFormation スタックとして正常にインポートしました *Amazon Web Services、Ram Kandaswamy* ## 概要 Amazon Simple Storage Service (Amazon S3) バケットなどのAmazon Web Services (AWS) リソースを使用し、コードとしての infrastructure as code (IaC) アプローチを使用したい場合は、リソースを AWS CloudFormation にインポートしてスタックとして管理できます。 このパターンは、S3 バケットを AWS CloudFormation スタックとして正常にインポートするための手順を示しています。このパターンの方法を使用すると、S3 バケットを 1 回のアクションでインポートした場合に発生する可能性のあるエラーを回避できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + 既存の S3 バケットおよび S3 バケットポリシー。この詳細については、「[AWS ナレッジセンターの AWS Config ルール s3-bucket-ssl-requests-only に準拠するために、どのような S3 バケットポリシーを使用すべきか](https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-policy-for-config-rule/)」を参照してください。 + 既存の AWS Key Management Service (AWS KMS) キーとそのエイリアス。詳細については、AWS KMS ドキュメント「[アラートの操作](https://docs.aws.amazon.com/kms/latest/developerguide/programming-aliases.html)」を参照してください。 + サンプル `CloudFormation-template-S3-bucket` AWS CloudFormation テンプレート (添付)。お使いのコンピュータにダウンロードされます。 ## アーキテクチャ ![\[CloudFormation テンプレートを使用して S3 バケットをインポートする CloudFormation スタックを作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/aea7f6fe-8e67-46c4-8b90-1ab06b879111/images/ee143374-a0a4-42d9-b7ca-16593a597a84.png) この図表は、次のワークフローを示しています: 1. ユーザーは JSON 形式または YAML 形式の AWS CloudFormation テンプレートを作成します。 1. このテンプレートは、S3 バケットをインポートするための AWS CloudFormation スタックを作成します。 1. AWS CloudFormation スタックは、テンプレートで指定した S3 バケットを管理します。 テクノロジースタック + AWS CloudFormation + AWS Identity and Access Management (IAM) + AWS KMS + Amazon S3 **ツール** + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」— AWS CloudFormation は、AWS インフラストラクチャのデプロイメントを予測可能かつ繰り返し作成し、プロビジョニングするのに役立ちます。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」— IAM は、AWS サービスへのアクセスをセキュアに制御するためのウェブサービスです。 + 「[AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)」— AWS Key Management Service (AWS KMS) は、クラウド向けに拡張された暗号化およびキー管理サービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。 ## エピック ### AWS KMS keyベースの暗号化を使用して S3 バケットを AWS CloudFormation スタックとしてインポートする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットと KMS キーをインポートするテンプレートを作成します。 | ローカルコンピュータで、以下のサンプルテンプレートを使用して S3 バケットと KMS キーをインポートするテンプレートを作成します。
AWSTemplateFormatVersion: 2010-09-09

Parameters:

  bucketName:

    Type: String

Resources:

  S3Bucket:

    Type: 'AWS::S3::Bucket'

    DeletionPolicy: Retain

    Properties:

      BucketName: !Ref bucketName

      BucketEncryption:

        ServerSideEncryptionConfiguration:

          - ServerSideEncryptionByDefault:

              SSEAlgorithm: 'aws:kms'

              KMSMasterKeyID: !GetAtt 

                - KMSS3Encryption

                - Arn

  KMSS3Encryption:

    Type: 'AWS::KMS::Key'

    DeletionPolicy: Retain

    Properties:

      Enabled: true

      KeyPolicy: !Sub |-

        {

            "Id": "key-consolepolicy-3",

            "Version": "2012-10-17",		 	 	 

            "Statement": [

                {

                    "Sid": "Enable IAM User Permissions",

                    "Effect": "Allow",

                    "Principal": {

                        "AWS": ["arn:aws:iam::${AWS::AccountId}:root"]

                    },

                    "Action": "kms:*",

                    "Resource": "*"

                }

                }

            ]

        }

      EnableKeyRotation: true
| AWS DevOps | | スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.html) | AWS DevOps | | KMS キーエイリアスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.html)
KMSS3EncryptionAlias:

    Type: 'AWS::KMS::Alias'

    DeletionPolicy: Retain

    Properties: 

    AliasName: alias/S3BucketKey

    TargetKeyId: !Ref KMSS3Encryption
これに関する詳細については、AWS CloudFormation ドキュメントの「[AWS CloudFormation スタックの更新](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks.html)」を参照してください。  | AWS DevOps | | S3 バケットポリシーを含むようにスタックを更新する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.html)
S3BucketPolicy:

  Type: 'AWS::S3::BucketPolicy'

  Properties:

    Bucket: !Ref S3Bucket

    PolicyDocument: !Sub |-

      {

                  "Version": "2008-10-17",		 	 	 

                  "Id": "restricthttp",

                  "Statement": [

                      {

                          "Sid": "denyhttp",

                          "Effect": "Deny",

                          "Principal": {

                              "AWS": "*"

                          },

                          "Action": "s3:*",

                          "Resource": ["arn:aws:s3:::${S3Bucket}","arn:aws:s3:::${S3Bucket}/*"],

                          "Condition": {

                              "Bool": {

                                  "aws:SecureTransport": "false"

                              }

                          }

                      }

                  ]

              }
この S3 バケットポリシーには、安全ではない API コールを制限する拒否ステートメントがあります。  | AWS DevOps | | キーポリシーを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.html)詳細については、AWS KMS ドキュメントの「[AWS KMSのキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)」を参照してください。 | AWS 管理者 | | リソースレベルのタグを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/successfully-import-an-s3-bucket-as-an-aws-cloudformation-stack.html)
Tags:

  - Key: createdBy

    Value: Cloudformation
| AWS DevOps | ## 関連リソース + 「[既存のリソースを AWS CloudFormation の管理に取り込む](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import.html)」 + 「[AWS re: Invent 2017: AWS CloudFormation のディープダイブ](https://www.youtube.com/watch?v=01hy48R9Kr8)」(ビデオ) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/aea7f6fe-8e67-46c4-8b90-1ab06b879111/attachments/attachment.zip)」 # AWS DataSync を使用して、異なる AWS リージョンの Amazon EFS ファイルシステム間でデータを同期する *Amazon Web Services、Sarat Chandra Pothula、Aditya Ambati* ## 概要 このソリューションは、異なる AWS リージョンの Amazon Elastic File System (Amazon EFS) インスタンス間で、効率的かつ安全なデータ同期を実現する堅牢なフレームワークを提供します。このアプローチでは、スケーラブルで制御されたクロスリージョンデータレプリケーションを実現します。このソリューションでディザスタリカバリとデータ冗長化戦略を強化できます。 このパターンでは、AWS Cloud Development Kit (AWS CDK) を Infrastructure as Code (IaC) アプローチとして使用し、ソリューションリソースをデプロイします。AWS CDK アプリケーションは、重要な AWS DataSync、Amazon EFS、Amazon Virtual Private Cloud (Amazon VPC)、および Amazon Elastic Compute Cloud (Amazon EC2) リソースをデプロイします。この IaC は、AWS のベストプラクティスに沿った、反復可能でバージョン管理されたデプロイプロセスを提供します。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + AWS コマンドラインインターフェイス (AWS CLI) バージョン 2.9.11 以降が[インストール済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)および[設定済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) + AWS CDK バージョン 2.114.1 以降が[インストール済み](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install)および[ブートストラップ済み](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_bootstrap) + NodeJS バージョン 20.8.0 以降が[インストール済み](https://nodejs.org/en/download) **制限事項** + このソリューションは、データ転送速度、サイズ制限、リージョンの可用性など、DataSync と Amazon EFS の制限を継承します。詳細については、「[AWS DataSync quotas](https://docs.aws.amazon.com/datasync/latest/userguide/datasync-limits.html)」と「[「Amazon EFS のクォータ](https://docs.aws.amazon.com/efs/latest/ug/limits.html)」を参照してください。 + このソリューションは Amazon EFS のみをサポートします。DataSync は、Amazon Simple Storage Service (Amazon S3) や Amazon FSx for Lustre など[その他の AWS サービス](https://docs.aws.amazon.com/datasync/latest/userguide/working-with-locations.html)をサポートします。ただし、このソリューションでは、データを他のサービスと同期するために変更が必要です。 ## アーキテクチャ ![\[異なるリージョンの EFS ファイルシステムにデータをレプリケートするためのアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e28ba6c2-ab8b-4812-932e-f038106d5496/images/18b35ae9-a22e-43e7-b7a3-30e40321c44e.png) このソリューションでは、次の AWS CDK スタックをデプロイします。 + **Amazon VPC スタック** – このスタックは、プライマリ AWS リージョンとセカンダリ AWS リージョンの両方で、サブネット、インターネットゲートウェイ、NAT ゲートウェイを含む仮想プライベートクラウド (VPC) リソースを設定します。 + **Amazon EFS スタック** – このスタックは、Amazon EFS ファイルシステムをプライマリリージョンとセカンダリリージョンにデプロイし、それぞれの VPC に接続します。 + **Amazon EC2 スタック** – このスタックは、プライマリリージョンとセカンダリリージョンで EC2 インスタンスを起動します。これらのインスタンスは、共有ストレージへのアクセスを許可する Amazon EFS ファイルシステムをマウントするように設定されています。 + **DataSync ロケーションスタック** – このスタックは、`DataSyncLocationConstruct` というカスタムコンストラクトを使用して、プライマリリージョンとセカンダリリージョンで DataSync ロケーションリソースを作成します。これらのリソースは、データ同期のエンドポイントを定義します。 + **DataSync タスクスタック** – このスタックは、`DataSyncTaskConstruct` というカスタムコンストラクトを使用して、プライマリリージョンで DataSync タスクを作成します。このタスクは、DataSync の送信元と送信先の場所を使用してプライマリリージョンとセカンダリリージョン間でデータを同期するように設定されています。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + 「[AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)」は、ファイルまたはオブジェクトデータを AWS ストレージサービス間で移動したり、AWS ストレージサービス間で移動したりするのに役立つオンラインデータ転送および検出サービスです。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) は、AWS クラウドでの共有ファイルシステムの作成と設定に役立ちます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 **コードリポジトリ** このパターンのコードは、GitHub の「[Amazon EFS Cross-Region DataSync Project](https://github.com/aws-samples/aws-efs-crossregion-datasync/tree/main)」リポジトリにあります。 ## ベストプラクティス 「[TypeScript で AWS CDK を使用し、IaC プロジェクトを作成する際のベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/introduction.html)」で説明されているベストプラクティスに従ってください。 ## エピック ### AWS CDK アプリをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトリポジトリのクローンを作成します。 | 次のコマンドを入力して、「[Amazon EFS Cross-Region DataSync Project](https://github.com/aws-samples/aws-efs-crossregion-datasync/tree/main)」リポジトリのクローンを作成します。
git clone https://github.com/aws-samples/aws-efs-crossregion-datasync.git
| AWS DevOps | | npm の依存関係をインストールします。 | 次のコマンドを入力します。
npm ci
| AWS DevOps | | プライマリリージョンとセカンダリリージョンを選択します。 | クローン作成されたリポジトリで、`src/infa` ディレクトリに移動します。`Launcher.ts` ファイルで、`PRIMARY_AWS_REGION` と `SECONDARY_AWS_REGION` の値を更新します。対応する[リージョンコード](https://docs.aws.amazon.com/general/latest/gr/datasync.html#datasync-region)を使用します。
const primaryRegion = { account: account, region: '' };
const secondaryRegion = { account: account, region: '' };
| AWS DevOps | | 環境を開始する。 | 次のコマンドを入力して、使用する AWS アカウントと AWS リージョンをブートストラップします。
cdk bootstrap /
詳細については、AWS CDK ドキュメントの「[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。 | AWS DevOps | | AWS CDK スタックを一覧表示します。 | 次のコマンドを入力して、アプリ内の AWS CDK スタックのリストを表示します。
cdk ls
| AWS DevOps | | AWS CDK スタックを合成します。 | 次のコマンドを入力して、AWS CDK アプリで定義された各スタックの AWS CloudFormation テンプレートを生成します。
cdk synth
| AWS DevOps | | AWS CDK アプリをデプロイします。 | 次のコマンドを入力して、変更を手動で承認することなく、すべてのスタックを AWS アカウントにデプロイします。
cdk deploy --all --require-approval never
| AWS DevOps | ### デプロイを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリリージョンの EC2 インスタンスにログインします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/synchronize-data-between-amazon-efs-file-systems-in-different-aws-regions-by-using-aws-datasync.html) | AWS DevOps | | 一時ファイルを作成します。 | 次のコマンドを入力して、Amazon EFS マウントパスで一時ファイルを作成します。
sudo dd if=/dev/zero \
of=tmptst.dat \
bs=1G \
seek=5 \
count=0

ls -lrt tmptst.dat
| AWS DevOps | | DataSync タスクを開始します。 | 次のコマンドを入力して、プライマリリージョンからセカンダリリージョンに一時ファイルをレプリケートします。ここで、`` は DataSync タスクの Amazon リソースネーム (ARN) です。
aws datasync start-task-execution \
    --task-arn
コマンドは、タスク実行の ARN を次の形式で返します。`arn:aws:datasync:::task/task-execution/` | AWS DevOps | | データ転送のステータスを確認します。 | 次のコマンドを入力して、DataSync 実行タスクを記述します。ここで、`` はタスク実行の ARN です。
aws datasync describe-task-execution \
    --task-execution-arn
DataSync タスクは、`PrepareStatus`、`TransferStatus`、`VerifyStatus` すべての値が `SUCCESS` になると完了します。 | AWS DevOps | | セカンダリリージョンの EC2 インスタンスにログインします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/synchronize-data-between-amazon-efs-file-systems-in-different-aws-regions-by-using-aws-datasync.html) | AWS DevOps | | アプリケーションを検証します。 | 次のコマンドを入力して、一時ファイルが Amazon EFS ファイルシステムに存在することを確認します。
ls -lrt
tmptst.dat
| AWS DevOps | ## 関連リソース **AWS ドキュメント** + [AWS CDK API リファレンス](https://docs.aws.amazon.com/cdk/api/v2/python/modules.html) + [Amazon EFS による AWS DataSync 転送の設定](https://docs.aws.amazon.com/datasync/latest/userguide/create-efs-location.html) + [AWS DataSync 転送に関する問題のトラブルシューティング](https://docs.aws.amazon.com/datasync/latest/userguide/troubleshooting-datasync-locations-tasks.html) **その他の AWS リソース** + [AWS DataSync のよくある質問](https://aws.amazon.com/datasync/faqs/) # LocalStack および Terraform テストを使用して AWS インフラストラクチャをテストする *Amazon Web Services、Ivan Girardi、Ioannis Kalyvas* ## 概要 このパターンは、 AWS 環境にインフラストラクチャをプロビジョニングすることなく、Terraform AWS で のInfrastructure as Code (IaC) をローカルでテストするのに役立ちます。[Terraform Tests フレームワーク](https://developer.hashicorp.com/terraform/language/tests)を [LocalStack](https://github.com/localstack/localstack) と統合します。LocalStack Docker コンテナは、さまざまな AWS のサービスをエミュレートするローカル開発環境を提供します。これにより、 AWS クラウドでコストを発生させることなく、インフラストラクチャのデプロイをテストして反復処理できます。 ソリューションは次の利点があります。 + **コストの最適化** – LocalStack に対してテストを実行すると、 AWS のサービスを使用する必要がなくなります。これにより、これらの AWS リソースの作成、運用、変更に関連するコストが発生するのを防ぐことができます。 + **速度と効率** – 通常、ローカルでのテストは AWS リソースのデプロイよりも高速です。この迅速なフィードバックループにより、開発とデバッグが高速化されます。LocalStack はローカルで実行されるため、インターネット接続なしで Terraform 設定ファイルを開発およびテストできます。Terraform 設定ファイルをローカルでデバッグし、すぐにフィードバックを受け取ることができるため、開発プロセスが効率化されます。 + **一貫性と再現性** – LocalStack は、テストのために一貫した環境を提供します。この整合性により、外部 AWS の変更やネットワークの問題に関係なく、テストで同じ結果が得られるようになります。 + **分離 **– LocalStack によるテストにより、ライブ AWS リソースや本番環境に誤って影響することを防ぐことができます。この分離により、さまざまな設定を安全に実験およびテストできます。 + **自動化** – 継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとの統合により、Terraform [設定ファイル](https://developer.hashicorp.com/terraform/language/files)を自動的にテストできます。パイプラインは、デプロイ前に IaC を徹底的にテストします。 + **柔軟性** – さまざまな および のサービス設定をシミュレートして AWS リージョン AWS アカウント、本番稼働環境により近いものにすることができます。 ## 前提条件と制限 **前提条件** + [Docker をインストールする](https://docs.docker.com/get-started/get-docker/) + デフォルトの Docker ソケット (`/var/run/docker.sock`) への[アクセスを有効](https://docs.docker.com/reference/cli/dockerd/#daemon-socket-option)にします。詳細については、[LocalStack のドキュメント](https://docs.localstack.cloud/user-guide/aws/lambda/#migrating-to-lambda-v2)を参照してください。 + Docker Compose を[インストール](https://docs.docker.com/compose/install/)する + Terraform バージョン 1.6.0 以降を[インストール](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)する + Terraform CLI を[インストール](https://developer.hashicorp.com/terraform/cli)する + Terraform AWS プロバイダー[を設定する](https://hashicorp.github.io/terraform-provider-aws/) + (オプション) AWS Command Line Interface () [をインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)して[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)しますAWS CLI。LocalStack AWS CLI で を使用する方法の例については、「LocalStack および Terraform Tests リポジトリを使用した GitHub Test インフラストラクチャ」を参照してください。 [AWS LocalStack ](https://github.com/aws-samples/localstack-terraform-test) **制限事項** + このパターンでは、Amazon Simple Storage Service (Amazon S3) AWS Lambda、 AWS Step Functions、および Amazon DynamoDB リソースをテストするための明示的な例を示します。ただし、このソリューションを拡張して追加の AWS リソースを含めることができます。 + このパターンでは、Terraform Tests をローカルで実行する手順を示しますが、任意の CI/CD パイプラインにテストを統合できます。 + このパターンでは、LocalStack Community イメージを使用する手順を示します。LocalStack Pro イメージを使用している場合は、[LocalStack Pro のドキュメント](https://hub.docker.com/r/localstack/localstack-pro)を参照してください。 + LocalStack は、さまざまな AWS APIs。完全なリストについては、[AWS サービス機能のカバレッジ](https://docs.localstack.cloud/user-guide/aws/feature-coverage/)を参照してください。一部の高度な機能では、LocalStack Pro のサブスクリプションが必要になる場合があります。 ## アーキテクチャ このソリューション用のアーキテクチャを次の図に示します。主要コンポーネントは、ソースコードリポジトリ、CI/CD パイプライン、および LocalStack Docker コンテナです。LocalStack Docker コンテナは、以下を AWS のサービス ローカルでホストします。 + ファイルを保存するための Amazon S3 バケット + モニタリングおよびログ記録用の Amazon CloudWatch + サーバーレスコードを実行するための AWS Lambda 関数 + マルチステップワークフローをオーケストレーションするための AWS Step Functions ステートマシン + NoSQL データを保存するための Amazon DynamoDB テーブル ![\[CI/CD パイプラインは、LocalStack Docker コンテナと AWS リソースを構築してテストします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/34bfbdbf-14e7-42a0-9022-c85a9c30cdcd/images/dc61fac9-b92c-4841-9132-ff8bb865eed9.png) この図表は、次のワークフローを示しています: 1. Terraform 設定ファイルをソースコードリポジトリに追加してコミットします。 1. CI/CD パイプラインが変更を検出し、Terraform の静的コード分析のビルドプロセスを開始します。パイプラインが LocalStack Docker コンテナを構築して実行します。その後、テストプロセスを開始します。 1. パイプラインが、LocalStack Docker コンテナでホストされている Amazon S3 バケットにオブジェクトをアップロードします。 1. オブジェクトをアップロードすると、 AWS Lambda 関数が呼び出されます。 1. Lambda 関数が、CloudWatch ログに Amazon S3 イベント通知を保存します。 1. Lambda 関数は AWS Step Functions ステートマシンを起動します。 1. ステートマシンが Amazon S3 オブジェクトの名前を DynamoDB テーブルに書き込みます。 1. CI/CD パイプラインのテストプロセスで、アップロードされたオブジェクトの名前が DynamoDB テーブルのエントリと一致することを確認します。また、S3 バケットが指定された名前でデプロイされ、 AWS Lambda 関数が正常にデプロイされたことも検証します。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行するアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意の量のデータを保存、保護、取得する上で役立つクラウドベースのオブジェクトストレージサービスです。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [Docker Compose](https://docs.docker.com/compose/) は、マルチコンテナアプリケーションを定義および実行するためのツールです。 + [LocalStack](https://localstack.cloud) は、単一のコンテナで実行されるクラウドサービスエミュレーターです。LocalStack を使用すると、 に接続せずに AWS のサービス、 を使用するローカルマシンでワークロードを実行できます AWS クラウド。 + [Terraform](https://www.terraform.io/) は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。 + [Terraform Tests](https://developer.hashicorp.com/terraform/language/tests) は、統合またはユニットテストに類似したテストを通じて Terraform モジュール設定の更新を検証するのに役立ちます。 **コードリポジトリ** このパターンのコードは、LocalStack および Terraform Tests リポジトリを使用した GitHub Test インフラストラクチャで使用できます。 [AWS LocalStack ](https://github.com/aws-samples/localstack-terraform-test) ## ベストプラクティス + このソリューションは、Terraform 設定ファイルで指定された AWS インフラストラクチャをテストし、それらのリソースを にデプロイしません AWS クラウド。リソースをデプロイする場合は、[最小特権の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) (IAM ドキュメント) に従い、[Terraform バックエンドを適切に設定](https://developer.hashicorp.com/terraform/language/backend) (Terraform ドキュメント) します。 + LocalStack を CI/CD パイプラインに統合する場合は、LocalStack Docker コンテナを特権モードで実行しないことをお勧めします。詳細については、[「Runtime privilege and Linux capabilities](https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities)」 (Docker ドキュメント) と[「Security for self-managed runners](https://docs.gitlab.com/runner/security/)」(GitLab ドキュメント) を参照してください。 ## エピック ### 解決策をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | bash シェルで、次のコマンドを入力します。これにより、GitHub から [ LocalStack および Terraform Tests リポジトリを使用してテスト AWS インフラストラクチャ](https://github.com/aws-samples/localstack-terraform-test)のクローンが作成されます。
git clone https://github.com/aws-samples/localstack-terraform-test.git
| DevOps エンジニア | | LocalStack コンテナを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/test-aws-infra-localstack-terraform.html) | DevOps エンジニア | | Terraform を初期化します。 | 次のコマンドを入力して、Terraform を初期化します。
terraform init
| DevOps エンジニア | | Terraform Tests を実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/test-aws-infra-localstack-terraform.html) | DevOps エンジニア | | リソースをクリーンアップします。 | 次のコマンドを入力して、LocalStack コンテナを破棄します。
docker-compose down
| DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `terraform test` コマンドを実行すると、`Error: reading DynamoDB Table Item (Files\|README.md): empty` になります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/test-aws-infra-localstack-terraform.html) | ## 関連リソース + [Terraform の開始方法: AWS CDK および AWS CloudFormation エキスパート向けガイダンス](https://docs.aws.amazon.com/prescriptive-guidance/latest/getting-started-terraform/introduction.html) (AWS 規範ガイダンス) + [Terraform AWS プロバイダーを使用するためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/terraform-aws-provider-best-practices/introduction.html) (AWS 規範ガイダンス) + [新しい Terraform Test Framework AWS を使用した Terraform CI/CD と でのテスト](https://aws.amazon.com/blogs/devops/terraform-ci-cd-and-testing-on-aws-with-the-new-terraform-test-framework/) (AWS ブログ記事) + [からの LocalStack Cloud Emulator を使用したソフトウェア配信の高速化 AWS Marketplace](https://aws.amazon.com/blogs/awsmarketplace/accelerating-software-delivery-localstack-cloud-emulator-aws-marketplace/) (AWS ブログ記事) ## 追加情報 **GitHub Actions との統合** GitHub Actions を使用して、LocalStack および Terraform Tests を CI/CD パイプラインに統合できます。詳細については、[GitHub Actions のドキュメント](https://docs.github.com/en/actions)を参照してください。以下は、サンプルの GitHub Actions 設定ファイルです。 ``` name: LocalStack Terraform Test on: push: branches: - '**' workflow_dispatch: {} jobs: localstack-terraform-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build and Start LocalStack Container run: | docker compose up -d - name: Setup Terraform uses: hashicorp/setup-terraform@v3 with: terraform_version: latest - name: Run Terraform Init and Validation run: | terraform init terraform validate terraform fmt --recursive --check terraform plan terraform show - name: Run Terraform Test run: | terraform test - name: Stop and Delete LocalStack Container if: always() run: docker compose down ``` # SAP ペースメーカークラスターを ENSA1 から ENSA2 にアップグレード *Amazon Web Services、Gergely Cserdi と Balazs Sandor Skublics* ## 概要 このパターンでは、スタンドアロンエンキューサーバー (ENSA1) に基づく SAP Pacemaker クラスターを ENSA2 にアップグレードする場合の手順と考慮事項を説明します。このパターンの情報は、SLES (SLES)Linux Enterprise Server (SLES) と Red Hat Enterprise Linux (RHEL) オペレーティングシステムの両方に適用されます。 SAP NetWeaver 7.52 または S/4HANA 1709 およびそれ以前のバージョンの Pacemaker クラスターは、ENSA1 アーキテクチャで動作し ENSA1 専用に設定されています。Amazon Web Services (AWS) で SAP ワークロードを実行して、ENSA2 への移行を検討している場合、SAP、SUSE、RHEL のドキュメントには包括的な情報が記載されていないことに気付くかもしれません。このパターンは、ENSA1 から ENSA2 にアップグレードするために SAP パラメータと Pacemaker クラスターを再設定するために必要な技術的ステップを説明します。SUSE システムの例を示していますが、RHEL クラスターでも概念は同じです。 **注記** ENSA1 と ENSA2 は SAP アプリケーションのみに関係する概念であるため、このパターンの情報は SAP HANA や他のタイプのクラスターには当てはまりません。 **注記** 技術的には、ENSA2 はエンキューレプリケーター 2 の有無にかかわらず使用できます。ただし、高可用性 (HA) と (クラスターソリューションによる) フェイルオーバー自動化には エンキューレプリケーター 2 が必要です。このパターンでは、*ENSA2 クラスター*という用語は、スタンドアロンエンキューサーバー 2 とエンキューレプリケーター 2 を備えたクラスターを指します。 ## 前提条件と制限事項 **前提条件** + SLES または RHEL の Pacemaker と Corosync を使用する、動作中の ENSA1 ベースのクラスターです。 + 少なくとも 2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスです。そこでは、(ABAP) SAP セントラルサービス (ASCS/SCS) インスタンスとエンキューレプリケーションサーバー (ERS) インスタンスが実行されています。 + SAP アプリケーションとクラスターの管理に関する知識です。 + ルートユーザーとして Linux 環境にアクセスします。 **機能制限** + ENSA1 ベースのクラスターに、2つのノードのアーキテクチャのみが適用されます。 + ENSA2 ベースのクラスターが、7.52 以前のバージョンの SAP NetWeaver にはデプロイされません。 + クラスターの EC2 インスタンスは、異なる AWS アベイラビリティーゾーンにある必要があります。 **製品バージョン** + SAP NetWeaver バージョン 7.52 以降 + S/4HANA 2020 以降では、ENSA2 クラスターのみが適用 + カーネル 7.53 以降では、ENSA2 とエンキューレプリケーター 2 に適用 + SAP アプリケーションバージョン 12 以降のSLES + ハイアベイラビリティ (HA) バージョン 7.9 以降の SAP 用 RHEL ## アーキテクチャ **ソーステクノロジースタック** + SAP カーネル 7.53 以降を搭載した SAP NetWeaver 7.52 + SLES または RHEL オペレーティングシステム **ターゲットテクノロジースタック** + SAP カーネル 7.53 以降を搭載した SAP NetWeaver 7.52 (ABAP プラットフォーム搭載の S/4HANA 2020 を含む) + SLES または RHEL オペレーティングシステム **ターゲットアーキテクチャ** 次の図表は、ENSA2 クラスターに基づく ASCS/SCS インスタンスと ERS インスタンスの HA 構成を示しています。 ![\[ENSA2 クラスターの ASCS/SCS インスタンスと ERS インスタンスの HA アーキテクチャー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c32560de-901f-4796-a6b3-c08c109b22c8/images/19501713-0ddf-4242-9ea3-90478200a19e.png) **ENSA1 クラスターと ENSA2 クラスターの比較** SAP は ENSA1 の後継として ENSA2 を導入しました。ENSA1 ベースのクラスターには、エラーが発生する場合、 ASCS/SCS インスタンスが ERS にフェイルオーバーする 2 ノードアーキテクチャが適用されます。この制限は、フェイルオーバー後に ASCS/SCS インスタンスが ERS ノードの共有メモリからロックテーブル情報を取り戻す方法によるものです。エンキューレプリケーター 2 を搭載した ENSA2 ベースのクラスターでは、ASCS/SCS インスタンスがネットワーク経由で ERS インスタンスからロック情報を収集できるため、この制限がなくなります。ASCS/SCS インスタンスは ERS ノードにフェイルオーバーする必要がなくなるため、ENSA2 ベースのクラスターは 3つ以上のノードを持つことができます。(ただし、2 ノードの ENSA2 クラスター環境では、ASCS/SCS インスタンスは ERS ノードにフェイルオーバーされます。クラスターに他にフェイルオーバーするノードがないためです。ENSA2 は SAP カーネル 7.50 以降に適用されますが、いくつかの制限があります。エンキューレプリケーター 2 が適用される HA セットアップの場合、最小要件は NetWeaver 7.52 です (「[SAP OSS ノート 2630416](https://launchpad.support.sap.com/#/notes/2630416)」 を参照)。S/4HANA 1809 にはデフォルトで推奨されている ENSA2 アーキテクチャが付属していますが、S/4HANA はバージョン 2020 以降には ENSA2 のみ適用されます。 **自動化とスケール** ターゲットアーキテクチャの HA クラスタにより、ASCS は他のノードに自動的にフェイルオーバーされます。 **ENSA2 ベースのクラスターに移動するシナリオ** ENSA2 ベースのクラスターへのアップグレードには、主に2つのシナリオがあります:  + シナリオ 1: SAP リリースとカーネルバージョンに ENSA2が適用されることを仮定して、SAP のアップグレードや S/4HANA の変換を伴わずに ENSA2 にアップグレードすることを選択します。 + シナリオ 2: SUM を使用して ENSA2 へのアップグレードまたは変換 (例えば、S/4HANA 1809 以降へ) の一環として移動します。 「[エピック](#upgrade-sap-pacemaker-clusters-from-ensa1-to-ensa2-epics)」 セクションでは、2つのシナリオのステップについて説明します。最初のシナリオでは、ENSA2 のクラスター構成を変更する前に SAP 関連のパラメータを手動で設定する必要があります。二つ目のシナリオでは、バイナリと SAP 関連のパラメータは SUM によってデプロイされます。残る作業は HA のクラスター構成を更新することだけです。SUM を使用した後にも SAP パラメータを検証することを推奨します。ほとんどの場合、S/4HANA 変換がクラスタアップグレードの主な理由です。 ## ツール + OS パッケージマネージャーには、Zypper (SLES の場合) または YUM (RHEL の場合) ツールを推奨します。 + クラスター管理には、**crm**(SLES の場合) または **pcs** (RHEL の場合) シェルを推奨します。 + SAPControl などの SAP インスタンス管理ツール。 + (オプション) S/4HANA 変換アップグレードの SUM ツール。 ## ベストプラクティス + AWS で SAP ワークロードを使用する際のベストプラクティスについては、AWS Well-Architected フレームワークの「[SAP Lens](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/sap-lens.html)」を参照してください。 + ENSA2 マルチノードアーキテクチャのクラスターノードの数 (奇数または偶数)を考慮します。 + SAP S/4-HA-CLU 1.0 認定基準に沿って、SLES 15 用の ENSA2 クラスターをセットアップします。 + ENSA2 にアップグレードする前に、必ず既存のクラスターとアプリケーションの状態を保存またはバックアップするようにします。 ## エピック ### ENSA2 の SAP パラメータを手動で設定する (シナリオ 1 のみ) | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デフォルトのプロファイルにパラメータを設定します。 | 同じ SAP リリースを保持しながら ENSA2 にアップグレードする場合や、ターゲットリリースのデフォルトが ENSA1 である場合、デフォルトプロファイル (DEFAULT.PFL ファイル) のパラメータを次の値に設定します。
enq/enable=TRUE
enq/serverhost=sapascsvirt
enq/serverinst=10        (instance number of ASCS/SCS instance)
enque/process_location=REMOTESA
enq/replicatorhost=sapersvirt
enq/replicatorinst=11    (instance number of ERS instance)
ここで、`sapascsvirt` が ASCS インスタンスの仮想ホスト名で、`sapersvirt` は ERS インスタンスの仮想ホスト名です。これらはターゲット環境に合わせて変更できます。このアップグレードオプションを使用するには、SAP リリースとカーネルバージョンが ENSA2 とエンキューレプリケーター 2 をサポートしている必要があります。 | SAP | | ASCS/SCS インスタンスプロファイルを設定します。 | 同じ SAP リリースを保持しながら ENSA2 にアップグレードする場合や、ターゲットリリースのデフォルトが ENSA1 である場合、ASCS/SCS インスタンスプロファイルに次のパラメータを設定します。 ENSA1 が定義されているプロファイルのセクションは以下のように表示されます。
#--------------------------------------------------------------
Start SAP enqueue server
#-------------------------------------------------------------- 
_EN = en.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) 
Execute_04 = local rm -f $(_EN) 
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enserver$(FT_EXE) $(_EN) 
Start_Program_01 = local $(_EN) pf=$(_PF)
このセクションを ENSA2 用に再設定するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/upgrade-sap-pacemaker-clusters-from-ensa1-to-ensa2.html)変更後、このプロファイルセクションは以下のように見えるでしょう。
#--------------------------------------------------------------
Start SAP enqueue server
#-------------------------------------------------------------- 
_ENQ = enq.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) 
Execute_04 = local rm -f $(_ENQ) 
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enq_server$(FT_EXE) $(_ENQ) 
Start_Program_01 = local $(_ENQ) pf=$(_PF) 
... 
enq/server/replication/enable = TRUE 
Autostart = 0
`_ENQ` は、再起動オプションを有効にしてはなりません。`RestartProgram_01` が `_ENQ` に設定されている場合、`StartProgram_01` に変更し これにより、SAP がサービスを再起動したり、クラスターが管理するリソースに干渉したりするのを防止します。 | SAP | | ERS プロファイルを設定します。 | 同じ SAP リリースを保持しながら ENSA2 にアップグレードする場合、またはターゲットリリースのデフォルトが ENSA1 である場合、次のパラメータを ERS インスタンスプロファイルに設定します。エンキューレプリケーターが定義されているセクションを見つけます。以下に似ているものになります。
#------------------------------------------------------
Start enqueue replication server
#------------------------------------------------------ 
_ER = er.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) 
Execute_03 = local rm -f $(_ER) 
Execute_04 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver$(FT_EXE) $(_ER) 
Start_Program_00 = local $(_ER) pf=$(_PF) NR=$(SCSID)
このセクションをエンキューレプリケーター 2 に再設定する場合：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/upgrade-sap-pacemaker-clusters-from-ensa1-to-ensa2.html)変更後、このプロファイルセクションは以下のように表示されます。
#------------------------------------------------------
Start enqueue replication server
#------------------------------------------------------ 
_ENQR = enqr.sap$(SAPSYSTEMNAME)$(INSTANCE_NAME) 
Execute_01 = local rm -f $(_ENQR) 
Execute_02 = local ln -s -f $(DIR_EXECUTABLE)/enq_replicator$(FT_EXE) $(_ENQR) 
Start_Program_00 = local $(_ENQR) pf=$(_PF) NR=$(SCSID) 
… 
Autostart = 0
`_ENQR` は、再起動オプションを有効にしてはなりません。`RestartProgram_01` が `_ENQR` に設定されている場合、`StartProgram_01`に変更します。これにより、SAP がサービスを再起動したり、クラスターが管理するサービスに干渉したりすることを防止します。 | SAP | | SAP スタートサービスを再起動します。 | このエピックで前述したプロファイルを変更した後に、ASCS/SCS と ERS の両方の SAP スタートサービスを再起動します。`sapcontrol -nr 10 -function RestartService SCT``sapcontrol -nr 11 -function RestartService SCT`ここで `SCT` は SAP システム ID を指し、ASCS/SCS インスタンスと ERS インスタンスのインスタンス番号がそれぞれ 10 と 11 であると仮定します。 | SAP | ### ENSA2 用にクラスターを再構成します (両方のシナリオも必要)。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SAP リソースエージェントのバージョン番号を検証します。 | SUM を使用して SAP を S/4HANA 1809 以降にアップグレードして、SUM は SAP プロファイルのパラメータ変更を処理します。クラスターのみが手動調整が必要です。ただし、クラスターを変更する前に、パラメータ設定を確認することを推奨します。このエピックの例は、SUSE オペレーティングシステムを使用していることが前提です。RHEL を使用する場合、Zypper や **crm** の代わりに YUM や **pcs** シェルなどのツールを使用する必要があります。アーキテクチャ内の両方のノードをチェックして、 `resource-agents` パッケージが SAP が推奨する最小バージョンと一致していることを確認します。SLES については、SAP OSS ノート 2641019 を確認します。RHEL については、SAP OSS ノート 2641322 を確認します。(SAP Notes では 「[SAP ONE サポートラウンチパッドのユーザーアカウント](https://support.sap.com/en/my-support/knowledge-base.html)」 が必要です。)
sapers:sctadm 23> zypper search -s -i resource-agents
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+-----------------+---------+------------------------------------+--------+-----------------------------
i | resource-agents | package | 4.8.0+git30.d0077df0-150300.8.28.1 | x86_64 | SLE-Product-HA15-SP3-Updates
必要に応じて、`resource-agents` バージョンを更新します。 | AWS システム管理者 | | クラスター設定をバックアップします。 | CRM クラスター構成を次のようにバックアップします。`crm configure show > /tmp/cluster_config_backup.txt` | AWS システム管理者 | | メンテナンスモードを設します。。 | クラスターをメンテナンスモードに設定します。`crm configure property maintenance-mode="true"` | AWS システム管理者 | | クラスター設定を確認します | 現在のクラスター設定をチェックします。`crm configure show`以下は、完全な出力からの抜粋です：
node 1: sapascs
node 2: sapers
...
primitive rsc_sap_SCT_ASCS10 SAPInstance \
operations $id=rsc_sap_SCT_ASCS10-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \ 
   AUTOMATIC_RECOVER=false \
meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
primitive rsc_sap_SCT_ERS11 SAPInstance \
operations $id=rsc_sap_SCT_ERS11-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \
   AUTOMATIC_RECOVER=false IS_ERS=true \
meta priority=1000
...
colocation col_sap_SCT_no_both -5000: grp_SCT_ERS11 grp_SCT_ASCS10
location loc_sap_SCT_failover_to_ers rsc_sap_SCT_ASCS10 \
rule 2000: runs_ers_SCT eq 1
order ord_sap_SCT_first_start_ascs Optional: rsc_sap_SCT_ASCS10:start rsc_sap_SCT_ERS11:stop symmetrical=false
...
ここで `sapascsvirt` は ASCS インスタンスの仮想ホスト名、`sapersvirt` はERS インスタンスの仮想ホスト名、`SCT` はSAP システム ID を指します。 | AWS システム管理者 | | フェイルオーバーコロケーションの制約を削除します。 | 前の例では、ロケーション制約 `loc_sap_SCT_failover_to_ers` は、フェイルオーバー時に ASCS の ENSA1 特徴量が常に ERS インスタンスに従うように指定されています。ENSA2 では、ASCS は参加しているすべてのノードに自由にフェイルオーバーできるはずなので、この制約を取り除くことができます。`crm configure delete loc_sap_SCT_failover_to_ers` | AWS システム管理者 | | プリミティブを調整します。 | ASCS と ERS の SAPInstance プリミティブにも若干の変更を加える必要があります。ENSA1 用に設定された ASCS SAP インスタンスプリミティブの例を次に示します。
primitive rsc_sap_SCT_ASCS10 SAPInstance \
operations $id=rsc_sap_SCT_ASCS10-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \
   AUTOMATIC_RECOVER=false \
meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
ENSA2 にアップグレードするには、この設定を次のように変更します。
primitive rsc_sap_SCT_ASCS10 SAPInstance \
operations $id=rsc_sap_SCT_ASCS10-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ASCS10_sapascsvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ASCS10_sapascsvirt" \
   AUTOMATIC_RECOVER=false \
meta resource-stickiness=3000
これは ENSA1 に設定された ERS SAPInstance プリミティブの例です。
primitive rsc_sap_SCT_ERS11 SAPInstance \
operations $id=rsc_sap_SCT_ERS11-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \
   AUTOMATIC_RECOVER=false IS_ERS=true \
meta priority=1000
ENSA2 にアップグレードするには、この設定を次のように変更します。
primitive rsc_sap_SCT_ERS11 SAPInstance \
operations $id=rsc_sap_SCT_ERS11-operations \
op monitor interval=120 timeout=60 on-fail=restart \
params InstanceName=SCT_ERS11_sapersvirt START_PROFILE="/sapmnt/SCT/profile/SCT_ERS11_sapersvirt" \
   AUTOMATIC_RECOVER=false IS_ERS=true
プリミティブは、さまざまな方法で変更できます。例えば、次の例のように、vi などのエディタで修正できます。`crm configure edit rsc_sap_SCT_ERS11` | AWS システム管理者 | | メンテナンスモードを無効にします。 | クラスターのメンテナンスモードを無効にします。`crm configure property maintenance-mode="false"`クラスターがメンテナンスモードを終了すると、新しい ENSA2 設定で ASCS インスタンスと ERS インスタンスをオンラインにしようとします。 | AWS システム管理者 | ### (オプション) クラスターノードを追加 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ベストプラクティスをレビューします。 | より多くのノードを追加する前に、使うノードの数が奇数か、偶数かなどのベストプラクティスを必ず理解するようにしてください。 | AWS システム管理者 | | ノードを追加します。 | もっと多くのノードを追加するには、オペレーティングシステムの更新、既存のノードと一致するソフトウェアパッケージのインストール、マウントを使用可能にするなど、一連のタスクが必要です。SAP ソフトウェアプロビジョニングマネージャー (SWPM) の**追加ホストの準備**オプションを使用して、ホストの SAP 特定のベースラインを作成できます。詳細について、次のセクションの SAP ガイドをご覧ください。 | AWS システム管理者 | ## 関連リソース **SAP と SUSE のリファレンス** SAP ノートにアクセスするには、 SAP ONE サポートラウンチパッドのユーザーアカウントが必要です。詳細については、「[SAP サポートウェブサイト](https://support.sap.com/en/my-support/knowledge-base.html)」 を参照してください。 + 「[SAP ノート 2501860 ‒ ABAP 7.52 の SAP NetWeaver アプリケーションサーバーのドキュメント](https://launchpad.support.sap.com/#/notes/2501860)」 + 「[SAP NOTE 2641019 ‒ SUSE HA 環境のENSA2 のインストールと ENSA1 から ENSA2 にアップデート](https://launchpad.support.sap.com/#/notes/2641019)」 + 「[SAP ノート 2641322 ‒ SAP の Red Hat HA ソリューションを使用する場合の ENSA2 のインストールと ENSA1 から ENSA2 にアップデート](https://launchpad.support.sap.com/#/notes/2641322)」 + 「[SAP ノート 2711036 ‒ HA 環境のスタンドアロンエンキューサーバー 2 の使用](https://launchpad.support.sap.com/#/notes/2711036)」 + 「[スタンドアロンエンキューサーバー2 ](https://help.sap.com/docs/ABAP_PLATFORM/cff8531bc1d9416d91bb6781e628d4e0/902412f09e134f5bb875adb6db585c92.html)」 (SAP ドキュメント) + 「[SAP S/4 HANA ‒ エンキューレプリケーション 2 ハイアベイラビリティクラスタ-のセットアップガイド](https://documentation.suse.com/sbp/all/html/SAP_S4HA10_SetupGuide-SLE12/index.html)」 (SUSE ドキュメント) **AWS リファレンス** + 「[SAP HANA on AWS: SLES と RHEL のハイアベイラビリティ設定ガイド](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html)」 + 「[SAP Lens - AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/sap-lens.html)」 # 異なる AWS アカウント間の VPC で一貫したアベイラビリティーゾーンを使用する *Amazon Web Services、Adam Spicer* ## 概要 Amazon Web Services (AWS) クラウドでは、アベイラビリティーゾーンには AWS アカウントによって異なる名前と、その場所を識別する「[アベイラビリティーゾーン ID (AZ ID)](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)」があります。AWS CloudFormation を使用して仮想プライベートクラウド (VPC) を作成する場合、サブネットを作成するときにアベイラビリティーゾーンの名前または ID を指定する必要があります。複数のアカウントで VPC を作成する場合、アベイラビリティーゾーン名はランダム化されます。つまり、サブネットはアカウントごとに異なるアベイラビリティーゾーンを使用します。  複数のアカウントに同じアベイラビリティーゾーンを使用するには、各アカウントのアベイラビリティーゾーン名を同じ AZ ID にマッピングする必要があります。例えば、次の図は、`use1-az6` AZ ID が AWS アカウント A では `us-east-1a`、AWSアカウントZでは `us-east-1c` という名前になっていることを示している。 ![\[use1-az6 AZ ID は、AWS アカウント A では us-east-1a、AWS アカウント Z では us-east-1c という名前になっています。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9954e7f9-d6ce-44bd-af99-0c6bb7cd3cb0/images/23c8a37b-2408-4534-a1e0-bccfa4d7fbe3.png) このパターンは、サブネット内の同じアベイラビリティーゾーンを使用するための、クロスアカウントでスケーラブルなソリューションを提供することで、ゾーンの一貫性を確保するのに役立ちます。ゾーンの整合性により、クロスアカウントのネットワークトラフィックがアベイラビリティーゾーン間のネットワークパスを回避できるため、データ転送コストを削減し、ワークロード間のネットワークレイテンシーを短縮できます。 このパターンは、AWS CloudFormation「[アベイラビリティーゾーン](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-subnet.html#cfn-ec2-subnet-availabilityzoneid)」プロパティの代替アプローチです。 ## 前提条件と制限 **前提条件** + 同じ AWS リージョンの少なくとも 2 つのアクティブな AWS アカウント。 + リージョン内の VPC 要件をサポートするのに必要なアベイラビリティーゾーンの数を評価してください。 + サポートする必要のある各アベイラビリティーゾーンの AZ ID を特定して記録します。詳細については、AWS ResAWS Resource Access Manager ドキュメントの「[AWS リソースのアベイラビリティーゾーン ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)」を参照してください。  + AZ ID の順序付きカンマ区切りリスト。例えば、リストの最初のアベイラビリティーゾーンは `az1` としてマッピングされ、2 番目のアベイラビリティーゾーンは `az2` としてマップされます。このマッピング構造は、カンマで区切られたリストが完全にマップされるまで続きます。マッピングできる AZ ID の数に上限はありません。  + ローカルマシンにコピーされた GitHub「[マルチアカウントアベイラビリティーゾーンのマッピング](https://github.com/aws-samples/multi-account-az-mapping/)」リポジトリの `az-mapping.yaml` ファイル ## アーキテクチャ 次の図は、アカウントにデプロイされ、AWS Systems Manager Parameter Store 値を作成するアーキテクチャを示しています。これらのパラメータストア値は、アカウントに VPC を作成するときに消費されます。 ![\[AZ ID ごとに Systems Manager Parameter Store 値を作成し、AZ 名を保存するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9954e7f9-d6ce-44bd-af99-0c6bb7cd3cb0/images/f1168464-55f8-4efc-9b28-6a0cda668b9e.png) この図表は、次のワークフローを示しています: 1. このパターンのソリューションは、VPC のゾーン整合性を必要とするすべてのアカウントにデプロイされます。  1. このソリューションでは、AZ ID ごとにパラメータストア値を作成し、新しいアベイラビリティーゾーン名を保存します。  1. AWS CloudFormation テンプレートは、各パラメータストア値に保存されているアベイラビリティーゾーン名を使用するため、ゾーンの一貫性が確保されます。 次の図は、このパターンのソリューションを使用して VPC を作成するワークフローを示しています。 ![\[このワークフローは CloudFormation テンプレートを送信して、正しい AZ ID を持つ VPC を作成します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9954e7f9-d6ce-44bd-af99-0c6bb7cd3cb0/images/cd859430-ac25-479f-b56a-21da24cddf21.png) この図表は、次のワークフローを示しています: 1. VPC を作成するためのテンプレートを AWS CloudFormation に送信します。 1. AWS CloudFormation は各アベイラビリティーゾーンのパラメータストア値を解決し、各 AZ ID のアベイラビリティーゾーン名を返します。 1. VPC は、ゾーンの整合性に必要な正しい AZ ID で作成されます。 このパターンのソリューションをデプロイしたら、Parameter Store 値を参照するサブネットを作成できます。AWS CloudFormation を使用する場合、次の YAML 形式のサンプルコードからアベイラビリティーゾーンのマッピングパラメータ値を参照できます。 ``` Resources: PrivateSubnet1AZ1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: !Ref PrivateSubnetAZ1CIDR AvailabilityZone: !Join - '' - - '{{resolve:ssm:/az-mapping/az1:1}}' ``` このサンプルコードは、GitHub「[マルチアカウントアベイラビリティーゾーンマッピングリ](https://github.com/aws-samples/multi-account-az-mapping/)」ポジトリの `vpc-example.yaml ` ファイルに含まれています。ゾーンの整合性を保つために、パラメータストアの値に合わせた VPC とサブネットを作成する方法について説明します。 テクノロジースタック + AWS CloudFormation + AWS Lambda + Systems Manager Parameter Store **自動化とスケール** このパターンは、AWS CloudFormation StackSets または AWS Control Tower 向けカスタマイズソリューションを使用して、すべての AWS アカウントにデプロイできます。詳細については、AWS Cloudformation ドキュメントの「[AWS CloudFormation StackSets 使用](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」と、AWS ソリューションライブラリの「[AWS Control Tower のカスタマイズ](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/)」を参照してください。  AWS CloudFormation テンプレートをデプロイしたら、パラメータストアの値を使用するようにテンプレートを更新し、パイプラインに、または要件に応じて VPC をデプロイできます。  ## ツール **AWS サービス** + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」は、AWS リソースのモデル化と設定、迅速かつ一貫したプロビジョニング、ライフサイクル全体にわたる管理を支援します。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。複数の AWS アカウントと AWS リージョンにまたがるスタックを管理およびプロビジョニングできます。 + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。課金は実際に消費したコンピューティング時間に対してのみ発生します。コードが実行されていない場合、料金は発生しません。 + 「[AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)」は AWS Systems Manager の一機能です。設定データ管理と機密管理のための安全な階層型ストレージを提供します。 **Code** このパターンのコードは、GitHub 内の「[マルチアカウントアベイラビリティーゾーンのマッピング](https://github.com/aws-samples/multi-account-az-mapping/)」リポジトリで利用できます。 ## エピック ### AZ マッピング.yaml ファイルをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リージョンの必要なアベイラビリティーゾーンを決定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-consistent-availability-zones-in-vpcs-across-different-aws-accounts.html) | クラウドアーキテクト | | az-mapping.yaml ファイルをデプロイします。 | `az-mapping.yaml` ファイルを使用して、必要なすべての AWS アカウントに AWS CloudFormation スタックを作成します。`AZIds` パラメータには、先ほど作成したカンマ区切りリストを使用します。 「[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」または「[AWS Control Tower ソリューション](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/)」のカスタマイズを使用することをお勧めします。 | クラウドアーキテクト | ### VPC をアカウントにデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation テンプレートをカスタマイズします。 | AWS CloudFormation を使用してサブネットを作成する場合、以前に作成したパラメータストア値を使用するようにテンプレートをカスタマイズします。サンプルテンプレートについては、GitHub「[マルチアカウントアベイラビリティーゾーンのマッピング](https://github.com/aws-samples/multi-account-az-mapping/)」リポジトリにある `vpc-example.yaml` ファイルを参照してください。 | クラウドアーキテクト | | VPC をデプロイします。 | カスタマイズした AWS CloudFormation テンプレートをアカウントにデプロイします。これにより、リージョン内の各 VPC は、サブネットに使用されるアベイラビリティーゾーンでゾーン整合性を保ちます。 | クラウドアーキテクト | ## 関連リソース + 「[AWS リソースのアベイラビリティーゾーン ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)」(AWS Resource Access Manager のドキュメント) + 「[AWS:: EC2:: サブネット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-subnet.html)」(AWS CloudFormation ドキュメント) # アクセスコントロールと自動化に IAM ポリシーのユーザー ID を使用する *Amazon Web Services、Srinivas Ananda Babu と Ram Kandaswamy* ## 概要 このパターンでは、 AWS Identity and Access Management (IAM) でユーザー名ベースのポリシーを使用する潜在的な落とし穴、ユーザー IDs を使用する利点、このアプローチを と統合して AWS CloudFormation 自動化する方法を説明します。 では AWS クラウド、IAM サービスを使用して、ユーザー ID とアクセスコントロールを正確に管理できます。ただし、ユーザー名に依存して IAM ポリシーを作成すると、予期しないセキュリティリスクやアクセスコントロールの問題が発生する可能性があります。例えば、John Doe という新しい従業員がチームに参加し、ユーザー名 `j.doe` を使用して IAM ユーザーアカウントを作成するとします。これにより、ユーザー名を参照する IAM ポリシーを通じてアクセス許可が付与されます。John が退職すると、アカウントは削除されます。問題は、Jane Doe という新しい従業員がチームに加わり、`j.doe` というユーザー名が再作成されたときに発生します。既存のポリシーは、John Doe と同じアクセス許可を Jane Doe に付与します。これはセキュリティとコンプライアンスに悪影響を及ぼす可能性があります。 新しいユーザーの詳細を反映するように各ポリシーを手動で更新するのは、特に組織が成長するほど、時間がかかり、エラーが発生しやすいプロセスです。解決策は、一意の変更不可能なユーザー ID を使用することです。IAM ユーザーアカウントを作成すると、 は IAM ユーザーに一意のユーザー ID (またはプリンシパル ID) を AWS 割り当てます。これらのユーザー ID を IAM ポリシーで使用することで、ユーザー名の変更や再利用の影響を受けない一貫した信頼性の高いアクセスコントロールを確保できます。 一例として、ユーザー ID を使用する IAM ポリシーは次のようになります。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example-bucket", "Principal": { "AWS": "arn:aws:iam::123456789012:user/abcdef01234567890" } } ] } ``` IAM ポリシーでユーザー ID を使用する利点は次のとおりです。 + **一意性。**ユーザー IDsはすべての で一意であるため AWS アカウント、正確で一貫性のあるアクセス許可アプリケーションを提供します。 + **変更不可能性。**ユーザー ID は変更できないため、ポリシーでユーザーを参照するための安定した識別子となります。 + **監査とコンプライアンス。** AWS のサービス 多くの場合、ログと監査証跡にユーザー IDs が含まれているため、特定のユーザーにアクションを簡単にトレースできます。 + **オートメーションと統合。** AWS APIs、SDKs、またはオートメーションスクリプトでユーザー IDs を使用すると、プロセスはユーザー名の変更の影響を受けません。 + **将来性。**最初からポリシーでユーザー ID を使用しておくと、潜在的なアクセスコントロールの問題や大幅なポリシーの更新を未然に防ぐことができます。 **オートメーション** などのInfrastructure as Code (IaC) ツールを使用すると AWS CloudFormation、ユーザー名ベースの IAM ポリシーの落とし穴が問題を引き起こす可能性があります。`Ref` 組み込み関数を呼び出すと、IAM ユーザーリソースはユーザー名を返します。組織のインフラストラクチャが発展するにつれて、IAM ユーザーアカウントなどのリソースを作成、削除するサイクルにより、ユーザー名を再利用した場合に意図しないアクセスコントロールの問題が発生する可能性があります。 この問題に対処するには、CloudFormation テンプレートにユーザー ID を組み込むことをお勧めします。ただし、この目的でユーザー ID を取得するのは難しい場合があります。そこで、カスタムリソースが役立ちます。CloudFormation カスタムリソースを使用して、 AWS APIs または外部サービスと統合することで、サービスの機能を拡張できます。特定の IAM ユーザーのユーザー ID を取得するカスタムリソースを作成することで、CloudFormation テンプレート内でユーザー ID を使用できるようになります。このアプローチにより、ユーザー ID を参照するプロセスを合理化し、オートメーションワークフローの堅牢性と将来性を確保できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + クラウド管理者が CloudFormation テンプレートを実行するための IAM ロール **制限事項** + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は CloudFormation 、 がバックアップするカスタムリソース AWS Lambda を使用して IAM ユーザー ID を取得する方法を示しています。 ![\[CloudFormation カスタムリソースの使用による IAM ユーザー ID の取得。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/71698647-274e-4911-92f0-549e444b53f6/images/7e507df4-f597-499e-bd5b-6d7a55e64146.png) **自動化とスケール** CloudFormation テンプレートは、異なる AWS リージョン および アカウントに複数回使用できます。各リージョンまたはアカウントで 1 回のみ実行できます。 ## ツール **AWS サービス** + [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) – AWS Identity and Access Management (IAM) は、 AWS リソースへのアクセスを安全に制御するのに役立つウェブサービスです。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) – AWS リソースをモデル化してセットアップ AWS CloudFormation できるため、それらのリソースの管理に費やす時間が減り、実行されるアプリケーションに集中する時間が増えます AWS。必要な AWS リソースを記述するテンプレートを作成すると、CloudFormation がそれらのリソースのプロビジョニングと設定を処理します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) – は、サーバーのプロビジョニングや管理を行わずにコードの実行をサポートするコンピューティングサービス AWS Lambda です。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。  ## ベストプラクティス ゼロからユーザー作成を開始する場合やグリーンフィールドデプロイを計画する場合は、[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用してユーザー管理を一元化することを強くお勧めします。IAM Identity Center は既存の ID プロバイダー (Active Directory や Okta など) と統合してユーザー ID をフェデレーションするため AWS、IAM ユーザーを直接作成および管理する必要はありません。このアプローチは、一貫したアクセスコントロールを保証するだけでなく、ユーザーライフサイクル管理を簡素化し、 AWS 環境全体のセキュリティとコンプライアンスを強化するのに役立ちます。 ## エピック ### アクセス許可を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS アカウント と IAM ロールを検証します。 | に CloudFormation テンプレートをデプロイするアクセス許可を持つ IAM ロールがあることを確認します AWS アカウント。この手順の最後のステップで、CloudFormation コンソール AWS CLI の代わりに を使用してテンプレートをデプロイする場合は、 AWS CLI コマンドを実行するための一時的な認証情報も設定する必要があります。手順については、[IAM ドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html#using-temp-creds-sdk-cli)を参照してください。 | クラウドアーキテクト | ### CloudFormation テンプレートの構築 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-user-ids-iam-policies-access-control-automation.html) | AWS DevOps、クラウドアーキテクト | | ユーザー名の入力パラメータを追加します。 | CloudFormation テンプレートの `Parameters` セクションに次のコードを追加します。
Parameters:
  NewIamUserName:
    Type: String
    Description: Unique username for the new IAM user
このパラメータは、ユーザーにユーザー名の入力を求めます。 | AWS DevOps、クラウドアーキテクト | | カスタムリソースを追加して、IAM ユーザーを作成します。 | CloudFormation テンプレートの `Resources` セクションに次のコードを追加します。
Resources:
  rNewIamUser:
    Type: 'AWS::IAM::User'
    Properties:
      UserName: !Ref NewIamUserName
このコードは、`NewIamUserName` パラメータによって指定された名前で IAM ユーザーを作成する CloudFormation リソースを追加します。 | AWS DevOps、クラウドアーキテクト | | Lambda 関数の実行ロールを追加します。 | このステップでは、IAM を取得するアクセス許可を AWS Lambda 関数に付与する IAM ロールを作成します`UserId`。Lambda がコードを実行するために必要な以下の最小限のアクセス許可を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-user-ids-iam-policies-access-control-automation.html)実行ロールを作成する手順については、[Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)を参照してください。次のステップで Lambda 関数を作成するときに、このロールを参照します。 | AWS 管理者、クラウドアーキテクト | | Lambda 関数を追加して、一意の IAM `UserId` を取得します。 | このステップでは、Python ランタイムを使用して Lambda 関数を定義し、一意の IAM `UserId` を取得します。これを行うには、CloudFormation テンプレートの `Resources` セクションに次のコードを追加します。`<>` を、先ほど作成した実行ロールの名前に置き換えます。
  GetUserLambdaFunction:
    Type: 'AWS::Lambda::Function'
    Properties:
      Handler: index.handler
      Role: <>
      Timeout: 30
      Runtime: python3.11
      Code:
        ZipFile: |
          import cfnresponse, boto3
          def handler(event, context):
            try:
              print(event)
              user = boto3.client('iam').get_user(UserName=event['ResourceProperties']['NewIamUserName'])['User']
              cfnresponse.send(event, context, cfnresponse.SUCCESS, {'NewIamUserId': user['UserId'], 'NewIamUserPath': user['Path'], 'NewIamUserArn': user['Arn']})
            except Exception as e:
              cfnresponse.send(event, context, cfnresponse.FAILED, {'NewIamUser': str(e)})
| AWS DevOps、クラウドアーキテクト | | カスタムリソースを追加します。 | CloudFormation テンプレートの `Resources` セクションに次のコードを追加します。
  rCustomGetUniqueUserId:
    Type: 'Custom::rCustomGetUniqueUserIdWithLambda'
    Properties:
      ServiceToken: !GetAtt GetUserLambdaFunction.Arn
      NewIamUserName: !Ref NewIamUserName
このカスタムリソースは Lambda 関数を呼び出して IAM `UserID` を取得します。 | AWS DevOps、クラウドアーキテクト | | CloudFormation 出力を定義します。 | CloudFormation テンプレートの `Outputs` セクションに次のコードを追加します。
Outputs:
  NewIamUserId:
    Value: !GetAtt rCustomGetUniqueUserId.NewIamUserId
これにより、新しい IAM ユーザーの IAM `UserID` が表示されます。 | AWS DevOps、クラウドアーキテクト | | テンプレートを保存します。 | 変更を CloudFormation テンプレートに保存します。 | AWS DevOps、クラウドアーキテクト | ### CloudFormation のテンプレートを入手するには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation のテンプレートをデプロイします。 | CloudFormation コンソールを使用して `get_unique_user_id.yaml` テンプレートをデプロイするには、[CloudFormation ドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)の手順に従います。または、次の AWS CLI コマンドを実行してテンプレートをデプロイすることもできます。
aws cloudformation create-stack \
--stack-name DemoNewUser \
--template-body file://get_unique_user_id.yaml \
--parameters ParameterKey=NewIamUserName,ParameterValue=demouser \
--capabilities CAPABILITY_NAMED_IAM
| AWS DevOps、クラウドアーキテクト | ## 関連リソース + [CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) (CloudFormation ドキュメント) + [Lambda を使用するカスタムリソース](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources-lambda.html) (CloudFormation ドキュメント) + [一意の識別子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) (IAM ドキュメント) + [AWS リソースで一時的な認証情報を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) (IAM ドキュメント) # Account Factory for Terraform (AFT) のコードをローカルで検証する *Amazon Web Services、Alexandru Pop と Michal Gorniak* ## 概要 このパターンは、 AWS Control Tower Account Factory for Terraform (AFT) によって管理される HashiCorp Terraform コードをローカルでテストする方法を示しています。Terraform は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ Infrastructure as Code (IaC) ツールです。AFT は、複数の AWS アカウント をプロビジョニングおよびカスタマイズするのに役立つ Terraform パイプラインを設定します AWS Control Tower。 コード開発時には、Terraform Infrastructure as Code (IaC) を AFT パイプラインの外部でローカルでテストすると役立つ場合があります。このパターンは、次を実行する方法を説明しています。 + AFT 管理アカウントの AWS CodeCommit リポジトリに保存されている Terraform コードのローカルコピーを取得します。 + 取得したコードを使用して AFT パイプラインをローカルでシミュレートします。 このプロシージャは、通常の AFT パイプラインに含まれていない Terraform コマンドを実行する場合にも使用できます。たとえば、このメソッドを使用して、`terraform validate`、`terraform plan`、`terraform destroy`や`terraform import`などのコマンドを実行できます。 ## 前提条件と制限事項 **前提条件** + が使用するアクティブな AWS マルチアカウント環境 [AWS Control Tower](https://aws.amazon.com/controltower) + 完全にデプロイされた [AFT 環境](https://docs.aws.amazon.com/controltower/latest/userguide/taf-account-provisioning.html)。 + 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)済み + [AWS CLI の認証情報ヘルパー AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html)、インストールおよび設定 + Python 3.x + [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)　ローカルマシンにインストールされて設定されている 。 + [インストールおよび設定](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html#setting-up-git-remote-codecommit-install)済みの `git-remote-commit` ユーティリティ + 「[Terraform](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS)」がインストールされ、構成されている (ローカルの Terraform パッケージのバージョンは AFT デプロイメントで使用されているバージョンと一致している必要がある) **制限事項** + このパターンは、、AFT AWS Control Tower、または特定の Terraform モジュールに必要なデプロイ手順には適用されません。 + この手順でローカルに生成された出力は、AFT パイプラインのランタイムログには保存されません。 ## アーキテクチャ **ターゲットテクノロジースタック** + デプロイ内に AWS Control Tower デプロイされた AFT インフラストラクチャ + Terraform + Git + AWS CLI バージョン 2 **自動化とスケール** このパターンは、単一の AFT 管理の AFT グローバルアカウントカスタマイズのために Terraform コードをローカルで呼び出す方法を示しています AWS アカウント。Terraform コードを検証したら、マルチアカウント環境の残りのアカウントにも適用できます。詳細については、 AWS Control Tower ドキュメントの[「カスタマイズの再呼び出し](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html#aft-re-invoke-customizations)」を参照してください。 同様のプロセスを使用して、ローカルターミナルで AFT アカウントのカスタマイズを実行することもできます。AFT アカウントのカスタマイズから Terraform コードをローカルで呼び出すには、AFT 管理アカウントの CodeCommit から 「**aft-グローバル-アカウント-カスタマイズ リポジトリ**」の代わりに「**aft-アカウント-カスタマイズ**」リポジトリを複製します。 ## ツール **AWS サービス** + [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、規範的なベストプラクティスに従って、 AWS マルチアカウント環境のセットアップと管理に役立ちます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 **その他のサービス** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのを支援する Infrastructure as Code (IaC) ツールです。 + 「[Git](https://git-scm.com/docs)」はオープンソースの分散型バージョン管理システムです。 **コード** 以下は、AFT が管理する Terraform コードをローカルで実行するために使用できる bash スクリプトの例です。このスクリプトを使用するには、このパターンの「[エピック](#validate-account-factory-for-terraform-aft-code-locally-epics)」セクションの手順に従ってください。 ``` #! /bin/bash # Version: 1.1 2022-06-24 Unsetting AWS_PROFILE since, when set, it interferes with script operation # 1.0 2022-02-02 Initial Version # # Purpose: For use with AFT: This script runs the local copy of TF code as if it were running within AFT pipeline. # * Facilitates testing of what the AFT pipline will do # * Provides the ability to run terraform with custom arguments (like 'plan' or 'move') which are currently not supported within the pipeline. # # © 2021 Amazon Web Services, Inc. or its affiliates. All Rights Reserved. # This AWS Content is provided subject to the terms of the AWS Customer Agreement # available at http://aws.amazon.com/agreement or other written agreement between # Customer and either Amazon Web Services, Inc. or Amazon Web Services EMEA SARL or both. # # Note: Arguments to this script are passed directly to 'terraform' without parsing nor validation by this script. # # Prerequisites: # 1. local copy of ct GIT repositories # 2. local backend.tf and aft-providers.tf filled with data for the target account on which terraform is to be run # Hint: The contents of above files can be obtain from the logs of a previous execution of the AFT pipeline for the target account. # 3. 'terraform' binary is available in local PATH # 4. Recommended: .gitignore file containing 'backend.tf', 'aft_providers.tf' so the local copy of these files are not pushed back to git readonly credentials=$(aws sts assume-role \ --role-arn arn:aws:iam::$(aws sts get-caller-identity --query "Account" --output text ):role/AWSAFTAdmin \ --role-session-name AWSAFT-Session \ --query Credentials ) unset AWS_PROFILE export AWS_ACCESS_KEY_ID=$(echo $credentials | jq -r '.AccessKeyId') export AWS_SECRET_ACCESS_KEY=$(echo $credentials | jq -r '.SecretAccessKey') export AWS_SESSION_TOKEN=$(echo $credentials | jq -r '.SessionToken') terraform "$@" ``` ## エピック ### サンプルコードをローカルファイルとして保存します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプルコードをローカルファイルとして保存します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html) | AWS 管理者 | | サンプルコードを実行可能にします。 | ターミナルウィンドウを開き、次のいずれかを実行して AWS AFT 管理アカウントを認証します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html)組織に、 AWS 環境に認証情報を提供するカスタムツールがある場合もあります。 | AWS 管理者 | | 正しい AWS リージョンの AFT 管理アカウントへのアクセスを確認します。 | AFT 管理アカウントへの認証に使用したのと同じターミナルセッションを使用していることを確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html) | AWS 管理者 | | AFT リポジトリコードを保存する新しいローカルディレクトリを作成します。 | 同じターミナルセッションから、次のコマンドを実行します。
mkdir my_aft 
cd my_aft
| AWS 管理者 | | リモート AFT リポジトリコードを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html) | AWS 管理者 | ### AFT パイプラインをローカルで実行するために必要な Terraform 設定ファイルを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 以前に実行した AFT パイプラインを開き、Terraform 設定ファイルをローカルフォルダーにコピーします。 | AFT パイプラインをローカルで実行するには、このエピックで作成された「`backend.tf`」と「`aft-providers.tf`」設定ファイルが必要です。これらのファイルはクラウドベースの AFT パイプライン内で自動的に作成されますが、パイプラインをローカルで実行するには手動で作成する必要があります。AFT パイプラインをローカルで実行するには、単一の AWS アカウント内でのパイプラインの実行を表す 1 つのファイルセットが必要です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html)**自動生成された backend.tf ステートメントの例**
## Autogenerated backend.tf ##
## Updated on: 2022-05-31 16:27:45 ##
terraform {
  required_version = ">= 0.15.0"
  backend "s3" {
    region         = "us-east-2"
    bucket         = "aft-backend-############-primary-region"
    key            = "############-aft-global-customizations/terraform.tfstate"
    dynamodb_table = "aft-backend-############"
    encrypt        = "true"
    kms_key_id     = "########-####-####-####-############"
    role_arn       = "arn:aws:iam::#############:role/AWSAFTExecution"
  }
}
** **`backend.tf`および `aft-providers.tf`ファイルは AWS アカウント、特定の、AFT デプロイ、およびフォルダに関連付けられます。これらのファイルは、同じ AFT デプロイ内の「**aft-global-customizations**」リポジトリと「**aft-account-customizations**」リポジトリにあるかどうかによっても異なります。必ず、同じランタイムリストから両方のファイルを生成してください。 | AWS 管理者 | ### サンプルの bash スクリプトを使用して AFT パイプラインをローカルで実行します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 検証したい Terraform の設定の変更を実装します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html) | AWS 管理者 | | `ct_terraform.sh` スクリプトを実行し、出力を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html)** **[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html) | AWS 管理者 | ### ローカルコードの変更を AFT リポジトリにプッシュバックします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `.gitignore` ファイルに `backend.tf` ファイルおよび `aft-providers.tf` ファイルへの参照を追加します。 | 以下のコマンドを実行して、作成した`backend.tf`** **と`aft-providers.tf`ファイルを`.gitignore`ファイルに追加します。
echo backend.tf >> .gitignore
echo aft-providers.tf >>.gitignore
ファイルを `.gitignore`** **ファイルに移動することで、ファイルがコミットされてリモート AFT リポジトリにプッシュバックされることがなくなります。 | AWS 管理者 | | コード変更をリモート AFT リポジトリにコミットしてプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/validate-account-factory-for-terraform-aft-code-locally.html)この時点で 1 つの AWS アカウント みに適用されるまで、この手順に従うことで導入するコードが変更されます。 | AWS 管理者 | ### 複数のアカウントに変更をロールアウトします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AFT が管理するすべてのアカウントに変更を適用します。 | AFT によって管理 AWS アカウント される複数の に変更をロールアウトするには、 AWS Control Tower ドキュメントの[「カスタマイズの再呼び出し](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html#aft-re-invoke-customizations)」の手順に従います。 | AWS 管理者 | # その他のパターン **Topics** + [リードレプリカを使用して Amazon RDS Customの Oracle PeopleSoft に HA を追加](add-ha-to-oracle-peoplesoft-on-amazon-rds-custom-by-using-a-read-replica.md) + [パブリック IP アドレスからのアクセスを許可する AWS セキュリティグループを自動的に監査する](audit-security-groups-access-public-ip.md) + [で Landing Zone Accelerator を使用してアカウントの作成を自動化する AWS](automate-account-creation-lza.md) + [AWS Systems Manager を使用して Windows レジストリエントリの追加または更新を自動化する](automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager.md) + [AWS リソース評価を自動化する](automate-aws-resource-assessment.md) + [AWS CDK を使用して AWS Service Catalog ポートフォリオと製品のデプロイを自動化する](automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.md) + [DR Orchestrator Framework を使用してクロスリージョンのフェイルオーバーとフェイルバックを自動化](automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.md) + [AWS CloudFormation スタックと関連リソースの削除を自動化する](automate-deletion-cloudformation-stacks-associated-resources.md) + [Terraform を使用して Amazon Managed Grafana での Amazon MWAA カスタムメトリクスの取り込みと視覚化を自動化する](automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.md) + [Amazon MQ で RabbitMQ 設定を自動化する](automate-rabbitmq-configuration-in-amazon-mq.md) + [マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する](automate-the-deployment-of-aws-supply-chain-data-lakes.md) + [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md) + [Cloud Custodian と AWS CDK を使用して、Systems Manager の AWS マネージドポリシーを EC2 インスタンスプロファイルに自動的にアタッチする](automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.md) + [AWS CDK を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECS クラスターを自動的に構築する](automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.md) + [CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md) + [AWS DataOps Development Kit を使用して Google Analytics データを取り込み、変換、分析するためのデータパイプラインを構築する](build-a-data-pipeline-to-ingest-transform-and-analyze-google-analytics-data-using-the-aws-dataops-development-kit.md) + [Amazon EC2 Auto Scaling と Systems Manager を搭載した Micro Focus Enterprise Server PAC を構築する](build-a-micro-focus-enterprise-server-pac-with-amazon-ec2-auto-scaling-and-systems-manager.md) + [GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md) + [MongoDB Atlas を含む AWS ランディングゾーンを構築する](build-aws-landing-zone-that-includes-mongodb-atlas.md) + [Terraform を使用して AWS Organizations の IAM アクセスキー管理を一元化する](centralize-iam-access-key-management-in-aws-organizations-by-using-terraform.md) + [Terraform を使用して AWS Organizations でのソフトウェアパッケージの配布を一元化する](centralize-software-package-distribution-in-aws-organizations-by-using-terraform.md) + [を使用して Amazon Bedrock でモデル呼び出しログ記録を設定する AWS CloudFormation](configure-bedrock-invocation-logging-cloudformation.md) + [で SQL Server の Always On 可用性グループで読み取り専用ルーティングを設定する AWS](configure-read-only-routing-in-an-always-on-availability-group-in-sql-server-on-aws.md) + [、Angular AWS Amplify、および Module Federation を使用してマイクロフロントエンド用のポータルを作成する](create-amplify-micro-frontend-portal.md) + [GitHub Actions と Terragrunt を使用した API 駆動型リソースオーケストレーションフレームワークの作成](create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.md) + [組織でクロスアカウント Amazon EventBridge 接続を作成する](create-cross-account-amazon-eventbridge-connection-organization.md) + [Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.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) + [と CloudFormation を使用して AWS Control Tower コントロールをデプロイ AWS CDK および管理する](deploy-and-manage-aws-control-tower-controls-by-using-aws-cdk-and-aws-cloudformation.md) + [Terraform を使用した AWS Control Tower コントロールのデプロイと管理](deploy-and-manage-aws-control-tower-controls-by-using-terraform.md) + [Terraform を使用して CloudWatch Synthetics Canary をデプロイする](deploy-cloudwatch-synthetics-canaries-by-using-terraform.md) + [Terraform を使用して Amazon EKS に CockroachDB クラスターをデプロイする](deploy-cockroachdb-on-eks-using-terraform.md) + [Terraform と DRA を使用して、高性能のデータ処理用の Lustre ファイルシステムをデプロイする](deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra.md) + [Terraform と Amazon Bedrock を使用して AWS に RAG ユースケースをデプロイする](deploy-rag-use-case-on-aws.md) + [Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする](deploy-resources-wavelength-zone-using-terraform.md) + [Terraform を使用して SQL Server フェイルオーバークラスターインスタンスを Amazon EC2 および Amazon FSx にデプロイする](deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.md) + [Terraform を使用して AWS WAF ソリューションのセキュリティオートメーションをデプロイする](deploy-the-security-automations-for-aws-waf-solution-by-using-terraform.md) + [CA 証明書の有効期限が切れる Amazon RDS および Aurora データベースのインスタンスを検出する](detect-rds-instances-expiring-certificates.md) + [AWS のランディングゾーンの設計を文書化する](document-your-aws-landing-zone-design.md) + [AWS Organizations 内の組織全体の AWS Backup レポートを CSV ファイルとしてエクスポートする](export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.md) + [Amazon Personalize を使用して、パーソナライズされ再ランク付けされたレコメンデーションを生成します](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md) + [Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する](govern-permission-sets-aft.md) + [Amazon Data Firehose リソースが AWS KMS キーで暗号化されていない場合の識別とアラート](identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key.md) + [ブートストラップパイプラインを使用して Account Factory for Terraform (AFT) を実装する](implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.md) + [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md) + [Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします](install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset.md) + [prebootstrapコマンドを使用して、SSM エージェントと CloudWatch エージェントを Amazon EKS ワーカーノードにインストールします。](install-the-ssm-agent-and-cloudwatch-agent-on-amazon-eks-worker-nodes-using-prebootstrapcommands.md) + [を使用してアクセス AWS IAM アイデンティティセンター 許可セットをコードとして管理する AWS CodePipeline](manage-aws-iam-identity-center-permission-sets-as-code-by-using-aws-codepipeline.md) + [Terraform を使用して AWS アクセス許可セットを動的に管理する](manage-aws-permission-sets-dynamically-by-using-terraform.md) + [複数の AWS アカウントと AWS リージョンで AWS Service Catalog 製品を管理](manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions.md) + [AWS CDK で Amazon ECS Anywhere を設定して、オンプレミスコンテナアプリケーションを管理します。](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md) + [AWS CodePipeline と Amazon Bedrock を使用して AWS Organizations ポリシーをコードとして管理する](manage-organizations-policies-as-code.md) + [DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する](migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.md) + [Oracle PeopleSoft を Amazon RDS Custom に移行](migrate-oracle-peoplesoft-to-amazon-rds-custom.md) + [AWS MGN を使用して RHEL BYOL システムを AWS ライセンス込みのインスタンスに移行する](migrate-rhel-byol-systems-to-aws-license-included-instances-by-using-aws-mgn.md) + [Amazon ElastiCache クラスターの保存時の暗号化をモニタリングする](monitor-amazon-elasticache-clusters-for-at-rest-encryption.md) + [CloudWatch Logs Insights を使用してアプリケーションアクティビティをモニタリングする](monitor-application-activity-by-using-cloudwatch-logs-insights.md) + [AWS のサービスを使用して SAP RHEL Pacemaker クラスターをモニタリングする](monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.md) + [Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する](multi-region-ipam-architecture.md) + [AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する](optimize-multi-account-serverless-deployments.md) + [GitHub Actions を使用して AWS CloudFormation テンプレートに基づいて AWS Service Catalog 製品をプロビジョニングする](provision-aws-service-catalog-products-using-github-actions.md) + [ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする](provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.md) + [AWS Lambda オートメーションを使用して 全体の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する](remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.md) + [AWS Lambda オートメーションを使用して AWS アカウント から同じ の Amazon EC2 AWS Managed Microsoft AD エントリを削除する](remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.md) + [Transfer Family、Amazon Cognito、GuardDuty を使用してファイル転送を保護する](secure-file-transfers.md) + [IAM ユーザーが作成されたときに通知を送信](send-a-notification-when-an-iam-user-is-created.md) + [セルベースアーキテクチャ用にサーバーレスセルルーターを設定する](serverless-cell-router-architecture.md) + [AWS CDK と GitLab を使用して、Amazon ECS Anywhere 上のハイブリッドワークロード用に CI/CD パイプラインを設定する](set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.md) + [Amazon RDS Custom でアクティブスタンバイデータベースを使用して Oracle E-Business Suite の HA/DR アーキテクチャを設定する](set-up-an-ha-dr-architecture-for-oracle-e-business-suite-on-amazon-rds-custom-with-an-active-standby-database.md) + [マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する](set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.md) + [Amazon FSx を使用して SQL Server Always On FCI 向けのマルチ AZ インフラストラクチャをセットアップする](set-up-multi-az-infrastructure-for-a-sql-server-always-on-fci-by-using-amazon-fsx.md) + [Aurora PostgreSQL-Compatible で Oracle UTL\$1FILE 機能をセットアップする](set-up-oracle-utl_file-functionality-on-aurora-postgresql-compatible.md) + [Application Load Balancer を使用して Amazon ECS の相互 TLS でアプリケーション認証を簡素化する](simplify-application-authentication-with-mutual-tls-in-amazon-ecs.md) + [AWS Private CA と AWS RAM を使用してプライベート証明書の管理を簡素化する](simplify-private-certificate-management-by-using-aws-private-ca-and-aws-ram.md) + [SageMaker AI と Hybrid を使用して、ローカルでの開発からスケーラブルな実験に至るまでの機械学習ワークフローを合理化する](streamline-machine-learning-workflows-by-using-amazon-sagemaker.md) + [AWS Organizations を使用して Transit Gateway アタッチメントに自動的にタグを付ける](tag-transit-gateway-attachments-automatically-using-aws-organizations.md) + [Amazon RDS Custom for Oracle 上の Oracle PeopleSoft アプリケーションの移行ロール](transition-roles-for-an-oracle-peoplesoft-application-on-amazon-rds-custom-for-oracle.md) + [Amazon Q Developer をコーディングアシスタントとして使用して生産性を高める](use-q-developer-as-coding-assistant-to-increase-productivity.md)