翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # デベロッパーツール **Topics** + [DevOps](devops-pattern-list.md) + [インフラストラクチャ](infrastructure-pattern-list.md) + [ウェブアプリとモバイルアプリ](websitesandwebapps-pattern-list.md) # DevOps **Topics** + [Backstage とセルフサービスの Amazon SageMaker AI テンプレートを使用して MLOps を高速化](accelerate-mlops-with-backstage-and-sagemaker-templates.md) + [Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する](automate-aws-infrastructure-operations-by-using-amazon-bedrock.md) + [Terraform を使用してロードバランサーエンドポイントが変更されたときの CloudFront 更新を自動化](automate-cloudfront-updates-when-load-balancer-endpoints-change.md) + [GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する](automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.md) + [GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する](automate-the-deployment-of-aws-supply-chain-data-lakes.md) + [AWS リソース評価を自動化する](automate-aws-resource-assessment.md) + [オープンソースツールを使用して SAP システムを自動的にインストール](install-sap-systems-automatically-by-using-open-source-tools.md) + [AWS CDK を使用して AWS Service Catalog ポートフォリオと製品のデプロイを自動化する](automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.md) + [AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.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) + [AWS CodePipeline および AWS CodeBuild を使用して、スタックセットデプロイを自動化](automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.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) + [GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md) + [AWS CodeCommit、AWS CodePipeline、AWS Device Farm を使用して iOS アプリを構築してテストする](build-and-test-ios-apps-with-aws-codecommit-aws-codepipeline-and-aws-device-farm.md) + [Amazon EKS で実行されているアプリケーションの相互 TLS 認証を設定する](configure-mutual-tls-authentication-for-applications-running-on-amazon-eks.md) + [を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation](automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.md) + [Firelens ログルーターを使用して Amazon ECS 用のカスタムログパーサーを作成する](create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.md) + [GitHub Actions と Terragrunt を使用した API 駆動型リソースオーケストレーションフレームワークの作成](create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.md) + [GitHub Actions を使用して Terraform マネージド AWS インフラストラクチャの自動プルリクエストを作成する](create-automated-pull-requests-for-terraform-managed-aws-infrastructure.md) + [Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.md) + [Terraform を使用して CloudWatch Synthetics Canary をデプロイする](deploy-cloudwatch-synthetics-canaries-by-using-terraform.md) + [ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation](deploy-chatops-solution-to-manage-sast-scan-results.md) + [Terraform を使用して CrewAI フレームワークで Amazon Bedrock にエージェンティックシステムを展開する](deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.md) + [AWS CodePipeline CI/CD パイプラインで AWS Glue ジョブをデプロイする](deploy-an-aws-glue-job-with-an-aws-codepipeline-ci-cd-pipeline.md) + [AWS CodePipeline、AWS CodeCommit、AWS CodeBuild を使用して、複数の AWS リージョンにコードをデプロイする](deploy-code-in-multiple-aws-regions-using-aws-codepipeline-aws-codecommit-and-aws-codebuild.md) + [Azure DevOps パイプラインからプライベート Amazon EKS クラスターにワークロードをデプロイする](deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.md) + [Terraform を使用して Amazon Redshift SQL クエリを実行する](execute-redshift-sql-queries-using-terraform.md) + [AWS Organizations 内の組織全体の AWS Backup レポートを CSV ファイルとしてエクスポートする](export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.md) + [Amazon EC2 インスタンスのリストのタグを CSV ファイルにエクスポートする](export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.md) + [Troposphere を使用して AWS Config マネージドルールを含む AWS CloudFormation テンプレートを生成します](generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.md) + [SageMaker ノートブックインスタンスに、別の AWS アカウントの CodeCommit リポジトリへの一時的なアクセスを許可する](give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.md) + [マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する](implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.md) + [マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する](implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.md) + [マルチアカウント DevOps 環境に Trunk 分岐戦略を実装する](implement-a-trunk-branching-strategy-for-multi-account-devops-environments.md) + [AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する](centralized-custom-checkov-scanning.md) + [K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md) + [CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md) + [AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合する](integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.md) + [Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md) + [Application Recovery Controller を使用して EMR クラスターのマルチ AZ フェイルオーバーを管理する](multi-az-failover-spark-emr-clusters-arc.md) + [AWS コードサービスと AWS KMS マルチリージョンキーを使用して、複数のアカウントとリージョンへのマイクロサービスのブルー/グリーンデプロイを管理](manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.md) + [AWS CloudFormation と AWS Config を使用して Amazon ECR リポジトリのワイルドカード権限をモニタリングする](monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.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) + [Amazon CloudWatch メトリクスを CSV ファイルに公開](publish-amazon-cloudwatch-metrics-to-a-csv-file.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) + [pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行する](run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.md) + [AWS CodePipeline と AWS CDK を使用して CI/CD パイプラインを設定する](set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.md) + [Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する](set-up-centralized-logging-at-enterprise-scale-by-using-terraform.md) + [cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定](set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.md) + [Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する](simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.md) + [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md) + [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md) + [AWS CodePipeline のサードパーティーの Git ソースリポジトリを使用する](use-third-party-git-source-repositories-in-aws-codepipeline.md) + [AWS CodePipeline を使用して Terraform の構成を検証するための CI/CD パイプラインを作成する](create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.md) + [その他のパターン](devops-more-patterns-pattern-list.md) # Backstage とセルフサービスの Amazon SageMaker AI テンプレートを使用して MLOps を高速化 *Amazon Web Services、Ashish Bhatt、Shashank Hirematt、Shivanshu Suryakar* ## 概要 機械学習オペレーション (MLOps) システムを使用している多くの組織は、ML インフラストラクチャのスケーリング、標準化、保護において大きな課題に直面しています。このパターンでは、オープンソースのデベロッパーポータルである [Backstage](https://backstage.io/) と [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)、および強化された Infrastructure as Code (IaC) モジュールを組み合わせることで、データサイエンスチームによる ML ワークフローの開発、デプロイ、管理の方法を向上させる革新的なアプローチを取り入れています。 このパターンの IaC モジュールは、GitHub [AWS AIOps モジュール](https://github.com/awslabs/aiops-modules/tree/main/modules/sagemaker)リポジトリで提供されています。これらのモジュールでは、ML インフラストラクチャをセットアップし一貫した ML 環境を作成する構築済みのテンプレートが提供されます。しかし、インフラストラクチャの専門知識が必要になるため、データサイエンティストがこれらのテンプレートをそのまま使用すると、苦労することがよくあります。Backstage などのデベロッパーポータルを追加すると、標準化された ML 環境を簡単にデプロイできるため、データサイエンティストは基盤となるインフラストラクチャの詳細を理解する必要はありません。 Backstage をセルフサービスプラットフォームとして使用し、事前設定された SageMaker AI テンプレートを統合することで、次のことが可能になります。 + ML イニシアチブの価値実現までの時間を短縮する。 + 一貫したセキュリティとガバナンスの実施を支援する。 + データサイエンティストに標準化された準拠環境を提供する。 + 運用上のオーバーヘッドとインフラストラクチャの複雑さを軽減する。 このパターンでは、MLOps の重要な課題に対処するためのソリューションと、組織の標準を維持しながらイノベーションを可能にするスケーラブルで反復可能なフレームワークも提供されます。 **ターゲットオーディエンス** このパターンは、組織内の ML、クラウドアーキテクチャ、プラットフォームエンジニアリングに携わる幅広いユーザーを対象としています。これには、以下が含まれます。 + **ML ワークフローのデプロイを標準化および自動化したいと考えている ML エンジニア**。 + 標準に準拠した事前設定済みの ML 環境へのセルフサービスアクセスを希望する**データサイエンティスト**。 + 社内デベロッパーのプラットフォームおよび共有インフラストラクチャの構築と保守を担当する**プラットフォームエンジニア**。 + MLOps 用の安全でスケーラブルかつ費用対効果の高いクラウドソリューションを設計する**クラウドアーキテクト**。 + 継続的インテグレーションと継続的デリバリー (CI/CD) のプラクティスを ML インフラストラクチャのプロビジョニングとワークフローに拡張することに関心のある **DevOps エンジニア**。 + ML イニシアチブを監督し、チームの生産性、ガバナンス、市場投入までの時間を向上させたいと考えている**技術部門のリーダーおよびマネージャー**。 MLOps の課題、SageMaker AI MLOps モジュール、および本パターンによって提供されるソリューションが ML チームのニーズにどう対応するのかの詳細については、「[追加情報](#accelerate-mlops-with-backstage-and-sagemaker-templates-additional)」のセクションを参照してください。 ## 前提条件と制限事項 **前提条件** + AWS Identity and Access Management にリソースをプロビジョニングするための (IAM) [ロールとアクセス許可](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#prerequisites) AWS アカウント + [Amazon SageMaker Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated.html)、[SageMaker プロジェクト](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-projects-whatis.html)、[SageMaker Pipelines](https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines-overview.html)、[SageMaker モデルレジストリ](https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html)の概念を理解していること + IaC の原則を理解しており、[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) などのツールを使用したことがあること **制限事項** + **テンプレートの対象範囲には制限があります**。現在、このソリューションは、より広範な [AIOps ソリューション](https://github.com/awslabs/aiops-modules)の SageMaker AI 関連の AIOps モジュールのみをサポートしています。Ray on Amazon Elastic Kubernetes Service (Amazon EKS)、MLflow、Apache Airflow、Amazon Bedrock のファインチューニングなどの他のモジュールは、Backstage テンプレートとしてまだご利用いただけません。 + **設定不可能なデフォルトの設定**。テンプレートでは、AIOps SageMaker モジュールからの固定のデフォルト設定がカスタマイズなしで使用されます。Backstage のインターフェイスから、インスタンスタイプ、ストレージサイズ、ネットワーク設定、セキュリティポリシーを変更することはできないため、特定のユースケースでは柔軟性が制限されます。 + **AWSのみをサポートしています**。プラットフォームは AWS デプロイ専用に設計されており、マルチクラウドシナリオをサポートしていません。の外部でクラウドサービスを使用する組織は AWS クラウド 、これらのテンプレートを ML インフラストラクチャのニーズに使用することはできません。 + **手動での認証情報管理**。デプロイごとに AWS 認証情報を手動で指定する必要があります。このソリューションでは、企業 ID プロバイダーとの統合 AWS IAM アイデンティティセンターや認証情報の自動ローテーションは提供されません。 + **ライフサイクル管理の制限**。このテンプレートには、自動クリーンアップポリシー、コスト最適化の推奨事項、インフラストラクチャのドリフト検出などの包括的なリソースライフサイクル管理機能はありません。デプロイされたリソースは、作成後に手動で管理およびモニタリングする必要があります。 ## アーキテクチャ 次の図は、SageMaker AI を使用して環境間で ML インフラストラクチャのデプロイを標準化および高速化する、統合デベロッパーポータルのソリューションアーキテクチャを示したものです。 ![\[Backstage、CNOE、GitHub Actions、Seed-Farmer を使用した統合デベロッパーポータルのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c16160cf-d637-423e-93a7-485ffbb28646/images/233adab3-83cf-42f3-a1de-72d0b8ade5ae.png) このアーキテクチャの詳細は以下のとおりです。 1. [AWS アプリケーションのモダナイゼーションブループリントは](https://github.com/aws-samples/appmod-blueprints.git)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) クラスターを使用してインフラストラクチャのセットアップを [Cloud Native Operational Excellence (CNOE)](https://cnoe.io/) フレームワークのベースとしてプロビジョニングします。この包括的なソリューションは、社内デベロッパー向けのスケーラブルなプラットフォーム (IDP) を提供することで、クラウドネイティブなインフラストラクチャ管理における複雑な課題を解消します。この設計図は、進化する組織のニーズに適応できる堅牢で柔軟なインフラストラクチャをセットアップする構造化されたアプローチを示しています。 1. CNOE オープンソースフレームワークは、DevOps ツールを統合し、統合されたプラットフォームエンジニアリングアプローチを通じてエコシステムの断片化を解決します。さまざまなツールとテクノロジーを組み合わせることで、クラウドネイティブ開発の複雑な環境を簡素化できるため、チームはツールチェーンの管理ではなくイノベーションに専念できます。このフレームワークは、開発ツールを選択、統合、管理するための標準化された方法を提供します。 1. CNOE では、Backstage は Amazon EKS クラスター内にすぐに使えるソリューションとしてデプロイされます。Backstage は、[Keycloak](https://www.keycloak.org/) による堅牢な認証と[、Argo CD](https://argo-cd.readthedocs.io/en/stable/) による包括的なデプロイワークフローにバンドルされています。この統合プラットフォームは、開発プロセスを管理するための一元化された環境を作成し、チームが複数の環境をまたいでインフラストラクチャとアプリケーションにアクセス、デプロイ、モニタリングできる一元的な場所として機能します。 1. GitHub リポジトリには、SageMaker AI ライフサイクル全体をカバーする、事前設定済みの AIOps ソフトウェアテンプレートが含まれています。これらのテンプレートは、SageMaker Studio のプロビジョニング、モデルトレーニング、推論パイプライン、モデルモニタリングなど、重要な ML インフラストラクチャのニーズに対処します。これらのテンプレートを使えば、ML イニシアチブを加速させ、さまざまなプロジェクトやチーム間で一貫性を確保することができます。 1. [GitHub Actions](https://github.com/features/actions) は、[Seed-Farmer](https://github.com/awslabs/seed-farmer) ユーティリティを介してリソースプロビジョニングを動的にトリガーする自動ワークフローを実装しています。このアプローチでは、Backstage カタログを AIOps モジュールリポジトリと統合させ、効率的なインフラストラクチャデプロイプロセスを作成します。自動化によって手動介入が軽減され、人的ミスを最小限に抑えることができ、さまざまな環境で迅速かつ一貫したインフラストラクチャの作成が可能になります。 1. [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) を使うことで、インフラストラクチャをコードとして定義してプロビジョニングすることができます。また、指定された AWS アカウント全体で反復可能な標準に準拠した安全なリソースをデプロイできます。このアプローチは、最小限の手動介入で最大限のガバナンスを実現できるため、標準化されたインフラストラクチャテンプレートを作成して、複製やバージョン管理、監査を簡単に行うことができます。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [Amazon SageMaker AI](https://docs.aws.amazon.com/sagemaker/) は、ML モデルを構築およびトレーニングし、これらの ML モデルを、稼働準備の整ったホストされている環境にデプロイするのに役立つマネージド型 ML サービスです。 **その他のツール** + [Backstage](https://backstage.io/) は、社内デベロッパー向けポータルの構築に役立つオープンソースフレームワークです。 + [GitHub Actions](https://github.com/features/actions) は、コードの構築、テスト、デプロイなどのタスクを含むソフトウェア開発のワークフローを自動化する CI/CD プラットフォームです。 **コードリポジトリ** 本パターンでは、次の GitHub リポジトリのコードとテンプレートを使用します。 + [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリ + [AWS AIOps モジュール](https://github.com/awslabs/aiops-modules)リポジトリの SageMaker AI 関連モジュール + [Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリ **実装** この実装では、[Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリから Backstage の本番稼働グレードのデプロイパターンを使用します。このアプローチは、セキュリティとスケーラビリティの AWS ベストプラクティスを組み込むと同時に、セットアッププロセスを大幅に簡素化します。 このパターンの[エピック](#accelerate-mlops-with-backstage-and-sagemaker-templates-epics)のセクションでは、実装アプローチの概要を説明します。詳細なデプロイ手順については、[Backstage を備えた AIOps 内部開発者プラットフォーム](https://github.com/aws-samples/sample-aiops-idp-backstage/)リポジトリにある包括的な[デプロイガイド](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md)を参照してください。この実装には以下が含まれます。 + 初期 Backstage プラットフォームのデプロイ + SageMaker ソフトウェアテンプレートと Backstage の統合 + Backstage テンプレートの使用と保守 本デプロイガイドには、継続的なメンテナンス、トラブルシューティング、プラットフォームのスケーリングに関するガイダンスも含まれています。 ## ベストプラクティス これらのベストプラクティスに従い、MLOps インフラストラクチャ実装のセキュリティ、ガバナンス、運用上の優秀性を確保してください。 **テンプレート管理** + ライブテンプレートに大きな変更を加えない。 + 本番環境にデプロイするときは事前に更新を十分にテストする。 + 明確かつ十分に立証されたテンプレートバージョンを維持する。 **セキュリティ** + GitHub Actions を特定のコミットセキュアハッシュアルゴリズム (SHAs) に固定し、サプライチェーン攻撃を防止する。 + きめ細かなアクセス許可を持つ最小特権の IAM ロールを使用する。 + 機密認証情報は [GitHub Secrets](https://docs.github.com/en/actions/concepts/security/secrets) および [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) に保存する。 + 認証情報をテンプレートでハードコードしない。 **ガバナンスと追跡** + 包括的なリソースタグ付け標準を実装する。 + 正確なコスト追跡とコンプライアンスモニタリングを有効にする。 + インフラストラクチャの変更に関する明確な監査証跡を維持する。 本ガイドは、Backstage、SageMaker AI、IaC モジュールを使用して上記のベストプラクティスを実装するための強固な基盤となるものです。 ## エピック ### ML 環境のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Backstage をデプロイする。 | このステップでは、 リポジトリ[の Modern Engineering AWS](https://github.com/aws-samples/appmod-blueprints) のブループリントを使用して、複数の を統合して ML ワークフロー用の一元化された IDP を作成する堅牢 AWS のサービス でスケーラブルなインフラストラクチャを構築します。デプロイガイドの[「Backstage deployment」セクション](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#backstage-deployment)の指示に従って、リポジトリのクローン作成、依存関係のインストール、環境変数 AWS CDK の設定のブートストラップ、Backstage プラットフォームのデプロイを行います。インフラストラクチャは、IDP コンポーネントをデプロイするためのコンテナオーケストレーションプラットフォームとして Amazon EKS を使用します。Amazon EKS アーキテクチャには、厳密なネットワーク分離を規定し、アクセスパターンを制御するための安全なネットワーク設定が含まれています。このプラットフォームには認証のメカニズムが統合され、サービスや環境間のユーザーアクセスを保護しています。 | プラットフォームエンジニア | | SageMaker AI テンプレートをセットアップする。 | このステップでは、GitHub の [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリのスクリプトを使用します。デプロイガイドの「[SageMaker テンプレートのセットアップ](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#sagemaker-template-setup)」のセクションの指示に従って、リポジトリのクローンを作成し、前提条件を設定し、セットアップスクリプトを実行します。このプロセスでは、Backstage との統合に必要な SageMaker AI テンプレートを含むリポジトリを作成します。 | プラットフォームエンジニア | | SageMaker AI** **テンプレートを Backstage と統合する。 | デプロイガイドの「[SageMaker テンプレートの統合](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#sagemaker-templates-integration)」セクションの指示に従って、SageMaker AI テンプレートを登録します。このステップでは、AIOps モジュール (前のステップの SageMaker AI テンプレート) を Backstage デプロイに統合し、ML インフラストラクチャのニーズをセルフサービスできるようにします。 | プラットフォームエンジニア | | Backstage の SageMaker AI テンプレートを使用する。 | デプロイガイドの「[SageMaker テンプレートの使用](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#using-sagemaker-templates)」セクションの指示に従って Backstage ポータルにアクセスし、SageMaker Studio で ML 環境を作成します。Backstage ポータルでは、SageMaker Studio 環境、SageMaker ノートブック、カスタム SageMaker プロジェクトテンプレート、モデルデプロイパイプラインのオプションなど、使用可能な SageMaker AI テンプレートの中から選択できます。設定パラメータを指定すると、プラットフォームは自動的に専用リポジトリを作成し、GitHub Actions と Seed-Farmer を通じて AWS リソースをプロビジョニングします。進行状況は、GitHub Actions ログと Backstage コンポーネントカタログからモニタリングできます。 | データサイエンティスト、データエンジニア、デベロッパー | ### ガバナンスとコンプライアンス用のテンプレートの管理 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SageMaker AI テンプレートを更新する。 | Backstage で SageMaker AI テンプレートを更新するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/accelerate-mlops-with-backstage-and-sagemaker-templates.html) | プラットフォームエンジニア | | テンプレートの複数のバージョンを作成および管理する。 | 破壊的変更やアップグレードの場合は、複数のバージョンの SageMaker AI テンプレートを作成することをお勧めします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/accelerate-mlops-with-backstage-and-sagemaker-templates.html) | プラットフォームエンジニア | ### ML 環境の拡張 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テンプレートの対象範囲を SageMaker AI を超えて拡張する。 | 現在のソリューションに実装されているのは SageMaker AI 関連の AIOps テンプレートのみです。[AIOps モジュール](https://github.com/awslabs/aiops-modules)を追加し、追加の AWS のサービス およびアプリケーション用のカスタムソフトウェアテンプレートを統合することで、ML 環境を拡張できます。これらは、Backstage のテンプレートデザイナーインターフェイスを使用するか、カスタムスキャフォールダーアクションを実装するか、標準メタデータでテンプレートリポジトリを維持することで作成できます。このプラットフォームは、一貫性を保つために、テンプレートのバージョニング、チーム間の共有、検証ワークフローをサポートしています。詳細については、[Backstage のドキュメント](https://backstage.io/docs/overview/what-is-backstage/)を参照してください。テンプレートの継承パターンを実装して、ベーステンプレートの特殊なバージョンを作成することもできます。この拡張性により、簡素化された開発者エクスペリエンスを維持し、組織の標準を維持しながら、SageMaker AI 以外のさまざまな AWS リソースやアプリケーションを管理できます。 | プラットフォームエンジニア | | 動的パラメータインジェクションを使用する。 | 現在のテンプレートは、デフォルトの設定をカスタマイズなしで使用し、Seed-Farmer CLI を実行して、デフォルトの変数を持つリソースをデプロイします。デフォルトの設定は、モジュールに固有の設定に動的パラメータインジェクションを使用することで拡張できます。 | プラットフォームエンジニア | | セキュリティとコンプライアンスを高める。 | AWS リソースの作成時のセキュリティを強化するために、ロールベースのアクセスコントロール (RBAC) に、シングルサインオン (SSO)、SAML、OpenID Connect (OIDC)、ポリシーをコード適用として統合することができます。 | プラットフォームエンジニア | | 自動リソースクリーンアップを追加する。 | 自動クリーンアップポリシーの機能を有効にしたり、インフラストラクチャドリフトの検出と修復を追加したりできます。 | プラットフォームエンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Backstage インフラストラクチャと SageMaker AI リソースを削除する。 | ML 環境の使用が完了したら、デプロイガイドの「[クリーンアップとリソース管理](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#cleanup-and-resource-management)」セクションの指示に従って Backstage のインフラストラクチャを削除し、ML 環境で SageMaker AI リソースを削除します。 | プラットフォームエンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS CDK ブートストラップの失敗 | AWS 認証情報とリージョン設定を確認します。 | | Amazon EKS クラスターアクセスの問題 | **kubectl** 設定と IAM アクセス許可を確認します。 | | Application Load Balancer の接続の問題 | セキュリティグループで、ポート 80/443 上の受信トラフィックが許可されていることを確認します。 | | SSH 統合の問題 | GitHub トークンのアクセス許可と組織アクセスを確認します。 | | SageMaker AI デプロイの失敗 | [AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html#limits_sagemaker)と IAM アクセス許可を確認する。 | ## 関連リソース + [プラットフォームエンジニアリング](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-caf-platform-perspective/platform-eng.html)(「*AWS クラウド導入フレームワーク: プラットフォームの視点*」ガイドを参照) + [Amazon SageMaker AI ドキュメント](https://docs.aws.amazon.com/sagemaker/) + [Backstage Software Templates](https://backstage.io/docs/features/software-templates/) (Backstage ウェブサイト) + [AIOps modules repository](https://github.com/awslabs/aiops-modules) (ML 用の再利用可能な IaC モジュールのコレクション) + [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリ + [Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリ + [Cloud Native Operational Excellence (CNOE) ウェブサイト](https://cnoe.io/) ## 追加情報 **ビジネス上の課題** MLOps イニシアチブを開始またはスケールしようとする多くの組織が、ビジネス上および技術上の課題に頻繁に遭遇していす。 + **一貫性のない環境**。開発環境とデプロイ環境が標準化されていないため、コラボレーションが困難になり、デプロイ上のリスクも高まります。 + **手動プロビジョニングのオーバーヘッド**。SageMaker Studio、Amazon Simple Storage Service (Amazon S3) バケット、IAM ロール、CI/CD パイプラインを使用して ML インフラストラクチャを手動でセットアップするのには時間がかかり、エラーも発生しやすく、データサイエンティストはモデル開発のコアタスクに専念することができません。 + **検出可能性と再利用性の欠如**。一元化されたカタログがなければ、既存の ML モデル、データセット、パイプラインを見つけることが困難になります。これにより、作業が重複し、再利用の機会が失われます。 + **複雑なガバナンスとコンプライアンス**。自動化されたガードレールがなければ、ML プロジェクトが組織のセキュリティポリシー、データプライバシー規制、医療保険の相互運用性と説明責任に関する法律 (HIPAA)、および一般データ保護規則 (GDPR) などのコンプライアンス標準に準拠しているかどうかを確認することが困難になります。 + **価値実現までの時間が長い**。これらの課題の累積的な影響により、ML プロジェクトのライフサイクルが長くなり、ML 投資によるビジネス価値の実現が遅れます。 + **セキュリティ上のリスク**。設定や手動プロセスに一貫性がなければ、セキュリティの脆弱性が発生し、最小特権やネットワーク分離の適用が困難になる可能性があります。 これらの問題は、開発サイクルを長引かせ、運用オーバーヘッドを増やし、セキュリティリスクをもたらします。反復的な性質を持つ ML には、反復可能なワークフローと効率的なコラボレーションが不可欠です。 Gartner 社による予測では、ソフトウェアエンジニアリング組織の 80% が 2026 年までにプラットフォームチームを持つと予想されています。(Gartner 社のウェブサイト[「Platform Engineering Empowers Developers to be Better, Faster, Happier](https://www.gartner.com/en/experts/top-tech-trends-unpacked-series/platform-engineering-empowers-developers)」を参照)。この予測では IDP がいかにしてソフトウェア配信を高速化するかに焦点が当てられています。IDP である Backstage は、チームが高品質のコードを迅速かつ安全に提供できるよう、複雑なインフラストラクチャへの命令の復元をサポートします。Backstage と強化された AIOps モジュールとを統合することで、事後対応型のトラブルシューティングから事前対応型の予防への移行が可能になります。 **MLOps SageMaker モジュール** このパターンに使用される GitHub リポジトリの [AIOps モジュールは](https://github.com/awslabs/aiops-modules)、再利用可能な強化された IaC AWS を通じて で MLOps を標準化するための貴重な基盤を提供します。これらのモジュールには、SageMaker プロジェクト、パイプライン、関連するネットワークおよびストレージリソースをプロビジョニングするためのベストプラクティスがカプセル化されているため、ML 環境の複雑さを軽減し、セットアップを高速化できます。これらのテンプレートをさまざまな MLOps ユースケースに使用することで、一貫性のある安全なデプロイパターンを確立し、ML ワークフローへの管理性および効率性が向上したアプローチを促進できます。 AIOps モジュールをそのまま使用すると、多くの場合、プラットフォームチームがこれらの IaC テンプレートをデプロイおよび管理しなければならなくなり、このことがセルフサービスアクセスを必要とするデータサイエンティストにとって課題となる可能性があります。使用可能なテンプレートの検出と理解、必要なパラメータの設定、デプロイのトリガーには、 AWS のサービス コンソールを操作するか、IaC ツールと直接やり取りする必要がある場合があります。これにより摩擦が生じ、ML タスクに専念したいデータサイエンティストの認知負荷が増加し、テンプレートが一元化された使いやすいインターフェイスで管理されていない場合には、一貫性のないパラメータ化や組織標準からの逸脱が生じる可能性があります。これらの強力な AIOps モジュールを Backstage などの IDP と統合すると、標準化された MLOps の構成要素を使用するための合理化されたセルフサービスエクスペリエンス、強化された検出可能性、強力なガバナンスコントロールが実現できるため、このような課題に対処できます。 **IDP としての Backstage** 社内デベロッパープラットフォーム (IDP) は、デベロッパーがアプリケーションを構築、デプロイ、管理する方法を簡素化および標準化するために、プラットフォームチームによって構築されたセルフサービスレイヤーです。インフラストラクチャの複雑さを抽象化し、デベロッパーは、統合されたインターフェイスを通じてツール、環境、サービスに簡単にアクセスできるようになります。 IDP の主な目標は、デベロッパーのエクスペリエンスと生産性を向上させることです。 + サービスの作成やデプロイなどのタスクでセルフサービスを有効にする。 + 標準のテンプレートを使用して一貫性とコンプライアンスを促す。 + 開発ライフサイクル全体でツールを統合する (CI/CD、モニタリング、ドキュメント)。 Backstage は、Spotify によって作成されたオープンソースのデベロッパーポータルであり、現在は Cloud Native Computing Foundation (CNCF) の一部となっています。ソフトウェアコンポーネント、ツール、ドキュメントを管理するための一元化された拡張可能なプラットフォームを提供し、組織が独自の IDP を構築するのを支援します。Backstage を使用すると、デベロッパーは次のことが行うことができます。 + ソフトウェアカタログを通じてすべての内部サービスを検出および管理する。 + スキャフォールダープラグインを使って、事前定義されたテンプレートを使用して新しいプロジェクトを作成する。 + CI/CD パイプライン、Kubernetes ダッシュボード、モニタリングシステムなどの統合ツールに一元的にアクセスできる。 + TechDocs を通じて一貫性のあるマークダウンベースのドキュメントを維持できる。 **よくある質問** **Backstage テンプレートを使用する場合と、SageMaker コンソールから SageMaker Studio を手動でデプロイする場合の違いは何ですか?** Backstage テンプレートには、組織のベストプラクティスに従った標準化された設定、Seed-Farmer と を使用した IaC の自動デプロイ AWS CDK、組み込みのセキュリティポリシーとコンプライアンス対策、GitHub を介した組織の開発者ワークフローとの統合など、手動 AWS コンソールデプロイよりもいくつかの利点があります。このテンプレートは、バージョン管理による再現可能なデプロイも作成します。これにより、さまざまなステージ (開発、ステージング、本番稼働) にまたがる環境を簡単に複製できるため、チーム間の一貫性が確保されます。さらに、テンプレートには自動クリーンアップ機能が含まれており、Backstage を通じて組織の ID 管理システムと統合されます。コンソールを介した手動デプロイには深い AWS 専門知識が必要であり、バージョン管理やテンプレートが提供するのと同じレベルの標準化とガバナンスは提供されません。このような理由から、コンソールのデプロイは、本番環境の ML 環境よりも 1 回限りの実験に適しています。 **Seed-Farmer とは何ですか? このソリューションがそれを使用しているのはなぜですか?** Seed-Farmer は、 を使用してインフラストラクチャモジュールを管理する AWS デプロイオーケストレーションツールです AWS CDK。このパターンでは、Seed-Farmer を使用します。これは、AI/ML ワークロード用に特別に設計された標準化された再利用可能なインフラストラクチャコンポーネントを提供し、 間の複雑な依存関係 AWS のサービス を自動的に処理し、異なる環境間で一貫したデプロイを保証するためです。 **これらのテンプレートを使用するには AWS CLI 、 をインストールする必要がありますか?** いいえ。コンピュータ AWS CLI に をインストールする必要はありません。テンプレートはクラウド内の GitHub Actions を通じて全体的に実行されます。Backstage インターフェイスを介して AWS 認証情報 (アクセスキー、シークレットキー、セッショントークン) を指定すると、デプロイは GitHub Actions 環境で自動的に行われます。 **SageMaker Studio 環境のデプロイにはどのくらいの時間がかかりますか?** SageMaker Studio のデプロイが完了するまでに通常 15～25 分かかります。これには、 AWS CDK ブートストラップ (2～3 分）、Seed-Farmer ツールチェーンのセットアップ (3～5 分）、リソースの作成 (10～15 分) が含まれます。正確な時間は、 AWS リージョン とネットワーク設定の複雑さによって異なります。 **同じ AWS アカウントに複数の SageMaker 環境をデプロイすることは可能ですか?** はい、可能です。各デプロイでは、テンプレートで指定したコンポーネント名に基づいて一意の名前のリソースが作成されます。ただし、 AWS のサービス クォータに注意してください。各アカウントでは、リージョンごとに SageMaker ドメインの数に制限があるため、複数の環境を作成する前に[クォータを確認してください](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html#limits_sagemaker)。 # Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する *Amazon Web Services、Ishwar Chauthaiwale、Anand Bukkapatnam Tirumala* ## 概要 クラウドネイティブなソリューションでは、一般的なインフラストラクチャオペレーションの自動化は、効率性と費用対効果の高い安全な環境を維持する上で重要な役割を果たします。オペレーションの手動処理は時間を要し、人為的ミスが発生しやすくなります。さらに、さまざまなレベルの AWS 専門知識を持つチームメンバーは、セキュリティプロトコルへの準拠を確保しながら、これらのタスクを実行する必要があります。このパターンは、Amazon Bedrock を使用して自然言語処理 (NLP) を通じて一般的な AWS インフラストラクチャオペレーションを自動化する方法を示しています。 本パターンは、複数の環境に生成 AI ベースのインフラストラクチャをデプロイする、再利用可能なモジュール式の安全なコードを開発するのに役立ちます。Infrastructure as Code (IaC) と自動化に重点を置くことで、バージョン管理、一貫したデプロイ、エラーの削減、プロビジョニングの高速化、コラボレーションの改善など、DevOps の主な利点を活用できるようになります。 このパターンは、以下 AWS のサービス を含むキーに関連するオペレーションをチームが管理できるようにする安全なアーキテクチャを実装しています。 + Amazon Simple Storage Service (Amazon S3) バケットのバージョニングを設定する + Amazon Relational Database Service (Amazon RDS) のスナップショット作成 + Amazon Elastic Compute Cloud (Amazon EC2) のインスタンス管理 このアーキテクチャは、安全な通信のために Amazon Virtual Private Cloud (Amazon VPC) エンドポイントとプライベートネットワークを採用し、 AWS Lambda プライベートサブネット内のタスクエグゼキュターとして機能します。Amazon S3 はデータ管理を提供し、包括的な AWS Identity and Access Management (IAM) ロールとアクセス許可を実装して、適切なアクセスコントロールを確保します。このソリューションにはチャット履歴機能がないため、チャットは保存されません。 ## 前提条件と制限事項 + アクティブ AWS アカウント。 + アクセスをセキュリティで保護および制御するには、適切なアクセスコントロール対策を講じる必要があります。アクセスコントロールの例としては AWS Systems Manager、 の使用、基盤モデルアクセス、デプロイ用の IAM ロール、サービスベースのロール、Amazon S3 バケットへのパブリックアクセスの無効化、デッドレターキューの設定などがあります。 + AWS Key Management Service (AWS KMS) [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)。 + AWS Command Line Interface (AWS CLI) バージョン 2 以降、デプロイ環境に[インストール](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)。 + Terraform AWS Provider バージョン 4 以降[がインストールされ](https://registry.terraform.io/providers/-/aws/latest/docs/guides/version-4-upgrade)、設定されています。 + Terraform バージョン 1.5.7 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/install)こと。 + 不正アクセスからの保護とデータ整合性の維持のため、[Amazon Bedrock でエージェントのアクショングループの OpenAPI スキーマを確認して定義](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-api-schema.html)します。 + 必要な Amazon Titan Text Embeddings v2 と Claude 3.5 Sonnet または Claude 3 Haiku 基盤モデルのいずれか AWS アカウント に対して で[有効になっているアクセス](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access-modify.html)。 [https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)デプロイの失敗を回避するには、ターゲットデプロイ AWS リージョン [が必要なモデルをサポート](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)していることを確認します。 + [AWS Well Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html) のベストプラクティスに従って設定された仮想プライベートクラウド (VPC)。 + [Amazon Responsible AI ポリシー](https://aws.amazon.com/ai/responsible-ai/policy/)のレビューが完了していること。 **製品バージョン** + Amazon Titan Text Embeddings V2 + Anthropic Claude 3.5 Sonnet or Claude 3 Haiku + Terraform AWS プロバイダーバージョン 4 以降 + Terraform バージョン 1.5.7 以降 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[Amazon Bedrock を使用して一般的な AWS インフラストラクチャオペレーションを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/924e503f-bfc5-4452-abdf-d72a58d4d36f/images/bd56ad29-b435-4543-8ee8-dc4e1d38df18.png) ソリューションアーキテクチャは、自然言語リクエストを処理し、対応する AWS オペレーションを実行するために連携する複数のレイヤーで構成されています。 1. ユーザーは、Amazon Bedrock のチャットコンソールからオペレーションリクエストを行います。 1. チャットボットはリクエスト処理に Amazon Bedrock ナレッジベースを使用します。こちらは自然言語処理用の Amazon Titan Text Embeddings v2 モデルを実装しています。 1. ユーザープロンプトにアクションリクエストが含まれている場合、Amazon Bedrock アクショングループは、実行ロジックに Anthropic Claude 3 Haiku または Claude 3.5 Sonnet モデル (ユーザーの選択による) のいずれかを使用し、OpenAPI スキーマを介してオペレーションを定義します。 1. アクショングループは、安全なサービス通信 AWS PrivateLink のために を使用して Amazon VPC [エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html)に到達します。 1. AWS Lambda 関数は、Amazon Bedrock サービスの Amazon VPC エンドポイントを介して到達します。 1. Lambda 関数は主要な実行エンジンです。Lambda 関数は、リクエストに基づいて API を呼び出し、 AWS のサービスに対してアクションを実行します。また、Lambda 関数はオペレーションのルーティングと実行も処理します。 1. Lambda 関数からの API リクエスト AWS のサービス の取得と、対応するオペレーションが実行されます。 1. Lambda 関数は、Amazon Bedrock によって理解される出力ペイロードを計算します。 1. このペイロードは、安全なサービス通信を行うため、PrivateLink を使用して Amazon Bedrock に送信されます。Amazon Bedrock で使用される大規模言語モデル (LLM) は、このペイロードを解釈し、人間が理解できる形式に変換します。 1. その後、出力は Amazon Bedrock チャットコンソール上でユーザーに対して表示されます。 このソリューションでは、次の主要なオペレーションを有効にします。 + Amazon S3 – バージョン管理のためにバケットのバージョニングを有効にします。 + Amazon RDS – バックアップ用のデータベーススナップショットを作成します。 + Amazon EC2 – インスタンスを一覧表示し、インスタンスの開始と停止を制御します。 ## ツール **AWS のサービス** + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、主要な AI スタートアップや Amazon が提供する高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにするフルマネージド型サービスです。 + [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/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-overview.html) は、Amazon OpenSearch Service 用のオンデマンドサーバーレス設定です。 + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から他の VPC 内のサービスへの単方向のプライベート接続の確立に役立ちます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub の [aws-samples/infra-ops-orchestrator](https://github.com/aws-samples/infra-ops-orchestrator) リポジトリから入手できます。 ## ベストプラクティス + Lambda 実行ログを定期的にモニタリングします。詳細については、「[Lambda 関数をモニタリングおよびトラブルシューティングする](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)」を参照してください。ベストプラクティスの詳細については、「 [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)」を参照してください。 + セキュリティ設定を定期的に見直し、組織の要件に準拠していることを確認します。詳細については、「[セキュリティのベストプラクティス](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-bp.html)」を参照してください。 + 最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 解決策をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | ローカルマシンにリポジトリのクローンを作成するときは次のコマンドを実行します。
git clone "git@github.com:aws-samples/infra-ops-orchestrator.git"
cd infra-ops-orchestrator
| AWS DevOps、DevOps エンジニア | | 環境変数を編集します。 | クローンされたリポジトリのルートディレクトリで `terraform.tfvars` file. を編集します。`[XXXXX]` に示されたプレースホルダーを確認し、お使いの環境に応じて更新します。 | AWS DevOps、DevOps エンジニア | | インフラストラクチャを作成する | インフラストラクチャを作成するには、次のコマンドを実行します。
terraform init
terraform plan
実行計画を注意深く確認します。計画された変更が許容できる場合は、次のコマンドを実行します。
terraform apply --auto-approve
| AWS DevOps、DevOps エンジニア | ### ソリューションにアクセスする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソリューションにアクセスする | デプロイが成功したら、以下のステップに従ってチャットベースのインターフェイスを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-infrastructure-operations-by-using-amazon-bedrock.html) | AWS DevOps、DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 作成したリソースを削除します。 | このパターンによって作成されたすべてのインフラストラクチャを削除するには、次のコマンドを実行します。
terraform plan -destroy
破棄計画を注意深く確認してください。計画された削除が許容される場合は、次のコマンドを実行します。
terraform destroy
注: このコマンドによって、本パターンで作成したリソースは完全に削除されます。リソースを削除する前にコマンドから確認を求められます。 | AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | エージェントの動作 | この問題の詳細については、Amazon Bedrock ドキュメントの「[Test and troubleshoot agent behavior](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 | | Lambda ネットワークの問題 | これらの問題の詳細については、「Lambda ドキュメント」の「[Lambda でのネットワーク問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 | | IAM アクセス許可 | これらの問題の詳細については、IAM ドキュメントの「[IAM のトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html)」を参照してください。 | ## 関連リソース + [Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) + [Define OpenAPI schemas for your agent's action groups in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-api-schema.html) + [バケットでのバージョニングの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html) + [Amazon Bedrock エージェントの仕組み](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html) + [Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/aws-privatelink.html) + [経由でサービスに安全にアクセスする AWS PrivateLink](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/aws-privatelink.html) + [Amazon EC2 インスタンスの停止と起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) + [アクショングループを使用して、エージェントが実行するアクションを定義する](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-create.html) # Terraform を使用してロードバランサーエンドポイントが変更されたときの CloudFront 更新を自動化 *Amazon Web Services、Tamilselvan P、Mohan Annam、Naveen Suthar* ## 概要 Amazon Elastic Kubernetes Service (Amazon EKS) のユーザーが Helm チャートを使用してイングレス設定を削除したのち再度インストールすると、新しい Application Load Balancer (ALB) が作成されます。この問題は、Amazon CloudFront が古い ALB の DNS レコードを参照し続けることが原因で発生します。そのためこのエンドポイント宛てのサービスに到達できません。(このワークフローの問題に関する詳細は[追加情報](#automate-cloudfront-updates-when-load-balancer-endpoints-change-additional)を参照してください)。 この問題を解決するために、このパターンでは Python で開発されたカスタム AWS Lambda 関数の使用について説明します。この Lambda 関数は、Amazon EventBridge ルールを使用して新しい ALB がいつ作成されるかを自動的に検出します。を使用して AWS SDK for Python (Boto3)、関数は新しい ALB の DNS アドレスで CloudFront 設定を更新し、トラフィックが正しいエンドポイントにルーティングされるようにします。 この自動化されたソリューションは、追加のルーティングなしで、また遅延を発生させることなくサービスの継続性を維持します。このプロセスにより、基盤となるインフラストラクチャが変更されても、CloudFront は常に正しい ALB DNS エンドポイントを参照することができます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + Helm を使用して Amazon EKS にデプロイされる、テスト用および検証用のサンプルウェブアプリケーション。詳細については、Amazon EKS ドキュメントの「[Helm を使用して Amazon EKS にアプリケーションをデプロイする](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」を参照してください。 + Helm の[Ingress コントローラー](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)が作成した ALB に、呼び出しをルーティングするように CloudFront を設定します。詳細については、Amazon EKS ドキュメントの「[Install AWS Load Balancer Controller with Helm](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)」および CloudFront ドキュメントの[「Application Load Balancer へのアクセスを制限する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)」を参照してください。 + ローカルワークスペースに[インストール](https://developer.hashicorp.com/terraform/install?product_intent=terraform)され設定された Terraform。 **制限事項** + 一部の 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)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + Terraform バージョン 1.0.0 以降 + Terraform [AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) バージョン 4.20 以降 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[EventBridge ルールで検出された新しい ALB DNS アドレスで CloudFront を更新するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/03c30b18-4dd7-4dd4-b960-5a5cc58cec63/images/28854767-0902-4398-80af-b19141dd94e4.png) 以下の手順で実行します。 1. Amazon EKS Ingress コントローラーは、Helm の再起動またはデプロイが行われるたびに、新しい Application Load Balancer (ALB) を作成します。 1. EventBridge は ALB の作成イベントを検索します。 1. ALB の作成イベントは Lambda 関数をトリガーします。 1. Lambda 関数は python 3.9 に基づいてデプロイされており、boto3 API を使用して を呼び出します AWS のサービス。Lambda 関数は、ロードバランサーの作成イベントから受信した最新のロードバランサー DNS 名で CloudFront エントリを更新します。 ## ツール **AWS のサービス** + [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 **その他のツール** + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub の [aws-cloudfront-automation-terraform-samples](https://github.com/aws-samples/aws-cloudfront-automation-terraform-samples) リポジトリで利用できます。 ## エピック ### ローカルワークステーションのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Git CLI をセットアップして設定します。 | ローカルワークステーションに Git コマンドラインインターフェイス (CLI) をインストールして設定するには、Git ドキュメントの「[Getting Started – Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」の手順に従います。 | DevOps エンジニア | | プロジェクトフォルダを作成し、ファイルを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア | ### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソリューションのデプロイ | ターゲットにリソースをデプロイするには AWS アカウント、次のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイを検証する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア | ### インフラストラクチャをクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | プロバイダー認証情報の検証中にエラーが発生しました。 | ローカルマシンから Terraform `apply` または `destroy` コマンドを実行すると、次のようなエラーが発生する場合があります。
Error: configuring Terraform AWS Provider: error validating provider 
credentials: error calling sts:GetCallerIdentity: operation error STS: 
GetCallerIdentity, https response error StatusCode: 403, RequestID: 
123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: 
The security token included in the request is invalid.
このエラーは、ローカルマシンの設定で使用されている認証情報のセキュリティトークンの有効期限が切れていることが原因です。エラーを解決するには、 AWS Command Line Interface (AWS CLI) ドキュメントの[「設定の設定と表示](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)」を参照してください。 | ## 関連リソース **AWS リソース** + [Application Load Balancer へのアクセスを制限する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) + [AWS Load Balancerコントローラーを使用してインターネットトラフィックをルーティングする](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) Terraformのドキュメント + [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) + 「[Terraform のインストール](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)」 + [Remote State](https://developer.hashicorp.com/terraform/language/state/remote) ## 追加情報 **問題のあるワークフロー** ![\[CloudFront で古い ALB DNS エントリを生成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/03c30b18-4dd7-4dd4-b960-5a5cc58cec63/images/bb3c2c93-c749-435d-9b1d-2bbf6f0cf085.png) この図表は、次のワークフローを示しています: 1. ユーザーがアプリケーションにアクセスすると、呼び出しは CloudFront に送信されます。 1. CloudFront は、呼び出しをそれぞれの Application Load Balancer (ALB) にルーティングします。 1. ALB には、アプリケーションポッドの IP アドレスであるターゲット IP アドレスが含まれています。そこから、ALB はユーザーに期待される結果を提供します。 ただし、このワークフローには問題があります。アプリケーションのデプロイは Helm チャートを通じて行われます。デプロイがあるたびに、または誰かが Helm を再起動すると、それぞれのイングレスも再作成されます。その結果、外部のロードバランサーコントローラーが ALB を再作成します。また、再作成のたびに、ALB は別の DNS 名で再作成されます。このため、CloudFront に最初の設定で古いエントリが作成されます。このエントリのためにユーザーはアプリケーションにアクセスできなくなります。この問題はユーザーのダウンタイムにつながります。 **代替の解決策** もう 1 つの可能な解決策は、ALB の[外部 DNS](https://github.com/kubernetes-sigs/external-dns) を作成し、CloudFront の Amazon Route 53 プライベートホストゾーンエンドポイントを指すことです。ただし、このアプローチではアプリケーションフローに別のホップが追加されるため、アプリケーションに遅延が発生する可能性があります。このパターンの Lambda 関数ソリューションは、現在のフローを中断しません。 # GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する *Amazon Web Services、Vanitha Dontireddy、Sarat Chandra Pothula* ## 概要 注: 2025 年 11 月 7 日現在、Amazon CodeGuru Reviewer で新しいリポジトリの関連付けを作成することはできません。CodeGuru Reviewer と同様の機能を持つサービスの詳細については、[CodeGuru Reviewer ドキュメントの「Amazon CodeGuru Reviewer の可用性の変更](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html)」を参照してください。 CodeGuru このパターンは、GitHub Actions を通じてオーケストレーションされた Python AWS Cloud Development Kit (AWS CDK) アプリケーションの Amazon CodeGuru 自動コードレビューの統合を示しています。このソリューションは、Python で定義されたサーバーレスアーキテクチャ AWS CDK をデプロイします。開発パイプライン内のエキスパートコード分析を自動化することで、このアプローチは Python AWS CDK プロジェクトに対して次のことを実行できます。 + コードの品質を向上させる + ワークフローを効率化する + サーバーレスコンピューティングの利点を最大化する ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + AWS Command Line Interface (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)済み。 + 有効な GitHub アカウントと、ワークフローの読み取りおよび書き込み権限ならびに PR ワークフローが正常に動作することを確保するための GitHub アクションによるプルリクエスト (PR) の作成機能を備えた GitHub リポジトリ。 + AWS アカウントにソリューションをデプロイするための GitHub アクションの OpenID Connect (OIDC) ロール。ロールを作成するには [AWS CDK コンストラクト](https://github.com/aws-samples/github-actions-oidc-cdk-construct)を使用します。 **制限事項** + Amazon CodeGuru Profiler は、すべての Java 仮想マシン (JVM) 言語 (Scala や Kotlin など) およびランタイム、ならびに Python 3.6 以降で記述された[アプリケーションをサポート](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html#what-is-language-support)しています。 + Amazon CodeGuru Reviewer は、、Bitbucket AWS CodeCommit、GitHub、GitHub Enterprise Cloud、GitHub Enterprise Server のソースプロバイダーからのみ、Java および Python コードリポジトリとの[関連付けをサポートします](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/working-with-repositories.html)。また、Amazon Simple Storage Service (Amazon S3) リポジトリは、GitHub アクションを通じてのみサポートされています。 + 継続的インテグレーションと継続的デプロイ (CI/CD) のパイプライン中に結果を自動的に出力する方法はありません。このパターンでは、代替の方法として GitHub アクションを使用し検出結果を処理および表示します。 + 一部の 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)」を参照し、サービスのリンクを選択してください。 ## アーキテクチャ このソリューション用のアーキテクチャを次の図に示します。 ![\[GitHub アクションを使用して AWS CDK Python アプリケーションの CodeGuru コードレビューを統合するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c5395e3e-ff2a-41cf-bd64-c73cc928b60b/images/18f880a2-9bc3-4d71-a598-bb83b68ee383.png) 図に示すように、開発者がレビュー用のプルリクエスト (PR) を作成すると、GitHub アクションが次のステップをトリガーします。 1. IAM ロールの引き受け – パイプラインは、GitHub Secrets で指定された IAM ロールを使用してデプロイタスクを実行します。 1. コード分析 + CodeGuru Reviewer は、Amazon S3 バケットに保存されているコードを分析します。不具合を特定し、修正と最適化に関する推奨事項を提供します。 + CodeGuru Security は、ポリシー違反と脆弱性をスキャンします。 1. 検出結果の確認 + パイプラインが、コンソールの出力に検出結果ダッシュボードへのリンクを出力します。 + 重要度が重大である場合、パイプラインは直ちに失敗します。 + 重要度が高、普通、低である場合、パイプラインは次のステップに進みます。 1. PR の承認 + レビュー担当者は、PR を手動で承認する必要があります。 + PR が拒否されると、パイプラインは失敗し、それ以降のデプロイステップが停止します。 1. CDK デプロイ – PR の承認後、CDK デプロイプロセスが開始します。以下の AWS のサービス および リソースを設定します。 + CodeGuru Profiler + AWS Lambda 関数 + Amazon Simple Queue Service (Amazon SQS) キュー 1. データ生成のプロファイリング – CodeGuru Profiler 用に十分なプロファイリングデータを生成するには: + パイプラインは、Amazon SQS キューに定期的にメッセージを送信することで、Lambda 関数を複数回呼び出します。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDK アプリの操作に役立つコマンドラインクラウド開発キットです。 + [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) は、ライブアプリケーションからランタイムパフォーマンスデータを収集し、アプリケーションのパフォーマンスを微調整する上で役立つ推奨事項を提供します。 + [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) は、プログラム解析と機械学習により、開発者が検出するのが難しい潜在的な不具合を検出します。次に、CodeGuru Profiler は Java および Python コードを改善するための提案を提供します。 + Amazon CodeGuru Security は、機械学習を使用してセキュリティポリシー違反と脆弱性を検出する静的アプリケーションセキュリティツールです。セキュリティリスクに対処するための提案を行い、アプリケーションのセキュリティ態勢を追跡できるようにメトリクスを生成します。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + 「[Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) 」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。 + 「[Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 」は、どのようなデータの量であっても、保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 **その他のツール** + [GitHub アクション](https://docs.github.com/en/actions/writing-workflows/quickstart)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub アクションを使用することで、生成、テスト、デプロイのパイプラインを自動化できます。 **コードリポジトリ** 本パターン用のコードは、GitHub の [amazon-codeguru-suite-cdk-python](https://github.com/aws-samples/amazon-codeguru-suite-cdk-python) リポジトリから入手できます。 ## ベストプラクティス + 「[Best practices for developing and deploying cloud infrastructure with the AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)」に従います。 + GitHub Actions ワークフロー AWS のサービス で を使用する場合は、[IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)に従います。 + リポジトリコードに認証情報を保存しない。 + 一時的な認証情報を受け取るときは [IAM ロールを引き受け](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)、可能な限り一時的な認証情報を使用する。 + GitHub アクションのワークフローで使用される IAM ロールに[最小特権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。アクセス権限は、GitHub アクションのワークフローでアクションを実行するために必要なもののみを付与する。 + GitHub アクションのワークフローで使用される IAM ロールの[アクティビティをモニタリングする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)。 + 有効期間の長い認証情報を使用するときは定期的にローテーションする。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS 認証情報を設定します。 | スタックをデプロイする AWS アカウント と AWS リージョン を定義する変数をエクスポートするには、次のコマンドを実行します。
export CDK_DEFAULT_ACCOUNT=<12-digit AWS account number>
export CDK_DEFAULT_REGION=
の AWS 認証情報 AWS CDK は、環境変数を通じて提供されます。 | AWS DevOps、DevOps エンジニア | | リポジトリのクローン作成 | ローカルマシンにリポジトリのクローンを作成するときは次のコマンドを実行します。
git clone https://github.com/aws-samples/amazon-codeguru-suite-cdk-python.git
| AWS DevOps、DevOps エンジニア | | CDK Toolkit をインストールします。 | CDK Toolkit がインストールされていることを確認し、バージョンをチェックするには、次のコマンドを実行します。 
cdk --version
CDK Toolkit のバージョンが 2.27.0 より前の場合は、次のコマンドを入力してバージョン 2.27.0 に更新します。
npm install -g aws-cdk@2.27.0
CDK Toolkit が*インストールされていない*場合は、次のコマンドを実行してインストールします。
npm install -g aws-cdk@2.27.0 --force
| AWS DevOps、DevOps エンジニア | | 必要な依存ファイルをインストールします。 | 必要なプロジェクトの従属関係をインストールには、次のコマンドを実行します。
python -m pip install --upgrade pip
pip install -r requirements.txt
| AWS DevOps、DevOps エンジニア | | CDK 環境をブートストラップします。 | AWS CDK 環境を[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)するには、以下のコマンドを実行します。
npm install
npm run cdk bootstrap "aws://${ACCOUNT_NUMBER}/${AWS_REGION}"
環境を正常に起動すると、次の出力が表示されるはずです。
⏳  Bootstrapping environment aws://{account}/{region}...
✅  Environment aws://{account}/{region} bootstrapped
| AWS DevOps、DevOps エンジニア | ### CDK アプリをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK アプリケーションを合成します。 | AWS CDK アプリケーションを合成するには、次のコマンドを実行します。
cdk synth
このコマンドの詳細については、 AWS CDK ドキュメントの[「cdk 合成](https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-synth.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | | リソースのデプロイ | コマンドをデプロイするには次のコマンドをデプロイします。
cdk deploy --require-approval never
`--require-approval never` フラグは、CDK がすべての変更を自動的に承認して実行することを意味します。これには、CDK が通常手動レビューを必要とするものとしてフラグを付ける変更 (IAM ポリシーの変更やリソースの削除など) が含まれます。本番環境で `--require-approval never` フラグを使用するときは、事前に CDK コードと CI/CD パイプラインが十分にテストされ安全であることを確認してください。 | AWS DevOps、DevOps エンジニア | ### GitHub シークレットと個人用アクセストークンを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub で必要なシークレットを作成します。 | GitHub Actions ワークフローがリポジトリのコードに機密情報を公開することなく AWS リソースに安全にアクセスできるようにするには、シークレットを作成します。GitHub for `ROLE_TO_ASSUME`、`CodeGuruReviewArtifactBucketName`、`AWS_ACCOUNT_ID` でシークレットを作成するには、GitHub アクションのドキュメントにある「[Creating secrets for a repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository)」の手順に従います。以下は、これらの変数の詳細です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.html) | AWS DevOps、DevOps エンジニア | | パーソナルアクセストークンを作成する | GitHub アクションのワークフローが GitHub を認証して操作するための安全な方法を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.html) | AWS DevOps、DevOps エンジニア | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | Python AWS CDK アプリケーションをクリーンアップするには、次のコマンドを実行します。
cdk destroy --all
| DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ダッシュボードの検出結果へのリンクを表示します。 | CI/CD パイプライン中に結果を出力することはできません。このパターンでは、代替の方法として GitHub アクションを使用し検出結果を処理および表示します。 | ## 関連リソース **AWS リソース** + [AWS クラウド開発キット](https://aws.amazon.com/cdk/) + [Amazon CodeGuru ドキュメント](https://docs.aws.amazon.com/codeguru/) + [Amazon S3](https://aws.amazon.com/s3/) + [AWS Identity and Access Management](https://aws.amazon.com/iam/) + [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) + [とは AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) **GitHub ドキュメント** + [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) + [GitHub Actions](https://github.com/features/actions) + [ワークフローの再利用](https://docs.github.com/en/actions/using-workflows/reusing-workflows) + [ワークフローのトリガー](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow)  # GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する *Keshav Ganesh、Amazon Web Services* ## 概要 このパターンは、マルチリポジトリの継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを使用して AWS Supply Chain データレイクをデプロイおよび管理するための自動化されたアプローチを提供します。これは、GitHub Actions ワークフローを使用した自動デプロイと、Terraform を使用した手動デプロイの 2 つのデプロイ方法を示しています。どちらのアプローチもInfrastructure as Code (IaC) に Terraform を使用し、自動化された方法で GitHub Actions と JFrog Artifactory を追加して CI/CD 機能を強化します。 このソリューションは AWS Supply Chain、 AWS Lambdaと Amazon Simple Storage Service (Amazon S3) を活用してデータレイクインフラストラクチャを確立し、いずれかのデプロイ方法を使用して設定とリソースの作成を自動化します。この自動化により、手動の設定手順がなくなり、環境間で一貫したデプロイが保証されます。さらに、 は抽出、変換、ロード (ETL) に関する深い専門知識の必要性 AWS Supply Chain を排除し、Amazon Quick Sight を活用したインサイトと分析を提供できます。 このパターンを実装することで、組織はバージョン管理された自動化されたプロセスを通じて、デプロイ時間を短縮し、Infrastructure as Code を維持し、サプライチェーンのデータレイクを管理できます。マルチリポジトリアプローチは、きめ細かなアクセスコントロールを提供し、さまざまなコンポーネントの独立したデプロイをサポートします。チームは、既存のツールやプロセスに最適なデプロイ方法を選択できます。 ## 前提条件と制限 **前提条件** ローカルマシンに以下がインストールされていることを確認します。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) バージョン 2 + [GitHub CLI](https://docs.github.com/en/get-started/git-basics/set-up-git) + [Python](https://www.python.org/downloads/) v3.13 + [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) v1.12 以降 デプロイする前に、以下が設定されていることを確認します。 + アクティブ AWS アカウント。 + AWS アカウント AWS リージョン 選択した の に 2 [つのプライベートサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html)を持つ [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)。 + 次のサービスへのデプロイに使用される AWS Identity and Access Management (IAM) ロールの十分なアクセス許可。 + AWS Supply Chain – データセットや統合フローなどのコンポーネントをデプロイし、 からアクセスする場合は、フルアクセスが推奨されます AWS マネジメントコンソール。 + Amazon CloudWatch Logs – CloudWatch ロググループの作成と管理用。 + Amazon Elastic Compute Cloud (Amazon EC2) – Amazon EC2 セキュリティグループと Amazon Virtual Private Cloud (Amazon VPC) エンドポイント用。 + Amazon EventBridge – が使用します AWS Supply Chain。 + IAM – AWS Lambda サービスロールの作成用。 + AWS Key Management Service (AWS KMS) – Amazon S3 アーティファクトバケットと Amazon S3 AWS Supply Chain ステージングバケット AWS KMS keys に使用される へのアクセス用。 + AWS Lambda – AWS Supply Chain コンポーネントをデプロイする Lambda 関数を作成する場合。 + Amazon S3 – Amazon S3 アーティファクトバケット、サーバーアクセスログバケット、 AWS Supply Chain ステージングバケットへのアクセス用。手動デプロイを使用している場合は、Amazon S3 Terraform アーティファクトバケットのアクセス許可も必要です。 + Amazon VPC – VPC の作成と管理用。 デプロイに GitHub Actions ワークフローを使用する場合は、以下を実行します。 + 前述のアクセス許可を使用して、IAM ロールの [OpenID Connect (OIDC)](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws#configuring-the-role-and-trust-policy) を設定します。 + にアクセスするための同様のアクセス許可を持つ IAM ロールを作成します AWS マネジメントコンソール。詳細については、IAM [ドキュメントの「IAM ユーザーにアクセス許可を付与するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。 手動デプロイを行う場合は、以下を実行します。 + 前述のアクセス許可を持つ IAM ロールを引き受ける IAM ユーザーを作成します。詳細については、IAM [ドキュメントの「IAM ユーザーにアクセス許可を付与するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。 + ローカルターミナルで [ロールを引き受け](https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-role.html)ます。 デプロイに GitHub Actions ワークフローを使用する場合は、以下を設定します。 + ホスト名、ログインユーザー名、ログインアクセストークンを取得する [JFrog Artifactory アカウント](https://jfrog.com/artifactory/?utm_source=google&utm_medium=cpc_search&utm_campaign=SearchDSKBrandAPACIN202506&utm_term=jfrog%20cloud&gads_network=g&utm_content=u-bin&gads_campaign_id=22674833884&gads_adgroup_id=184501797241&gads_extension_id=233003714635&gads_target_id=aud-312135645780:kwd-1598615735032&gads_matchtype=b&gad_source=1&gad_campaignid=22674833884&gbraid=0AAAAADqV85U5B37iapTR9IIFHBvydF5AQ&gclid=CjwKCAjwiY_GBhBEEiwAFaghvqdNV-odNLZXPHjT7NAwf8lA-QuMtg666hgvDW1oCJ4nn7wvf869_xoCW4IQAvD_BwE)。 + アーティファクトを保存するための [JFrog プロジェクトキーとリポジトリ](https://jfrog.com/help/r/jfrog-platform-administration-documentation/step-1-set-up-a-new-project)。 **制限事項** + AWS Supply Chain インスタンスは、複雑なデータ変換手法をサポートしていません。 + AWS Supply Chain は、組み込みの分析とインサイトを提供するため、サプライチェーンドメインに最適です。他のドメインの場合、 AWS Supply Chain はデータレイクアーキテクチャの一部としてデータストアとして使用できます。 + このソリューションで使用される Lambda 関数は、本番環境のデプロイで API の再試行とメモリ管理を処理するために拡張する必要がある場合があります。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ このソリューションは、自動化された GitHub Actions ワークフローを使用するか、Terraform を使用して手動でデプロイできます。 **GitHub Actions を使用した自動デプロイ** 次の図は、GitHub Actions ワークフローを使用する自動デプロイオプションを示しています。JFrog Artifactory はアーティファクトの管理に使用されます。マルチリポジトリデプロイで使用するリソース情報と出力を保存します。 ![\[GitHub Actions ワークフローと JFrog を使用する自動デプロイオプション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2f0b78b0-a174-4703-b533-d66b3fb005e0/images/d454a5c5-ed51-421c-a87f-ff74cfcb30be.png) **Terraform を使用した手動デプロイ** 次の図は、Terraform による手動デプロイオプションを示しています。JFrog Artifactory の代わりに、Amazon S3 がアーティファクト管理に使用されます。 ![\[Terraform と Amazon S3 を使用した手動デプロイオプション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2f0b78b0-a174-4703-b533-d66b3fb005e0/images/1130e728-44d5-4ae7-9586-1e497f54352a.png) **デプロイのワークフロー** 図は次のワークフローを示しています。 1. 次のいずれかのデプロイ方法を使用して、 AWS Supply Chain サービスデータセットのインフラストラクチャとデータベースをデプロイします。 + **自動デプロイ** – GitHub Actions ワークフローを使用してすべてのデプロイステップを調整し、JFrog Artifactory を使用してアーティファクトを管理します。 + **手動デプロイ** – デプロイステップごとに Terraform コマンドを直接実行し、Amazon S3 を使用してアーティファクトを管理します。 1. AWS Supply Chain サービスオペレーションに必要なサポート AWS リソースを作成します。 + Amazon VPC エンドポイントとセキュリティグループ + AWS KMS keys + CloudWatch Logs ロググループ 1. 次のインフラストラクチャリソースを作成してデプロイします。 + AWS Supply Chain サービスインスタンス、名前空間、データセットを管理 (作成、更新、削除する) する Lambda 関数。 + AWS Supply Chain データインジェスト用の Amazon S3 バケットのステージング 1. ステージングバケットと AWS Supply Chain データセット間の統合フローを管理する Lambda 関数をデプロイします。デプロイが完了すると、残りのワークフローステップでデータの取り込みと分析を管理します。 1. AWS Supply Chain ステージング Amazon S3 バケットへのソースデータの取り込みを設定します。 1. AWS Supply Chain ステージング Amazon S3 バケットにデータが追加されると、サービスは自動的に AWS Supply Chain データセットへの統合フローをトリガーします。 1. AWS Supply Chain は Quick Sight Analytics と統合して、取り込まれたデータに基づいてダッシュボードを生成します。 ## ツール **AWS のサービス** + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を承認するかを制御することで、 AWS リソースへのアクセスを安全に管理できます。 + [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用すると、すべての AWS アカウント およびクラウドアプリケーションへのシングルサインオン (SSO) アクセスを一元管理できます。 + [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 Q](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/qinasc.html) in AWS Supply Chain は、 AWS Supply Chain データレイク内のデータを分析することでサプライチェーンをより効率的に運用するのに役立つインタラクティブな生成 AI アシスタントです。 + [Amazon QuickSight](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は、視覚化、分析、レポート生成に使用できるクラウドスケールのビジネスインテリジェンス (BI) サービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/adminguide/getting-started.html) は、サプライチェーンドメインのデータストアとして組織で使用できるクラウドベースのマネージドアプリケーションです。これは、インサイトを生成し、取り込まれたデータに対して分析を実行するために使用できます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。[Amazon VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)は、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要と AWS のサービス せずに、サポートされている に VPC をプライベートに接続するのに役立つ仮想デバイスです。 **その他のツール** + [GitHub アクション](https://docs.github.com/en/actions)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。 + [HashiCorp Terraform](https://www.terraform.io/) は、Infrastructure as Code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/jfrog-artifactory) は、アプリケーション配信プロセスを通じてバイナリとアーティファクトのend-to-endの自動化と管理を提供します。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。このパターンでは、 AWS 関数のコードが とやり取りするために Python を使用します。 AWS Supply Chain . ## ベストプラクティス + このパターンを実装する場合、可能な限り高レベルのセキュリティを維持します。[「前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)」で説明されているように、2 つのプライベートサブネットを持つ [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) が、 AWS リージョン 選択した AWS アカウント の にあることを確認します。 [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) + 可能な限り AWS KMS [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/cryptographic-details/basic-concepts.html)を使用し、制限付きアクセス許可を付与します。 + このパターンのデータを取り込むために必要な最小限のアクセスを持つ IAM ロールを設定するには、このパターンのリポジトリの[「ソースシステムから Amazon S3 への安全なデータ取り込み](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main?tab=readme-ov-file#secure-data-ingestion-from-source-systems-to-amazon-s3)」を参照してください。 ## エピック ### (両方のオプション) ローカルワークステーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | このパターンのリポジトリのクローンを作成するには、ローカルワークステーションで次のコマンドを実行します。
git clone https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment.git
cd ASC-Deployment
| AWS DevOps | | (自動オプション) デプロイの前提条件を確認します。 | 自動デプロイの[前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)が完了していることを確認します。 | アプリ所有者 | | (手動オプション) AWS Supply Chain データセットのデプロイを準備します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。
cd ASC-Datasets/terraform-deployment
[前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)で作成されたロール ARN を引き受けるには、次のコマンドを実行します。
aws sts assume-role --role-arn  --role-session-name
環境変数を設定してエクスポートするには、次のコマンドを実行します。
# Export Environment variables
export REGION=
export REPO_NAME=
export PROJECT_NAME="asc-deployment-poc"
export ACCOUNT_ID=
export ENVIRONMENT="dev"
export LAMBDA_LAYER_TEMP_DIR_TERRAFORM="layerOutput"
export LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM="lambdaOutput"
export AWS_USER_ROLE=
export S3_TERRAFORM_ARTIFACTS_BUCKET_NAME="$PROJECT_NAME-$ACCOUNT_ID-$REGION-terraform-artifacts-$ENVIRONMENT"
| AWS DevOps | | (手動オプション) デプロイで AWS Supply Chain 統合フローを管理する準備をします。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。
cd ASC-Integration-Flows/terraform-deployment
以前に作成したロール ARN を引き受けるには、次のコマンドを実行します。
aws sts assume-role --role-arn  --role-session-name
環境変数を設定してエクスポートするには、次のコマンドを実行します。
# Export Environment variables
export REGION=
export REPO_NAME=
export ASC_DATASET_VARS_REPO=  #Must be the same directory name used for ASC Datasets deployment
export PROJECT_NAME="asc-deployment-poc"
export ACCOUNT_ID=
export ENVIRONMENT="dev"
export LAMBDA_LAYER_TEMP_DIR_TERRAFORM="layerOutput"
export LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM="lambdaOutput"
export S3_TERRAFORM_ARTIFACTS_BUCKET_NAME="$PROJECT_NAME-$ACCOUNT_ID-$REGION-terraform-artifacts-$ENVIRONMENT"
| アプリ所有者 | ### (自動オプション) GitHub Actions ワークフローを使用して AWS Supply Chain データセットをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `ASC-Datasets` ディレクトリをコピーします。 | `ASC-Datasets` ディレクトリを新しい場所にコピーするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | AWS DevOps | | `ASC-Datasets` ディレクトリを設定します。 | を組織内のスタンドアロンリポジトリ`ASC-Datasets`として設定するには、次のコマンドを実行します。
git init
git add .
git commit -m "Initial commit: ASC-Datasets standalone repository"
git remote add origin 
git branch -M dev
| AWS DevOps | | .github ワークフローファイルでブランチ名を設定します。 | 次の例に示すように、[デプロイ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/.github/workflows/asc-datasets.yml)ワークフローファイルにブランチ名を設定します。
   on:
     workflow_dispatch:
     push:
       branches:
         - dev     #Change to any other branch preferred for deployment
| アプリ所有者 | | GitHub 環境をセットアップし、環境値を設定します。 | GitHub 組織で GitHub 環境を設定するには、このパターンのリポジトリにある [ GitHub 環境のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-github-environments)の手順を使用します。ワークフローファイルで[環境値](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-environment-values-in-the-workflow-files)を設定するには、このパターンのリポジトリ[のワークフローファイルの環境値のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-environment-values-in-the-workflow-files)の手順を使用します。 | アプリ所有者 | | ワークフローをトリガーします。 | 変更を GitHub 組織にプッシュし、デプロイワークフローをトリガーするには、次のコマンドを実行します。
git push -u origin dev
| AWS DevOps | ### (自動オプション) GitHub Actions ワークフローを使用して AWS Supply Chain 統合フローをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `ASC-Integration-Flows` ディレクトリをコピーします。 | `ASC-Integration-Flows` ディレクトリを新しい場所にコピーするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | AWS DevOps | | `ASC-Integration-Flows` ディレクトリを設定します。 | `ASC-Integration-Flows` ディレクトリを組織内のスタンドアロンリポジトリとして設定するには、次のコマンドを実行します。
git init
git add .
git commit -m "Initial commit: ASC-Integration-Flows standalone repository"
git remote add origin 
git branch -M dev
| AWS DevOps | | .github ワークフローファイルでブランチ名を設定します。 | 次の例に示すように、[デプロイ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/.github/workflows/asc-integration-flows.yml)ワークフローファイルにブランチ名を設定します。
   on:
     workflow_dispatch:
     push:
       branches:
         - dev     #Change to any other branch preferred for deployment
| アプリ所有者 | | GitHub 環境をセットアップし、環境値を設定します。 | GitHub 組織で GitHub 環境を設定するには、このパターンのリポジトリにある [ GitHub 環境のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-github-environments)の手順を使用します。ワークフローファイルで[環境値](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-github-environments)を設定するには、このパターンのリポジトリ[のワークフローファイルの環境値のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-environment-values-in-the-workflow-files)の手順を使用します。 | アプリ所有者 | | ワークフローをトリガーします。 | 変更を GitHub 組織にプッシュし、デプロイワークフローをトリガーするには、次のコマンドを実行します。
git push -u origin dev
| AWS DevOps | ### (手動オプション) Terraform を使用して AWS Supply Chain データセットをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `terraform-deployment ` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。
cd ASC-Datasets/terraform-deployment
| AWS DevOps | | Terraform 状態 Amazon S3 バケットを設定します。 | Terraform 状態 Amazon S3 バケットを設定するには、次のスクリプトを使用します。
# Setup terraform bucket
chmod +x ../scripts/setup-terraform.sh
../scripts/setup-terraform.sh
| AWS DevOps | | Terraform アーティファクト Amazon S3 バケットを設定します。 | Terraform アーティファクト Amazon S3 バケットを設定するには、次のスクリプトを使用します。
# Setup terraform artifacts bucket
chmod +x ../scripts/setup-terraform-artifacts-bucket.sh
../scripts/setup-terraform-artifacts-bucket.sh
| AWS DevOps | | Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。
# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps | | デプロイプランを生成します。 | デプロイプランを生成するには、次のコマンドを実行します。
# Run terraform init and validate
terraform init
terraform validate

# Run terraform plan
terraform plan \
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="user_role=$AWS_USER_ROLE" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps | | 設定をデプロイします。 | 設定をデプロイするには、次のコマンドを実行します。
# Run terraform apply
terraform apply tfplan.out
| AWS DevOps | | 他の設定を更新し、出力を保存します。 | AWS KMS キーポリシーを更新し、適用された設定出力を Terraform アーティファクト Amazon S3 バケットに保存するには、次のコマンドを実行します。
# Update AWS Supply Chain KMS Key policy with the service's requirements
chmod +x ../scripts/update-asc-kms-policy.sh
../scripts/update-asc-kms-policy.sh
# Update AWS KMS Keys' policy with IAM roles
chmod +x ../scripts/update-kms-policy.sh
../scripts/update-kms-policy.sh
# Create terraform outputs file to be used as input variables
terraform output -json > raw_output.json
jq -r 'to_entries | map(
  if .value.type == "string" then
      "\(.key) = \"\(.value.value)\""
  else
      "\(.key) = \(.value.value | tojson)"
  end
) | .[]' raw_output.json > $REPO_NAME-outputs.tfvars
# Upload reformed outputs file to Amazon S3 terraform artifacts bucket (For retrieval from other repositories)
aws s3 cp $REPO_NAME-outputs.tfvars s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
rm -f raw_output.json
rm -f $REPO_NAME-outputs.tfvars
| AWS DevOps | ### (手動オプション) Terraform を使用して AWS Supply Chain サービス統合フローをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。
cd ASC-Integration-Flows/terraform-deployment
| AWS DevOps | | Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。
# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps | | デプロイプランを生成します。 | デプロイプランを生成するには、次のコマンドを実行します。これらのコマンドは、Terraform 環境を初期化し、 の設定変数を既存の Terraform 設定`ASC-Datasets`とマージして、デプロイプランを生成します。
# Run terraform init and validate
terraform init
terraform validate
# Download and merge ASC DATASET tfvars
chmod +x ../scripts/download-vars-through-s3.sh
../scripts/download-vars-through-s3.sh $ASC_DATASET_VARS_REPO
# Run terraform plan
terraform plan \
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps | | 設定をデプロイします。 | 設定をデプロイするには、次のコマンドを実行します。
# Run terraform apply
terraform apply tfplan.out
| AWS DevOps | | 他の設定を更新します。 | AWS KMS キーポリシーを更新し、適用された設定出力を Terraform アーティファクト Amazon S3 バケットに保存するには、次のコマンドを実行します。
# Update AWS KMS Keys' policy with IAM roles
chmod +x ../scripts/update-kms-policy-through-s3.sh
../scripts/update-kms-policy-through-s3.sh $ASC_DATASET_VARS_REPO
# Create terraform outputs file to be used as input variables
terraform output -json > raw_output.json
jq -r 'to_entries | map(
  if .value.type == "string" then
      "\(.key) = \"\(.value.value)\""
  else
      "\(.key) = \(.value.value | tojson)"
  end
) | .[]' raw_output.json > $REPO_NAME-outputs.tfvars
# Upload reformed outputs file to Amazon S3 terraform artifacts bucket (For retrieval from other repositories)
aws s3 cp $REPO_NAME-outputs.tfvars s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
rm -f raw_output.json
rm -f $REPO_NAME-outputs.tfvars
| AWS DevOps | ### (両方のオプション) データを取り込む | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプル CSV ファイルをアップロードします。 | データセットのサンプル CSV ファイルをアップロードするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | データエンジニア | ### (両方のオプション) AWS Supply Chain アクセスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Supply Chain アクセスを設定します。 | からの AWS Supply Chain アクセスを設定するには AWS マネジメントコンソール、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | アプリ所有者 | ### (自動オプション) GitHub Actions ワークフローを使用してすべてのリソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 統合フローリソースの破棄ワークフローをトリガーします。 | GitHub 組織のデプロイブランチ`ASC-Integration-Flows`から の[破棄ワークフロー](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/.github/workflows/destroy-workflow.yml)をトリガーします。 | AWS DevOps | | データセットリソースの破棄ワークフローをトリガーします。 | GitHub 組織のデプロイブランチ`ASC-Datasets`から の[破棄ワークフロー](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/.github/workflows/destroy-workflow.yml)をトリガーします。 | AWS DevOps | ### (手動オプション) Terraform を使用して AWS Supply Chain 統合フローのリソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。
cd ASC-Integration-Flows/terraform-deployment
| AWS DevOps | | Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。
# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps | | インフラストラクチャ破壊計画を作成します。 | 詳細なティアダウンプランを生成して AWS インフラストラクチャの制御された破壊に備えるには、次のコマンドを実行します。このプロセスでは、Terraform を初期化し、 AWS Supply Chain データセット設定を組み込み、実行前に確認できる破棄計画を作成します。
# Run terraform init and validate
terraform init
terraform validate
# Download and merge ASC DATASET tfvars
chmod +x ../scripts/download-vars-through-s3.sh
../scripts/download-vars-through-s3.sh $ASC_DATASET_VARS_REPO
# Run terraform plan
terraform plan -destroy\
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps | | インフラストラクチャ破壊計画を実行します。 | インフラストラクチャの計画された破棄を実行するには、次のコマンドを実行します。
# Run terraform apply
terraform apply tfplan.out
| AWS DevOps | | Amazon S3 バケットから Terraform 出力を削除します。 | のデプロイ中にアップロードされた出力ファイルを削除するには`ASC-Integration-Flows`、次のコマンドを実行します。
# Delete the outputs file
aws s3 rm s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
| AWS DevOps | ### (手動オプション) Terraform を使用して AWS Supply Chain サービスデータセットのリソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。
cd ASC-Datasets/terraform-deployment
| AWS DevOps | | Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。
# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps | | インフラストラクチャ破壊計画を作成します。 | AWS Supply Chain データセットリソースを破棄する計画を作成するには、次のコマンドを実行します。
# Run terraform init and validate
terraform init
terraform validate

# Run terraform plan
terraform plan -destroy\
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="user_role=$AWS_USER_ROLE" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps | | Amazon S3 バケットを空にします。 | すべての Amazon S3 バケット ( 用に設定されたサーバーアクセスログ記録バケットを除く`force-destroy`) を空にするには、次のスクリプトを使用します。
# Delete S3 buckets excluding server access logging bucket
chmod +x ../scripts/empty-s3-buckets.sh
../scripts/empty-s3-buckets.sh tfplan.out
| AWS DevOps | | インフラストラクチャ破壊計画を実行します。 | 生成されたプランを使用して AWS Supply Chain データセットインフラストラクチャの計画された破壊を実行するには、次のコマンドを実行します。
# Run terraform apply
terraform apply tfplan.out
| AWS DevOps | | Amazon S3 Terraform アーティファクトバケットから Terraform 出力を削除します。 | クリーンアッププロセスを完了するには、次のコマンド`ASC-Datasets`を実行して、 のデプロイ中にアップロードされた出力ファイルを削除します。
# Delete the outputs file
aws s3 rm s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
| AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS Supply Chain 内部エラーまたはサービスロールの IAM アクセス許可が不十分であるため、 AWS Supply Chain データセットまたは統合フローが正しくデプロイされませんでした。 | まず、すべてのリソースをクリーンアップします。次に、 AWS Supply Chain [データセットリソース](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/README.md)を再デプロイし、 AWS Supply Chain [統合フローリソース](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/README.md)を再デプロイします。 | | AWS Supply Chain 統合フローは、 AWS Supply Chain データセットにアップロードされた新しいデータファイルを取得しません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | ## 関連リソース **AWS ドキュメント** + [AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/adminguide/getting-started.html) **その他のリソース** + [GitHub Actions ワークフローについて](https://docs.github.com/en/actions/get-started/understand-github-actions) (GitHub ドキュメント) ## 追加情報 このソリューションは、 で提供される構築済みのダッシュボード AWS Supply Chain または Amazon Quick Sight とのカスタム統合を通じて、より多くのデータセットにレプリケートでき、さらなる分析のためにクエリを実行できます。さらに、Amazon Q を使用して、 AWS Supply Chain インスタンスに関連する質問をすることができます。 **Analytics でデータを分析する AWS Supply Chain ** AWS Supply Chain 分析を設定する手順については、 AWS Supply Chain ドキュメントの[AWS Supply Chain 「分析の設定](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/setting_analytics.html)」を参照してください。 このパターンは、**カレンダー**データセットと **Outbound\$1Order\$1Line** データセットの作成を示しています。これらのデータセットを使用する分析を作成するには、次の手順を実行します。 1. データセットを分析するには、**季節性分析**ダッシュボードを使用します。ダッシュボードを追加するには、 AWS Supply Chain ドキュメントの[「構築済みダッシュボード](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/prebuilt_dashboards.html)」のステップに従います。 1. ダッシュボードを選択すると、カレンダーデータとアウトバウンド注文明細データのサンプル CSV ファイルに基づく分析が表示されます。 ダッシュボードは、データセットの取り込まれたデータに基づいて、長年にわたってオンデマンドでインサイトを提供します。ProductID、CustomerID、年、およびその他のパラメータをさらに指定して分析できます。 **Amazon Q を使用して AWS Supply Chain インスタンスに関連する質問をする** [Amazon Q in AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/qinasc.html) は、サプライチェーンをより効率的に運用するのに役立つインタラクティブな生成 AI アシスタントです。Amazon Q は以下を実行できます。 + AWS Supply Chain データレイク内のデータを分析します。 + 運用上および財務上のインサイトを提供します。 + サプライチェーンに関する即時の質問に回答します。 Amazon Q の使用の詳細については、 AWS Supply Chain ドキュメントの[「 での Amazon Q の有効化 AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/enabling_QinASC.html)」と[「 での Amazon Q の使用 AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/using_QinASC.html)」を参照してください。 # AWS リソース評価を自動化する *Amazon Web Services、Naveen Suthar、Arun bagal、Manish Garg、Sandeep Gawande* ## 概要 このパターンでは、[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) を使用してリソース評価機能を設定する自動化アプローチを説明します。このパターンを使用すると、運用チームはリソース監査の詳細を自動的に収集し、AWS アカウントにデプロイされたすべてのリソースの詳細を単一のダッシュボードに表示できます。このパターンは、以下に示すユースケースで役立ちます。 + infrastructure as code (IaC) ツールを特定し、[HashiCorp Terraform](https://www.terraform.io/)、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)、AWS CDK、[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) など、さまざまな IaC ソリューションによって作成されたリソースを孤立化します。 + リソース監査情報を取得する このソリューションは、リーダーシップチームが単一ダッシュボードから AWS アカウントのリソースとアクティビティに関する洞察を得る上でも役立ちます。 | | | 注: [Amazon Quick Sight](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は有料サービスです。データを分析し、ダッシュボードを作成する前に、[Amazon Quick Sight の料金](https://aws.amazon.com/quicksight/pricing/)を確認してください。 | | --- | ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + AWS Identity and Access Management (IAM) ロールとプロビジョンリソースへのアクセス権限 + Amazon [Simple Storage Service (Amazon Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)[S3) と Amazon Athena にアクセスできるように作成された Amazon Quick アカウント](https://docs.aws.amazon.com/quicksight/latest/user/signing-up.html) [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) + AWS CDK バージョン 2.55.1 以降がインストールされている + [Python](https://www.python.org/downloads/release/python-390/) 3.9 以降がインストールされている **制限** + このソリューションは単一 AWS アカウントにデプロイされます。 + このソリューションは、AWS CloudTrail がすでにセットアップされ、S3 バケットにデータを保存していない限り、デプロイ前に発生したイベントを追跡しません。 **製品バージョン** + AWS CDK バージョン 2.55.1 またはそれ以降 + Python バージョン 3.9 以降 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Athena + AWS CloudTrail + AWS Glue + AWS Lambda + Amazon Quick Sight + Amazon S3 **ターゲットアーキテクチャ** AWS CDK コードは、AWS アカウントへのリソース評価機能の設定に必要なすべてのリソースをデプロイします。次の図は、CloudTrail ログを AWS Glue、Amazon Athena、および Quick Sight に送信するプロセスを示しています。 ![\[AWS Glue、Amazon Athena、Amazon QuickSight を使用した AWS リソース評価は 6 つのステップから成るプロセスです。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a504774e-db7a-4c36-a22c-ce56d252fb58/images/8f2b549d-33a8-4cbf-86fd-33244716b668.png) 1. CloudTrail は、ストレージ用にログを S3 バケットに送信します。 1. イベント通知は、ログを処理してフィルタリングされたデータを生成する Lambda 関数を呼び出します。 1. フィルタリングされたデータは、別の S3 バケットに保存されます。 1. S3 バケット内のフィルタリングされたデータに AWS Glue クローラーを設定して、AWS Glue データカタログテーブルにスキーマを作成します。 1. フィルタリングされたデータを Amazon Athena によってクエリする準備ができました。 1. クエリされたデータは、Quick Sight によって視覚化のためにアクセスされます。 **自動化とスケール** + AWS Organizations に組織全体の CloudTrail トレイルがある場合は、このソリューションを 1 つの AWS アカウントから複数の AWS アカウントに拡張できます。CloudTrail を組織レベルでデプロイすることで、このソリューションを使用して、必要なすべてのリソースのリソース監査詳細を取得することもできます。 + このパターンでは、AWS サーバーレスリソースを使用してソリューションをデプロイします。 ## ツール **AWS サービス** + [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) はインタラクティブなクエリサービスで、Amazon S3 内のデータをスタンダード SQL を使用して直接分析できます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングをし、AWS アカウントと AWS リージョンにわたってライフサイクル全体のリソースを管理できます。 + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、AWS アカウントのガバナンス、コンプライアンス、運用面のリスクの監査をサポートします。 + [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) は、フルマネージド型の抽出、変換、ロード (ETL) サービスです。これにより、データストアとデータストリーム間でのデータの確実な分類、整理、強化、移動をサポートできます。このパターンでは、AWS Glue クローラーと AWS Glue データカタログテーブルを使用します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Quick](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は、単一のダッシュボードでデータを視覚化、分析、レポートするのに役立つクラウドスケールのビジネスインテリジェンス (BI) サービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[infrastructure-assessment-iac-automation](https://github.com/aws-samples/infrastructure-assessment-iac-automation)」リポジトリで利用できます。 コードリポジトリには、以下のファイルとフォルダが含まれます。 + `lib` フォルダ — AWS CDK は、AWS リソースの作成に使用される Python ファイルをコンストラクトします。 + `src/lambda_code` — Lambda 関数で実行される Python コード + `requirements.txt` — インストールする必要があるすべての Python 依存関係のリスト + `cdk.json` — リソースの起動に必要な値を提供する入力ファイル ## ベストプラクティス Lambda 関数のモニタリングとアラートを設定します。詳細については、[Lambda 関数をモニタリングおよびトラブルシューティングする](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)を参照してください。Lambda 関数を使用する際の一般的なベストプラクティスについては、[AWS ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)を参照してください。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ローカルマシンにリポジトリを複製します。 | リポジトリを複製するには、`git clone https://github.com/aws-samples/infrastructure-assessment-iac-automation.git` コマンドを実行します。 | AWS DevOps、DevOps エンジニア | | Python 仮想環境を設定し、必要な依存関係をインストールします。 | Python 仮想環境をセットアップするには、次のコマンドを実行します。
cd infrastructure-assessment-iac-automation
python3 -m venv .venv
source .venv/bin/activate
必要な依存関係を設定するには、`pip install -r requirements.txt` コマンドを実行します。 | AWS DevOps、DevOps エンジニア | | AWS CDK 環境をセットアップし、AWS CDK コードを合成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア | ### ローカルマシンで AWS 認証情報をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スタックをデプロイするアカウントとリージョンの変数をエクスポートします。 | 環境変数を使用して AWS CDK の AWS 認証情報を提供には、次のコマンドを実行します。
export CDK_DEFAULT_ACCOUNT=<12 Digit AWS Account Number>
export CDK_DEFAULT_REGION=
| AWS DevOps、DevOps エンジニア | | AWS CLI プロファイルをセットアップします。 | アカウントの AWS CLI プロファイルを設定するには、[AWS ドキュメント](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/keys-profiles-credentials.html)の指示に従います。 | AWS DevOps、DevOps エンジニア | ### リソース評価ツールを設定してデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アカウントにリソースをデプロイします。 | AWS CDK を使用して AWS アカウントにリソースをデプロイするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps | | AWS Glue クローラーを実行し、データカタログテーブルを作成します。 | [AWS Glue クローラー](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html)は、データスキーマを動的に保つために使用されます。このソリューションは、AWS Glue クローラースケジューラーの定義に従ってクローラーを定期的に実行することで、[AWS Glue データカタログテーブル](https://docs.aws.amazon.com/athena/latest/ug/querying-glue-catalog.html)のパーティションを作成および更新します。出力 S3 バケットでデータが使用できるようになると、次のステップを使用して AWS Glue クローラーを実行し、テスト用の Data Catalog テーブルスキーマを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html)AWS CDK コードは AWS Glue クローラーを特定の時間に実行するように設定しますが、オンデマンドで実行することもできます。 | AWS DevOps、DevOps エンジニア | | Quick Sight コンストラクトをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア | | Quick Sight ダッシュボードを作成します。 | Quick Sight ダッシュボードと分析の例を作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html)詳細については、[「Amazon Quick Sight での分析の開始](https://docs.aws.amazon.com/quicksight/latest/user/creating-an-analysis.html)」および[「Amazon Quick Sight でのビジュアルタイプ](https://docs.aws.amazon.com/quicksight/latest/user/working-with-visual-types.html)」を参照してください。 | AWS DevOps、DevOps エンジニア | ### ソリューション内のすべての AWS リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS リソースを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア | ### AWS リソース評価ツールの自動化のトップに追加機能を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 手動で作成したリソースを監視してクリーンアップします。 | (オプション) アプリケーションに IaC ツールを使用してリソースを作成するというコンプライアンス要件がある場合は、AWS リソース評価ツールの自動化を使用して手動でプロビジョニングされたリソースを取得することで、コンプライアンスを達成できます。また、このツールを使用して、リソースを IaC ツールにインポートまたはリソースを再作成できます。手動でプロビジョニングされたリソースを監視するには、以下の高レベルのタスクを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS CDK はエラーを返します。 | AWS CDK の問題に関するヘルプは、[一般的な AWS CDK 問題をトラブルシューティングする](https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html)を参照してください。 | ## 関連リソース + [Python で Lambda 関数を構築する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) + [AWS CDK の使用を開始する](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) + [Python の AWS CDK を使用する](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-python.html) + [CloudTrail ログ証跡を作成する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [Amazon Quick Sight の使用を開始する](https://aws.amazon.com/quicksight/getting-started/) ## 追加情報 **複数アカウント** 複数アカウントの AWS CLI 認証情報を設定するには、AWS プロファイルを使用します。詳細については、[AWS CLI をセットアップする](https://aws.amazon.com/getting-started/guides/setup-environment/module-three/)」の*複数のプロファイルの設定する*セクションを参照してください。 **AWS CDK コマンド** AWS CDK を使用する際は、以下の便利なコマンドに注意してください。 + アプリ内のすべてのスタックを一覧表示 ``` cdk ls ``` + 合成された AWS CloudFormation テンプレートを発行 ``` cdk synth ``` + スタックをデフォルトの AWS アカウントとリージョンにデプロイ ``` cdk deploy ``` + デプロイされたスタックを現在の状態と比較 ``` cdk diff ``` + AWS CDK ドキュメントを開く ``` cdk docs ``` # オープンソースツールを使用して SAP システムを自動的にインストール *Amazon Web Services、Guilherme Sesterheim* ## 概要 このパターンでは、オープンソースツールを使用して以下のリソースを作成することで SAP システムのインストールを自動化する方法を示しています。 + SAP S/4HANA 1909 データベース + SAP ABAP セントラルサービス (ASCS) インスタンス + SAP プライマリアプリケーションサーバー (PAS) インスタンス HashiCorp Terraform が SAP システムのインフラストラクチャを作成し、Ansible がオペレーティングシステム (OS) を設定し、SAP アプリケーションをインストールします。Jenkins がインストールを実行します。 この設定により、SAP システムのインストールが反復可能なプロセスになり、デプロイの効率と品質が向上します。 **注記** このパターンで提供されるサンプルコードは、高可用性 (HA) システムと非 HA システムの両方で機能します。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + すべての SAP メディアファイルを含めるAmazon Simple Storage Service (Amazon S3) バケット + [アクセスキーとシークレットキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) を持ち、以下の権限を持つ AWS アイデンティテとアクセス管理 (IAM) プリンシパルです。 + **読み取り専用権限：**Amazon Route 53、AWS Key Management Service (AWS KMS) + **読み取り権限と書き込み権限：**Amazon S3、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic File System (Amazon EFS)、IAM、Amazon CloudWatch、Amazon DynamoDB + ルート 53 [プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) + Amazon マーケットプレイスの [HA およびアップデートサービス 8.2 付けの Red Hat Enterprise Linux for SAP](https://aws.amazon.com/marketplace/pp/prodview-5grz5a5thx7c2) のAmazon マシンイメージ (AMI) についての説明 + [AWS KMS カスタマー管理キー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html#aws-managed-customer-managed-keys) + [Secure Shell (SSH) キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) + Jenkins をインストールしたホスト名からのポート 22 で SSH 接続を許可する [Amazon EC2 セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) (多分、ホスト名が**localhost**) + インストール、設定されたHashiCorpによる [バグラント](https://www.vagrantup.com/) + インストール、設定された Oracle による [VirtualBox](https://www.virtualbox.org/) + Git、テラフォーム、アンシブル、ジェンキンスに精通 **制限事項** + この特定のシナリオで完全にテストされているのは SAP S/4HANA 1909 だけです。別のバージョンの SAP HANA を使用する場合、このパターンの Ansible コード例を変更する必要があります。 + このパターンのサンプル手順は Mac OS と Linux オペレーティングシステムで機能します。一部のコマンドは UNIX ベースの端末でしか実行できません。ただし、別のコマンドと Windows OS を使用しても同様の結果が取得されます。 **製品バージョン** + SAP S/4HANA 1909 + Red Hat Enterprise Linux (RHEL) バージョン 6 以上 ## アーキテクチャ 次の図表では、オープンソースツールを使用して AWS アカウントで SAP システムのインストールを自動化するワークフローの例を示しています。 ![\[オープンソースツールを使用して AWS アカウントで SAP システムのインストールを自動化するワークフローの例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/aaf11dac-38cc-4e89-be86-51d4409cf238/images/d7902f9d-f1be-461f-b69b-cf3c663c8f2f.png) この図表は、次のワークフローを示しています: 1. Jenkins は Terraform と Ansible のコードを実行することで SAP システムのインストールをオーケストレーションします。 1. Terraform コードは SAP システムのインフラストラクチャを構築します。 1. Ansible コードが OS を設定し、SAP アプリケーションをインストールします。 1. 定義されたすべての前提条件を含む SAP S/4HANA 1909 データベース、ASCS インスタンス、および PAS インスタンスが Amazon EC2 インスタンスにインストールされます。 **注記** このパターンの設定例では、Terraform 状態ファイルを保存するための Amazon S3 バケットが AWS アカウントに自動的に作成されます。 **テクノロジースタック** + Terraform + Ansible + Jenkins + SAP S/4HANA 1909 データベース + SAP ASCS インスタンス + SAP PAS インスタンス + Amazon EC2  ## ツール ** サービス** + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/?id=docs_gateway)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、ユーザーのデータを保護するために使用される、暗号化キーの作成と制御を容易にするマネージドサービスです。 + [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) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つコマンドラインインターフェイスアプリケーションです。 + [Ansible](https://www.ansible.com/) は、アプリケーション、構成、IT インフラストラクチャの自動化に役立つオープンソースのコード設定 (CaC) ツールです。 + [Jenkins](https://www.jenkins.io/) は、デベロッパーがソフトウェアを確実に構築、テスト、デプロイできるようにするオープンソースのオートメーションサーバーです。 **コード** このパターンのコードでは、GitHub 内の「[aws-install-sap-with-jenkins-ansible](https://github.com/aws-samples/aws-install-sap-with-jenkins-ansible)」リポジトリで利用できます。 ## エピック ### AWS の前提条件の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon S3 バケットにファイルを追加します。 | SAP メディアファイルをすべて含め、[Amazon S3 バケットを作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)します。[Launch Wizard ドキュメント](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap-software-install-details.html) の **S/4HANA** の AWS Launch Wizard のフォルダ階層に必ず従ってください。 | クラウド管理者 | | VirtualBox をインストールします。 | Oracle で [VirtualBox](https://www.virtualbox.org/) をインストールして設定します。 | DevOps エンジニア | | Vagrant をインストールします。 | HashiCorp による [Vagrant](https://www.vagrantup.com/)のインストールと設定を行います。 | DevOps エンジニア | | AWS アカウントの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html) | AWS 全般 | ### SAP インストールを構築して実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub から リポジトリのクローンを作成します。 | GitHub の [aws-install-sap-with-jenkins-ansible](https://github.com/aws-samples/aws-install-sap-with-jenkins-ansible) リポジトリをクローンします。 | DevOps エンジニア | | Jenkins サービスを開始します。 | Linux ターミナルを開く 次に、クローンされたコードリポジトリフォルダを含むローカルフォルダにナビゲーションし、以下のコマンドを実行します。
sudo vagrant up
Jenkins の起動には約 20 分かかります。コマンドが成功する場合、**サービスがアップし、実行されています**というメッセージが返されます。 | DevOps エンジニア | | ウェブブラウザで Jenkins を開き、ログインします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html) | DevOps エンジニア | | SAP システムのインストールパラメータを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)その他の必須ではないパラメータは、ユースケースに基づいて必要に応じて設定できます。例えば、SAP システムのインスタンスの SAP システム ID (SID)、デフォルトパスワード、名前、タグを変更できます。 すべての必須変数には、名前の先頭に **(必須)** が付いています。 | AWS システム管理者、DevOps エンジニア | | SAP システムインストールを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)パイプラインステップの詳細については、AWS ブログの[オープンソースツールによる SAP インストールの自動化](https://aws.amazon.com/blogs/awsforsap/automating-sap-installation-with-open-source-tools/) の**パイプラインステップの理解** セクションを参照してください。エラーが発生した場合、表示される赤いエラーボックスの上にカーソルを移動し、**[ログ]** を選択します。エラーが発生したパイプラインステップのログが表示されます。ほとんどのエラーは、誤ったパラメータ設定が原因で発生します。 | DevOps エンジニア、AWS システム管理者 | ## 関連リソース + [SAP 向け DevOps — SAP インストール：2 か月から 2 時間へ](https://videos.itrevolution.com/watch/707351918/) (DevOps エンタープライズ提出ビデオライブラリ) # AWS CDK を使用して AWS Service Catalog ポートフォリオと製品のデプロイを自動化する *Amazon Web Services、Sandeep Gawande、Vyoma Sachdeva、RAJNEESH TYAGI* ## 概要 AWS Service Catalog は、組織の AWS 環境での使用が承認された IT サービスまたは*製品*のカタログを一元管理するのに役立ちます。*ポートフォリオ*とは製品の一群のことです。これには設定情報も含まれます。AWS Service Catalogでは、組織のユーザータイプごとにカスタマイズしたポートフォリオを作成し、適切なポートフォリオへのアクセス権を選択的に付与できます。そうすれば、ユーザーはポートフォリオ内から必要な製品をすばやくデプロイできます。 マルチリージョンアーキテクチャやマルチアカウントアーキテクチャなどの複雑なネットワークインフラストラクチャを使用している場合は、Service Catalog ポートフォリオを単一の中央アカウントで作成および管理することをお勧めします。このパターンでは、AWS Cloud Development Kit (AWS CDK) を使用して、中央アカウントでの Service Catalog ポートフォリオの作成を自動化し、エンドユーザーにそのポートフォリオへのアクセスを許可し、オプションで 1 つ以上のターゲット AWS アカウントに製品をプロビジョニングする方法を説明します。このすぐに使用できるソリューションにより、ソースアカウントに Service Catalog ポートフォリオが作成されます。また、オプションで AWS CloudFormation スタックを使用してターゲットアカウントに製品をプロビジョニングし、製品の TagOptions を設定するのに役立ちます。 + **AWS CloudFormation StackSets** — StackSets を使用して、複数の AWS リージョンとアカウントにわたってService Catalog 製品を起動できます。このソリューションでは、このソリューションをデプロイするときに製品を自動的にプロビジョニングできます。詳細については、[AWS CloudFormation StackSets](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/using-stacksets.html) (Service Catalog ドキュメント) と [StackSets の概念](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html) (CloudFormation ドキュメント) を参照してください。 + **TagOption ライブラリ** — TagOption ライブラリを使用して、プロビジョニングされた製品のタグを管理できます。*TagOption* は AWS Service Catalog で管理されるキーと値のペアです。これは AWS のタグではありませんが、TagOption に基づいて AWS のタグを作成するためのテンプレートとして機能します。詳細については、[TagOption ライブラリー](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/tagoptions.html) との共有(Service Catalog ドキュメント) を参照してください。 ## 前提条件と制限 **前提条件** + Service Catalog ポートフォリオを管理するためのソースアカウントとして使用するアクティブな AWS アカウント。 + このソリューションを使用して 1 つ以上のターゲットアカウントに製品をプロビジョニングする場合、ターゲットアカウントはすでに存在し、アクティブである必要があります。 + AWS Service Catalog、AWS CloudFormationおよび AWS IAM にアクセスするための AWS Identity and Access Management (IAM) 権限。 **製品バージョン** + AWS CDK バージョン 2.27.0 ## アーキテクチャ **ターゲットテクノロジースタック** + 一元管理された AWS アカウントのService Catalog ポートフォリオ + ターゲットアカウントにデプロイされたService Catalog 製品 **ターゲット アーキテクチャ** ![\[AWS CDK がService Catalog ポートフォリオを作成し、ターゲットアカウントに製品をプロビジョニングします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e8f217a7-aec4-4c85-8f6b-f91995506be0/images/1f027b82-14c3-485a-909b-1544e974b90a.png) 1. ポートフォリオ (または *ソース*) アカウントで、**config.json** ファイルを AWS アカウント、AWS リージョン、IAM ロール、ポートフォリオ、ユースケースの製品情報で更新します。 1. AWS CDK アプリケーションをデプロイします。 1. AWS CDK アプリケーションはデプロイメント IAM ロールを引き受け、**config.json** ファイルに定義されているService Catalog ポートフォリオと製品を作成します。 ターゲットアカウントに製品をデプロイするように StackSets を設定した場合、プロセスは続行されます。製品をプロビジョニングするように StackSets を設定していない場合、プロセスは完了です。 1. AWS CDK アプリケーションは**StackSet 管理者**ロールを引き受け、**config.json** ファイルで定義した AWS CloudFormationスタックセットをデプロイします。 1. ターゲットアカウントでは、StackSets が **StackSet の実行**ロールを引き受け、製品をプロビジョニングします。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDKアプリケーションの操作に役立つコマンドラインクラウド開発キットです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、AWS で承認された IT サービスのカタログを一元管理できます。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[aws-cdk-servicecatalog-automation](https://github.com/aws-samples/aws-cdk-servicecatalog-automation.git)」リポジトリで利用できます。コードリポジトリには以下のファイルとフォルダが含まれています。 + **cdk-sevicecatalog-app** — このフォルダには、このソリューションの AWS CDK アプリケーションが含まれています。 + **config** — このフォルダには、Service Catalog ポートフォリオに製品をデプロイするための **config.json** ファイルと CloudFormation テンプレートが含まれています。 + **config/config.json** — このファイルにはすべての設定情報が含まれています。このファイルを更新して、ユースケースに合わせてこのソリューションをカスタマイズします。 + **config/templates** — このフォルダには、サービスセンター製品のCloudFormation テンプレートが含まれています。 + **setup.sh** — このスクリプトはソリューションをデプロイします。 + **uninstall.sh** — このスクリプトは、スタックと、このソリューションのデプロイ時に作成されたすべての AWS リソースを削除します。 これらのファイルを使用するには、[エピック](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-epics)セクションの指示に従ってください。 ## ベストプラクティス + このソリューションのデプロイに使用する IAM ロールは、[最小権限の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) (IAM ドキュメント) に従う必要があります。 + [AWS CDK でクラウドアプリケーションを開発するためのベストプラクティス](https://aws.amazon.com/blogs/devops/best-practices-for-developing-cloud-applications-with-aws-cdk/) (AWS ブログ記事) に従ってください。 + [AWS CloudFormation のベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) (クラウドフォーメーションドキュメント) に従ってください。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK Toolkitをインストールします。 | AWS CDK Toolkit がインストールされていることを確認します。次のコマンドを入力して、インストールされているかどうかを確認し、バージョンを確認します。 
cdk --version
がインストールされていない場合は、次のコマンドを実行してインストールします。
npm install -g aws-cdk@2.27.0
AWS CDK Toolkit のバージョンが 2.27.0 より前の場合は、次のコマンドを入力してバージョン 2.27.0 に更新します。
npm install -g aws-cdk@2.27.0 --force
| AWS DevOps、DevOps エンジニア | | リポジトリのクローン作成 | 次のコマンドを入力します。[追加情報](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-additional) セクションの*リポジトリのクローン* では、リポジトリの URL を含むコマンド全体をコピーできます。これにより、GitHub から [aws-cdk-サービスカタログ-自動化](https://github.com/aws-samples/aws-cdk-servicecatalog-automation) リポジトリがクローンされます。
git clone .git
これにより、ターゲットディレクトリに `cd aws-cdk-servicecatalog-automation` フォルダーが作成されます。次のコマンドを入力して、このフォルダーに移動します。
cd aws-cdk-servicecatalog-automation
| AWS DevOps、DevOps エンジニア | | AWS 認証情報の設定 | 以下のコマンドを入力します。これらは、スタックをデプロイする AWS アカウントとリージョンを定義する以下の変数をエクスポートします。
export CDK_DEFAULT_ACCOUNT=<12-digit AWS account number>
export CDK_DEFAULT_REGION=
AWS CDK の AWS 認証情報は、環境変数を通じて提供されます。 | AWS DevOps、DevOps エンジニア | | エンドユーザーIAM ロールのアクセス許可を設定する | IAM ロールを使用してポートフォリオとその中の製品へのアクセスを許可する場合、ロールには **servicecatalog.amazonaws.com**サービスプリンシパルが引き受ける権限が必要です。これらのアクセス権限を付与する方法については、[Service Catalog による信頼できるアクセスの有効化](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-servicecatalog.html#integrate-enable-ta-servicecatalog) (AWS Organizations ドキュメント) を参照してください。 | AWS DevOps、DevOps エンジニア | | StackSets に必要な IAM ロールを設定します。 | StackSets を使用してターゲットアカウントに製品を自動的にプロビジョニングする場合は、スタックセットを管理および実行する IAM ロールを設定する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html) | AWS DevOps、DevOps エンジニア | ### ソリューションのカスタマイズとデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートの準備 | この `config/templates` フォルダーで、ポートフォリオに含めたい製品の CloudFormation テンプレートを作成します。詳細については、[Working with AWS CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) (CloudFormation ドキュメント) を参照してください。 | アプリ開発者、AWS DevOps、DevOps エンジニア | | 設定ファイルをカスタマイズします。 | `config` フォルダーで **config.json** ファイルを開き、ユースケースに適したパラメーターを定義します。特に明記されていない限り、以下のパラメータは必須です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html)完成した設定ファイルの例については、[追加情報](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-additional) セクションの*サンプル設定ファイル*を参照してください。 | アプリ開発者、AWS DevOps、DevOps エンジニア | | ソリューションのデプロイ | 次のコマンドを入力します。これにより、AWS CDK アプリケーションがデプロイされ、**config.json** ファイルに指定されているService Catalog ポートフォリオと製品がプロビジョニングされます。
sh +x setup.sh
| アプリ開発者、AWS DevOps、DevOps エンジニア | | デプロイメントを確認する | 以下を実行して、デプロイが正常に完了したことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html) | AWS 全般 | | (オプション) ポートフォリオと製品を更新します。 | このソリューションを使用してポートフォリオや製品を更新したり、新しい製品をプロビジョニングしたりする場合：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html)たとえば、ポートフォリオを追加したり、リソースをさらにプロビジョニングできます。AWS CDK アプリケーションは変更のみを実装します。以前にデプロイしたポートフォリオや製品に変更がなければ、再デプロイしても影響はありません。 | アプリ開発者、AWS DevOps、DevOps エンジニア | ### ソリューションをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | (オプション) このソリューションによってデプロイされた AWS リソースを削除します。 | プロビジョニング済み製品を削除する場合は、[プロビジョニング済み製品の削除](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html) (Service Catalog ドキュメント)の手順に従ってください。このソリューションで作成されたリソースをすべて削除する場合は、次のコマンドを入力します。
sh uninstall.sh
| AWS DevOps、DevOps エンジニア | ## 関連リソース + [AWS Service Catalog コンストラクトライブラリ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_servicecatalog-readme.html) (AWS API リファレンス) + [StackSets の概念](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html) (CloudFormation ドキュメント) + [AWS Service Catalog](https://aws.amazon.com/servicecatalog) (AWS マーケティング) + [AWS CDK でのService Catalog の使用](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US/4-builders-devs/sc-cdk) (AWS ワークショップ) ## 追加情報 **リポジトリをクローンします** リポジトリのクローンを作成するには、次の コマンドを入力します。 ``` git clone https://github.com/aws-samples/aws-cdk-servicecatalog-automation.git ``` **サンプル設定ファイル** 以下は、サンプル値を含む **config.json** ファイルのサンプルです。 ``` { "portfolios": [ { "displayName": "EC2 Product Portfolio", "providerName": "User1", "description": "Test1", "roles": [ "" ], "users": [ "" ], "groups": [ "" ] }, { "displayName": "Autoscaling Product Portfolio", "providerName": "User2", "description": "Test2", "roles": [ "" ] } ], "tagOption": [ { "key": "Group", "value": [ "finance", "engineering", "marketing", "research" ] }, { "key": "CostCenter", "value": [ "01", "02", "03", "04" ] }, { "key": "Environment", "value": [ "dev", "prod", "stage" ] } ], "products": [ { "portfolioName": "EC2 Product Profile", "productName": "Ec2", "owner": "owner1", "productVersionName": "v1", "templatePath": "../../config/templates/template1.json" }, { "portfolioName": "Autoscaling Product Profile", "productName": "autoscaling", "owner": "owner1", "productVersionName": "v1", "templatePath": "../../config/templates/template2.json", "deployWithStackSets": { "accounts": [ "012345678901", ], "regions": [ "us-west-2" ], "stackSetAdministrationRoleName": "AWSCloudFormationStackSetAdministrationRole", "stackSetExecutionRoleName": "AWSCloudFormationStackSetExecutionRole" } } ] } ``` # AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline *Amazon Web Services、Balaji Vedagiri、Faisal Shahdad、Shanmugam Shanker、Vivek Thangamuthu* ## 概要 **注記** AWS CodeCommit は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider) このパターンは、ホットフィックスソリューションの本番環境への安全なデプロイ専用の動的ホットフィックスパイプラインを管理するシナリオに対応します。このソリューションは、 AWS Service Catalog ポートフォリオと製品を使用して実装および管理されます。Amazon EventBridge ルールがイベントの自動化に使用されます。制限は、Service Catalog ポートフォリオの制約と開発者向けの AWS Identity and Access Management (IAM) ロールを使用して適用されます。EventBridge ルールによってトリガーされる Service Catalog 製品を起動できるのは、 AWS Lambda 関数のみです。このパターンは、「[追加情報](#automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-additional)」で説明されている特定の Gitflow セットアップを使用する環境向けに設計されています。 通常、修正プログラムは、本番稼働環境などのライブ環境で報告された重大な問題やセキュリティ問題に対応するためにデプロイされます。ホットフィックスはステージング環境と本番環境にのみ直接デプロイする必要があります。ステージングパイプラインと本番パイプラインは、定期的な開発リクエストに広く使用されています。これらのパイプラインは、品質検証中の機能があり、本番環境に移行できないため、ホットフィックスのデプロイには使用できません。このパターンでは、ホットフィックスのリリース用として、次のセキュリティ機能を備えた、存続期間の短い動的パイプラインについて説明します。 + **自動作成** — ホットフィックスブランチが AWS CodeCommit リポジトリに作成されるたびに、ホットフィックスパイプラインが自動的に作成されます。 + **アクセス制限** – 開発者は、ホットフィックスプロセスの外でこのパイプラインを作成するためのアクセス権限がありません。 + **制御されたステージ** – パイプラインには特別なアクセストークンを持つ制御されたステージがあり、プルリクエスト (PR) は 1 回しか作成できません。 + **承認ステージ** – 関連するステークホルダーから必要な承認を得るため、承認ステージがパイプラインに含まれます。 + **自動削除** – ホットフィックスパイプラインは、`hotfix` ブランチが PR とマージされた後、CodeCommit リポジトリから削除されるたびに自動的に削除されます。 ## 前提条件と制限 **前提条件** + 次のように 3 つのアクティブな AWS アカウント が必要です。 + ツールアカウント – 継続的インテグレーションと継続的デリバリー (CI/CD) + ステージアカウント – ユーザー承認テスト用。 + 本番環境用アカウント – ビジネスエンドユーザー向け。 + (オプション) QA アカウント AWS アカウント として機能する を追加します。このアカウントは、QA を含むメインパイプライン設定とテスト用のホットフィックスパイプラインソリューションの両方を希望する場合に必要です。 + 必要に応じて、メインパイプラインを使用して QA アカウントにデプロイするオプションの条件を持つ AWS CloudFormation スタック。パターンは、`hotfix` ブランチを作成および削除することで、メインパイプラインのセットアップなしでテストできます。 + Service Catalog 製品の作成に使用される CloudFormation テンプレートを保存する Amazon Simple Storage Service (Amazon S3) バケット。 + コンプライアンス要件に従って CodeCommit リポジトリの PR 承認ルールを作成します (リポジトリの作成の後)。 + 開発者とチームの IAM アクセス許可を制限して、[prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) Lambda 関数の実行を拒否します (この関数の呼び出しはパイプラインからのみとする必要があるため)。 **制限事項** + CloudFormation プロバイダーはデプロイステージで使用され、アプリケーションは CloudFormation 変更セットを使用してデプロイされます。別のデプロイオプションを使用する場合、必要に応じて CodePipeline スタックを変更します。 + このパターンでは AWS CodeBuild 、 およびその他の設定ファイルを使用してサンプルマイクロサービスをデプロイします。別のワークロードタイプ (サーバーレスワークロードなど) を使用している場合は、関連する設定をすべて更新する必要があります。 + このパターンでは、アプリケーションを単一の AWS リージョン (たとえば、米国東部 (バージニア北部) us-east-1) にデプロイします AWS アカウント。複数のリージョンにデプロイするには、コマンドとスタックでリージョンリファレンスを変更します。 + 一部の 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)」を参照し、サービスのリンクを選択してください。 ## アーキテクチャ このセクションの図は、ライフサイクルイベント作成とライフサイクルイベント削除のワークフローを示しています。 ![\[ライフサイクルイベント作成のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/3939f77c-4221-4c23-a3a1-3e8a294b2b32.png) ライフサイクルイベント作成の前述の図は、以下を示しています。 1. 開発者は CodeCommit リポジトリに `hotfix-*` ブランチを作成して、ホットフィックス関連のソリューションを開発します。 1. `hotfix-*` ブランチ作成イベントは、EventBridge ルールを通じてキャプチャされます。イベントの詳細には、リポジトリ名およびブランチ名が含まれます。 1. EventBridge ルールは AWS Lambda 関数 を呼び出します`hotfix-lambda-function`。EventBridge ルールは、入力としてイベント情報を Lambda 関数に渡します。 1. Lambda 関数は入力を処理してリポジトリ名とブランチ名を取得します。処理された入力から取得した値を使用して Service Catalog 製品を起動します。 1. Service Catalog 製品には、ソリューションをステージ環境と本番環境にデプロイするパイプライン設定が含まれています。パイプラインブロックには、ソース、ビルド、デプロイの各ステージが含まれます。また、本番環境のデプロイを昇格させる手動承認ステージもあります。 1. ソースステージは、最初のステップで作成されたリポジトリと `hotfix-*` ブランチからコードを取得します。コードは、アーティファクト用の Amazon S3 バケットを介してビルドステージに渡されます。ビルドステージでは、`hotfix-*` ブランチで開発され、Amazon Elastic Container Registry (Amazon ECR) にプッシュされるホットフィックスを含むコンテナイメージが作成されます。 1. ステージ環境へのデプロイステージでは、ホットフィックスを含む最新のコンテナイメージで Amazon Elastic Container Service (Amazon ECS) が更新されます。ホットフィックスは、CloudFormation 変更セットを作成して実行することでデプロイされます。 1. `prcreation-lambda` Lambda 関数は、ステージ環境で正常にデプロイされた後に呼び出されます。この Lambda 関数は、`hotfix-*` ブランチからリポジトリの `develop` および `main` ブランチに PR を作成します。Lambda 関数は、`hotfix-*` ブランチで開発された修正がバックマージされ、後続のデプロイに含まれるようにします。 1. 手動承認ステージは、必要なステークホルダーが修正を確認し、本番環境にデプロイするための承認を与えるのに役立ちます。 1. 本番環境へのデプロイステージでは、ホットフィックスを含む最新のコンテナイメージで Amazon ECS が更新されます。ホットフィックスは、CloudFormation 変更セットを作成して実行することでデプロイされます。 ![\[ライフサイクルイベントを削除するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/192aa897-bd9b-4a9f-804e-340371612b3b.png) ライフサイクルイベント削除の前述の図は、以下を示しています。 1. 開発者は、ホットフィックスを本番環境に正常にデプロイした後、`hotfix-*` ブランチを削除します。 1. `hotfix-*` ブランチ削除イベントは、EventBridge ルールを通じてキャプチャされます。イベントの詳細には、リポジトリ名およびブランチ名が含まれます。 1. EventBridge ルールは、Lambda 関数を呼び出します。EventBridge ルールは、入力としてイベント情報を Lambda 関数に渡します。 1. Lambda 関数は入力を処理してリポジトリ名とブランチ名を取得します。Lambda 関数は、渡された入力からそれぞれの Service Catalog 製品を決定し、製品を終了します。 1. Service Catalog でプロビジョニングされた製品が終了すると、その製品で以前に作成されたパイプラインおよび関連リソースが削除されます。 **自動化とスケール** + このパターンには、EventBridge ルールと Lambda 関数が含まれており、複数の修正ブランチの作成リクエストに並行して対応できます。Lambda 関数は、一致するイベントルール向けの Service Catalog 製品をプロビジョニングします。 + パイプラインのセットアップは、バージョン管理機能を提供する Service Catalog 製品を使用して対応されます。また、このソリューションは、同じアプリケーションの複数の修正プログラム開発に並行して対応するように自動的にスケーリングされます。 + [prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) 関数を使用すると、これらのホットフィックスの変更も自動プルリクエストの作成を通じて `main` と `develop` ブランチにマージされます。このアプローチは、`main` と `develop` ブランチをすべての修正で最新の状態に保ち、潜在的なコードリグレッションを回避するために不可欠です。このプロセスは、存続期間の長いすべてのブランチに最新の修正を適用することで、ブランチ間の一貫性を維持し、コードのリグレッションを防ぐのに役立ちます。 ## ツール **AWS のサービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースの設定、迅速かつ一貫したプロビジョニング、および AWS アカウント 全体にわたるライフサイクル全体の管理に役立ちます 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 CodeCommit の提供は終了しました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。詳細については、[AWS CodeCommit 「リポジトリを別の Git プロバイダーに移行する方法](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)」を参照してください。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + 「[Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」 は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 + [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 **その他のツール** + [CloudFormation Linter (cfn-lint)](https://github.com/aws-cloudformation/cfn-lint) は、CloudFormation YAML または JSON テンプレートを [CloudFormation リソース仕様](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-resource-specification.html)と照合する linter です。また、リソースプロパティの有効な値の確認やベストプラクティスの遵守などの他のチェックも実行します。 + [cfn\$1nag](https://github.com/stelligent/cfn_nag) は、CloudFormation テンプレートのパターンを探して潜在的なセキュリティ問題を特定するオープンソースツールです。 + 「[Docker](https://www.docker.com/)」は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するPlatform as a Service (PaaS) 製品のセットです。このパターンでは、Docker でコンテナイメージをローカルでビルドしてテストします。 + [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。 **コードリポジトリ** このパターンのコードは、GitHub [dynamic\$1hotfix\$1codepipeline](https://github.com/aws-samples/dynamic_hotfix_codepipeline) リポジトリにあります。 ## ベストプラクティス 環境内の IAM ロールとサービスコントロールポリシー (SCP) を確認および調整し、アクセスが適切に制限されていることを確認します。これは、このパターンに含まれるセキュリティ対策を上書きする可能性のあるアクションを防ぐために重要です。最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 作業環境の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | サンプル[リポジトリ](https://github.com/aws-samples/dynamic_hotfix_codepipeline)を作業場所の新しいディレクトリにクローンするには、次のコマンドを実行します。
git clone git@github.com:aws-samples/dynamic_hotfix_codepipeline.git
| AWS DevOps | | CloudFormation スタックデプロイ用の環境変数を出力します。 | このパターンの後半で CloudFormation スタックへの入力として使用する次の環境変数を定義します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)
export BucketStartName=
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)
export ProdAccount=
export StageAccount=
export QAAccount=
export ToolsAccount=
export DepRegion=
| AWS DevOps | ### で必要な前提条件を設定する AWS アカウント | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ツールアカウントで CI/CD に必要なリソースを作成します。 | ツールアカウントに CloudFormation スタックをデプロイするには、次のコマンドを使用します。(セットアップに QA アカウントを使用していない場合は、`QAAccount` パラメータを削除します)。
#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
CodeCommit リポジトリと Amazon ECR が前のスタックから作成したリソースを書き留めておきます。これらのパラメータは、次のステップでパイプラインの `main` ブランチをセットアップするために必要です。 | AWS DevOps | | ワークロードアカウントで CI/CD に必要なリソースを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | | S3 アーティファクトバケットポリシーを更新して、ワークロードアカウントへのアクセスを許可します。 | ツールアカウント内の CloudFormation スタックの前提条件を更新するには、次のコマンドを使用して、ステージおよび本番ワークロードアカウントに必要なすべてのアクセス許可を追加します。(セットアップに使用していない場合は、`QAAccount` パラメータを削除します)。
#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} PutPolicy=true \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
| AWS DevOps | ### ツールアカウントで Lambda 関数と Service Catalog リソースを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Service Catalog ポートフォリオと製品をセットアップします。 | Service Catalog ポートフォリオと製品をセットアップするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | | Lambda 関数をセットアップします。 | このソリューションでは、次の Lambda 関数を使用してホットフィックスワークフローを管理します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)`hotfix ` ブランチが関連する EventBridge ルールによって作成または削除されたときに、Lambda 関数が Service Catalog 製品をプロビジョニングおよび終了できるようにするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | ### main ブランチのパイプラインを作成し、ワークロードアカウントにアプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `main` ブランチのパイプラインを設定します。 | メインブランチのパイプラインを設定するには、ツールアカウントで次のコマンドを実行します。`MainProductId` および `servicecatalogsetup` のパラメータを `MainProductArtifactId` スタック出力の値に置き換えます。
#InToolsAccount
aws servicecatalog provision-product \
    --product-id  \
    --provisioning-artifact-id  \
    --provisioned-product-name "${ApplicationName}-main-pipeline" \
    --provisioning-parameters Key=CodeCommitRepoName,Value="${ApplicationName}-repository" Key=ECRRepository,Value="${ApplicationName}-app" \
    --region=${DepRegion}
| AWS DevOps | | `main` ブランチを使用してアプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | ### hotfix-\$1 ブランチのパイプラインを作成し、ホットフィックスをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `hotfix-*` ブランチを作成し、変更をコミットします。 | `hotfix-*` ブランチのパイプラインを作成し、ワークロードアカウントにホットフィックスをデプロイするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | | `hotfix-check1` ブランチを削除する | 前に作成した `hotfix-check1` ブランチを削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイされたリソースをクリーンアップします。 | 以前にデプロイされたリソースをクリーンアップするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)
##In Tools Account##
aws cloudformation delete-stack --stack-name servicecatalogsetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prlambdasetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prereqs --region ${DepRegion}
##In Workload Accounts##
aws cloudformation delete-stack --stack-name inframainstack --region ${DepRegion}
詳細については、Service Catalog ドキュメントの「[Deleting provisioned products](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html)」を参照してください。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | CodeCommit リポジトリにコミットした変更はデプロイされません。 | CodeBuild ログに Docker ビルド操作のエラーがないか確認します。詳細については、「[CodeBuild のドキュメント](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)」を参照してください。 | | Service Catalog 製品はプロビジョニングされていません。 | 関連する CloudFormation スタックで失敗したイベントを確認します。詳細については、「[CloudFormation のドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html)」を参照してください。 | ## 関連リソース + [基本的な Git コマンド](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-basic-git.html) + [ブランチへのプッシュとマージを制限するように IAM ポリシーを設定する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-conditional-branch.html#how-to-conditional-branch-create-policy) + [AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html) + [ユーザーへのアクセス権限の付与](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_users.html) + [Docker イメージを Amazon ECR プライベートリポジトリにプッシュする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html) + [トラブルシューティング AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html) + [とは AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) ## 追加情報 このパターンは、CI/CD プロセスの開発ワークフローに採用された Gitflow セットアップ環境向けに設計されています。パイプラインは、開発から始まり、品質保証 (QA)、ステージ、本番環境を通過するデプロイサイクルに従います。CI/CD セットアップには、次のように環境への昇格デプロイを含む 2 つの git ブランチが含まれています。 + `develop` ブランチは開発環境にデプロイされます。 + `main` ブランチは、QA、ステージ、本番環境にデプロイされます。 この設定では、新機能のアクティブな開発の進行中に、通常のデプロイサイクルよりも早くホットフィックスまたはセキュリティパッチを適用することが課題になります。修正プログラムやセキュリティリクエストに対処し、本番環境の適切な機能と安全性を確実に維持するには、専用のプロセスが必要です。 ただし、以下の場合は専用のデプロイプロセスを必要とせずに、使用可能な他のオプションを使用できます。 + CI/CD プロセスは、機能テストやエンドツーエンドテストなどの自動テストを備えているため、手動テストが不要になり、本番環境へのデプロイの遅延を防ぐことができます。ただし、自動テストが CI/CD プロセスに適切に統合されていない場合、本番環境に小規模の修正をプッシュすると、開発者側の作業が複雑化し、手間が増えてしまう可能性があります。これは、QA 環境で承認とサインオフを待機する新機能が存在する可能性があるためです。修正プログラムまたはセキュリティ修正プログラムを同時に本番環境にプッシュすることはできません。 + 開発チームは、新しい機能を本番環境に継続的にデプロイし、各新機能のスケジュールされたデプロイにホットフィックスまたはセキュリティパッチを統合します。つまり、本番環境への次の機能更新は、新機能の追加と、修正プログラムまたはセキュリティパッチの追加の 2 つの要素で構成されます。ただし、デプロイサイクルが連続していない場合は、QA 環境で承認を待機する複数の新機能が既に存在する可能性があります。異なるバージョンを管理し、正しい変更が再適用されるようにした場合、作業が複雑になり、エラーが発生しやすくなります。 **注記** `hotfix` バージョン [2 ](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types.html#:~:text=V2%20type%20pipelines%20have%20the%20same%20structure)を使用してブランチに AWS CodePipeline 適切なトリガーを設定している場合は、予定外のリクエストに対応するための専用プロセスが必要です。バージョン 2 では、プッシュリクエストまたはプルリクエストのトリガーを設定できます。実行は、パイプラインの以前の状態に応じて、キューに入れられるかすぐに実行されます。ただし、専用パイプラインでは、修正がすぐに本番環境に適用され、緊急の問題が遅滞なく解決されます。 # AWS CloudFormation スタックと関連リソースの削除を自動化する *SANDEEP SINGH および James Jacob、Amazon Web Services* ## 概要 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、クラウド Infrastructure as Code (IaC) を管理するために広く使用されているサービスです。CloudFormation を使用する際、関連リソースは*スタック*と呼ばれる単一のユニットとして管理します。スタックを作成、更新、削除することで、リソースのコレクションを作成、更新、削除します。 CloudFormation スタック内のリソースが不要になる場合があります。リソースとその設定によっては、スタックとその関連リソースの削除が複雑になる場合があります。実際の実稼働システムでは、CloudFormation が上書きできない競合する条件や制限により、削除が失敗する場合や、削除に長時間を要する場合があります。すべてのリソースが効率的かつ一貫した方法で適切に削除されるように、慎重な計画と実行が必要になることがあります。このパターンでは、以下のような複雑さを伴う CloudFormation スタックの削除を管理するのに役立つフレームワークを設定する方法について説明します。 + **削除保護を持つリソース** – 一部のリソースでは、削除保護が有効になっている場合があります。一般的な例としては、[Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) テーブルと [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) バケットがあります。削除保護は、CloudFormation による削除などの自動削除を防止します。これらのリソースを削除する場合、手動で、またはプログラムで削除保護を上書きまたは一時的に無効にする必要があります。先に進む前に、これらのリソースを削除する意味を慎重に検討する必要があります。 + **保持ポリシーを持つリソース** – AWS Key Management Service (AWS KMS) キーや Amazon S3 バケットなどの特定のリソースには、削除がリクエストされた後に保持する期間を指定する保持ポリシーがある場合があります。組織のポリシーと規制要件への準拠を維持するため、クリーンアップ戦略でこれらのポリシーを考慮する必要があります。 + **VPC にアタッチされている Lambda 関数の遅延削除** – 仮想プライベートクラウド (VPC) にアタッチされている [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 関数の削除には、プロセスに関連する相互接続された複数の依存関係に応じて、5～40 分が必要になります。スタックを削除する前に VPC から関数をデタッチすると、この遅延を 1 分未満まで短縮できます。 + **CloudFormation によって直接作成されていないリソース** – 特定のアプリケーション設計では、アプリケーション自体によって、またはスタックを介してプロビジョニングされたリソースによって、リソースが元の CloudFormation スタックの外部に作成される場合があります。以下に 2 つの例を示します。 + CloudFormation では、ユーザーデータスクリプトを実行する [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) インスタンスをプロビジョニングする場合があります。その後、このスクリプトはアプリケーション関連のデータを保存するための [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) パラメータを作成する場合があります。このパラメータは CloudFormation では管理されません。 + CloudFormation では、ログを保存するための [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) グループを自動的に生成する Lambda 関数をプロビジョニングする場合があります。このロググループは CloudFormation では管理されません。 これらのリソースは CloudFormation によって直接管理されることはありませんが、多くの場合スタックが削除されたときにクリーンアップする必要があります。管理対象外のままにしておくと孤立状態となり、不要なリソース消費につながる可能性があります。 これらのガードレールにより作業が煩雑化する可能性はありますが、これは重要度が高く意図的な仕様です。CloudFormation がすべての制約を上書きし、リソースを無差別に削除できるようにすると、多くのシナリオで有害で予期しない結果が生じる可能性があります。ただし、環境の管理を担当する DevOps またはクラウドエンジニアは、特に開発、テスト、またはステージング環境では、これらの制約を上書きする必要がある場合があります。 **ターゲットを絞ったビジネス成果** このフレームワークを実装すると、次の利点を実現できます。 + **コスト管理** – エンドツーエンドのテスト環境やユーザー受け入れテスト環境など、一時的な環境を定期的に効率的にクリーンアップすることで、リソースが必要以上に長く実行されないようにします。これにより、コストを大幅に削減できます。 + **セキュリティ** – 古いリソースや未使用のリソースの自動クリーンアップは、攻撃対象領域を減らし、安全な AWS 環境を維持するのに役立ちます。 + **運用効率** – 定期クリーンアップと自動クリーンアップには、次の運用上の利点があります。 + 古いロググループまたは空の Amazon S3 バケットを削除する自動スクリプトは、環境をクリーンで管理しやすいようにすることで、運用効率を向上させることができます。 + スタックを迅速に削除して再作成すると、設計と実装のための迅速なイテレーションが可能になるため、アーキテクチャの堅牢性と回復性が向上する可能性があります。 + 環境を定期的に削除および再構築すると、潜在的な問題を特定して修正するのに役立ちます。これにより、インフラストラクチャが現実のシナリオに耐えることができます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Python バージョン 3.6 以降が[インストールされている](https://www.python.org/downloads/) + 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)済み **制限事項** + 命名規則は、削除するリソースを識別するために使用されます。このパターンのサンプルコードでは、リソース名のプレフィックスが使用されますが、独自の命名規則を定義できます。この命名規則を使用しないリソースは識別されず、その後も削除されません。 ## アーキテクチャ 次の図は、このフレームワークがターゲット CloudFormation スタックとそれに関連付けられた追加のリソースをどのように識別するかを示しています。 ![\[CloudFormation スタックおよび関連するリソースを検出、処理、削除するフェーズ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ab7c3b56-3476-41a3-8ece-68915605a546/images/a7fceb1c-d624-47b3-957d-f910ef2f44d7.png) この図表は、次のワークフローを示しています: 1. **リソースの収集** – 自動化フレームワークでは命名規則を使用して、関連するすべての CloudFormation スタック、Amazon Elastic Container Registry (Amazon ECR) リポジトリ、DynamoDB テーブル、Amazon S3 バケットを返します。 **注記** このステージの関数では、切り捨てられた API 結果セットを反復するプロセスを抽象化する Boto3 の機能である[ページネーター](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html)が使用されます。これにより、すべてのリソースが確実に処理されます。パフォーマンスをさらに最適化するには、[サーバー側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results)フィルタリングを適用するか、JMESPath を使用して[クライアント側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results-with-jmespath)フィルタリングの実行を検討してください。 1. **前処理** – 自動化フレームワークは、CloudFormation がリソースを削除できるようにするために上書きする必要があるサービス制約を特定して対応します。例えば、DynamoDB テーブルの `DeletionProtectionEnabled` 設定を `False` に変更します。コマンドラインインターフェイスでは、リソースごとに制約を上書きするかどうか確認するプロンプトが表示されます。 1. **スタックの削除** – 自動化フレームワークは CloudFormation スタックを削除します。コマンドラインインターフェイスで、スタックを削除するかどうかを確認するプロンプトが表示されます。 1. **後処理** – 自動化フレームワークが、スタックの一部として CloudFormation から直接プロビジョニングされなかった関連リソースをすべて削除します。これらのリソースタイプの例には、Systems Manager パラメータおよび CloudWatch ロググループが含まれます。個別の関数は、これらのリソースを収集し、前処理してから削除します。コマンドラインインターフェイスでは、リソースごとにリソースを削除するかどうかを確認するプロンプトが表示されます。 **注記** このステージの関数では、切り捨てられた API 結果セットを反復するプロセスを抽象化する Boto3 の機能である[ページネーター](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html)が使用されます。これにより、すべてのリソースが確実に処理されます。パフォーマンスをさらに最適化するには、[サーバー側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results)フィルタリングを適用するか、JMESPath を使用して[クライアント側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results-with-jmespath)フィルタリングの実行を検討してください。 **自動化とスケール** CloudFormation スタックにサンプルコードに含まれていない他のリソースが含まれている場合、またはスタックにこのパターンで対処されていない制約がある場合、ユースケースに合わせて自動化フレームワークを適応させることができます。リソースの収集、前処理、スタックの削除、後処理と同じ手法に従います。 ## ツール **AWS のサービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [CloudFormation コマンドラインインターフェイス (CFN-CLI) ](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/what-is-cloudformation-cli.html)は、 AWS およびサードパーティーの拡張機能を開発およびテストし、CloudFormation で使用するために登録するのに役立つオープンソースツールです。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 **その他のツール** + [Click](https://click.palletsprojects.com/en/stable/) は、コマンドラインインターフェイスの作成に役立つ Python ツールです。 + [Poetry](https://python-poetry.org/docs/) は、Python での依存関係管理とパッケージングのためのツールです。 + [Pyenv](https://github.com/pyenv/pyenv) は、Python のバージョンを管理および切り替えるのに役立つツールです。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[cloudformation-stack-cleanup](https://github.com/aws-samples/cloudformation-stack-cleanup/)」リポジトリで利用できます。 ## ベストプラクティス + **識別しやすいようにリソースにタグを付ける** – [タグ付け戦略](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)を実行して、さまざまな環境や目的で作成されたリソースを特定します。タグに基づいてリソースをフィルタリングするのに役立つため、クリーンアッププロセスを簡素化できます。 + **リソースライフサイクルの設定** – 一定期間後にリソースを自動的に削除するために、リソースライフサイクルを定義します。この手法は、一時的な環境が永続的なコスト負担にならないようにするのに役立ちます。 ## エピック ### ツールをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア | | Poetry をインストールします。 | [手順](https://python-poetry.org/docs/) (Poetry ドキュメント) に従い、ターゲット仮想環境に Poetry をインストールします。 | DevOps エンジニア | | 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア | | (オプション) Pyenv をインストールします。 | [手順](https://github.com/pyenv/pyenv#installation) (GitHub) に従って Pyenv をインストールします。 | DevOps エンジニア | ### (オプション) フレームワークをカスタマイズする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットリソースを収集、前処理、削除する関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア、Python | ### サンプルリソースを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | AWS DevOps | | Systems Manager パラメータを作成します。 | 次のコマンドを入力し、CloudFormation を介してプロビジョニングされない Systems Manager パラメータを作成します。
aws ssm put-parameter \
  --name "/sampleforcleanup/database/password" \
  --value "your_db_password" \
  --type "SecureString" \
  --description "Database password for my app" \
  --tier "Standard" \
  --region "us-east-1"
| AWS DevOps | | Amazon S3 バケットを作成する。 | 次のコマンドを入力し、CloudFormation を介してプロビジョニングされない Amazon S3 バケットを作成します。
aws s3api create-bucket \
  --bucket samplesorcleanup-unmanagedbucket- \
  --region us-east-1 \
  --create-bucket-configuration LocationConstraint=us-east-1
| AWS DevOps | ### サンプルリソースを削除する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | AWS DevOps | | リソースの削除を検証します。 | 出力で、すべてのサンプルリソースが削除されていることを確認します。出力例については、このパターンの[追加リソース](#automate-deletion-cloudformation-stacks-associated-resources-additional)のセクションを参照してください。 | AWS DevOps | ## 関連リソース + [スタックを削除する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) (CloudFormation ドキュメント) + [CloudFormation のトラブルシューティング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html) (CloudFormation ドキュメント) + [Lambda 関数に Amazon VPC 内のリソースへのアクセスを許可する](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html) (Lambda ドキュメント) + [DELETE\$1FAILED ステータスのままになっている AWS CloudFormation スタックを削除するにはどうすればよいですか?](https://repost.aws/knowledge-center/cloudformation-stack-delete-failed) (AWS ナレッジセンター) ## 追加情報 以下は、`cfncli` コマンドからの出力例です。 ``` cfncli --region aus-east-1 dev cleanup-env --prefix-list sampleforcleanup https://sts.us-east-1.amazonaws.com Cleaning up: ['sampleforcleanup'] in xxxxxxxxxx:us-east-1 Do you want to proceed? [Y/n]: Y No S3 buckets No ECR repositories No Lambda functions in VPC The following DynamoDB tables will have their deletion protection removed: sampleforcleanup-MyDynamoDBTable Do you want to proceed with removing deletion protection from these tables? [Y/n]: Y Deletion protection disabled for DynamoDB table 'sampleforcleanup-MyDynamoDBTable'. The following CloudFormation stacks will be deleted: sampleforcleanup-Stack Do you want to proceed with deleting these CloudFormation stacks? [Y/n]: Y Initiated deletion of CloudFormation stack: `sampleforcleanup-Stack` Waiting for stack `sampleforcleanup-Stack` to be deleted... CloudFormation stack `sampleforcleanup-Stack` deleted successfully. The following ssm_params will be deleted: /sampleforcleanup/database/password Do you want to proceed with deleting these ssm_params? [Y/n]: Y Deleted SSM Parameter: /sampleforcleanup/database/password Cleaned up: ['sampleforcleanup'] ``` # Terraform を使用して Amazon Managed Grafana での Amazon MWAA カスタムメトリクスの取り込みと視覚化を自動化する *Faisal Abdullah、Satya Vajrapu (Amazon Web Services)* ## 概要 このパターンでは、Amazon Managed Grafana を使用して、Amazon Managed Workflows for Apache Airflow (Amazon MWAA) によって取り込まれるカスタムメトリクスを作成およびモニタリングする方法を説明します。Amazon MWAA はワークフローのオーケストレーターとして機能し、Python でスクリプト化された有向非巡回グラフ (DAG) を使用します。このパターンは、過去 1 時間以内に実行 DAG の合計数、1 時間あたりの合格および不合格の DAG の数、これらのプロセスの平均期間など、カスタムメトリクスのモニタリングに焦点を当てています。この分析は、Amazon Managed Grafana を Amazon MWAA と統合して、この環境内のワークフローのオーケストレーションに関する包括的なモニタリングとインサイトを実現する方法を示しています。 ## 前提条件と制限 **前提条件** + 以下を作成および管理するために必要なユーザーアクセス許可 AWS アカウント を持つアクティブな AWS のサービス。 + AWS Identity and Access Management (IAM) ロールとポリシー + AWS Lambda + Amazon Managed Grafana + Amazon Managed Workflows for Apache Airflow (Amazon MWAA) + Amazon Simple Storage Service (Amazon S3) + Amazon Timestream + ローカルマシンまたは [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) のターミナルであるシェル環境へのアクセス。 + Git がインストールされ、最新バージョンの AWS Command Line Interface (AWS CLI) がインストールされ、設定されているシェル環境。詳細については、 AWS CLI ドキュメントの[「 の最新バージョンのインストールまたは更新 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 + Terraform `required_version = ">= 1.6.1, < 2.0.0"` バージョンがインストール済み。[tfswitch](https://tfswitch.warrensbox.com/) を使用して、Terraform の異なるバージョンを切り替えることができます。 + AWS IAM アイデンティティセンター 用に で設定された ID ソース AWS アカウント。詳細については、IAM Identity Center ドキュメントの「[Confirm your identity sources in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereq-identity-sources.html)」を参照してください。デフォルト IAM アイデンティティセンターディレクトリ、Active Directory、または Okta などの外部 ID プロバイダー (IdP) から選択できます。詳細については、「[関連リソース](#automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics-resources)」を参照してください。 **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。 **製品バージョン** + Terraform `required_version = ">= 1.6.1, < 2.0.0"` + Amazon Managed Grafana バージョン 9.4 以降。このパターンはバージョン 9.4 でテストされました。 ## アーキテクチャ 次のアーキテクチャ図は、ソリューション AWS のサービス で使用される を示しています。 ![\[Amazon MWAA カスタムメトリクスの取り込みを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3458d0a9-aee1-428a-bf2f-c357bb531c64/images/b43ed8d2-94ac-4438-913b-81c7eba8f3e0.png) 前の図は、次のワークフローを段階的に示しています。 1. Amazon MWAA 内のカスタムメトリクスは、環境内で実行されている DAG から生成されます。メトリクスは、CSV ファイル形式で Amazon S3 バケットにアップロードされます。次の DAG は、Amazon MWAA のデータベースクエリ機能を使用します。 + `run-example-dag` – この DAG には、1 つ以上のタスクを定義するサンプル Python コードが含まれています。7 分ごとに実行され、日付が出力されます。日付の表示後、DAG には、特定の期間の実行をスリープまたは一時停止するタスクが含まれます。 + `other-sample-dag` – この DAG は 10 分ごとに実行され、日付を出力します。日付の表示後、DAG には、特定の期間の実行をスリープまたは一時停止するタスクが含まれます。 + `data-extract` – この DAG は 1 時間ごとに実行され、Amazon MWAA データベースをクエリしてメトリクスを収集します。メトリクスが収集されると、この DAG はそれらを Amazon S3 バケットに書き込み、さらに処理と分析を行います。 1. データ処理を効率化するため、Lambda 関数は Amazon S3 イベントによってトリガーされたときに実行されるため、Timestream へのメトリクスのロードが容易になります。 1. Timestream は Amazon Managed Grafana 内のデータソースとして統合されており、Amazon MWAA のすべてのカスタムメトリクスが保存されます。 1. ユーザーはデータをクエリし、カスタムダッシュボードを構築することで、主要なパフォーマンス指標を視覚化し、Amazon MWAA 内のワークフローのオーケストレーションに関するインサイトを得ることができます。 ## ツール **AWS のサービス** + [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用すると、すべての AWS アカウント およびクラウドアプリケーションへのシングルサインオン (SSO) アクセスを一元管理できます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。このパターンでは、 は Amazon S3 イベントに応答して Python コード AWS Lambda を実行し、コンピューティングリソースを自動的に管理します。 + [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) は、フルマネージド型データ可視化サービスであり、メトリクス、ログ、トレースを照会、関連付け、視覚化できます。このパターンでは、Amazon Managed Grafana を使用し、メトリクスの視覚化とアラートのためのダッシュボードを作成します。 + [Amazon Managed Workflows for Apache Airflow (Amazon MWAA)](https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html) は、Apache Airflow 用のマネージドオーケストレーションサービスで、クラウド上でデータパイプラインを大規模に設定、運用するために使用できます。[Apache Airflow](https://airflow.apache.org/) は、ワークフローと呼ばれる一連のプロセスとタスクをプログラムで作成、スケジュール、監視するために使用されるオープンソースのツールです。このパターンでは、サンプル DAG とメトリクスエクストラクタ DAG が Amazon MWAA にデプロイされます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このパターンでは、Amazon S3 を使用して DAG、スクリプト、カスタムメトリクスを CSV 形式で保存します。 + [Amazon Timestream for LiveAnalytics](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) は、高速でスケーラブルなフルマネージド型の専用時系列データベースで、1 日あたり何兆もの時系列データポイントの保存と分析を容易にします。また、LiveAnalytics の Timestream は、データ収集、視覚化、機械学習に一般的に使用されるサービスと統合されます。このパターンでは、生成された Amazon MWAA カスタムメトリクスを取り込むために使用されます。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースを割り当てて管理するのに役立つ Infrastructure as Code (IaC) ツールです。このパターンでは、Terraform モジュールを使用して AWSでのインフラストラクチャのプロビジョニングを自動化します。 **コードリポジトリ** このパターンのコードは、GitHub の [visualize-amazon-mwaa-custom-metrics-grafana](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana) リポジトリで入手できます。`stacks/Infra` フォルダには以下が含まれています。 + すべての AWS リソースの Terraform 設定ファイル + `grafana` フォルダ内の Grafana ダッシュボード .json ファイル + `mwaa/dags` フォルダ内の Amazon Managed Workflows for Apache Airflow DAG + .csv ファイルを解析し、メトリクスを `src` フォルダの Timestream データベースに保存するための Lambda コード + `templates` フォルダ内の IAM ポリシー .json ファイル ## ベストプラクティス Terraform は、実際のリソースを設定にマッピングできるよう、マネージドインフラストラクチャと設定に関する状態を保存する必要があります。デフォルトでは、Terraform は `terraform.tfstate` という名前のファイルに状態をローカルに保存します。インフラストラクチャの現在の状態が維持されるため、Terraform 状態ファイルの安全性と整合性を確保することが重要です。詳細については、Terraform ドキュメントの「[Remote State](https://developer.hashicorp.com/terraform/language/state/remote)」を参照してください。 ## エピック ### Terraform を使用してインフラストラクチャをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャを準備します。 | ソリューションインフラストラクチャをデプロイするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps | ### デプロイされたインフラストラクチャリソースを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon MWAA 環境を検証する | Amazon MWAA 環境を検証するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps、データエンジニア | | DAG スケジュールを確認します。 | 各 DAG スケジュールを表示するには、**Airflow UI** の **[Schedule]**タブに移動します。以下の各 DAG には、Amazon MWAA 環境で実行され、カスタムメトリクスを生成する事前設定されたスケジュールがあります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)各 DAG が正常に実行されたことを **Runs** 列で確認することもできます。 | データエンジニア、AWS DevOps | ### Amazon Managed Grafana 環境を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Managed Grafana ワークスペースへのアクセスを設定します。 | Terraform スクリプトが、必要な Amazon Managed Grafana ワークスペース、ダッシュボード、メトリクスページを作成しました。アクセスを表示できるように設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps | | Amazon Timestream プラグインをインストールします。 | Amazon MWAA カスタムメトリクスは、Timestream データベースにロードされます。Timestream プラグインを使用し、Amazon Managed Grafana ダッシュボードでメトリクスを視覚化します。Timestream プラグインをインストールするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)詳細については、Amazon Managed Grafana ドキュメントの「[Extend your workspace with plugins](https://docs.aws.amazon.com/grafana/latest/userguide/grafana-plugins.html#manage-plugins)」を参照してください。 | AWS DevOps、DevOps エンジニア | ### Amazon Managed Grafana ダッシュボードでカスタムメトリクスを視覚化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Managed Grafana ダッシュボードを表示します。 | Amazon Managed Grafana ワークスペースに取り込まれたメトリクスを表示するには次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)ダッシュボードのメトリクスページには、次の情報が表示されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps | | Amazon Managed Grafana ダッシュボードをカスタマイズします。 | 今後の機能強化のためにダッシュボードをカスタマイズするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)または、このダッシュボードのソースコードは、[GitHub リポジトリ](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana/blob/main/stacks/infra/grafana/dashboard.json)の `stacks/infra/grafana` フォルダの `dashboard.json` ファイルで使用できます。 | AWS DevOps | ### AWS リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon MWAA DAG の実行を一時停止します。 | DAG 実行を一時停止するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps、データエンジニア | | Amazon S3 バケットのオブジェクトを削除します。 | Amazon S3 バケットの **mwaa-events-bucket-\$1** および **mwaa-metrics-bucket-\$1** を削除するには、Amazon S3 ドキュメントの「[汎用バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」で Amazon S3 コンソールを使用する手順に従ってください。 | AWS DevOps | | Terraform によって作成されたリソースを破棄します。 | Terraform によって作成されたリソースと関連するローカル Terraform 状態ファイルを破棄するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `null_resource.plugin_mgmt (local-exec): aws: error: argument operation: Invalid choice, valid choices are:` | AWS CLI を[最新バージョン](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)にアップグレードします。 | | データソースのロードエラー: `Fetch error: 404 Not Found Instantiating…` | エラーは断続的です。数分待ってからデータソースを更新して、リストされた Timestream データソースを表示します。 | ## 関連リソース **AWS ドキュメント** + [ダッシュボードと可視化のための Amazon Managed Grafana](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/amg-dashboarding-visualization.html) + [Okta を使用するように Amazon Managed Grafana を設定する](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-SAML-providers-okta.html) + [Amazon Managed Grafana ワークスペース AWS IAM アイデンティティセンター で を使用する](https://docs.aws.amazon.com/grafana/latest/userguide/authentication-in-AMG-SSO.html) + [Amazon MWAA での DAGs の使用](https://docs.aws.amazon.com/mwaa/latest/userguide/working-dags.html) **AWS ビデオ** + 次の[ビデオ](https://www.youtube.com/watch?v=XX2Xcz-Ps9U)に示されているように、認証用に Amazon Managed Grafana で IAM Identity Center を設定します。 [https://www.youtube-nocookie.com/embed/XX2Xcz-Ps9U?controls=0](https://www.youtube-nocookie.com/embed/XX2Xcz-Ps9U?controls=0) + IAM Identity Center が利用できない場合は、次の[動画](https://www.youtube.com/watch?v=Z4JHxl2xpOg)に示されているように、Okta などの外部 ID プロバイダー (IdP) を使用して Amazon Managed Grafana 認証を統合することもできます。 [https://www.youtube-nocookie.com/embed/Z4JHxl2xpOg?controls=0](https://www.youtube-nocookie.com/embed/Z4JHxl2xpOg?controls=0) ## 追加情報 Amazon MWAA 環境の包括的なモニタリングおよびアラートソリューションを作成し、事前対応型の管理と潜在的な問題や異常への迅速な対応を可能にします。Amazon Managed Grafana には次の機能が含まれています。 **アラート** – 事前定義されたしきい値または条件に基づいて、Amazon Managed Grafana にアラートを設定できます。特定のメトリクスが指定されたしきい値を上回ったり下回ったりした場合に、関連するステークホルダーに警告する E メール通知を設定します。詳細については、Amazon Managed Grafana ドキュメントの「[Grafana alerting](https://docs.aws.amazon.com/grafana/latest/userguide/alerts-overview.html)」を参照してください。 **統合** – Amazon Managed Grafana を OpsGenie、PagerDuty、Slack などのさまざまなサードパーティーツールと統合し、通知機能を強化できます。例えば、Amazon Managed Grafana で生成されたアラートに基づいて、ウェブフックを設定したり API と統合したりして、これらのプラットフォームでインシデントや通知をトリガーしたりできます。さらに、このパターンは AWS リソースを作成するための [GitHub リポジトリ](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana)を提供します。このコードをインフラストラクチャのデプロイワークフローとさらに統合できます。 # AWS CodePipeline および AWS CodeBuild を使用して、スタックセットデプロイを自動化 *Thiyagarajan Mani、Mihir Borkar、Raghu Gowda (Amazon Web Services)* ## 概要 継続的統合と継続的デリバリ (CI/CD) のプロセスでは、既存のすべてのAWSアカウントと、AWS Organizationsで組織に追加する新しいアカウントにアプリケーションを自動的にデプロイする場合があります。この要件に対応する CI/CD ソリューションを設計する場合、AWS CloudFormation の[委任スタックセット管理者](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) キャパシティが役立ちます。管理アカウントへのアクセスを制限することでセキュリティレイヤーを実現できるためです。ただし、AWS CodePipeline はサービス管理型のアクセス権限モデルを使用して、アプリケーションを複数のアカウントとリージョンにデプロイします。AWS CodePipeline に委任スタックセット管理者機能が適用されないため、 AWS Organizations 管理アカウントを使用して、スタックセットでデプロイします。 このパターンでは、この制限を回避する方法を示しています。このパターンでは、AWS CodeBuild とカスタムスクリプトを使用して、AWS CodePipeline 付けのスタックセットのデプロイを自動化します。以下のアプリケーションデプロイアクティビティを自動化します。 + アプリケーションをスタックセットとして既存の組織単位 (OU) にデプロイ + アプリケーションのデプロイをその他の OU やリージョンにまで拡張  + デプロイされたアプリケーションをすべてまたは特定の OU またはリージョンから削除 ## 前提条件と制限事項 **前提条件** このパターンのステップに従う前に、 + AWS Organizations の管理アカウントで組織を作成します。手順については、[AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_create.html)を参照してください。 + AWS Organizations と CloudFormation 間の信頼できるアクセスを有効にして、サービス管理の権限を使用します。手順について、CloudFormation ドキュメントの[AWS Organizations との信頼できるアクセスを有効にする](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html) を参照してください。 **機能制限** このパターンで提供されるコードには以下の制限があります。  + 1 つのアプリケーションにデプロイする CloudFormation テンプレートは 1 つだけです。複数のテンプレートのデプロイが現在サポートされていません。 + 現在の実装をカスタマイズするには、DevOpsの専門知識が必要です。 + このパターンでは AWS キー管理システム (AWS KMS) キーは使用されません。ただし、このパターンに含まれている CloudFormation テンプレートを再設定することで、この機能を有効にできます。 ## アーキテクチャ ![\[CI/CD パイプライン自動化アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a5c47de7-9039-415d-a9e5-9de0d4c3a260/images/2dbca422-7f32-4f9c-a4aa-1f95b484b772.png) この CI/CD デプロイパイプラインのアーキテクチャは、以下を処理します。 + スタックセットデプロイの責任を、アプリケーションデプロイのスタックセット管理者として専用 CI/CD アカウントに委任することで、管理アカウントへの直接アクセスを制限します。 + サービス管理型の権限モデルを使用して、OU に新しいアカウントが作成されマッピングされるたびに、アプリケーションを自動的にデプロイします。 + 環境レベルですべてのアカウントでアプリケーションバージョンの一貫性を確保します。 + リポジトリレベルとパイプラインレベルで複数の承認ステージを使用して、デプロイされたアプリケーションのセキュリティとガバナンスをさらに強化します。 + CodeBuild のカスタムビルドのデプロイスクリプトを使用して、スタックセットとスタックインスタンスを自動的にデプロイまたは削除することで、CodePipeline の現在の制限を克服します。カスタムスクリプトによって実装される API 呼び出しのフロー制御と階層の図について、[追加情報](#automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild-additional) セクションを参照してください。 + 開発環境、テスト環境、本番環境用に個別のスタックセットを作成します。さらに、各段階で複数の OU とリージョンを組み合わせたスタックセットを作成できます。たとえば、開発デプロイメント段階でサンドボックスと開発 OU を組み合わせることができます。 + アカウントのサブセットや OU リストへのアプリケーションのデプロイや除外が適用されます。 **自動化とスケール** このパターンで提供されるコードを使用して、AWS CodeCommit リポジトリとアプリケーション用のコードパイプラインを作成できます。その後、これらをスタックセットとして OU レベルで複数のアカウントにデプロイできます。このコードでは、承認者に通知する Amazon Simple Notification Service (Amazon SNS) トピック、必要な AWS Identity and Access Management (IAM) ロール、管理アカウントに適用するサービスコントロールポリシー (SCP) などのコンポーネントも自動化されます。 ## ツール **AWS サービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、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 Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理している複数の AWS アカウントを組織に統合するためのアカウント管理サービスです。 + 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[自動コードパイプラインスタックセットデプロイ](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment)」リポジトリで利用できます。フォルダ構造やその他の詳細については、リポジトリの [readme ファイル](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment/blob/main/README.md)を参照してください。 ## ベストプラクティス このパターンでは、OU レベルでアプリケーションをデプロイしている間、管理アカウントへの直接アクセスが制限されます。パイプラインとリポジトリのプロセスに複数の承認ステージを追加することで、このアプローチを使用してデプロイするアプリケーションとコンポーネントのセキュリティとガバナンスを強化できます。 ## エピック ### AWS Organizations アカウントを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 管理アカウントですべての特徴量を有効にします。 | [AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) の指示に従って、組織の管理アカウントのすべての機能を有効にします。 | AWS 管理者、プラットフォーム管理者 | | CI/CD アカウントを作成します。 | AWS Organizations では、組織内で専用の CI/CD アカウントを作成し、そのアカウントへのアクセスを所有および管理するチームを割り当てます。 | AWS 管理者 | | 委任管理者を追加する | 管理アカウントに、前のステップで作成した CI/CD アカウントを委任スタックセット管理者として登録します。手順については、[AWS CloudFormation のドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) を参照してください。 | AWS 管理者、プラットフォーム管理者 | ### アプリケーションリポジトリと CI/CD パイプラインを作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードリポジトリを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps | | SNS トピックを作成します。 | GitHub リポジトリに用意されている `sns-template.yaml` テンプレートを使用して SNS トピックを作成し、承認リクエストのサブスクリプションを設定できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps | | CI/CD コンポーネントの IAM ロールを作成します。 | GitHub リポジトリに用意されている `cicd-role-template.yaml` テンプレートを使用して、CI/CD コンポーネントに必要な IAM ロールとポリシーを作成できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps | | アプリケーションの CodeCommit リポジトリとコードパイプラインを作成します。 | GitHub リポジトリに提供されている `cicd-pipeline-template.yaml` テンプレートを使用して、アプリケーションの CodeCommit リポジトリとコードパイプラインを作成できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps | ### スタックセットをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションリポジトリをクローニングします。 | 以前に使用した CI/CD パイプラインテンプレートは、サンプルアプリケーションリポジトリとコードパイプラインを作成します。リポジトリを複製して検証するには：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア | | アプリケーションアーティファクトの追加。 | CloudFormation テンプレートを使用してアプリケーションリポジトリを更新します。このソリューションでは、単一の CloudFormation テンプレートのデプロイのみが適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア | | デプロイ設定ファイルを更新します。 | ファイルを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html)このパターンでは、デプロイ設定ファイルに指定したスタックセット名に環境名を追加して、環境ごとに個別のスタックセットを作成します。 | アプリ開発者、データエンジニア | | 変更内容をコミットし、スタックセットをデプロイします。 | アプリケーションテンプレートで指定した変更をコミットし、スタックセットを複数の環境に段階的にマージしてデプロイします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 例外のせいでデプロイが失敗しました。*テンプレートパラメータファイルの名前を<アプリケーション名>-パラメータ-.json に変更します。デフォルトの名前は使用できません* | CloudFormation テンプレートのパラメータファイルは、指定された命名規則に従う必要があります。パラメータファイル名を更新し、再試行します。 | | 例外のせいでデプロイが失敗しました。*CloudFormation テンプレートの名前を <アプリケーション名>.yml 、デフォルトのテンプレート.yml 、または template.yaml は使用できませんに変更します* | CloudFormation テンプレートのパラメータファイルは、指定された命名規則に従う必要があります。ファイル名を更新して、再試行します。 | | 例外のせいでデプロイが失敗しました。*\$1環境名\$1 環境の有効な CloudFormation テンプレートとそのパラメータファイルが見つかりません* | CloudFormation テンプレートのファイル命名規則と、指定された環境のパラメータファイルを確認します。 | | 例外のせいでデプロイが失敗しました。*デプロ設定ファイルに無効なデプロイアクションが提供されています。有効なオプションは「デプロイ」と「削除」です。* | デプロイ設定ファイルの `deployment_action` パラメータに無効な値を指定しました。このパラメータには、`deploy` と `delete` の 2 つの有効な値があります。`deploy` を使用して、スタックセットとそれに関連するスタックインスタンスを作成、更新します。スタックセット全体と関連するスタックインスタンスを削除する場合のみ、`delete` を使用します。 | ## 関連リソース + GitHub [自動コードパイプラインスタックセットデプロイ](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment) リポジトリ + [組織内のすべての特徴量の有効化](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) (AWS Organizations ドキュメント) + [委任管理者を登録](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) (AWS CloudFormation ドキュメント) + [サービスマネージド型スタックセットのアカウントレベルのターゲット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/account-level-targets.html) (AWS CloudFormation ドキュメント) ## 追加情報 **フローチャート** 次のフローチャートは、スタックセットのデプロイを自動化するためにカスタムスクリプトによって実装される API 呼び出しのフロー制御と階層を示しています。 ![\[Python スクリプトによって実装されたフロー制御と API 呼び出し\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a5c47de7-9039-415d-a9e5-9de0d4c3a260/images/1898883a-62b7-40c2-8f08-9f2a9dda8404.png) ** サンプルのデプロイ設定ファイル** **新しいスタックセットの作成t** 次のデプロイ設定ファイルは、3 つの OU の AWS リージョン `us-east-1` の `sample-stack-set` と呼ばれる新しいスタックセットを作成します。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` **既存のスタックセットを別の OU にデプロイ** 前の例で示した設定をデプロイし、`dev-org-unit-2` 開発環境で呼び出される別の OU にスタックセットをデプロイする場合、デプロイ設定ファイルは次のようになります。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1", "dev-org-unit-2"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` **既存のスタックセットを別の AWS リージョンにデプロイ** 前の例で示した設定をデプロイし、2 つの OU( `dev-org-unit-1` と `dev-org-unit-2` ) の開発環境内の別の AWS リージョン (`us-east-2`) にスタックセットをデプロイする場合、デプロイ設定ファイルは次のようになります。 **注記** CloudFormation テンプレート内のリソースは有効で、リージョン固有である必要があります。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1", "dev-org-unit-2"], "regions": ["us-east-1", "us-east-2"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` **OU または AWS リージョンからのスタックインスタンスを削除** 前の例で示したデプロイ設定がデプロイされたとみなされます。次の設定ファイルは OU `dev-org-unit-2` の両方のリージョンからスタックインスタンスを削除します。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1"], "regions": ["us-east-1", "us-east-2"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` 次の設定ファイルは、開発環境内の両方の OU の AWS リージョン `us-east-1` からスタックインスタンスを削除します。    ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1", "dev-org-unit-2"], "regions": ["us-east-2"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` **スタックセット全体を削除します。** 次のデプロイ設定ファイルは、スタックセット全体と関連するスタックインスタンスを削除します。 ``` { "deployment_action": "delete", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1", "dev-org-unit-2"], "regions": ["us-east-2"], "filter_accounts": [], "filter_type": "" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` * ***デプロイメントからアカウントを除外します。**  次のデプロイ設定ファイルでは、OU `dev-org-unit-1` の一部であるアカウント `111122223333` がデプロイから除外されます。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": ["111122223333"], "filter_type": "DIFFERENCE" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` **OU のアカウントのサブセットにアプリケーションをデプロイ** 次のデプロイ設定ファイルでは、OU `dev-org-unit-1` の 3 つのアカウント(`111122223333`、`444455556666`、および `777788889999`)にのみアプリケーションをデプロイします。 ``` { "deployment_action": "deploy", "stack_set_name": "sample-stack-set", "stack_set_desciption": "this is a sample stack set", "deployment_targets": { "dev": { "org_units": ["dev-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": ["111122223333", "444455556666", "777788889999"], "filter_type": "INTERSECTION" }, "test": { "org_units": ["test-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" }, "prod": { "org_units": ["prod-org-unit-1"], "regions": ["us-east-1"], "filter_accounts": [], "filter_type": "" } }, "cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"], "auto_deployement": "True", "retain_stacks_on_account_removal": "True", "region_deployment_concurrency": "PARALLEL" } ``` # Cloud Custodian と AWS CDK を使用して、Systems Manager の AWS マネージドポリシーを EC2 インスタンスプロファイルに自動的にアタッチする *Ali Asfour、Aaron Lennon (Amazon Web Services)* ## 概要 運用タスクを自動化し、より多くの可視性と制御を提供する AWS Systems Manager に、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを統合することができます。Systems Manager と統合するには、EC2 インスタンスに [AWS Systems Manager Agent(SSM Agent)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) をインストールし、`AmazonSSMManagedInstanceCore` AWS Identity and Access Management (IAM) ポリシーをプロファイルに追加する必要があります。  ただし、すべての EC2 インスタンスプロファイルに `AmazonSSMManagedInstanceCore` ポリシーを確実にアタッチする場合、インスタンスプロファイルを持たない新規 EC2 インスタンスや、インスタンスプロファイルを持つが `AmazonSSMManagedInstanceCore` ポリシーを持たない EC2 インスタンスを更新する際に問題が発生する可能性があります。また、このポリシーを複数の Amazon Web Services (AWS) アカウントや AWS リージョンに追加することが難しい場合もあります。 このパターンは、AWS アカウントに次の 3 つの [Cloud Custodian](https://cloudcustodian.io/) ポリシーをデプロイすることで、これらの課題を解決するのに役立ちます。 + 最初の Cloud Custodian ポリシーは、インスタンスプロファイルを持つが、`AmazonSSMManagedInstanceCore` ポリシーを持たない既存の EC2 インスタンスをチェックします。その後、`AmazonSSMManagedInstanceCore` ポリシーがアタッチされます。  + 2 つ目の Cloud Custodian ポリシーは、インスタンスプロファイルのない既存の EC2 インスタンスをチェックし、`AmazonSSMManagedInstanceCore` ポリシーがアタッチされたデフォルトのインスタンスプロファイルを追加します。 + 3 つ目の Cloud Custodian ポリシーでは、EC2 インスタンスとインスタンスプロファイルの作成を監視するための [AWS Lambda 関数](https://cloudcustodian.io/docs/aws/lambda.html)をアカウント内に作成します。これにより、EC2 インスタンスの作成時に自動的に `AmazonSSMManagedInstanceCore` ポリシーがアタッチされます。 このパターンは、[AWS DevOps](https://aws.amazon.com/devops/) ツールを使用することで、個別のコンピューティング環境をプロビジョニングすることなく、マルチアカウント環境で Cloud Custodian ポリシーの継続的かつ大規模なデプロイを実現します。  ## 前提条件と制限 **前提条件** + 2 つ以上の AWS アカウントがアクティブである。一方のアカウントは*セキュリティアカウント*で、他方は*メンバーアカウント*である。 + セキュリティアカウントで AWS リソースをプロビジョニングする権限がある。このパターンでは、[管理者権限](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)を使用しますが、組織の要件とポリシーに従って権限を付与する必要があります。 + セキュリティアカウントから IAM ロールをメンバーアカウントに引き継ぎ、必要な IAM ロールを作成できます。詳細については、IAM ドキュメントの「[IAM ロールを使用して AWS アカウント間でアクセスを委任する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)」を参照してください。 + **重要** AWS コマンドラインインターフェイス (AWS CLI) をインストールして設定済み。テスト目的で、`aws configure` コマンドを使用するか、環境変数を設定することで、AWS CLI を設定できます。: これは本番環境では推奨されません。このアカウントには、最小特権のみ付与することをお勧めします。詳細については、IAM ドキュメントの「[最小特権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。 + `devops-cdk-cloudcustodian.zip` ファイル (添付) は、ローカルコンピュータにダウンロードされます。 + Python に精通していること。 + 必要なツール (Node.js、AWS Cloud Development Kit (AWS CDK)、および Git) をインストールして設定済み。`devops-cdk-cloudcustodian.zip` ファイル内の `install-prerequisites.sh` ファイルを使用して、これらのツールをインストールできます。****このファイルを root 権限で実行していることを確認します。****  **機能制限** + このパターンは実稼働環境でも使用できますが、すべての IAM ロールとポリシーが組織の要件とポリシーを満たしていることを確認してください。  **パッケージバージョン** + Cloud Custodian バージョン 0.9 以降 + TypeScript バージョン 3.9.7 以降 + Node.js バージョン 14.15.4 以降 + `npm` バージョン 7.6.1 以降 + AWS CDK バージョン 1.96.0 またはそれ以降 ## アーキテクチャ ![\[AWS CodePipeline workflow with CodeCommit, CodeBuild, and deployment to member accounts.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/169a7bde-789e-4ebd-b4ca-80eb28ac9927/images/8ec0b6b4-d4b0-42e5-833d-24d1e6098fd9.png) この図表は、次のワークフローを示しています: 1. Cloud Custodian ポリシーが、セキュリティ アカウントに AWS CodeCommit リポジトリにプッシュされます。Amazon CloudWatch Events ルールは、AWS CodePipeline パイプラインを自動的に起動します。 1. パイプラインは CodeCommit から最新のコードを取得し、AWS CodeBuild で処理される CI/CD (継続統合および継続配信) パイプラインの継続的な統合部分に送信します。 1. CodeBuild は、Cloud Custodian ポリシーのポリシー構文検証を含む完全な DevSecOps アクションを実行し、`--dryrun` モードでこれらのポリシーを実行して、どのリソースが認識されているかをチェックします。 1. エラーがなければ、次のタスクで変更を確認し、メンバーアカウントへのデプロイを承認するよう管理者にアラートが送信されます。 **テクノロジースタック** + AWS CDK + CodeBuild + CodeCommit + CodePipeline + IAM + Cloud Custodian  **自動化とスケール** AWS CDK Pipelines モジュールは、AWS CloudFormation スタックを使用した AWS リソースのデプロイに加え、CodePipeline を使用する CI/CD コンジットをプロビジョニングして、CodeBuild を介したソースコードのビルドとテストをオーケストレーションします。このパターンは、組織内のすべてのメンバーアカウントとリージョンで使用できます。`Roles creation` スタックを拡張して、メンバーアカウントに他の IAM ロールをデプロイすることもできます。  ## ツール + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation を通じてプロビジョニングするための、ソフトウェア開発フレームワーク + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) はオープンソースのツールであり、コマンドラインシェルのコマンドを使用して 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) は、プライベートな保存と管理を有効にするバージョン管理サービスです。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)は、ソフトウェアをリリースするために必要な手順のモデル化、視覚化、および自動化に使用できる継続的な配信サービスです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、AWS リソースへのアクセスをセキュアに制御するためのウェブサービスです。 + [Cloud Custodian](https://cloudcustodian.io/) は、多くの組織がパブリック クラウドアカウントの管理に使用しているツールとスクリプトを 1 つのオープンソースツールに統合します。 + [Node.js](https://nodejs.org/en/) は Google Chrome の V8 JavaScript エンジンをベースに構築された JavaScript ランタイムです。 **コード ** このパターンで使用されるモジュール、アカウント関数、ファイル、およびデプロイコマンドの詳細なリストについては、`devops-cdk-cloudcustodian.zip` ファイル（添付） `README` 内のファイルを参照してください。 ## エピック ### AWS CDK でパイプラインをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CodeCommit リポジトリを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)詳細については、AWS CodeCommit ドキュメントの「[CodeCommit リポジトリの作成](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-repository.html)」を参照してください。 | 開発者 | | 必要なツールをインストールします。 | `install-prerequisites.sh` ファイルを使用して Amazon Linux に必要なすべてのツールをインストールします。AWS CLI は事前にインストールされているため、含まれていません。詳細については、AWS CDK ドキュメントの「[AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」にある「[前提条件](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html#getting_started_prerequisites)」セクションを参照してください。 | 開発者 | | 必要な AWS CDK パッケージをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)以下のパッケージは AWS CDK に必要であり、`requirements.txt` ファイルに含まれています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html) | 開発者 | ### 環境の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 必要な変数を更新してください。 | CodeCommit `vars.py` リポジトリのルートフォルダにあるファイルを開き、次の変数を更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html) | 開発者 | | account.yml ファイルをメンバーアカウント情報で更新します。 | [c7n-org Cloud Custodian](https://cloudcustodian.io/docs/tools/c7n-org.html) ツールを複数のアカウントに対して実行するには、`accounts.yml` 設定ファイルをリポジトリのルートに配置する必要があります。以下は、AWS の Cloud Custodian 設定のサンプルファイルです。
accounts:
- account_id: '123123123123'
  name: account-1
  regions:
  - us-east-1
  - us-west-2
  role: arn:aws:iam::123123123123:role/CloudCustodian
  vars:
    charge_code: xyz
  tags:
  - type:prod
  - division:some division
  - partition:us
  - scope:pci
| 開発者 | ### AWS アカウントをブートストラップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | セキュリティアカウントをブートストラップします。 | 以下のコマンドを実行して、`cloudcustodian_stack` アプリケーションで `deploy_account` をブートストラップします。
cdk bootstrap -a 'python3 
cloudcustodian/cloudcustodian_stack.py
| 開発者 | | オプション 1 - メンバーアカウントを自動的にブートストラップします。　 | `vars.py` ファイルで `cdk_bootstrap_member_accounts` 変数が `True` に設定されている場合、`member_accounts` 変数で指定されたアカウントは パイプラインによって自動的にブートストラップされます。必要に応じて、IAM ロールを使用して `*cdk_bootstrap_role*` を更新できます。このロールは、セキュリティアカウントから引き受けることができ、AWS CDK をブートストラップするために必要な権限を持っています。`member_accounts ` 変数に追加された新規アカウントは、パイプラインによって自動的にブートストラップされ、必要なロールをデプロイできるようになります。 | 開発者 | | オプション 2 - メンバーアカウントを手動でブートストラップします。　 | この方法はお勧めしませんが、`cdk_bootstrap_member_accounts` の値を `False` に設定し、次のコマンドを使用して手動で実行できます：
$ cdk bootstrap -a 'python3 cloudcustodian/member_account_roles_stack.py' \

--trust {security_account_id} \

--context assume-role-credentials:writeIamRoleName={role_name} \

--context assume-role-credentials:readIamRoleName={role_name} \

--mode=ForWriting \

--context bootstrap=true \

--cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess
`{security_account_id}` と `{role_name}` の値は、セキュリティアカウントから引き受けることができ、AWS CDK のブートストラップに必要な権限を持つ IAM ロールの名前で更新されることを確認してください。AWS CloudFormation など、他の方法を使用してメンバーアカウントをブートストラップすることもできます。詳細については、AWS CDK ドキュメントの「[ブートストラップ](https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)」を参照してください。 | 開発者 | ### AWS CDK スタックをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メンバーアカウントで IAM ロールを作成します。 | 次のコマンドを実行して、`member_account_roles_stack` スタックをデプロイし、メンバーアカウントに IAMロールを作成します：
cdk deploy --all -a 'python3 cloudcustodian/member_account_roles_stack.py' --require-approval never
| 開発者 | | Cloud Custodian パイプラインスタックをデプロイします。　 | 次のコマンドを実行して、セキュリティアカウントにデプロイされる Cloud Custodian `cloudcustodian_stack.py` パイプラインを作成します。
cdk deploy -a 'python3 cloudcustodian/cloudcustodian_stack.py'
| 開発者 | ## 関連リソース + [AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/169a7bde-789e-4ebd-b4ca-80eb28ac9927/attachments/attachment.zip)」 # AWS CDK を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECS クラスターを自動的に構築する *Varsha Raju (Amazon Web Services)* ## 概要 このパターンは、Amazon Elastic Container Service (Amazon ECS) でマイクロサービスを構築およびデプロイするための、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと基盤となるインフラストラクチャを自動的に作成する方法を示しています。概念実証の CI/CD パイプラインを設定して、組織に CI/CD、マイクロサービス、DevOps の利点を説明する場合は、このアプローチを使用できます。また、このアプローチを使用して最初の CI/CD パイプラインを作成し、組織の要件に応じてカスタマイズまたは変更もできます。  このパターンのアプローチでは、本番環境と非本番環境を作成し、それぞれに仮想プライベートクラウド (VPC) と 2 つのアベイラビリティーゾーンで実行するように設定された Amazon ECS クラスターがあります。これらの環境はすべてのマイクロサービスとユーザーで共有され、各マイクロサービスに CI/CD パイプラインを作成します。これらの CI/CD パイプラインは、AWS CodeCommit のソースリポジトリから変更を取得し、変更を自動的にビルドして、本番環境と非本番環境にデプロイします。パイプラインがすべてのステージを正常に完了すると、URL を使用して本番環境と非本番環境のマイクロサービスにアクセスできます。 ## 前提条件と制限事項 **前提条件** + アクティブな Amazon Web Services (AWS)アカウント。 + `starter-code.zip` ファイル (添付) を含む既存の Amazon Simple Storage Service (Amazon S3) バケット。 + AWS Cloud Development Kit (AWS CDK) はお使いのアカウントにインストールおよび設定済みです。詳細については、AWS CDK ドキュメントの「[Getting started with the AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」を参照してください。 + Python 3 と `pip` をインストールおよび設定済みです。詳細については、[Python のドキュメント](https://www.python.org/)を参照してください。 + AWS CDK、AWS CodePipeline、AWS CodeBuild、CodeCommit、Amazon Elastic Container Registry (Amazon ECR)、Amazon ECS、AWS Fargate に精通していること。 + Docker に精通していること。 + CI/CD と DevOps について理解していること。 **制限** + AWS アカウントの全般的な制限が適用されます。この詳細については、AWS 全般のリファレンスドキュメントの「[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。 **製品バージョン** + このコードは、 Node.js バージョン 16.13.0 および AWS CDK バージョン 1.132.0 を使用してテストされました。 ## アーキテクチャ ![\[AWS クラウド architecture diagram showing CI/CD pipeline and deployment to production and non-production VPCs.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/05ac2cad-408e-433f-8150-0a2b71f63cfd/images/6fa3dbef-88de-4b3f-ae41-dfa90256a058.png) この図表は、次のワークフローを示しています: 1. アプリ開発者は CodeCommit リポジトリにコードをコミットします。 1. パイプラインが開始されます。 1. CodeBuild は、Docker イメージをビルドして Amazon ECR リポジトリにプッシュします。 1. CodePipeline は、非本番環境の Amazon ECS クラスター内の既存の Fargate サービスに新しいイメージをデプロイします。 1. Amazon ECS は Amazon ECR リポジトリから非本番環境の Fargate サービスにイメージを引き出します。 1. テストは非本番環境の URL を使用して実行されます。 1. リリースマネージャーは本番環境へのデプロイを承認します。 1. CodePipeline は、新しいイメージを本番環境の Amazon ECS クラスター内の既存の Fargate サービスにデプロイします。 1. Amazon ECS は Amazon ECR リポジトリから本番環境の Fargate サービスにイメージを引き出します。 1. 本番環境ユーザーは本番環境の URL を使用して機能にアクセスします。 **テクノロジースタック** + AWS CDK + CodeBuild + CodeCommit  + CodePipeline + Amazon ECR  + Amazon ECS  + Amazon VPC **自動化とスケール** このパターンのアプローチを使用して、共有の AWS CloudFormation スタックにデプロイされたマイクロサービスのパイプラインを作成できます。自動化により、各 VPC に複数の Amazon ECS クラスターを作成できるほか、共有 Amazon ECS クラスターにデプロイされたマイクロサービスのパイプラインも作成できます。ただし、そのためには、新しいリソース情報をパイプラインスタックへの入力として提供する必要があります。 ## ツール + [AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/home.html)— AWS Cloud Development Kit (AWS CDK) は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation でプロビジョニングするソフトウェア開発フレームワークです。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) - AWS CodeBuild はクラウドの完全マネージド型のビルドサービスです。CodeBuild はソースコードをコンパイルし、ユニットテストを実行して、すぐにデプロイできるアーティファクトを作成します。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) – AWS CodeCommit は、 AWS クラウドでの Git リポジトリのプライベートな保存と管理を可能にするバージョン制御サービスです。CodeCommit により、お客様が独自のソース制御システムを管理、またはインフラストラクチャのスケーリングに関して心配する必要はなくなります。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) – AWS CodePipeline は、ソフトウェアのリリースに必要な手順のモデル化、可視化、および自動化に使用できる継続的な配信サービスです。ソフトウェアリリースプロセスのさまざまなステージを素早くモデル化して設定できます。CodePipeline はソフトウェア変更の継続的リリースに必要なステップを自動化します。 + [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナの実行、停止、管理に使用される、高度にスケーラブルで高速のコンテナ管理サービスです。タスクとサービスは、 AWS Fargate で管理されているサーバーレスインフラストラクチャで実行できます。または、インフラストラクチャをより詳細に制御するために、管理する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターでタスクとサービスを実行できます。 + [Docker](https://www.docker.com/) — Dockerを使用すると、開発者は任意のアプリケーションを軽量、ポータブル、自給自足のコンテナとして梱包、出荷、実行する上で役立ちます。 **コード** このパターンのコードは、`cicdstarter.zip` および `starter-code.zip` ファイル (添付) にあります。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK の作業ディレクトリを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ | ### 共有インフラストラクチャの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 共有インフラストラクチャを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ | | AWS CloudFormation スタックを監視します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ | | AWS CloudFormation スタックをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html)2 つの VPC の ID と、両方の VPC のデフォルトセキュリティグループのセキュリティグループ ID が記録されていることを確認します。 | AWS DevOps、クラウドインフラストラクチャ | ### マイクロサービスの CI/CD パイプラインの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マイクロサービスのインフラストラクチャーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html)ディレクトリの `cdk.json` ファイルを使用して、両方のコマンドの値を指定することもできます。 | AWS DevOps、クラウドインフラストラクチャ | | AWS CloudFormation スタックを監視します。 | AWS CloudFormation コンソールを開き、`myservice1-cicd-stack` スタックの進捗状況をモニタリングします。最終的に、ステータスは `CREATE_COMPLETE`* に変わります。* | AWS DevOps、クラウドインフラストラクチャ | | AWS CloudFormation スタックをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | | | パイプラインを使用します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ | | 各マイクロサービスにこのエピックを繰り返します。 | このエピックのタスクを繰り返して、各マイクロサービスの CI/CD パイプラインを作成します。 | AWS DevOps、クラウドインフラストラクチャ | ## 関連リソース + [Python と AWS CDK の併用](https://docs.aws.amazon.com/cdk/latest/guide/work-with-cdk-python.html)  + [AWS CDK Python リファレンス](https://docs.aws.amazon.com/cdk/api/latest/python/index.html) + [AWS CDK を使用して AWS Fargate サービスを作成する](https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.html) ## 追加情報 **`cdk synth`コマンド** ``` cdk synth --context aws_account= --context aws_region= --context vpc_nonprod_id= --context vpc_prod_id= --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id= --context code_commit_s3_bucket_for_code= --context code_commit_s3_object_key_for_code= --context microservice_name= ``` **`cdk deploy `コマンド** ``` cdk deploy --context aws_account= --context aws_region= --context vpc_nonprod_id= --context vpc_prod_id= --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id= --context code_commit_s3_bucket_for_code= --context code_commit_s3_object_key_for_code= --context microservice_name= ``` ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/05ac2cad-408e-433f-8150-0a2b71f63cfd/attachments/attachment.zip)」 # GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする *Ruchika Modi (Amazon Web Services)* ## 概要 このパターンでは、再利用可能な GitHub ワークフローを作成して Dockerfile を構築し、結果のイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュする方法について説明します。このパターンは、Terraform と GitHub Actions を使用して Dockerfile のビルドプロセスを自動化します。これにより、人為的ミスの可能性が最小限に抑えられ、デプロイ時間を大幅に短縮できます。 GitHub リポジトリのメインブランチへの GitHub プッシュアクションにより、リソースのデプロイが開始されます。このワークフローでは、GitHub 組織とリポジトリ名の組み合わせに基づいて一意の Amazon ECR リポジトリが作成されます。その後、Dockerfile イメージが Amazon ECR リポジトリにプッシュされます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + アクティブな GitHub アカウント。 + [GitHub リポジトリ](https://docs.github.com/en/get-started/quickstart/create-a-repo)。 + Terraform バージョン 1 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)こと。 + [Terraform バックエンド](https://developer.hashicorp.com/terraform/language/settings/backends/s3)の Amazon Simple Storage Service (Amazon S3) バケット。 + Terraform の状態ロックと整合性のための [Amazon DynamoDB](https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwjO95K9xqCCAxW-KIMDHfOvD7IYABADGgJzZg&gclid=EAIaIQobChMIzveSvcagggMVviiDAx3zrw-yEAAYASADEgJYWfD_BwE&ohost=www.google.com&cid=CAASJuRoKjv_llGjIU3liZ4T2IRecPqw0dVHSvjZ7bee1lvcc36K_lO_&sig=AOD64_1b294pq65HiFN-T1YxQAuXmRu_hw&adurl&ved=2ahUKEwjhiY29xqCCAxUgzjgGHRu6CAIQqyQoAnoECAkQDQ) テーブル。テーブルには、データ型が `String` の `LockID` という名前のパーティションキーが必要です。これが設定されていない場合、状態ロックは無効になります。 + Terraform の Amazon S3 バックエンドを設定するアクセス許可を持つ AWS Identity and Access Management (IAM) ロール。設定の手順については、[Terraform のドキュメント](https://developer.hashicorp.com/terraform/language/settings/backends/s3#assume-role-configuration)を参照してください。 **制限事項** この再利用可能なコードは、GitHub Actions でのみテストされています。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon ECR リポジトリ + GitHub Actions + Terraform **ターゲットアーキテクチャ** ![\[再利用可能な GitHub ワークフローを作成して Dockerfile を構築し、Amazon ECR にイメージをプッシュするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c39c110e-cbe5-459e-a0aa-de27e884fb10/images/298e0e16-3054-49b7-8695-db510e0df2df.png) この図表は、以下を示すものです: 1. ユーザーが Dockerfile と Terraform テンプレートを GitHub リポジトリに追加します。 2. これらの追加により、GitHub Actions ワークフローが開始されます。 3. ワークフローは、Amazon ECR リポジトリが存在するかどうかをチェックします。既存のものがなければ、GitHub の組織とリポジトリ名に基づいてリポジトリが作成されます。 4. Dockerfile が構築され、Amazon ECR リポジトリにイメージがプッシュされます。 ## ツール **Amazon サービス** + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナレジストリサービスです。 **その他のツール** + [GitHub Actions](https://docs.github.com/en/actions) は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。 + [Terraform](https://developer.hashicorp.com/terraform/intro) は HashiCorp の提供する infrastructure as code (IaC) ツールであり、クラウドおよびオンプレミスインフラストラクチャの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub の [Docker ECR Actions ワークフロー](https://github.com/aws-samples/docker-ecr-actions-workflow)リポジトリで利用できます。 + GitHub Actions を作成すると、Docker ワークフローファイルはこのリポジトリの `/.github/workflows/` フォルダに保存されます。このソリューションのワークフローは [workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) ファイル内にあります。 + `e2e-test` フォルダには、参照およびテスト用のサンプル Dockerfile が用意されています。 ## ベストプラクティス + Dockerfiles を記述するためのベストプラクティスについては、[Docker ドキュメント](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)を参照してください。 + [Amazon ECR の VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)を使用します。VPC エンドポイントには AWS PrivateLink が使用されています。これは、プライベート IP アドレスを介して Amazon ECR API にプライベートにアクセスするためのテクノロジーです。Fargate 起動タイプを使用する Amazon ECS タスクの場合、VPC エンドポイントを利用することで、タスクにパブリック IP アドレスを割り当てることなく、Amazon ECR からプライベートイメージをプルできます。 ## エピック ### OIDC プロバイダーと GitHub リポジトリを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | OpenID Connect を設定します。 | OpenID Connect (OIDC) プロバイダーを作成します。このプロバイダーは、このアクションで使用される IAM ロールの信頼ポリシーで使用します。手順については、GitHub ドキュメントの「[Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。 | AWS 管理者、AWS DevOps、AWS 全般 | | GitHub リポジトリのクローンを作成します。 | GitHub [Docker ECR Actions ワークフロー](https://github.com/aws-samples/docker-ecr-actions-workflow)リポジトリのクローンをローカルフォルダに作成します。
$git clone https://github.com/aws-samples/docker-ecr-actions-workflow
| DevOps エンジニア | ### GitHub の再利用可能なワークフローをカスタマイズし、Docker イメージをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Docker ワークフローを開始するイベントをカスタマイズします。 | このソリューションのワークフローは [workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) 内にあります。このスクリプトは現在、`workflow_dispatch` イベントを受信したときにリソースをデプロイするように設定されています。この設定をカスタマイズするには、イベントを `workflow_call` に変更し、このワークフローを別の親ワークフローから呼び出します。 | DevOps エンジニア | | ワークフローをカスタマイズします。 | [Workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) ファイルは、動的で再利用可能な GitHub ワークフローを作成するように設定されています。このファイルを編集してデフォルト設定をカスタマイズすることもできますが、`workflow_dispatch` イベントを使用してデプロイを手動で開始している場合は、GitHub Actions コンソールからの入力値を渡すこともできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.html) | DevOps エンジニア | | Terraform テンプレートをデプロイします。 | このワークフローにより、設定済みの GitHub イベントに基づいて、Amazon ECR リポジトリを作成する Terraform テンプレートが自動的にデプロイされます。これらのテンプレートは、[Github リポジトリのルート](https://github.com/aws-samples/docker-ecr-actions-workflow/tree/main)にある `.tf` ファイルとして使用できます。 | AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Amazon S3 と DynamoDB を Terraform リモートバックエンドとして設定する際の問題またはエラー。 | [Terraform ドキュメント](https://developer.hashicorp.com/terraform/language/settings/backends/s3)の指示に従って、リモートバックエンド設定のための Amazon S3 および DynamoDB リソースに必要となるアクセス許可を設定します。 | | `workflow_dispatch` イベントでワークフローを実行または開始できない。 | `workflow_dispatch` イベントからデプロイするように設定されたワークフローは、このワークフローがメインブランチでも設定されている場合にのみ機能します。 | ## 関連リソース + [Reusing workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) (GitHub ドキュメント) + [Triggering a workflow](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow) (GitHub ドキュメント) # AWS CodeCommit、AWS CodePipeline、AWS Device Farm を使用して iOS アプリを構築してテストする *Abdullahi Olaoye、Amazon Web Services* ## 概要 このパターンでは、AWS CodePipeline を使用して AWS 上の実際のデバイスで iOS アプリケーションを構築してテストする、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを作成する手順の概要を示しています。このパターンでは、AWS CodeCommit を使用してアプリケーションコードを保存し、Jenkins のオープンソースツールを使用して iOS アプリケーションを構築し、AWS Device Farm を使用して構築したアプリケーションを実際のデバイス上でテストします。これらの 3 つのフェーズは、AWS CodePipeline を使用してパイプラインにまとめてオーケストレーションされます。 このパターンは、AWS DevOps ブログの「[AWS DevOps とモバイルサービスを使用した iOS および iPadOS アプリの構築とテスト](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」の投稿に基づいています。詳細な手順については、このブログ記事を参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Apple 開発者アカウント + ビルドサーバー (macOS) + [Xcode](https://developer.apple.com/xcode/) バージョン 11.3 (ビルドサーバーにインストールしてセットアップ済み) + AWS コマンドラインインターフェイス (AWS CLI) を[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)して[設定済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) + [Git](https://git-scm.com/docs) の基本的な知識 **制限事項** + アプリケーションビルドサーバーは macOS を実行していることが必要です。 + CodePipeline が構築を開始するためにリモートで接続できるように、ビルドサーバーにはパブリック IP アドレスが必要です。 ## アーキテクチャ **ソーステクノロジースタック** + シミュレータを使用するか、物理デバイス上で手動テストを行うオンプレミスの iOS アプリケーション構築プロセス **ターゲットテクノロジースタック** + アプリケーションのソースコードを保存するための AWS CodeCommit リポジトリ　 + Xcode を使用してアプリケーションを構築するための Jenkins サーバー + 実際のデバイスでアプリケーションをテストするための AWS Device Farm デバイスプール **ターゲットアーキテクチャ** ユーザーがソースリポジトリに変更をコミットすると、パイプライン (AWS CodePipeline) はソースリポジトリからコードを取得し、Jenkins ビルドを開始して、アプリケーションコードを Jenkins に渡します。ビルドの完了後、パイプラインはビルドアーティファクトを取得し、AWS Device Farm ジョブを開始してデバイスプールに対してアプリケーションをテストします。 ![\[CI/CD パイプラインは AWS CodePipeline を使用して、実際のデバイスで iOS アプリケーションを構築してテストします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/06fbd82f-4aed-441c-818c-5f89f56af78e/images/0ae3d7b6-b40c-44ef-9580-8c8266c3d841.png) ## ツール + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) はフルマネージド型の継続的デリバリーサービスで、アプリケーションとインフラストラクチャの更新を迅速に、かつ高い信頼性で行うために、パイプラインのリリースを自動化します。CodePipeline はお客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、およびデプロイを自動化します。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、安全な Git ベースのリポジトリをホストする完全マネージド型のソース管理サービスです。これにより、セキュアで拡張性の高いエコシステムで、チームによるコードの共同作業が簡単になります。CodeCommit を使用することにより、独自のソース管理システムを運用したり、そのインフラストラクチャをスケールしたりする必要がなくなります。 + [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) は、テストインフラストラクチャをプロビジョニングして管理しなくても、さまざまなデスクトップブラウザと実際のモバイルデバイスでテストすることで、ウェブアプリやモバイルアプリの品質を向上させることができるアプリケーションテストサービスです。 + [Jenkins](https://www.jenkins.io/) は、デベロッパーがソフトウェアを確実に構築、テスト、デプロイできるようにするオープンソースのオートメーションサーバーです。 ## エピック ### ビルド環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | macOS を実行しているビルドサーバーに Jenkins をインストールします。　 | Jenkins を使用してアプリケーションを構築するので、最初に Jenkins をビルドサーバーにインストールする必要があります。このタスクとそれ以降のタスクの詳細な手順については、このパターンの最後にある「[関連リソース](#build-and-test-ios-apps-with-aws-codecommit-aws-codepipeline-and-aws-device-farm-resources)」セクションで、AWS ブログ投稿「[AWS DevOps とモバイルサービスを使用して、iOS および iPadOS のアプリを構築してテストする](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」とその他のリソースを参照してください。 | DevOps | | Jenkins を設定します。 | 画面上の指示に従って Jenkins を設定します。　 | DevOps | | Jenkins 用の AWS CodePipeline プラグインをインストールします。 | Jenkins が AWS CodePipeline サービスとやり取りできるようにするには、このプラグインを Jenkins サーバーにインストールする必要があります。　 | DevOps | | 自由形式の Jenkins プロジェクトを作成します。 | Jenkins で、自由形式のプロジェクトを作成します。トリガーやその他のビルド設定オプションを指定するようにプロジェクトを設定します。 | DevOps | ### AWS Device Farm を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Device Farm プロジェクトを作成します。 | AWS Device Farm コンソールを開きます。テスト用のプロジェクトとデバイスプールを作成します。手順については、ブログ記事を参照してください。 | 開発者 | ### ソースリポジトリを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CodeCommit リポジトリを作成します。 | ソースコードを保存するリポジトリを作成します。 | DevOps | | アプリケーションコードをリポジトリにコミットします。 | 作成した CodeCommit リポジトにリコネクトします。　 コードをローカルマシンからリポジトリにプッシュします。 | DevOps | ### パイプラインを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CodePipeline でパイプラインを作成します。 | AWS CodePipeline コンソールを使用してパイプラインを作成します。パイプラインは CI/CD プロセスのすべてのフェーズをオーケストレーションします。手順については、AWS ブログ投稿「[AWS DevOps とモバイルサービスを使用して、iOS および iPadOS のアプリを構築してテストする](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」を参照してください。 | DevOps | | パイプラインにテストステージを追加します。 | テストステージを追加して AWS Device Farm と統合するには、パイプラインを編集します。 | DevOps | | パイプラインを開始します。 | パイプラインと CI/CD プロセスを開始するには、**[変更をリリース]** を選択します。 | DevOps | ### アプリケーションテストの結果を表示します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト結果を確認します。 | AWS Device Farm コンソールで、作成したプロジェクトを選択し、テストの結果を確認します。コンソールには、各テストの詳細が表示されます。 | 開発者 | ## 関連リソース **このパターンのステップバイステップの説明** + 「[AWS DevOps とモバイルサービスを使用した iOS および iPadOS アプリの構築とテスト](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」(AWS DevOps ブログ記事) **AWS Device Farm を設定する** + [AWS Device Farm コンソール](https://console.aws.amazon.com/devicefarm) **ソースリポジトリを設定する** + 「[新しい AWS CodeCommit リポジトリの作成](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-repository.html)」 + 「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」 「**パイプラインを設定する**」 + 「[AWS CodePipeline コンソール](https://console.aws.amazon.com/codesuite/codepipeline/home)」 **追加リソース** + 「[AWS CodePipeline ドキュメント](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)」 + 「[AWS CodeCommit ドキュメント](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)」 + 「[AWS Device Farm ドキュメント](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)」 + 「[Jenkins ドキュメント](https://www.jenkins.io/doc/)」 + 「[macOS での Jenkins のインストール](https://www.jenkins.io/download/weekly/macos/)」 + 「[Jenkins 用の AWS CodePipeline プラグイン](https://plugins.jenkins.io/aws-codepipeline/)」 + 「[Xcode のインストール](https://developer.apple.com/xcode/)」 + AWS CLI の [インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)と[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) + 「[Git ドキュメント](https://git-scm.com/docs)」 # Amazon EKS で実行されているアプリケーションの相互 TLS 認証を設定する *Mahendra Revanasiddappa (Amazon Web Services)* ## 概要 証明書ベースの相互 Transport Layer Security (TLS) は、サーバーとクライアント間の双方向ピア認証を提供するオプションの TLS コンポーネントです。相互 TLS では、クライアントはセッションネゴシエーションプロセス中に X.509 証明書を提供する必要があります。サーバーは、この証明書を使用してクライアントを識別し、認証します。 相互 TLS は、モノのインターネット (IoT) アプリケーションの一般的な要件であり、企業間 (B2B) アプリケーションや[オープンバンキング](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/open-banking.html)などの標準に使用できます。 このパターンでは、NGINX Ingress Controller を使用して Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで実行されているアプリケーションの相互 TLS を設定する方法を説明します。イングレスリソースに注釈を付けることで、NGINX イングレスコントローラーのビルトイン相互 TLS 機能を有効にできます。NGINX コントローラーの相互 TLS アノテーションについて詳しくは、Kubernetes ドキュメントの「[クライアント証明書認証](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#client-certificate-authentication)」を参照してください。 **重要** このパターンでは、自己署名証明書を使用します。このパターンはテストクラスターでのみ使用し、本番環境では使用しないことをお勧めします。このパターンを本番環境で使用する場合は、「[AWS Private Certificate Authority (AWS Private CA) (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)」または既存のパブリックキーインフラストラクチャ (PKI) 標準を使用してプライベート証明書を発行できます。 ## 前提条件と制限事項 **前提条件** + アクティブな Amazon Web Services (AWS)アカウント。 + 既存の Amazon EKS クラスター。 + AWS コマンドラインインターフェイス(AWS CLI) バージョン 1.7 以降。macOS、Linux、または Windows にインストールされ、設定されている。 + Amazon EKS クラスターにアクセスするためにインストールして設定した kubectl コマンドラインユーティリティ。詳細については、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。 + アプリケーションをテストするための既存のドメインネームシステム (DNS) 名。 **制限事項** + このパターンでは、自己署名証明書を使用します。このパターンはテストクラスターでのみ使用し、本番環境では使用しないことをお勧めします。 ## アーキテクチャ ![\[Amazon EKS で実行されているアプリケーションの相互 TLS 認証の設定\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ae2761e3-7ed2-4c2a-ba54-a4ddce8a1e7e/images/cefc60f9-2f29-4052-b7ae-df4eb6395e1c.png) テクノロジースタック + Amazon EKS + Amazon Route 53 + kubectl ## ツール + 「[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」は、AWS で Kubernetes を実行する際に役立ち、独自の Kubernetes コントロールプレーンまたはノードをインストールまたは維持する必要はありません。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 + 「[Kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」は、Amazon EKS クラスターを操作するために使用するコマンドラインユーティリティです。 ## エピック ### 自己署名証明書を生成します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CA キーと証明書を生成します。 | 次のコマンドを実行して、証明機関 (CA) キーと証明書を生成します。
openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 356 -nodes -subj '/CN=Test Cert Authority'
| DevOps エンジニア | | サーバーキーと証明書を生成し、CA 証明書で署名します。 | サーバーキーと証明書を生成し、次のコマンドを実行して CA 証明書で署名します。
openssl req -new -newkey rsa:4096 -keyout server.key -out server.csr -nodes -subj '/CN=  ' && openssl x509 -req -sha256 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
`` は、必ず既存のドメイン名に置き換えてください。 | DevOps エンジニア | | クライアントキーと証明書を生成し、CA 証明書で署名します。 | クライアントキーと証明書を生成し、次のコマンドを実行して CA 証明書で署名します。
openssl req -new -newkey rsa:4096 -keyout client.key -out client.csr -nodes -subj '/CN=Test' && openssl x509 -req -sha256 -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt
| DevOps エンジニア | ### NGINX イングレスコントローラーをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS クラスターに NGINX イングレスコントローラーをデプロイします。 | 次のコマンドを使用して、NGINX イングレスコントローラをデプロイします。
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.7.0/deploy/static/provider/aws/deploy.yaml
| DevOps エンジニア | | NGINX Ingress Controller サービスが実行中であることを確認します。 | 以下のコマンドを使用して、NGINX イングレスコントローラサービスが実行されていることをを確認します。
kubectl get svc -n ingress-nginx
サービスアドレスのフィールドに Network Load Balancer のドメイン名が含まれていることを確認してください。 | DevOps エンジニア | ### Amazon EKS クラスターにネームスペースを作成して、相互 TLS をテストします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EKS クラスターにネームスペースを作成します。 | 次のコマンドを実行して、Amazon EKS クラスターに `mtls` という名前の名前空間を作成します。
kubectl create ns mtls
これにより、相互 TLS をテストするためのサンプルアプリケーションがデプロイされます。 | DevOps エンジニア | ### サンプルアプリケーションのデプロイとサービスを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Kubernetes デプロイメントとサービスを mtls 名前空間に作成します。 | `mtls.yaml` という名前のファイルを作成します。ファイルに次のコードを貼り付けます。
kind: Deployment
apiVersion: apps/v1
metadata:
  name: mtls-app
  labels:
    app: mtls
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mtls
  template:
    metadata:
      labels:
        app: mtls
    spec:
      containers:
      - name: mtls-app
        image: hashicorp/http-echo
        args:
          - "-text=mTLS is working"


---

kind: Service
apiVersion: v1
metadata:
  name: mtls-service
spec:
  selector:
    app: mtls
  ports:
    - port: 5678 # Default port for image
次のコマンドを実行して、`mtls` 名前空間に Kubernetes デプロイとサービスを作成します。
kubectl create -f mtls.yaml -n mtls
| DevOps エンジニア | | Kubernetes デプロイが作成されていることを確認します。 | デプロイが作成され、1 つのポッドが使用可能になっていることを確認するには、次のコマンドを実行します。
kubectl get deploy -n mtls
| DevOps エンジニア | | Kubernetes サービスが作成されていることを確認します。 | 次のコマンドを実行して、Kubernetes サービスが作成されたことを確認します。
kubectl get service -n mtls
| DevOps エンジニア | ### mtls 名前空間にシークレットを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | イングレスリソースにシークレットを作成します。 | 以下のコマンドを実行して、前に作成した証明書を使用して NGINX Ingress コントローラーのシークレットを作成します。
kubectl create secret generic mtls-certs --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt -n mtls
シークレットには、サーバーを識別するためのクライアント用のサーバー証明書と、クライアント証明書を検証するためのサーバー用の CA 証明書があります。 | DevOps エンジニア | ### mtls 名前空間に Ingress リソースを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | mtls 名前空間にイングレスリソースを作成します。 | `ingress.yaml` という名前のファイルを作成します。ファイルに次のコードを貼り付けます (`` を既存のドメイン名に置き換えます)。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: mtls/mtls-certs
  name: mtls-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: "*."
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mtls-service
            port:
              number: 5678
  tls:
  - hosts:
    - "*."
    secretName: mtls-certs
次のコマンドを実行して、`mtls` ネームスペースに Ingress リソースを作成します。
kubectl create -f ingress.yaml -n mtls
つまり、NGINX Ingress コントローラーはトラフィックをサンプルアプリケーションにルーティングできます。 | DevOps エンジニア | | Ingress リソースが作成されていることを確認します。 | 次のコマンドを実行して、Ingress リソースが作成されたことを確認します。
kubectl get ing -n mtls
Ingress リソースのアドレスに、NGINX Ingress コントローラー用に作成されたロードバランサーが表示されていることを確認してください。 | DevOps エンジニア | ### ホスト名がロードバランサーを指すように DNS を設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | NGINX Ingress コントローラーのロードバランサーを指す CNAME レコードを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開いて、NGINX イングレスコントローラーのロードバランサーに `mtls.` を指す正規名 (CNAME) レコードを作成します。詳細については、Route 53 ドキュメントの「[Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」を参照してください。 | DevOps エンジニア | ### アプリケーションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 証明書なしで相互 TLS セットアップをテストする。 | 以下のコマンドを実行してください。
curl -k https://mtls.
「400 必要な SSL 証明書は送信されませんでした」というエラー応答が表示されるはずです。 | DevOps エンジニア | | 証明書を使用して相互 TLS セットアップをテストします。 | 以下のコマンドを実行してください。
curl -k https://mtls. --cert client.crt --key client.key
「mTLS は動作しています」という応答が返されるはずです。 | DevOps エンジニア | ## 関連リソース + 「[Amazon Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」 + 「[Amazon EKS の NGINX 入力コントローラーでのNetwork Load Balancer の使用](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/)」 + 「[クライアント証明書認証](https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/)」 # を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation *Ram Kandaswamy (Amazon Web Services)* ## 概要 このパターンでは、 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) テンプレート AWS クラウド を使用して での [Amazon WorkSpaces アプリケーション](https://aws.amazon.com/workspaces/applications/)リソースの作成を自動化するコードサンプルと手順を示します。このパターンは、 CloudFormation スタックを使用して、Image Builder、イメージ、フリートインスタンス、スタックなどの WorkSpaces アプリケーションアプリケーションリソースの作成を自動化する方法を示しています。デスクトップまたはアプリケーション配信モードを使用して、HTML5-compliantのブラウザで WorkSpaces アプリケーションアプリケーションをエンドユーザーにストリーミングできます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + WorkSpaces アプリケーションの利用規約の承諾 + [フリート、スタック](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-stacks-fleets.html)、[Image Builder](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-image-builders.html) などの WorkSpaces アプリケーションリソースに関する基本的な知識 **制限事項** + WorkSpaces アプリケーションインスタンスに関連付けられた [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) ロールは、そのインスタンスの作成後に変更することはできません。 + Image Builder の作成後に WorkSpaces Applications Image Builder インスタンスのプロパティ ([サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics)や[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)など) を変更することはできません。 ## アーキテクチャ 次の図は、 CloudFormation テンプレートを使用して WorkSpaces アプリケーションリソースの作成を自動化する方法を示しています。 ![\[WorkSpaces アプリケーションリソースを自動的に作成するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4f0205f5-5b91-4832-9f0f-2135ae866226/images/cb578939-d9af-4f60-93c9-286881df4c3a.png) この図表は、次のワークフローを示しています: 1. このパターンの[追加情報](#automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation-additional)セクションの YAML コードに基づいて CloudFormation テンプレートを作成します。 1. CloudFormation テンプレートは CloudFormation テストスタックを作成します。 1. (オプション) WorkSpaces アプリケーションを使用して Image Builder インスタンスを作成します。 1. (オプション) カスタムソフトウェアを使用して Windows イメージを作成します。 1. CloudFormation スタックは WorkSpaces Applications フリートインスタンスとスタックを作成します。 1. WorkSpaces アプリケーションリソースを HTML5-compliantのブラウザでエンドユーザーにデプロイします。 ## ツール + [Amazon WorkSpaces Applications](https://docs.aws.amazon.com/appstream2/latest/developerguide/what-is-appstream.html) は、どこからでもデスクトップアプリケーションに瞬時にアクセスできるフルマネージド型のアプリケーションストリーミングサービスです。WorkSpaces Applications は、アプリケーションのホストと実行に必要な AWS リソースを管理し、自動的にスケールし、オンデマンドでユーザーへのアクセスを提供します。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースのモデル化とセットアップ、迅速かつ一貫したプロビジョニング、ライフサイクル全体の管理に役立ちます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。複数の および にまたがるスタックを管理 AWS アカウント およびプロビジョニングできます AWS リージョン。 ## ベストプラクティス + **Image Builder のネットワークアクセスを正しく設定**する – アウトバウンドのみのインターネットアクセスに NAT ゲートウェイを使用して、適切なインターネットアクセスで Virtual Private Cloud (VPC) サブネットで Image Builder を起動します。 イメージを作成する前に、必要なリソース (アプリケーションサーバー、データベース、ライセンスサーバーなど) へのネットワーク接続をテストします。VPC ルートテーブルで、必要なすべてのネットワークリソースへの接続が許可されていることを確認します。詳細については、WorkSpaces アプリケーションドキュメントの[「インターネットアクセス](https://docs.aws.amazon.com/appstream2/latest/developerguide/internet-access.html)」を参照してください。 + フリー**ト容量をサービスクォータに対してプロアクティブにモニタリング**する – WorkSpaces Applications インスタンスタイプとサイズクォータは ごと AWS アカウント、 ごとです AWS リージョン。同じリージョン内に同じインスタンスタイプとサイズを使用するフリートが複数存在する場合、そのリージョン内のすべてのフリートインスタンスの総数は、該当するクォータ以下でなければなりません。詳細については、WorkSpaces [アプリケーションドキュメントの「フリートのトラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting-fleets.html)」を参照してください。 + **フリートデプロイ前に Image Builder テストモードでアプリケーションをテスト**する – イメージを作成してフリートにデプロイする前に、必ず Image Builder テストモードでアプリケーションを検証します。テストモードは、エンドユーザーがフリートインスタンスに対して持つ制限されたアクセス許可をシミュレートします。詳細については、WorkSpaces アプリケーションドキュメントの[「Image Builders のトラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting-image-builder.html#troubleshooting-07)」を参照してください。 ## エピック ### (オプション) WorkSpaces アプリケーションイメージを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カスタムソフトウェアをインストールしてイメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html)Windows AppLocker 機能を使用してイメージをさらにロックダウンすることを検討してください。 | AWS DevOps、クラウドアーキテクト | ### CloudFormation テンプレートをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation テンプレートを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html) | AWS システム管理者、クラウド管理者、クラウドアーキテクト、AWS 全般、AWS 管理者 | | テンプレートを使用して CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html) | アプリ所有者、AWS システム管理者、Windows エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | さまざまな問題 | 詳細については、WorkSpaces アプリケーションドキュメントの[「トラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting.html)」を参照してください。 | ## 関連リソース **リファレンス** + [Amazon WorkSpaces アプリケーションの使用を開始する: サンプルアプリケーションのセットアップ](https://docs.aws.amazon.com/appstream2/latest/developerguide/getting-started.html) + [Amazon WorkSpaces アプリケーションフリートとスタックを作成する](https://docs.aws.amazon.com/appstream2/latest/developerguide/set-up-stacks-fleets.html) **チュートリアルと動画** + [Amazon WorkSpaces アプリケーションユーザーワークフロー](https://www.youtube.com/watch?v=hVGQ87-Uhrc) + [レガシー Windows Forms アプリを Amazon WorkSpaces アプリケーションに移行する方法](https://www.youtube.com/watch?v=CIImtS2iVbg) + [AWS re:Invent 2018: Amazon WorkSpaces アプリケーションでデスクトップアプリケーションを安全に配信する (BAP201)](https://www.youtube.com/watch?v=xNIyc_inOhM) ## 追加情報 次のコードは、WorkSpaces アプリケーションリソースを自動的に作成するために使用できる CloudFormation テンプレートの例です。 ``` AWSTemplateFormatVersion: 2010-09-09 Parameters: SubnetIds: Type: 'List' testSecurityGroup: Type: 'AWS::EC2::SecurityGroup::Id' ImageName: Type: String Resources: AppStreamFleet: Type: 'AWS::AppStream::Fleet' Properties: ComputeCapacity: DesiredInstances: 5 InstanceType: stream.standard.medium Name: appstream-test-fleet DisconnectTimeoutInSeconds: 1200 FleetType: ON_DEMAND IdleDisconnectTimeoutInSeconds: 1200 ImageName: !Ref ImageName MaxUserDurationInSeconds: 345600 VpcConfig: SecurityGroupIds: - !Ref testSecurityGroup SubnetIds: !Ref SubnetIds AppStreamStack: Type: 'AWS::AppStream::Stack' Properties: Description: AppStream stack for test DisplayName: AppStream test Stack Name: appstream-test-stack StorageConnectors: - ConnectorType: HOMEFOLDERS UserSettings: - Action: CLIPBOARD_COPY_FROM_LOCAL_DEVICE Permission: ENABLED - Action: CLIPBOARD_COPY_TO_LOCAL_DEVICE Permission: ENABLED - Action: FILE_DOWNLOAD Permission: ENABLED - Action: PRINTING_TO_LOCAL_DEVICE Permission: ENABLED AppStreamFleetAssociation: Type: 'AWS::AppStream::StackFleetAssociation' Properties: FleetName: appstream-test-fleet StackName: appstream-test-stack DependsOn: - AppStreamFleet - AppStreamStack ``` # Firelens ログルーターを使用して Amazon ECS 用のカスタムログパーサーを作成する *Amazon Web Services、Varun Sharma* ## 概要 Firelensは、Amazon Elastic Container Service (Amazon ECS) と AWS Fargate 用のログルーターです。Firelens を使用して、Amazon ECS から Amazon CloudWatch やその他の転送先 ([Splunk](https://www.splunk.com/) や [Sumo Logic](https://www.sumologic.com/) など) にコンテナログをルーティングできます。Firelens は [Fluentd](https://www.fluentd.org/) または [Fluent Bit](https://fluentbit.io/) をロギングエージェントとして使用し、これにより [Amazon ECS タスク定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)を使用してログをルーティングできます。 ログをソースレベルで解析することを選択することで、ロギングデータを分析し、クエリを実行して、運用上の問題に効率的かつ効果的に対応できます。アプリケーションが異なればロギングパターンも異なるため、ログを構造化して最終転送先での検索を容易にするカスタムパーサーを使用する必要があります。 このパターンでは、カスタムパーサーを備えた Firelens ログルーターを使用して、Amazon ECS で実行されているサンプル Spring Boot アプリケーションから CloudWatch にログをプッシュします。その後、Amazon CloudWatch Logs Insights を使用して、カスタムパーサーによって生成されたカスタムフィールドに基づいてログをフィルタリングできます。 ## 前提条件と制限事項 **前提条件** + アクティブな Amazon Web Services (AWS)アカウント。 + ユーザーのローカルマシンにインストールされ、構成された AWS コマンドラインインターフェイス (AWS CLI)。 + コンピュータにインストールされて構成されている Docker。 + Amazon Elastic Container Registry (Amazon ECR) にある既存の Spring Boot ベースのコンテナ化アプリケーション。  ## アーキテクチャ ![\[Firelens ログルーターを使用して、Amazon ECS で実行されているアプリケーションから CloudWatch にログをプッシュします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e82b4992-c4e0-4af5-b87e-cb0b1c1ed8c9/images/ef60e087-965a-40e9-9f80-35edbda2befe.png) テクノロジースタック + CloudWatch + Amazon ECR + Amazon ECS + Fargate + Docker + Fluent Bit ## ツール + [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) – Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えた AWS マネージドコンテナイメージレジストリサービスです。 + [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナの実行、停止、管理を簡単に行うことのできる、高度にスケーラブルで高速なコンテナ管理サービスです。 + [ Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) - IAM は、AWS サービスへのアクセスをセキュアに制御するためのウェブサービスです。 + [ CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) – AWS コマンドラインインターフェイス (AWS CLI) は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + [Docker](https://www.docker.com/) — Docker は、アプリケーションの開発、出荷、実行のためのオープンプラットフォームです。 **Code** このパターンには以下のファイルが添付されています。 + `customFluentBit.zip` – カスタムの解析と構成を追加するためのファイルが含まれています。 + `firelens_policy.json` – IAM ポリシーを作成するためのポリシードキュメントが含まれます。 + `Task.json` – Amazon ECS のサンプルタスク定義が含まれています。 ## エピック ### カスタム Fluent Bit イメージの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリを作成します。 | AWS マネジメントコンソールにサインインし、Amazon ECR コンソールを開いて、`fluentbit_custom` というリポジトリを作成します。これに関する詳細については、Amazon ECR のドキュメントの「[リポジトリを作成する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」を参照してください。 | システム管理者、開発者 | | customFluentBit.zip パッケージを解凍する。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | | | カスタム Docker イメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html)詳細については、Amazon ECR のドキュメントの「[Docker イメージの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」を参照してください。  | システム管理者、開発者 | ### Amazon ECS クラスターの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECS クラスターを作成します。 | Amazon ECS クラスターを作成するには、Amazon ECS ドキュメントの「[クラスターの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)」の「*ネットワーク専用テンプレート*」セクションの指示に従います。Amazon ECS クラスター用の新しい仮想プライベートクラウド (VPC) を作成する場合は、必ず、**[VPC の作成]** を選択してください。 | システム管理者、開発者 | ### Amazon ECS タスクを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECS タスク実行 IAM ロールを設定します。 | `AmazonECSTaskExecutionRolePolicy` マネージドポリシーを使用して Amazon ECS タスク実行 IAM ロールを作成します。これに関する詳細については、Amazon ECS デベロッパーガイド の 「[Amazon ECS タスク実行 IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html)」 を参照してください。IAM ロールの Amazon リソースネーム (ARN) は必ず記録してください。 | システム管理者、開発者 | | IAM ポリシーを Amazon ECS タスク実行 IAM ロールに添付する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | システム管理者、開発者 | | Amazon ECS タスク定義のセットアップ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html)これに関する詳細については、Amazon ECS ドキュメントの「[タスク定義の作成」](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)」を参照してください。 | システム管理者、開発者 | ### Amazon ECS タスクを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECS タスクを実行します。 | Amazon ECS コンソールで [**クラスター**] を選択し、先に作成したクラスターを選択して、スタンドアロンタスクを実行します。これに関する詳細については、Amazon ECS ドキュメントの「[スタンドアロンタスクの実行](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_run_task.html)」を参照してください。 | システム管理者、開発者 | ### CloudWatch のログを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ログを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | システム管理者、開発者 | ## 関連リソース + [Amazon ECS のドッカーの基本](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html)  + [AWS Fargate 上の Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)  + [基本的なサービスパラメーターの構成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/basic-service-params.html)  ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/e82b4992-c4e0-4af5-b87e-cb0b1c1ed8c9/attachments/attachment.zip)」 # GitHub Actions と Terragrunt を使用した API 駆動型リソースオーケストレーションフレームワークの作成 *Amazon Web Services、Tamilselvan P、Abhigyan Dandriyal、Sandeep Gawande、および Akash Kumar* ## 概要 このパターンでは、GitHub Actions ワークフローを活用して、標準化された JSON ペイロードによるリソースのプロビジョニングを自動化するため、手動設定が不要になります。この自動化されたパイプラインは、デプロイライフサイクル全体を管理し、カスタム UI コンポーネントから ServiceNow まで、さまざまなフロントエンドシステムとスムーズに統合できます。このソリューションの柔軟性により、ユーザーは標準化されたプロセスを維持しながら、推奨されるインターフェイスを介してシステムとやり取りできます。 パイプラインアーキテクチャは設定可能で、さまざまな組織要件を満たすように調整できます。実装例では、Amazon Virtual Private Cloud (Amazon VPC) と Amazon Simple Storage Service (Amazon S3) のプロビジョニングに焦点を当てています。このパターンは、組織にまたがる要望を標準化し、一貫した統合ポイントを提供することで、一般的なクラウドリソース管理の課題に効果的に対処します。このアプローチにより、チームは標準化を確保しながらリソースを簡単に要求および管理することができます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + 設定されたリポジトリにアクセスできるアクティブな GitHub アカウント **制限事項** + 新しいリソースでは、リポジトリ設定に `terragrunt.hcl` ファイルを手動で追加する必要があります。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ 次の図は、このパターンのコンポーネントとワークフローを示しています。 ![\[GitHub Actions と Terraform を使用してリソースのプロビジョニングを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bff5d70e-e8f1-454a-94bc-60e8cc16e69f/images/d4a768c8-4e11-493c-85ed-f4bf7e76ce60.png) アーキテクチャ図は次のアクションを示しています。 1. ユーザーは JSON ペイロードを GitHub Actions に送信することで、自動化のパイプラインを実行できます。 1. GitHub Actions パイプラインは、ペイロードの仕様に基づいて、Terragrunt リポジトリと Terraform リポジトリから必要なリソースコードを取得します。 1. パイプラインは、指定された AWS アカウント ID を使用して適切な AWS Identity and Access Management (IAM) ロールを引き受けます。次に、パイプラインはリソースをターゲットにデプロイ AWS アカウント し、アカウント固有の Amazon S3 バケットと Amazon DynamoDB テーブルを使用して Terraform 状態を管理します。 各 AWS アカウント には、セキュアアクセス用の IAM ロール、Terraform ステートストレージ用の Amazon S3 バケット、およびステートロック用の DynamoDB テーブルが含まれています。この設計により、 AWS アカウント全体で制御された自動リソースデプロイが可能になります。デプロイプロセスは、各アカウントの専用の Amazon S3 バケットと IAM ロールを通じて、適切な状態管理とアクセスコントロールを維持します。 ## ツール **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 リソースへのアクセスを安全に管理するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [GitHub アクション](https://docs.github.com/en/actions)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、ビルド、テスト、デプロイパイプラインを自動化できます。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [Terragrunt](https://terragrunt.gruntwork.io/docs/getting-started/overview/) は、OpenTofu と Terraform の両方の機能を拡張するオーケストレーションツールです。一般的なインフラストラクチャパターンをどのように適用するかを管理し、大規模なインフラストラクチャ資産のスケーリングと維持を容易にします。 **コードリポジトリ** このパターンのコードは、GitHub 内の [sample-aws-orchestration-pipeline-terraform](https://github.com/aws-samples/sample-aws-orchestration-pipeline-terraform) リポジトリで入手可能です。 ## ベストプラクティス + GitHub リポジトリシークレットを使用して AWS 認証情報と機密データを保存し、安全なアクセスを実現します。 + GitHub Actions の OpenID Connect (OIDC) プロバイダーを設定して IAM ロールを引き受け、静的認証情報を回避します。 + 最小特権の原則に従い、タスク実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### リポジトリの作成と設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリを初期化します。 | GitHub リポジトリを初期化するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア | | IAM ロールとアクセス許可を設定します。 | IAM ロールとアクセス許可を設定するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア | | GitHub シークレットおよび変数を設定します。 | GitHub リポジトリでリポジトリシークレットと変数を設定する方法については、GitHub ドキュメントの「[Creating configuration variables for a repository](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#creating-configuration-variables-for-a-repository)」を参照してください。次の変数を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア | | リポジトリ構造を作成します。 | リポジトリ構造を作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア | ### パイプラインをトリガーし、結果を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | curl を使用してパイプラインを実行します。 | [curl](https://curl.se/) を使用してパイプラインを実行するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html)パイプライン実行プロセスの詳細については、「[追加情報](#create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt-additional)」を参照してください。 | DevOps エンジニア | | パイプライン実行結果の検証 | 結果を検証するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html)また、`terragrunt.hcl` ファイルと同じリソース内にあるリポジトリで作成された `output.json` ファイルを使用して、作成されたリソースを相互確認することもできます。 | DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クリーンアップリクエストを送信します。 | 不要になったリソースを削除するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア | ## 関連リソース **AWS ブログ** + [IAM ロールを使用して GitHub Actions を のアクションに接続する AWS](https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/) **AWS のサービス ドキュメント** + [IAM ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) + [Amazon CloudWatch Logs を使用した CloudTrail ログファイルのモニタリング](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html) + [Amazon S3 のセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) **GitHub リソース** + [Create a repository dispatch event](https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event) + [ウェブフックの作成](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks#payload) + [GitHub 上のアクセス権限](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github) + [Organization のセキュリティ設定の管理](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization) + [Security checks in the CI/CD pipeline](https://github.com/marketplace/actions/checkov-github-action) + [2 要素認証を設定する](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) ## 追加情報 **パイプライン実行プロセス** パイプライン実行の手順を次に示します。 1. **JSON ペイロード形式を検証する** – 受信 JSON 設定が適切に構造化され、すべての必須パラメータが含まれていることを確認します 1. **指定された IAM ロールを引き受ける** - AWS オペレーションに必要な IAM ロールを認証して引き受けます 1. **必要な Terraform および Terragrunt コードをダウンロードする** – 指定されたバージョンのリソースコードと依存関係を取得します 1. **リソースデプロイを実行する** - 設定を適用して、ターゲット環境に AWS リソースをデプロイまたは更新します **VPC 作成に使用されるペイロードのサンプル** 次に示すのは、Terraform バックエンドのステートバケット作成のコード例です。 ``` state_bucket_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate" ``` ``` lock_table_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate-lock" ``` 次に示すのは、Amazon VPC で VPC を作成するためのペイロードの例です。`vpc_cidr` は VPC の [CIDR ブロック](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)仕様を定義します。Terraform ステートバケットは、`terraform` ファイルで定義された変数にマッピングされます。`ref` パラメータには、実行するコードのブランチ名が含まれます。 ``` { "ref": "main", "inputs": { "RequestParameters": { "RequestId": "1111111", "RequestType": "create", "ResourceType": "vpc", "AccountId": "1234567890", "AccountAlias": "account-alias", "RegionId": "us-west-2", "ApplicationName": "myapp", "DivisionName": "division-name", "EnvironmentId": "dev", "Suffix": "poc" }, "ResourceParameters": [ { "VPC": { "vpc_cidr": "10.0.0.0/16" } } ] } } ``` `RequestParameters` は、パイプラインセクションのリクエストステータスを追跡するために使用され、`tfstate` はこの情報に基づいて作成されます。次のパラメータにはメタデータとコントロールに関する情報が含まれます。 + `RequestId` – リクエストの一意の識別子 + `RequestType` – オペレーションのタイプ (作成、更新、または削除) + `ResourceType` – プロビジョニングするリソースのタイプ + `AccountId` – デプロイ AWS アカウント のターゲット + `AccountAlias` – のわかりやすい名前 AWS アカウント + `RegionId` – リソースデプロイ AWS リージョン 用 + `ApplicationName` – アプリケーション名 + `DivisionName` – 組織部門 + `EnvironmentId` – 環境 (dev や prod など) + `Suffix` – リソースの追加識別子 `ResourceParameters` には、Terraform ファイルで定義された変数にマッピングするリソース固有の設定が含まれます。Terraform モジュールに渡す必要があるカスタム変数はすべて、`ResourceParameters` に含める必要があります。Amazon VPC には、`vpc_cidr` パラメータが必須です。 # GitHub Actions を使用して Terraform マネージド AWS インフラストラクチャの自動プルリクエストを作成する *Amazon Web Services、Matt Padgett、Ashish Bhatt、Ashwin Divakaran、Sandip Gangapadhyay、および Prafful Gupta* ## 概要 このパターンでは、複数の Terraform リポジトリ間での変更管理に伴う手動の繰り返し作業を排除するように設計された自動化ユーティリティについて説明します。多くの組織は、Terraform リポジトリを使用して Infrastructure as Code (IaC) を管理しています。多くの場合、数百の個別のリポジトリがさまざまな環境、サービス、チームを表しています。これらのリポジトリを大規模に管理することは、運用上の重要な課題となります。パラメータの更新、モジュールバージョンのアップグレード、設定変更の適用などの日常的なタスクでは、多くの場合、多くのリポジトリに 1 日に何度もプルリクエスト (PR) を作成および管理する必要があります。 単純な変更であっても、この繰り返しで手動のプロセスには時間がかかり、エラーが発生しやすくなります。エンジニアは、すべてのターゲットリポジトリに同じ変更を一貫して適用し、意味のある PR タイトルと説明を作成する必要があります。さらに、問題追跡リファレンスを取得または含めるために、Jira などの外部ツールとやり取りする必要がたびたび生じます。これらのタスクは、必要ではあるものの、貴重なエンジニアリング時間を消費し、全体的な効率を低下させるような、差別化にならない重労働です。このワークフローを自動化しないと、衝突が発生し、引き渡しが遅くなり、大規模な Terraform インフラストラクチャの維持を担当するチームの認知負担が増大します。 **ソリューションの概要** この課題に対処するために、このパターンでは完全に設定駆動型のユーティリティを提供します。これにより、ユーザーは構造化された設定ファイルで必要な変更を定義できます。このファイルでは、明確に定義されたスキーマを使用して、ターゲットリポジトリ、モジュール、パラメータ、および値を指定できます。 設定が済むと、ユーティリティは次の自動ステップを実行します。 1. **ユーザー定義の設定を読み取り**、変更の範囲と性質を決定する 1. 各ターゲットリポジトリに、必要な更新が適用された**新しいブランチを作成**する 1. 変更ごとに **PR を生成**し、すべてのリポジトリ間で整合性を確保する 1. **Slack 通知を送信**して (オプション)、作成された PR へのリンクと共に関係者に警告する これらの繰り返しのタスクを自動化することにより、このユーティリティは大規模なインフラストラクチャ更新の管理に伴う時間、労力、リスクを大幅に削減します。その結果、チームは、変更が一貫して適用されて、すべてのリポジトリで追跡できることを容易に確認できると同時に、より価値の高いエンジニアリング作業に集中できます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + Python バージョン 3.8 以降。 + GitHub の個人用アクセストークン (PAT)。詳細は、GitHub ドキュメントの「[Creating a personal access token (classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)」を参照してください。 + GitHub PAT はターゲットリポジトリにアクセスできるため、ユーティリティはブランチの作成やプルリクエストなどのオペレーションを実行できます。詳細については、このパターンの GitHub [コードリポジトリ](https://github.com/aws-samples/sample-terraform-pr-automation-utility?tab=readme-ov-file#repository-access-verification)を参照してください。 **制限事項** + **設定の複雑さ**が主な課題です。オートメーションの有効性は、設定ファイルの機能によって制約されます。システムは標準の変更を効率的に処理しますが、複雑なインフラストラクチャの変更には手動による介入が必要になる場合があり、特定のまれな状況は自動処理の範囲外のままです。 + **セキュリティとアクセス**は、特に GitHub アクセストークンと API レート制限を管理する上で重要な検討事項です。組織は、自動化の必要性と安全な認証情報の保管と管理を慎重に釣り合いをとり、運用効率を維持すると同時に、適切なアクセスコントロールを確保する必要があります。 + 自動システムにはビジネス論理と環境固有の要件を検証する機能が限られているため、**検証制約**には別の重要な制限があります。自動検証ではすべての文脈の微妙な差異とビジネスルールを完全に把握できないため、複雑な依存関係とサービス間のやり取りには多くの場合、人による監視が必要です。 + 大規模なインフラストラクチャの変更に対処していると、**スケールとパフォーマンス**の問題が発生します。システムは、多数のリポジトリを同時に管理しながら GitHub API の制限内で動作する必要があります。広範なインフラストラクチャにわたるリソース集約型のオペレーションは、慎重な管理を必要とするパフォーマンスのボトルネックを引き起こす可能性があります。 + **統合境界**は、主に GitHub や Slack などの特定のツールで動作するように設計されているため、システムの柔軟性を制限します。さまざまなツールを使用する組織にはカスタムソリューションが必要になる場合があり、このパターンのワークフローカスタマイズオプションはサポート対象の統合ポイントに制限されます。 ## アーキテクチャ 次の図は、このソルーションのワークフローとコンポーネントを示しています。 ![\[GitHub Actions を使用して自動プルリクエストを作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e211359a-03b1-4e69-b152-eb7c09bdb01a/images/6cee0660-5b44-4abe-970c-c0a3c830a9aa.png) ワークフローの主なステップは、以下のとおりです。 1. デベロッパーは Terraform リポジトリを指定して GitHub Actions の実行を開始します。 1. 自動化ユーティリティは、定義された設定を読み取ります。 1. 自動化ユーティリティは、提供された Terraform リポジトリも取得します。 1. 自動化ユーティリティは新しいブランチを作成し、Terraform テンプレートをローカルで更新します。 1. 自動化ユーティリティは、新しいブランチをリポジトリに反映し、新しい PR を作成します。 1. 自動化ユーティリティは、PR リンクを含む Slack 通知を使用してデベロッパーに通知し、Terraform テンプレートを AWS クラウド デプロイできるようにします。 ## ツール + [GitHub](https://docs.github.com/) は、デベロッパーがコードの作成、保存、管理、共有に使用できるデベロッパー用プラットフォームです。 + [GitHub Actions](https://docs.github.com/en/actions) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。 + [HashiCorp Terraform](https://www.terraform.io/) は、Infrastructure as Code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + Salesforce の製品である [Slack](https://slack.com/help/articles/115004071768-What-is-Slack-) は、チャットとビデオでの共同作業、ノーコードでのプロセスの自動化、情報共有が可能な、AI を活用した対話型プラットフォームです。 **コードリポジトリ** このパターンのコードは、GitHub の [Automated Terraform Infrastructure Update Workflow using GitHub Actions](https://github.com/aws-samples/sample-terraform-pr-automation-utility?tab=readme-ov-file) リポジトリで入手可能です。 ## ベストプラクティス + 実装を成功させるためには、効果的な**変更管理**が不可欠です。組織は、大規模な変更に対して段階的な導入戦略を採用する必要があります。一貫したブランチ命名規則と PR の記述を維持し、すべての変更を包括的に文書化することを確実にします。 + **セキュリティコントロール**は、最小特権のアクセス原則と安全な認証情報管理に焦点を当てて、厳格に実装する必要があります。ブランチ保護ルールを有効にして、不正な変更を防止します。システムの整合性を維持するために、定期的にセキュリティ監査を実施します。 + 堅牢な**テストプロトコル**には、継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインでの自動化した `terraform plan` の実行を含める必要があります。プロトコルには、コミット前検証チェックと重要な変更に特化したレビュー環境も含める必要があります。この多層テストアプローチは、問題を早期に発見し、インフラストラクチャの安定性を確保するのに役立ちます。 + **モニタリング戦略**には、包括的な警告メカニズム、詳細な成功/失敗メトリックの追跡、および失敗したオペレーションの自動再試行メカニズムを含める必要があります。この戦略は、運用の可視性を確保し、発生した問題への迅速な対応を可能にします。 + **設定標準**では、すべての設定のバージョン管理を重視し、再利用性とスケーラビリティのためにモジュール性を維持する必要があります。スキーマと事例の明確なドキュメントは、チームが自動化システムを効果的に理解し、使用するのに役立ちます。 ## エピック ### インストールとセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリを設定します。 | リポジトリのクローンを作成するには、次のコマンドを実行します。
# Clone the automation tool repository
git clone https://github.com/aws-samples/sample-terraform-pr-automation-utility
cd sample-terraform-pr-automation-utility

# Copy example configuration
cp config.example.yaml config.yaml
| AWS DevOps | | 依存関係をインストールします。 | 次のコマンドを実行して、Python の依存関係をインストールし、検証します。
# Install Python dependencies
pip3 install -r requirements.txt

# Verify installation
python3 -c "import github; import hcl2; import yaml; import requests; print('All packages installed successfully')"
| AWS DevOps | | GitHub トークンを設定します。 | GitHub トークンを設定し、それが機能することを確認するには、次のコマンドを実行します。
# Set GitHub token environment variable
export GITHUB_TOKEN="your_github_token_here"

# Verify token works
curl -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/user
| AWS DevOps | ### Terraform を変更する設定ファイルのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `config.yaml` ファイルを設定します。 | ターゲットリポジトリと必要な変更を定義するには、次のように `config.yam`l ファイルを編集します。
repositories:
  - owner: "your-org"
    repo: "your-terraform-repo"
    files:
      - path: "variables.tf"
        changes:
          variables:
            - app_version:
                default:
                  update:
                    - from: ["1.0.0"]
                      to: "1.1.0"

settings:
  pr_title_template: "Infrastructure Update - {{timestamp}}"
  slack:
    username: "Terraform Bot"
    icon_emoji: ":terraform:"
    notify_on_success: true
    notify_on_error: true
    notify_batch_summary: true
| AWS DevOps | ### テストと検証 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 事前テストを実行します。 | 本番用リポジトリで実行する前に、必ず設定をテストしてください。次のコマンドを使用します。
# 1. Test configuration syntax
python3 -c "from main import get_config_content; get_config_content()"

# 2. Run in dry-run mode first
DRY_RUN=true python3 main.py

# 3. Test with minimal configuration
# Use a simple config.yaml with just one repository and one change
| AWS DevOps | | リポジトリへのアクセスを確認します。 | GitHub トークンがリポジトリにアクセスできることを確認するには、次のコマンドを実行します。
# Test GitHub token access
curl -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/owner/repo-name

# Should return repository information, not 404
| AWS DevOps | ### 自動化ユーティリティの実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub Actions UI を使用して自動化ユーティリティを実行します。 | GitHub Actions UI を使用して自動化ユーティリティを実行するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-automated-pull-requests-for-terraform-managed-aws-infrastructure.html) | AWS DevOps | | (代替) コマンドラインから自動化ユーティリティを実行します。 | 必要に応じて、GitHub Actions UI ではなく、コマンドラインから自動化ユーティリティを実行できます。以下のコマンドを使用します。
# Run actual automation
python3 main.py
| AWS DevOps | ### PR と変更を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 作成された PR と変更を確認します。 | GitHub ワークフロー実行の結果をモニタリングするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-automated-pull-requests-for-terraform-managed-aws-infrastructure.html) | AWS DevOps | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | (オプション) PR をクリーンアップします。 | 中止された、もしくは不要な PR を閉じます。 | AWS DevOps | ## 関連リソース **AWS 規範ガイダンス** + [の IaC ツールとしての Terraform の使用 AWS クラウド](https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/terraform.html) **GitHub ドキュメント** + [pull requests について](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) + [個人用アクセストークンを管理する](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) + [GitHub Actions を理解する](https://docs.github.com/en/actions/get-started/understand-github-actions) + [GitHub Actions のクイックスタート](https://docs.github.com/en/actions/get-started/quickstart) # Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成 *Amazon Web Services、Aromal Raj Jayarajan、Vijesh Vijayakumaran Nair、MAHESH RAGHUNANDANAN、Amarnath Reddy* ## 概要 このパターンは、AWS 開発者ツールを使用して Java および Python プロジェクトの動的継続的インテグレーション (CI) パイプラインを自動的に作成する方法を示しています。 テクノロジースタックが多様化し、開発活動が増えるにつれて、組織全体で一貫性のある CI パイプラインを作成して維持することが難しくなる可能性があります。AWS Step Functions のプロセスを自動化することで、CI パイプラインの使用法とアプローチに一貫性を持たせることができます。 動的 CI パイプラインの作成を自動化するために、このパターンでは以下の変数入力を使用します。 + プログラミング言語 (Java または Python のみ) + パイプライン名 + 必要なパイプラインステージ **注記** Step Functions は、複数の AWS サービスを使用してパイプラインの作成をオーケストレーションします。このソリューションで使用されている AWS サービスの詳細については、このパターンの「**ツール**」セクションを参照してください。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + このソリューションがデプロイされている同じ AWS リージョンにある Amazon S3 バケット + このソリューションに必要なリソースを作成するために必要な AWS CloudFormation アクセス許可を持つ AWS Identity and Access Management (IAM) 「[プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)」 **制限事項** + このパターンは Java プロジェクトと Python プロジェクトのみをサポートします。 + このパターンでプロビジョニングされる IAM ロールは、最小特権の原則に従います。IAM ロールの権限は、CI パイプラインが作成する必要のある特定のリソースに基づいて更新する必要があります。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS CloudFormation + AWS CodeBuild + AWS CodeCommit + AWS CodePipeline + IAM + Amazon Simple Storage Service (Amazon S3) + AWS Systems Manager + AWS Step Functions + AWS Lambda + Amazon DynamoDB **ターゲットアーキテクチャ** 次の図は、AWS 開発者ツールを使用して Java および Python プロジェクトの動的 CI パイプラインを自動的に作成するワークフローの例を示しています。 ![\[AWS ツールを使用して Java および Python プロジェクトの動的 CI パイプラインを自動的に作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bef2ccb8-68b3-4c0f-9ee7-4b93e9422d9c/images/b5ed003f-cf16-4130-8bfb-2bc2cb9a0d33.png) この図表は、次のワークフローを示しています: 1. AWS ユーザーは CI パイプラインを作成するための入力パラメータを JSON 形式で提供します。この入力により、AWS 開発者ツールを使用して CI パイプラインを作成する Step Functions ワークフロー (*ステートマシン*) が開始されます。 1. Lambda 関数は Amazon S3 バケットに保存されている「**インプット-レファレンス**」という名前のフォルダを読み取り、「**buildspec.yml**」ファイルを生成します。この生成されたファイルは CI パイプラインのステージを定義し、パラメータ参照を格納しているのと同じ Amazon S3 バケットに保存されます。 1. Step Functions は CI パイプライン作成ワークフローの依存関係に変更がないか確認し、必要に応じて依存関係スタックを更新します。 1. Step Functions は、CodeCommit リポジトリ、CodeBuild プロジェクト、CodePipeline パイプラインを含む CI パイプラインリソースを CloudFormation スタックに作成します。 1. CloudFormation スタックは、選択したテクノロジースタック (Java または Python) のサンプルソースコードと 「**buildspec.yml**」ファイルを CodeCommit リポジトリにコピーします。 1. CI パイプラインランタイムの詳細は DynamoDB テーブルに保存されます。 **自動化とスケール** + このパターンは 1 つの開発環境でのみ使用できます。複数の開発環境で使用するには、設定の変更が必要です。 + 複数の CloudFormation スタックのサポートを追加するには、追加の CloudFormation テンプレートを作成できます。詳細については、CloudFormation ドキュメントの「[AWS CloudFormation 入門](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)」を参照してください。 ## ツール **ツール** + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [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 CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + 「[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) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、設定データ管理とシークレット管理用の安全な階層型ストレージを提供します。 **Code** このパターンのコードは、GitHub 内の「[automated-ci-pipeline-creation](https://github.com/aws-samples/automated-ci-pipeline-creation)」リポジトリで利用できます。リポジトリには、このパターンで概説されているターゲットアーキテクチャの作成に必要な CloudFormation テンプレートが含まれています。 ## ベストプラクティス + トークンやパスワードなどの認証情報 (*シークレット*) を CloudFormation テンプレートや Step Functions アクション設定に直接入力しないでください。その場合、情報は DynamoDB ログに表示されます。代わりに、AWS Secrets Manager を使用してシークレットを設定し、保存してください。次に、必要に応じて CloudFormation テンプレートとStep Functions アクション設定内のSecrets Manager に保存されているシークレットを参照します。詳細については、AWS Secrets Manager ユーザーガイドの「[AWS Secrets Manager とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」を参照してください。 + Amazon S3 に保存した CodePipeline アーティファクトのサーバー側の暗号化を設定する 詳細については、CodePipeline ドキュメントの「[CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する](https://docs.aws.amazon.com/codepipeline/latest/userguide/S3-artifact-encryption.html)」を参照してください。 + IAM ロールを設定する際には、最小特権アクセス許可を適用します。詳細については、IAM ドキュメントの「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。 + Amazon S3 バケットがパブリックにアクセスできないことを確認します。詳細については、Amazon S3 ドキュメントの「[S3 バケットのブロックパブリックアクセス設定を行う](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html)」を参照してください。 + Amazon S3 バケットのバージョニングを必ず有効にしてください。詳細については、「[Amazon S3 バケットでのバージョニングの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)」を参照してください。 + IAM ポリシーを設定するときは IAM アクセスアナライザーを使用してください。このツールは安全で機能的なIAMポリシーを作成するのに役立つ実用的な推奨事項を提供します。詳細については、IAM ドキュメントの「[AWS アイデンティティとアクセスマネジメントアクセスアナライザの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。 + 可能な場合は、IAM ポリシーを設定する際に特定のアクセス条件を定義してください。 + モニタリングと監査の目的で Amazon CloudWatch のロギングを有効化します。詳細については、Cloudwatch ドキュメントの「[Amazon CloudWatch Logsとは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」を参照してください。 ## エピック ### AWS の前提条件の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon S3 バケットを作成する。 | Amazon S3 バケットを作成して (または既存のバケットを使用して)、ソリューションに必要な CloudFormation テンプレート、ソースコード、および入力ファイルを保存します。詳細については、Amazon S3 ドキュメントの「[ステップ１：最初の S3 バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html)」を参照してください。Amazon S3 バケットが、ソリューションをデプロイしているリージョンと同じ AWS リージョンに存在する必要があります。 | AWS DevOps | | GitHub リポジトリのクローンを作成します。 | ターミナルウィンドウで次のコマンドを実行して、GitHub 「[自動 CI パイプライン作成](https://github.com/aws-samples/automated-ci-pipeline-creation)」リポジトリをクローンします。
git clone https://github.com/aws-samples/automated-ci-pipeline-creation.git
詳細については、Github ドキュメントの「[リポジトリのクローン](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | AWS DevOps | | クローンした GitHub リポジトリから Amazon S3 バケットにソリューションテンプレートフォルダをアップロードします。 | クローンした「**ソリューション-テンプレート**」フォルダから内容をコピーし、作成した Amazon S3 バケットにアップロードします。詳細については、Amazon S3 ドキュメントの「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。必ず **Solution-Templates** フォルダのコンテンツのみをアップロードしてください。Amazon S3 バケットのルートレベルでのみファイルをアップロードできます。 | AWS DevOps | ### 解決策をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クローンされた GitHub リポジトリ内の template.yml ファイルを使用して、ソリューションをデプロイするための CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)スタックの作成中、スタックは **[スタック]**ページにリストされ、そのステータスが **CREATE\$1IN\$1PROGRESS** と表示されます。このパターンの残りのステップを完了する前に、スタックのステータスが「**作成\$1完了**」に変わるのを必ず待ってください。 | AWS 管理者、AWS DevOps | ### セットアップをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 作成した関数を実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)(JSON 形式) を使用してエクスポートおよびダウンロードするには：
{
  "details": {
    "tech_stack": "Name of the Tech Stack (python/java)",
    "project_name": "Name of the Project that you want to create with",
    "pre_build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
    "build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
    "post_build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
    "reports": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
  }
}
**Java JSON 入力の例**
{
  "details": {
    "tech_stack": "java",
    "project_name": "pipeline-java-pjt",
    "pre_build": "yes",
    "build": "yes",
    "post_build": "yes",
    "reports": "yes"
  }
}
**Python JSON 入力の例**
{
  "details": {
    "tech_stack": "python",
    "project_name": "pipeline-python-pjt",
    "pre_build": "yes",
    "build": "yes",
    "post_build": "yes",
    "reports": "yes"
  }
}
| AWS 管理者、AWS DevOps | | CI パイプラインの CodeCommit リポジトリが作成されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps | | CodeBuild プロジェクトリソースを確認してください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps | | CodePipeline のステージを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps | | CI パイプラインが正常に実行されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps | ### リソースのクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation のリソーススタックを削除します。 | CloudFormation 内の CI パイプラインのリソーススタックを削除します。詳細については、CloudFormationドキュメントの「[AWS CloudFormation でのスタックの削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。**-stack** という名前のスタックは必ず削除してください。 | AWS DevOps | | Amazon S3 とCloudFormation の CI パイプラインの依存関係を削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)**pipeline-creation-dependencies-stack** という名前のスタックは必ず削除してください。 | AWS DevOps | | Amazon S3 バケットを削除します。 | このパターンの「**前提条件の設定**」セクションで作成した Amazon S3 バケットを削除します。このバケットには、このソリューションのテンプレートが保存されています。詳細については、Amazon S3 ドキュメントの「[バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」を参照してください。 | AWS DevOps | ## 関連リソース + 「[Lambda を使用する Step Functions ステートマシンの作成](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-creating-lambda-state-machine.html)」 (「AWS Step Functions 開発者ガイド」) + 「[AWS Step Functions Workflow Studio](https://docs.aws.amazon.com/step-functions/latest/dg/workflow-studio.html)」 (「AWS Step Functions 開発者ガイド」) + [DevOps と AWS](https://aws.amazon.com/devops/) + [AWS CloudFormation の仕組み](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-howdoesitwork.html) (「AWS CloudFormation ドキュメント」) + 「[Complete CI/CD with AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/)」 (AWS ブログ) + 「[IAM および AWS STS クォータ、名前の要件、および文字の制限](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)」 (「IAM ドキュメント」) # Terraform を使用して CloudWatch Synthetics Canary をデプロイする *Amazon Web Services、Dhrubajyoti Mukherjee および Jean-Francois Landreau* ## 概要 顧客の観点からシステムの状態を検証し、顧客が接続できることを確認することは重要です。顧客がエンドポイントを頻繁に呼び出さない場合、これはさらに困難になります。[Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) は、パブリックエンドポイントとプライベートエンドポイントの両方をテストできる Canary の作成をサポートしています。Canary を使用すれば、使用中でなくてもシステムの状態を知ることができます。これらの Canary は Node.js Puppeteer スクリプトまたは Python Selenium スクリプトのどちらかです。 このパターンでは、HashiCorp Terraform を使用してプライベートエンドポイントをテストする Canary をデプロイする方法を説明します。URL が `200-OK` に返されるかどうかをテストする Puppeteer スクリプトが組み込まれています。その後、Terraform スクリプトを、プライベートエンドポイントをデプロイするスクリプトと統合できます。パブリックエンドポイントを監視するようにソリューションを変更することもできます。 ## 前提条件と制限事項 **前提条件** + 仮想プライベートクラウド (VPC) とプライベートサブネットを持つアクティブなAmazon Web Services (AWS) アカウント + プライベートサブネットからアクセスできるエンドポイントの URL + Terraform をインストールしたデプロイメント環境 **制限** 現在のソリューションは、次の CloudWatch Synthetics ランタイムバージョンで動作します。 + syn-nodejs-puppeteer-3.4 + syn-nodejs-puppeteer-3.5 + syn-nodejs-puppeteer-3.6 + syn-nodejs-puppeteer-3.7 新しいランタイムバージョンがリリースされると、現在のソリューションの更新が必要な場合があります。また、セキュリティアップデートに対応できるようにソリューションを変更する必要もあります。 **製品バージョン** + Terraform 1.3.0 ## アーキテクチャ Amazon CloudWatch Synthetics は、CloudWatch、Lambda、および Amazon Simple Storage Service (Amazon S3) をベースにしています。Amazon CloudWatch には、Canary を作成するウィザードと、Canary の実行状況を表示するダッシュボードが用意されています。Lambda 関数はスクリプトを実行します。Amazon S3 は、Canary 実行のログとスクリーンショットを保存します。 このパターンは、ターゲットサブネットにデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを介してプライベートエンドポイントをシミュレートします。Lambda 関数には、プライベートエンドポイントがデプロイされている VPC 内の伸縮自在なネットワークインターフェイスが必要です。 ![\[説明は図に続いて記載します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/73ed0103-ec45-4653-bb29-f402a88f0c64/images/39aaed0f-f259-4f2a-98fb-8e3a340d0b02.png) 図に示す内容は以下のとおりです。 1. Synthetics canary が Canary Lambda 関数を開始します。 1. Canary Lambda 関数が Elastic Network Interface に接続します。 1. Canary Lambda 関数はエンドポイントのステータスを監視します。 1. Synthetics Canary は、実行データを S3 バケットと CloudWatch メトリックスにプッシュします。 1. メトリックスに基づいて CloudWatch アラームが開始されます。 1. CloudWatch アラームが Amazon Simple Notification Service (Amazon SNS) トピックを開始します。 ## ツール **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)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンは VPC エンドポイントとエラスティックネットワークインターフェイスを使用します。 **その他のサービス** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つオープンソースの Infrastructure as Code (IaC) ツールです。このパターンでは、Terraform を使用してインフラストラクチャをデプロイします。 + [Puppeteer](https://pptr.dev/) は Node.js ライブラリです。CloudWatch Synthetics ランタイムは Puppeteer フレームワークを使用しています。 **コード** このソリューションは、GitHub の [cloud watch-synthetics-canary-terraform](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform) リポジトリで利用できます。詳細については、「追加情報」セクションを参照してください。 ## エピック ### プライベート URL を監視するソリューションを実装してください。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライベート URL を監視するための要件を収集する。 | ドメイン、パラメータ、ヘッダーなどの URL 定義をすべて収集します。Amazon S3 や Amazon CloudWatch とプライベートに通信するには、VPC エンドポイントを使用してください。VPC とサブネットがエンドポイントにどのようにアクセスできるかに注意してください。Canary 実行の頻度を考えてみましょう。 | クラウドアーキテクト、ネットワーク管理者 | | プライベート URL を監視するように既存のソリューションを変更する。 | `terraform.tfvars` ファイルの変更:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cloudwatch-synthetics-canaries-by-using-terraform.html) | クラウドアーキテクト | | ソリューションをデプロイして運用する。 | ソリューションを展開するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cloudwatch-synthetics-canaries-by-using-terraform.html) | クラウドアーキテクト、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | プロビジョニングされたリソースの削除が停止する。 | Canary Lambda 関数、対応する elastic network interface、セキュリティグループをこの順序で手動で削除します。 | ## 関連リソース + [模擬モニタリングの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [Monitor API Gateway endpoints with Amazon CloudWatch Synthetics](https://aws.amazon.com/blogs/mt/monitor-api-gateway-endpoints-with-amazon-cloudwatch-synthetics/) (ブログ記事) ## 追加情報 **リポジトリのアーティファクト** リポジトリのアーティファクトは、次の構造を持っています。 ``` . ├── README.md ├── main.tf ├── modules │   ├── canary │   └── canary-infra ├── terraform.tfvars ├── tf.plan └── variable.tf ``` `main.tf` ファイルにはコアモジュールが含まれ、2 つのサブモジュールがデプロイされます。 + `canary-infra` は、Canary に必要なインフラストラクチャをデプロイします。 + `canary` は、Canary をデプロイします。 ソリューションの入力パラメータは `terraform.tfvars` ファイルにあります。次のコード例を使用して 1 つの Canary を作成できます。 ``` module "canary" { source = "./modules/canary" name = var.name runtime_version = var.runtime_version take_screenshot = var.take_screenshot api_hostname = var.api_hostname api_path = var.api_path reports-bucket = module.canary_infra.reports-bucket role = module.canary_infra.role security_group_id = module.canary_infra.security_group_id subnet_ids = var.subnet_ids frequency = var.frequency alert_sns_topic = var.alert_sns_topic } ``` 対応する.var ファイルは次のとおりです。 ``` name = "my-canary" runtime_version = "syn-nodejs-puppeteer-3.7" take_screenshot = false api_hostname = "mydomain.internal" api_path = "/path?param=value" vpc_id = "vpc_id" subnet_ids = ["subnet_id1"] frequency = 5 alert_sns_topic = "arn:aws:sns:eu-central-1:111111111111:yyyyy" ``` **ソリューションのクリーンアップ** 開発環境でこれをテストする場合は、コストの発生を避けるためにソリューションをクリーンアップできます。 1. AWS マネジメントコンソールで、Amazon S3 コンソールに移動します。ソリューションが作成した Amazon S3 バケットを空にします。必要な場合は、必ずデータのバックアップを取ってください。 1. 開発環境の `cloudwatch-synthetics-canary-terraform` ディレクトリから `destroy` コマンドを実行します。 ``` terraform destroy ``` # ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation *Amazon Web Services、Anand Bukkapatnam Tirumala* ## 概要 このパターンは、チャットアプリケーションで Amazon Q Developer を使用して、SonarQube を通じて報告された静的アプリケーションセキュリティテスト (SAST) のスキャン障害の管理を合理化する包括的なソリューションを示しています。この革新的なアプローチは、カスタムアクションと通知を会話型インターフェイスに統合し、開発チーム内での効率的な共同作業と意思決定プロセスを可能にします。 今日のペースの速いソフトウェア開発環境では、SAST スキャン結果を効率的に管理することは、コードの品質とセキュリティを維持する上で不可欠です。しかし、多くの組織は次のような大きな課題に直面しています。 + 非効率的な通知システムによる重大な脆弱性の認識の遅延 + 分断された承認ワークフローによる時間のかかる意思決定プロセス + SAST スキャン障害に対する即時の実用的な対応の欠如 + セキュリティ検出結果に関する断片化されたコミュニケーションとコラボレーション + セキュリティツールに関する、時間がかかり、エラーが発生しやすい手動インフラストラクチャ設定 これらの問題は、多くの場合、セキュリティリスクの増加、リリースの遅延、チームの生産性の低下につながります。これらの課題に効果的に対処するには、SAST の結果管理を合理化し、チームのコラボレーションを強化し、インフラストラクチャの割り当てを自動化できるソリューションが必要です。 このソリューションの主な機能は次のとおりです。 + **カスタマイズされた通知** – リアルタイムの警告と通知はチームチャットチャネルに直接配信されるため、SAST スキャンの脆弱性や障害に対する迅速な認識とアクションが保証されます。 + **会話による承認** – 利害関係者は、チャットインターフェイス内で途切れなく SAST スキャン結果の承認ワークフローを開始および完了できるため、意思決定プロセスが加速されます。 + **カスタムアクション** – チームは、品質ゲートの障害に対する E メールメッセージの自動トリガー、セキュリティ問題への応答性の向上など、SAST スキャンの結果に基づいてカスタムアクションを定義して実行できます。 + **一元化されたコラボレーション** – SAST スキャン関連の議論、決定、アクションはすべて統一されたチャット環境内に保持されるため、チームメンバー間のコラボレーションと知識共有が向上します。 + **Infrastructure as Code (IaC)** – ソリューション全体が AWS CloudFormation テンプレートでラップされ、手動セットアップエラーを減らしながら、より高速で信頼性の高いインフラストラクチャプロビジョニングを可能にします。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + ツールに AWS のサービス リストされている に関連付けられたリソースを作成および管理するためのアクセス許可を持つ AWS Identity and Access Management (IAM) ロール[ツール](#deploy-chatops-solution-to-manage-sast-scan-results-tools)。 + Slack ワークスペース。 + 必要な Slack ワークスペースにプラグインとして追加されたチャットアプリケーションの Amazon Q Developer。詳細については、Slack ドキュメントの「[Slack ワークスペースにアプリを追加する](https://slack.com/intl/en-in/help/articles/202035138-Add-apps-to-your-Slack-workspace)」を参照してください。登録が成功 AWS マネジメントコンソール したら、「」に示すように Slack ワークスペース ID を書き留めます。 + チャットアプリケーションクライアントで設定された Amazon Q Developer。ワークスペース ID は CloudFormation コンソールですぐに入力できます。手順については、「*Amazon Q Developer in chat applications Administrator Guide*」の「[Configure a Slack client](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#slack-client-setup)」を参照してください。 + 承認 E メールメッセージを送信するために Amazon Simple Email Service (Amazon SES) で作成および検証される送信元 E メールアカウント。セットアップ手順については、「*Amazon Simple Email Service Developer Guide*」の「[Creating and verifying email identities](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure)」を参照してください。 + 承認通知を受信するための送信先 E メールアドレス。このアドレスは、共有受信トレイまたは特定のチームの配布グループにすることができます。 + からアクセスできる運用上の SonarQube インスタンス AWS アカウント。詳細については「[SonarQube installation instructions](https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/install-the-server/introduction/)」を参照してください。 + パイプラインを介してプロジェクトをトリガーおよび作成するためのアクセス許可を持つ SonarQube [ユーザートークン](https://docs.sonarsource.com/sonarqube-server/latest/user-guide/managing-tokens/)。 **制限事項** + カスタムアクションボタンの作成は、このソリューションでは手動プロセスです。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[Amazon Q Developer を使用したリリース管理用の自動コード品質保証をデプロイするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/198312ed-e379-49a7-b706-8e79e2142f21/images/a977924c-957e-4f91-99d6-ed790e343ea6.png) この図は、自動コード品質保証ワークフローを示しています。 1. コードの準備とアップロード: + 開発者はコードベースを .zip ファイルに圧縮します。 + 開発者は、指定された Amazon Simple Storage Service (Amazon S3) バケットに手動で .zip ファイルをアップロードします。 1. Amazon S3 イベントトリガーと AWS Step Functions オーケストレーション: + Amazon S3 アップロードイベントは Step Functions ワークフローの実行を開始します。 + Step Functions は、SonarQube を使用して SAST スキャンをオーケストレーションします。 + ワークフローは AWS CodeBuild ジョブのステータスをモニタリングして、次のアクションを決定します。CodeBuild が成功すると (品質ゲート通過)、ワークフローは終了します。CodeBuild が失敗すると、診断のために AWS Lambda 関数が呼び出されます。詳細については、このセクションの後半にある「**AWS Step Functions のロジック**」を参照してください。 1. AWS CodeBuild 実行: + CodeBuild ジョブは、アップロードされたコードベースで SonarQube スキャンを実行します。 + スキャンアーティファクトは、監査と分析のために別の Amazon S3 バケットに保存されます。 1. 障害分析 (Lambda 関数): + CodeBuild が失敗すると、`CheckBuildStatus` Lambda 関数の実行が開始されます。 + CodeBuild が成功すると、プロセスは終了し、それ以上のアクションは必要ありません。 1. Lambda 関数が障害の原因を分析 (品質ゲートの障害またはその他の問題) + `CheckBuildStatus` 関数は、詳細な障害情報を含むカスタムペイロードを作成します。 + `CheckBuildStatus` 関数は、カスタムペイロードを Amazon Simple Notification Service (Amazon SNS) トピックに発行します。 1. 通知システム: + Amazon SNS は、Slack 統合用のチャットアプリケーションでペイロードを Amazon Q Developer に転送します。 1. Slack 統合: + チャットアプリケーションの Amazon Q Developer は、指定された Slack チャンネルに通知を投稿します。 1. 承認プロセス: + 承認者は、Slack 通知で障害の詳細を確認します。 + 承認者は、Slack の **[承認]** ボタンを使用して承認を開始できます。 1. 承認ハンドラー: + 承認 Lambda 関数は、Slack からの承認アクションを処理します。 + 承認関数は、カスタムメッセージを Amazon SES に発行します。 1. 生成されたメッセージ: + 承認関数は、開発者への通知用のカスタムメッセージを生成します。 1. 開発者への通知: + Amazon SES は、次のステップまたは必要なアクションを含む E メールメッセージを開発者に送信します。 このワークフローは、手動コードアップロードと自動品質チェックを組み合わせて、Slack を通じて即座にフィードバックを提供し、必要に応じて人間の介入を可能にし、堅牢で柔軟なコードレビュープロセスを確実にします。 **AWS Step Functions  ** ロジック 前のアーキテクチャ図に示すように、SonarQube の品質ゲート通過が失敗すると、ワークフローは `CheckBuildStatus` Lambda 関数に移ります。`CheckBuildStatus` 関数は、Slack チャンネルで通知をトリガーします。各通知には、次に実行すべきステップに関する情報が含まれています。次に示すのが通知のタイプです。 + **アプリケーションがコードセキュリティスキャンで不合格だった** – アップロードされたコードが SonarQube セキュリティスキャンに合格しなかった場合、ユーザーはこの通知を受け取ります。ユーザーは **[APPROVE]** を選択してビルドを受け入れることができます。しかし、この通知は、潜在的なコードの品質問題とセキュリティリスクに注意するようユーザーに忠告します。通知には、次の詳細が含まれます。 + Next steps: Error: Quality gate status: FAILED – 指定された URL に詳細が表示されます。 + 指定された URL でドキュメントに記載されている脆弱性の優先順位付けをします。 + CodeBuild の詳細は、指定された URL で示される場所にあります。 + **アプリケーションスキャンパイプラインが他の理由で失敗した** – ユーザーは、コードセキュリティスキャンの失敗以外の理由でパイプラインが失敗したときにこの通知を受け取ります。通知には、次の詳細が含まれます。 + 次のステップについては、さらなるトラブルシューティング用のリンク先を参照してください。 Slack チャンネルに表示される通知のスクリーンショットを表示するには、chatops-slack GitHub リポジトリの[アセットフォルダ](https://github.com/aws-samples/chatops-slack/tree/main/assets)に移動します。 次の図は、品質ゲート通過に失敗した後の Step Functions ステップステータスの例を示しています。 ![\[品質ゲート通過に失敗した後の AWS Step Functions ステップステータスのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/198312ed-e379-49a7-b706-8e79e2142f21/images/40b7ebf0-2518-4413-9717-0bfb7559adde.png) ## ツール **AWS のサービス** + [チャットアプリケーションの Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) を使用すると、Amazon Chime、Microsoft Teams、Slack チャットチャネルを使用して、 AWS アプリケーションの運用イベントをモニタリングして対応できます。*サポート終了通知:* 2026 年 2 月 20 日に、 AWS は Amazon Chime サービスのサポートを終了します。2026 年 2 月 20 日以降、Amazon Chime コンソールまたは Amazon Chime アプリケーションリソースにアクセスできなくなります。詳細については、こちらの[ブログ記事](https://aws.amazon.com/blogs/messaging-and-targeting/update-on-support-for-amazon-chime/)をご覧ください。これは [Amazon Chime SDK サービス](https://aws.amazon.com/chime/chime-sdk/)の可用性には影響しません。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。 + [Amazon Simple Email Service (Amazon SES)](https://docs.aws.amazon.com/ses/latest/dg/Welcome.html) は、独自の E メールアドレスとドメインを使用して E メールを送受信するのに役立ちます。 + 「[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 Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数と他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 **その他のツール** + Salesforce の製品である [Slack](https://slack.com/help/articles/115004071768-What-is-Slack-) は、チャットと動画による共同作業を可能にし、ノーコードでプロセスを自動化し、情報共有に対応する AI を活用した会話型プラットフォームです。 + [SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) は、30 を超える言語、フレームワーク、IaC プラットフォームでコーディングの問題を検出するように設計されたオンプレミスの分析ツールです。 **コードリポジトリ** このパターンのコードは [chatops-slack](https://github.com/aws-samples/chatops-slack) GitHub リポジトリから入手可能です。 ## ベストプラクティス + **CloudFormation スタック管理** – CloudFormation スタックの実行中に障害が発生した場合は、障害が発生したスタックを削除することを推奨します。次に、正しいパラメータ値を使用して再作成します。このアプローチは、クリーンなデプロイを支援し、潜在的な競合や一部だけ実装されることを回避するのに役立ちます。 + **共有受信トレイ E メール設定** – `SharedInboxEmail` パラメータを設定するときは、関連するすべての開発者がアクセスできる共通の配布グループを使用します。このアプローチは透明性を促進し、関連するチームメンバーへの重要な通知に役立ちます。 + **本番承認ワークフロー** – 本番環境では、ビルド承認に使用される Slack チャンネルへのアクセスを制限します。指定された承認者のみがこのチャンネルのメンバーである必要があります。この習慣は、明確な責任の連鎖を維持し、重要な変更を承認できるユーザーを制限することでセキュリティを強化します。 + **IAM アクセス権限** – 最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPracticesAndUseCases.html)」を参照してください。 ## エピック ### 初期セットアップを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | このパターンの [chatops-slack](https://github.com/aws-samples/chatops-slack) リポジトリを複製するには、次のコマンドを使用します。`git clone "git@github.com:aws-samples/chatops-slack.git"` | AWS DevOps、ビルドリード、DevOps エンジニア、クラウド管理者 | | Lambda コードを含む .zip ファイルを作成する。 | `CheckBuildStatus` および `ApprovalEmail`機能の AWS Lambda 関数コードの .zip ファイルを作成します。`notification.zip` と `approval.zip` を作成するには、次のコマンドを使用します。
cd chatops-slack/src
chmod -R 775 *
zip -r approval.zip approval
zip -r notification.zip notification
| AWS DevOps、ビルドリード、DevOps エンジニア、クラウド管理者 | ### pre-requisite.yml スタックファイルをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `pre-requisite.yml` スタックファイルを実行する。 | `pre-requisite.yml` CloudFormation スタックファイルは、`app-security.yml` スタックファイルを実行する前に必要な初期リソースをデプロイします。`pre-requisite.yml` ファイルを実行するには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS 管理者、AWS DevOps、ビルドリード、DevOps エンジニア | | .zip ファイルを Amazon S3 バケットにアップロードする。 | 前に作成した `notification.zip` および `approval.zip` ファイルを、`S3LambdaBucket` という名前の Amazon S3 バケットにアップロードします。`app-security.yml` CloudFormation スタックファイルは、`S3LambdaBucket` を使用して Lambda 関数を割り当てます。 | AWS DevOps、ビルドリード、DevOps エンジニア、AWS システム管理者 | ### app-security.yml スタックファイルを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `app-security.yml` スタックファイルを実行する。 | `app-security.yml` スタックファイルは、通知と承認システムの残りのインフラストラクチャをデプロイします。`app-security.yml` ファイルを実行するには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS DevOps、AWS システム管理者、DevOps エンジニア、ビルドリード | | 通知設定をテストする。 | 通知設定をテストするには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html)テストメッセージが正常に配信されると、Slack チャンネルに通知が表示されます。詳細については、「Amazon Q Developer in chat applications Administrator Guide」の[「Test notifications from AWS のサービス to Slack](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#test-notifications-slack)」を参照してください。 ** | AWS DevOps、AWS システム管理者、DevOps エンジニア、ビルドリード | ### 承認フローを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カスタム Lambda アクションを設定する。 | カスタム AWS Lambda アクションを設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS 管理者、AWS DevOps、ビルドリード、DevOps エンジニア、Slack 管理者 | | 承認フローを検証する。 | 承認フローが期待どおりに機能することを検証するには、Slack の **[Approve]** ボタンを選択します。**承認 E メールが正常に送信された**ことを示す確認文字列の通知が、Slackbot からメッセージスレッドに送信されるはずです。 | AWS 管理者、AWS DevOps、DevOps エンジニア、Slack 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Slack の設定ミス | Slack の設定ミスに関連する問題のトラブルシューティングについては、「*Amazon Q Developer in chat applications Administrator Guide*」の「Troubleshooting Amazon Q Developer」を参照してください。 | | 他の理由でのスキャン失敗 | このエラーは、コードビルドタスクが失敗したことを意味します。この問題をトラブルシューティングするには、メッセージ内のリンクで示される場所に移動します。コードビルドタスクの失敗には、次の原因が考えられます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | ## 関連リソース **AWS ドキュメント** + [Configure a Slack client](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#slack-client-setup) + [カスタムアクションの作成](https://docs.aws.amazon.com/chatbot/latest/adminguide/custom-actions.html#creating-custom-actions) + [Creating an email address identity](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure) [procedure](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure) + [チュートリアル: Slack の使用を開始する](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html) **その他のリソース** + [Slack ワークスペースにアプリを追加する](https://slack.com/intl/en-in/help/articles/202035138-Add-apps-to-your-Slack-workspace) (Slack ドキュメント) + [Generating and using tokens](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) (SonarQube ドキュメント) + [Introduction to the server installation](https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/install-the-server/introduction/) (SonarQube ドキュメント) ## 追加情報 このソリューションは、リリース管理の目的における、チャットアプリケーションの Amazon Q Developer のカスタムアクションに重点を置いています。しかし、特定のユースケースに合わせて Lambda コードを変更し、それを活用することで、ソリューションを再利用できます。 **CloudFormation スタックファイルのパラメータ** 次の表は、CloudFormation スタックファイル `pre-requisite.yml` のパラメータとその説明を示しています。 | | | **キー** | **説明** | | --- |--- | | `StackName` | CloudFormation スタックの名前。 | | `S3LambdaBucket` | Lambda コードをアップロードした Amazon S3 バケットの名前。名前はグローバルに一意である必要があります。 | | `SonarToken` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている SonarQube ユーザートークン。 | 次の表は、CloudFormation スタックファイル `app-security.yml` のパラメータとその説明を示しています。 | | | **キー** | **説明** | | --- |--- | | `CKMSKeyArn` | このスタックで作成された IAM ロールと Lambda 関数で使用される AWS KMS key Amazon リソースネーム (ARN)。 | | `CKMSKeyId` | このスタックで作成された Amazon SNS トピックで使用される AWS KMS key ID。 | | `EnvironmentType` | アプリケーションスキャンパイプラインをデプロイするクライアント環境の名前。許可された値のドロップダウンリストから環境名を選択します。 | | `S3LambdaBucket` | `approval.zip` と `notification.zip` ファイルを含む、Amazon S3 バケットの名前。 | | `SESEmail` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている Amazon SES に登録された E メール ID の名前。この ID は送信元の E メールアドレスです。 | | `SharedInboxMail` | スキャン通知の送信先 E メールアドレス。 | | `SlackChannelId` | 通知を送信する Slack チャンネルのチャンネル ID。チャンネル ID を見つけるには、Slack アプリの **[Channel Details]** でチャンネル名を右クリックします。チャンネル ID は下部にあります。 | | `SlackWorkspaceId` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている Slack ワークスペース ID。Slack ワークスペース ID を検索するには、 にサインインし AWS マネジメントコンソール、チャットアプリケーションコンソールで Amazon Q Developer を開き、**設定済みクライアント**、**Slack**、**WorkspaceID** を選択します。 | | `StackName` | CloudFormation スタックの名前。 | | `SonarFileDirectory` | `sonar.project..properties` ファイルを含むディレクトリ。 | | `SonarFileName` | `sonar.project.properties` ファイルの名前。 | | `SourceCodeZip` | `sonar.project.properties` ファイルとソースコードが含まれている .zip ファイルの名前。 | # Terraform を使用して CrewAI フレームワークで Amazon Bedrock にエージェンティックシステムを展開する *Amazon Web Services、Vanitha Dontireddy* ## 概要 このパターンは、[Amazon Bedrock](https://aws.amazon.com/bedrock/?nc1=h_ls) および [Terraform](https://registry.terraform.io/) と統合された [CrewAI](https://www.crewai.com/) フレームワークを使用して、拡張性のあるマルチエージェント AI システムを実装する方法を示しています。このソリューションにより、組織は Infrastructure as Code (IaC) を通じて高度な AI エージェントワークフローを作成、展開、管理できます。このパターンでは、CrewAI マルチエージェントオーケストレーション機能を Amazon Bedrock 基盤モデルと Terraform インフラストラクチャ自動化と組み合わせています。その結果、チームは人間による監視を最小限に抑えながら、複雑なタスクに取り組むためのリリース可能な AI システムを構築できます。このパターンは、エンタープライズ等級のセキュリティ、スケーラビリティ、運用に対する最良の手法を実装しています。 ## 前提条件と制限 **前提条件** + [Amazon Bedrock 基盤モデルにアクセス](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html)するための適切なアクセス許可 AWS アカウント を持つアクティブな + Terraform バージョン 1.5 以降が[インストール済み](https://developer.hashicorp.com/terraform/install) + Python バージョン 3.9 以降[がインストールされている](https://www.python.org/downloads/) + CrewAI フレームワークが[インストール済み](https://docs.crewai.com/installation) **制限事項** + エージェントとのやり取りは、モデルコンテキストウィンドウによって制限されます。 + 大規模なデプロイでは、Terraform ステート管理に関する考慮事項がこのパターンに適用されます。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ このパターンでは、次の相互作用が発生します。 + Amazon Bedrock は、一連の基盤モデル (FM) を通じてエージェントインテリジェンスの基盤を提供します。これにより、高可用性とスケーラビリティを維持しながら、AI エージェントの自然言語処理 (NLP)、論理的思考、意思決定能力を実現します。 + CrewAI フレームワークは、AI エージェントを作成および管理するためのコアオーケストレーションレイヤーとして機能します。Amazon Bedrock と統合しながら、エージェントの通信プロトコル、タスクの委譲、ワークフロー管理を処理します。 + Terraform は、コンピューティングリソース、ネットワーク、セキュリティグループ、 AWS Identity and Access Management (IAM) ロールなどのコードを通じてインフラストラクチャスタック全体を管理します。これにより、環境間で一貫性のある、バージョン管理されたデプロイが保証されます。Terraform デプロイでは、次の機能が作成されます。 + AWS Lambda CrewAI アプリケーションを実行する 関数 + コードとレポート用の Amazon Simple Storage Service (Amazon S3) バケット + 適切なアクセス許可を持つ IAM ロール + Amazon CloudWatch ログ + Amazon EventBridge によってスケジュールされた実行 次の図は、Amazon Bedrock と Terraform を使用して CrewAI マルチエージェントシステムを展開するためのアーキテクチャを示しています。 ![\[Terraform と Amazon Bedrock を使用して CrewAI マルチエージェントシステムを展開するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46069e9-4c38-405f-b0f0-310eabb06b06/images/b3296b17-e388-46ba-8d71-2ec7ce3ed3e0.png) この図表は、次のワークフローを示しています: 1. ユーザーはリポジトリを複製します。 1. ユーザーは コマンドを実行して AWS リソース`terraform apply`をデプロイします。 1. Amazon Bedrock モデル設定には、CrewAI エージェントの設定に使用する基盤モデル (FM) の指定が含まれます。 1. EventBridge ルールが確立され、定義されたスケジュールに従って Lambda 関数の実行が開始されます。 1. (スケジュールまたは手動で) トリガーされると、Lambda 関数は と Amazon Bedrock へのアクセス許可を持つ IAM ロールを初期化 AWS のサービス して引き受けます。 1. CrewAI フレームワークは、YAML ファイルからエージェント設定をロードし、特殊な AI エージェント (*AWS インフラストラクチャセキュリティ監査*クルー) を作成します。Lambda 関数は、これらのエージェントを順次実行して、 AWS リソースをスキャンし、セキュリティの脆弱性を分析し、包括的な監査レポートを生成します。 1. CloudWatch Logs は、365 日間の保持期間とコンプライアンス要件のための AWS Key Management Service (AWS KMS) 暗号化を使用して、Lambda 関数から詳細な実行情報をキャプチャします。ログは、エージェントのアクティビティ、エラー追跡、パフォーマンスメトリックを可視化し、セキュリティ監査プロセスの効果的なモニタリングとトラブルシューティングを可能にします。 1. セキュリティ監査レポートが自動的に生成され、指定された Amazon S3 バケットに保存されます。自動セットアップは、運用上のオーバーヘッドを最小限に抑えながら、セキュリティモニタリングの一貫性を維持するのに役立ちます。 最初のデプロイ後、ワークフローは、手動で介入することなく AWS 、インフラストラクチャの継続的なセキュリティ監査とレポートを提供します。 **AI エージェントの概要** このパターンでは、それぞれに一意のロール、目標、ツールを持つ、複数の AI エージェントを作成します。 + **セキュリティアナリストエージェント**は、 AWS リソース情報を収集して分析します。 + **ペネトレーションテスターエージェント**は、 AWS リソースの脆弱性を特定します。 + **コンプライアンスエキスパートエージェント**は、コンプライアンス標準に照らして設定をチェックします。 + **レポートライターエージェント**は、検出結果を包括的なレポートに編集します。 これらのエージェントは、一連のタスクで共同作業を行い、集合的なスキルを活用してセキュリティ監査を実行し、包括的なレポートを生成します。(この `config/agents.yaml` ファイルは、このクルーでの各エージェントの機能と設定の概要を示しています。) セキュリティ分析処理は、次のアクションで構成されます。 1. セキュリティアナリストエージェントは、次のような AWS リソースについて収集されたデータを調べます。 + Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとセキュリティグループ + Amazon S3 バケットと設定 + IAM ロール、ポリシー、およびアクセス権限 + 仮想プライベートクラウド (VPC) の設定とネットワーク設定 + Amazon RDS データベースとセキュリティ設定 + Lambda 関数と設定 + 監査範囲内 AWS のサービス のその他 1. 侵入テスターエージェントは潜在的な脆弱性を特定します。 1. エージェントは CrewAI フレームワークを通じて共同作業を行い、検出結果を共有します。 レポート生成は、次のアクションで構成されます。 1. レポートライターエージェントは、他のすべてのエージェントの検出結果を編集します。 1. セキュリティの問題は、サービス、重要度、コンプライアンスへの影響の分類で整理されています。 1. 特定された問題ごとに修復のための推奨事項が生成されます。 1. 包括的なセキュリティ監査レポートはマークダウン記法で作成され、指定された Amazon S3 バケットにアップロードされます。履歴レポートは、コンプライアンス追跡とセキュリティ体制の改善のために保持されます。 ログ記録とモニタリングアクティビティには以下が含まれます。 + CloudWatch ログは、実行の詳細とエラーをキャプチャします。 + Lambda 実行メトリックはモニタリングのために記録されます。 **注記** のコード`aws-security-auditor-crew`は、 AWS サンプルコレクションで利用可能な GitHub [3P-Agentic\$1frameworks](https://github.com/aws-samples/3P-Agentic-Frameworks/blob/main/crewai/aws-security-auditor-crew/README.md) リポジトリから取得されます。 **可用性とスケール** 使用可能なエージェントは、4 つ以上のコアエージェントに拡張できます。追加の専門エージェントに合わせてスケールするには、次の新しいエージェントタイプを検討します。 + *脅威インテリジェンススペシャリスト*エージェントは、以下を実行できます。 + 外部の脅威フィードをモニタリングし、内部検出結果と関連付けます + インフラストラクチャに関連する新たな脅威に関する背景を提供します。 + 実環境での悪用に基づいて脆弱性の優先順位付けをする + *コンプライアンスフレームワーク*エージェントは、次のような特定の規制分野に集中できます。 + Payment Card Industry Data Security Standard (PCI DSS) コンプライアンスエージェント + 1996 年の医療保険の携行性と責任に関する法律 (HIPAA) コンプライアンスエージェント + System and Organization Controls 2 (SOC 2) コンプライアンスエージェント + EU 一般データ保護規則 (GDPR) コンプライアンスエージェント 利用可能なエージェントを慎重に拡張することで、このソリューションは大規模な AWS 環境全体でスケーラビリティを維持しながら、より深く、より専門的なセキュリティインサイトを提供できます。実装方法、ツール開発、スケールに関する考慮事項の詳細については、「[追加情報](#deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework-additional)」を参照してください。 ## ツール **AWS のサービス** + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにする完全管理型 AI サービスです。 + [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。このパターンでは、エージェントワークフローのスケジューリングとオーケストレーションに使用されます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰が認証され、誰に使用を許可するかを制御することで、 AWS リソースへのアクセスを安全に管理できます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このパターンでは、エージェントアーティファクトとステート管理用のオブジェクトストレージを提供します。 **その他のツール** + [CrewAI](https://www.crewai.com/open-source) は、マルチエージェント AI システムを構築するためのオープンソースで Python ベースのフレームワークです。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub 「[deploy-crewai-agents-terraform](https://github.com/aws-samples/deploy-crewai-agents-terraform.git)」リポジトリから入手可能です。 ## ベストプラクティス + Amazon S3 バックエンドを Amazon DynamoDB ロックと共に使用して、Terraform の適切な状態管理を実装します。詳細については、*「Terraform AWS プロバイダーを使用するためのベストプラクティス*」の[「バックエンド](https://docs.aws.amazon.com/prescriptive-guidance/latest/terraform-aws-provider-best-practices/backend.html)のベストプラクティス」を参照してください。 + ワークスペースを使用して、開発環境、ステージング環境、本番環境を分離します。 + 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 + CloudWatch ログを使用して詳細なログ記録とモニタリングを有効にします。 + エージェントオペレーションの再試行メカニズムとエラー処理を実装します。 ## エピック ### CrewAI フレームワークを展開する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | ローカルマシンでこのパターンのリポジトリの複製を作成するには、次のコマンドを実行します。
git clone "git@github.com:aws-samples/deploy-crewai-agents-terraform.git"
cd deploy-crewai-agents-terraform
| DevOps エンジニア | | 環境変数を編集します。 | 環境変数を編集するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア | | インフラストラクチャを作成する。 | インフラストラクチャを作成するには、次のコマンドを実行します。
cd terraform
terraform init
terraform plan
実行計画を注意深く確認します。計画された変更が許容できる場合は、次のコマンドを実行します。
terraform apply --auto-approve
| DevOps エンジニア | ### CrewAI エージェントにアクセスする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | エージェントにアクセスする。 | AWS インフラストラクチャセキュリティ監査およびレポートクルーのエージェントは、Lambda 関数としてデプロイされます。エージェントにアクセスするには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア | | (オプション) エージェントの手動実行を設定する。 | エージェントは、毎日のスケジュール (UTC 午前 0 時) で自動的に実行されるように設定されています。ただし、次の手順を使用して手動で実行を開始できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)詳細については、「Lambda ドキュメント」の「[コンソールでの Lambda 関数のテスト](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html)」を参照してください。 | DevOps エンジニア | | デバッグ用のエージェントログにアクセスする。 | CrewAI エージェントは、セキュリティ監査を実行し、Amazon S3 にレポートを保存するために必要なアクセス許可を持つ Lambda 環境で実行されています。出力は、 AWS インフラストラクチャの包括的なセキュリティ分析を提供するマークダウンレポートです。エージェントの動作の詳細なデバッグを支援するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア | | エージェント実行の結果を表示する。 | エージェント実行の結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)レポートは、次のようなタイムスタンプベースのファイル名で保存されます。`security-audit-report-YYYY-MM-DD-HH-MM-SS.md)` | DevOps エンジニア | | エージェントの実行をモニタリングする。 | CloudWatch Logs を使用してエージェントの実行をモニタリングするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア | | エージェントの動作をカスタマイズする。 | エージェントもしくはそのタスクを変更するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)
cd terraform 
terraform apply
| DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 作成したリソースを削除します。 | このパターンによって作成されたすべてのインフラストラクチャを削除するには、次のコマンドを実行します。
terraform plan -destroy
次のコマンドは、このパターンによって作成されたすべてのリソースを完全に削除します。リソースを削除する前にコマンドから確認を求められます。破棄計画は注意して確認してください。計画された削除が許容される場合は、次のコマンドを実行します。
terraform destroy
| DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | エージェントの動作 | この問題の詳細については、Amazon Bedrock ドキュメントの「[Test and troubleshoot agent behavior](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 | | Lambda ネットワークの問題 | これらの問題の詳細については、「Lambda ドキュメント」の「[Lambda でのネットワーク問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 | | IAM アクセス許可 | これらの問題の詳細については、IAM ドキュメントの「[IAM のトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html)」を参照してください。 | ## 関連リソース **AWS ブログ** + 「[Build agentic systems with CrewAI and Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/build-agentic-systems-with-crewai-and-amazon-bedrock/)」 **AWS ドキュメント** + [Amazon Bedrock ドキュメント](https://docs.aws.amazon.com/bedrock/) + [Amazon Bedrock エージェントの仕組み](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html) + [AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) **その他のリソース** + [CrewAI ドキュメント](https://docs.crewai.com/introduction) + [Terraform AWS プロバイダーのドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) ## 追加情報 このセクションでは、先の[自動化とスケール](#deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework-architecture)の議論に関連して、実装アプローチ、ツール開発、スケールに関する考慮事項について説明します。 **実装アプローチ** エージェントを追加する際、次のアプローチを検討してください。 1. エージェントの設定 + `config/agents.yaml` ファイルに新しいエージェント定義を追加します。 + エージェントごとに特殊なバックストーリー、目標、ツールを定義します。 + エージェントの専門分野に基づいてメモリと分析機能を設定します。 1. タスクのオーケストレーション + `config/tasks.yaml` ファイルを更新して、新しいエージェント固有のタスクを含めます。 + タスク間に依存関係を作成して、適切な情報フローを確保します。 + 必要に応じて並列タスク実行を実装します。 **技術的な実装** 次に示すのは、提案された脅威インテリジェンススペシャリストエージェントの `agents.yaml` ファイルへの追加です。 ``` Example new agent configuration in agents.yaml threat_intelligence_agent: name: "Threat Intelligence Specialist" role: "Cybersecurity Threat Intelligence Analyst" goal: "Correlate AWS security findings with external threat intelligence" backstory: "Expert in threat intelligence with experience in identifying emerging threats and attack patterns relevant to cloud infrastructure." verbose: true allow_delegation: true tools: - "ThreatIntelligenceTool" - "AWSResourceAnalyzer" ``` **ツール開発** CrewAI フレームワークを使用すると、セキュリティ監査のクルーの有効性を高めるために、次のアクションを取ることができます。 + 新しいエージェントのカスタムツールを作成します。 + 脅威インテリジェンスのために外部 API と統合します。 + さまざまな 専用のアナライザーを開発します AWS のサービス。 **スケーリングに関する考慮事項** AWS インフラストラクチャセキュリティ監査およびレポートシステムを拡張して大規模な環境やより包括的な監査を処理する場合は、次のスケーリング要因に対処します。 + **計算リソース** + Lambda メモリ割り当てを増やして、追加のエージェントを処理します。 + エージェントワークロードを複数の Lambda 関数に分割することを検討します。 + **コスト管理** + エージェント数の増加に応じて Amazon Bedrock API の使用状況をモニタリングします。 + 監査範囲に基づいて選択的なエージェントの有効化を実装します。 + **コラボレーション効率** + エージェント間の情報共有を最適化します。 + 複雑な環境のために階層型エージェント構成を実装します。 + **知識ベースの機能強化** + エージェントにドメインの専門知識ベースを提供します。 + 新しいセキュリティのベストプラクティスを使用して、エージェントの知識を定期的に更新します。 # AWS CodePipeline CI/CD パイプラインで AWS Glue ジョブをデプロイする *Amazon Web Services、Bruno Klein、Luis Henrique、Massao Yamada* ## 概要 このパターンは、AWS CodeCommit と AWS CodePipeline を AWS Glue に統合し、開発者が変更をリモートの AWS CodeCommit リポジトリに反映すると直ちに AWS Lambda を使用してジョブを起動する方法を示しています。  開発者が抽出、変換、ロード (ETL) リポジトリに変更を送信し、その変更を AWS CodeCommit にプッシュすると、新しいパイプラインが呼び出されます。パイプラインは、これらの変更を含む AWS Glue ジョブを起動する Lambda 関数を開始します。AWS Glue ジョブは ETL タスクを実行します。 このソリューションは、企業、開発者、データエンジニアが変更をコミットしてターゲットリポジトリにプッシュしたらすぐにジョブを開始する場合に役立ちます。より高いレベルの自動化と再現性を実現できるため、ジョブの起動時とライフサイクル中のエラーを回避できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + [Git](https://git-scm.com/) がローカルマシンにインストールされている + [Amazon Cloud 開発キット (Amazon CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) がローカルマシンにインストールされている + [Python](https://www.python.org/) がローカルマシンにインストールされている + *添付ファイル*セクションのコード **制限** + パイプラインは、AWS Glue ジョブが正常に起動されるとすぐに終了します。ジョブの完了を待たずに行われます。 + 添付のコードはデモ専用です。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Glue + AWS Lambda + AWS CodePipeline + AWS CodeCommit **ターゲットアーキテクチャ** ![\[開発者が CodeCommit リポジトリに変更を反映すると、直ちに Lambda を使用して Glue ジョブを起動します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/99a67388-5939-4267-8324-b6ca8bfa7962/images/917c9041-b94d-4e95-a3c4-9a1115ead228.png) このプロセスは次の 4 つの手順で構成されます。 1. 開発者またはデータエンジニアは ETL コードを変更してコミットし、その変更を AWS CodeCommit にプッシュします。 1. プッシュによってパイプラインが開始されます。 1. パイプラインは Lambda 関数を開始します。Lambda 関数はリポジトリで `codecommit:GetFile` を呼び出し、ファイルを Amazon Simple Storage Service (Amazon S3) にアップロードします。 1. Lambda 関数は ETL コードで新しい AWS Glue ジョブを起動します。 1. Lambda 関数はパイプラインを終了します。 **自動化とスケール** 添付ファイルのサンプルは、AWS Glue を AWS CodePipeline と統合する方法を示しています。ユーザー自身で使用するためにカスタマイズまたは拡張できるベースラインサンプルを提供します。詳細については、「*エピック*」セクションを参照ください。 ## ツール + [AWS CodePipeline](https://aws.amazon.com/codepipeline/) – AWS CodePipeline はフルマネージド型の[継続的デリバリー](https://aws.amazon.com/devops/continuous-delivery/)サービスで、アプリケーションとインフラストラクチャの更新を迅速かつ信頼できるものにするパイプラインのリリース自動化に役立ちます。 + [AWS CodeCommit](https://aws.amazon.com/codecommit/) — AWS CodeCommit は、安全な Git ベースのリポジトリをホストするフルマネージド型の[ソース管理](https://aws.amazon.com/devops/source-control/)サービスです。 + [AWS Lambda](https://aws.amazon.com/lambda/) – AWS Lambda はサーバーをプロビジョニングまたは管理しなくてもコードを実行できるサーバーレスコンピュートサービスです。 + [AWS Glue](https://aws.amazon.com/glue) – AWS Glue は、分析、機械学習、アプリケーション開発用のデータの検出、準備、結合を容易にするサーバーレスデータ統合サービスです。 + [Git クライアント](https://git-scm.com/downloads) — Git は GUI ツールを提供し、コマンドラインまたはデスクトップツールを使用して GitHub から必要なアーティファクトをチェックアウトできます。  + [AWS CDK](https://aws.amazon.com/cdk/) — AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースの定義に役立つオープンソースのソフトウェア開発フレームワークです。 ## エピック ### サンプルコードをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CLI を設定します。 | AWS コマンドラインインターフェイス (AWS CLI) を設定し、現在の AWS アカウントをターゲットにして認証します。手順については、[AWS CLI ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)を参照してください。 | 開発者、DevOpsエンジニア | | サンプルプロジェクトファイルを抽出します。 | 添付ファイルからファイルを抽出し、サンプルプロジェクトファイルを含めるフォルダを作成します。 | 開発者、DevOpsエンジニア | | サンプルコードをデプロイします。 | ファイルを抽出したら、抽出場所から以下のコマンドを実行してベースラインサンプルを作成します。
cdk bootstrap
cdk deploy
git init
git remote add origin 
git stage .
git commit -m "adds sample code"
git push --set-upstream origin main
最後のコマンドの後、パイプラインと AWS Glue ジョブのステータスを監視できます。 | 開発者、DevOpsエンジニア | | コードをカスタマイズします。 | etl.py ファイルのコードをビジネス要件に合わせてカスタマイズします。ETL コードを改訂、パイプラインステージを変更、またはソリューションを拡張できます。 | データエンジニア | ## 関連リソース + [AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html) + [AWS Glue にジョブを追加する](https://docs.aws.amazon.com/glue/latest/dg/add-job.html) + [CodePipeline のソースアクション統合](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-source) + [CodePipeline の パイプラインで AWS Lambda 関数を呼び出す](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html) + [AWS Glue プログラミング](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming.html) + [AWS CodeCommit GetFile API](https://docs.aws.amazon.com/codecommit/latest/APIReference/API_GetFile.html) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/99a67388-5939-4267-8324-b6ca8bfa7962/attachments/attachment.zip)」 # AWS CodePipeline、AWS CodeCommit、AWS CodeBuild を使用して、複数の AWS リージョンにコードをデプロイする *Amazon Web Services、Anand Krishna Varanasi* ## 概要 このパターンは、AWS AWS CloudFormation を使用して複数のAmazon Web Services (AWS) リージョンにまたがるインフラストラクチャまたはアーキテクチャを構築する方法を示しています。　 これには、複数の AWS リージョンにわたる継続的インテグレーション (CI) / 継続的デプロイ (CD) が含まれており、デプロイを迅速に行うことができます。** **このパターンのステップは、例として 3 つの AWS リージョンにデプロイする AWS CodePipeline ジョブの作成でテストされています。ユースケースに基づいてリージョン数を変更できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + + *AmazonS3FullAccess* ポリシーと *CloudWatchFullAccess* ポリシーを含む CodeBuild ロール。これらのポリシーは、CodeBuild に Amazon CloudWatch を通じて AWS CodeCommit のイベントをモニタリングしたり、Amazon Simple Storage Service (Amazon S3) をアーティファクトストアとして使用したりするためのアクセス権を付与します。 + 以下のポリシーを持つ AWS CloudFormation ロール。これにより、AWS CloudFormation は、ビルドの最終段階で AWS Lambda 関数を作成または更新したり、Amazon CloudWatch Logs をプッシュまたはモニタリングしたり、変更セットを作成および更新したりできるようになります。  + *AWSLambdaFullAccess* + *AWSCodeDeployFullAccess* + *CloudWatchFullAccess* + *AWSCloudFormationFullAccess* + *AWSCodePipelineFullAccess* **注記** AWS CodeBuild と AWS CloudFormation の 2 つの AWS Identity and Access Management (IAM) ロールには、アーティファクトのテスト、バンドル、パッケージ化、複数の AWS リージョンへのデプロイという CI タスクを並列して実行するための CodeBuild 用の適切なポリシーがあります。　　  CodePipeline によって作成されたポリシーをクロスチェックして、CodeBuild と AWS CloudFormation が CI フェーズと CD フェーズで適切なアクセス権限を持っていることを確認します。 ## アーキテクチャ ![\[3 つの AWS リージョンにデプロイする AWS CodePipeline ジョブ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d44c393c-7243-4d4e-8b84-88a8503af98f/images/5c27fc35-5e62-4292-8b18-a7bc7faf2631.png) このパターンの複数リージョンのアーキテクチャとワークフローは以下のステップで構成されています。 1. CodeCommit リポジトリにコールを送信します。 1. コードの更新またはコミットを受信すると、CodeCommit は CloudWatch イベントを呼び出し、そのイベントによって CodePipeline ジョブが開始されます。　 1. CodePipeline は CodeBuild によって処理される CI を利用します。以下のタスクが実行されます。 + AWS CloudFormation テンプレートのテスト (オプション) + デプロイに含まれる各リージョンの AWS CloudFormation テンプレートをパッケージ化します。例えば、このパターンは 3 つの AWS リージョンに並列にデプロイされるため、CodeBuild は AWS CloudFormation テンプレートを、指定された各リージョンに 1 つずつ、合計 3 つの S3 バケットにパッケージ化します。S3 バケットは CodeBuild によってアーティファクトリポジトリとしてのみ使用されます。 1. CodeBuild は、3 つの AWS リージョンで並列に実行される次のデプロイフェーズの入力としてアーティファクトをパッケージ化します。　 異なる数のリージョンを指定すると、CodePipeline はそれらのリージョンにデプロイされます。　 ## ツール **ツール** + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) – AWS CodePipelineは、ソフトウェアを継続的に変更するために必要な手順のモデル化、視覚化、および自動化に使用できる継続的な配信サービスです。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) – CodeBuild は、ソースコードをコンパイルし、ユニットテストを実行し、すぐにデプロイできるアーティファクトを生成するフルマネージドビルドサービスです。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) — CodeCommit は、Amazon Web Services がホスティングするバージョン管理サービスで、アセット（ソースコード、バイナリファイルなど）をクラウド内で非公開で保存して管理するために使用できます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) – AWS CloudFormation は、Amazon Web Services リソースのモデル化とセットアップを支援するサービスであるため、これらのリソースの管理に費やす時間を減らし、AWS で実行されるアプリケーションに集中する時間を増やすことができます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) – AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスをセキュアに制御するのに役立つウェブサービスです。 + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。Web スケールのコンピューティングを開発者が容易にできるように設計されています。 **コード** 次のサンプルコードは `BuildSpec.yaml` ファイル (ビルドフェーズ) 用です。 ``` --- artifacts: discard-paths: true files: - packaged-first-region.yaml - packaged-second-region.yaml - packaged-third-region.yaml phases: build: commands: - echo "********BUILD PHASE - CF PACKAGING**********" - "aws cloudformation package --template-file sam-template.yaml --s3-bucket $S3_FIRST_REGION --output-template-file packaged-first-region.yaml --region $FIRST_REGION" - "aws cloudformation package --template-file sam-template.yaml --s3-bucket $S3_SECOND_REGION --output-template-file packaged-second-region.yaml --region $SECOND_REGION" - "aws cloudformation package --template-file sam-template-anand.yaml --s3-bucket $S3_THIRD_REGION --output-template-file packaged-third-region.yaml --region $THIRD_REGION" install: commands: - echo "********BUILD PHASE - PYTHON SETUP**********" runtime-versions: python: 3.8 post_build: commands: - echo "********BUILD PHASE - PACKAGING COMPLETION**********" pre_build: commands: - echo "********BUILD PHASE - DEPENDENCY SETUP**********" - "npm install --silent --no-progress" - echo "********BUILD PHASE - DEPENDENCY SETUP DONE**********" version: 0.2 ``` ## エピック ### コードと CodeCommit リポジトリを準備します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイするプライマリ AWS リージョンを選択します。 | AWS アカウントにサインインして、デプロイするプライマリリージョンを選択します。CodeCommit リポジトリはプライマリ リージョンにあります。 | DevOps | | CodeCommit リポジトリを作成します。 | CodeCommit リポジトリを作成し、必要なコードをプッシュします。コードには通常、AWS CloudFormation または AWS SAM テンプレート、Lambda コード (ある場合)、および AWS CodePipeline への入力としての CodeBuild `buildspec.yaml` ファイルが含まれます。 | DevOps | | コードを CodeCommit リポジトリにプッシュします。 | 「*添付ファイル*」セクションで、この例のコードをダウンロードし、必要なコードをそのコードにプッシュします。通常、コードには、パイプラインへの入力として AWS CloudFormation または AWS SAM テンプレート、Lambda コード、および CodeBuild `buildspec.yaml` ファイルを含めることができます。 | DevOps | ### ソースフェーズ: パイプラインを作成する　 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CodePipeline ジョブを作成します。　 | CodePipeline コンソールで、[**パイプラインの作成**] を選択します。 | DevOps | | CodePipeline ジョブに名前を付け、サービスロール設定を選択します。 | ジョブの名前を入力し、デフォルトのサービスロール設定のままにして、CodePipeline が必要なポリシーをアタッチしたロールを作成します。 | DevOps | | アーティファクトストアの場所を指定します。 | [**詳細設定**] では、デフォルトのオプションをそのまま使用して、CodePipeline がコードアーティファクトストレージに使用する S3 バケットを作成します。代わりに既存の S3 バケットを使用する場合、そのバケットは最初のエピックで指定したプライマリリージョンにある必要があります。　 | DevOps | | 暗号化キーを指定します。　 | デフォルトのオプションである**デフォルトの AWS マネージドキー**をそのまま使用するか、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用します。 | DevOps | | ソースプロバイダを指定します。 | [**ソースプロバイダ**] には、**AWS CodeCommit** を選択します。 | DevOps | | リポジトリを指定します。 | 最初のエピックで作成した CodeCommit リポジトリを選択します。ブランチにコードを配置した場合は、ブランチを選択します。 | DevOps | | コード変更の検出方法を指定します。 | CodeCommit が CodePipeline ジョブを開始するための変更トリガーとして、デフォルトの **Amazon CloudWatch Events** ままにします。 | DevOps | ### ビルドフェーズ:パイプラインを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ビルドプロバイダを指定します。 | [ビルドプロバイダ] には、[**AWS CodeBuild**] を選択します。 | DevOps | | AWS リージョンを指定します。 | 最初のエピックで指定したプライマリ リージョンを選択します。 | DevOps | ### ビルドフェーズ:プロジェクトを作成して設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトの作成 | プロジェクトの名前を入力し、[**プロジェクトの作成**] を選択します。 | DevOps | | 環境イメージを指定します。 | このパターンのデモンストレーションでは、デフォルトの CodeBuild マネージドイメージを使用します。　 また、カスタムの Docker イメージがある場合は、使用することもできます。 | DevOps | | オペレーティングシステムを指定します。 | Amazon Linux 2 または Ubuntu のいずれかを選択します。Amazon Linux 2 のサポートは間もなく終了します。詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください。 | DevOps | | サービスロールを指定します。 | CodePipeline ジョブの作成を開始する前に CodeBuild 用に作成したロールを選択します。　 (「*前提条件*」セクションを参照してください) | DevOps | | 追加のオプションを設定します。 | [**タイムアウト**] と [**キュータイムアウト**] は、デフォルト値のままにします。証明書については、使用したいカスタム証明書がない限り、デフォルト設定のままにします。 | DevOps | | 環境変数 | デプロイする AWS リージョンごとに、S3 バケット名とリージョン名 (us-east-1 など) を指定して環境変数を作成します。 | DevOps | | buildspec.yml でない場合は、buildspec ファイル名を指定します。 | ファイル名がデフォルトの `buildspec.yaml` の場合は、このフィールドを空白のままにします。buildspec ファイルの名前を変更した場合は、ここに名前を入力します。CodeCommit リポジトリ内のファイルの名前と一致することを確認します。 | DevOps | | ログ記録を指定します。 | Amazon CloudWatch Events のログを表示するには、デフォルト設定のままにします。または、特定のグループ名やロガー名を定義することもできます。 | DevOps | ### デプロイフェーズをスキップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイフェーズをスキップして、パイプラインの作成を完了します。 | パイプラインを設定すると、CodePipeline ではデプロイフェーズに 1 つのステージのみ作成できます。複数の AWS リージョンにデプロイするには、このフェーズをスキップしてください。パイプラインを作成した後、複数のデプロイ フェーズ段階を追加できます。 | DevOps | ### デプロイフェーズ: パイプラインを最初のリージョンにデプロイするように設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイ フェーズにステージを追加します。　 | パイプラインを編集し、デプロイ フェーズで**ステージを追加**を選択します。この第 1 ステージはプライマリ リージョン用です。 | DevOps | | ステージのアクション名を指定します。 | 最初の（プライマリ）ステージおよびリージョンを反映する一意の名前を入力します。たとえば、 **primary\$1<リージョン>\$1deploy** と入力します。 | DevOps | | アクションプロバイダを指定します。 | [**アクションプロバイダ**] で、AWS CloudFormation を選択します。 | DevOps | | 第 1 ステージのリージョンを設定します。　 | 第 1 (プライマリ) リージョンは、CodePipeline と CodeBuild が設定されているのと同じリージョンを選択します。これは、スタックをデプロイするプライマリ リージョンです。 | DevOps | | 入力アーティファクトを指定します。 | **BuildArtifact** を選択します。これはビルドフェーズの出力です。 | DevOps | | 必要なアクションを指定します。 | [**アクションモード**] で、[**スタックを作成または更新する**] をクリックします。 | DevOps | | CloudFormation スタックの名前を入力します。 | | DevOps | | 第 1 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 1 (プライマリ) リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。　 | DevOps | | 機能を指定します。 | スタックテンプレートに IAM リソースがある場合やマクロを含むテンプレートから直接スタックを作成する場合に、機能が必要です。このパターンでは、CAPABILITY\$1IAM、CAPABILITY\$1NAMED\$1IAM、CAPABILITY\$1AUTO\$1EXPAND を使用します。 | DevOps | ### デプロイフェーズ:パイプラインを第 2 リージョンにデプロイするように設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイ フェーズに第 2 ステージを追加します。　 | 第 2 リージョンにステージを追加するには、パイプラインを編集し、デプロイ フェーズで [**ステージを追加**] を選択します。重要: 第 2 リージョンの作成プロセスは、次の値を除いて第 1 リージョンの作成プロセスと同じです。 | DevOps | | 第 2 ステージのアクション名を指定します。 | 第 2 ステージと第 2 リージョンを表す一意の名前を入力します。 | DevOps | | 第 2 ステージのリージョンを設定します。　 | スタックをデプロイする第 2 リージョンを選択します。 | DevOps | | 第 2 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 2 リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。　 | DevOps | ### デプロイフェーズ:パイプラインを第 3 リージョンにデプロイするように設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイ フェーズにステージを追加します。　 | 第 3 リージョンにステージを追加するには、パイプラインを編集し、デプロイフェーズで [**ステージを追加**] を選択します。重要: 第 2 リージョンの作成プロセスは、次の値を除いて、これまでの 2 つのリージョンの作成プロセスと同じです。 | DevOps | | 第 3 ステージのアクション名を指定します。 | 第 3 ステージと第 3 リージョンを表す一意の名前を入力します。 | DevOps | | 第 3 ステージのリージョンを設定します。　 | スタックをデプロイする第 3 リージョンを選択します。 | DevOps | | 第 3 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 3 リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。　 | DevOps | ### デプロイをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS リソースを削除します。 | デプロイをクリーンアップするには、各リージョンの CloudFormation スタックを削除します。次に、CodeCommit、CodeBuild、および CodePipeline リソースをプライマリリージョンから削除します。 | DevOps | ## 関連リソース + 「[AWS CodePipeline とは何ですか?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)」 + 「[AWS サーバーレスアプリケーションモデル](https://aws.amazon.com/serverless/sam/)」 + 「[AWS CloudFormation](https://aws.amazon.com/cloudformation/)」 + 「[AWS CodePipeline 用の AWS CloudFormation アーキテクチャ構造リファレンス](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-CloudFormation.html)」 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/d44c393c-7243-4d4e-8b84-88a8503af98f/attachments/attachment.zip)」 # Azure DevOps パイプラインからプライベート Amazon EKS クラスターにワークロードをデプロイする *Amazon Web Services、Mahendra Revanasiddappa* ## 概要 このパターンは、Azure DevOps パイプラインからプライベート Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに継続的インテグレーションおよび継続的デリバリー (CI/CD) を実装する方法を示しています。Amazon EKS クラスターのプライベート API サーバーエンドポイントに移行することにより、セキュリティ体制を強化している組織が直面する重大な課題に対処します。 パブリックエンドポイントは Kubernetes API サーバーをインターネットに直接公開するため、悪意のある攻撃者のターゲットとなりうる大きなアタックサーフェスが発生します。プライベートエンドポイントに切り替えると、クラスターのコントロールプレーンへのアクセスが顧客の仮想プライベートクラウド (VPC) 内に限定されます。 Amazon EKS クラスターをプライベート API エンドポイントに移行するとセキュリティが大幅に強化されますが、Azure DevOps などの外部 CI/CD プラットフォームに接続の課題が生じます。プライベートエンドポイントにアクセスできるのは、クラスターの VPC またはピアネットワーク内からのみです。したがって、 AWS プライベートネットワーク外で動作する標準の Microsoft がホストする Azure DevOps エージェントは、Kubernetes API サーバーに直接到達できません。これらのエージェントで実行されている kubectl や Helm などのツールに依存する一般的なデプロイワークフローは、クラスターへの接続を確立できないため、中断されます。 この問題を解決するために、このパターンでは、プライベート Amazon EKS クラスター内でセルフホスト型の Azure DevOps エージェントを使用して効率的なアプローチを説明します。このソリューションは、セキュリティ要件を維持しながら、優れたコスト最適化、運用効率、スケーラビリティを提供します。このアプローチは、特に、パフォーマンスやセキュリティを犠牲にすることなく、マルチクラウド DevOps プロセスを合理化しようとする企業にメリットをもたらします。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + AWS Command Line Interface (AWS CLI) バージョン 2.13.17 以降がインストールされ[ています。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) + kubectl バージョン 1.25.1 以降が[インストールされていること。](https://kubernetes.io/docs/tasks/tools/) + 名前空間、シークレット、デプロイを作成するアクセス権限を持つプライベート Amazon EKS クラスターバージョン 1.24 以降[が作成されていること](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)[。](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) + インターネットへのアウトバウンド接続を持つ Amazon EKS クラスター内のワーカーノード。これは、ワーカーノードで動作している Azure DevOps エージェントを Azure DevOps エージェントプールに接続できるようにするものです。 + GitHub アカウントが[作成されていること](https://github.com/signup)。 + サービス接続を設定できるアクセス権を持つ Azure DevOps プロジェクト (Azure Pipelines と外部サービスまたはリモートサービス間の認証された接続) が[作成されていること](https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates?view=azure-devops&tabs=microsoft-account)。 + 前のポイントで説明した Azure DevOps プロジェクト用にインストールされた AWS Toolkit for Azure DevOps バージョン 1.15 以降。インストール手順は、Visual Studio Marketplace の「[AWS Toolkit for Azure DevOps](https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.aws-vsts-tools)」を参照してください。 **制限事項** + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ このパターンでは、以下が作成されます。 + **Amazon ECR リポジトリ** – Amazon Elastic Container Registry (Amazon ECR) リポジトリは、Azure DevOps エージェントとデプロイされたサンプルアプリケーションを使用して Docker イメージを保存します。 + **Azure DevOps エージェントプール** – Azure DevOps セルフホスト型エージェントプールは、プライベート Amazon EKS クラスターで動作するエージェントを登録します。 + **IAM ロール** - プライベート Amazon EKS クラスターで実行されているエージェントに必要なアクセスを提供する Azure サービス接続の AWS Identity and Access Management (IAM) ロール。 + **Azure DevOps サービス接続** – パイプラインジョブが AWS のサービスにアクセスするために必要なアクセスを提供する IAM ロールを使用する Azure DevOps アカウントのサービス接続。 次の図は、プライベート Amazon EKS クラスターにセルフホスト型の Azure DevOps エージェントをデプロイし、同じクラスターにサンプルアプリケーションをデプロイするアーキテクチャを示しています。 ![\[プライベート Amazon EKS クラスターへのセルフホスト型の Azure DevOps エージェントとサンプルアプリケーションのデプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a965834f-a1e2-4679-bd8c-15eed4f57b55/images/ee22bd3e-311c-46e0-8024-9b7e7752080a.png) この図表は、次のワークフローを示しています: 1. セルフホスト型の Azure DevOps エージェントを Amazon EKS クラスター内のデプロイとしてデプロイします。 1. Azure DevOps エージェントは、認証のための個人アクセストークン (PAT) を使用して Azure DevOps アカウントのエージェントプールに接続します。 1. Azure Pipelines は、GitHub リポジトリのコードを使用して、デプロイするパイプラインを設定します。 1. パイプラインは、パイプライン設定で設定されたエージェントプールからのエージェントで動作します。Azure DevOps エージェントは、Azure DevOps アカウントに常にポーリングすることにより、パイプラインのジョブ情報を取得します。 1. Azure DevOps エージェントは、Docker イメージをパイプラインジョブの一部として構築し、そのイメージを Amazon ECR リポジトリにプッシュします。 1. Azure DevOps エージェントは、`webapp` という名前空間のプライベート Amazon EKS クラスターにサンプルアプリケーションをデプロイします。 ## ツール **ツール** + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしてのPlatform as a Service (PaaS) 製品のセットです。 + [kubectl](https://kubernetes.io/docs/tasks/tools/)は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。 **コードリポジトリ** + このパターンのコードは、GitHub の [deploy-kubernetes-resources-to-amazon-eks-using-azure-devops](https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops) リポジトリで入手できます。 ## ベストプラクティス + Amazon EKS については、「[Amazon EKS Best Practices Guide](https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html)」を参照してください。 + 最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### サービス接続を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Azure DevOps の組織 GUID を検索する。 | Azure DevOps アカウントにサインインし、次の URL (`https://dev.azure.com/{DevOps_Org_ID}/_apis/projectCollections?api-version=6.0`) を使用して組織の GUID を検索します。この URL で、`{DevOps_org_ID}` は Azure DevOps の組織 ID に置き換えてください。 | AWS DevOps | | AWS アカウントで IdP を設定する。 | Azure サービス接続 AWS アカウント 用に で ID プロバイダー (IdP) を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細については、[OpenID Connect を使用して Azure DevOps AWS から にフェデレーションする方法](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/)」を参照してください。 | AWS DevOps | | AWS アカウントで IAM ポリシーを作成する。 | Azure DevOps パイプラインで使用される IAM ロールに必要なアクセス権限を付与する IAM ポリシーを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps | | AWS アカウントで IAM ロールを作成する。 | Azure サービス接続 AWS アカウント 用に で IAM ロールを設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::{account_id}:oidc-provider/vstoken.dev.azure.com/{OrganizationGUID}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "vstoken.dev.azure.com/{OrganizationGUID}:aud": "api://AzureADTokenExchange",
          "vstoken.dev.azure.com/{OrganizationGUID}:sub": "sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}"
        }
      }
    }
  ]
}
ポリシーで、次のプレースホルダーの情報を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps | | Azure DevOps アカウントでサービス接続を作成する。 | Azure サービス接続を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細は、Microsoft ドキュメントの「[Create a service connection](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops#create-a-service-connection)」を参照してください。 | AWS DevOps | | Amazon EKS 設定ファイルに IAM ロールを追加する。 | IAM ロールには、Amazon EKS クラスターで必要なオペレーションを実行するためのアクセス権限が必要です。パイプラインロールであるため、IAM ロールでクラスター上のほぼすべてのタイプのリソースを管理できる必要があります。そのため、このロールには `system:masters` グループアクセス権限が適しています。必要な設定を Kubernetes 内の `aws-auth ConfigMap` に追加するには、次のコードを使用します。
- groups:
  - system:masters
  rolearn: arn:aws:iam::{account_id}:role/ADO-role
  username: ADO-role
を AWS アカウント ID `{account_id}`に置き換えます。詳細は、Amazon EKS ドキュメントの「[Amazon EKS で IAM を使用する方法](https://docs.aws.amazon.com/eks/latest/userguide/security-iam-service-with-iam.html#security-iam-service-with-iam-roles)」を参照してください。 | AWS DevOps | ### エージェントプールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | セルフホスト型エージェントプールを作成する。 | Azure DevOps アカウントでセルフホスト型エージェントプールを設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細については、Microsoft ドキュメントの「[Create and manage agent pools](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser)」を参照してください。 | | ### Azure DevOps エージェントイメージを構築し、Amazon ECR にプッシュする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリを作成します。 | Azure DevOps エージェントとサンプルアプリケーション (`webapp`) をプライベート Amazon EKS クラスターにデプロイするために使用される Docker イメージは、Amazon ECR リポジトリに保存する必要があります。Amazon ECR リポジトリを作成するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細は、Amazon ECR ドキュメントの「[Creating an Amazon ECR private repository to store images](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」を参照してください。 | AWS DevOps | | Dockerfile を作成して Azure DevOps エージェントを構築する。 | Dockerfile を作成して、Azure DevOps エージェントがインストールされている Docker イメージを構築します。次の内容を `Dockerfile` という名前のファイルに保存します。

FROM ubuntu:22.04 
ENV TARGETARCH="linux-x64"
RUN apt update && apt upgrade -y && apt install -y curl git jq libicu70 unzip wget

RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
RUN unzip awscliv2.zip
RUN ./aws/install
RUN rm -rf aws awscliv2.zip

RUN curl -sSL https://get.docker.com/ | sh

RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash
RUN mkdir -p azp 
WORKDIR /azp/

COPY ./start.sh ./ 
RUN chmod +x ./start.sh

RUN useradd -m -d /home/agent agent 
RUN chown -R agent:agent /azp /home/agent
RUN groupadd -f docker 
RUN usermod -aG docker agent
USER agent

ENTRYPOINT [ "./start.sh" ]
| AWS DevOps | | Azure DevOps エージェント用のスクリプトを作成する。 | `start.sh` スクリプトを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps | | Azure DevOps エージェントを使用して Docker イメージを構築する。 | Azure DevOps エージェントをインストールするための Docker イメージを作成するには、前に作成した Dockerfile を使用してイメージを構築します。Dockerfile を保存したのと同じディレクトリで、以下のコマンドを実行します。
aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

docker build --platform linux/amd64 -t ado-agent:latest .

docker tag ado-agent:latest aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest

docker push aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest
`aws_account_id` と を AWS アカウント ID と `region` に置き換えます AWS リージョン。 | AWS DevOps | ### Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Azure 個人アクセストークンを生成する。 | プライベート Amazon EKS クラスターで動作するエージェントには、Azure DevOps アカウントで認証できるように個人アクセストークン (PAT) が必要です。PAT を生成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)
apiVersion: v1
kind: Secret
metadata:
  name: azdevops-pat
  namespace: default
type: Opaque
stringData:
  AZP_TOKEN:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)
kubectl create -f ado-secret.yaml
詳細は、Microsoft ドキュメントの「[Register an agent using a personal access token (PAT)](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/personal-access-token-agent-registration?view=azure-devops)」を参照してください。 | AWS DevOps | | エージェントのデプロイに Kubernetes マニフェストファイルを使用する。 | Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイするには、次のマニフェストファイルをコピーし、`agent-deployment.yaml` として保存します。
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-pipelines-agent-eks
  labels:
    app: azure-pipelines-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-pipelines-agent
  template:
    metadata:
      labels:
        app: azure-pipelines-agent
    spec:
      containers:
      - name: docker
        image: docker:dind
        securityContext: 
          privileged: true
        volumeMounts:
        - name: shared-workspace
          mountPath: /workspace
        - name: dind-storage
          mountPath: /var/lib/docker
        env:
        - name: DOCKER_TLS_CERTDIR
          value: ""
      - name: azure-pipelines-agent
        image: aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest
        env:
        - name: AZP_URL
          value: ""
        - name: AZP_POOL
          value: "eks-agent"
        - name: AZP_TOKEN
          valueFrom:
            secretKeyRef:
              name: azdevops-pat
              key: AZP_TOKEN
        - name: AZP_AGENT_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: DOCKER_HOST
          value: tcp://localhost:2375
        volumeMounts:
        - mountPath: /workspace
          name: shared-workspace
      volumes:
      - name: dind-storage
        emptyDir: {}
      - name: shared-workspace
        emptyDir: {}
`aws_account_id` と を AWS アカウント ID と Azure DevOps アカウント URL ``に置き換えます。 | AWS DevOps | | エージェントをプライベート Amazon EKS クラスターにデプロイする。 | Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイするには、次のコマンドを実行します。
kubectl create -f agent-deployment.tf
| AWS DevOps | | エージェントが実行されていることを確認する | Azure DevOps エージェントが実行されていることを確認するには、次のコマンドを使用します。
kubectl get deploy azure-pipelines-agent-eks
次のような内容が出力されます。

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
azure-pipelines-agent-eks   1/1     1            1           58s
`READY ` 列に `1/1` が表示されていることを確認します。 | AWS DevOps | | エージェントが Azure DevOps エージェントプールに登録されていることを確認する。 | エージェントがプライベート Amazon EKS クラスターにデプロイされ、エージェントプール `eks-agent` に登録されていることを確認するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)**[Status]** が **[Online]** のエージェントが 1 つ表示されます。エージェントの名前は、**azure-pipelines-agent-eks-\$1** で始まっているはずです。 | AWS DevOps | ### サンプルアプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプルアプリケーションリポジトリを GitHub アカウントにフォークする。 | 次の AWS サンプルリポジトリを GitHub アカウントにフォークします。[https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops](https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops) | AWS DevOps | | パイプラインを作成する | Azure DevOps アカウントでパイプラインを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)
pool:
  name: eks-agent
#pool: self-hosted # If you are running self-hosted Azure DevOps Agents

stages:
# Refering the pipeline template, input parameter that are not specified will be added with defaults
- template: ./pipeline_templates/main_template.yaml
  parameters:
    serviceConnectionName: aws-sc
    awsRegion: 
    awsEKSClusterName: 
    projectName: webapp
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps | | サンプルアプリケーションがデプロイされていることを確認する。 | パイプラインが完了したら、Amazon ECR リポジトリと Amazon EKS クラスターの両方をチェックして、サンプルアプリケーションのデプロイが成功したことを確認します。Amazon ECR リポジトリのアーティファクトを検証するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)例えば、`20250501.1-image` と `20250501.1-helm` です。名前空間 `webapp` のプライベート Amazon EKS クラスターでのデプロイを確認するには、次のコマンドを実行します。
kubectl get deploy -n webapp
予想される出力は次のようになります。

NAME     READY   UP-TO-DATE   AVAILABLE
webapp   1/1     1            1
注: これが最初のパイプライン実行である場合は、サービス接続とエージェントプールの承認が必要となる場合があります。Azure DevOps パイプラインインターフェイスでアクセス許可リクエストを探し、承認して続行します。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Amazon ECR リポジトリ名が `webapp` と一致しないとパイプラインが失敗する | サンプルアプリケーションでは、Amazon ECR リポジトリ名が `azure_pipeline.yml` の `projectName: webapp` パラメータと一致することが想定されています。この問題を解決するには、Amazon ECR リポジトリの名前を `webapp` に変更するか、以下を更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | | エラー: Kubernetes クラスターに到達できません: サーバーがクライアントに認証情報の提供を要求しました | Azure パイプラインの「Helm チャートのプルとデプロイ」ステップでこのエラーが発生した場合、通常、Amazon EKS クラスターの `aws-auth ConfigMap` での誤った IAM ロール設定が根本原因です。この問題を解決するには、以下を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | ## 関連リソース **AWS ブログ** + [OpenID Connect を使用して Azure DevOps AWS から にフェデレーションする方法](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/) **AWS のサービス ドキュメント** + [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) + [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) **Microsoft ドキュメント** + [What is Azure DevOps?](https://learn.microsoft.com/en-us/azure/devops/user-guide/what-is-azure-devops?view=azure-devops) + [What is Azure Pipelines?](https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-azure-pipelines?view=azure-devops) # Terraform を使用して Amazon Redshift SQL クエリを実行する *Amazon Web Services、Sylvia Qi、Aditya Ambati* ## 概要 Amazon Redshift のデプロイと管理に Infrastructure as Code (IaC) を使用することは、DevOps 内での一般的なプラクティスです。IaC を使用すると、クラスター、スナップショット、パラメータグループなど、さまざまな Amazon Redshift リソースのデプロイと設定が簡単に行えます。ただし、IaC はテーブル、スキーマ、ビュー、ストアドプロシージャなどのデータベースリソースの管理までは対応していません。これらのデータベース要素は SQL クエリによって管理されるもので、IaC ツールでは直接サポートされていません。これらのリソースを管理するためのソリューションとツールがありますが、テクノロジースタックへの追加ツールの導入を回避したい場合があります。 このパターンでは、Terraform を使用してテーブル、スキーマ、ビュー、ストアドプロシージャなどの Amazon Redshift データベースリソースをデプロイする方法の概要を示します。パターンでは、2 種類の SQL クエリを区別します。 + **再現不可能なクエリ** – これらのクエリは、最初の Amazon Redshift デプロイ中に 1 回実行され、重要なデータベースコンポーネントを確立します。 + **反復可能なクエリ** – これらのクエリはイミュータブルであり、データベースに影響を与えることなく再実行できます。このソリューションは、Terraform を使用して反復可能なクエリの変更をモニタリングし、それに応じて適用します。 詳細については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の*「ソリューションの詳細*」を参照してください。 ## 前提条件と制限 **前提条件** をアクティブに AWS アカウント し、デプロイマシンに以下をインストールする必要があります。 + [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (AWS CLI) + Amazon Redshift の読み取り/書き込みアクセス権限が設定された [AWS CLI プロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) + [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) バージョン 1.6.2 以降 + [Python3](https://www.python.org/downloads/) + [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) **制限事項** + Terraform でのクラスター作成中はデータベースを 1 つしか作成できないため、このソリューションでは単一の Amazon Redshift データベースをサポートします。 + このパターンには、反復可能なクエリへの変更を適用する前に検証するテストは含まれません。信頼性を高めるために、このようなテストを組み込むことをお勧めします。 + このソリューションを説明するために、このパターンではローカル Terraform ステートファイルを使用するサンプル `redshift.tf` ファイルを用意しています。ただし、本番環境では、安定性とコラボレーションを強化するために、ロック機構を備えたリモートステートファイルを使用することを強くお勧めします。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。 **製品バージョン** このソリューションは、[Amazon Redshift パッチ 179](https://docs.aws.amazon.com/redshift/latest/mgmt/cluster-versions.html#cluster-version-179) で開発およびテストされています。 **コードリポジトリ** このパターンのコードは、GitHub の「[amazon-redshift-sql-deploy-terraform](https://github.com/aws-samples/amazon-redshift-sql-deploy-terraform)」リポジトリで入手できます。 ## アーキテクチャ 次の図に、Terraform が反復不可能な SQL クエリと反復不可能な SQL クエリの両方を処理することで Amazon Redshift データベースリソースを管理する方法を示します。 ![\[Terraform が SQL クエリを使用して Amazon Redshift データベースリソースを管理するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0f4467ac-761b-4b6b-a32f-e18a2ca2245d/images/3b6ff9e8-e3d1-48ed-9fa1-4b14f7d3d65b.png) 図表に示す内容は以下のステップです。 1. Amazon Redshift クラスターの初回デプロイ時に、Terraform が反復不可能な SQL クエリを適用します。 1. 開発者が、反復可能な SQL クエリの変更をコミットします。 1. Terraform が、反復可能な SQL クエリの変更をモニタリングします。 1. Terraform が、反復可能な SQL クエリを Amazon Redshift データベースに適用します。 このパターンで提供するソリューションは、[Amazon Redshift 用の Terraform モジュール](https://registry.terraform.io/modules/terraform-aws-modules/redshift/aws/latest)に基づいて構築されています。Terraform モジュールは Amazon Redshift クラスターとデータベースをプロビジョニングします。モジュールを強化するために、ここでは `terraform_data` リソースを使用しています。ここで、カスタム Python スクリプトを呼び出し、Amazon Redshift [ExecuteStatement](https://docs.aws.amazon.com/redshift-data/latest/APIReference/API_ExecuteStatement.html) API オペレーションを使用して SQL クエリを実行します。結果として、モジュールは以下を実行できます。 + データベースのプロビジョニング後に SQL クエリを使用して、任意の数のデータベースリソースをデプロイする。 + 反復可能な SQL クエリの変更を継続的にモニタリングし、Terraform を使用してそれらの変更を適用する。 詳細については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の*「ソリューションの詳細*」を参照してください。 ## ツール **AWS のサービス** + [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html) は、フルマネージド型で、ペタバイトスケールのデータウェアハウスを提供する、 AWS クラウドのサービスです。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 + [Python](https://www.python.org/) は、SQL クエリを実行するためにこのパターンで使用する汎用プログラミング言語です。 ## ベストプラクティス + [Amazon Redshift のベストプラクティス](https://docs.aws.amazon.com/redshift/latest/dg/best-practices.html) + [Using the Amazon Redshift Data API to interact with Amazon Redshift clusters](https://aws.amazon.com/blogs/big-data/using-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-clusters/) ## エピック ### Terraform を使用してソリューションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | **リポジトリのクローンを作成します。** | Amazon Redshift クラスターをプロビジョニングするための Terraform コードを含む Git リポジトリのクローンを作成するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/amazon-redshift-sql-deploy-terraform.git
| DevOps エンジニア | | **Terraform 変数を更新します。** | 特定の要件に従って Amazon Redshift クラスターのデプロイをカスタマイズするには、`terraform.tfvars` ファイル内の次のパラメータを更新します。
region                    = ""
cluster_identifier        = ""
node_type                 = ""
number_of_nodes           = ""
database_name             = ""
subnet_ids                = ""
vpc_security_group_ids    = ""
run_nonrepeatable_queries = true
run_repeatable_queries    = true
sql_path_bootstrap        = ""
sql_path_nonrepeatable    = ""
sql_path_repeatable       = ""
sql_path_finalize         = ""
create_random_password    = false
master_username           = ""
| DevOps エンジニア | | Terraform を使用してリソースをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/execute-redshift-sql-queries-using-terraform.html) | DevOps エンジニア | | (オプション) 追加の SQL クエリを実行します。 | サンプルリポジトリには、デモ用の SQL クエリがいくつか用意されています。独自の SQL クエリを実行するには、それらを次のフォルダに追加します。`/bootstrap` `/nonrepeatable` `/repeatable` `/finalize` | | ### SQL ステートメントの実行をモニタリングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SQL ステートメントのデプロイをモニタリングします。 | Amazon Redshift クラスターに対する SQL 実行の結果をモニタリングできます。失敗した SQL 実行と成功した SQL 実行を示す出力の例については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の「*SQL ステートメントの例*」を参照してください。 | DBA、DevOps エンジニア | | リソースをクリーンアップします。 | Terraform によってデプロイされたリソースをすべて削除するには、次のコマンドを実行します。
terraform destroy
| DevOps エンジニア | ### 結果を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Redshift クラスターのデータを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/execute-redshift-sql-queries-using-terraform.html) | DBA、AWS DevOps | ## 関連リソース **AWS ドキュメント** + [Amazon Redshift でプロビジョニングされたクラスター](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html) + [Amazon Redshift Data API の問題のトラブルシューティング](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-troubleshooting.html) **その他のリソース** + [コマンド: apply](https://developer.hashicorp.com/terraform/cli/commands/apply) (Terraform ドキュメント) ## 追加情報 **ソリューションの詳細** このソリューションを使用するには、Amazon Redshift SQL クエリを特定の方法で配置する必要があります。すべての SQL クエリは、`.sql` 拡張子が付いたファイルに保存する必要があります。 このパターンで提供するコード例では、SQL クエリは次のフォルダ構造内に配置されます。独自のユースケースに適した任意の構造に対応するように、コード (`sql-queries.tf` と `sql-queries.py`) を変更することができます。 ``` /bootstrap |- Any # of files |- Any # of sub-folders /nonrepeatable |- Any # of files |- Any # of sub-folders /repeatable /udf |- Any # of files |- Any # of sub-folders /table |- Any # of files |- Any # of sub-folders /view |- Any # of files |- Any # of sub-folders /stored-procedure |- Any # of files |- Any # of sub-folders /finalize |- Any # of files |- Any # of sub-folders ``` このようなフォルダ構造のため、Amazon Redshift クラスターのデプロイ中、Terraform でのクエリ実行は次の順序で行われます。 1. `/bootstrap` 1. `/nonrepeatable` 1. `/repeatable` 1. `/finalize` `/repeatable` フォルダには、`/udf`、`/table`、`/view`、`/stored-procedure` の 4 つのサブフォルダがあります。これらのサブフォルダは、Terraform が SQL クエリを実行する順序を示しています。 SQL クエリを実行する Python スクリプトは `sql-queries.py` です。スクリプトは、まず `sql_path_bootstrap` パラメータなど、特定のソースディレクトリのすべてのファイルとサブフォルダを読み取ります。その次に、Amazon Redshift [ExecuteStatement](https://docs.aws.amazon.com/redshift-data/latest/APIReference/API_ExecuteStatement.html) API オペレーションを呼び出してクエリを実行します。ファイル内に 1 つ以上の SQL クエリがある場合があります。次のコードスニペットは、ファイルに保存されている SQL ステートメントを Amazon Redshift クラスターに対して実行する Python 関数を示しています。 ``` def execute_sql_statement(filename, cluster_id, db_name, secret_arn, aws_region): """Execute SQL statements in a file""" redshift_client = boto3.client( 'redshift-data', region_name=aws_region) contents = get_contents_from_file(filename), response = redshift_client.execute_statement( Sql=contents[0], ClusterIdentifier=cluster_id, Database=db_name, WithEvent=True, StatementName=filename, SecretArn=secret_arn ) ... ``` Terraform スクリプト `sql-queries.tf` は、`sql-queries.py` スクリプトを呼び出す [terraform\$1data](https://developer.hashicorp.com/terraform/language/resources/terraform-data) リソースを作成します。`/bootstrap`、`/nonrepeatable`,`/repeatable`,`/finalize` の 4 つのフォルダのそれぞれに 1 つの `terraform_data` リソースがあります。次のコードスニペットは、`/bootstrap` フォルダ内の SQL クエリを実行する `terraform_data` リソースを示しています。 ``` locals { program = "${path.module}/sql-queries.py" redshift_cluster_name = try(aws_redshift_cluster.this[0].id, null) } resource "terraform_data" "run_bootstrap_queries" { count = var.create && var.run_nonrepeatable_queries && (var.sql_path_bootstrap != "") && (var.snapshot_identifier == null) ? 1 : 0 depends_on = [aws_redshift_cluster.this[0]] provisioner "local-exec" { command = "python3 ${local.program} ${var.sql_path_bootstrap} ${local.redshift_cluster_name} ${var.database_name} ${var.redshift_secret_arn} ${local.aws_region}" } } ``` これらのクエリを実行するかどうかを制御するには、次の変数を使用できます。`sql_path_bootstrap`、`sql_path_nonrepeatable`、`sql_path_repeatable`、`sql_path_finalize` でクエリを実行しない場合は、それらの値を `""` に設定します。 ``` run_nonrepeatable_queries = true run_repeatable_queries = true sql_path_bootstrap = "src/redshift/bootstrap" sql_path_nonrepeatable = "src/redshift/nonrepeatable" sql_path_repeatable = "src/redshift/repeatable" sql_path_finalize = "src/redshift/finalize" ``` `terraform apply` を実行すると、Terraform はスクリプトの結果に関係なく、スクリプトが完了した後に追加された `terraform_data` リソースを考慮します。一部の SQL クエリが失敗し、再実行する場合は、Terraform 状態からリソースを手動で削除して、`terraform apply` を再度実行できます。例えば、次のコマンドを実行すると、Terraform 状態から `run_bootstrap_queries` リソースが削除されます。 `terraform state rm module.redshift.terraform_data.run_bootstrap_queries[0]` 次のコード例は、`run_repeatable_queries` リソースが [sha256 ハッシュ](https://developer.hashicorp.com/terraform/language/functions/sha256)を使用して `repeatable` フォルダでの変更をモニタリングする方法を示しています。フォルダ内のファイルが更新されると、Terraform はディレクトリ全体に更新のマークを付けます。そして、次の `terraform apply` 中にディレクトリ内でクエリを再度実行します。 ``` resource "terraform_data" "run_repeatable_queries" { count = var.create_redshift && var.run_repeatable_queries && (var.sql_path_repeatable != "") ? 1 : 0 depends_on = [terraform_data.run_nonrepeatable_queries] # Continuously monitor and apply changes in the repeatable folder triggers_replace = { dir_sha256 = sha256(join("", [for f in fileset("${var.sql_path_repeatable}", "**") : filesha256("${var.sql_path_repeatable}/${f}")])) } provisioner "local-exec" { command = "python3 ${local.sql_queries} ${var.sql_path_repeatable} ${local.redshift_cluster_name} ${var.database_name} ${var.redshift_secret_arn}" } } ``` コードを効率化するために、すべてのファイルに無差別に変更を適用するのではなく、`repeatable` フォルダ内で更新されたファイルのみの変更を検出して適用するメカニズムを実装できます。 **SQL ステートメントの例** 次の出力は、失敗した SQL 実行とエラーメッセージを示しています。 ``` module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Executing: ["/bin/sh" "-c" "python3 modules/redshift/sql-queries.py src/redshift/nonrepeatable testcluster-1 db1 arn:aws:secretsmanager:us-east-1:XXXXXXXXXXXX:secret:/redshift/master_user/password-8RapGH us-east-1"] module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): ------------------------------------------------------------------- module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): src/redshift/nonrepeatable/table/admin/admin.application_family.sql module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): ------------------------------------------------------------------- module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Status: FAILED module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): SQL execution failed. module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Error message: ERROR: syntax error at or near ")" module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Position: 244 module.redshift.terraform_data.run_nonrepeatable_queries[0]: Creation complete after 3s [id=ee50ba6c-11ae-5b64-7e2f-86fd8caa8b76] ``` 次の出力は、成功した SQL 実行を示しています。 ``` module.redshift.terraform_data.run_bootstrap_queries[0]: Provisioning with 'local-exec'... module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): Executing: ["/bin/sh" "-c" "python3 modules/redshift/sql-queries.py src/redshift/bootstrap testcluster-1 db1 arn:aws:secretsmanager:us-east-1:XXXXXXXXXXXX:secret:/redshift/master_user/password-8RapGH us-east-1"] module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): ------------------------------------------------------------------- module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): src/redshift/bootstrap/db.sql module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): ------------------------------------------------------------------- module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): Status: FINISHED module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): SQL execution successful. module.redshift.terraform_data.run_bootstrap_queries[0]: Creation complete after 2s [id=d565ef6d-be86-8afd-8e90-111e5ea4a1be] ``` # AWS Organizations 内の組織全体の AWS Backup レポートを CSV ファイルとしてエクスポートする *Amazon Web Services、Aromal Raj Jayarajan、Purushotham G K* ## 概要 このパターンは、AWS Organizations 内のある組織全体の AWS Backup ジョブレポートを CSV ファイルとしてエクスポートする方法を示しています。このソリューションでは、AWS Lambda と Amazon EventBridge を使用して AWS Backup ジョブレポートをステータスに基づいて分類します。これは、ステータスベースの自動化を構成するときに役立ちます。 AWS Backup は、AWS のサービス、クラウド内、およびオンプレミス間の一元化およびデータ保護の自動化を支援します。ただし、AWS Organizations 内で構成された AWS Backup ジョブの場合、統合レポートは各組織の管理アカウントの AWS マネジメントコンソールでのみ使用できます。このレポートを管理アカウントの外部に置くことで、監査に必要な労力を減らし、自動化、通知、アラートの範囲を広げることができます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + 少なくとも管理アカウントとメンバーアカウントを含む、AWS Organizations 内のアクティブな[組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html) + AWS Organizations の組織レベルで構成された AWS Backup (詳細については、AWS ブログの「[ Backup を使用して AWS のサービス全体にわたる大規模集中バックアップを自動化する](https://aws.amazon.com/blogs/storage/automate-centralized-backup-at-scale-across-aws-services-using-aws-backup/)」を参照してください) + ローカルマシンにインストールされて構成されている [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) **機能制限** このパターンで提供されるソリューションは、AWS Backup ジョブ専用に構成された AWS リソースを識別します。このレポートでは、AWS Backup によるバックアップ用に構成されていない AWS Backup リソースは特定できません。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Backup + AWS CloudFormation + Amazon EventBridge + AWS Lambda + AWS Security Token Service (AWS STS) + Amazon Simple Storage Service (Amazon S3) + AWS Identity and Access Management (IAM) **ターゲットアーキテクチャ** 次の図は、AWS Organizations 内のある組織全体から AWS Backup ジョブレポートを CSV ファイルとしてエクスポートするワークフローの例を示しています。 ![\[EventBridge、Lambda、AWS STS、IAM を使用して、組織全体の AWS Backup ジョブレポートを CSV 形式でエクスポートします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/74955aad-cc6d-488b-aa34-ae43f50fec60/images/5c39c79f-e731-4ad0-b404-51ebe0976420.png) この図表は、次のワークフローを示しています: 1. スケジュールされた EventBridge イベントルールは、メンバー (レポーティング) AWS アカウントの Lambda 関数を呼び出します。 1. 次に、Lambda 関数は AWS STS を使用して、管理アカウントへの接続に必要な権限を持つ IAM ロールを引き受けます。 1. Lambda 関数は以下を実行します。 + AWS Backup サービスに統合された AWS Backup ジョブレポートをリクエストする + AWS Backup ジョブのステータスに基づいて結果を分類する + レスポンスを CSV ファイルに変換する + 作成日に基づいてラベル付けされたフォルダ内のレポーティングアカウントの Amazon S3 バケットに、結果をアップロードする ## ツール **ツール** + [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、フルマネージド型のサービスで、 AWS サービス、クラウド、オンプレミスにおけるデータ保護の一元化と自動化に役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。たとえば、AWS Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、または他の AWS アカウントのイベントバスなどです。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS 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) 」は、どのようなデータの量であっても、保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 **Code** このパターンのコードは、GitHub の[aws-backup-report-generator](https://github.com/aws-samples/aws-backup-report-generator) リポジトリにあります。 ## ベストプラクティス + [Amazon S3 のセキュリティベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) (*Amazon S3 ユーザーガイド*) + [AWS Lambda 関数を操作するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) (*AWS Lambda デベロッパーガイド*) + [管理アカウントのベストプラクティス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) (*AWS Organizations ユーザーガイド*) ## エピック ### ソリューションコンポーネントをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリのクローン作成 | ターミナルウィンドウで次のコマンドを実行して、GitHub の [aws-backup-report-generator](https://github.com/aws-samples/aws-backup-report-generator) リポジトリをクローン作成します。
git clone https://github.com/aws-samples/aws-backup-report-generator.git
詳細については、GitHub Docsの「[リポジトリのクローン作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | AWS DevOps、DevOps エンジニア | | メンバー (レポーティング) AWS アカウントにソリューションコンポーネントをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | DevOps エンジニア、AWS DevOps | ### ソリューションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト前に EventBridge ルールが実行されていることを確認する。 | 少なくとも 24 時間待つか、CloudFormation テンプレートの **template-reporting.yml** ファイル内のレポート頻度を増やして、EventBridge ルールが実行されることを確認してください。**レポート頻度を増やすには**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア | | 生成されたレポートを Amazon S3 バケットで確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア | ### リソースのクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メンバー (レポーティング) アカウントからソリューションコンポーネントを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア | | 管理アカウントからソリューションコンポーネントを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア | ## 関連リソース + [チュートリアル: スケジュールされたイベントで Lambda を使用する](https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents-tutorial.html) (AWS Lambda ドキュメント) + [Creating scheduled events to execute AWS Lambda functions](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/scheduled-events-invoking-lambda-example.html) (AWS SDK for JavaScript ドキュメント) + [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) (IAM ドキュメント) + [AWS Organizations 用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations ドキュメント) + [Creating report plans using the AWS Backup console](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-report-plan-console.html) (AWS Backup ドキュメント) + [Create an audit report](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-audit-report.html) (AWS Backup ドキュメント) + [Creating on-demand reports](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-on-demand-reports.html) (AWS Backup ドキュメント) + [AWS Backup とは?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) (AWS Backup ドキュメント) + [Automate centralized backup at scale across AWS services using AWS Backup](https://aws.amazon.com/blogs/storage/automate-centralized-backup-at-scale-across-aws-services-using-aws-backup/) (AWS ブログ記事) # Amazon EC2 インスタンスのリストのタグを CSV ファイルにエクスポートする *Amazon Web Services、Sida Ju、PAC Joonhyun* ## 概要 このパターンは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのリストのタグをプログラムで CSV ファイルにエクスポートする方法を示しています。 以下の Python スクリプトの例を使用すると、Amazon EC2 インスタンスを確認して特定のタグで分類するのにかかる時間を短縮できます。たとえば、このスクリプトを使用して、セキュリティチームがソフトウェアアップデートのフラグを付けたインスタンスのリストをすばやく特定して分類できます。 ## 前提条件と制限 **前提条件** + Python 3 がインストールされ、構成されている + AWS コマンドラインインターフェイス (AWS CLI) がインストールされ、構成されている **制限事項** このパターンで指定される Python スクリプトの例では、以下の属性のみに基づいて Amazon EC2 インスタンスを検索できます。 + インスタンス ID + プライベート IPv4 アドレス + パブリック IPv4 アドレス ## ツール + 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。 + [virtualenv](https://virtualenv.pypa.io/en/latest/) は、隔離された Python 環境を作成するのに役立ちます。 + 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 **コードリポジトリ** このパターンの Python スクリプトの例は、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリにあります。 ## エピック ### 前提条件をインストールして設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリのクローン作成 | AWS CLI コマンドの実行中にエラーが発生した場合は、[最新の CLI バージョンを使用していることを確認してください](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html)。ターミナルウィンドウで次の Git コマンドを実行して、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリのクローンを作成します。
git clone https://github.com/aws-samples/search-ec2-instances-export-tags.git
| DevOps エンジニア | | virtualenv をインストールして有効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.html)詳細については、「[virtualenv ユーザーガイド](https://virtualenv.pypa.io/en/latest/user_guide.html)」を参照してください。 | DevOps エンジニア | | 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.html) | DevOps エンジニア | | AWS の名が付いたプロファイルを構成します。 | まだ構成していない場合は、スクリプトを実行するために必要な認証情報を含む AWS の名前付きプロファイルを構成します。名前付きプロファイルを作成するには、[ configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods) コマンドを実行します。詳細については、AWS CLI ドキュメントの「[名前付きプロファイルを使用する](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles)」を参照してください。 | DevOps エンジニア | ### Python スクリプトを構成して実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 入力ファイルを作成します。 | スクリプトでタグを検索してエクスポートしたい Amazon EC2 インスタンスのリストを含む入力ファイルを作成します。インスタンス ID、プライベート IPv4 アドレス、またはパブリック IPv4 アドレスを一覧表示できます。各 Amazon EC2 インスタンスが入力ファイルの個別の行にリストされていることを確認してください。**入力データの例**
1    i-0547c351bdfe85b9f
2    54.157.194.156
3    172.31.85.33
4    54.165.198.144
5    i-0b6223b5914111a4b
6    172.31.85.44
7    54.165.198.145
8    172.31.80.219
9    172.31.94.199
| DevOps エンジニア | | Python スクリプトを実行する。 | ターミナルで次のコマンドを実行して、スクリプトを実行します。
python search_instances.py -i INPUTFILE -o OUTPUTFILE -r REGION [-p PROFILE]
`INPUTFILE` を入力ファイルの名前に置き換えます。`OUTPUTFILE` を、CSV 出力ファイルの名前に置き換えます。`REGION` を Amazon EC2 リソースが存在する AWS リージョンに置き換えます。AWS の名前付きプロファイルを使用している場合は、`PROFILE` を使用している名前付きプロファイルに置き換えます。サポートされているパラメータとその説明のリストを取得するには、次のコマンドを実行します。
python search_instances.py -h
詳細および出力ファイルの例については、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリにある `README.md` ファイルを参照してください。 | DevOps エンジニア | ## 関連リソース + [AWS CLI の構成](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) (*AWS CLI ユーザーガイド*) # Troposphere を使用して AWS Config マネージドルールを含む AWS CloudFormation テンプレートを生成します *Lucas Nation と Freddie Wilson、Amazon Web Services* ## 概要 多くの組織は、「[AWS Config マネージド](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)」ルールを使用して、Amazon Web Services (AWS) リソースのコンプライアンスを一般的なベストプラクティスに照らして評価しています。ただし、これらのルールは保守に時間がかかる場合があり、このパターンは Python ライブラリである「[Troposphere](https://troposphere.readthedocs.io/en/latest/quick_start.html)」を活用して AWS Config マネージドルールを生成および管理するのに役立ちます。 このパターンは、Python スクリプトを使用して AWS マネージドルールを含む Microsoft Excel スプレッドシートを AWS CloudFormation テンプレートに変換することで、AWS Config マネージドルールを管理するのに役立ちます。Troposphere は infrastructure as code (IaC) として機能します。つまり、JSON や YAML 形式のファイルを使用する代わりに、マネージドルールで Excel スプレッドシートを更新できるということです。次に、このテンプレートを使用して AWS CloudFormation スタックを起動し、AWS アカウントのマネージドルールを作成および更新します。 AWS CloudFormation テンプレートは Excel スプレッドシートを使用して各 AWS Config マネージドルールを定義し、AWS マネジメントコンソールで個々のルールを手動で作成する手間を省くのに役立ちます。このスクリプトでは、各マネージドルールのパラメータは空の辞書にデフォルト設定され、`ComplianceResourceTypes` スコープのデフォルトは `THE_RULE_IDENTIFIER.template file` からになります*。*ルール識別子の詳細については、AWS Config ドキュメントの「[AWS CloudFormation テンプレートを使用した AWS Config マネージドルールの作成](https://docs.aws.amazon.com/config/latest/developerguide/aws-config-managed-rules-cloudformation-templates.html)」を参照してください。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + AWS CloudFormation テンプレートを使用して AWS Config マネージドルールを作成することに精通していること。これに関する詳細については、AWS Config ドキュメントの「[AWS CloudFormation テンプレートを使用した AWS Config マネージドルールの作成](https://docs.aws.amazon.com/config/latest/developerguide/aws-config-managed-rules-cloudformation-templates.html)」を参照してください。  + Python 3 がインストールされ、設定されています。詳細については、「[Python ドキュメント](https://www.python.org/)」を参照してください。 + 既存の統合開発環境 (IDE)。  + サンプル `excel_config_rules.xlsx` Excel スプレッドシート (添付) の列で組織単位 (OU) を特定します。 ## エピック ### AWS Config マネージドルールのカスタマイズと設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプル Excel スプレッドシートを更新してください。 | サンプル `excel_config_rules.xlsx` Excel スプレッドシート (添付) をダウンロードし、使用したい AWS Config マネージドルールを `Implemented` としてラベルを付けます。 `Implemented` とマークされたルールは AWS CloudFormation テンプレートに追加されます。 | 開発者 | | (オプション) config\$1rules\$1params.json ファイルを AWS Config ルールパラメータで更新します。 | 一部の AWS Config マネージドルールはパラメータを必要とするため、`--param-file` オプションを使用して JSON ファイルとして Python スクリプトに渡す必要があります。たとえば、`access-keys-rotated` マネージドルールは次の `maxAccessKeyAge` パラメータを使用します。
{
         "access-keys-rotated": {
             "InputParameters": {
                 "maxAccessKeyAge": 90
             }
         }
     }
このサンプルパラメータでは、`maxAccessKeyAge` は 90 日に設定されています。スクリプトはパラメータファイルを読み取り、見つかった `InputParameters` をすべて追加します。 | 開発者 | | (オプション) config\$1rules\$1params.json ファイルを AWS Config コンプライアンスリソースタイプで更新します。 | デフォルトでは、Python スクリプトは AWS 定義のテンプレートから `ComplianceResourceTypes` を取得します。特定の AWS Config マネージドルールの範囲をオーバーライドする場合は、`--param-file` オプションを使用して JSON ファイルとして Python スクリプトに渡す必要があります。たとえば、次のサンプルコードは、`ec2-volume-inuse-check` の `ComplianceResourceTypes` を `["AWS::EC2::Volume"]` リストに設定する方法を示しています。
{
         "ec2-volume-inuse-check": {
             "Scope": {
                 "ComplianceResourceTypes": [
                     "AWS::EC2::Volume"
                 ]
             }
         }
     }
| 開発者 | ### Python スクリプトを実行する。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | requirements.txt ファイルから pip パッケージをインストールします。 | `requirements.txt` ファイル (添付) をダウンロードし、IDE で次のコマンドを実行して Python パッケージをインストールします。`pip3 install -r requirements.txt` | 開発者 | | Python スクリプトを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html)また、次のオプションパラメータを含めることができます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html) | 開発者 | ### AWS Config マネージドルールをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html) | 開発者 | ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/07c1cfff-fc9e-4a1f-bd36-48f025808bd8/attachments/attachment.zip)」 # SageMaker ノートブックインスタンスに、別の AWS アカウントの CodeCommit リポジトリへの一時的なアクセスを許可する *Helge Aufderheide、Amazon Web Services* ## 概要 このパターンは、Amazon SageMaker ノートブックインスタンスとユーザーに、別の AWS アカウントにある AWS CodeCommit リポジトリへの一時的なアクセスを許可する方法を示しています。このパターンはまた、各エンティティが各リポジトリで実行できる特定のアクションに対してきめ細かいアクセス権限を付与する方法も示しています。 組織は多くの場合、開発環境をホストするアカウントとは別の AWS アカウントに CodeCommit リポジトリを保存します。このマルチアカウント設定は、リポジトリへのアクセスを制御し、リポジトリを誤って削除するリスクを軽減するのに役立ちます。クロスアカウントアクセス権の付与には、AWS Identity and Access Management (IAM) ロールを使用するのがベストプラクティスです。これにより、各 AWS アカウントの事前定義済みの IAM アイデンティティが一時的にロールを引き受け、アカウント間で制御された信頼の連鎖を構築できます。 **注記** 同様の手順を適用して、他の IAM アイデンティティに CodeCommit リポジトリへのクロスアカウントアクセスを許可できます。詳細については、「*AWS CodeCommit ユーザーガイド*」の「[ロールを使用して AWS CodeCommit リポジトリへのクロスアカウントアクセスを構成する](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html)」を参照してください。 ## 前提条件と制限 **前提条件** + CodeCommit リポジトリを持つアクティブな AWS アカウント (*アカウント A*) + SageMaker ノートブックインスタンスを持つ 2 つ目のアクティブな AWS アカウント (*アカウント B*) + アカウント A の IAM ロールを作成および変更するための十分な権限を持つ AWS ユーザー + アカウント B の IAM ロールを作成および変更するための十分な権限を持つ 2 人目の AWS ユーザー ## アーキテクチャ 以下の図は、SageMaker ノートブックインスタンスと 1 つの AWS アカウントのユーザーに CodeCommit リポジトリへのクロスアカウントアクセスを許可するワークフローの例を示しています。 ![\[CodeCommit へのクロスアカウントアクセスを許可するワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/54d0fdb3-6d25-4433-9f67-c87846633d61/images/97a799af-ce88-4495-a61c-d0cd22493ce2.png) この図表は、次のワークフローを示しています: 1. アカウント B の AWS ユーザーロールと SageMaker ノートブックインスタンスロールは、[名前付きプロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles)を前提としています。 1. 名前付きプロファイルのアクセス権限ポリシーは、プロファイルが引き受けるアカウント A の CodeCommit アクセスロールを指定します。 1. アカウント A の CodeCommit アクセスロールの信頼ポリシーにより、アカウント B の名前付きプロファイルが CodeCommit アクセスロールを引き受けます。 1. アカウント A の CodeCommit リポジトリの IAM アクセス権限ポリシーにより、CodeCommit アクセスロールは CodeCommit リポジトリにアクセスできます。 **テクノロジースタック** + CodeCommit + Git + IAM + pip + SageMaker ## ツール + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [Git](https://git-scm.com/) は、ソフトウェア開発中のソースコードの変更を追跡するための分散型バージョン管理システムです。 + [git-remote-codecommit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html) は、Git を拡張することにより、CodeCommit リポジトリからコードをプッシュおよびプルするための簡単な方法を提供するユーティリティです。 + [pip](https://pypi.org/project/pip/) は Python のパッケージインストーラです。pip を使用して Python Package インデックスやその他のインデックスからパッケージをインストールできます。 ## ベストプラクティス IAM ポリシーでアクセス許可を設定するときは、タスクの実行に必要なアクセス許可のみを付与するようにします。詳細については、IAM ドキュメントの「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。 このパターンを実装する場合は、必ず以下を実行してください。 + IAM プリンシパルには、各リポジトリ内で必要な特定のアクションを実行するための権限のみが含まれていることを確認してください。たとえば、承認された IAM プリンシパルは変更を特定のリポジトリブランチにプッシュしてマージすることを許可しますが、保護されたブランチへのマージのみを要求することが推奨されます。 + IAM プリンシパルには、各プロジェクトのそれぞれのロールと責任に基づいて異なる IAM ロールが割り当てられていることを確認してください。たとえば、開発者はリリースマネージャーや AWS 管理者とは異なるアクセス権限を持ちます。 ## エピック ### IAM ロールを構成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CodeCommit のアクセスロールと権限ポリシーを構成します。 | このエピックで説明されている手動設定プロセスを自動化するには、****[AWS CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)を使用します。CodeCommit リポジトリを含むアカウント (*アカウント A*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)ベストプラクティスは、この設定を本稼働環境に移行する前に、[最小特権アクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)を適用する独自の IAM ポリシーを作成することです。詳細については、このパターンの「**追加情報**」セクションを参照してください。 | AWS 全般、AWS DevOps | | アカウント B の SageMaker ノートブックインスタンスのロールに、アカウント A の CodeCommit アクセスロールを引き受ける権限を付与します。 | SageMaker ノートブックインスタンスの IAM ロールを含むアカウント (*アカウント B*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)注: リポジトリの Amazon リソースネーム (ARN) を表示するには、「*AWS CodeCommit ユーザーガイド*」の「[CodeCommit リポジトリの詳細を表示する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-view-repository-details.html)」を参照してください。 | AWS 全般、AWS DevOps | ### アカウント B に SageMaker ノートブックインスタンスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS SageMaker ノートブックインスタンスにユーザープロファイルを設定して、アカウント A のロールを引き受けます。 | [最新バージョンの AWS コマンドラインインターフェイス (AWS CLI) がインストールされていることを確認してください](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。SageMaker ノートブックインスタンスを含むアカウント (*アカウント B*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)
------.aws/config--------------
[profile remoterepouser]
role_arn = arn:aws:iam:::role/
role_session_name = remoteaccesssession
region = eu-west-1
credential_source  = Ec2InstanceMetadata
----------------------------------
| AWS 全般、AWS DevOps | | git-remote-codecommit ユーティリティをインストールします。 | 「*AWS CodeCommit ユーザーガイド*」の「[ステップ 2: git-remote-codecommit をインストールする](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html#setting-up-git-remote-codecommit-install)」の指示に従ってください。 | データサイエンティスト | ### リポジトリにアクセスする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Git コマンドまたは SageMaker を使用して CodeCommit リポジトリにアクセスする。 | **Git を使用するには**これで、アカウント B で SageMaker ノートブックインスタンスのロールを引き受ける IAM プリンシパルは、Git コマンドを実行してアカウント A の CodeCommit リポジトリにアクセスできるようになりました。たとえば、ユーザーは、`git clone`、`git pull`、`git push` などのコマンドを実行できます。手順については、「*AWS CodeCommit ユーザーガイド*」の「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」 を参照してください。CodeCommit で Git を使用する方法については、「*AWS CodeCommit ユーザーガイド*」の「[AWS CodeCommit 入門](https://docs.aws.amazon.com/codecommit/latest/userguide/getting-started-cc.html)」を参照してください。**SageMaker を使用するには**SageMaker コンソールから Git を使用するには、Git が CodeCommit リポジトリから認証情報を取得できるよう許可する必要があります。手順については、「SageMaker ドキュメント」の「[別の アカウントの CodeCommit リポジトリをノートブックインスタンスに関連付ける](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-git-cross.html)」を参照してください。 | Git、バッシュコンソール | ## 関連リソース + [ロールを使用して AWS CodeCommit リポジトリへのクロスアカウントアクセスを設定する](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) (AWS CodeCommit ドキュメント) + [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) (IAM ドキュメント) ## 追加情報 **CodeCommit 権限を特定のアクションに制限する** IAM プリンシパルが CodeCommit リポジトリで実行できるアクションを制限するには、CodeCommit アクセスポリシーで許可されているアクションを変更します。 CodeCommit API の操作の詳細については、「*AWS CodeCommit ユーザーガイド*」の「[CodeCommit アクセス権限リファレンス](https://docs.aws.amazon.com/codecommit/latest/userguide/auth-and-access-control-permissions-reference.html)」を参照してください。 **注記** [AWSCodeCommitPowerUser](https://docs.aws.amazon.com/codecommit/latest/userguide/security-iam-awsmanpol.html#managed-policies-poweruser) AWS マネージドポリシーをユースケースに合わせて編集することもできます。 **CodeCommit 権限を特定のリポジトリに制限する** 特定のユーザーだけが複数のコードリポジトリにアクセスできるマルチテナント環境を作成するには、次の操作を行います。 1. アカウント A に複数の CodeCommit アクセスロールを作成します。次に、アカウント B の特定のユーザーがロールを引き受けることができるように、各アクセスロールの信頼ポリシーを構成します。 1. 各 CodeCommit アクセスロールのポリシーに「**リソース**」条件を追加して、各ロールが引き受けることができるコードリポジトリを制限します。 **特定の CodeCommit リポジトリに対する IAM プリンシパルのアクセスを制限する「リソース」条件の例** ``` "Resource" : [, ] ``` **注記** 同じ AWS アカウント内の複数のコードリポジトリを識別して区別しやすくするために、リポジトリ名に異なるプレフィックスを割り当てることができます。たとえば、**myproject-subproject1-repo1** や **myproject-subproject2-repo1** など、異なる開発者グループに対応するプレフィックスを付けた名前をコードリポジトリに付けます。その後、割り当てられたプレフィックスに基づいて、開発者グループごとに IAM ロールを作成できます。たとえば、**myproject-subproject1-repoaccess** という名前のロールを作成し、**myproject-subproject1** というプレフィックスを含むすべてのコードリポジトリへのアクセスをそのロールに付与することができます。 **特定のプレフィックスを含むコードリポジトリ ARN を参照する「リソース」条件の例** ``` "Resource" : arn:aws:codecommit:::myproject-subproject1-* ``` # マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する *Amazon Web Services、Mike Stephens と Abhilash Vinod* ## 概要 ソースコードリポジトリを管理する場合、さまざまな分岐戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的な分岐戦略の例としては、Trunk、GitHub Flow、Gitflow などがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に GitHub フローブランチ戦略を実装するプロセスについて説明します。 このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。GitHub フローは、組織で使用できるブランチ戦略の 1 つです。このドキュメントシリーズでは、[トランク](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)および [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) ブランチモデルについても説明します。まだ確認していない場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適したブランチ戦略を選択してください。 このガイドでは、組織が GitHub フロー戦略を実装する方法を記した図を示します。「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各段階に推奨されるタスク、ステップ、制限が含まれます。 ## 前提条件と制限事項 **前提条件** + 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。 + Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、`feature` ブランチから本番環境へのデプロイまでを示します。 ![\[各ブランチと環境での GitHub フローアクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780a5bce-3cd2-4092-8537-b7a77c3d6b8d/images/8a2a774a-cd85-466e-838e-a9a1f3b58a63.png) GitHub Flow アプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach)」を参照してください。 **自動化とスケール** 継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。 AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。 ## ツール **AWS サービスとツール** AWS には、このパターンの実装に使用できる一連の開発者サービスが用意されています。 + スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 **その他のツール** + [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) は、フローチャートと図を作成するためのアプリケーションです。コードリポジトリには、Draw.io 用の .drawio 形式のテンプレートが格納されています。 + [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。 **コードリポジトリ** このパターンにおける図のソースファイルは、[Git Branching Strategy for GitHub Flow](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow) GitHub リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。 ## ベストプラクティス 「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、GitHub フローベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を高め、開発プロセスを合理化するのに役立ちます。 ## エピック ### GitHub フローワークフローの確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 標準の GitHub フロープロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | | バグ修正 GitHub フロープロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | | ホットフィックス GitHub フロープロセスを確認する。 | GitHub フローは、継続的な配信が可能になり、コードの変更が上位環境に頻繁かつ確実にデプロイされるように設計されています。重要なのは、すべての `feature` ブランチがいつでもデプロイ可能であることです。`Hotfix` ブランチは、`feature` ブランチや `bugfix` ブランチに似ていますが、これらの他のブランチと同じプロセスに従うことができます。ただし、緊急性を考慮すると、通常はホットフィックスの優先度が高くなります。チームのポリシーと状況の緊急性によっては、プロセスの特定のステップが迅速化される可能性があります。例えば、ホットフィックスのコードレビューは高速で追跡される場合があります。そのため、ホットフィックスプロセスでは機能プロセスとバグ修正プロセスが並列で扱われますが、ホットフィックスの緊急性により、手続きの遵守に変更が必要となる場合があります。ホットフィックスが効率的かつ安全に処理されるように、ホットフィックスの管理に関するガイドラインを確立することが重要です。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ブランチの競合 | GitHub フローモデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている `feature`、`bugfix`、または `hotfix` ブランチでもそれに対応する変更を適用する必要があるという状況です。`main` へのマージ時に大きな競合が発生するのを避けるため、`main` の変更を下位ブランチに頻繁にマージすることをお勧めします。 | | チームの成熟度 | GitHub フローは、真の継続的インテグレーションと継続的デリバリー (CI/CD) により、上位環境への日々のデプロイを促進します。機能を構築し、機能の自動化テストを作成するには、チームのエンジニアリングスキルが成熟している必要があります。チームは、変更が承認される前に、マージリクエストの詳細なレビューを実行する必要があります。これにより、開発プロセスの品質、説明責任、効率性を促進する堅牢なエンジニアリング文化が育まれます。 | ## 関連リソース このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。 以下のリソースは、 AWS クラウドで GitHub フローブランチを利用する際に役立ちます。 **AWS DevOps ガイダンス** + [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) + [AWS デプロイパイプラインリファレンスアーキテクチャ](https://pipelines.devops.aws.dev/) + [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/) + [DevOps リソース](https://aws.amazon.com/devops/resources/) **GitHub フローガイダンス** + [GitHub フローのクイックスタートチュートリアル](https://docs.github.com/en/get-started/using-github/github-flow) (GitHub) + [Why GitHub Flow?](https://githubflow.github.io/) **その他のリソース** + [Twelve-factor app methodology](https://12factor.net/) (12factor.net) # マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する *Amazon Web Services、Mike Stephens、Stephen DiCato、Abhilash Vinod、Tim Wondergem* ## 概要 ソースコードリポジトリを管理する場合、さまざまなブランチ戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的なブランチ戦略の例としては、トランク、Gitflow、GitHub フローなどがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に Gitflow ブランチ戦略を実装するプロセスについて説明します。 このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。Gitflow は、組織で使用できるブランチ戦略の 1 つです。このドキュメントシリーズでは、[トランク](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)および [GitHub フロー](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html)ブランチモデルについても説明します。まだ確認していない場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適したブランチ戦略を選択してください。 このガイドでは、組織が Gitflow 戦略を実装する方法を記した図を示します。「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各段階に推奨されるタスク、ステップ、制限が含まれます。 ## 前提条件と制限事項 **前提条件** + 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。 + Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。 + (オプション) Gitflow プラグインが[インストールされていること](https://github.com/nvie/gitflow)。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、feature ブランチから本番環境へのデプロイまでを示します。 ![\[各ブランチと環境での Gitflow アクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1dee2a06-cc54-4797-b9a9-78b6685edd33/images/d8be49bf-dca1-4892-ac4c-11996a7258c2.png) Gitflow アプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を参照してください。 **自動化とスケール** 継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。 AWS は、CI/CD パイプラインの構築を支援するように設計されたデベロッパーサービスのスイートを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。 ## ツール **AWS サービスとツール** AWS は、このパターンの実装に使用できる一連の開発者サービスを提供します。 + スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2)、オンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 **その他のツール** + [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) は、フローチャートと図を作成するためのアプリケーションです。コードリポジトリには、Draw.io 用の .drawio 形式のテンプレートが格納されています。 + [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。 + (オプション) [Gitflow プラグイン](https://github.com/nvie/gitflow)は、Gitflow ブランチモデルの高レベルのリポジトリオペレーションを提供する Git 拡張機能のコレクションです。 **コードリポジトリ** このパターンにおける図のソースファイルは、[Git Branching Strategy for GitFlow](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/gitflow) GitHub リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。 ## ベストプラクティス 「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、Gitflow ベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を高め、開発プロセスを合理化するのに役立ちます。 ## エピック ### Gitflow ワークフローの確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 標準の Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | | ホットフィックス Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | | バグ修正 Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ブランチの競合 | Gitflow モデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、別のブランチによって同じリソースが変更されている下位環境でもそれに対応する変更を適用する必要があるという状況です。有効にする release ブランチは一度に 1 つだけにすることをお勧めします。複数のブランチが同時に有効になっている場合、環境内での変更が衝突し、ブランチを本番環境に移行できない可能性があります。 | | マージ | リリースをメインにマージし、できるだけ早く開発して、作業をプライマリブランチに統合する必要があります。 | | スカッシュマージ | スカッシュマージは、`feature` ブランチから `develop` ブランチにマージする場合にのみ使用します。上位のブランチでスカッシュマージを使用すると、変更を下位のブランチに戻してマージする際に問題が発生します。 | ## 関連リソース このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。 以下のリソースは、 AWS クラウドで Gitflow ブランチを利用する際に役立ちます。 **AWS DevOps ガイダンス** + [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) + [AWS デプロイパイプラインリファレンスアーキテクチャ](https://pipelines.devops.aws.dev/) + [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/) + [DevOps リソース](https://aws.amazon.com/devops/resources/) **Gitflow ガイダンス** + [元の Gitflow ブログ](https://nvie.com/posts/a-successful-git-branching-model/) (Vincent Driessen 氏のブログ記事) + [Gitflow ワークフロー](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian) + [Gitflow on GitHub: How to use Git Flow workflows with GitHub Based Repos](https://youtu.be/WQuxeEvaCxs) (YouTube 動画) + [Git Flow Init Example](https://www.youtube.com/watch?v=d4cDLBFbekw) (YouTube 動画) + [The Gitflow Release Branch from Start to Finish](https://www.youtube.com/watch?v=rX80eKPdA28) (YouTube 動画) **その他のリソース** [Twelve-factor app methodology](https://12factor.net/) (12factor.net) # マルチアカウント DevOps 環境に Trunk 分岐戦略を実装する *Mike Stephens と Rayjan Wilson、Amazon Web Services* ## 概要 ソースコードリポジトリを管理する場合、さまざまな分岐戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的な分岐戦略の例としては、Trunk、GitHub Flow、Gitflow などがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に Trunk 分岐戦略を実装するプロセスについて説明します。 このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。Trunk は、組織で使用できる分岐戦略の 1 つです。このドキュメントシリーズでは、[GitHub Flow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) および [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) 分岐モデルについても説明します。確認がまだの場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適した分岐戦略を選択してください。 このガイドでは、組織が Trunk 戦略を実装する方法を記した図を示します。公式の「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各ステップのための推奨のタスク、ステップ、制限が含まれます。 ## 前提条件と制限事項 **前提条件** + 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。 + Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、`feature` ブランチから本番環境へのデプロイまでを案内します。 ![\[各ブランチと環境での Trunk アクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5df23e4d-84fe-4ab3-a54f-96b6406abc57/images/ad549ef4-90ad-47c1-bd01-f21d6ce5511a.png) トランクアプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach)」を参照してください。 **自動化とスケール** 継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。 AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。 ## ツール **AWS サービスとツール** AWS には、このパターンの実装に使用できる一連の開発者サービスが用意されています。 + スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 **その他のツール** + [Draw.io デスクトップ](https://github.com/jgraph/drawio-desktop/releases) – フローチャートと図を作成するためのアプリケーション。 + [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。 **コードリポジトリ** このパターンの図のソースファイルは、GitHub の「[Git Branching Strategy for Trunk](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/trunk)」リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。 ## ベストプラクティス 「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、Trunk ベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を向上させ、開発プロセスを合理化するのに役立ちます。 ## エピック ### Trunk のワークフローの確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 標準の Trunk プロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ブランチの競合 | Trunk モデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている `feature` ブランチでもそれに対応する変更を適用する必要があるという状況です。`main` へのマージ時に大きな競合が発生するのを避けるため、`main` の変更を下位ブランチに頻繁にマージすることをお勧めします。 | ## 関連リソース このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。 以下のリソースは、 AWS クラウドで Trunk 分岐を利用する際に役立ちます。 **AWS DevOps ガイダンス** + [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) + [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/) + [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/) + [DevOps リソース](https://aws.amazon.com/devops/resources/) **Trunk ガイダンス** + [Trunk Based Development](https://trunkbaseddevelopment.com/) **その他のリソース** + [Twelve-factor app methodology](https://12factor.net/) (12factor.net) # AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する *Benjamin Morris (Amazon Web Services)* ## 概要 このパターンは、1 つのリポジトリ内にカスタム Checkov ポリシーを作成し、このポリシーを GitHub 組織全体で再利用するための GitHub Actions フレームワークを提供します。このパターンに従うことにより、情報セキュリティチームは会社の要件に基づいてカスタムポリシーを記述、追加、維持できます。カスタムポリシーは、GitHub 組織内のすべてのパイプラインに自動的にプルされます。このアプローチを使用して、リソースをデプロイする前に、リソースに関する会社の標準を適用できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + GitHub Actions を使用する GitHub 組織 + AWS HashiCorp Terraform または AWS CloudFormation **制限事項** + このパターンは GitHub Actions 用に記述されています。ただし、GitLab など、同様の継続的インテグレーションおよび継続的デリバリー (CI/CD) フレームワークにも適応できます。GitHub の特定の有料バージョンは必要ありません。 + 一部の AWS のサービス は では使用できません AWS リージョン。リージョンの可用性については、 AWS ドキュメントの[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択します。 ## アーキテクチャ このパターンは、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを含む GitHub リポジトリとしてデプロイされるように設計されています。再利用可能なワークフローは、Terraform と CloudFormation のどちらの Infrastructure as Code (IaC) リポジトリでもスキャンできます。 次の図では、**再利用可能な GitHub ワークフローリポジトリ**と**カスタム Checkov ポリシーリポジトリ**を、それぞれ別のアイコンとして示しています。ただし、これらのリポジトリは個別のリポジトリとしても、単一のリポジトリとしても実装できます。サンプルコードでは 1 つのリポジトリを使用し、ワークフロー用のファイル (`.github/workflows`) とカスタムポリシー用のファイル (`custom_policies` フォルダと `.checkov.yml` 設定ファイル) を同一リポジトリ内に含めています。 ![\[GitHub Actions は、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを使用して IaC を評価します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png) この図表は、次のワークフローを示しています。 1. ユーザーが GitHub リポジトリにプルリクエストを作成します。 1. 再利用可能な Checkov ワークフローへの参照を含むパイプラインワークフローが GitHub Actions で開始されます。 1. パイプラインワークフローは、参照された再利用可能な Checkov ワークフローを外部リポジトリからダウンロードし、GitHub Actions を使用してこの Checkov ワークフローを実行します。 1. 再利用可能な Checkov ワークフローは、外部リポジトリからカスタムポリシーをダウンロードします。 1. 再利用可能な Checkov ワークフローは、組み込みの Checkov ポリシーとカスタム Checkov ポリシーの両方に照合して GitHub リポジトリの IaC を評価します。再利用可能な Checkov ワークフローは、セキュリティの問題が見つかったかどうかに基づいて合格または不合格になります。 **自動化とスケール** このパターンにより Checkov 設定を一元管理できるため、ポリシーの更新を 1 か所に適用するだけで済みます。ただし、このパターンでは、中央の再利用可能なワークフローへの参照を含むワークフローを、全リポジトリが使用する必要があります。この参照を手動で追加することも、スクリプトを使用して各リポジトリの `.github/workflows` フォルダにファイルをプッシュすることもできます。 ## ツール **AWS のサービス** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。Checkov は CloudFormation をスキャンできます。 **その他のツール** + [Checkov](https://www.checkov.io/) は、IaC のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。 + [GitHub Actions](https://github.com/features/actions) は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。 + [Terraform](https://www.terraform.io/) は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。Checkov は Terraform をスキャンできます。 **コードリポジトリ** このパターンのコードは、GitHub の [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast) リポジトリから入手できます。 ## ベストプラクティス + 一貫したセキュリティ体制を維持するには、会社のセキュリティポリシーと Checkov ポリシーの整合性を確保します。 + Checkov カスタムポリシーの実装の初期段階では、セキュリティ問題のある IaC もマージされるように、Checkov スキャンにソフトフェイルオプションを使用することもできます。プロセスが成熟したら、ソフトフェイルオプションからハードフェイルオプションに切り替えます。 ## エピック ### カスタムポリシー用の中央 Checkov リポジトリを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 中央の Checkov リポジトリを作成 | 組織内で使用されるカスタム Checkov ポリシーを保存するためのリポジトリを作成します。クイックスタートとして、このパターンの GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)リポジトリの内容を、中央の Checkov リポジトリにコピーできます。 | DevOps エンジニア | | 再利用可能なワークフロー用のリポジトリを作成 | 再利用可能なワークフロー用のリポジトリが既に存在する場合、またはカスタム Checkov ポリシーと同じリポジトリに再利用可能なワークフローファイルを保存する場合は、このステップをスキップできます。再利用可能なワークフローを保持する GitHub リポジトリを作成します。このリポジトリは、他のリポジトリのパイプラインから参照されます。 | DevOps エンジニア | ### 再利用可能なサンプル Checkov ワークフローを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 再利用可能な Checkov ワークフローを追加する | 再利用可能なワークフローリポジトリ内に、再利用可能な Checkov GitHub Actions ワークフロー (YAML ファイル) を作成します。この再利用可能なワークフローは、このパターンで提供されているワークフローファイルを基に作成できます。変更の例として、ソフトフェイルオプションを使用するように再利用可能なワークフローを変更することが挙げられます。`soft-fail` を `true` に設定すると、Checkov スキャンが失敗した場合でもジョブを正常に完了できます。手順については、Checkov ドキュメントの「[Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)」を参照してください。 | DevOps エンジニア | | ワークフローの例を追加する | `reusable` ワークフローを参照するサンプル Checkov ワークフローを追加します。これにより、`reusable` ワークフローを再利用するためのテンプレートが提供されます。サンプルリポジトリでは、`checkov-source.yaml` は再利用可能なワークフローであり、`checkov-scan.yaml` は `checkov-source` を利用するサンプルです。サンプル Checkov ワークフローの記述方法の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。 | DevOps エンジニア | ### 企業ポリシーを Checkov カスタムポリシーに関連付ける | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Checkov によって適用可能なポリシーを決定する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Checkov カスタムポリシーの作成方法の詳細については、Checkov ドキュメントの「[Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)」を参照してください。 | セキュリティおよびコンプライアンス | | Checkov カスタムポリシーを追加する | 特定した企業ポリシーを、中央リポジトリのカスタム Checkov ポリシーに変換します。Python または YAML を使用して、シンプルな Checkov ポリシーを記述できます。 | セキュリティ | ### 一元化された Checkov カスタムポリシーを実装する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Checkov の再利用可能なワークフローをすべてのリポジトリに追加する | この時点で、再利用可能なワークフローを参照するサンプル Checkov ワークフローが必要となります。再利用可能なワークフローを参照するサンプル Checkov ワークフローを、これを必要とする各リポジトリにコピーします。 | DevOps エンジニア | | マージ前に Checkov が実行されるようにメカニズムを作成する | プルリクエストごとに Checkov ワークフローが実行されるようにするには、Checkov ワークフローが成功した場合にのみプルリクエストをマージするための[ステータスチェック](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)を作成します。GitHub では、プルリクエストをマージする前に特定のワークフローが実行されるように指定できます。 | DevOps エンジニア | | 組織全体の PAT を作成し、シークレットとして共有する | GitHub 組織が公開されている場合は、このステップをスキップできます。このパターンでは、Checkov ワークフローが、GitHub 組織のカスタムポリシーリポジトリからカスタムポリシーをダウンロードできる必要があります。Checkov ワークフローがこれらのリポジトリにアクセスできるように、必要なアクセス許可を付与する必要があります。これには、組織リポジトリを読み取るアクセス許可を持つ[個人用アクセストークン (PAT) を作成](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token)します。この PAT を、組織全体のシークレット (有料プランの場合) または各リポジトリのシークレット (無料版の場合) として、各リポジトリと共有します。サンプルコードでは、シークレットのデフォルト名は `ORG_PAT` です。 | DevOps エンジニア | | (オプション) Checkov ワークフローファイルを変更から保護する | Checkov ワークフローファイルを不要な変更から保護するには、`CODEOWNERS` ファイルを使用します。`CODEOWNERS` ファイルは通常、ディレクトリのルートにデプロイされます。例えば、`checkov-scan.yaml` ファイルの変更時に GitHub 組織の `secEng` グループからの承認が必要となるように設定するには、リポジトリの `CODEOWNERS` ファイルに以下を追加します。
[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
`CODEOWNERS` ファイルは、ファイルが存在するリポジトリに固有です。リポジトリで使用される Checkov ワークフローを保護するには、各リポジトリに `CODEOWNERS` ファイルを追加 (または更新) する必要があります。Checkov ワークフローファイルの保護の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。`CODEOWNERS` ファイルの詳細については、CI/CD プロバイダー ([GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) など) の公式ドキュメントを参照してください。 | DevOps エンジニア | ## 関連リソース + [Checkov Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) + [CloudFormation Configuration Scanning](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html) + [GitHub Actions Reusable Workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) ## 追加情報 **Checkov ワークフローファイルの記述** `checkov-scan.yaml` を記述する場合は、このファイルをいつ実行するかを検討してください。最上位の `on` キーは、ワークフローの実行時を決定します。サンプルリポジトリでは、`main` ブランチをターゲットとするプルリクエストがあった場合 (およびプルリクエストのソースブランチが変更された場合) に、ワークフローが実行されます。ワークフローは、`workflow_dispatch` キーによって必要とされる時点で実行することもできます。 ワークフローのトリガー条件は、ワークフローを実行する頻度に応じて変更できます。例えば、`pull_request` を `push` に置き換えて `branches` キーを削除することにより、いずれかのブランチにコードがプッシュされるたびにワークフローが実行されるように変更できます。 個々のリポジトリ内で作成したサンプルワークフローファイルを変更できます。例えば、リポジトリが `production` ブランチを中心に構造化されている場合は、ターゲットブランチの名前を `main` から `production` に変更して調整できます。 **Checkov ワークフローファイルの保護** Checkov スキャンを実行することにより、潜在的なセキュリティ設定ミスに関する有用な情報が得られます。しかし、デベロッパーによってはこのスキャンが生産性の障壁のように感じられ、スキャンワークフローを削除または無効にしようとする場合があります。 この問題にはいくつかの対処方法が考えられます。例えば、セキュリティスキャンの長期的な価値を伝える的確なメッセージを発信したり、安全なインフラストラクチャのデプロイ方法を明確に規定するドキュメントを整備したりします。こうした方法は、DevSecOps コラボレーションに対する重要な「ソフト」アプローチであり、この問題の根本原因の解決策とみなすことができます。ただし、デベロッパーを適切な方向に誘導するためのガードレールとして、`CODEOWNERS` ファイルなどの技術的な制御を使用することもできます。 **サンドボックスでのパターンのテスト** サンドボックス環境でこのパターンをテストするには、次の手順に従います。 1. 新しい GitHub 組織を作成します。組織内のすべてのリポジトリに対する読み取り専用アクセス権を持つトークンを作成します。このトークンは有料環境ではなくサンドボックス環境用であるため、このトークンを組織全体のシークレットに保存することはできません。 1. Checkov 設定を保持する `checkov` リポジトリと、再利用可能なワークフロー設定を保持する `github-workflows` リポジトリを作成します。各リポジトリに、サンプルリポジトリの内容を入力します。 1. アプリケーションリポジトリを作成し、`checkov-scan.yaml` ワークフローをコピーして、その `.github/workflows` フォルダに貼り付けます。組織の読み取り専用アクセス用に作成した PAT を含むシークレットをリポジトリに追加します。デフォルトのシークレットは `ORG_PAT` です。 1. Terraform または CloudFormation コードをアプリケーションリポジトリに追加するプルリクエストを作成します。Checkov スキャンを実行し、その結果が返される必要があります。 # K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する *Amazon Web Services、Ishwar Chauthaiwale、Muskan、Prafful Gupta* ## 概要 このパターンでは、K8sGPT を Amazon Bedrock で利用可能な Anthropic Claude v2 モデルと統合することで、AI を活用した Kubernetes の診断とトラブルシューティングを実装する方法を示します。このソリューションは、安全な踏み台ホストアーキテクチャを通じて、Kubernetes クラスターの問題に対する自然言語分析と修復手順を提供します。K8sGPT Kubernetes の専門知識と Amazon Bedrock の高度な言語機能を組み合わせることで、DevOps チームはクラスターの問題をすばやく特定して解決することができます。これらの機能により、平均解決時間 (MTTR) を最大 50% 短縮できます。 このクラウドネイティブのパターンでは、Kubernetes の管理のために Amazon Elastic Kubernetes Service (Amazon EKS) を使用します。このパターンは、適切な AWS Identity and Access Management (IAM) ロールとネットワーク分離を通じてセキュリティのベストプラクティスを実装します。このソリューションは、Kubernetes のオペレーションを合理化し、AI の支援によりトラブルシューティング機能を強化することを求めている組織にとって特に価値があります。 ## 前提条件と制限 **前提条件** + 適切なアクセス許可 AWS アカウント を持つアクティブな + 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) + Amazon EKS クラスター + [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html) での Anthropic Claude 2 モデルへのアクセス + 必要なセキュリティグループが設定された踏み台ホスト + K8sGPT が[インストールされていること](https://docs.k8sgpt.ai/getting-started/installation/) **制限事項** + K8sGPT 分析は、Claude v2 モデルのコンテキストウィンドウサイズによって制限されます。 + Amazon Bedrock API レート制限は、アカウントのクォータに基づいて適用されます。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + Amazon EKS [バージョン 1.31 以降](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) + Amazon Bedrock 上の [Claude 2 モデル](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) + K8sGPT [v0.4.2 以降](https://github.com/k8sgpt-ai/k8sgpt/releases) ## アーキテクチャ 次の図に、 AWS クラウドの Amazon Bedrock と統合された K8sGPT を使用した AI 活用 Kubernetes 診断のためのアーキテクチャを示します。 ![\[Amazon Bedrock と統合された K8sGPT を使用した Kubernetes 診断のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/09bc08f6-e191-4cef-b26b-dcb6225b15cc/images/8789891d-4a90-44b0-a108-387f6d96496b.png) アーキテクチャは以下のワークフローを示しています。 1. 開発者が、踏み台ホストへの安全な接続を介して環境にアクセスします。この Amazon EC2 インスタンスは安全なエントリポイントとして機能し、K8sGPT コマンドラインインターフェイス (CLI) のインストールと必要な設定が格納されています。 1. 特定の IAM ロールで設定された踏み台ホストが、Amazon EKS クラスターと Amazon Bedrock エンドポイントの両方への安全な接続を確立します。K8sGPT は Kubernetes クラスター分析を実行するための踏み台ホストにインストールされ、設定されます。 1. Amazon EKS が Kubernetes コントロールプレーンとワーカーノードを管理し、K8sGPT 分析のターゲット環境を提供します。このサービスは、仮想プライベートクラウド (VPC) 内の複数のアベイラビリティーゾーンで実行され、高可用性と耐障害性を提供するのに役立ちます。Amazon EKS が Kubernetes API を通じて運用データを提供し、包括的なクラスター分析を可能にします。 1. K8sGPT が分析データを Amazon Bedrock に送信します。Amazon Bedrock は、自然言語処理用の Claude v2 基盤モデル (FM) を備えています。このサービスは K8sGPT 分析を処理して人間が読める説明を生成し、特定された問題に基づいて詳細な修復の提案を示します。Amazon Bedrock は、高可用性とスケーラビリティを備えたサーバーレス AI サービスとして動作します。 **注記** このワークフロー全体で、IAM はロールとポリシーを通じてコンポーネント間のアクセスを制御し、踏み台ホスト、Amazon EKS、Amazon Bedrock インタラクションの認証を管理します。IAM は最小特権の原則を実装し、アーキテクチャ全体で安全なクロスサービス通信を可能にします。 **自動化とスケール** K8sGPT オペレーションは、さまざまな およびツールを使用して、複数の Amazon EKS クラスターにまたがって自動化 AWS のサービス およびスケーリングできます。このソリューションは、スケジュールされた分析のために、[Jenkins](https://www.jenkins.io/)、[GitHub Actions](https://docs.github.com/en/actions/get-started/understand-github-actions)、または [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) を使用した継続的インテグレーションと継続的デプロイ (CI/CD) 統合をサポートします。K8sGPT Operator は、自動問題検出およびレポート機能を使用して、クラスター内の継続的なモニタリングを可能にします。エンタープライズ規模のデプロイでは、[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) を使用してスキャンをスケジュールし、カスタムスクリプトで自動レスポンスをトリガーできます。 AWS SDK 統合により、大規模なクラスターフリートをプログラムで制御できます。 ## ツール **AWS サービス** + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 **その他のツール** + [K8sGPT](https://k8sgpt.ai/) は、Kubernetes 管理を変革するオープンソースの AI 搭載ツールです。仮想サイト信頼性エンジニアリング (SRE) のエキスパートとして機能し、Kubernetes クラスターの問題を自動的にスキャン、診断、トラブルシューティングします。管理者は自然言語を使用して K8sGPT を操作し、クラスターの状態、ポッドのクラッシュ、サービス障害に関する明確で実用的なインサイトを得ることができます。ツールの組み込みアナライザーは、コンポーネントの設定ミスからリソースの制約まで、幅広い問題を検出し、わかりやすい説明とソリューションを提供します。 ## ベストプラクティス + 踏み台ホストアクセス AWS Systems Manager Session Manager に を使用して、安全なアクセスコントロールを実装します。 [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) + K8sGPT 認証で、Amazon Bedrock および Amazon EKS インタラクション用の最小特権のアクセス許可を持つ専用の IAM ロールを使用していることを確認します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 + [リソースへのタグ付け](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html)を設定し、Amazon CloudWatch の[監査証跡のログ記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)を有効にして、機密情報の[データ匿名化](https://aws.amazon.com/solutions/guidance/data-anonymization-on-aws/)を実装します。 + K8sGPT 設定の定期的なバックアップを維持しながら、オフピーク時に自動スキャンスケジュールを設定して、運用への影響を最小限に抑えます。 ## エピック ### Amazon Bedrock を AI バックエンドプロバイダーリストに追加する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Bedrock を K8sGPT の AI バックエンドプロバイダーとして設定する。 | Amazon Bedrock を K8sGPT 用の AI [バックエンド provide](https://docs.k8sgpt.ai/reference/providers/backend/) r として設定するには、次の AWS CLI コマンドを使用します。
k8sgpt auth add -b amazonbedrock \
 -r us-west-2 \
 -m anthropic.claude-v2 \
 -n endpoint-name
コマンド例では、 AWS リージョンに `us-west-2` を使用します。ただし、Amazon EKS クラスターとそれに対応する Amazon Bedrock モデルの両方がその選択したリージョンで使用可能であり有効になっている場合は、別のリージョンを選択できます。`amazonbedrock` が AI バックエンドプロバイダーリストに追加されていて、`Active` 状態であることを確認するには、次のコマンドを実行します。
k8sgpt auth list
以下に、このコマンドを実行したときの出力の例を示します。
Default: 
> openai
Active: 
> amazonbedrock
Unused: 
> openai
> localai
> ollama
> azureopenai
> cohere
> amazonsagemaker
> google
> noopai
> huggingface
> googlevertexai
> oci
> customrest
> ibmwatsonxai
| AWS DevOps | ### フィルターを使用してリソースをスキャンする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 使用可能なフィルターのリストを表示する。 | 使用可能なすべてのフィルターのリストを表示するには、次の AWS CLI コマンドを使用します。
k8sgpt filters list
以下に、このコマンドを実行したときの出力の例を示します。
Active: 
> Deployment
> ReplicaSet
> PersistentVolumeClaim
> Service
> CronJob
> Node
> MutatingWebhookConfiguration
> Pod
> Ingress
> StatefulSet
> ValidatingWebhookConfiguration
| AWS DevOps | | フィルターを使用して、特定の名前空間のポッドをスキャンする。 | このコマンドは、Kubernetes クラスター内の特定ポッドの問題に対するターゲットを絞ったデバッグに役立ち、Amazon Bedrock AI 機能を使用して、検出された問題を分析および説明します。フィルターを使用して特定の名前空間のポッドをスキャンするには、次の AWS CLI コマンドを使用します。
k8sgpt analyze --backend amazonbedrock --explain --filter Pod -n default
以下に、このコマンドを実行したときの出力の例を示します。
100% |████████████████████████████████████████████████████████| (1/1, 645 it/s)        
AI Provider: amazonbedrock

0: Pod default/crashme()
- Error: the last termination reason is Error container=crashme pod=crashme
Error: The pod named crashme terminated because the container named crashme crashed.
Solution: Check logs for crashme pod to identify reason for crash. Restart pod or redeploy application to resolve crash.
| AWS DevOps | | フィルターを使用して、特定の名前空間のデプロイをスキャンする。 | このコマンドは、特に実際の状態が目的の状態と一致しない場合に、デプロイ固有の問題を特定してトラブルシューティングするのに役立ちます。フィルターを使用して特定の名前空間のデプロイをスキャンするには、次の AWS CLI コマンドを使用します。
k8sgpt analyze --backend amazonbedrock --explain --filter Deployment -n default
以下に、このコマンドを実行したときの出力の例を示します。
100% |██████████████████████████████████████████████████████████| (1/1, 10 it/min)        
AI Provider: amazonbedrock

0: Deployment default/nginx()
- Error: Deployment default/nginx has 1 replicas but 2 are available
 Error: The Deployment named nginx in the default namespace has 1 replica specified but 2 pod replicas are running.
Solution: Check if any other controllers like ReplicaSet or StatefulSet have created extra pods. Delete extra pods or adjust replica count to match available pods.
| AWS DevOps | | フィルターを使用して、特定の名前空間のノードをスキャンする。 | フィルターを使用して特定の名前空間のノードをスキャンするには、次の AWS CLI コマンドを使用します。
k8sgpt analyze --backend amazonbedrock --explain --filter Node -n default
以下に、このコマンドを実行したときの出力の例を示します。
AI Provider: amazonbedrock

No problems detected
| AWS DevOps | ### 詳細な出力を分析する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 詳細な出力を取得する。 | 詳細な出力を取得するには、次の AWS CLI コマンドを使用します。
k8sgpt analyze --backend amazonbedrock --explain --ouput json
以下に、このコマンドを実行したときの出力の例を示します。
{
  "provider": "amazonbedrock",
  "errors": null,
  "status": "ProblemDetected",
  "problems": 1,
  "results": [
    {
      "kind": "Pod",
      "name": "default/crashme",
      "error": [
        {
          "Text": "the last termination reason is Error container=crashme pod=crashme",
          "KubernetesDoc": "",
          "Sensitive": []
        }
      ],
      "details": " Error: The pod named crashme terminated because the container named crashme crashed.\nSolution: Check logs for crashme pod to identify reason for crash. Restart pod or redeploy application to resolve crash.",
      "parentObject": ""
    }
  ]
}
| AWS DevOps | | 問題のあるポッドを確認する。 | 特定の問題のあるポッドを確認するには、次の AWS CLI コマンドを使用します。
kubectl get pods --all-namespaces | grep -v Running
以下に、このコマンドを実行したときの出力の例を示します。
NAMESPACE    NAME      READY    STATUS          RESTARTS      AGE                                       
default     crashme     0/1   CrashLoopBackOff   260(91s ago)   21h
| AWS DevOps | | アプリケーション固有のインサイトを取得する。 | このコマンドは、特に次の場合に便利です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.html)アプリケーション固有のインサイトを取得するには、次のコマンドを実行します。
k8sgpt analyze --backend amazonbedrock --explain -L app=nginx -n default
以下に、このコマンドを実行したときの出力の例を示します。
AI Provider: amazonbedrock

No problems detected
| | ## 関連リソース **AWS ブログ** + [Automate Amazon EKS troubleshooting using an Amazon Bedrock agentic workflow](https://aws.amazon.com/blogs/machine-learning/automate-amazon-eks-troubleshooting-using-an-amazon-bedrock-agentic-workflow/) + [Use K8sGPT and Amazon Bedrock for simplified Kubernetes cluster maintenance](https://aws.amazon.com/blogs/machine-learning/use-k8sgpt-and-amazon-bedrock-for-simplified-kubernetes-cluster-maintenance/) **AWS ドキュメント** + AWS CLI コマンド: [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html) および [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-cluster.html) + [Amazon EKS の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) (Amazon EKS ドキュメント) + [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM ドキュメント) **その他のリソース** + [K8sGPT](https://k8sgpt.ai/) # CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する *Helton ribeiro、Petrus Batalha、Ricardo Morais (Amazon Web Services)* ## 概要 **注意**: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/) このパターンは、 でモノレポベースのアプリケーションのソースコードの変更を自動的に検出し AWS CodeCommit 、マイクロサービスごとに継続的インテグレーションと継続的デリバリー (CI/CD) オートメーション AWS CodePipeline を実行するパイプラインを で開始するのに役立ちます。このアプローチは、モノレポベースのアプリケーション内の各マイクロサービスに専用の CI/CD パイプラインを持たせることができることを意味します。これにより、可視性が向上し、コードの共有が容易になり、コラボレーション、標準化、発見が容易になります。 このパターンで説明されているソリューションは、モノレポ内のマイクロサービス間での依存関係分析を実行しません。ソースコードの変更のみを検出し、一致する CI/CD パイプラインを開始します。 このパターンでは、 を統合開発環境 (IDE) AWS Cloud9 として使用し AWS Cloud Development Kit (AWS CDK) 、 `MonoRepoStack`と の 2 つの CloudFormation スタックを使用してインフラストラクチャを定義します`PipelinesStack`。`MonoRepoStack` スタックは、 にモノレポ AWS CodeCommit を作成し、CI/CD パイプラインを開始する AWS Lambda 関数を作成します。`PipelinesStack` スタックはパイプラインインフラストラクチャを定義します。 **重要** このパターンのワークフローは概念実証 (PoC) です。テスト環境でのみ使用することをお勧めします。このパターンのアプローチを本番環境で使用する場合は、 AWS Identity and Access Management ([IAM) ドキュメントの「IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照して、IAM ロールと に必要な変更を加えます AWS のサービス。  ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + AWS Command Line Interface (AWS CLI)、インストールおよび設定済み。詳細については、 AWS CLI ドキュメント[AWS CLIの「 のインストール、更新、アンインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。  + ローカルマシンにインストール済みの Python 3 と `pip`。詳細については、[Python のドキュメント](https://www.python.org/)を参照してください。  + AWS CDKがインストールされ設定済みであること。詳細については、 AWS CDK ドキュメントの[「Getting started with the AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」を参照してください。  + IDE AWS Cloud9 がインストールされ、設定されています。詳細については、 AWS Cloud9 ドキュメントの[「セットアップ AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/setting-up.html)」を参照してください。  + GitHub の [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger)リポジトリが、ローカルマシンでクローン済み。  + CodePipeline でビルドしてデプロイするアプリケーションコードを含む既存のディレクトリ。 + AWS クラウドでの DevOps のベストプラクティスに関する知識と経験。DevOps の知識を高めるには、 パターンを使用します。[DevOps プラクティスと 規範ガイダンスウェブサイトを使用して、マイクロサービスと疎結合アーキテクチャを構築 AWS Cloud9](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/build-a-loosely-coupled-architecture-with-microservices-using-devops-practices-and-aws-cloud9.html)します。 AWS   ## アーキテクチャ 次の図は、 を使用して、 `MonoRepoStack`と の 2 つの AWS CloudFormation スタックを持つインフラストラクチャ AWS CDK を定義する方法を示しています`PipelinesStack`。 ![\[AWS CDK を使用して 2 つの CloudFormation スタックを持つインフラストラクチャを定義するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a3397158-a208-4033-844e-969af13ae8b6/images/b0bb1094-b598-4b3d-ab8b-ad9b0eb45f38.png) この図表は、次のワークフローを示しています: 1. ブートストラッププロセスでは、 AWS CDK を使用して AWS CloudFormation スタック`MonoRepoStack`と を作成します`PipelinesStack`。 1. `MonoRepoStack` スタックは、アプリケーション用の CodeCommit リポジトリと、各コミットの後に開始される `monorepo-event-handler` Lambda 関数を作成します。 1. `PipelinesStack` スタックは、Lambda 関数によって開始されるパイプラインを CodePipeline に作成します。各マイクロサービスにはインフラストラクチャパイプラインが定義されている必要があります。 1. `microservice-n` のパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。 1. `microservice-1` のパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。 次の図は、 アカウント`PipelinesStack`での AWS CloudFormation スタック`MonoRepoStack`と のデプロイを示しています。 ![\[CloudFormation スタック MonoRepoStack と PipelinesStack の AWS アカウントへのデプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a3397158-a208-4033-844e-969af13ae8b6/images/39e60e49-dea2-486d-8a2c-6cae438f69b4.png) 1. ユーザーがアプリケーションのマイクロサービスの 1 つでコードを変更します。 1. ユーザーは、ローカルリポジトリから CodeCommit リポジトリに変更をプッシュします。 1. プッシュアクティビティは、CodeCommit リポジトリへのすべてのプッシュを受け取る Lambda 関数を開始します。 1. Lambda 関数は、 AWS Systems Managerの機能として Parameter Store のパラメータを読み取り、最新のコミット ID を取得します。パラメータには `/MonoRepoTrigger/{repository}/{branch_name}/LastCommit` 命名形式があります。パラメータが見つからない場合、Lambda 関数は CodeCommit リポジトリから最後のコミット ID を読み取り、戻り値をパラメータストアに保存します。 1. コミット ID と変更されたファイルを特定すると、Lambda 関数は各マイクロサービスディレクトリのパイプラインを識別し、必要な CodePipeline パイプラインを開始します。 ## ツール + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするためのソフトウェア開発フレームワークです CloudFormation。 + [Python](https://www.python.org/) は、すばやく作業し、システムをより効果的に統合できるプログラミング言語です。 **コード** このパターンのソースコードとテンプレートは、GitHub の [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger) リポジトリにあります。 ## ベストプラクティス + このサンプルアーキテクチャには、デプロイされたインフラストラクチャのモニタリングソリューションは含まれていません。このソリューションを本番環境にデプロイしたい場合は、モニタリングを有効にすることをお勧めします。詳細については、 AWS Serverless Application Model (AWS SAM) ドキュメントの[CloudWatch Application Insights を使用してサーバーレスアプリケーションをモニタリングする](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/monitor-app-insights.html)」を参照してください。 + このパターンで提供されるサンプルコードを編集するときは、 AWS CDK ドキュメントの[クラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)に従ってください。 + マイクロサービスパイプラインを定義するときは、 AWS CodePipeline ドキュメント[のセキュリティのベストプラクティス](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)を確認してください。 + [cdk-nag](https://github.com/cdklabs/cdk-nag) ユーティリティを使用して AWS CDK 、コードのベストプラクティスを確認することもできます。このツールは、パックごとにグループ化された一連のルールを使用してコードを評価します。使用可能なパックは次のとおりです。 + [AWS ソリューションライブラリ](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#awssolutions) + [医療保険の相互運用性と責任に関する法律 (HIPAA) セキュリティ](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#hipaa-security) + [米国国立標準技術研究所 (NIST) 800-53 リビジョン 4](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#nist-800-53-rev-4) + [NIST 800-53 rev 5](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#nist-800-53-rev-5) + [Payment Card Industry Data Security Standard (PCI DSS) 3.2.1](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#pci-dss-321) ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 仮想 Python 環境を作成します。 | AWS Cloud9 IDE で、仮想 Python 環境を作成し、次のコマンドを実行して必要な依存関係をインストールします。`make install` | 開発者 | | の AWS アカウント と AWS リージョン をブートストラップします AWS CDK。 | 次のコマンドを実行して、必要な AWS アカウント とリージョンをブートストラップします。`make bootstrap account-id= region=` | 開発者 | ### マイクロサービス用の新しいパイプラインの追加 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプルコードをアプリケーションディレクトリに追加します。 | サンプルアプリケーションコードを含むディレクトリを、複製された GitHub [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger) リポジトリ内の `monorepo-sample` ディレクトリに追加します。 | 開発者 | | `monorepo-main.json` ファイルを編集します。 | アプリケーションのコードのディレクトリ名とパイプラインの名前を、複製されたリポジトリ内の `monorepo-main.json` ファイルに追加します。 | 開発者 | | パイプラインを作成します。 | リポジトリの `Pipelines` ディレクトリに、アプリケーションのパイプライン `class` を追加します。ディレクトリには、`pipeline_hotsite.py` と `pipeline_demo.py` の 2 つのサンプルファイルが含まれています。各ファイルには、ソース、ビルド、デプロイの 3 つのステージがあります。ファイルの 1 つをコピーして、アプリケーションの要件に応じて変更を加えることができます。  | 開発者 | | `monorepo_config.py` ファイルを編集します。 | `service_map` に、アプリケーションのディレクトリ名と、パイプライン用に作成したクラスを追加します。例えば、次のコードは、`MySamplePipeline`クラスで `pipeline_mysample.py` と名前が付けられたファイルを使用する `Pipelines` ディレクトリ内のパイプライン定義を示しています。
...
# Pipeline definition imports
from pipelines.pipeline_demo import DemoPipeline
from pipelines.pipeline_hotsite import HotsitePipeline
from pipelines.pipeline_mysample import MySamplePipeline

### Add your pipeline configuration here
service_map: Dict[str, ServicePipeline]  = {
    # folder-name -> pipeline-class
    'demo': DemoPipeline(),
    'hotsite': HotsitePipeline(),
    'mysample': MySamplePipeline()
}
| 開発者 | ### MonorePostack スタックをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックをデプロイします。 | `make deploy-core` コマンドを実行して、 AWS CloudFormation `MonoRepoStack`デフォルトのパラメータ値を持つスタックをクローンされたリポジトリのルートディレクトリにデプロイします。リポジトリの名前は、`make deploy-core monorepo-name=` コマンドを実行して変更できます。`make deploy monorepo-name=` コマンドを使用すると、両方のパイプラインを同時にデプロイできます。 | 開発者 | | CodeCommit リポジトリを検証します。 | `aws codecommit get-repository --repository-name ` コマンドを実行して、リソースが作成されたことを確認します。 CloudFormation スタックはモノレポが保存されている CodeCommit リポジトリを作成するため、変更のプッシュを開始した場合は`cdk destroy MonoRepoStack `コマンドを実行しないでください。 | 開発者 | | CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 CloudFormation `MonoRepoStack`スタックが正しく作成および設定されていることを確認します。
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
| 開発者 | ### PipelinesStack スタックをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックをデプロイします。 | AWS CloudFormation `PipelinesStack` スタックは、スタックをデプロイした後にデプロイする必要があります`MonoRepoStack`。monorepo のコードベースに新しいマイクロサービスが追加されるとスタックのサイズが大きくなり、新しいマイクロサービスが導入されるとスタックが再デプロイされます。`make deploy-pipelines` コマンドを実行して PipelinesStack スタックをデプロイします。`make deploy monorepo-name=` コマンドを実行して、両方のパイプラインを同時にデプロイすることもできます。以下の出力例は、実装の最後に `PipelinesStacks` デプロイメントによってマイクロサービスの URL がどのように出力されるかを示しています。
Outputs:
PipelinesStack.demourl = .cloudfront.net
PipelinesStack.hotsiteurl = .cloudfront.net
| 開発者 | | AWS CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 AWS CloudFormation `PipelinesStacks`スタックが正しく作成および設定されていることを確認します。
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
| 開発者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックを削除します。 | `make destroy` コマンドを実行します。 | 開発者 | | パイプラインの S3 バケットを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) | 開発者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS CDK 問題が発生しました。 | AWS CDK ドキュメントの「一般的な[AWS CDK 問題のトラブルシューティング](https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html)」を参照してください。 | | マイクロサービスコードをプッシュしましたが、マイクロサービスパイプラインは実行されませんでした。 | **セットアップの検証***ブランチ設定を確認します。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)*設定ファイルを検証します。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)**コンソールでのトラブルシューティング***AWS CodePipeline は以下をチェックします。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)*AWS Lambda トラブルシューティング:*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) | | すべてのマイクロサービスを再デプロイする必要があります。 | すべてのマイクロサービスの再デプロイを強制するためには、2 つのアプローチがあります。要件に合ったオプションを選択してください。**アプローチ 1: Parameter Store でパラメータを削除する**このメソッドでは、デプロイに使用された最後のコミット ID を追跡する Systems Manager Parameter Store 内の特定のパラメータを削除します。このパラメータを削除すると、システムは新しい状態として認識するため、次のトリガーですべてのマイクロサービスを強制的に再デプロイします。手順:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)メリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)デメリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)**アプローチ 2: 各モノレポサブフォルダにコミットをプッシュする**この方法では、マイナーな変更を行い、モノレポ内の各マイクロサービスサブフォルダにプッシュし、個々のパイプラインを開始します。手順:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)メリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)デメリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) | ## 関連リソース + [CDK Pipelines を使用した継続的な統合と配信 (CI/CD)](https://docs.aws.amazon.com/cdk/latest/guide/cdk_pipeline.html) (AWS CDK ドキュメント) + [aws-cdk/pipelines モジュール](https://docs.aws.amazon.com/cdk/api/latest/docs/pipelines-readme.html) (AWS CDK API リファレンス) # AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合する *Amazon Web Services、Alwin Abraham* ## 概要 AWS Amplify を使用すると、通常必要なインフラストラクチャをセットアップしなくても、静的ウェブサイトを迅速にデプロイしてテストできます。既存のアプリケーションコードを移行する場合でも、新しいアプリケーションを構築する場合でも、組織が Bitbucket をソース管理に使用したい場合は、このパターンのアプローチを導入できます。AWS CloudFormation を使用して Amplify を自動的にセットアップすることで、使用している設定を可視化できます。 AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合することで、フロントエンド CI/CD パイプラインとデプロイ環境を作成します。このパターンのアプローチは、反復可能なデプロイメントのためのAmplify フロントエンドパイプラインを構築できることを意味します。 ## 前提条件と制限事項 前提条件 + Amazon Web Services (AWS) (AWS) アカウント。 + 管理者アクセス権を持つアクティブな Bitbucket アカウント + 「[cURL](https://curl.se/)」または「[Postman](https://www.postman.com/)」アプリケーションを使用する端末へのアクセス + Amplify Gurify の使用方法 + AWS CloudFormation に精通している + YAML 形式のファイルに精通していること ## アーキテクチャ ![\[Diagram showing user interaction with Bitbucket repository connected to AWS Amplify in AWS クラウド region.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/24ae87ed-aa5d-4114-9c5d-bdcb4d40a78b/images/25d73a9d-d2ae-40bc-9ebc-57f9bd13884a.png) **テクノロジースタック** + Amplify + AWS CloudFormation + Bitbucket ## ツール + [AWS Amplify](https://docs.aws.amazon.com/amplify/) — Amplify は、開発者がクラウドを利用したモバイルアプリやウェブアプリを開発およびデプロイするのに役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) – AWS CloudFormation は AWS リソースのモデル化とセットアップに役立つサービスです。リソース管理に割く時間を減らし、AWS で実行するアプリケーションにより注力できるようになります。 + [Bitbucket](https://bitbucket.org/) — Bitbucket は、プロフェッショナルチーム向けに設計された Git リポジトリ管理ソリューションです。Git リポジトリの管理、ソースコードの共同編集、開発フローのガイドなどを一元的に行えます。 **コード** `bitbucket-amplify.yml`ファイル (添付) には、このパターンの AWS CloudFormation テンプレートが含まれています。 ## エピック ### Bitbucket リポジトリを設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | (オプション) Bitbucket リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)既存の Bitbucket リポジトリを使用することもできます。 | DevOps エンジニア | | ワークスペース設定を開きます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html) | DevOps エンジニア | | OAuth コンシューマーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html) | DevOps エンジニア | | OAuth アクセストークンを取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)`curl -X POST -u "KEY:SECRET" https://bitbucket.org/site/oauth2/access_token -d grant_type=client_credentials ``KEY` と `SECRET` を先ほど記録したキーとシークレットに置き換えます。 2. 引用符を使わずにアクセストークンを記録します。トークンの有効期間は限られており、デフォルトは 2 時間です。この期間内に AWS CloudFormation テンプレートを実行する必要があります。 | DevOps エンジニア | ### AWS CloudFormation スタックの設定とデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation のテンプレートをダウンロードします。 | `bitbucket-amplify.yml`AWS CloudFormation のテンプレートをダウンロードします。このテンプレートは、Amplify プロジェクトとブランチに加えて、AAmplify でCI/CDパイプラインを作成します。 | | | AWS CloudFormation スタックの設定とデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)5. [**次へ**] を選択してから、[**スタックの作成**] を選択します。 | DevOps エンジニア | ### CI/CD パイプラインをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードをリポジトリのブランチにデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)このコマンドの詳細については、Ｂｉｔｂｕｋｅｃｔドキュメントの「[基本の Git コマンド](https://confluence.atlassian.com/bitbucketserver/basic-git-commands-776639767.html)」を参照してください。  | アプリ開発者 | ## 関連リソース [認証方法](https://developer.atlassian.com/bitbucket/api/2/reference/meta/authentication) (アトラシアン製品ドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/24ae87ed-aa5d-4114-9c5d-bdcb4d40a78b/attachments/attachment.zip)」 # Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する *Amazon Web Services、Richard Milner-Watts および Amit Anjarlekar* ## 概要 このパターンは、AWS Step Functions と AWS Lambda プロキシ関数を使用して複数の AWS アカウント間で AWS CodeBuild プロジェクトを非同期で起動する方法を示しています。パターンのサンプル Step Functions ステートマシンを使用して、CodeBuild プロジェクトの成功をテストできます。 CodeBuild は、フルマネージドのランタイム環境から AWS コマンドラインインターフェイス (AWS CLI) を使用して運用タスクを起動するのに役立ちます。環境変数をオーバーライドすることで、ランタイムにおける CodeBuild プロジェクトの動作を変更できます。また、CodeBuild を使用してワークフローを管理できます。詳細については、AWS ワークショップウェブサイトの「[サービスカタログツール](https://service-catalog-tools-workshop.com/tools.html)」と、AWS データベースブログの「[AWS CodeBuild と Amazon EventBridge を使用して Amazon RDS for PostgreSQL のジョブをスケジュールする](https://aws.amazon.com/blogs/database/schedule-jobs-in-amazon-rds-for-postgresql-using-aws-codebuild-and-amazon-eventbridge/)」を参照してください。 ## 前提条件と制限 **前提条件** + 2 つのアクティブな AWS アカウント。1 つはStep Functions で Lambda プロキシ関数を呼び出すためのソースアカウントで、もう 1 つはリモート CodeBuild サンプルプロジェクトを構築するためのターゲットアカウント **制限事項** + このパターンを使用して、[アーティファクト](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-artifacts.html)をアカウント間でコピーすることはできません。 ## アーキテクチャ このパターンが構築するアーキテクチャを次の図に示します。 ![\[複数の AWS アカウントで CodeBuild プロジェクトを起動するアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/809a5716-56e5-477c-aac6-02243675a2f2/images/857ba3ae-eb9a-4d6b-b73e-e596f41c8cb8.png) この図表は、次のワークフローを示しています: 1. Step Functions ステートマシンは、指定された入力マップを解析し、定義したアカウント、リージョン、プロジェクトごとに Lambda プロキシ関数 (`codebuild-proxy-lambda`) を呼び出します。 1. Lambda プロキシ関数は、AWS Security Token Service (AWS STS) を使用して、ターゲットアカウントで IAM ポリシー (`codebuild-proxy-policy`) に関連付けられている IAM プロキシロール (`codebuild-proxy-role`) を引き受けます。 1. 引き受けたロールを使用して、Lambda 関数は CodeBuild プロジェクトを起動し、CodeBuild ジョブ ID を返します。Step Functions ステートマシンは、成功または失敗のステータスを受け取るまでループし、CodeBuild ジョブをポーリングします。 ステートマシンロジックを次の図に示します。 ![\[Step Functions ステートマシンのワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/809a5716-56e5-477c-aac6-02243675a2f2/images/4729bbfc-79ad-455d-a85a-b96cce00f432.png) テクノロジースタック + AWS CloudFormation + CodeBuild + IAM + Lambda + ステップ関数 + X-Ray ## ツール + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。 + [AWS CloudFormation Designer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-json-editor.html) には、CloudFormation テンプレートの表示と編集に役立つ JSON と YAML の統合エディタが用意されています。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージドの構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。 + [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) は、アプリケーションで処理するリクエストに関するデータを収集するのに役立ち、さらにデータの表示、フィルタリング、インサイトによって問題や機会を特定して最適化するために使用できるツールを提供します。 **Code** このパターンのサンプルコードは、GitHub [クロスアカウント CodeBuild プロキシ](https://github.com/aws-samples/cross-account-codebuild-proxy)リポジトリにあります。このパターンでは、AWS Lambda Powertools for Python ライブラリを使用してロギング機能とトレース機能を提供しています。このライブラリとそのユーティリティの詳細については、「[Powertools for AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda/python/latest/)」を参照してください。 ## ベストプラクティス 1. ジョブステータスのポーリングリクエストを最小限に抑えるために、Step Function ステートマシンの待機時間の値を調整します。CodeBuild プロジェクトの予想される実行時間を使用します。 1. Step Functions のマップの `MaxConcurrency` プロパティを調整して、並行して実行できる CodeBuild プロジェクトの数を制御します。 1. 必要に応じて、サンプルコードを確認して本番稼働への準備状況を確認します。ソリューションによってログに記録される可能性のあるデータと、デフォルトの Amazon CloudWatch 暗号化で十分かどうかを検討します。 ## エピック ### ソースアカウントで Lambda プロキシ関数と関連する IAM ロールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS アカウント ID を記録する。 | アカウント間のアクセスを設定するには、AWS アカウント ID が必要です。ソースアカウントとターゲットアカウントの AWS アカウント ID を記録します。詳細については、IAM ドキュメントの「[ アカウント ID の検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId)」を参照してください。 | AWS DevOps | | AWS CloudFormation のテンプレートをダウンロードする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html)AWS CloudFormation テンプレートでは、`` はソースアカウントの AWS アカウント ID で、`` はターゲットアカウントの AWS アカウント ID です。 | AWS DevOps | | AWS CloudFormation スタックを設定しデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html)ターゲットアカウントにリソースを作成する前に、プロキシ Lambda 関数用の AWS CloudFormation スタックを作成する必要があります。ターゲットアカウントで信頼ポリシーを作成すると、IAM ロールはロール名から内部識別子に変換されます。これが、IAM ロールが既に存在している必要がある理由です。 | AWS DevOps | | プロキシ関数とステートマシンが作成されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps | ### ターゲットアカウントに IAM ロールを作成し、サンプル CodeBuild プロジェクトを起動する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックを設定しデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps | | サンプル CodeBuild プロジェクトが作成されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps | ### クロスアカウントの Lambda プロキシ関数のテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ステートマシンを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps | | 環境変数を検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Step Functions の実行には予想よりも時間がかかります。 | Step Function ステートマシンのマップの `MaxConcurrency` プロパティを調整して、並行して実行できる CodeBuild プロジェクトの数を制御します。 | | CodeBuild ジョブの実行には予想よりも時間がかかります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | # Application Recovery Controller を使用して EMR クラスターのマルチ AZ フェイルオーバーを管理する *Amazon Web Services、Aarti Rajput、Ashish Bhatt、Neeti Mishra、Nidhi Sharma* ## 概要 このパターンは、Amazon EMR ワークロードの効率的なディザスタリカバリ戦略を提供し、ひとつの AWS リージョン内における複数のアベイラビリティーゾーン間で高可用性とデータ整合性を確保するのに役立ちます。この設計では、[Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) と [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) を使用して、Apache Spark ベースの EMR クラスターのフェイルオーバーオペレーションとトラフィック分散を管理します。 標準条件下では、プライマリアベイラビリティーゾーンは、完全な読み取り / 書き込み機能を備えたアクティブな EMR クラスターとアプリケーションをホストします。アベイラビリティーゾーンが予期せず失敗した場合、トラフィックは自動的にセカンダリアベイラビリティーゾーンにリダイレクトされ、そこで新しい EMR クラスターが起動されます。両方のアベイラビリティーゾーンは、専用の[ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)を介して共有 Amazon Simple Storage Service (Amazon S3) バケットにアクセスし、一貫したデータ管理を実現します。このアプローチにより、ダウンタイムが最小限に抑えられ、アベイラビリティーゾーンの障害発生時に重要なビッグデータワークロードを迅速に復旧できます。このソリューションは、リアルタイム分析が重要な金融や小売などの業界で役立ちます。 ## 前提条件と制限 **前提条件** + アクティブな [AWS アカウント](https://aws.amazon.com/resources/create-account/) + Amazon Elastic Compute Cloud (Amazon EC2) 上の [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) + EMR クラスターのプライマリノードから Amazon S3 へのアクセス。 + AWS マルチ AZ インフラストラクチャ **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについて、詳しくは「[AWS のサービス by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」をご確認ください。特定のエンドポイントについては、「[Service endpoints and quotas page](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」から、サービスのリンクを選択してご確認ください。 **製品バージョン** + [Amazon EMR リリース 6.x 以降](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html) ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EMR クラスター + Amazon Application Recovery Controller + Application Load Balancer + Amazon S3 バケット + Amazon S3 のゲートウェイエンドポイント **ターゲットアーキテクチャ** ![\[Application Recovery Controller を使用した自動復旧メカニズムのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e5ecdb66-0eef-4a6a-8367-982a55104748/images/e982d580-13db-4bdd-9f6b-6400d7c31c01.png) このアーキテクチャは、複数のアベイラビリティーゾーンを使用し、Application Recovery Controller を通じて自動復旧メカニズムを実装することで、アプリケーションの耐障害性を提供します。 1. Application Load Balancer は、トラフィックをアクティブな Amazon EMR 環境にルーティングします。通常この環境は、プライマリアベイラビリティーゾーンのプライマリ EMR クラスターになります。 1. アクティブな EMR クラスターはアプリケーションリクエストを処理し、専用の Amazon S3 ゲートウェイエンドポイント経由で Amazon S3 に接続して、読み取りおよび書き込みオペレーションを行います。 1. Amazon S3 は中央データリポジトリとして機能し、チェックポイントまたは EMR クラスター間の共有ストレージとして使用される可能性があります。EMR クラスターは、`s3://` プロトコルと [EMR ファイルシステム (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs.html) を介して Amazon S3 に直接書き込む際にデータ整合性を維持します。 1. Application Recovery Controller は、プライマリアベイラビリティーゾーンの状態を継続的にモニタリングし、必要に応じてフェイルオーバーオペレーションを自動的に管理します。 1. Application Recovery Controller がプライマリ EMR クラスターで障害を検出すると、次のアクションを実行します。 + アベイラビリティーゾーン 2 のセカンダリ EMR クラスターへのフェイルオーバープロセスを開始します。 + ルーティング設定を更新して、トラフィックをセカンダリクラスターに転送します。 ## ツール **AWS サービス** + [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)** **は、 とアベイラビリティーゾーン間のアプリケーションの復旧を管理 AWS リージョン および調整するのに役立ちます。このサービスは、従来のツールやプロセスに必要な手動ステップを削減することで、プロセスを簡素化し、アプリケーション復旧の信頼性を向上させます。 + [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) は、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します。受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンスなど) に分散します。これにより、アプリケーションの可用性が向上します。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) は、Apache Spark、Apache Hive、Presto などのオープンソースフレームワークのデータ処理、インタラクティブ分析、機械学習を提供するビッグデータプラットフォームです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) のウェブサービスインターフェイスはシンプルで、いつでも、ウェブのどこからでも容量に関係なくデータを格納および取得できます。このサービスを使用すると、クラウドネイティブストレージを利用するアプリケーションを簡単に構築できます。 + [Amazon S3 のゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)は、 AWS ネットワーク経由で Virtual Private Cloud (VPC) から Amazon S3 にアクセスするためにルートテーブルで指定するゲートウェイです。 ## ベストプラクティス + 「[AWS best practices for security, identity, and compliance](https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=%5b…%5d.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all)」の記載に従って、信頼性のある安全なアーキテクチャを構築します。 + アーキテクチャ調整の際には「[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)」を参照してください。 + Amazon S3 Access Grants を使用して、Spark ベースの EMR クラスターから Amazon S3 へのアクセスを管理します。詳しくはブログ記事「[Use Amazon EMR with S3 Access Grants to Scale Spark access to Amazon S3](https://aws.amazon.com/blogs/big-data/use-amazon-emr-with-s3-access-grants-to-scale-spark-access-to-amazon-s3/)」をご確認ください。 + [Amazon S3 で Spark のパフォーマンスを向上させます](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-performance.html)。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS マネジメントコンソールにサインインします。 | [AWS マネジメントコンソール](https://console.aws.amazon.com/) に IAM ユーザーとしてサインインします。手順については、[AWS ドキュメント](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-iam-user-sign-in-tutorial.html)を参照してください。 | AWS DevOps | | AWS CLIを設定します。**** | をインストールする AWS CLI か、最新バージョンに更新して、 AWS のサービス で を操作できるようにします AWS マネジメントコンソール。手順については、[AWS CLI ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)を参照してください。 | AWS DevOps | ### EMR クラスターに Spark アプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを作成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | | EMR クラスターの作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | | EMR クラスターのセキュリティ設定を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | | EMR クラスターに接続します。 | 提供されたキーペアを使用して、SSH を介して EMR クラスターのプライマリノードに接続します。キーペアファイルがアプリケーションと同じディレクトリに存在することを確認します。次のコマンドを実行して、キーペアに正しいアクセス許可を設定し、SSH 接続を確立します。
chmod 400 
ssh -i ./ hadoop@
| AWS DevOps | | Spark アプリケーションをデプロイします。 | SSH 接続を確立すると、Hadoop コンソールに表示されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | | Spark アプリケーションをモニタリングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | ### トラフィックを別のアベイラビリティーゾーンに移動する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Application Load Balancer を作成します。 | AWS リージョン内の 2 つのアベイラビリティーゾーンにデプロイされている Amazon EMR プライマリノード間でトラフィックをルーティングするターゲットグループを設定します。手順について、詳しくは「[Create a target group for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」(Elastic ロードバランサードキュメント) をご確認ください。 | AWS DevOps | | Application Recovery Controller でゾーンシフトを設定します。 | このステップでは、Application Recovery Controller の[ゾーンシフト機能](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)を使用して、トラフィックを別のアベイラビリティーゾーンにシフトします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html)を使用するには AWS CLI、Application Recovery Controller [ドキュメントの「ゾーンシフト AWS CLI で を使用する例](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-cli-zonalshift.html)」を参照してください。 | AWS DevOps | | ゾーンシフトの設定と進行状況を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps | ## 関連リソース + AWS CLI コマンド: + [クラスター作成](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr/create-cluster.html) + [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr/describe-cluster.html) + [arc-zonal-shift](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/arc-zonal-shift/index.html) + [Configuring Amazon EMR cluster instance types and best practices for Spot instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html) (Amazon EMR ドキュメント) + [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM ドキュメント) + [インスタンスプロファイルを使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) (IAM ドキュメント) + [Use zonal shift and zonal autoshift to recovery applications in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/multi-az.html) (Application Recovery Controller ドキュメント) # AWS コードサービスと AWS KMS マルチリージョンキーを使用して、複数のアカウントとリージョンへのマイクロサービスのブルー/グリーンデプロイを管理 *Amazon Web Services、Balaji Vedagiri、Vanitha Dontireddy、Ashish Kumar、Faisal Shahdad、Vivek Thangamuthu、および Anand Krishna Varanasi* ## 概要 このパターンは、ブルー/グリーンデプロイ戦略に従い、中央のAWS アカウントから複数のワークロードアカウントとリージョンにグローバルマイクロサービスアプリケーションをデプロイする方法を説明しています。このパターンは以下をサポートします。 + ソフトウェアは中央アカウントで開発されますが、ワークロードとアプリケーションは複数のアカウントと AWS リージョンに分散されます。 + ディザスタリカバリとして、単一の AWS キー管理システム (AWS KMS) マルチリージョンキーが暗号化と復号に使用されます。 + KMS キーはリージョン固有であり、パイプラインアーティファクト用に 3 つの異なるリージョンで管理しまたは作成する必要があります。KMS マルチリージョンキーは、リージョン間で同じキー ID を保持することに役立ちます。 + Git ワークフローの分岐モデルは 2 つのブランチ (開発とメイン) で実装され、コードはプルリクエスト (PR) でマージされます。このスタックからデプロイされる AWS Lambda 関数は、開発ブランチからメインブランチへの PR を作成します。メインブランチにマージするPR は、AWS CodePipeline パイプラインを開始します。これにより、継続的インテグレーションと継続的デリバリー (CI/CD) フローをオーケストレーションし、アカウントにスタックをデプロイします。 このパターンは、AWS CloudFormation スタックによるコードとしての Infrastructure as Code (IaC) 設定のサンプルを提供され、このユースケースを説明します。マイクロサービスのブルー/グリーンデプロイは、AWS CodeDeploy を使用して実装されます。 ## 前提条件と制限 **前提条件** + 4 つのアクティブな AWS アカウント: + コードパイプラインを管理し、AWS CodeCommit リポジトリを維持するためのツールアカウント。 + マイクロサービスワークロードをデプロイするための 3 つのワークロード (テスト) アカウント。 + このパターンでは次のリージョンを使用します。他のリージョンを使用する場合は、AWS CodeDeploy と AWS KMS マルチリージョンスタックに適切な変更を加える必要があります。 + ツール (AWS CodeCommit) アカウント： `ap-south-1` + ワークロード (テスト) アカウント 1： `ap-south-1` + ワークロード (テスト) アカウント 2： `eu-central-1` + ワークロード (テスト) アカウント 3： `us-east-1` + 各ワークロードアカウントのデプロイ用の 3 つの Amazon Simple Storage Service (Amazon S3) バケット。(これらはこのパターンで、`S3BUCKETNAMETESTACCOUNT1` 、`S3BUCKETNAMETESTACCOUNT2 ` 、`S3BUCKETNAMETESTACCOUNT3 ` と呼ばれています。) 例えば、これらのバケットは、特定のアカウントとリージョンに次のように固有のバケット名で作成できます (*xxxx* をランダムなナンバーに置き換える)。 ``` ##In Test Account 1 aws s3 mb s3://ecs-codepipeline-xxxx-ap-south-1 --region ap-south-1 ##In Test Account 2 aws s3 mb s3://ecs-codepipeline-xxxx-eu-central-1 --region eu-central-1 ##In Test Account 3 aws s3 mb s3://ecs-codepipeline-xxxx-us-east-1 --region us-east-1 #Example ##In Test Account 1 aws s3 mb s3://ecs-codepipeline-18903-ap-south-1 --region ap-south-1 ##In Test Account 2 aws s3 mb s3://ecs-codepipeline-18903-eu-central-1 --region eu-central-1 ##In Test Account 3 aws s3 mb s3://ecs-codepipeline-18903-us-east-1 --region us-east-1 ``` **制限事項** このパターンは、AWS CodeBuild とその他の設定ファイルでサンプルマイクロサービスをデプロイします。別のワークロードタイプ (サーバーレスなど) を使用している場合は、関連する設定をすべて更新する必要があります。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS CloudFormation + AWS CodeCommit + AWS CodeBuild + AWS CodeDeploy + AWS CodePipeline **ターゲットアーキテクチャ** ![\[マイクロサービスを複数のアカウントとリージョンにデプロイするためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a144c977-6823-4b08-a215-fae779b3ce7c/images/eedfabdb-f266-4190-b271-5caf7ac9b47b.png) **自動化とスケール** 設定は、AWS CloudFormation スタックテンプレート (IaC) を使用して自動化されます。複数の環境やアカウントに合わせて簡単にスケールすることができます。 ## ツール **AWS サービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、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 Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + 「[Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に効果的な暗号キーを作成および管理する上で役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 その他のツール + 「[Git](https://git-scm.com/docs)」は、AWS CodeCommit リポジトリと連携するオープンソースの分散型バージョン管理システムです。 + 「[Docker](https://www.docker.com/)」は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するPlatform as a Service (PaaS) 製品のセットです。このパターンでは、Docker でコンテナイメージをローカルでビルドしてテストします。 + 「[cfn-lint](https://github.com/aws-cloudformation/cfn-lint)」と「[cfn-nag](https://github.com/stelligent/cfn_nag)」は、CloudFormation スタックにエラーやセキュリティ上の問題がないかを確認することに役立つオープンソースツールです。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[複数のリージョンとアカウントのグローバルブルー/グリーンデプロイ](https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline)」リポジトリで利用できます。 ## エピック ### 環境変数のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックデプロイ用の環境変数を出力します。 | このパターンの後半で CloudFormation スタックへの入力として使用する環境変数を定義します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | ### インフラストラクチャ用にCloudFormation スタックをパッケージしてデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | [「サンプルリポジトリ」](https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline)を作業場所の新しいリポジトリにクローンを作成します。
##In work location
git clone https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline.git
| AWS DevOps | | Cloudformation リソースをパッケージします。 | このステップでは、CloudFormation テンプレートが参照するローカルアーティファクトをパッケージして、Amazon Virtual Private Cloud (Amazon VPC) やApplication Load Balancer などのサービスに必要なインフラストラクチャリソースを作成します。このテンプレートはコードリポジトリの `Infra` フォルダで利用できます。
##In TestAccount1##
aws cloudformation package \
    --template-file mainInfraStack.yaml \
    --s3-bucket $S3BUCKETNAMETESTACCOUNT1 \
    --s3-prefix infraStack \
    --region $TESTACCOUNT1REGION \
    --output-template-file infrastructure_${TESTACCOUNT1}.template
##In TestAccount2##
aws cloudformation package \
    --template-file mainInfraStack.yaml \
    --s3-bucket $S3BUCKETNAMETESTACCOUNT2 \
    --s3-prefix infraStack \
    --region $TESTACCOUNT2REGION \
    --output-template-file infrastructure_${TESTACCOUNT2}.template
##In TestAccount3##
aws cloudformation package \
    --template-file mainInfraStack.yaml \
    --s3-bucket $S3BUCKETNAMETESTACCOUNT3 \
    --s3-prefix infraStack \
    --region $TESTACCOUNT3REGION \
    --output-template-file infrastructure_${TESTACCOUNT3}.template
| AWS DevOps | | パッケージテンプレートを検証します。 | パッケージテンプレートを検証します。
aws cloudformation validate-template \
    --template-body file://infrastructure_${TESTACCOUNT1}.template

aws cloudformation validate-template \
    --template-body file://infrastructure_${TESTACCOUNT2}.template

aws cloudformation validate-template \
    --template-body file://infrastructure_${TESTACCOUNT3}.template
| AWS DevOps | | パッケージファイルをワークロードアカウントにデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | ### サンプルイメージをプッシュして Amazon ECS をスケールします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon ECR リポジトリにサンプルイメージをプッシュします | (パラメータで設定されているように) `web` という Amazon Elastic Container Registry (Amazon ECR) リポジトリに、サンプル (NGINX) イメージをプッシュします。このイメージは必要に応じてカスタマイズできます。ログインして、Amazon ECR にイメージをプッシュするための認証情報を設定するには、「[Amazon ECR のドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」の指示に従ってください。コマンドは以下のとおりです。
  docker pull nginx
  docker images
  docker tag  aws_account_id.dkr.ecr.region.amazonaws.com/:latest
  docker push .dkr.ecr..amazonaws.com/:tag
| AWS DevOps | | Amazon ECS をスケールしてアクセスを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | ### コードサービスとリソースを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ツール アカウントに CodeCommit リポジトリを作成します。 | GitHub リポジトリの `code` フォルダにある `codecommit.yaml` テンプレートを使用して、ツールアカウントに CodeCommit リポジトリを作成します。このリポジトリは、コードを開発する予定の 1 つのリージョンにのみ作成する必要があります。
aws cloudformation deploy --stack-name codecommitrepoStack --parameter-overrides  CodeCommitReponame=$CODECOMMITREPONAME \
ToolsAccount=$TOOLSACCOUNT --template-file codecommit.yaml  --region $TOOLSACCOUNTREGION \
--capabilities CAPABILITY_NAMED_IAM
| AWS DevOps | | CodePipeline によって生成されたアーティファクトを管理するための S3 バケットを作成します。 | GitHub リポジトリの `code` フォルダにある `pre-reqs-bucket.yaml` テンプレートを使用して、CodePipeline によって生成されたアーティファクトを管理するための S3 バケットを作成します。スタックは 3 つのワークロード (テスト) とツールのアカウントとリージョンにすべてデプロイする必要があります。
aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT1REGION --capabilities CAPABILITY_NAMED_IAM

aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT2REGION --capabilities CAPABILITY_NAMED_IAM

aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT3REGION --capabilities CAPABILITY_NAMED_IAM

aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TOOLSACCOUNTREGION --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps | | マルチリージョン KMS キーを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | | ツールアカウントで CodeBuild プロジェクトを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | | ワークロードアカウントに CodeDeploy を設定します。 | GitHub リポジトリの `code` フォルダにある `codedeploy.yaml` テンプレートを使用して、3 つのワークロードアカウントにすべて CodeDeploy を設定します。`mainInfraStack` の出力には、Amazon ECS クラスターの Amazon リソースネーム (ARN) とApplication Load Balancer リスナーが含まれます。インフラストラクチャスタックの値は既に出力されているため、CodeDeploy スタックテンプレートにより入力されます。
##WorkloadAccount1##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides  ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml  --region $TESTACCOUNT1REGION --capabilities CAPABILITY_NAMED_IAM

##WorkloadAccount2##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml  --region $TESTACCOUNT2REGION --capabilities CAPABILITY_NAMED_IAM

##WorkloadAccount3##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml  --region $TESTACCOUNT3REGION --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps | ### ツールアカウントで CodeBuild プロジェクトを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ツールアカウントにコードパイプラインを作成します。 | ツールアカウントで、以下のコマンドを実行します。
aws cloudformation deploy --stack-name ecscodepipelinestack --parameter-overrides  \
TestAccount1=$TESTACCOUNT1 TestAccount1Region=$TESTACCOUNT1REGION \
TestAccount2=$TESTACCOUNT2 TestAccount2Region=$TESTACCOUNT2REGION \
TestAccount3=$TESTACCOUNT3 TestAccount3Region=$TESTACCOUNT3REGION \
CMKARNTools=$CMKTROOLSARN CMKARN1=$CMKARN1 CMKARN2=$CMKARN2 CMKARN3=$CMKARN3 \
CodeCommitRepoName=$CODECOMMITREPONAME BucketStartName=$BUCKETSTARTNAME \
--template-file codepipeline.yaml --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps | | AWS KMS キーポリシーと S3 バケットポリシーの CodePipeline と CodeBuild ロールへのアクセスを提供します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps | ### パイプラインを呼び出してテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 変更を CodeCommit リポジトリにプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイされたすべてのリソースをクリーンアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | リポジトリにコミットした変更はデプロイされません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | ## 関連リソース + 「[Docker イメージをプッシュする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」(Amazon ECR のドキュメント) + 「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」(AWS CodeCommit のドキュメント) + 「[AWS CodeBuild のトラブルシューティング](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)」(AWS CodeBuild のドキュメント) # AWS CloudFormation と AWS Config を使用して Amazon ECR リポジトリのワイルドカード権限をモニタリングする *Amazon Web Services、Vikrant Telkar、Wassim Benhallam、Sajid Momin* ## 概要 Amazon Web Services (AWS) クラウド上のAmazon Elastic Container Registry (Amazon ECR) は AWS Identity and Access Management (IAM) を使用したリソースベースのアクセス権限によるプライベートリポジトリをサポートするマネージドコンテナイメージレジストリサービスです。 IAM はリソース属性とアクション属性の両方で「`*`」ワイルドカードをサポートしているため、一致する複数の項目を簡単に自動的に選択できます。テスト環境では、「[リポジトリポリシーステートメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)」のプリンシパル要素にある `ecr:*` 「[ワイルドカードアクセス権限](https://docs.aws.amazon.com/lambda/latest/operatorguide/wildcard-permissions-iam.html)」を使用して、認証されたすべての AWS ユーザーに Amazon ECR リポジトリへのアクセスを許可できます。`ecr:*` ワイルドカードアクセス権限は、本稼働データにアクセスできない開発アカウントで開発やテストを行う場合に役立ちます。 ただし、`ecr:*` ワイルドカード権限は重大なセキュリティ上の脆弱性を引き起こす可能性があるため、本番環境では使用しないようにする必要があります。このパターンのアプローチは、`ecr:*` リポジトリポリシーステートメントにワイルドカード権限が含まれている Amazon ECR リポジトリを特定することに役立ちます。  このパターンには、AWS Config でカスタムルールを作成するためのステップと AWS CloudFormation テンプレートが含まれています。次に、AWS Lambda 関数が Amazon ECR リポジトリのポリシーステートメントを監視して、`ecr:*` ワイルドカードアクセス権限を確認します。準拠していないリポジトリポリシーステートメントが見つかると、Lambda は Amazon EventBridge にイベントを送信するよう AWS Config に通知し、EventBridge は Amazon Simple Notification Service (Amazon SNS) トピックを開始します。SNS トピックは、非準拠のリポジトリポリシーステートメントについてメールで通知します。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + AWS コマンドラインインターフェイス (AWS CLI) がインストール済みおよび設定済み。詳細については、AWS CLI ドキュメントの「[AWS CLI バージョン 2 のインストール、更新、およびアンインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。 + ポリシーステートメントが添付された既存の Amazon ECR リポジトリがテスト環境にインストールし、設定されています。詳細については、「Amazon ECR のドキュメント」の「[プライベートリポジトリを作成する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」と「[リポジトリポリシーステートメントを設定する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)」を参照してください。 + お好みの AWS リージョンで設定された AWS Config。詳細については、「AWS Config のドキュメント」の「[AWS Config の開始方法](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html)」を参照してください。 + `aws-config-cloudformation.template` ファイル (添付) は、ローカルマシンにダウンロードされます。   **制限事項** + このパターンのソリューションはリージョナルで、リソースは、同じリージョンに作成されます。  ## アーキテクチャ 次の図は、AWS Config が Amazon ECR リポジトリポリシーステートメントを評価する方法を示しています。  ![\[AWS Config workflow with Lambda, Amazon ECR, EventBridge, SNS, and email notification components.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01bbf5f8-27aa-4c64-9a03-7fcccc0955b8/images/49bbf14b-0a18-4d4a-86ab-162d37708e01.png) この図表は、次のワークフローを示しています: 1. AWS Config はカスタムルールを開始します。  1. カスタムルールは Lambda 関数を呼び出して Amazon ECR リポジトリポリシーステートメントのコンプライアンスを評価します。次に、Lambda 関数は非準拠のリポジトリポリシーステートメントを識別します。 1. Lambda 関数はコンプライアンス違反ステータスを AWS Config に送信します。 1. AWS Config は EventBridge にイベントを送信します。 1. EventBridge はコンプライアンス違反通知を SNS トピックに公開します。 1. Amazon SNS は、ユーザーや承認されたユーザーにメールアラートを送信します。 **自動化とスケール** このパターンのソリューションでは、Amazon ECR リポジトリのポリシーステートメントをいくつでもモニタリングできますが、評価するリソースはすべて同じリージョンで作成されている必要があります。 ## ツール + 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」 を使用することで、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクルの最初から最後までリソースを管理できます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。複数の AWS アカウントと AWS リージョンにまたがるスタックを管理およびプロビジョニングすることが可能です。 + 「[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)」— AWS Config は、AWS アカウント内の AWS リソースの設定の詳細なビューを提供します。これには、リソース間の関係と設定の履歴が含まれるため、時間の経過と共に設定と関係がどのように変わるかを確認できます。 + [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)** **–** **Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。Amazon ECR は、 IAM を使用するリソースベースの許可を持つプライベートリポジトリをサポートします。                                 + 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」— Amazon EventBridgeは、アプリケーションをさまざまなソースからのデータに接続するために使用できるサーバーレスのイベントバスサービスです。EventBridge は、アプリケーション、software as a service (SaaS) アプリケーション、および AWS サービスからのリアルタイムデータのストリームを、AWS Lambda 関数、API デスティネーションを使用した HTTP 呼び出しエンドポイント、または他のアカウントのイベントバスなどのターゲットに配信します。 + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。課金は実際に消費したコンピューティング時間に対してのみ発生します。コードが実行されていない場合、料金は発生しません。 + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) — Amazon Simple Notification Service (Amazon SNS) は、ウェブサーバーや E メールアドレスなど、パブリッシャーとクライアント間のメッセージ配信や送信を調整および管理します。サブスクライバーは、サブスクライブしているトピックに対して発行されたすべてのメッセージを受信します。また、同じトピックのサブスクライバーはすべて同じメッセージを受信します。  **Code** このパターンのコードは `aws-config-cloudformation.template` ファイル (添付) にあります。 ## エピック ### AWS CloudFormation スタックを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation スタックを作成する | AWS CLI で次のコマンドを実行して AWS CloudFormation スタックを作成します。
$ aws cloudformation create-stack --stack-name=AWSConfigECR \
    --template-body  file://aws-config-cloudformation.template \
    --parameters ParameterKey=,ParameterValue= \
    --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps | ### AWS Config カスタムルールをテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Config カスタムルールをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.html) | AWS DevOps | ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/01bbf5f8-27aa-4c64-9a03-7fcccc0955b8/attachments/attachment.zip)」 # AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する *Amazon Web Services、Sarat Chandra Pothula、VAMSI KRISHNA SUNKAVALLI* ## 概要 サーバーレスインフラストラクチャを複数の AWS アカウント および環境にデプロイしている組織では、コードの重複、手動プロセス、一貫性のないプラクティスなどの課題に直面することがよくあります。このパターンのソリューションは、Go および GitHub Actions の再利用可能なワークフロー AWS Cloud Development Kit (AWS CDK) で を使用して、マルチアカウントのサーバーレスインフラストラクチャ管理を合理化する方法を示しています。クラウドリソースをコードとして定義する手法、標準化された継続的インテグレーション/継続的デプロイ (CI/CD) プロセスの実装法、モジュール式の再利用可能コンポーネントの作成方法を説明します。 これらの操作を行うことで、組織は複数のアカウントにまたがるリソースを効率的に管理し、一貫したデプロイパイプラインの実装と、複雑なサーバーレスアーキテクチャの簡素化を実現できます。このアプローチは、 で使用するために標準化されたプラクティスを適用することでセキュリティとコンプライアンスを強化し AWS アカウント、最終的には生産性を向上させ、サーバーレスアプリケーションの開発とデプロイのエラーを減らします。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + AWS Identity and Access Management デプロイプロセスには (IAM) [ロールとアクセス許可](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam.html)が設定されています。これには、Amazon Elastic Container Registry (Amazon ECR) リポジトリへのアクセス、 AWS Lambda 関数の作成、およびターゲット全体で必要なその他のリソースへのアクセス許可が含まれます AWS アカウント。 + AWS Command Line Interface (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 Cloud Development Kit (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)。 + [インストール済み](https://go.dev/doc/install)の Go 1.22 以降。 + [インストール済み](https://docs.docker.com/engine/install/)の Docker 24.0.6 以降。 **制限事項** + **言語の互換性 **– Go はサーバーレスアプリケーションの一般的言語です。ただし、Go に加えて、 は C\$1、Java、Python、TypeScript などの他のプログラミング言語 AWS CDK をサポートしています。他の言語に対する既存コードベースや専門知識を組織が有している場合でも、本パターンで説明するソリューションを最大限に活用するためには Go を導入し、学習していくことが推奨されます。 + **学習曲線 **– Go (組織を初めて使用する場合) AWS CDK、GitHub の再利用可能なワークフローを採用すると、デベロッパーと DevOps チーム向けの学習曲線が必要になる場合があります。テクノロジーの円滑な導入と効果的な使用を実現するためには、研修の実施や資料作成が必要になる場合があります。 ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[マルチアカウントサーバーレスインフラストラクチャ管理のための AWS CDK および GitHub Actions ワークフローのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d61917b-bd27-44fa-ae95-55358aaf8812/images/a4b36793-95c7-42f7-a92f-99b4722c9c64.png) このソリューションでは、以下のステップを実行します。 1. 開発者がリポジトリのクローンを元に新しいブランチを作成し、ローカル環境でアプリケーションコードを変更します。 1. 開発者がこれらの変更を確定し、新たなブランチを GitHub リポジトリにプッシュします。 1. 開発者が GitHub リポジトリにプルリクエストを作成し、機能および新機能ブランチのメインブランチへのマージを提案します。 1. このプルリクエストは、継続的インテグレーション (CI) の GitHub Actions ワークフローをトリガーします。このパターンの CI と継続的デプロイ (CD) ワークフローは、再利用可能なワークフローを使用します。再利用可能なワークフローは、さまざまなプロジェクトまたはリポジトリ間で共有および実行できる、事前定義されたモジュール式のテンプレートです。再利用可能なワークフローを使用すると、CI/CD プロセスを標準化し、効率を向上させることができます。 1. CI ワークフローが必要な環境を設定し、イメージの Docker タグを生成して、アプリケーションコードで Docker イメージを構築します。 1. CI ワークフローは central AWS アカウント GitHub OIDC ロールを使用して AWS で認証します。CI ワークフローの場合、 central AWS アカウント GitHub OIDC ロールは AWS Security Token Service (AWS STS) を使用して一時的な認証情報を取得します。これらの認証情報により、ロールは Docker イメージを構築して中央の Amazon ECR リポジトリにプッシュできます AWS アカウント。 1. CI ワークフローは、ビルドされた Docker イメージを Amazon ECR にプッシュします。 1. CI ワークフローは、イメージタグを Systems Manager Parameter Store に保存します。 1. CI ワークフローが正常に完了すると、Docker イメージタグが出力されます。 1. CD ワークフローをトリガーする際、開発者はデプロイする Docker イメージのイメージタグを手動で入力します。このイメージタグは、CI ワークフロー中に生成され Amazon ECR にプッシュされたタグに対応します。 1. 開発者は、CD 再利用可能なワークフローを使用する CD ワークフローを手動でトリガーします。 1. CD ワークフローは central AWS アカウント GitHub OIDC ロール AWS を使用して で認証します。CD ワークフローの場合、 AWS STS 最初に central AWS アカウント GitHub OIDC ロールを引き受けるために使用されます。次に、このロールはターゲットアカウントのデプロイの CDK ブートストラップロールを引き受けます。 1. CD ワークフローは、 を使用して AWS CloudFormation テンプレート AWS CDK を合成します。 1. CD ワークフローは、Lambda 関数に手動で指定されたイメージタグ AWS アカウント を使用して、CDK デプロイを使用してアプリケーションをターゲットにデプロイします。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。CloudFormation は AWS CDK デプロイプロセスの不可欠な部分です。CDK は CloudFormation テンプレートを合成し、CloudFormation を使用して AWS 環境内のリソースを作成または更新します。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、設定データ管理とシークレット管理のための安全な階層型ストレージを提供します。 **その他のツール** + [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。 + [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。 + [Go](https://go.dev/doc/install) は、Google がサポートするオープンソースのプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub の [aws-cdk-golang-serverless-cicd-github-actions](https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions) リポジトリから入手できます。 ## ベストプラクティス + **モジュラー設計** – AWS CDK コードをモジュール式で再利用可能なコンストラクトまたはスタックに整理し、複数のアカウントやプロジェクトでコードの再利用と保守性を促進します。 + **懸念事項の分離** – インフラストラクチャコードをアプリケーションコードから分離すれば、各コンポーネントの独立したデプロイと管理が可能になります。 + **バージョニングとイミュータビリティ** – Infrastructure as Code (IaC) を処理し、バージョン管理に Git を使用します。既存のリソースを変更するのではなく、新しいリソースを作成すれば、堅牢なインフラストラクチャを築くことができます。 + **テストと検証** – ユニットテスト、統合テスト、end-to-endテストなどの包括的なテスト戦略を実装して、 AWS CDK コードとデプロイの正確性と信頼性をサポートします。 + **セキュリティとコンプライアンス** – 最小特権アクセス、安全な通信、データ暗号化などの AWS セキュリティのベストプラクティスに従います。コンプライアンスチェックと監査メカニズムを実装して、組織のポリシーと規制要件に準拠していることを確認します。脆弱性のスキャン、イメージ署名の強制、組織のコンプライアンス要件の遵守など、コンテナイメージのセキュリティのベストプラクティスを実装します。 + **モニタリングとログ記録** – サーバーレスアプリケーションとインフラストラクチャの健全性やパフォーマンスを追跡するためのモニタリングとログ記録メカニズムを設定します。Amazon CloudWatch AWS のサービス と同様に を使用し AWS CloudTrail、モニタリングと監査 AWS X-Ray の目的で使用します。 + **自動化と CI/CD** – GitHub の再利用可能なワークフローやその他の CI/CD ツールを使用して、ビルド、テスト、デプロイのプロセスを自動化します。この作業は、複数のアカウント間で、一貫性のある反復可能なデプロイを実行するのに役立ちます。 + **環境管理** – 個別の環境 (開発、ステージング、本番環境など) の保守を行います。環境間の変更を促進する戦略を実装し、本番環境のデプロイ前に適切なテストと検証を行います。 + **ドキュメントとコラボレーション** – インフラストラクチャコード、デプロイプロセス、ベストプラクティスを文書化して、チーム内での知識の共有とコラボレーションを促進します。 + **コスト最適化** – リソースの適正化、自動スケーリングの使用、 や などのコスト最適化サービスの利用など、 AWS コストのモニタリングと最適化戦略を実装 AWS Budgets します AWS Cost Explorer。 + **ディザスタリカバリとバックアップ** – サーバーレスアプリケーションとインフラストラクチャリソースのバックアップと復元メカニズムを実装することで、ディザスタリカバリシナリオを計画します。 + **継続的な改善** — サーバーレスエコシステムにおける最新のベストプラクティス、セキュリティ上の推奨事項、技術面での進歩に合わせて、定期的に見直しを行い、プラクティス、ツール、プロセスを更新します。 + **セキュリティ体制の改善** – を使用して[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)、Amazon ECR のインターフェイス VPC エンドポイント、および AWS Systems Manager Parameter Store を設定することで AWS Lambda、仮想プライベートクラウド (VPC) のセキュリティ体制を改善します。 ## エピック ### 環境設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 中央で Amazon ECR リポジトリを作成します AWS アカウント。 | 複数の 間でコンテナイメージを共有するには AWS アカウント、Amazon ECR のクロスアカウントアクセスを設定する必要があります。まず、中央で Amazon ECR リポジトリを作成します AWS アカウント。Amazon ECR レポジトリを作成するには、次のコマンドを実行します。
aws ecr create-repository --repository-name sample-repo
後のタスクでは、コンテナイメージを使用する AWS アカウント 必要がある他の にプルアクセスを許可します。 | AWS DevOps | | Amazon ECR リポジトリにクロスアカウントアクセス許可を追加します。 | 中央の Amazon ECR リポジトリにクロスアカウントアクセス許可を追加するには AWS アカウント、次のコードを実行します。
{
  "Version": "2008-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "LambdaECRImageRetrievalPolicy",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": [
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer",
      ],
      "Condition": {
        "StringLike": {
          "aws:sourceArn": "arn:aws:lambda:::function:*"
        }
      }
    },
    {
      "Sid": "new statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
        },
      "Action": [
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer",
      ],
    }
  ] 
}
| AWS DevOps | | 中央で GitHub OIDC ロールのロールを設定します AWS アカウント。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | AWS DevOps | | ターゲットで AWS 環境をブートストラップします AWS アカウント。 | 中央アカウントからのクロスアカウントデプロイを有効に AWS アカウント AWS リージョン し、最小特権の原則を CloudFormation 実行ロールに適用する特定の および で CDK 環境を設定します。 AWS 環境を[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)するには、次のコマンドを実行します。
cdk bootstrap aws:/// --trust  --cloudformation-execution-policies arn:aws:iam::aws:policy/
| AWS DevOps | | ターゲット AWS アカウント ブートストラップロールへのアクセス権を中央 AWS アカウント OIDC ロールに付与します。 | CDK ブートストラップは、CDK デプロイプロセスの AWS アカウント さまざまな段階で中央 が引き受けるように設計された次の IAM ロールを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)各ロールは、最小特権の原則に従って、目的に合わせた特定のアクセス権限が付与されています。`Target_Region` 各ロール名の `Target_Account_ID`と は、これらのロールが異なる AWS アカウント およびリージョン間で一意であることを示すのに役立ちます。このアプローチは、マルチアカウント、マルチリージョンのセットアップで明確な識別と管理に役立ちます。
Target Account CDK Bootstrap Roles
arn:aws:iam:::role/cdk-deploy-role--
arn:aws:iam:::role/cdk-file-publishing-role--
arn:aws:iam:::role/cdk-image-publishing-role--
arn:aws:iam:::role/cdk-lookup-role--
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)中央の OIDC ロールのアクセス許可ポリシーを更新するには AWS アカウント、次のコードを使用します。
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam:::role/cdk-deploy-role--",
                "arn:aws:iam:::role/cdk-file-publishing-role--",
                "arn:aws:iam:::role/cdk-image-publishing-role--",
                "arn:aws:iam:::role/cdk-lookup-role--"
            ]
        }
    ]
 }
| AWS DevOps | ### Docker イメージを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトリポジトリのクローンを作成します。 | 以下のコマンドを実行して、このパターンの [GitHub リポジトリ](https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions)のクローンを作成します。
git clone https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions.git
| AWS DevOps | | Dockerfile パスに移動します。 | Dockerfile パスに移動するには、次のコマンドを実行します。
cd lambda
| AWS DevOps | | Amazon ECR で Docker を認証します。 | Amazon ECR には、プライベートコンテナリポジトリへの安全なアクセスが必要になります。この方法でサインインすると、ローカルマシンまたは CI/CD 環境で Docker が Amazon ECR と安全にやり取りできるようになります。Amazon ECR で Docker を認証するには、次のコマンドを実行します。
aws ecr get-login-password --region  | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com
プレースホルダー `AWS_REGION` および `AWS_Account_ID` を自分の情報に置き換えます。 | AWS DevOps | | Docker イメージを作成します。 | Docker イメージを作成するには、次のコマンドを実行します。
docker build --platform linux/arm64 -t sample-app .
| AWS DevOps | | Docker イメージをタグ付けし、プッシュします。 | 次のコマンドを実行して、Docker イメージを Amazon ECR リポジトリにタグ付けしてプッシュします。
docker tag sample-app:latest .dkr.ecr..amazonaws.com/:
docker push .dkr.ecr..amazonaws.com/:
プレースホルダー `AWS_Account_ID`、`AWS_REGION`、`ECR_REPOSITORY`、`DOCKER_TAG` を自分の情報に置き換えます。 | AWS DevOps | ### AWS CDK アプリをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CDK スタックを環境固有の変数で合成します。 | CDK コードで定義されているインフラストラクチャの CloudFormation テンプレートを生成するには、次のコマンドを実行します。
ENV= IMAGETAG= ECR_ARN= cdk synth
以下のプレースホルダーを自分の情報に置き換えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | AWS DevOps | | CDK スタックをデプロイします。 | CDK スタックを にデプロイするには AWS アカウント、次のコマンドを実行します。`--require-approval never` フラグは、CDK が*すべての*変更を自動的に承認して実行することを意味します。これには、CDK が通常手動レビューを必要とするものとしてフラグを付ける変更 (IAM ポリシーの変更やリソースの削除など) が含まれます。本番環境で `--require-approval never` フラグを使用する前に、CDK コードと CI/CD パイプラインが十分にテストされ、安全であることを確認してください。
ENV= IMAGETAG= ECR_ARN= cdk deploy --require-approval never
| AWS DevOps | ### GitHub Actions ワークフローを使用して CI/CD を自動化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 機能ブランチを作成し、変更を追加します。 | 事前に作成したリポジトリのクローンを使用して機能ブランチを作成し、アプリケーションコードに変更を追加します。次のコマンドを使用します。
git checkout -b 
git add .
git commit -m "add your changes"
git push origin
変更の例を次に示します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)GitHub Actions は再利用可能なワークフローを使用し、CI/CD パイプラインをトリガーします。 | AWS DevOps | | 変更をマージします。 | プルリクエストを作成し、変更点を本文とマージします。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `AccessDenied` リソースを にデプロイする際のエラー。 AWS アカウントたとえば、 です`AccessDenied: User not authorized to perform: "sts:AssumeRole"`。 | この問題を解決するには、以下を実行してクロスアカウントのアクセス権を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | | 旧バージョン CDK の `undefined: awscdkStack` エラーなど、バージョンの不一致による互換性の問題。 | この問題を解決するには、以下を実行して、 AWS CDK と Go の必要なバージョンを使用していることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | | CI/CD パイプラインの失敗や、YAML の設定不備による `Error: No such file or directory`、あるいはブランチが防がれたことによる `Permission denied` などが例として挙げられます。 | GitHub Actions 設定の問題を解決するには、再利用可能なワークフローが正しく参照・設定されていることを確認してください。 | ## 関連リソース 「**AWS リソース**」 + [AWS セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス](https://aws.amazon.com/architecture/security-identity-compliance/) + [AWS CDK ワークショップ](https://cdkworkshop.com/60-go.html) + [AWS クラウド開発キットライブラリ](https://pkg.go.dev/github.com/aws/aws-cdk-go/awscdk/v2) + [コンテナイメージを使用した Lambda 関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html) + [Amazon Elastic Container Registry の Identity and Access Management](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam.html) + [Working with the AWS CDK in Go](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-go.html) **その他のリソース** + [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) (GitHub ドキュメント) + [Go 言語ドキュメント](https://golang.org/doc/) + [Quickstart for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) (GitHub ドキュメント) + [Reusing workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) (GitHub ドキュメント) # GitHub Actions を使用して AWS CloudFormation テンプレートに基づいて AWS Service Catalog 製品をプロビジョニングする *Amazon Web Services、Ashish Bhatt、Ruchika Modi* ## 概要 このパターンは、[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)製品とポートフォリオを使用して標準化され、チーム AWS のサービス 間で準拠したプロビジョニングを行う効率的なアプローチを組織に提供します。 は、Service Catalog 製品とポートフォリオの重要なコンポーネントを組み合わせて、ベースネットワークインフラストラクチャをプロビジョニングする[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)のに役立ちます AWS クラウド。このパターンは、[GitHub Actions](https://github.com/features/actions) を使用して Infrastructure as Code (IaC) を自動開発ワークフローに統合することで、DevOps プラクティスも促進します。 AWS Service Catalog を使用すると、組織は で承認された IT サービスを作成および管理でき AWS、標準化、一元管理、セルフサービスプロビジョニング、コスト管理などのメリットが得られます。GitHub Actions を通じて Service Catalog ポートフォリオと製品のデプロイを自動化することで、組織は以下を実行できます。 + 一貫性のある反復可能なデプロイ。 + IaC のバージョン管理。 + クラウドリソース管理の既存の開発ワークフローとの統合。 この組み合わせにより、手動エラーを減らし、全体的な効率を向上させながら、クラウド運用を合理化し、コンプライアンスを強制し、承認されたサービスの配信を高速化できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + [GitHub リポジトリ](https://docs.github.com/en/get-started/quickstart/create-a-repo)へのアクセス権 + AWS CloudFormation と の基本的な理解 AWS Service Catalog + CloudFormation テンプレートをホストするための Amazon Simple Storage Service (Amazon S3) バケット + GitHub と 間の接続に使用される という名前`github-actions`の AWS Identity and Access Management (IAM) ロール AWS **制限事項** + このパターンの再利用可能なコードは、GitHub Actions でのみテストされています。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 **製品バージョン** このパターンのソリューションは、次の [GitHub Marketplace](https://github.com/marketplace) アクションとそれぞれのバージョンを使用して作成されました。 + `actions/checkout@v4` + `aws-actions/configure-aws-credentials@v2` + `aws-actions/aws-cloudformation-github-deploy@v1.2.0` ## アーキテクチャ このソリューション用のアーキテクチャを次の図に示します。 ![\[GitHub Actions を使用して、CloudFormation テンプレートに基づいて Service Catalog 製品をプロビジョニングします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/49f82fa7-0c74-4581-bf92-95505dca264c/images/a13c7b41-534e-4a9e-bdca-2974fa40a49a.png) 1. 管理者またはプラットフォームエンジニアは、標準化された CloudFormation テンプレートを GitHub リポジトリにプッシュし、そこでテンプレートが維持されます。GitHub リポジトリには、GitHub Actions AWS Service Catalog を使用した のプロビジョニングを自動化するワークフローも含まれています。 1. GitHub Actions は、OpenID Connect (OIDC) プロバイダー AWS クラウド を使用して に接続し、Service Catalog をプロビジョニングするワークフローをトリガーします。 1. Service Catalog には、開発者が標準化された AWS リソースのプロビジョニングに直接使用できるポートフォリオと製品が含まれています。このパターンは、仮想プライベートクラウド (VPCs)、サブネット、NAT およびインターネットゲートウェイ、ルートテーブルなどの AWS リソースをバンドルします。 1. 開発者が Service Catalog 製品を作成すると、Service Catalog はそれを事前設定および標準化された AWS リソースに変換します。その結果、開発者は個々のリソースをプロビジョニングして手動で設定する必要がなくなるため、時間を節約できます。 ## ツール **AWS のサービス** + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。これは、 製品タイプの 1 つとして簡単に使用できるコードとしてのインフラストラクチャ (IaC) サービスです AWS Service Catalog。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を許可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 **その他** + [GitHub Actions](https://docs.github.com/en/actions) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub アクションを使用することで、生成、テスト、デプロイのパイプラインを自動化できます。 **コードリポジトリ** このパターンのコードは、GitHub 内の [service-catalog-with-github-actions](https://github.com/aws-samples/service-catalog-with-github-actions) リポジトリから取得できます。リポジトリには、以下のファイルが含まれます。 + `github/workflows`: + `e2e-test.yaml` – このファイルは[再利用可能なワークフロー](https://docs.github.com/en/actions/sharing-automations/reusing-workflows)である `workflow.yaml` を呼び出します。このワークフローは、ブランチにコミットとプッシュがあるとすぐにトリガーされます。 + `workflow.yaml` – このファイルには、このソリューションの再利用可能なワークフローが含まれており、トリガーとして `workflow_call` が設定されています。再利用可能なワークフローとして、`workflow.yaml` は他のワークフローから呼び出すことができます。 + `templates`: + `servicecatalog-portfolio.yaml` – この CloudFormation テンプレートには、Service Catalog ポートフォリオと Service Catalog 製品をプロビジョニングするリソースが含まれています。テンプレートには、Service Catalog ポートフォリオと製品のプロビジョニング中に使用される一連のパラメータが含まれています。1 つのパラメータは、テンプレートの `vpc.yaml` がアップロードされる Amazon S3 ファイル URL を受け入れます。このパターンには AWS リソースをプロビジョニングする `vpc.yaml` ファイルが含まれていますが、設定に パラメータ S3 ファイル URL を使用することもできます。 + `vpc.yaml` – この CloudFormation テンプレートには、Service Catalog product に追加される AWS リソースが含まれています。 AWS リソースには、VPCs、サブネット、インターネットゲートウェイ、NAT ゲートウェイ、ルートテーブルが含まれます。`vpc.yaml` テンプレートは、Service Catalog 製品およびポートフォリオテンプレートで CloudFormation テンプレートを使用する方法の例です。 ## ベストプラクティス + AWS Service Catalog ドキュメントの[「 のセキュリティのベストプラクティス AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/security-best-practices.html)」を参照してください。 + GitHub ドキュメントの「[Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)」をご確認ください。 ## エピック ### ローカルワークステーションのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ローカルワークステーションに Git をセットアップします。 | Git ドキュメントの「[Getting Started – Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」に記載の手順に従って、ローカルワークステーションへ Git をインストールし、設定します。 | アプリ開発者 | | GitHub プロジェクトリポジトリのクローンを作成します。 | GitHub プロジェクトリポジトリのクローンを作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | DevOps エンジニア | ### OIDC プロバイダーをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | OIDC プロバイダーを設定します。 | AWS 認証情報を存続期間の長い GitHub シークレットとして保存することなく AWS、GitHub Actions ワークフローがリソースにアクセスできるようにする OpenID Connect (OIDC) GitHub プロバイダーを作成します。手順について、詳しくは GitHub ドキュメントの「[Amazon Web Services での OpenID Connect の構成](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」をご確認ください。OIDC プロバイダーが設定されると、[前提条件](#provision-aws-service-catalog-products-using-github-actions-prereqs)で前述した IAM ロール `github-actions` の信頼ポリシーが更新されます。 | AWS 管理者、AWS DevOps、AWS 全般 | ### GitHub Actions パイプラインをトリガーして Service Catalog ポートフォリオと製品をデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `e2e-test.yaml` を更新する。 | この `e2e-test.yaml` ファイルは、`workflow.yaml` で再利用可能なワークフローをトリガーします。`e2e-test.yaml` で次の入力パラメータの値を更新して検証します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | DevOps エンジニア | ### デプロイを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Service Catalog リソースを検証します。 | Service Catalog リソースを検証するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | AWS DevOps | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックを削除します。 | 以下の操作を行い CloudFormation スタックを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html)詳細については、CloudFormation ドキュメントの「[CloudFormation コンソールからスタックを削除する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」をご確認ください。 | DevOps エンジニア、AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `e2e-test``Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '*/home/runner/work/service-catalog-with-github-actions/service-catalog-with-github-actions``Did you forget to run actions/checkout before running your local action?` | 正しいリポジトリ設定が有効になっていることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | ## 関連リソース **AWS ドキュメント** + [Service Catalog の概要](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/what-is_concepts.html) **その他のリソース** + [About events that trigger workflows](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#about-events-that-trigger-workflows) (GitHub ドキュメント) + [Reuse workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) (GitHub ドキュメント) ## 追加情報 [エピック](#provision-aws-service-catalog-products-using-github-actions-epics)に関連するスクリーンショットを表示するには、このパターンの GitHub リポジトリの **[Images]** フォルダに移動してください。次のスクリーンショットを使用できます。 + [AWS Service Catalog ポートフォリオ、管理セクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_portfolio.png) + [AWS Service Catalog product、Administration セクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_Product.png) + [AWS Service Catalog product、ユーザー/プロビジョニングセクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_Product_User.png) # ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする *Benjamin Morris、Nima Fotouhi、Aman Kaur Gandhi、および Chad Moon、Amazon Web Services* ## 概要 パイプラインのスコープを超える AWS Identity and Access Management (IAM) ロールのアクセス許可は、組織に不要なリスクをもたらす可能性があります。開発者は、開発中に広範なアクセス許可を付与することがありますが、コードのトラブルシューティング後にアクセス許可の範囲を絞り込むことを忘れることがあります。これにより、ビジネスニーズのない強力なロールが存在し、セキュリティエンジニアによってレビューされていない可能性がある問題が発生します。 このパターンの場合、問題の解決策としてロールベンディングマシン (RVM) があります。RVM は、一元化された安全なデプロイモデルを使用して、開発者の労力を最小限に抑えながら、個々の GitHub リポジトリのパイプラインに対して最小特権の IAM ロールをプロビジョニングする方法を示します。RVM は中央ソリューションであるため、セキュリティチームを変更の承認に必要なレビューアーとして設定できます。このアプローチにより、セキュリティチームは過剰な権限のパイプラインロールリクエストを拒否できます。 RVM は Terraform コードを入力として受け取り、パイプライン対応の IAM ロールを出力として生成します。必要な入力は、 AWS アカウント ID、GitHub リポジトリ名、およびアクセス許可ポリシーです。RVM はこれらの入力を使用して、ロールの信頼ポリシーとアクセス許可ポリシーを作成します。結果として得られる信頼ポリシーにより、指定された GitHub リポジトリがロールを引き受け、パイプラインオペレーションに使用できます。 RVM は IAM ロール (ブートストラップ中に設定) を使用します。このロールには、組織内の各アカウントで role-provisioning-role を引き受けるアクセス許可があります。ロールは、 AWS Control Tower Account Factory for Terraform (AFT) または AWS CloudFormation StackSets を介して設定されます。role-provisioning-roles は、開発者向けのパイプラインロールを実際に作成するロールです。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + GitHub Actions を通じて Infrastructure as Code (IaC) をデプロイするために使用される GitHub 組織。(GitHub Enterprise/Premium/Ultimate は必要*ありません*** **。) + マルチアカウント AWS 環境。この環境の一部である必要はありません AWS Organizations。 + all AWS アカウント (AFT や CloudFormation StackSets など) に IAM ロールをデプロイするメカニズム。 + Terraform バージョン 1.3 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)。 + Terraform AWS Provider バージョン 4 以降[がインストールされ](https://github.com/hashicorp/terraform-provider-aws/releases)、[設定されています](https://developer.hashicorp.com/terraform/language/providers/configuration)。 **制限事項** + このパターンのコードは GitHub Actions と Terraform に固有のものです。ただし、パターンの一般的な概念は、他の継続的インテグレーションおよびデリバリー (CI/CD) フレームワークで再利用できます。 + 一部の 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)」を参照して、サービスのリンクを選択してください。 ## アーキテクチャ 次の図は、このパターンのワークフローを図解したものです。 ![\[GitHub Actions を使用して IAM ロールの作成とデプロイを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/215c590e-0c84-411d-be6e-b1739f1e19d2/images/82fcdc9f-9576-4e7c-b7fe-b45046ba79d2.png) ロールベンディングマシンは、一般的に以下のステップで使用されます。 1. 開発者は、新しくリクエストされた IAM ロールの Terraform コードを含むコードを RVM GitHub リポジトリにプッシュします。このアクションは、RVM GitHub Actions パイプラインをトリガーします。 1. パイプラインは、OpenID Connect (OIDC) 信頼ポリシーを使用して RVM ロール引き受けロールを引き受けます。 1. RVM パイプラインは実行されると、開発者の新しい IAM ロールをプロビジョニングするアカウントの RVM ワークフローロールを引き受けます。(RVM ワークフローロールは、AFT または CloudFormation StackSets を使用してプロビジョンされました。) 1. RVM は、適切なアクセス許可と信頼を持つ開発者の IAM ロールを作成し、そのロールを他のアプリケーションパイプラインが引き受けられるようにします。 1. アプリ開発者は、この RVM がプロビジョニングしたロールを引き受けるようにアプリパイプラインを設定できます。 作成されたロールには、開発者がリクエストしたアクセス許可と`ReadOnlyAccess` ポリシーが含まれます。ロールを引き受けられるのは、開発者が指定したリポジトリの `main` ブランチに対して実行されるパイプラインだけです。このアプローチで、ロールを使用するためにブランチの保護とレビューを要求できます。 **自動化とスケール** 最小特権のアクセス許可では、プロビジョニングされる各ロールの詳細に注意する必要があります。このモデルにより、これらのロールの作成に必要となる複雑さが軽減され、開発者は追加の学習や多大な労力をかけることなく、必要なロールを作成できます。 ## ツール **AWS のサービス** + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。 **その他のツール** + [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。これには、[組織アカウント](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts)を作成する機能が含まれます。 + [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) は、GitHub リポジトリと密接に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、ビルド、テスト、デプロイパイプラインを自動化できます。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub 内の [role-vending-machine](https://github.com/aws-samples/role-vending-machine) リポジトリで利用できます。 ## ベストプラクティス + **正しい方法は簡単に、間違った方法は難しく** – 正しい方法を簡単に行えるようにします。開発者が RVM プロビジョニングプロセスに苦戦しているときに、他の方法でロールを作成しようとする可能性があります。その場合、RVM の中心的な性質が損なわれます。セキュリティチームが RVM を安全かつ効果的に使用する方法について明確なガイダンスを提供していることを確認します。 また、開発者が間違った方法で作業するのが難しくなるようにする必要があります。サービスコントロールポリシー (SCPs) またはアクセス許可の境界を使用して、他のロールを作成できるロールを制限します。このアプローチによって、ロールの作成を RVM やその他の信頼できるソースのみに制限できます。 + **良い例を提供する** – 一部の開発者は、必然的に非公式テンプレートとして RVM リポジトリ内の既存のロールを適応させ、新しいロールにアクセス許可を付与するようになります。コピー可能な最小限のアクセス許可の例がある場合は、それを提供して、開発者が広範でワイルドカードの多いアクセス許可をリクエストするリスクを軽減できるようにします。多数のワイルドカードを持つアクセス許可の多いロールから開始すると、時間の経過とともにその問題が増大する可能性があります。 + **命名規則と条件を使用する** – 開発者がアプリケーションで作成されるすべてのリソース名を知らなくても、命名規則を使用してロールのアクセス許可を制限する必要があります。例えば、Amazon S3 バケットを作成する場合、リソースキーの値は `arn:aws:s3:::myorg-myapp-dev-*` のようになります。これにより、ロールはその名前に一致するバケット以外のアクセス許可を持たなくなります。IAM ポリシーを使用して命名規則を適用すると、命名規則への準拠が向上するという別の利点があります。これは、一致しないリソースは作成できなくなるためです。 + **プルリクエスト (PR) レビューを要求する** – RVM ソリューションの価値は、新しいパイプラインロールをレビューできる一元的な場所を作成することにあります。ただし、この設計は、安全で質の高いコードが RVM にコミットされるよう保証するガードレールがある場合にのみ役立ちます。コード (`main` など) をデプロイするために使用されるブランチを直接のプッシュから保護し、それらをターゲットとするマージリクエストの承認を要求します。 + **読み取り専用ロールを設定する** – デフォルトでは、RVM はリクエストされた各ロール `readonly` バージョンをプロビジョニングします。このロールは、`terraform plan` パイプラインワークフローなど、データを書き込まない CI/CD パイプラインで使用できます。このアプローチは、読み取り専用ワークフローの動作が異常である場合に、不要な変更を防ぐのに役立ちます。 デフォルトでは、 AWS 管理`ReadOnlyAccess`ポリシーは読み取り専用ロールと読み取り/書き込みロールの両方にアタッチされます。このポリシーによって、必要なアクセス許可を決定する際のイテレーションの必要性を軽減できますが、一部の組織では過度な許可となる場合があります。必要に応じて、Terraform コードからポリシーを削除できます。 + **最小限の権限を付与する** – 最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプルリポジトリを GitHub 組織にコピーします。 | このパターンのリポジトリを[クローン](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)するか、このリポジトリを GitHub 組織に[フォーク](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)して、ニーズに合わせて調整できるようにします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア | | RVM AWS アカウント の を決定します。 | RVM AWS アカウント に使用するインフラストラクチャのデプロイを決定します。管理アカウントまたはルートアカウントを使用しないでください。 | クラウドアーキテクト | | (オプション) 組織のパイプラインに PR の作成を許可します。 | このステップは、`generate_providers_and_account_vars` ワークフローに PR の作成を許可する場合にのみ必要です。組織のパイプラインに PR の作成を許可するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)詳細については、GitHub ドキュメントの「[リポジトリの GitHub Actions の設定を管理する](https://docs.github.com/en/enterprise-server@3.10/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)」を参照してください。 | DevOps エンジニア | | RVM アカウントに読み取り専用アクセス許可を付与します。 | RVM アカウントに読み取り専用アクセス許可を付与する委任ポリシーを管理アカウントに作成します。これにより、RVM GitHub ワークフローは、`generate_providers_and_account_vars.py`スクリプトの実行時に AWS 組織のアカウントのリストを動的にプルできます。次のコードを使用して、 をステップ 2 で選択した AWS アカウント ID ``に置き換えます。
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
| クラウド管理者 | | サンプルリポジトリのデフォルト値を更新します。 | 特定の環境で動作するように RVM を設定するには AWS リージョン、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア | ### インフラストラクチャの初期化 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | RVM リポジトリをブートストラップします。 | このステップは、RVM パイプライン自体で使用される OIDC 信頼ロールと IAM ロールを作成するために必要です。これにより、他のロールの運用と販売を開始できるようになります。RVM アカウントのコンテキストで、`scripts/bootstrap` ディレクトリから `terraform apply` コマンドを手動で実行します。変数ドキュメントに基づいて必要な値を指定します。 | DevOps エンジニア | ### オペレーションの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `github-workflow-rvm` および `github-workflow-rvm-readonly` ロールをすべてのアカウントにデプロイします。 | AFT や StackSets など、組織のプラクティスに沿ったデプロイ方法を選択します。このメソッドを使用して、`scripts/assumed_role/main.tf` ファイル内の 2 つの IAM ロール (デフォルト名 `github-workflow-rvm` と `github-workflow-rvm-readonly`) を、RVM がパイプラインロールを作成できる各アカウントにデプロイします。これらの IAM ロールには、RVM アカウントのロール引き受けロール (または `readonly` と同等のロール) が引き受けることを許可する信頼ポリシーがあります。このロールには、`github-workflow-role-*` に一致するロールの読み取りと書き込み (`readonly` ロールを使用している場合を除く) を許可する IAM アクセス許可ポリシーもあります。 | AWS 管理者 | | `generate_providers_and_account_vars` ワークフローを実行します。 | RVM を設定してパイプラインロールを作成する準備を整えるには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)ワークフローが完了すると、RVM は次を行う準備が整います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | RVM を使用してロールを作成しましたが、GitHub がロールを引き受けることができません。 | GitHub リポジトリの名前が `github_workflow_roles` モジュールに指定された名前と一致していることを確認します。引き受けられるリポジトリが 1 つだけになるように、ロールの範囲が設定されています。同様に、GitHub パイプラインで使用されるブランチが、`github_workflow_roles` モジュールに指定されたブランチの名前と一致することを確認します。通常、書き込み権限を持つ RVM 作成ロールは、`main` ブランチ (つまり、`main` から取得されたデプロイ) を対象とするワークフローでのみ使用できます。 | | 特定のリソースを読み取るアクセス許可がないため、読み取り専用ロールはパイプラインの実行に失敗しています。 | `ReadOnlyAccess` ポリシーには広範な読み取り専用アクセス許可がありますが、一部の読み取りアクション (特定の AWS Security Hub CSPM アクションなど) はありません。`github-workflow-roles` モジュールの `inline_policy_readonly` パラメータを使用して、特定のアクションのアクセス許可を追加できます。 | ## 関連リソース + [Stack AWS CloudFormation StackSets を使用するためのベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-bestpractices.html) + [複数のアカウントを使用した AWS 環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) + [AWS Control Tower Account Factory for Terraform (AFT) の概要](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) + [ポリシーのベストプラクティス](https://docs.aws.amazon.com/codepipeline/latest/userguide/security_iam_service-with-iam-policy-best-practices.html) ## 追加情報 **GitHub 環境の使用** GitHub 環境は、ロールアクセスのブランチベースの制限に代わるアプローチです。GitHub 環境を使用する場合、IAM 信頼ポリシーの追加条件の構文の例は以下のようになります。この構文は、GitHub アクションが `Production` 環境で実行されている場合にのみロールを使用できることを指定します。 ``` "StringLike": { "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production" } ``` 構文の例では、次のプレースホルダー値を使用します。 + `octo-org` は GitHub 組織名です。 + `octo-repo` はリポジトリの名前です。 + `Production` は特定の GitHub 環境名です。 # Amazon CloudWatch メトリクスを CSV ファイルに公開 *Abdullahi Olaoye、Amazon Web Services* ## 概要 このパターンでは、Python スクリプトを使用して Amazon CloudWatch メトリクスを取得し、メトリクス情報をカンマ区切り値 (CSV) ファイルに変換して読みやすくします。このスクリプトは、メトリックスを取得する必要がある AWS サービスを必須の引数として取ります。AWS リージョンと AWS 認証情報プロファイルをオプションの引数として指定できます。これらの引数を指定しない場合、スクリプトはスクリプトが実行されるワークステーションに設定されているデフォルトのリージョンとプロファイルを使用します。スクリプトが実行されると、CSV ファイルが生成され、同じディレクトリに保存されます。 このパターンで提供されるスクリプトと関連ファイルについては、*添付ファイル*セクションを参照してください。 ## 前提条件と制限事項 **前提条件** + Python 3.x + AWS コマンドラインインターフェイス (AWS CLI) **制限事項** このスクリプトでは、現在以下の AWS サービスをサポートします。 + AWS Lambda + Amazon Elastic Compute Cloud (Amazon EC2) + デフォルトでは、スクリプトは Amazon Elastic Block Store (Amazon EBS) ボリュームメトリクスを収集しません。Amazon EBS メトリクスを収集するには、添付 `metrics.yaml` ファイルを変更する必要があります。 + Amazon Relational Database Service (Amazon RDS) + ただし、このスクリプトは Amazon Aurora をサポートしていません。 + Application Load Balancer + Network Load Balancer + Amazon API Gateway ## ツール + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、DevOps エンジニア、開発者、サイト信頼性エンジニア (SRE)、IT マネージャー向けに構築された、モニタリングサービスです。CloudWatch では、データと実用的なインサイトを提供して、アプリケーションのモニタリング、システム全体のパフォーマンスの変化に関する対応、リソース使用率の最適化、および運用状態の統合的な確認を行うことができます。CloudWatch は、ログ、メトリックス、イベントの形式でモニタリングデータと運用データを収集し、AWS とオンプレミスサーバーで実行される AWS のリソース、アプリケーション、サービスを一元的に表示します。 ## エピック ### 前提条件をインストールして設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 前提条件をインストールします。 | 次のコマンドを実行します。
$ pip3 install -r requirements.txt
| 開発者 | | AWS CLI を設定します。 | 次のコマンドを実行します。 
$ aws configure
| 開発者 | ### Python スクリプトを設定します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スクリプトを開きます。 | スクリプトのデフォルト設定を変更するには、`metrics.yaml` を開きます。 | 開発者 | | スクリプトの期間を設定します。 | これは取得する期間です。デフォルト期間は 5 分 (300 秒) です。期間は変更できますが、以下の制限事項に注意します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/publish-amazon-cloudwatch-metrics-to-a-csv-file.html)そうしないと、API オペレーションはデータポイントを返しません。 | 開発者 | | スクリプトの時間を設定します。 | この値には、取得するメトリックスの時間数を指定します。デフォルトは 1 時間です。複数日分のメトリクスを取得するには、値を時間単位で指定します。例えば、2 日間の場合は 48 と指定します。 | 開発者 | | スクリプトの統計値を変更します。 | (オプション) グローバル統計値は `Average` で、特定の統計値が割り当てられていないメトリクスを取得するときに使用されます。このスクリプトは統計値 `Maximum`、`SampleCount`、`Sum` をサポートします。 | 開発者 | ### Python スクリプトを実行する。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スクリプトを実行します。 | 以下のコマンドを使用します。 
$ python3 cwreport.py
サービス値、オプション `region `、`profile ` パラメータのリストを表示するには、以下のコマンドを実行します。
 $ python3 cwreport.py -h
オプションパラメータの詳細については、*追加情報*セクションを参照してください。 | 開発者 | ## 関連リソース + 「[AWS CLI の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」 + [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + 「[Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」 + 「[EC2: CloudWatch - メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics)」 + [AWS Lambda メトリクス](https://docs.aws.amazon.com/lambda/latest/operatorguide/logging-metrics.html) + 「[Amazon RDS メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html#rds-cw-metrics-instance)」 + 「[Application Load Balancer のメトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」 + 「[Network Load Balancer のメトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html)」 + 「[Amazon API Gateway のメトリクス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)」 ## 追加情報 スクリプトの使用法 ``` $ python3 cwreport.py -h ``` シンタックス例 ``` python3 cwreport.py <--region=Optional Region> <--profile=Optional credential profile> ``` **パラメータ** + **service (必須)** ‒ スクリプトを実行したいサービス。スクリプトは現在、AWS Lambda、Amazon EC2、Amazon RDS、Application Load Balancer、Network Load Balancer、API ゲートウェイといったサービスをサポートします。 + **region (オプション)** ‒ メトリックスを取得する AWS リージョン。デフォルトのリージョンは `ap-southeast-1` です。 + **プロファイル (オプション)** ‒ 使用する AWS CLI の名前付きプロファイル。このパラメータを指定しない場合、デフォルトで設定されている認証情報プロファイルが使用されます。 **例** + デフォルトのリージョンと `ap-southeast-1` デフォルトで設定された認証情報を使用して Amazon EC2 メトリックスを取得するには:`$ python3 cwreport.py ec2` + リージョンを指定して API ゲートウェイメトリクスを取得するには:`$ python3 cwreport.py apigateway --region us-east-1` + AWS プロファイルを指定して Amazon EC2 メトリックスを取得するには: `$ python3 cwreport.py ec2 --profile testprofile` + リージョンとプロファイルの両方を指定して、Amazon EC2 メトリックスを取得するには: `$ python3 cwreport.py ec2 --region us-east-1 --profile testprofile` ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/0a915a9d-2eef-4da1-8283-3cf4a115b3b2/attachments/attachment.zip)」 # AWS Lambda オートメーションを使用して 全体の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する *Amazon Web Services、Dr. Rahul Sharad Gaikwad、Tamilselvan P* ## 概要 Active Directory (AD) は、ドメイン情報とネットワークサービスとのユーザーインタラクションを管理する Microsoft スクリプトツールです。これは、従業員の認証情報とアクセス許可を管理するために、マネージドサービスプロバイダー (MSP) の間で広く使用されています。AD 攻撃者は非アクティブなアカウントを使用して組織をハッキングしようとするため、非アクティブなアカウントを見つけて定期的なメンテナンススケジュールで無効にすることが重要です。を使用すると AWS Directory Service for Microsoft Active Directory、Microsoft Active Directory をマネージドサービスとして実行できます。このパターンは、非アクティブなアカウントをすばやく見つけて削除するように AWS Lambda 自動化を設定するのに役立ちます。 次のシナリオが組織に当てはまる場合、このパターンが役立ちます。 + **一元化された AD 管理** – 組織に複数の があり AWS アカウント、それぞれに独自の AD デプロイがある場合、すべてのアカウントでユーザーアカウントとアクセス許可を一貫して管理するのは難しい場合があります。アカウント間の AD クリーンアップソリューションを使用すると、すべての AD インスタンスから非アクティブなアカウントを一元的に無効化または削除できます。 + **AD の再構築または移行** – 組織が AD デプロイを再構築または移行する場合、アカウント間の AD クリーンアップソリューションが環境の準備に役立ちます。このソリューションを使用すると、不要なアカウントや非アクティブなアカウントを削除し、移行プロセスを簡素化し、潜在的な競合や問題を減らしやすくなります。 このパターンを使用すると、次のような利点があります。 + データベースとサーバーのパフォーマンスを向上させ、非アクティブなアカウントのセキュリティの脆弱性を修正します。 + AD サーバーがクラウドでホストされている場合、非アクティブなアカウントを削除すると、パフォーマンスを向上させながらストレージコストを削減することもできます。帯域幅料金とコンピューティングリソースの両方が下がることがあるため、月額請求額が減る可能性があります。 + クリーンな Active Directory を使用して、潜在的な攻撃者を阻止しましょう。 ## 前提条件と制限 **前提条件** + アクティブな親アカウント AWS アカウント と 1 つ以上の子アカウント。このパターンでは、*親アカウント*は Active Directory が作成される場所です。*子アカウント*は Windows サーバーをホストし、親アカウントの Active Directory を介して結合されます。 + ローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。 + ローカルワークステーションに[インストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)および設定されている Terraform。 + AWS Managed Microsoft AD 親アカウントで設定され、すべての子アカウントと共有される ディレクトリ。詳細については、 *AWS Directory Service 管理ガイド*の[「チュートリアル: シームレスな EC2 ドメイン参加のための AWS Managed Microsoft AD ディレクトリの共有](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」を参照してください。 + 仮想プライベートクラウド (VPC) ピアリング接続、または AWS Directory Service (親アカウント) の VPC と Amazon Elastic Compute Cloud (Amazon EC2) インスタンス (子アカウント) の VPC の間で利用可能な AWS Transit Gateway 接続。詳細は、*AWS Directory Service 管理ガイド*で「[Configure a VPC peering connection between the directory owner and the directory consumer account](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html#step1_configure_owner_account_vpc)」を参照してください。 + すべての親アカウントと子アカウントで `EC2WindowsUserdata` スクリプトで設定された Windows マシン。スクリプトファイルは、このパターンの[コードリポジトリ](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/tree/main/multiple-account-cleanup)のルートにあります。 + 親アカウントからの AWS Lambda 関数の使用を許可する信頼ポリシーで設定された各子アカウントで使用可能なクロスアカウント AWS Identity and Access Management (IAM) ロール。詳細については、[「Amazon EventBridge ユーザーガイド」の「Amazon EventBridge AWS アカウント での 間のイベントの送受信](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatchEvents-CrossAccountEventDelivery.html)」を参照してください。 * EventBridge * + 親アカウントの Parameter Store AWS Systems Manager で使用できる次のシークレット値。 + `domainJoinUser` – ディレクトリサービスのユーザー名 + `domainJoinPassword` – ディレクトリサービスのパスワード シークレットの詳細については、「 *AWS Secrets Manager ユーザーガイド*」の「 [AWS Secrets Manager シークレットの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。 **制限事項** + 子アカウントでのリソースの作成は、Terraform では自動化されません。 AWS マネジメントコンソールを使用して、次のリソースを手動で作成する必要があります。 + Amazon EC2 終了イベントを親アカウントに送信する Amazon EventBridge ルール + 信頼ポリシーを持つ子アカウントでの Amazon EC2 クロスアカウントロールの作成 + VPC ピアリングまたは Transit Gateway 接続 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。 **製品バージョン** + [Terraform バージョン 1.1.9 以降](https://developer.hashicorp.com/terraform/install) + [Terraform AWS プロバイダーバージョン 3.0 以降](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade) ## アーキテクチャ 次の図は、ソリューションの高レベルアーキテクチャを示しています。 ![\[Lambda オートメーションを使用して、AWS アカウント間から EC2 エントリを削除するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c397d873-e10d-44b6-8352-5f1380ab94ca/images/bd6c80a7-e490-47db-bd47-165314e1ea8a.png) アーキテクチャ図は次のプロセスを示しています。 1. 子アカウントで、EventBridge ルールはすべての Amazon EC2 終了イベントを収集します。ルールは、親アカウントに存在する EventBridge にこれらのイベントを送信します。 1. 親アカウントから、EventBridge はすべてのイベントを収集します。EventBridge には、Lambda 関数 `ADcleanup-Lambda` をトリガーするルールが含まれます。 1. 親アカウントは、親アカウントまたは子アカウントから終了イベントを受け取り、Lambda 関数をトリガーします。 1. Lambda 関数は、Python boto モジュールを使用して Amazon EC2 Auto Scaling グループを呼び出し、ランダムなインスタンス ID を取得します。インスタンス ID は、Systems Manager コマンドを実行するために使用されます。 1. Lambda 関数は、boto モジュールを使用して Amazon EC2 に別の呼び出しを行います。Lambda 関数は、実行中の Windows サーバーのプライベート IP アドレスを取得し、そのアドレスを一時変数に保存します。ステップ 5.1 および 5.2 では、実行中の Windows EC2 インスタンスが子アカウントから収集されます。 1. Lambda 関数は、Systems Manager をもう一度呼び出して、 AWS Directory Serviceに接続されているコンピュータ情報を取得します。 1. AWS Systems Manager ドキュメントは、Amazon EC2 Windows サーバーで PowerShell コマンドを実行して、AD に接続されているコンピュータのプライベート IP アドレスを取得するのに役立ちます。(Systems Manager ドキュメントは、ステップ 4 で取得したインスタンス ID を使用します。) 1. AD ドメインのユーザー名とパスワードは Parameter Store AWS Systems Manager に保存されます。 AWS Lambda Systems Manager は Parameter Store を呼び出し、AD への接続に使用するユーザー名とパスワードの値を取得します。 1. Systems Manager ドキュメントを使用し、ステップ 4 で先ほど取得したインスタンス ID を使用して PowerShell スクリプトが Amazon EC2 Windows サーバーで実行されます。 1. Amazon EC2 は PowerShell コマンド AWS Directory Service を使用して に接続し、使用されていないコンピュータや非アクティブのコンピュータを削除します。 ## ツール **AWS サービス** + [AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) には、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon FSx for Windows File Server AWS のサービス など、他の で Microsoft Active Directory (AD) を使用する複数の方法が用意されています。 + [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 クラウド。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。IAM を使用すると、 のサービスとリソースにアクセスできるユーザーまたはユーザーを指定し AWS、きめ細かなアクセス許可を一元管理し、アクセスを分析してアクセス許可を絞り込むことができます AWS。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 + [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)は、Systems Manager がマネージドインスタンスで実行するアクションを定義します。Systems Manager には、ランタイムでパラメータを指定して使用できる事前設定済みのドキュメントが 100 件以上含まれています。 + [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は の機能であり、設定データ管理 AWS Systems Manager とシークレット管理のための安全な階層型ストレージを提供します。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ infrastructure as code (IaC) ツールです。 + [PowerShell](https://learn.microsoft.com/en-us/powershell/) は Windows、Linux、および macOS で動作するMicrosoft の自動化および構成管理プログラムです。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[aws-lambda-ad-cleanup-terraform-samples](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/tree/main/multiple-account-cleanup)」リポジトリで利用できます。 ## ベストプラクティス + **自動的にドメインを結合します。** Directory Service ドメインの一部となる Windows インスタンスを起動する場合は、後でインスタンスを手動で追加するのではなく、インスタンスの作成プロセス中にドメインに参加します。自動的にドメインを結合するには、新しいインスタンスを起動するときに、**ドメイン結合ディレクトリ**の適切なディレクトリを選択します。詳細については、 *Directory Service 管理ガイド*[のAmazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory にシームレスに結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)」を参照してください。 + **未使用のアカウントを削除します。**AD では、使用されたことがないアカウントがよく見られます。システム内に残っている無効または非アクティブなアカウントと同様に、未使用のアカウントを無視すると、AD システムが遅くなったり、組織がデータ侵害に対して脆弱になる可能性があります。 + **Active Directory のクリーンアップを自動化します。**セキュリティリスクを軽減し、古いアカウントが AD のパフォーマンスに影響を与えないようにするには、AD クリーンアップを定期的に実行する必要があります。スクリプトを記述することで、ほとんどの AD 管理タスクとクリーンアップタスクを実行できます。タスクの例としては、無効なアカウントと非アクティブなアカウントの削除、空のグループと非アクティブなグループの削除、期限切れのユーザーアカウントとパスワードの特定などがあります。 ## エピック ### 子アカウントをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 子アカウントにクロスアカウントロールを作成します。 | 子アカウントにクロスアカウントロールを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | | 子アカウントでイベントルールを作成します。 | 子アカウントごとに EventBridge ルールを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)詳細については、*Amazon EventBridge ユーザーガイド*の「[Creating rules that react to events in Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)」を参照してください。 | DevOps エンジニア | | EC2 インスタンスを作成し、AD に結合します。 | Windows 用の EC2 インスタンスを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | ### ローカルワークステーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトフォルダを作成し、ファイルを追加します。 | リポジトリを複製し、プロジェクトフォルダを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | | `adcleanup.zip` ファイルを構築します。 | `lambda_function.py` ファイルを圧縮するには、次のコマンドを実行します。`zip -r adcleanup.zip lambda_function.py` | DevOps エンジニア | ### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Terraform 変数の値を指定します。 | 子アカウントの場合、`terraform.tfvars` ファイルに文字列型として次の `arn` 変数の値を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | | Terraform の設定を初期化します。 | Terraform ファイルを含む作業ディレクトリを初期化するには、次のコマンドを実行します。`terraform init` | DevOps エンジニア | | 変更のプレビュー | インフラストラクチャがデプロイされる前に、Terraform がインフラストラクチャに加える変更をプレビューできます。Terraform が必要に応じて変更を行うことを確認するには、次のコマンドを実行します。`terraform plan —-var-file=examples/terraform.tfvars` | DevOps エンジニア | | 提案されたアクションを実行します。 | `terraform plan` コマンドの結果が期待どおりであることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を実行およびテストします。 | デプロイが正常に行われたことを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)実行結果には、関数の出力が表示されます。 | DevOps エンジニア | | 親アカウントの EventBridge ルール実行の結果を表示します。 | 親アカウントの Amazon EC2 終了イベントに基づく EventBridge ルールの結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア | | 子アカウントの EventBridge ルール実行の結果を表示します。 | 子アカウントの Amazon EC2 終了イベントに基づく EventBridge ルールの結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア | ### 使用後にインフラストラクチャをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy``destroy` コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア | | クリーンアップ後に確認します。 | リソースが正常に削除されたことを確認します。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS Directory Service (親アカウント) と Amazon EC2 インスタンス (子アカウント) 間の接続の問題 – VPC ピア接続が使用可能であっても、子アカウントのコンピュータを AD に参加させることはできません。 | VPC にルーティングを追加します。手順については、 AWS Directory Service ドキュメントの[「ディレクトリ所有者とディレクトリコンシューマーアカウント間の VPC ピアリング接続を設定する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html#step1_configure_owner_account_vpc)」を参照してください。 | ## 関連リソース **AWS ドキュメント** + [Amazon EventBridge と AWS Identity and Access Management](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-iam.html) + [Systems Manager に必要なインスタンスのアクセス許可を設定する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) + [の ID とアクセスの管理 Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/iam_auth_access.html) + [Lambda のアイデンティティベースの IAM ポリシー](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html) + [Amazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory に手動で結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html) + [AWS Lambda オートメーションを使用して同じ の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html) **その他のリソース** + [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Terraform ドキュメント) + [バックエンド設定](https://developer.hashicorp.com/terraform/language/backend) (Terraform ドキュメント) + [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) (Terraform ドキュメント) + [Python boto モジュール](https://pypi.org/project/boto/) (Python Package Index リポジトリ) + [Terraform バイナリダウンロード](https://www.terraform.io/downloads) (Terraform ドキュメント) # AWS Lambda オートメーションを使用して AWS アカウント から同じ の Amazon EC2 AWS Managed Microsoft AD エントリを削除する *Amazon Web Services、Dr. Rahul Sharad Gaikwad、Tamilselvan P* ## 概要 Active Directory (AD) は、ドメイン情報とネットワークサービスとのユーザーインタラクションを管理する Microsoft スクリプトツールです。これは、従業員の認証情報とアクセス許可を管理するために、マネージドサービスプロバイダー (MSP) の間で広く使用されています。AD 攻撃者は非アクティブなアカウントを使用して組織をハッキングしようとするため、非アクティブなアカウントを見つけて定期的なメンテナンススケジュールで無効にすることが重要です。を使用すると AWS Directory Service for Microsoft Active Directory、Microsoft Active Directory をマネージドサービスとして実行できます。 このパターンは、非アクティブなアカウントをすばやく見つけて削除するように AWS Lambda 自動化を設定するのに役立ちます。このパターンを使用すると、次のような利点があります。 + データベースとサーバーのパフォーマンスを向上させ、非アクティブなアカウントのセキュリティの脆弱性を修正します。 + AD サーバーがクラウドでホストされている場合、非アクティブなアカウントを削除すると、パフォーマンスを向上させながらストレージコストを削減することもできます。帯域幅料金とコンピューティングリソースの両方が下がることがあるため、月額請求額が減る可能性があります。 + クリーンな Active Directory を使用して、潜在的な攻撃者を阻止しましょう。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + ローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。 + ローカルワークステーションに[インストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)および設定されている Terraform。 + Active Directory モジュール (`ActiveDirectory`) を搭載した Windows コンピュータ。 + パラメータストアの パラメータに保存されている AWS Managed Microsoft AD および 認証情報のディレクトリ。 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) + AWS Identity and Access Management [「 ツール](#remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad-tools)」に AWS のサービス リストされている へのアクセス許可を持つ (IAM) ロール*。*IAM の詳細については、「[関連リソース](#remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad-resources)」を参照してください。 **制限事項** + このパターンは、クロスアカウント設定をサポートしていません。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。 **製品バージョン** + [Terraform バージョン 1.1.9 以降](https://developer.hashicorp.com/terraform/install) + [Terraform AWS プロバイダーバージョン 3.0 以降](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade) ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[Lambda オートメーションを使用して Managed Microsoft AD から EC2 エントリを削除するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6b50dcc5-4f4b-4eea-85a7-04cebc9f7454/images/b7fc5962-bfb8-4f5a-968e-7487b1d48c4f.png) この図表は、次のワークフローを示しています: 1. Amazon EventBridge は、cron 式に基づいて AWS Lambda 関数をトリガーします。(このパターンでは、cron 式スケジュールは 1 日に 1 回です)。 1. 必要な IAM ロールとポリシーが作成され、Terraform AWS Lambda を介して にアタッチされます。 1. AWS Lambda 関数が実行され、Python boto モジュールを使用して Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling Groups を呼び出します。Lambda 関数はランダムなインスタンス ID を取得します。インスタンス ID は AWS Systems Manager コマンドの実行に使用されます。 1. AWS Lambda は、boto モジュールを使用して Amazon EC2 に別の呼び出しを行い、実行中の Windows サーバーのプライベート IP アドレスを取得し、そのアドレスを一時変数に保存します。 1. AWS Lambda は、Systems Manager をもう一度呼び出して、接続されているコンピュータ情報を取得します Directory Service。 1. AWS Systems Manager ドキュメントは、Amazon EC2 Windows サーバーで PowerShell スクリプトを実行して、AD に接続されているコンピュータのプライベート IP アドレスを取得するのに役立ちます。 1. AD ドメインのユーザー名とパスワードは Parameter Store AWS Systems Manager に保存されます。 AWS Lambda Systems Manager は Parameter Store を呼び出し、AD の接続に使用するユーザー名とパスワードの値を取得します。 1. Systems Manager ドキュメントを使用し、ステップ 3 で先ほど取得したインスタンス ID を使用して PowerShell スクリプトが Amazon EC2 Windows サーバーで実行されます。 1. Amazon EC2 Directory Service は PowerShell コマンドを使用して接続し、使用されていないコンピュータや非アクティブのコンピュータを削除します。 ## ツール **AWS サービス** + [AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon FSx for Windows File Server AWS のサービス など、他の で Microsoft Active Directory (AD) を使用する複数の方法を提供します。 + [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 クラウド。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWSリソースへのアクセスを安全に管理するのに役立ちます。IAM を使用すると、 のサービスとリソースにアクセスできるユーザーまたはユーザーを指定し AWS、きめ細かなアクセス許可を一元管理し、アクセスを分析してアクセス許可を絞り込むことができます AWS。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 + [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)は、Systems Manager がマネージドインスタンスで実行するアクションを定義します。Systems Manager には、ランタイムでパラメータを指定して使用できる事前設定済みのドキュメントが 100 件以上含まれています。 + [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は の機能であり、設定データ管理 AWS Systems Manager とシークレット管理のための安全な階層型ストレージを提供します。 **その他のツール** + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つオープンソースの infrastructure as code (IaC) ツールです。 + [PowerShell](https://learn.microsoft.com/en-us/powershell/) は Windows、Linux、および macOS で動作するMicrosoft の自動化および構成管理プログラムです。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コ****ードリポジトリ** このパターンのコードは、GitHub 内の「[カスタム AD クリーンアップオートメーションソリューション](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/)」リポジトリで利用できます。 ## ベストプラクティス + **自動的にドメインを結合します。** Directory Service ドメインの一部となる Windows インスタンスを起動する場合は、後でインスタンスを手動で追加するのではなく、インスタンスの作成プロセス中にドメインに参加します。自動的にドメインを結合するには、新しいインスタンスを起動するときに、**ドメイン結合ディレクトリ**の適切なディレクトリを選択します。詳細については、 *Directory Service 管理ガイド*[のAmazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory にシームレスに結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)」を参照してください。 + **未使用のアカウントを削除します。**AD では、使用されたことがないアカウントがよく見られます。システム内に残っている無効または非アクティブなアカウントと同様に、未使用のアカウントを無視すると、AD システムが遅くなったり、組織がデータ侵害に対して脆弱になる可能性があります。 + **Active Directory のクリーンアップを自動化します。**セキュリティリスクを軽減し、古いアカウントが AD のパフォーマンスに影響を与えないようにするには、AD クリーンアップを定期的に実行する必要があります。スクリプトを記述することで、ほとんどの AD 管理タスクとクリーンアップタスクを実行できます。タスクの例としては、無効なアカウントと非アクティブなアカウントの削除、空のグループと非アクティブなグループの削除、期限切れのユーザーアカウントとパスワードの特定などがあります。 ## エピック ### 環境をセットアップします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトフォルダを作成し、ファイルを追加します。 | リポジトリを複製し、プロジェクトフォルダを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | ### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Terraform の設定を初期化する | Terraform ファイルを含む作業ディレクトリを初期化するには、次のコマンドを実行します。`terraform init` | DevOps エンジニア | | 変更のプレビュー | インフラストラクチャがデプロイされる前に、Terraform がインフラストラクチャに加える変更をプレビューできます。Terraform が必要に応じて変更を行うことを確認するには、次のコマンドを実行します。`terraform plan` | DevOps エンジニア | | 提案されたアクションを実行します。 | `terraform plan` コマンドの結果が期待どおりであることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html) | DevOps エンジニア | | インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy`destroy コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数を実行およびテストします。 | デプロイが正常に行われたことを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html)実行結果には、関数の出力が表示されます。 | DevOps エンジニア | | Lambda 関数の結果を表示します。 | このパターンでは、EventBridge ルールは Lambda 関数を 1 日に 1 回実行します。Lambda 関数の結果を表示するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア | ### 使用後にインフラストラクチャをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy`destroy コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア | | クリーンアップ後に確認します。 | リソースが正常に削除されたことを確認します。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AD コンピュータを削除しようとすると、「アクセスが拒否されました」というメッセージが表示されます。デフォルトでは、アクションは AD サービスの一部として接続されている 2 つのプライベート IP アドレスを削除しようとするため、AD コンピュータを削除することはできません。 | このエラーを回避するには、AD コンピュータ出力と Windows を実行しているマシンの出力の違いを一覧表示するときに、次の Python オペレーションを使用して最初の 2 つのコンピュータを無視します。
Difference = Difference[2:]
| | Lambda は Windows サーバーで PowerShell スクリプトを実行する場合、Active Directory モジュールがデフォルトで使用可能であることを想定します。モジュールが使用できない場合、Lambda 関数は「Get-AdComputer is not installed on instance」というエラーを作成します。 | このエラーを回避するには、EC2 インスタンスのユーザーデータを使用して必要なモジュールをインストールします。このパターンの GitHub リポジトリにある [EC2WindowsUserdata](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/blob/main/EC2WindowsUserdata) スクリプトを使用します。 | ## 関連リソース **AWS ドキュメント** + [Amazon EventBridge と AWS Identity and Access Management](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-iam.html) + [Systems Manager に必要なインスタンスのアクセス許可を設定する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html) + [の ID とアクセスの管理 Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/iam_auth_access.html) + [Amazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory に手動で結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html) + [でのアイデンティティベースの IAM ポリシーの使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html) **その他のリソース** + [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Terraform ドキュメント) + [バックエンド設定](https://developer.hashicorp.com/terraform/language/backend) (Terraform ドキュメント) + [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) (Terraform ドキュメント) + [Python boto モジュール](https://pypi.org/project/boto/) (Python Package Index リポジトリ) + [Terraform バイナリダウンロード](https://www.terraform.io/downloads) (Terraform ドキュメント) # pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行する *Praveen Kumar Jeyarajan と Vaidy Sankaran、Amazon Web Services* ## 概要 [ローカル開発環境で](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-libraries.html) の Python 抽出、変換、ロード (ETL) ジョブ AWS Glue のユニットテストを実行できますが、DevOps パイプラインでこれらのテストをレプリケートするのは困難で時間がかかる場合があります。 AWS テクノロジースタックでメインフレーム ETL プロセスをモダナイズする場合、ユニットテストは特に難しい場合があります。このパターンは、既存の機能をそのまま維持し、新機能をリリースしたときに主要なアプリケーション機能の中断を回避し、高品質のソフトウェアを維持しながら、ユニットテストを簡素化する方法を示しています。このパターンのステップとコードサンプルを使用して、pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行できます AWS CodePipeline。このパターンを使用して、複数の AWS Glue ジョブをテストおよびデプロイすることもできます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Amazon ECR Public Gallery からダウンロードした AWS Glue ライブラリの Amazon Elastic Container Registry (Amazon ECR) イメージ URI [https://gallery.ecr.aws/glue/aws-glue-libs](https://gallery.ecr.aws/glue/aws-glue-libs) + ターゲット AWS アカウント と のプロファイルを持つ Bash ターミナル (任意のオペレーティングシステム上) AWS リージョン + [Python 3.10](https://www.python.org/downloads/) 以降 + [Pytest](https://github.com/pytest-dev/pytest) + テスト用の [Moto](https://github.com/getmoto/moto) Python ライブラリ AWS のサービス ## アーキテクチャ 次の図は、Python に基づく AWS Glue ETL プロセスのユニットテストを一般的なエンタープライズスケールの AWS DevOps パイプラインに組み込む方法を示しています。 ![\[AWS Glue ETL プロセスのユニットテスト。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/82781ca8-4da0-4df0-bf23-32992fece231/images/6286dafc-f1e0-4967-beed-4dedc6047c10.png) この図表は、次のワークフローを示しています: 1. ソースステージでは、 AWS CodePipeline はバージョニングされた Amazon Simple Storage Service (Amazon S3) バケットを使用して、ソースコードアセットを保存および管理します。これらのアセットには、サンプル Python ETL ジョブ (`sample.py`)、ユニットテストファイル (`test_sample.py`)、 AWS CloudFormation テンプレートが含まれます。次に、CodePipeline は最新のコードをメインブランチから AWS CodeBuild プロジェクトに転送し、さらに処理します。 1. ビルドおよび公開ステージでは、前のソースステージの最新のコードは、 AWS Glue パブリック Amazon ECR イメージを使用してユニットテストされます。次に、テストレポートが CodeBuild レポートグループに公開されます。 AWS Glue ライブラリのパブリック Amazon ECR リポジトリのコンテナイメージには、 で [PySpark ベースの](https://spark.apache.org/docs/latest/api/python/) ETL タスクを AWS Glue ローカルで実行およびユニットテストするために必要なすべてのバイナリが含まれています。パブリックコンテナリポジトリには、 AWS Glueがサポートするバージョンごとに 1 つずつ、合計 3 つのイメージタグがあります。デモンストレーションの目的から、このパターンでは `glue_libs_4.0.0_image_01` image タグを使用しています。このコンテナイメージを CodeBuild のランタイムイメージとして使用するには、使用する予定のイメージタグに対応するイメージ URI をコピーし、`TestBuild` リソースの GitHub リポジトリ内の `pipeline.yml` ファイルを更新します。 1. デプロイ段階では、CodeBuild プロジェクトが起動され、すべてのテストに合格すると Amazon S3 バケットにコードが公開されます。 1. ユーザーは、 `deploy`フォルダの CloudFormation テンプレートを使用して AWS Glue タスクをデプロイします。 ## ツール **AWS のサービス** + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。 + [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) はフルマネージド型の ETL サービスです。これにより、データストアとデータストリーム間でのデータの分類、整理、強化、移動を確実に行うことができます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。 **その他のツール** + [Python](https://www.python.org/) は、高水準のインタープリター型汎用プログラミング言語です。 + [Moto](https://github.com/getmoto/moto) はテスト用の Python ライブラリです AWS のサービス。 + [Pytest](https://github.com/pytest-dev/pytest) は、アプリケーションやライブラリの複雑な機能テストをサポートするように拡張できる小規模なユニットテストを作成するためのフレームワークです。 + の [Python ETL ライブラリ](https://github.com/awslabs/aws-glue-libs) AWS Glue は、PySpark バッチジョブのローカル開発で使用される Python ライブラリのリポジトリです AWS Glue。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[aws-glue-jobs-unit-testing](https://github.com/aws-samples/aws-glue-jobs-unit-testing)」リポジトリで利用できます。リポジトリには次のリソースが含まれています。 + `src` フォルダ内のサンプル Python ベースの AWS Glue ジョブ + `tests` フォルダ内の関連ユニットテストケース (pytest フレームワークを使用して構築) + `deploy` フォルダ内の CloudFormation テンプレート (YAML で記述) ## ベストプラクティス **CodePipeline リソースのセキュリティ** CodePipeline のパイプラインに接続するソースリポジトリに暗号化と認証を使用することがベストプラクティスです。詳細については、CodePipeline ドキュメントの「[Security best practices](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)」を参照してください。 **CodePipeline リソースで使用するモニタリングとログ記録** AWS ログ記録機能を使用して、ユーザーがアカウントで実行するアクションと使用するリソースを決定するのがベストプラクティスです。ログファイルには次の内容が表示されます。 + アクションが実行された日時 + アクション送信元 IP アドレス + 不適切なアクセス権限が理由で失敗したアクション ログ記録機能は、 AWS CloudTrail および Amazon CloudWatch Events で使用できます。CloudTrail を使用して、 によって、または に代わって行われた AWS API コールおよび関連イベントを記録できます AWS アカウント。詳細については、CodePipeline ドキュメントの「[Logging CodePipeline API calls with AWS CloudTrail](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring-cloudtrail-logs.html)」を参照してください。 CloudWatch Events を使用して、 で実行されている AWS クラウド リソースとアプリケーションをモニタリングできます AWS。CloudWatch イベントでアラートを作成することもできます。詳細については、CodePipeline ドキュメントの「[CodePipeline イベントのモニタリング](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)」を参照してください。 ## エピック ### ソースコードをデプロイするには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードアーカイブをデプロイ用に準備する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | DevOps エンジニア | | CloudFormation スタックを更新する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html)スタックは、Amazon S3 をソースとして使用して CodePipeline ビューを作成します。上記のステップでは、パイプラインは **aws-glue-unit-test-pipeline** です。 | AWS DevOps、DevOps エンジニア | ### ユニットテストを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パイプラインでユニットテストを実行する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | AWS DevOps、DevOps エンジニア | ### すべての AWS リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 環境内のリソースをクリーンアップする。 | 追加のインフラストラクチャコストを避けるため、このパターンで提供されている例を試した後は、必ずスタックを削除してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | CodePipeline サービスロールは Amazon S3 バケットにアクセスできません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | | CodePipeline は、Amazon S3 バケットがバージョニングされていないというエラーを返します。 | CodePipeline では、ソース Amazon S3 バケットがバージョニングされている必要があります。Amazon S3 バケットのバージョニングを有効にします。手順については、「[バケットでのバージョニングの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html)」を参照してください。 | ## 関連リソース + [AWS Glue](https://aws.amazon.com/glue/) + [ローカルでの AWS Glue ジョブの開発とテスト](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-libraries.html) + [の AWS CloudFormation AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/populate-with-cloudformation-templates.html) ## 追加情報 さらに、 AWS Command Line Interface () を使用して AWS CloudFormation テンプレートをデプロイできますAWS CLI。詳細については、CloudFormation ドキュメントの「[変換が含まれるテンプレートの迅速なデプロイ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-cli-deploy.html)」を参照してください。 # AWS CodePipeline と AWS CDK を使用して CI/CD パイプラインを設定する *Amazon Web Services、Konstantin Zarudaev、Yasha Dabas、Lars Kinder、Cizer Pereira* ## ホーム 継続的インテグレーションおよび継続的デリバリー (CI/CD) によるソフトウェアのビルドとリリースのプロセスを自動化することで、繰り返しビルドが可能になり、ユーザーへの新機能の迅速な提供が可能になります。各コード変更をすばやく簡単にテストでき、ソフトウェアをリリースする前にバグを見つけて修正できます。各変更をステージングとリリースのプロセスで実行することで、アプリケーションやインフラストラクチャコードの品質を検証できます。CI/CD は、アプリケーション開発チームがコード変更をより頻繁かつ確実に行うのに役立つ文化、一連の運用原則、[一連のプラクティス](https://aws.amazon.com/devops/#cicd)を体現しています。この実装は *CI/CD パイプライン*とも呼ばれます。 このパターンは、AWS CodeCommit リポジトリを使用して、Amazon Web Services (AWS) での再利用可能な継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを定義します。AWS CodePipeline パイプラインは、[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) v2 を使用して作成されています。 CodePipeline を使用すると、AWS マネジメントコンソールインターフェイス、AWS コマンドラインインターフェイス (AWS CLI)、AWS CloudFormation、または AWS SDK を使用して、ソフトウェアリリースプロセスのさまざまな段階をモデル化することができます。このパターンは、AWS CDK を使用して CodePipeline とそのコンポーネントを実装する方法を示しています。ライブラリを構築することに加えて、AWS CDK には AWS CDK アプリケーションを操作するための主要なツールであるツールキット (CLI コマンド `cdk`) が含まれています。他の機能の中でも、このツールキットには、1 つ以上のスタックを CloudFormation テンプレートに変換して AWS アカウントにデプロイする機能があります。 パイプラインにはサードパーティライブラリのセキュリティを検証するテストが含まれており、指定された環境で迅速かつ自動的なリリースを保証するのに役立ちます。アプリケーションを検証プロセスにかけることで、アプリケーション全体のセキュリティを強化できます。 このパターンの目的は、デプロイするリソースが DevOps のベストプラクティスに従っていることを確認しながら、CI/CD パイプラインを使用してコードをデプロイする時間を短縮することです。[サンプルコード](https://github.com/aws-samples/aws-codepipeline-cicd)を実装すると、リンティング、テスト、セキュリティチェック、デプロイ、およびデプロイ後のプロセスを含む [AWS CodePipeline](https://aws.amazon.com/codepipeline/) が完成します。このパターンには Makefile のステップも含まれています。Makefile を使用すると、デベロッパーは CI/CD のステップをローカルで再現し、開発プロセスのスピードを上げることができます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + 基本的な理解は以下のとおりです。 + AWS CDK + AWS CloudFormation + AWS CodePipeline + TypeScript **制限** このパターンでは、TypeScript のみに [AWS CDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html) を使用します。AWS CDK でサポートされている他の言語は対象外です。 **製品バージョン** 次のツールの最新バージョンを使用します。 + AWS コマンドラインインターフェイス (AWS CLI) + cfn\$1nag + git-remote-codecommit + Node.js ## アーキテクチャ **ターゲットテクノロジースタック** + AWS CDK + AWS CloudFormation + AWS CodeCommit + AWS CodePipeline **ターゲットアーキテクチャ** パイプラインは、AWS CodeCommit リポジトリ (`SampleRepository`) の変更によってトリガーされます。最初に、CodePipeline はアーティファクトをビルドし、それ自体を更新し、デプロイプロセスを開始します。作成されたパイプラインは、次の 3 つの独立した環境に解決策をデプロイします。 + 開発 – アクティブな開発環境での 3 段階のコードチェック + テスト – 統合/リグレッションテスト環境 + 本番 – 本番環境 開発段階には、リンティング、セキュリティ、ユニットテストの 3 つのステップが含まれます。これらの手順はプロセスを高速化するために並行して実行されます。パイプラインが動作するアーティファクトのみを提供するようにするため、プロセス内のステップが失敗するたびにパイプラインの実行が停止されます。開発段階のデプロイ後、パイプラインは検証テストを実行して結果を検証します。成功すると、パイプラインはデプロイ後の検証を含むテスト環境にアーティファクトをデプロイします。最後のステップは、アーティファクトを Prod 環境にデプロイすることです。 次の図は、CodeCommit リポジトリから CodePipeline によって実行されるビルドおよび更新プロセスまでのワークフロー、3 つの開発環境ステップ、および 3 つの環境のそれぞれにおけるその後のデプロイと検証を示しています。 ![\[各工程にデプロイと検証を含む、リンティング、セキュリティ検査、ユニットテストを含む開発環境。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d617e735-8624-4722-8a3d-073bcc356328/images/92504aac-03e3-4c95-b225-74505f8dd136.png) ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。このパターンでは、CloudFormation テンプレートを使用して CodeCommit リポジトリと CodePipeline CI/CD パイプラインを作成できます。 + [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 **その他のツール** + [cfn\$1nag](https://github.com/stelligent/cfn_nag) は、CloudFormation テンプレートのパターンを探して潜在的なセキュリティ問題を特定するオープンソースのツールです。 + [git-remote-codecommit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html) は、Git を拡張して CodeCommit リポジトリからコードをプッシュおよびプルするためのユーティリティです。 + [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 **コード** このパターンのコードは、GitHub 内の「[AWS CodePipeline with CI/CD practices](https://github.com/aws-samples/aws-codepipeline-cicd)」リポジトリで利用できます。 ## ベストプラクティス AWS Identity and Access Management (IAM) ポリシーなどのリソースを確認して、組織のベストプラクティスに沿っていることを確認します。 ## エピック ### ツールをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | macOS または Linux にツールをインストールします。 | macOS または Linux を使用している場合は、任意のターミナルで次のコマンドを実行するか、[Homebrew for Linux](https://docs.brew.sh/Homebrew-on-Linux) を使用してツールをインストールできます。
brew install
brew install git-remote-codecommit
brew install ruby brew-gem
brew-gem install cfn-nag
| DevOps エンジニア | | AWS CLI をセットアップします。 | AWS CLI を設定するには、お使いのオペレーティングシステムの手順に従ってください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | DevOps エンジニア | ### 初期のデプロイをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コードをダウンロードまたはクローンします。 | このパターンで使用されるコードを取得するには、以下のいずれかを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html)
git clone --depth 1 https://github.com/aws-samples/aws-codepipeline-cicd.git
クローニングしたリポジトリから `.git` ディレクトリを削除します。
cd ./aws-codepipeline-cicd
rm -rf ./.git
後で、新しく作成した AWS CodeCommit リポジトリをリモートオリジンとして使用します。 | DevOps エンジニア | | AWS アカウントに接続します。 | 一時的なセキュリティトークンまたはランディングゾーン認証を使用して接続できます。正しいアカウントと AWS リージョンを使用していることを確認するには、以下のコマンドを実行します。
AWS_REGION="eu-west-1"
ACCOUNT_NUMBER=$(aws sts get-caller-identity --query Account --output text)
echo "${ACCOUNT_NUMBER}"
| DevOps エンジニア | | 環境を起動します。 | AWS CDK 環境を起動するには、以下のコマンドを実行します。
npm install
npm run cdk bootstrap "aws://${ACCOUNT_NUMBER}/${AWS_REGION}"
環境を正常に起動すると、次の出力が表示されるはずです。
⏳  Bootstrapping environment aws://{account}/{region}...
✅  Environment aws://{account}/{region} bootstrapped
AWS CDK 起動の詳細については、[AWS CDK のドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)を参照してください。 | DevOps エンジニア | | テンプレートを合成します。 | AWS CDK アプリケーションを合成するには、`cdk synth` コマンドを使用します。
npm run cdk synth
次のような出力が表示されます。
Successfully synthesized to /aws-codepipeline-cicd/cdk.out
Supply a stack id (CodePipeline, Dev-MainStack) to display its template.
| DevOps エンジニア | | CodePipeline スタックをデプロイします。 | CloudFormation テンプレートを起動して合成したので、デプロイできます。デプロイすると、CodePipeline パイプラインと CodeCommit リポジトリが作成されます。これらは、パイプラインのソースとトリガーになります。
npm run cdk -- deploy CodePipeline --require-approval never
コマンドを実行すると、CodePipeline スタックが正常にデプロイされ、情報が出力されるはずです。`CodePipeline.RepositoryName` により、AWS アカウントの CodeCommit リポジトリの名前が表示されます。
CodePipeline: deploying...
CodePipeline: creating CloudFormation changeset...
✅  CodePipeline
Outputs:
CodePipeline.RepositoryName = SampleRepository
Stack ARN:
arn:aws:cloudformation:REGION:ACCOUNT-ID:stack/CodePipeline/STACK-ID
| DevOps エンジニア | | リモート CodeCommit リポジトリとブランチを設定します。 | デプロイが成功すると、CodePipeline はパイプラインの最初の実行を開始します。この実行は [AWS CodePipeline コンソール](https://eu-west-1.console.aws.amazon.com/codesuite/codepipeline/pipelines)で確認できます。AWS CDK と CodeCommit はデフォルトブランチを開始しないため、この最初のパイプライン実行は失敗し、次のエラーメッセージが返されます。
The action failed because no branch named main was found in the selected AWS CodeCommit repository SampleRepository. Make sure you are using the correct branch name, and then try again. Error: null
このエラーを修正するには、リモートオリジンを `SampleRepository` として設定し、必要な `main` ブランチを作成します。
RepoName=$(aws cloudformation describe-stacks --stack-name CodePipeline --query "Stacks[0].Outputs[?OutputKey=='RepositoryName'].OutputValue" --output text)
echo "${RepoName}"
#
git init
git branch -m master main
git remote add origin codecommit://${RepoName}
git add .
git commit -m "Initial commit"
git push -u origin main
| DevOps エンジニア | ### デプロイされた CodePipeline パイプラインをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 変更をコミットしてパイプラインを有効にします。 | 初期デプロイメントが成功すると、`SampleRepository` の `main` ブランチをソースブランチとして持つ完全な CI/CD パイプラインが完成するはずです。`main` ブランチに変更をコミットするとすぐに、パイプラインは次の一連のアクションを開始して実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | DevOps エンジニア | ### Makefile を使用してローカルでテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Makefile を使用して開発プロセスを実行します。 | `make` コマンドを使用してパイプライン全体をローカルで実行することも、個別のステップ (`make linting` など) を実行することもできます。`make` を使用してテストするには、次のアクションを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | アプリ開発者、DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CDK アプリケーションリソースを削除します。 | AWS CDK アプリをクリーンアップするには、次のコマンドを実行します。
cdk destroy --all
起動中に作成された Amazon Simple Storage Service (Amazon S3) バケットは、自動的に削除されないことに注意してください。削除を許可する保持ポリシーが必要か、AWS アカウントで手動で削除する必要があります。 | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | テンプレートが期待どおりに動作しません。 | 何か問題が発生し、テンプレートが機能しない場合は、次があることを確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | ## 関連リソース + [IAM アイデンティティセンターで一般的なタスクを開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) + [AWS CodePipeline ドキュメント](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) # Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する *Amazon Web Services、Aarti Rajput、Yashwant Patel、Nishtha Yadav* ## 概要 一元化されたログ記録は、組織のクラウドインフラストラクチャにとって不可欠です。これにより、組織の運用、セキュリティ、コンプライアンスを可視化できるためです。組織が複数のアカウントにまたがって AWS 環境をスケールするにつれて、構造化ログ管理戦略は、セキュリティ運用の実行、監査要件を満たすこと、運用上の優秀性を達成するための基本となります。 このパターンは、複数の AWS アカウント および サービスからのログを一元化するためのスケーラブルで安全なフレームワークを提供し、複雑な AWS デプロイ全体でエンタープライズ規模のログ記録管理を可能にします。このソリューションは、Terraform を使用して自動化されます。Terraform は HashiCorp の Infrastructure as Code (IaC) ツールであり、一貫性のある反復可能なデプロイを保証し、手動設定を最小限に抑えます。Amazon CloudWatch Logs、Amazon Data Firehose、Amazon Simple Storage Service (Amazon S3) を組み合わせることで、以下を実現する堅牢なログ集約と分析パイプラインを実装できます。 + での組織全体の一元化されたログ管理 AWS Organizations + 組み込みのセキュリティコントロールを使用した自動ログ収集 + スケーラブルなログ処理と耐久性のあるストレージ + シンプルなコンプライアンスレポートと監査証跡 + リアルタイムの運用に関するインサイトとモニタリング このソリューションは、CloudWatch Logs を介して Amazon Elastic Kubernetes Service (Amazon EKS) コンテナ、 AWS Lambda 関数、Amazon Relational Database Service (Amazon RDS) データベースインスタンスからログを収集します。CloudWatch サブスクリプションフィルターを使用して、これらのログを専用のログ記録アカウントに自動的に転送します。Firehose は、Amazon S3 への高スループットのログストリーミングパイプラインを管理し、長期保存を可能にします。Amazon Simple Queue Service (Amazon SQS) は、オブジェクトの作成時に Amazon S3 イベント通知を受信するように設定されています。これにより、以下を含む分析サービスとの統合が可能になります。 + ログ検索、視覚化、リアルタイム分析のための Amazon OpenSearch Service + SQL ベースクエリ用の Amazon Athena + 大規模な処理のための Amazon EMR + カスタム変換のための Lambda + ダッシュボード用の Amazon Quick Sight すべてのデータは AWS Key Management Service (AWS KMS) を使用して暗号化され、インフラストラクチャ全体が Terraform を使用して環境間で一貫した設定でデプロイされます。 この一元的なログ記録アプローチにより、組織はセキュリティ体制を改善し、コンプライアンス要件を維持し、 AWS インフラストラクチャ全体の運用効率を最適化できます。 ## 前提条件と制限 **前提条件** + [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) を使用して構築された組織のランディングゾーン + 必要なアカウントでデプロイおよび設定された [Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html) + インフラストラクチャをプロビジョニングするための [Terraform](https://developer.hashicorp.com/terraform/downloads) + クロスアカウントアクセス用の [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html) ロールとポリシー アカウント AWS Control Tower、AFT、およびアプリケーションアカウントを設定する手順については、[「エピック」セクション](#set-up-centralized-logging-at-enterprise-scale-by-using-terraform-epics)を参照してください。 **必要なアカウント** の組織には、次のアカウントを含める AWS Organizations 必要があります。 + **アプリケーションアカウント** – AWS のサービス (Amazon EKS、Lambda、Amazon RDS) が実行され、ログを生成する 1 つ以上のソースアカウント + **ログアーカイブアカウント** – 一元化されたログの保管と管理を行うための専用アカウント **製品バージョン** + [AWS Control Tower バージョン 3.1](https://docs.aws.amazon.com/controltower/latest/userguide/2023-all.html#lz-3-1) 以降 + [Terraform バージョン 0.15.0](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) 以降 ## アーキテクチャ 次の図は、複数のアプリケーションアカウントから専用のログアーカイブアカウントにログを収集、処理、保存するためのスケーラブルなソリューションを提供する一 AWS 元的なログ記録アーキテクチャを示しています。このアーキテクチャは AWS のサービス、Amazon RDS、Amazon EKS、Lambda などの からのログを効率的に処理し、合理化されたプロセスを通じて Log Archive アカウントのリージョン S3 バケットにルーティングします。 ![\[複数のアプリケーションアカウントからログを収集する AWS の一元化されたログ記録アーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9fc71a10-65d6-437b-9128-cc27bda11af4/images/2e916040-0f11-4712-a8dd-31c95194ce5d.png) ワークフローには 5 つのプロセスが含まれます。 1. **ログフロープロセス** + ログフロープロセスはアプリケーションアカウントで開始されます。アプリケーションアカウントでは、一般ログ、エラーログ、監査ログ、Amazon RDS からのスロークエリログ、Amazon EKS からのコントロールプレーンログ、Lambda からの関数の実行ログとエラーログなど、さまざまなタイプのログ AWS のサービス が生成されます。 + CloudWatch は最初の収集ポイントとして機能します。これらのログは、各アプリケーションアカウント内のロググループレベルで収集されます。 + CloudWatch では、[サブスクリプションフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)によって、中央アカウントに転送するログを判断します。これらのフィルターを使用すると、ログ転送をきめ細かく制御できるため、正確なログパターンや完全なログストリームを指定して一元化できます。 1. **クロスアカウントログ転送** + ログはログアーカイブアカウントに移動します。CloudWatch サブスクリプションフィルターによって、クロスアカウント転送が容易になり、リージョンコンテキストが保持されます。 + このアーキテクチャは、さまざまなログソースを効率的に処理するために複数の並列ストリームを確立して、最適なパフォーマンスとスケーラビリティを確保します。 1. **ログアーカイブアカウントでのログ処理** + ログアーカイブアカウントでは、Firehose が受信ログストリームを処理します。 + 各リージョンは、必要に応じてログを変換、または強化できる専用の Firehose 配信ストリームを維持します。 + これらの Firehose ストリームは、データ主権要件を維持するために、ソースアプリケーションアカウント (図のリージョン A) と同じリージョンにあるログアーカイブアカウントの S3 バケットに処理されたログを配信します。 1. **通知と追加のワークフロー** + ログが宛先の S3 バケットに到達すると、アーキテクチャは Amazon SQS を使用して通知システムを実装します。 + リージョン SQS キューは、非同期処理を有効にし、保存されたログに基づいて追加のワークフロー、分析、またはアラートシステムをトリガーできます。 1. **AWS KMS セキュリティ用** このアーキテクチャには、セキュリティ AWS KMS のために が組み込まれています。 は S3 バケットの暗号化キー AWS KMS を提供します。これにより、保存されているすべてのログが保存中の暗号化を維持するとともに、リージョンでの暗号化を保つことで、データレジデンシー要件を満たすことが保証されます。 ## ツール **AWS のサービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、ログ、メトリクス、イベントの形式でモニタリングおよび運用データを収集するモニタリングおよびオブザーバビリティサービスです。AWS サーバーとオンプレミスサーバーで実行される AWS リソース、アプリケーション、サービスの統合ビューを提供します。 + [CloudWatch Logs サブスクリプションフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html)は、受信ログイベントのパターンに一致し、一致するログイベントを指定された AWS リソースに配信して、さらなる処理または分析を行う式です。 + [AWS Control Tower Account Factory For Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。AFT は Terraform ベースのアカウントプロビジョニングを提供し、アカウントを管理できるようにします AWS Control Tower。 + [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service などの送信先にリアルタイムのストリーミングデータを配信します。これはデータのスループットに合わせて自動的に拡張し、継続的な管理作業は不要です。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、Kubernetes を使用してコンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするマネージドコンテナオーケストレーションサービスです。Kubernetes コントロールプレーンノードの可用性とスケーラビリティを自動で管理します。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データを暗号化するための暗号化キーを作成および制御します。 は、他の と AWS KMS 統合 AWS のサービス して、これらのサービスで保存するデータを保護します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理をする必要なくコードを実行できるサーバーレスコンピューティングサービスです。各トリガーに応じてコードを実行することでアプリケーションを自動でスケーリングします。使用したコンピューティング時間に対してのみ料金が発生します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) は、クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングすることのできるマネージドリレーショナルデータベースです。時間のかかる管理タスクを自動化しながら、コスト効率が高くサイズ変更可能な容量を提供します。 + [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) は、マイクロサービス、分散システム、およびサーバーレスアプリケーションの疎結合化とスケールを可能にするメッセージキューイングサービスです。メッセージ指向ミドルウェアの管理と運用の複雑さを解消します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、スケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するクラウドベースのオブジェクトストレージサービスです。ウェブ上の任意の場所から、任意の量のデータを保存および取得できます。 **その他のツール** + [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **Code** このパターンのコードは GitHub 内の [Centralized logging](https://github.com/aws-samples/sample-centralised-logging-at-enterprise-scale-using-terraform) リポジトリで入手できます。 ## ベストプラクティス + [の 1 つの組織 AWS アカウント で複数の を使用します AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html)。この方法により、アカウント間で一元的な管理と標準化されたログ記録が可能になります。 + [S3 バケットのバージョニング、ライフサイクルポリシー、クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)を設定します。セキュリティとコンプライアンスのため、暗号化とアクセスのログ記録を実装します。 + 標準のタイムスタンプとフィールドを含む、[JSON 形式を使用した一般的なログ記録標準](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html)を実装します。追跡と分析を容易にするために、一貫したプレフィックス構造と相関 ID を使用します。 + [AWS KMS 暗号化と最小特権アクセスを使用してセキュリティコントロール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)を有効にします。セキュリティを強化するために、 AWS CloudTrail モニタリングと定期的なキーローテーションを維持します。 + 配信追跡用の [CloudWatch メトリクスとアラート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)を設定します。自動通知を使用してコストとパフォーマンスをモニタリングします。 + コンプライアンス要件を満たすように [Amazon S3 保持ポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を設定し、Amazon S3 サーバーアクセスログ記録を有効にして、S3 バケットに対して行われたすべてのリクエストを追跡します。S3 バケットポリシーとライフサイクルルールのドキュメントを維持管理します。アクセスログ、バケットのアクセス許可、ストレージ設定を定期的に見直して、コンプライアンスと[セキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)を確保します。 ## エピック ### セットアップ AWS Control Tower、AFT、およびアプリケーションアカウント | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AFT を使用して AWS Control Tower 環境をセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | AWS 管理者 | | 組織のリソース共有を有効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | AWS 管理者 | | アプリケーションアカウントを検証またはプロビジョニングします。 | ユースケース用に新しいアプリケーションアカウントをプロビジョニングするには、AFT を介してアカウントを作成します。詳細については、 AWS Control Tower ドキュメント[の「AFT を使用して新しいアカウントをプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)する」を参照してください。 | AWS 管理者 | ### アプリケーションアカウントの設定ファイルを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `Application_account` フォルダの内容を `aft-account-customizations` リポジトリにコピーします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | アプリケーションアカウントを設定するための入力パラメータを確認して編集します。 | このステップでは、CloudWatch ロググループ、CloudWatch サブスクリプションフィルター、IAM ロールとポリシー、Amazon RDS、Amazon EKS、Lambda 関数の設定詳細など、アプリケーションアカウントにリソースを作成するための設定ファイルを設定します。`aft-account-customizations` リポジトリの `Application_account` フォルダで、組織の要件に基づいて `terraform.tfvars` ファイルの入力パラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | ### ログアーカイブアカウントの設定ファイルを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `Log_archive_account` フォルダの内容を `aft-account-customizations` リポジトリにコピーします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | ログアーカイブアカウントを設定するための入力パラメータを確認して編集します。 | このステップでは、Firehose 配信ストリーム、S3 バケット、SQS キュー、IAM ロールとポリシーなど、ログアーカイブアカウントにリソースを作成するための設定ファイルを設定します。`aft-account-customizations` リポジトリの `Log_archive_account` フォルダで、組織の要件に基づいて `terraform.tfvars` ファイルの入力パラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | ### Terraform コマンドを実行してリソースをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オプション 1 – AFT から Terraform 設定ファイルをデプロイします。 | AFT では、設定変更を含むコードを GitHub `aft-account-customizations` リポジトリにプッシュすると、AFT パイプラインがトリガーされます。AFT は変更を自動的に検出し、アカウントのカスタマイズプロセスを開始します。Terraform (`terraform.tfvars`) ファイルに変更を加えたら、変更をコミットして `aft-account-customizations` リポジトリにプッシュします。
$ git add *
$ git commit -m "update message"
$ git push origin main
別のブランチ (`dev` など) を使用している場合は、`main` をブランチ名に置き換えます。 | DevOps エンジニア | | オプション 2 – Terraform 設定ファイルを手動でデプロイします。 | AFT を使用していない場合、またはソリューションを手動でデプロイする場合は、`Application_account` および `Log_archive_account` フォルダから次の Terraform コマンドを使用できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | ### リソースを検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションフィルターを検証します。 | サブスクリプションフィルターがアプリケーションアカウントのロググループからログアーカイブアカウントにログを正しく転送することを検証するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | Firehose ストリームを確認します。 | ログアーカイブアカウントの Firehose ストリームがアプリケーションログを正常に処理することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | 一元化された S3 バケットを検証します。 | 一元化された S3 バケットがログを適切に受信して整理することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | SQS キューを検証します。 | SQS キューが新しいログファイルの通知を受信することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オプション 1 – AFT から Terraform 設定ファイルを削除します。 | Terraform 設定ファイルを削除して変更をプッシュすると、AFT は自動的にリソース削除プロセスを開始します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | | オプション 2 – Terraform リソースを手動でクリーンアップします。 | AFT を使用していない場合、またはリソースを手動でクリーンアップする場合は、`Application_account` および `Log_archive_account` フォルダから次の Terraform コマンドを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | CloudWatch Logs の送信先が作成されていないか、非アクティブです。 | 以下を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | | サブスクリプションフィルターが失敗した、または保留中のステータスのままです。 | 以下をチェックしてください:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | | Firehose 配信ストリームに受信レコードが表示されません。 | 以下について確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | ## 関連リソース + [Terraform infrastructure setup](https://developer.hashicorp.com/terraform/tutorials/aws-get-started) (Terraform ドキュメント) + [Account AWS Control Tower Factory for Terraform (AFT) をデプロイ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)する (AWS Control Tower ドキュメント) + [IAM チュートリアル: IAM ロール AWS アカウント を使用して 全体でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する (IAMdocumentation) # cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定 *Mahendra Revanasiddappa と Vasanth Jeyaraj、Amazon Web Services* ## 概要 エンドツーエンド暗号化の実装は複雑で、マイクロサービスアーキテクチャ内の各アセットの証明書を管理する必要があります。Amazon Web Services (AWS) ネットワークの端にあるTransport Layer Security (TLS) 接続は、Network Load Balancer または Amazon API Gateway を使用して終了できますが、一部の組織ではエンドツーエンドの暗号化が必要です。 このパターンでは、入力に NGINX Ingress コントローラーを使用します。これは、Kubernetes Ingress を作成する場合、イングレスリソースがNetwork Load Balancer を使用するためです。Network Load Balancer は、クライアント証明書のアップロードを許可しません。したがって、Kubernetes Ingress では相互TLSを実現できません。 このパターンは、アプリケーション内のすべてのマイクロサービス間の相互認証を必要とする組織を対象としています。相互 TLS は、ユーザー名やパスワードを管理する負担を軽減し、すぐに使えるセキュリティフレームワークを使用することもできます。このパターンのアプローチは、接続されているデバイスが多数ある組織や、厳格なセキュリティガイドラインに準拠する必要がある場合にも適合します。 このパターンは、Amazon Elastic Kubernetes Service (Amazon EKS) 上で実行されるアプリケーションにエンドツーエンドの暗号化を実装することで、組織のセキュリティ体制強化に役立ちます。このパターンでは、「[Amazon EKS リポジトリの GitHub エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」 のサンプルアプリケーションとコードを提供し、マイクロサービスが Amazon EKS でエンドツーエンド暗号化を使用してどのように実行されるかを示します。このパターンのアプローチでは、Kubernetes のアドオンである「[cert-manager](https://cert-manager.io/docs/)」 を使用し、認証局 (CA) として 「[Let's Encrypt](https://letsencrypt.org/)」 を使用します。Let's Encrypt は費用対効果の高い証明書管理ソリューションで、90 日間有効な証明書を無料で提供しています。Cert-manager は、新しいマイクロサービスが Amazon EKS にデプロイされたときに、証明書のオンデマンドプロビジョニングとローテーションを自動化します。  **対象者** このパターンは、Kubernetes、TLS、Amazon Route 53、およびドメインネームシステム (DNS) の使用経験があるユーザーに推奨されます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + 既存の Amazon EKS クラスター。 + macOS、Linux、または Windows にインストールされ、設定された AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降。 + Amazon EKS クラスターにアクセスするために、インストールおよび設定された `kubectl` コマンドラインユーティリティ。これについての詳細は、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」 を参照してください。 + アプリケーションをテストするための既存のアプリケーション名です。これについての詳細は、Amazon Route 53 デベロッパーガイドの「 [Amazon Route 53 を使用したドメイン名の登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)」を参照してください。  + ローカルマシンにインストールされている最新の 「[Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 バージョン。これについての詳細は、Amazon EKS ドキュメントの「[Amazon EKS での Helm の使用](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 と GitHub 「[Helm](https://github.com/helm/helm)」 リポジトリを参照してください。  + ローカルマシンに複製された GitHub 「[Amazon EKS リポジトリの エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」。  + 複製された GitHub 「[Amazon EKS リポジトリのエンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」から `policy.json` と `trustpolicy.json` のファイルの以下の値を置き換えます: + `` — ソリューションをデプロイするアカウントの AWS アカウント ID と置き換えます。  + `` — ドメイン名の Route 53 ゾーン ID に置き換えます。  + `` — Amazon EKS ノードに関連付けられている AWS 識別とアクセス管理(IAM) ロールの名前に置き換えます。 + `` — NGINX Ingress コントローラーとサンプルアプリケーションをデプロイする Kubernetes 名前空間に置き換えます。 + `` — Route 53 の DNS ドメイン名に置き換えます。 **制限事項** + このパターンでは、証明のローテーション方法を説明するものではなく、Amazon EKS のマイクロサービスで証明書を使用する方法のみを示しています。  ## アーキテクチャ 次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。 ![\[cert-manager と Let's Encrypt を使用して Amazon EKS のアプリケーションの暗号化を設定するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png) この図表は、次のワークフローを示しています: 1. クライアントは DNS 名へのアプリケーションへのアクセスリクエストを送信します。 1. Route 53 レコードは Network Load Balancer の CNAMEです。 1. Network Load Balancer は、TLS リスナーで設定された NGINX Ingress コントローラーにリクエストを転送します。NGINX Ingress コントローラーと Network Load Balancer 間の通信は HTTPS プロトコルに従います。 1. NGINX Ingress Controller は、アプリケーションサービスへのクライアントのリクエストに基づいてパスベースのルーティングを実行します。 1. アプリケーションサービスはリクエストをアプリケーションポッドに転送します。このアプリケーションは、シークレットを呼び出すことで。同じ証明書を使用するように設計されています。 1. ポッドは cert-managerの証明書を使用してサンプルアプリケーションを実行します。NGINX Ingress コントローラーとポッド間の通信には HTTPS が使用されます。 | | | 注: cert-managerはその独自の名前空間で実行されます。Kubernetes クラスターロールを使用して、証明書を特定の名前空間のシークレットとしてプロビジョニングします。これらの名前空間はアプリケーションポッドと NGINX Ingress コントローラーにアタッチできます。 | | --- | ## ツール **AWS サービス** + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、AWS で Kubernetes を簡単に実行できるようにするマネージド型サービスです。ユーザー独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、維持する必要はありません。 + [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信したトラフィックを複数のターゲット、コンテナ、IPアドレスに自動的に分散します。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 **その他のツール** + 「[cert-manager](https://cert-manager.io/docs/installation/supported-releases/)」 は Kubernetes のアドオンで、証明書をリクエストして Kubernetes コンテナに配布し、証明書の更新を自動化します。 + 「[NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/) 」は、Kubernetes およびコンテナ化された環境におけるクラウドネイティブアプリケーション向けのトラフィック管理ソリューションです。 ## エピック ### Route 53 でパブリックホストゾーンを作成して設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Route 53 にドメインのパブリックホストゾーンを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開き、［**ホストゾーン**］を選択し、［**ホストゾーンの作成**］を選択します。パブリックホストゾーンを作成し、ゾーン ID を記録します。これについての詳細は、Amazon Route 53 ドキュメントの「[公開ホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)」を参照してください。ACME DNS01 は DNS プロバイダーを使用して、証明書発行用の cert-manager にチャレンジを投稿します。このチャレンジでは、ドメイン名の TXT レコードに特定の値を入力して、そのドメイン名の DNS を管理していることを証明するよう求められます。Let's Encrypt が ACME クライアントにトークンを渡した後、クライアントはそのトークンとアカウントキーから得た TXT レコードを作成し、そのレコードを `_acme-challenge.` に保存します。次に、Let's Encrypt は DNS にそのレコードを問い合わせます。一致するものが見つかったら、証明書の発行に進むことができます。 | AWS DevOps | ### 証明書マネージャーがパブリックホストゾーンにアクセスできるように IAM ロールを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | cert-manager 用の IAM ポリシーを作成します。 | ユーザーが Route 53 ドメインを所有していることを検証する権限を cert-manager に提供するには、IAM ポリシーが必要です。`policy.json` のサンプル IAM ポリシーが、複製されたGitHub「[ Amazon EKS リポジトリのエンドツーエンドの暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」リポジトリの `1-IAMRole` ディレクトリにあります。次の AWS CLI コマンドを使用して、IAM ポリシーを作成します。
aws iam create-policy \
  --policy-name PolicyForCertManager \
  --policy-document file://policy.json
| AWS DevOps | | cert-managerの IAM ロールを作成します。 | IAM ポリシーを作成したら、IAM ロールを作成する必要があります。`trustpolicy.json` サンプル IAM ロールが `1-IAMRole` ディレクトリに提供されます。IAM ロールを作成するには、次のコマンドをAWS CLIに入力します。
aws iam create-role \
  --role-name RoleForCertManager \
  --assume-role-policy-document file://trustpolicy.json
| AWS DevOps | | ロールへのポリシーの付与 | AWS CLI に以下のコマンドを入力して、 IAM ロールにIAMポリシーをアタッチします。`AWS_ACCOUNT_ID` を自分の AWS アカウントのID に置き換えます。
aws iam attach-role-policy \
  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \
  --role-name RoleForCertManager
| AWS DevOps | ### Amazon EKS で NGINX Ingress コントローラーをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | NGINX Ingress コントローラーをデプロイします。 | Helm を使用する `nginx-ingress` の最新バージョンをインストールします。デプロイする前に、要件に応じて `nginx-ingress` の設定を変更できます。このパターンでは、`5-Nginx-Ingress-Controller` ディレクトリの使用可能の注釈付き、内部向けのNetwork Load Balancer を使用します。 `5-Nginx-Ingress-Controller` ディレクトリから次の Helm コマンドを実行して、 NGINX Ingress コントローラーをインストールします。`helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml` | AWS DevOps | | コントローラーがインストールされていることを確認します。 | `helm list` コマンドを入力します。出力では NGINX Ingress コントローラーがインストールされていることが表示されるはずです。 | AWS DevOps | | Route 53 A レコードを作成します。 | A レコードは NGINX Ingress コントローラーによって作成された Network Load Balancer を指します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | ### Amazon EKS に NGINX 仮想サーバーをセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | NGINX 仮想サーバーをデプロイします。 | NGINX VirtualServer リソースは、イングレスリソースの代替となるロードバランシング設定です。NGINX VirtualServer リソースを作成するための設定は、`6-Nginx-Virtual-Server` ディレクトリの `nginx_virtualserver.yaml` のファイルで利用可能です。NGINX VirtualServer リソースを作成するには、`kubectl` に以下のコマンドを入力します。`kubectl apply -f  nginx_virtualserver.yaml``nginx_virtualserver.yaml` ファイルのアプリケーションドメイン名、証明書シークレット、アプリケーションサービス名の更新を必ず行ってください。 | AWS DevOps | | NGINX 仮想サーバーが作成されていることを確認します。 | `kubectl` にある以下のコマンドを入力して、NGINX VirtualServer リソースが正常に作成されたことを確認します。`kubectl get virtualserver``Host` 列がアプリケーションのドメイン名と一致することを確認します。 | AWS DevOps | | TLS を有効にして NGINX ウェブサーバーをデプロイします。 | このパターンでは、TLS が有効になっている NGINX Web サーバーを、エンドツーエンドの暗号化をテストするためのアプリケーションとして使用します。テストアプリケーションのデプロイに必要な設定ファイルは、`demo-webserver` のディレクトリに使用可能です。 アプリケーションのテストを行うには、次のコマンドを`kubectl` に入力します。`kubectl apply -f nginx-tls-ap.yaml` | AWS DevOps | | テストアプリケーションリソースが作成されたことを確認します。 | 次のコマンドを `kubectl` に入力して、テストアプリケーションに必要なリソースが作成されていることを確認します[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | | アプリケーションを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | ## 関連リソース 「**AWS リソース**」 + 「[Amazon Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」 (Amazon Route 53 ドキュメント) + 「[Amazon EKS の NGINX イングレスコントローラーでのNetwork Load Balancer の使用](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/)」 (AWS ブログ投稿) **その他のリソース** + 「[Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/)」 (cert-managerドキュメント) + 「[DNS01 チャレンジプロバイダーの設定](https://cert-manager.io/docs/configuration/acme/dns01/)」 (cert-managerドキュメント) + 「[Let’s Encrypt DNS チャレンジ](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge)」(Let’s Encrypt ドキュメント) # Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する *Nadeem Rahaman、Aditya Ambati、Aniket Dekate、Shrikant Patil、Amazon Web Services* ## 概要 製品やサービスを提供する多くの企業は、社内のビジネス機能間のデータバリアを維持するためにデータ規制が必要とされる業界です。このパターンでは、Amazon Elastic Kubernetes Service (Amazon EKS) のマルチテナンシー機能を使用して、単一の Amazon EKS クラスターを共有するテナントまたはユーザー間で論理的および物理的な分離を実現するデータプラットフォームを構築する方法について説明します。このパターンは、以下のアプローチを通じて分離を実現します。 + Kubernetes 名前空間の分離 + ロールベースのアクセスコントロール (RBAC) + ネットワークポリシー + リソースクォータ + AWS Identity and Access Management サービスアカウント (IRSA) の (IAM) ロール また、このソリューションは Flux を使用して、アプリケーションをデプロイするときにテナント設定をイミュータブルに保ちます。設定に Flux `kustomization.yaml` ファイルを含むテナントリポジトリを指定することにより、テナントアプリケーションをデプロイできます。 このパターンでは、以下を実装します。 + AWS CodeCommit Terraform スクリプトを手動でデプロイすることで作成されるリポジトリ、 AWS CodeBuild プロジェクト、 AWS CodePipeline パイプライン。 + テナントをホストするために必要なネットワークコンポーネントとコンピューティングコンポーネント。これらは、Terraform を使用して CodePipeline と CodeBuild を介して作成されます。 + Helm チャートで設定されるテナント名前空間、ネットワークポリシー、リソースクォータ。 + Flux を使用してデプロイされた、異なるテナントに属するアプリケーション。 固有の要件とセキュリティ上の考慮事項に基づいて、マルチテナンシー用に独自のアーキテクチャを慎重に計画および構築することをお勧めします。このパターンは、実装の開始点となります。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + AWS Command Line Interface (AWS CLI) バージョン 2.11.4 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み + ローカルマシンにインストールされた [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) バージョン 0.12 以降 + [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest) バージョン 3.0.0 以降 + [Kubernetes Provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) バージョン 2.10 以降 + [Helm Provider](https://registry.terraform.io/providers/hashicorp/helm/latest/docs) バージョン 2.8.0 以降 + [Kubectl Provider](https://registry.terraform.io/providers/gavinbunney/kubectl/latest/docs) バージョン 1.14 以降 **制限事項** + **Terraform 手動デプロイの依存関係: **CodeCommit リポジトリ、CodeBuild プロジェクト、CodePipeline パイプラインの作成を含むワークフローの初期セットアップは、Terraform の手動デプロイに依存します。インフラストラクチャの変更に手動で介入する必要があるため、自動化とスケーラビリティの面で潜在的な制限が生じます。 + **CodeCommit リポジトリの依存関係: **ワークフローは、ソースコード管理ソリューションとして CodeCommit リポジトリに依存し、密接に結合されています AWS のサービス。 ## アーキテクチャ **ターゲットアーキテクチャ** このパターンでは、次の図に示すように、3 つのモジュールをデプロイして、データプラットフォームのパイプライン、ネットワーク、コンピューティングインフラストラクチャを構築します。 *パイプラインアーキテクチャ:* ![\[Amazon EKS マルチテナントアーキテクチャのパイプラインインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/76a4a23d-4275-427a-ae36-51c9a3803128.png) *ネットワークアーキテクチャ:* ![\[Amazon EKS マルチテナントアーキテクチャのネットワークインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/e542249a-19a3-4c99-b6f5-fdf80fee4edf.png) *コンピューティングアーキテクチャ:* ![\[Amazon EKS マルチテナントアーキテクチャのコンピューティングインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/91bd1ca8-17f0-433c-8600-4c8e6c474e31.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 CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [Amazon Elastic Kubernetes Service (Amazon EKS) ](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 + [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のスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [Cilium ネットワークポリシー](https://cilium.io/use-cases/network-policy/#:~:text=Cilium%20implements%20Kubernetes%20Network%20Policies,%2C%20Kafka%2C%20gRPC%2C%20etc.)は、Kubernetes L3 および L4 ネットワークポリシーをサポートします。L7 ポリシーで拡張して、HTTP、Kafka、gRPC、その他の同様のプロトコルに API レベルのセキュリティを提供できます。 + [Flux](https://fluxcd.io/) は、Git ベースの継続的デリバリー (CD) ツールです。Kubernetes へのアプリケーションのデプロイを自動化します。 + [Helm](https://helm.sh/docs/) は、Kubernetes 用のオープンソースのパッケージマネージャです。Kubernetes クラスター上でアプリケーションをインストールおよび管理できます。 + 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub「[EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment)」のリポジトリで入手できます。 ## ベストプラクティス この実装を使用するためのガイドラインとベストプラクティスについては、以下を参照してください。 + [Amazon EKS マルチテナンシーのベストプラクティス](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/) + [Flux ドキュメント](https://fluxcd.io/flux/get-started/) ## エピック ### Terraform のビルド、テスト、デプロイの各ステージのパイプラインを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクトリポジトリのクローンを作成する | ターミナルウィンドウで次のコマンドを実行して、GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment) のリポジトリをクローンします。
git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
| AWS DevOps | | Terraform S3 バケットと Amazon DynamoDB をブートストラップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | `run.sh` および `locals.tf` ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | パイプラインモジュールをデプロイします。 | パイプラインリソースを作成するには、次の Terraform コマンドを手動で実行します。これらのコマンドを自動的に実行するためのオーケストレーションはありません。
./run.sh -m pipeline -e demo -r  -t init
./run.sh -m pipeline -e demo -r  -t plan
./run.sh -m pipeline -e demo -r  -t apply
| AWS DevOps | ### ネットワークインフラストラクチャを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パイプラインを開始します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html)初めて実行した後は、CodeCommit リポジトリのメインブランチに変更をコミットするたびに、パイプラインが自動的に開始されます。パイプラインには次の[ステージ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)が含まれます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | ネットワークモジュールを通じて作成されたリソースを検証します。 | パイプラインが正常にデプロイされた後に、次の AWS リソースが作成されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | ### コンピューティングインフラストラクチャを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `locals.tf` を更新して、CodeBuild プロジェクトの VPC へのアクセスを有効にします。 | Amazon EKS プライベートクラスターのアドオンをデプロイするには、CodeBuild プロジェクトを Amazon EKS VPC にアタッチする必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | `buildspec` ファイルを更新してコンピューティングモジュールを構築します。 | `templates` フォルダのすべての `buildspec` YAML ファイルで、`TF_MODULE_TO_BUILD` 変数の値を `network` から `compute` に設定します。
TF_MODULE_TO_BUILD: "compute"
| AWS DevOps | | テナント管理 Helm チャートの `values` ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | コンピューティングリソースを検証します。 | 前のステップでファイルを更新すると、CodePipeline が自動的に起動します。コンピューティングインフラストラクチャ用に次の AWS リソースが作成されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | ### テナント管理およびその他のリソースを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Kubernetes のテナント管理リソースを検証します。 | 次のコマンドを実行し、Helm を使用してテナント管理リソースが正常に作成されたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps | | テナントアプリケーションのデプロイを確認します。 | 次のコマンドを実行して、テナントアプリケーションがデプロイされたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 次のようなエラーメッセージが表示されます。`Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.` | 問題のトラブルシューティングを行うには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | ## 関連リソース + [Amazon EKS Blueprints for Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints) + [Amazon EKS ベストプラクティスガイド、マルチテナンシーセクション](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/) + [Flux ウェブサイト](https://fluxcd.io/) + [Helm ウェブサイト](https://helm.sh/) ## 追加情報 テナントアプリケーションをデプロイするためのリポジトリ構造の例を次に示します。 ``` applications sample_tenant_app ├── README.md ├── base │ ├── configmap.yaml │ ├── deployment.yaml │ ├── ingress.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── tenant-1 │ ├── configmap.yaml │ ├── deployment.yaml │ └── kustomization.yaml └── tenant-2 ├── configmap.yaml └── kustomization.yaml ``` # 自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する *Balaji Panneerselvam、Attila Dancso、Pavan Dusanapudi、Anand Jumnani、James O'Hara (Amazon Web Services)* ## 概要 Amazon Lex 会話ボットの開発とデプロイは、複数の機能、開発者、および環境を管理しようとする場合には困難になることがあります。Infrastructure as Code (IaC) 原則を使用する自動ワークフローは、このプロセスを合理化するのに役立ちます。このパターンは、以下のようにして Amazon Lex 開発者の生産性の向上と、効率的なボットライフサイクル管理の実現に寄与します。 + **複数の機能の同時開発を可能にする** - 自動ワークフローを使用すると、開発者はさまざまな機能を別々のブランチで並行して開発できます。その後、他の作業をブロックすることなく、変更をマージしてデプロイできます。 + **Amazon Lex コンソール UI を使用する** - 開発者は、使いやすい Amazon Lex コンソールを使用してボットをビルドおよびテストできます。その後、ボットはインフラストラクチャコードで記述され、デプロイされます。 + **複数の環境にまたがってボットを昇格させる** - ワークフローは、ボットバージョンの下位環境 (開発やテストなど) から本番環境までの昇格を自動化します。このアプローチにより、手動昇格のリスクとオーバーヘッドが軽減されます。 + **バージョン管理を維持する** - ボット定義は、Amazon Lex サービスだけでなく Git でも管理されます。これにより、バージョン管理と監査証跡が提供されます。または AWS マネジメントコンソール APIs のみを使用して保存されているボットを変更する場合とは異なり、変更は個々の開発者に追跡されます AWS。 チームは、Amazon Lex ボットのリリースプロセスを自動化することで、リスクと労力を軽減し、機能をより迅速に提供できます。ボットは、Amazon Lex コンソールで分離されるのではなく、バージョン管理下にとどまります。 ## 前提条件と制限事項 **前提条件** + ワークフローには、異なる環境 (開発、本番稼働、DevOps) AWS アカウント に対して複数の が含まれます。そのためには、アカウント管理とクロスアカウントアクセス設定が必要です。 + デプロイ環境またはパイプラインで利用可能な Python 3.9。 + ソース管理のためにローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。 + AWS Command Line Interface (AWS CLI) コマンドラインまたは Python を使用して認証するように[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)および設定されています。 **制限事項** + **リポジトリアクセス** – ワークフローでは、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに、ソースコードリポジトリに変更をコミットするために必要なアクセス許可があることを前提としています。 + **初期ボットバージョン** – ツールでは、 AWS CloudFormation テンプレートを使用してボットの初期バージョンをデプロイする必要があります。ボットを自動ワークフローに引き継がせる前に、ボットの最初のイテレーションを作成し、リポジトリにコミットする必要があります。 + **マージの競合** – ワークフローの目的は同時開発を可能にすることですが、さまざまなブランチからの変更を統合するときにマージの競合が発生する可能性がまだあります。ボット設定の競合を解決するには、手動介入が必要になる場合があります。 **製品バージョン** + [Python 3.9](https://www.python.org/downloads/) 以降 + [AWS CDK v2 2.124.0](https://docs.aws.amazon.com/cdk/api/versions.html) 以降 + [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk/) 1.28 以降 ## アーキテクチャ 次の図は、ソリューションの高レベルアーキテクチャと主要コンポーネントを示しています。 ![\[Amazon Lex ボットの開発とデプロイを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3c7f9d16-9708-43c4-afa6-9d804d6b9dad/images/cdc73e82-a777-4e88-8bf8-a73c9bacb47f.png) 主なコンポーネントは以下のとおりです。 + **Lex ボットリポジトリ** – Amazon Lex ボットの IaC 定義を保存する Git リポジトリ。 + **DevOps** – 開発およびデプロイプロセス用の CI/CD パイプラインおよび関連リソースを格納する AWS アカウント 専用の です。 + **パイプライン** – 新しいボットの作成、ボットの定義のエクスポート、ボット定義のインポート、ボットの削除など、ボットの開発とデプロイのライフサイクルのさまざまな段階を自動化する AWS CodePipeline インスタンス。 + **チケットボットとメインボット** – Amazon Lex ボットリソース。ここで、チケットボットは個々のチームまたは開発者によって開発される機能固有のボットで、メインボットはすべての機能を統合するベースラインボットです。 このアーキテクチャ図は、次のワークフローを示しています。 1. **メインボットをベースラインに設定する** – ワークフローの出発点は、開発 (Dev) 環境でメインボットをベースラインに設定することです。メインボットは、将来の開発と機能追加の基盤として機能します。 1. **チケットボットを作成する** – 新機能または変更が必要な場合、チケットボットが作成されます。チケットボットは基本的に、開発者がメインバージョンに影響を与えることなく操作できるメインボットのコピーまたはブランチです。 1. **チケットボットをエクスポートする** - チケットボットに対する作業が完了したら、Amazon Lex サービスからチケットボットがエクスポートされます。その後、チケットボットを含むブランチがメインブランチからリベースされます。このステップにより、チケットボットの開発中にメインボットに加えられた変更が確実に組み込まれ、潜在的な競合が軽減されます。 1. **リベースされたチケットボットをインポートして検証する** – リベースされたチケットボットは開発環境にインポートされ、メインブランチからの最新の変更で正しく機能することが検証されます。検証が成功すると、チケットボットの変更をメインブランチにマージするためのプルリクエスト (PR) が作成されます。 1. **チケットボットを削除する** – 変更がメインブランチに正常にマージされると、チケットボットは不要になります。チケットボットを削除して、環境をクリーンで管理しやすい状態に保つことができます。 1. **メインボットを開発環境にデプロイしてテストする** – 新機能や変更を含む最新のメインボットが開発環境にデプロイされます。ここでは、徹底的なテストを実施して、すべての機能が予期したとおりに動作することを確認します。 1. **メインボットを本番環境にデプロイする** – 開発環境でのテストが正常に完了すると、メインボットが本番環境にデプロイされます。このステップはワークフローの最終段階で、ここでエンドユーザーが新機能を利用できるようになります。 **自動化とスケール** 自動ワークフローにより、開発者はさまざまな機能を別々のブランチで並行して開発できます。これにより、同時開発が容易になり、チームが効果的にコラボレーションして、機能をより迅速に提供することが可能になります。相互に分離されたブランチにより、他の進行中の作業をブロックまたは妨害することなく、変更をマージしてデプロイできます。 ワークフローは、開発、テスト、本番などのさまざまな環境にまたがるボットバージョンのデプロイと昇格を自動化します。 Git などのバージョン管理システムにボット定義を保存することで、包括的な監査証跡が提供され、効率的なコラボレーションが可能になります。変更は個々の開発者まで追跡されます。これにより、開発ライフサイクル全体を通じて透明性と説明責任が確保されます。このアプローチでは、コードレビューも容易になるため、チームは本番環境にデプロイする前に問題を特定して対処できます。 AWS CodePipeline およびその他の を使用することで AWS のサービス、自動化ワークフローは増加するワークロードとチームサイズに合わせてスケーリングできます。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、使い慣れたプログラミング言語を使用してコード内の AWS クラウド インフラストラクチャを定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです CloudFormation。このパターンのサンプル実装では Python を使用します。 + [AWS CDK コマンドラインインターフェイス (AWS CDK CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) - Toolkit AWS CDK は、 AWS CDK アプリを操作するための主要なツールです。アプリケーションを実行し、定義したアプリケーションモデルを調査し、CDK によって生成された CloudFormation テンプレートを生成してデプロイします。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。このパターンでは、CloudFormation を使用し、Infrastructure as Code によって Amazon Lex ボット設定と関連リソースをデプロイします。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。このパターンでは、CodeBuild を使用してデプロイアーティファクトをビルドおよびパッケージ化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。このパターンでは、CodePipeline を使用して継続的デリバリーパイプラインをオーケストレーションします。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドAWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Lex V2](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html) は、音声とテキストを使用してアプリケーションの会話インターフェイス (ボット) を構築 AWS のサービス するための です。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 **その他のツール** + [Git](https://git-scm.com/docs) はオープンソースの分散型バージョン管理システムです。 **コードリポジトリ** このパターンのコードは、GitHub [management-framework-sample-for-amazon-lex](https://github.com/aws-samples/management-framework-sample-for-amazon-lex) リポジトリで入手できます。コードリポジトリには、以下のフォルダとファイルが含まれています。 + `prerequisite` フォルダ – 必要なリソースと環境を設定するための CloudFormation スタック定義 ( を使用 AWS CDK) が含まれています。 + `prerequisite/lexmgmtworkflow` フォルダ – スタック定義や Python コードを含む、Lex Management Workflow プロジェクトのメインディレクトリ。 + `prerequisite/tests` – ユニットテストが含まれています。 + `src` フォルダ – Amazon Lex ボット管理ラッパーとユーティリティを含むソースコードディレクトリ。 + `src/dialogue_lambda` – Amazon Lex ボットとの会話中にユーザー入力を傍受して処理するダイアログフック Lambda 関数のソースコードディレクトリ。 ## ベストプラクティス + **懸念事項の分離** + DevOps、開発、および本番環境間の責任の明確な分離を維持します。 + 環境 AWS アカウント ごとに個別の を使用して、適切な分離とセキュリティの境界を適用します。 + クロスアカウントロールと最小特権アクセス原則を使用して、環境間の制御されたアクセスを確保します。 + **コードとしてのインフラストラクチャ** + インフラストラクチャコードを定期的に見直し、ベストプラクティスと要件の変化に合わせて更新します。 + ソースコードリポジトリに対する明確なブランチおよびマージ戦略を確立する + **テストと検証** + パイプラインのさまざまな段階で自動テストを実装して、開発サイクルの早い段階で問題を特定します。 + Amazon Lex コンソールまたは自動テストフレームワークを使用し、ボットを上位環境に昇格させる前にボットの設定と機能を検証します。 + 本番環境または重要な環境へのデプロイのための手動承認ゲートを実装することを検討します。 + **モニタリングとログ記録 ** + パイプライン、デプロイ、ボットインタラクションのモニタリングおよびログ記録メカニズムを設定します。 + パイプラインイベント、デプロイステータス、ボットパフォーマンスメトリクスをモニタリングし、問題を迅速に特定して対処します。 + Amazon CloudWatch などの AWS のサービス、および を使用して AWS CloudTrail、一元的なログ記録とモニタリング AWS X-Ray を行います。 + 自動ワークフローのパフォーマンス、効率、および有効性を定期的に見直して分析します。 + セキュリティとコンプライアンス + 安全なコーディングプラクティスを実装し、Amazon Lex ボットの開発とデプロイのセキュリティ AWS のベストプラクティスに従います。 + 最小特権の原則に合わせて IAM ロール、ポリシー、およびアクセス許可を定期的に見直して更新します。 + セキュリティスキャンとコンプライアンスチェックをパイプラインに統合することを検討します。 ## エピック ### Amazon Lex ボット管理用の IaC を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ローカル環境を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | AWS DevOps | | `devops` 環境でクロスアカウントロールを作成します。 | `devops` アカウントは、CI/CD パイプラインのホスティングおよび管理を担当します。CI/CD パイプラインが `dev` および `prod` 環境とやり取りできるようにするには、以下のコマンドを実行して `devops` アカウントにクロスアカウントロールを作成します。
cdk bootstrap --profile=devops

cdk deploy LexMgmtDevopsRoleStack -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps | | `dev` 環境でクロスアカウントロールを作成します。 | `dev` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `dev` アカウントで実行します。IAM ロールを作成するには、以下のコマンドを実行します。
cdk bootstrap --profile=dev

cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=dev
| AWS DevOps | | `prod` 環境でクロスアカウントロールを作成します。 | `prod` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `prod` アカウントで実行します。
cdk bootstrap --profile=prod

cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=prod
| AWS DevOps | | `devops` 環境にパイプラインを作成します。 | Amazon Lex ボットの開発ワークフローを管理するには、以下のコマンドを実行して `devops` 環境にパイプラインを設定します。
cdk deploy LexMgmtWorkflowStack -c devops-account-id=1111111111111 -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps | ### メインボットのベースラインを確立する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メインボットの初期バージョンを定義します。 | メインボットの初期バージョンを定義するには、`BaselineBotPipeline` パイプラインを[トリガー](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-triggers)します。このパイプラインは、CloudFormation テンプレートで定義されている基本的なボット定義をデプロイし、メインボット定義を .json ファイルとしてエクスポートし、メインボットコードをバージョン管理システムに保存します。 | AWS DevOps | ### 機能開発ワークフローを実装する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | チケットボットを作成し、機能を開発してテストします。 | `TicketBot` は、機能ブランチにある既存のメインボット定義からインポートされる新しいボットインスタンスです。このアプローチにより、メインボットの最新の機能と設定が新しいボットに含まれることが保証されます。チケットボットの初期バージョンを定義するには、`CreateTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムに新しい機能ブランチを作成し、メインボットに基づいて新しいチケットボットインスタンスを作成します。 | Lex ボット開発者 | | チケットボット機能を開発してテストします。 | 機能を開発してテストするには、 にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。詳細については、Amazon Lex ドキュメントの「[コンソールを使用したボットのテスト](https://docs.aws.amazon.com/lexv2/latest/dg/test-bot.html)」を参照してください。`TicketBot` インスタンスにより、ボットの機能を追加、変更、または拡張して新機能を実装できるようになりました。例えば、インテント、発話、スロット、ダイアログフローを作成または変更できます。詳細については、Amazon Lex ドキュメントの「[インテントの追加](https://docs.aws.amazon.com/lexv2/latest/dg/add-intents.html)」を参照してください。 | Lex ボット開発者 | | チケットボット定義をエクスポートします。 | エクスポートされたボット定義は、基本的にボットの設定と機能を JSON 形式で表現したものです。チケットボット定義をエクスポートするには、`ExportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、チケットボット定義を .json ファイルとしてエクスポートし、チケットボットコードをバージョン管理システムの機能ブランチに保存します。 | Lex ボット開発者 | | 最新のメインブランチから機能ブランチをリベースします。 | 新機能の開発中に、別の開発者またはチームがメインブランチに他の変更を加えた可能性があります。これらの変更を機能ブランチに組み込むには、Git `rebase` オペレーションを実行します。このオペレーションは基本的に、メインブランチからの最新のコミットに加えて機能ブランチからのコミットをリプレイすることで、機能ブランチに最新の変更がすべて含まれるようにします。 | Lex ボット開発者 | | リベースされたチケットボットをインポートして検証します。 | 機能ブランチをリベースしたら、それをチケットボットインスタンスにインポートする必要があります。このインポートにより、既存のチケットボットがリベースされたブランチからの最新の変更で更新されます。リベースされたチケットボットをインポートするには、`ImportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムの機能ブランチにあるチケットボット定義 .json ファイルを `TicketBot` インスタンスにインポートします。 | Lex ボット開発者 | | リベースされたボット定義を検証します。 | リベースされたボット定義をインポートしたら、その機能を検証することが重要です。新機能が予期したとおりに動作し、既存の機能と競合しないことを確認する必要があります。この検証では、通常、ボットをさまざまな入力シナリオでテストし、レスポンスを調べて、ボットが意図したとおりに動作することを検証します。検証は、次のいずれかの方法で実行できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者 | | 機能ブランチをメインブランチにマージします。 | 分離された `TicketBot` インスタンスで新機能を開発してテストしたら、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者、リポジトリ管理者 | | 機能ブランチとチケットボットを削除します。 | 機能ブランチがメインブランチに正常にマージされたら、ソースコードリポジトリから機能ブランチとチケットボットを削除します。機能ブランチとチケットボットを削除するには、`DeleteTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、開発プロセス中に作成された一時的なボットリソース (チケットボットなど) を削除します。このアクションは、リポジトリをクリーンな状態に保ち、将来の機能ブランチとの混同や競合を防ぐのに役立ちます。 | Lex ボット開発者 | ### メインボットを保守する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最新のメインボット定義を `dev` 環境にインポートします。 | メインブランチの最新のメインボット定義を `dev` 環境にインポートするには、`DeployBotDevPipeline` パイプラインをトリガーします。このパイプラインは、承認時に git タグも作成します。 | AWS DevOps | | 最新のメインボット定義を `prod` 環境にインポートします。 | メインブランチの最新のボット定義を `prod` 環境にインポートするには、前のタスクのタグリファレンスをパラメータとして指定して `DeployBotProdPipeline` パイプラインをトリガーします。このパイプラインは、特定のタグの最新のボット定義を `prod` 環境にインポートします。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Amazon Lex ボットを別の にデプロイする場合 AWS アカウント、ツールサービスには、それらのアカウントのリソースにアクセスするために必要なアクセス許可が必要です。 | クロスアカウントアクセスを付与するには、IAM ロールとポリシーを使用します。ターゲットアカウントに IAM ロールを作成し、必要なアクセス許可を付与するロールにポリシーをアタッチします。次に、Amazon Lex ボットがデプロイされているアカウントからそれらのロールを引き受けます。詳細については、Amazon Lex ドキュメントの「[インポートに必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/import.html#import-permissions)」と「[Lex V2 でボットをエクスポートするために必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/export.html#export-permissions)」を参照してください。 | ## 関連リソース + [Amazon Lex V2 でのボットのインポート](https://docs.aws.amazon.com/lexv2/latest/dg/import.html) + [CodePipeline でパイプラインを開始する](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-about-starting.html) + [Amazon Lex V2 ボットの使用 V2 ](https://docs.aws.amazon.com/lexv2/latest/dg/building-bots.html) # AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する *Amazon Web Services、Stan Fan* ## 概要 このパターンでは、Amazon Elastic Container Service (Amazon ECS) クラスターの [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) タスクをオーケストレーションするために設計されたクラウドネイティブソリューションである WaitCondition フック (`waitcondition-hook-for-aws-fargate-task`) npm パッケージを説明します。 WaitCondition フックは、 との統合用に特別にカスタマイズされた AWS Cloud Development Kit (AWS CDK) コンストラクトです AWS CloudFormation。WaitCondition フックの主な機能は、次のとおりです。 + 待機条件メカニズムとして機能し、指定された Fargate タスクが完了するまで CloudFormation スタックの実行を一時停止します。これにより、正しい順序でのデプロイとリソースプロビジョニングがしやすくなります。 + TypeScript と Python をサポートしているため、 AWS CDK プロジェクトに最適です。 + AWSでコンテナ化されたアプリケーションのタスク完了とリソース管理を調整することで、開発者やアーキテクトがデプロイをオーケストレーションできるようにします。 + CloudFormation ライフサイクルに埋め込まれた 1 つ以上のコンテナを使用する Fargate タスクの実行を可能にします。また、タスクの失敗を処理し、タスクの失敗後に CloudFormation スタックをロールバックできます。 + カスタムタスクを有効にしたり、他のエンドポイントを呼び出したりして、リソースと Fargate タスク実行結果の間の依存関係を柔軟に追加できるようにします。例えば、CloudFormation スタックを一時停止し、データベース移行 (Fargate タスクによって実行) の完了を待ち、データベース移行の成功に依存する可能性のある他のリソースをプロビジョニングできます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + AWS Cloud Development Kit (AWS CDK) ローカルワークステーションにインストールされたコマンドラインインターフェイス (CLI)。詳細については、 AWS CDK ドキュメントの [AWS CDK CLI リファレンス](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)を参照してください。 + ローカルワークステーションにインストールされ、[TypeScript のAWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) 用に設定されたノードパッケージマネージャー (npm)。詳細については、npm ドキュメントの [[Node.js と npm のダウンロードとインストール]](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) を参照してください。 + ローカルワークステーションにインストールされた Yarn。詳細については、Yarn ドキュメントの「[インストール](https://yarnpkg.com/getting-started/install)」を参照してください。 **制限事項** + このソリューションは 1 つの にデプロイされます AWS アカウント。 + 成功の場合、コンテナの期待されるリターンコードは `0` です。その他のリターンコードは失敗を示し、CloudFormation スタックはロールバックされます。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」から、サービスのリンクを選択してご確認ください。 ## アーキテクチャ コンストラクトアーキテクチャを次の図に示します。 ![\[waitcondition-hook-for-aws-fargate-task コンストラクトの AWS Step Functions ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e58680e3-f89f-422f-b0e1-e85605ae8bf9/images/598020df-908c-4486-9844-c05af759c18a.png) この図表は、`waitcondition-hook-for-aws-fargate-task` のワークフローを示しています。 1. `WaitCondition` および `WaitConditionHandler` は、 AWS Lambda 関数からのレスポンスをリッスンするようにプロビジョニングされます。 1. タスクの結果に応じて、Fargate タスクの終了によって `CallbackFunction` または `ErrorHandlerFunction` がトリガーされます。 1. Lambda 関数は、SUCCEED シグナルか FAILURE シグナルを `WaitConditionHandler` に送信します。 1. Fargate タスクの実行結果が成功だった場合、`WaitConditionHandler` はリソースのプロビジョニングを継続します。タスクが失敗した場合はスタックをロールバックします。 次の図は、データベース移行を実行するためのワークフローの例を示しています。 ![\[WaitCondition フックコンストラクトを使用した Amazon RDS データベース移行のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e58680e3-f89f-422f-b0e1-e85605ae8bf9/images/3b83fc2a-80bb-4ba9-9637-782060493cf0.png) このワークフロー例では、`waitcondition-hook-for-aws-fargate-task` コンストラクトを使用して、次のようにデータベース移行を実行します。 1. Amazon Relational Database Service (Amazon RDS) インスタンスがプロビジョニングされます。 1. `waitcondition-hook-for-aws-fargate-task` コンストラクトは、データベース移行タスクを実行し、スタックを Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとして一時停止します。 1. 移行タスクが正常に終了すると、Succeed シグナルを CloudFormation に送信します。正常に終了しなかった場合は、Fail シグナルを CloudFormation に送信し、スタックをロールバックします。 ## ツール **AWS サービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするのに役立つソフトウェア開発フレームワークです CloudFormation。 + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。 + [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) を使用すると、サーバーや Amazon EC2 インスタンスを管理する必要なくコンテナを実行できます。これは Amazon ECS と組み合わせて使用されます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるというメリットがあります。 **その他のツール** + [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。 + [Yarn](https://yarnpkg.com/) は、JavaScript プロジェクトの依存関係を管理するために使用できるオープンソースのパッケージマネージャーです。Yarn は、パッケージの依存関係のインストール、更新、設定、削除をサポートします。 **コードリポジトリ** このパターンのコードは、GitHub の [waitcondition-hook-for-aws-fargate-task](https://github.com/aws-samples/waitcondition-hook-for-aws-fargate-task) リポジトリで入手できます。 ## ベストプラクティス + AWS CDK アプリを構築するときは、v2 AWS CDK ドキュメントの「 [を使用したクラウドインフラストラクチャの開発とデプロイのベストプラクティス AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)」に従ってください。 + AWS Fargate タスクについては、[Amazon ECS ドキュメントの「Amazon ECS コンテナイメージのベストプラクティス](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/application.html)」に従ってください。 ## エピック ### のセットアップ AWS CDK | タスク | 説明 | 必要なスキル | | --- | --- | --- | | をインストールします AWS CDK。 | AWS CDK ローカルマシンまたは他の環境に をインストールするには、次のコマンドを実行します。
npm install -g aws-cdk@latest
| クラウドアーキテクト、アプリ開発者 | | をブートストラップします AWS CDK。 | [ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)は、デプロイ用の[環境](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)を準備するプロセスです。ターゲット AWS アカウント と の AWS CDK ツールキットをブートストラップするには AWS リージョン、次のコマンドを実行します。
cdk bootstrap aws://ACCOUNT-NUMBER-1/REGION-1
このコマンドは、`CDKToolkit` という名前の CloudFormation スタックを作成します。 | クラウドアーキテクト | ### AWS Fargate タスクコンストラクトの WaitCondition フックを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CDK プロジェクトを作成します。 | 任意の言語を使用して、CDK プロジェクトを作成します。このパターンでは、TypeScript を使用します。TypeScript を使用して CDK プロジェクトを作成するには、次のコマンドを実行します。`cdk init app —language typescript` | クラウドアーキテクト | | パッケージをインストールします。 | CDK プロジェクトのルートパスで `npm install` を実行します。CDK ライブラリをインストールしたら、次のコマンドを実行して `waitcondition-hook-for-aws-fargate-task` をインストールします。`yarn add waitcondition-hook-for-aws-fargate-task` | クラウドアーキテクト | | CDK アプリケーションと Amazon ECS コンポーネントをビルドします。 | CDK プロジェクトをビルドします。Amazon ECS タスク定義リソースが必要です。タスク定義の作成に関する詳細については、Amazon ECS ドキュメントの「[Amazon ECS タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」を参照してください。次の例ではこのコンストラクトを使用します。
import * as cdk from 'aws-cdk-lib';
import { Vpc } from 'aws-cdk-lib/aws-ec2';
import * as ecr from 'aws-cdk-lib/aws-ecr';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';
import { FargateRunner } from 'waitcondition-hook-for-aws-fargate-task';
import { Queue } from 'aws-cdk-lib/aws-sqs';

export class FargateRunnerStack extends cdk.Stack {
    constructor(scope: Construct, id: string, props?: cdk.StackProps) {
        super(scope, id, props);
        // Define the VPC
        const vpc = new Vpc(this, 'MyVpc')
        // Define the Fargate Task
        const taskDefinition = new ecs.FargateTaskDefinition(this, 'MyTask', {});
        // Import exiting ecr repo
        const repo = ecr.Repository.fromRepositoryName(this, 'MyRepo', 'RepoName');
        // Add a container to the task
        taskDefinition.addContainer('MyContainer', {
            image: ecs.ContainerImage.fromEcrRepository(repo),
        });
        // Create the Fargate runner
        const myFargateRunner = new FargateRunner(this, 'MyRunner', {
            fargateTaskDef: taskDefinition,
            timeout: `${60 * 5}`,
            vpc: vpc,
        });
        // Create the SQS queue
        const myQueue = new Queue(this, 'MyQueue', {});
        // Add dependency
        myQueue.node.addDependency(myFargateRunner);
    }
}
| クラウドアーキテクト | | CDK アプリケーションを合成し、起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)`waitcondition-hook-for-aws-fargate-task` コンストラクトは Fargate タスクを実行します。 | クラウドアーキテクト | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | 前のステップでプロビジョニングされたリソースをクリーンアップするには、次のコマンドを実行します。
cdk destroy
| クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 一般的な CloudFormation スタックの障害 | 一般的な CloudFormation スタックの障害のトラブルシューティングに役立つように、次の例に示すように `--no-rollback` フラグを追加します。
cdk deploy --no-rollback
このコマンドは CloudFormation スタックのロールバックを一時停止し、トラブルシューティングのためのリソースを提供します。詳細については、 CloudFormation ドキュメントの[「リソースをプロビジョニングするときに障害を処理する方法を選択する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html)」を参照してください。 | | AWS Step Functions 失敗 | AWS Step Functions ステートマシンは、さまざまな理由で実行に失敗することがあります。`—disable-rollback` が設定されている場合は、次のステップを使用してトラブルシューティングを行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)詳細については、 AWS Step Functions ドキュメントの[「Step Functions の問題のトラブルシューティング](https://docs.aws.amazon.com/step-functions/latest/dg/troubleshooting.html)」および[「Step Functions コンソールの実行の詳細の表示](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-view-execution-details.html#exec-details-intf-step-details)」を参照してください。 | | AWS Lambda 関数の失敗 | このコンストラクトは、`CallbackFunction` と `ErrorhandlerFunction` の 2 つの Lambda 関数をプロビジョニングします。処理されない例外など、さまざまな理由で失敗する可能性があります。次の手順を使用して、トラブルシューティングを行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)詳細については、 AWS Lambda ドキュメントの[「Lambda の問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/lambda-troubleshooting.html)」を参照してください。 | ## 関連リソース **AWS ドキュメント** + [AWS CDK コンストラクト API リファレンス](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html) + [の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) + [Amazon ECS リソースを作成して使用する方法について説明します。](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/getting-started.html) + [Step Functions の使用を開始する方法について説明します。](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html) + [とは AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) **その他のリソース** + [AWS Fargate タスクの待機条件フック](https://pypi.org/project/waitcondition-hook-for-aws-fargate-task/) (npm) + [waitcondition-hook-for-aws-fargate-task 1.0.6](https://pypi.org/project/waitcondition-hook-for-aws-fargate-task/) (pypi.org) # AWS CodePipeline のサードパーティーの Git ソースリポジトリを使用する *Amazon Web Services、Kirankumar Chandrashekar* ## 概要 このパターンでは、AWS CodePipeline をサードパーティーの Git ソースリポジトリで使用する方法を説明します。 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) は、ソフトウェアの構築、テスト、製品へのデプロイを自動化する 継続的デリバリーサービス です。このサービスは現在、GitGitHub、「[AWS CodeCommit](https://aws.amazon.com/codecommit)」、およびアトラシアン Bitbucket によって管理されている Git リポジトリをサポートしています。ただし、一部の企業では、シングルサインオン (SSO) サービスとMicrosoft Active Directoryと統合されたサードパーティー製の Git リポジトリを認証に使用しています。カスタムアクションと Webhook を作成することで、これらのサードパーティーの Git リポジトリを CodePipeline のソースとして使用できます。 ウェブフックとは、GitHub リポジトリなど、別のツールにおけるイベントを検出し、この外部イベントをパイプラインに接続する HTTP 通知です。CodePipeline でウェブフックを作成すると、サービスは Git リポジトリのウェブフックで使用できる URL を返します。Git リポジトリの特定のブランチにコードをプッシュすると、Git ウェブフックはこの URL から CodePipeline ウェブフックを開始し、パイプラインのソースステージを「**進行中**」に設定します。パイプラインがこの状態になると、ジョブワーカーは CodePipeline をポーリングしてカスタムジョブを探し、ジョブを実行し、成功または失敗のステータスを CodePipeline に送信します。この場合、パイプラインはソースステージにあるため、ジョブワーカーは Git リポジトリのコンテンツを取得して圧縮し、ポーリングされたジョブによって提供されたオブジェクトキーを使用して、パイプラインのアーティファクトが保存されている Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。カスタムアクションのトランジションを Amazon CloudWatch のイベントに関連付けて、そのイベントに基づいてジョブワーカーを起動することもできます。この設定により、サービスがネイティブにサポートしていないサードパーティーの Git リポジトリを CodePipeline のソースとして使用できます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + ウェブフックをサポートし、インターネット経由で CodePipeline ウェブフック URL に接続できる Git リポジトリ + AWS コマンドラインインターフェイス (AWS CLI) が「[インストールされ](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」、AWS アカウントと連携するように「[設定されている](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」 ## アーキテクチャ このパターンには以下のステップが含まれます。 1. ユーザーは Git リポジトリにコードをコミットします。 1. Git ウェブフックが呼び出されます。 1. CodePipeline ウェブフックが呼び出されます。 1. パイプラインは「**進行中**」に設定され、ソースステージは「**進行中**」状態に設定されます。 1. ソースステージアクションは、開始されたことを示す CloudWatch Events ルールを開始します。 1. CloudWatch イベントは Lambda 関数を開始します。 1. Lambda 関数はカスタムアクションジョブの詳細を取得します。 1. Lambda 関数は AWS CodeBuild を起動し、ジョブに関連するすべての情報を渡します。 1. CodeBuild は、HTTPS Git アクセス用の公開 SSH キーまたはユーザー認証情報をSecrets Manager から取得します。 1. CodeBuild は特定のブランチの Git リポジトリをクローンします。 1. CodeBuild はアーカイブを圧縮し、CodePipeline アーティファクトストアとして機能する S3 バケットにアップロードします。 ![\[AWS CodePipeline のソースとしてサードパーティーの Git ソースリポジトリを使用するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/84284bec-b39d-466a-9fd9-994be2c953df/images/85555dab-7317-40f5-86a7-ccb8987c5bf3.png) ## ツール + [AWS CodePipeline](https://aws.amazon.com/codepipeline/) – AWS CodePipeline はフルマネージド型の[継続的デリバリー](https://aws.amazon.com/devops/continuous-delivery/)サービスで、アプリケーションとインフラストラクチャの更新を迅速かつ信頼できるものにするパイプラインのリリース自動化に役立ちます。CodePipeline はお客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、およびデプロイを自動化します。機能とアップデートをすばやく、信頼性の高い方法で配信できます。AWS CodePipeline は、GitHub などのサードパーティーサービスや独自のカスタムプラグインと統合できます。 + [AWS Lambda](https://aws.amazon.com/lambda/) – AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。Lambda を使用すれば、実質どのようなタイプのアプリケーションやバックエンドサービスでも、管理をまったく必要とせずに実行できます。コードをアップロードするだけで、コードの実行とスケールに必要な処理はすべて Lambda により自動的に実行され、高い可用性が維持されます。コードは、他の AWS サービスから自動的に開始するよう設定することも、ウェブやモバイルアプリケーションから直接呼び出すよう設定することもできます。 + [AWS CodeBuild](https://aws.amazon.com/codebuild/) – AWS CodeBuild はフルマネージド型の[継続的統合](https://aws.amazon.com/devops/continuous-integration/)サービスであり、このサービスにより、ソースコードをコンパイルし、テストを実行し、デプロイ可能なソフトウェアパッケージを作成できます。CodeBuild により、ビルドサーバーのプロビジョニング、管理、スケーリングが不要になります。CodeBuild では、継続的にスケーリングされ、複数のビルドが同時にプロセスされるため、ビルドの実行までキューで待機することはありません。パッケージ済みのビルド環境を使用、またはご自分のビルドツールを使用するカスタムビルド環境を作成できることですぐに開始できます。 + [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) – AWS Secrets Manager は、アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護に役立ちます。このサービスを使用すると、データベースクレデンシャル、APIキー、およびその他のシークレットをライフサイクル全体で簡単にローテーション、管理、および取得できます。ユーザーとアプリケーションは、機密情報をプレーンテキストにハードコーディングしなくても、Secrets Manager API を呼び出すことでシークレットを取得します。Secrets Manager では、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon DocumentDB の統合が組み込まれています。このサービスは、API キーや OAuth トークンなど、他のタイプのシークレットをサポートするように拡張できます。さらに、Secrets Manager では、きめ細かい権限を使用してシークレットへのアクセスを制御したり、AWS クラウド、サードパーティーサービス、オンプレミス環境内のリソースに対するシークレットのローテーションを一元的に監査したりできます。 + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) – Amazon CloudWatch は、DevOps エンジニア、開発者、サイト信頼性エンジニア (SRE)、ITマネージャー、アプリケーション所有者向けに構築された、モニタリングおよびオブザーバビリティサービスです。CloudWatch では、データと実用的なインサイトを提供して、アプリケーションのモニタリング、システム全体のパフォーマンスの変化に関する対応、リソース使用率の最適化、および運用状態の統合的な確認を行うことができます。CloudWatch は、ログ、メトリックス、イベントの形式でモニタリングデータと運用データを収集し、AWS とオンプレミスサーバーで実行される AWS のリソース、アプリケーション、サービスを一元的に把握できるようにします。CloudWatch を使用すると、環境内の異常な動作の検出、アラームの設定、ログとメトリクスの並列表示、自動アクションの実行、問題のトラブルシューティング、およびアプリケーションの円滑な稼働を維持するための洞察の発見を行うことができます。 + [Amazon S3](https://aws.amazon.com/s3/) — Amazon Simple Storage Service (Amazon S3) は、ウェブサイト、モバイルアプリケーション、バックアップおよび復元、アーカイブ、エンタープライズアプリケーション、IoT デバイス、ビッグデータ分析など、広範なユースケースのデータを容量にかかわらず、保存して保護することができます。Amazon S3 には、特定のビジネス、組織、コンプライアンスの要件を満たすために、データへのアクセスを最適化、整理、設定できる管理機能があります。 ## エピック ### CodePipeline でカスタムアクションを作成および追加する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CLI または AWS CloudFormation を使用してカスタムアクションを作成します。 | このステップでは、特定のリージョンの AWS アカウントのパイプラインのソースステージで使用できるカスタムソースアクションを作成します。カスタムソースアクションを作成するには、AWS CLI または AWS CloudFormation (コンソールではない) を使用する必要があります。このエピックやその他のエピックで説明されているコマンドとステップの詳細については、このパターンの最後にある「関連リソース」セクションを参照してください。AWS CLI では、カスタムアクションタイプの作成コマンドを使用します。--configuration-properties を使用して、ジョブワーカーがジョブの CodePipeline をポーリングするときに処理する必要があるすべてのパラメータを指定します。このカスタムソースステージでパイプラインを作成するときに同じ値を使用できるように、--provider オプションと--action-version オプションに指定されている値を必ず書き留めてください。リソースタイプ AWS：： CodePipeline：： CustomActionType を使用して AWS CloudFormation でカスタムソースアクションを作成することもできます。 | AWS 全般 | ### 認証を設定する。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSH キーペア を作成します。 | Secure Shell (SSH) key pair を作成します。手順については、Github のドキュメントを参照してください。 | システム/DevOps エンジニア | | AWS Secrets Manager でシークレットを作成します。 | SSH キーkey pair からプライベートキーの内容をコピーし、AWS Secrets Manager でシークレットを作成します。このシークレットは、Git リポジトリにアクセスするときの認証に使用されます。 | AWS 全般 | | パブリックキーを Git リポジトリに追加します。 | SSH キーペアのパブリックキーを Git リポジトリアカウント設定に追加して、プライベートキーに対する認証を行います。 | システム/DevOps エンジニア | ### パイプラインと Webhook を作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カスタムソースアクションを含むパイプラインを作成します。 | CodePipeline でパイプラインを作成します。ソースステージを設定するときは、以前に作成したカスタムソースアクションを選択します。AWS CodePipeline コンソールまたは AWS CLI でこれを行うことができます。CodePipeline は、カスタムアクションに設定した設定プロパティの入力を求めます。この情報は、ジョブワーカーがカスタムアクションのジョブを処理するために必要です。ウィザードに従い、パイプラインの次のステージを作成します。 | AWS 全般 | | CodePipeline Web フックを作成します。 | カスタムソースアクションで作成したパイプライン用の Webhook を作成します。ウェブフックを作成するには、AWS CLI または AWS CloudFormation (コンソールではない) を使用する必要があります。AWS CLI で put-webhook コマンドを実行し、ウェブフックオプションに適切な値を指定します。コマンドから返される Webhook URL を書き留めておきます。AWS CloudFormation を使用してウェブフックを作成する場合は、リソースタイプ AWS：： CodePipeline：： Webhook を使用してください。作成したリソースからウェブフック URL を出力し、書き留めておいてください。 | AWS 全般 | | Lambda 関数と CodeBuild プロジェクトを作成します。 | カスタムアクションを作成する際、このカスタムアクションのジョブリクエストの CodePipeline をポーリングするジョブワーカーを作成し、ジョブを実行してステータス結果を CodePipeline に返す必要があります。​ パイプラインのカスタムソースアクションステージが「進行中」に移行したときに Amazon CloudWatch Events ルールによって開始される Lambda 関数を作成します。Lambda 関数が開始されると、ジョブをポーリングしてカスタムアクションジョブの詳細を取得する必要があります。PollForJobs API を使用してこの情報を返すことができます。ポーリングされたジョブ情報を取得したら、Lambda 関数は確認を返し、カスタムアクションの設定プロパティから取得したデータを使用して情報を処理する必要があります。ワーカーが Git リポジトリと通信する準備ができたら、CodeBuild プロジェクトを開始します。SSH クライアントを使用して Git タスクを処理する方が便利なためです。 | AWS 全般、コード開発者 | ### CloudWatch でイベントを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch Events ルールを作成します。 | パイプラインのカスタムアクションステージが「進行中」に移行するたびに、ターゲットとして Lambda 関数を開始する CloudWatch Events ルールを作成します。 | AWS 全般 | ## 関連リソース **CodePipeline でカスタムアクションにタグ付けする** + [CodePipeline でカスタムアクションを作成および追加する](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-create-custom-action.html) + [AWS：：CodePipeline：：CustomActionType](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-customactiontype.html) **認証の設定** + [AWS Secrets Manager でのシークレットの作成と管理](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets.html) **パイプラインと Web フックの作成** + [CodePipeline でパイプラインの作成](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html) + [put-webhook コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/codepipeline/put-webhook.html) + [AWS：：CodePipeline：：Webhook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html) + [PollForJobs API リファレンス](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html) + [CodePipeline でカスタムアクションを作成および追加する](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-create-custom-action.html) + [AWS CodeBuild でビルドプロジェクトを削除する](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html) **イベントの作成** + [Amazon CloudWatch Eventsでパイプラインステートの変更を検知し反応する](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html) **その他の参考資料** + [CodePipeline でのパイプラインの使用](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines.html) + [AWS Lambda 開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) # AWS CodePipeline を使用して Terraform の構成を検証するための CI/CD パイプラインを作成する *Aromal Raj Jayarajan、Vijesh Vijayakumaran Nair (Amazon Web Services)* ## 概要 このパターンは、AWS CodePipeline がデプロイした継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して HashiCorp Terraform の構成をテストする方法を説明しています。 Terraform は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理する上で役立つコマンドラインインターフェイスアプリケーションです。このパターンで提供されるソリューションは、[CodePipeline の 5 つのステージ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)を実行して Terraform 構成の整合性を検証する際に役立つ CI/CD パイプラインを作成します。 1. `"checkout"` は、テスト中の Terraform 構成を AWS CodeCommit リポジトリから取得します。 1. `"validate"` は、[tfsec](https://github.com/aquasecurity/tfsec)、[TFLint](https://github.com/terraform-linters/tflint)、[checkov](https://www.checkov.io/) などの Infrastructure as Code (IaC) 検証ツールを実行します。このステージでは、Terraform の IaC 検証コマンド `terraform validate` および `terraform fmt` も実行されます。 1. `"plan"` は、Terraform 構成が適用された場合にインフラストラクチャにどのような変更が適用されるかを示します。 1. `"apply"` は、生成された計画を使用して、必要なインフラストラクチャをテスト環境にプロビジョニングします。 1. `"destroy"` は、`"apply"` ステージ中に作成されたテストインフラストラクチャを削除します。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + [インストールされ](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 コマンドラインインターフェイス (AWS CLI) + ローカルマシンにインストールされて構成されている [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + ローカルマシンにインストールされ、構成済みの [Terraform](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) **制限事項** + このパターンのアプローチでは、AWS CodePipeline を 1 つの AWS アカウントと AWS リージョンのみにデプロイします。マルチアカウントおよびマルチリージョンデプロイには、構成の変更が必要です。 + このパターンでプロビジョニングされる AWS Identity and Access Management (IAM) ロール (**codepipeline\$1iam\$1role**) は、最小特権の原則に従います。IAM ロールの権限は、パイプラインが作成する必要のある特定のリソースに基づいて更新する必要があります。**** **製品バージョン** + AWS CLI バージョン 2.9.15 以降 + Terraform バージョン 1.3.7 以降: ## アーキテクチャ **ターゲットテクノロジースタック** + AWS CodePipeline + AWS CodeBuild + AWS CodeCommit + AWS IAM + Amazon Simple Storage Service (Amazon S3) + AWS Key Management Service (AWS KMS) + Terraform **ターゲットアーキテクチャ** 次の図は、CodePipeline で Terraform 構成をテストするための CI/CD パイプラインワークフローの例を示しています。 ![\[AWS CI/CD パイプラインを使用して Terraform 設定をテストするアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4df7b1f8-8eef-4d85-a971-a7f158be9691/images/90b931c8-e745-4b52-92de-a367fb0f1f51.png) この図表は、次のワークフローを示しています: 1. CodePipeline では、AWS ユーザーは AWS CLI で `terraform apply` コマンドを実行して Terraform プランで提案されているアクションを開始します。 1. AWS CodePipeline は、CodeCommit、CodeBuild、AWS KMS、Amazon S3 へのアクセスに必要なポリシーを含む IAM サービスロールを引き受けます。 1. CodePipelineは、`"checkout"` パイプラインステージを実行して、テスト用に AWS CodeCommit リポジトリから Terraform 構成を取得します。 1. CodePipeline は、CodeBuild プロジェクトで IaC 検証ツールを実行し、Terraform IaC 検証コマンドを実行して Terraform 構成をテストする `"validate"` ステージを実行します。 1. CodePipeline は `"plan"` ステージを実行し、Terraform 構成に基づいて CodeBuild プロジェクトでプランを作成します。AWS ユーザーは、変更をテスト環境に適用する前にこのプランを確認できます。 1. Code Pipeline は、CodeBuild プロジェクトを使用してテスト環境に必要なインフラストラクチャをプロビジョニングすることで、プランを実装する `"apply"` ステージを実行します。 1. CodePipeline は、`"destroy"` ステージを実行することで、`"apply"` ステージ中に作成されたテストインフラストラクチャを CodeBuild で削除します。 1. Amazon S3 バケットには、AWS KMS [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)を使用して暗号化および復号化されたパイプラインアーティファクトが格納されます。 ## ツール **ツール** *AWS サービス* + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。 + [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 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) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意のデータ量を保存、保護、取得する際に役立つクラウドベースのオブジェクトストレージサービスです。 *その他のサービス* + [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つコマンドラインインターフェイスアプリケーションです。 **コード** このパターンのコードは、GitHub 内の「[aws-codepipeline-terraform-cicdsamples](https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples)」リポジトリで利用できます。リポジトリには、このパターンで概説されているターゲットアーキテクチャの作成に必要な Terraform 構成が含まれています。 ## エピック ### ソリューションコンポーネントのプロビジョニング | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリのクローン作成 | ターミナルウィンドウで以下のコマンドを実行して GitHub の [aws-codepipeline-terraform-cicdsamples](https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples) リポジトリをクローン作成します。
git clone https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples.git
詳細については、GitHub ドキュメントの「[リポジトリのクローン作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | DevOps エンジニア | | Terraform 変数定義ファイルを作成する。 | ユースケース要件に基づいて `terraform.tfvars` ファイルを作成します。クローン作成したリポジトリにある `examples/terraform.tfvars` ファイル内の変数を更新できます。詳細については、Terraform ドキュメントの「[ルートモジュール変数への値の割り当て](https://developer.hashicorp.com/terraform/language/values/variables#assigning-values-to-root-module-variables)」を参照してください。リポジトリの `Readme.md` ファイルには、必要な変数に関する詳細情報が含まれています。 | DevOps エンジニア | | AWS を Terraform プロバイダーとして構成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)詳細については、[ のプロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)を参照してください。 | DevOps エンジニア | | Amazon S3 レプリケーションバケットを作成するための Terraform プロバイダー構成を更新する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)レプリケーションを使用すると、Amazon S3 バケット間でオブジェクトを自動で非同期的にコピーできます。 | DevOps エンジニア | | Terraform 構成を初期化します。 | Terraform 構成ファイルを含む作業ディレクトリを初期化するには、クローン作成したリポジトリのルートフォルダで以下のコマンドを実行します。
terraform init
| DevOps エンジニア | | Terraform プランを作成します。 | Terraform プランを作成するには、クローン作成したリポジトリのルートフォルダで以下のコマンドを実行します。
terraform plan --var-file=terraform.tfvars -out=tfplan
Terraform は設定ファイルを評価して、宣言されたリソースのターゲット状態を判断します。次に、ターゲットの状態を現在の状態と比較し、プランを作成します。 | DevOps エンジニア | | Terraform プランを検証します。 | Terraform プランを確認し、ターゲット AWS アカウントで必要なアーキテクチャが構成されていることを確認します。 | DevOps エンジニア | | ソリューションのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)Terraform は、構成ファイルに宣言されている目標状態を達成するために、インフラストラクチャを作成、更新、または破棄します。 | DevOps エンジニア | ### パイプラインを実行して Terraform の構成を検証します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースコードリポジトリをセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html) | DevOps エンジニア | | パイプラインのステージを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)詳細については、*AWS CodePipeline ユーザーガイド*の「[パイプラインの詳細と履歴を表示する (コンソール)](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-view-console.html)」を参照してください。ソースリポジトリのメインブランチに変更がコミットされると、テストパイプラインは自動的に有効になります。 | DevOps エンジニア | | レポート出力を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)`-validate` CodeBuild プロジェクトは、`"validate"` ステージ中にコードの脆弱性レポートを生成します。 | DevOps エンジニア | ### リソースのクリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パイプラインと関連リソースをクリーンアップします。 | AWS アカウントからテストリソースを削除するには、クローン作成したリポジトリのルートフォルダで次のコマンドを実行します。
terraform destroy --var-file=terraform.tfvars
| DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `"apply"` ステージ中に **AccessDenied** エラーが表示される。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html) | ## 関連リソース + [Module blocks](https://developer.hashicorp.com/terraform/language/modules/syntax) (Terraform ドキュメント) + [How to use CI/CD to deploy and configure AWS security services with Terraform](https://aws.amazon.com/blogs/security/how-use-ci-cd-deploy-configure-aws-security-services-terraform/) (AWS ブログ投稿) + [サービスにリンクされたロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) (IAM ドキュメント) + [create-pipeline](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/codepipeline/create-pipeline.html) (AWS CLI ドキュメント) + [Configure server-side encryption for artifacts stored in Amazon S3 for CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/S3-artifact-encryption.html) (AWS CodePipeline ドキュメント) + [Quotas for AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/limits.html) (AWS CodeBuild ドキュメント) + [Data protection in AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/data-protection.html) (AWS CodePipeline ドキュメント) ## 追加情報 **カスタム Terraform モジュール** 以下は、このパターンで使用されるカスタム Terraform モジュールのリストです。 + `codebuild_terraform` は、パイプラインの各ステージを形成する CodeBuild プロジェクトを作成します。 + `codecommit_infrastructure_source_repo` は、ソース CodeCommit リポジトリをキャプチャして作成します。 + `codepipeline_iam_role` は、パイプラインに必要な IAM ロールを作成します。 + `codepipeline_kms` は、Amazon S3 オブジェクトの暗号化と復号化に必要な AWS KMS キーを作成します。 + `codepipeline_terraform` は、ソース CodeCommit リポジトリのテストパイプラインを作成します。 + `s3_artifacts_bucket` は、Amazon S3 バケットを作成して、パイプラインアーティファクトを管理します。 **ビルド仕様ファイル** 以下は、このパターンが各パイプラインステージを実行するために使用するビルド仕様 (buildspec) ファイルのリストです。 + `buildspec_validate.yml` は、`"validate"` ステージを実行します。 + `buildspec_plan.yml` は、`"plan"` ステージを実行します。 + `buildspec_apply.yml` は、`"apply"` ステージを実行します。 + `buildspec_destroy.yml` は、`"destroy"` ステージを実行します。 *ビルド仕様ファイル変数* 各 buildspec ファイルは次の変数を使用して異なるビルド固有の設定を有効にします。 | | | 変数 | デフォルトの 値 | 説明 | | --- |--- |--- | | `CODE_SRC_DIR` | "." | ソース CodeCommit ディレクトリを定義します。 | | `TF_VERSION` | 「1.3.7」 | ビルド環境の Terraform バージョンを定義します。 | `buildspec_validate.yml` ファイルでは、さまざまなビルド固有の設定を有効にする以下の変数もサポートしています。 | | | 変数 | デフォルトの 値 | 説明 | | --- |--- |--- | | `SCRIPT_DIR` | 「./templates/scripts」 | スクリプトディレクトリを定義します。 | | `ENVIRONMENT` | 「dev」 | 環境名を定義します | | `SKIPVALIDATIONFAILURE` | 「Y」 | 障害発生時の検証をスキップします | | `ENABLE_TFVALIDATE` | 「Y」 | Terraform 検証を有効にします  | | `ENABLE_TFFORMAT` | 「Y」 | Terraform フォーマットを有効にします | | `ENABLE_TFCHECKOV` | 「Y」 | checkovスキャンを有効にします | | `ENABLE_TFSEC` | 「Y」 | tfsec スキャンを有効にします | | `TFSEC_VERSION` | 「v1.28.1」 | tfsec バージョンを定義します。 | # その他のパターン **Topics** + [AWS PrivateLink と Network Load Balancer を使用して、Amazon EKS 上のコンテナアプリケーションにプライベートアクセスします。](access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer.md) + [ある の AWS CodeCommit リポジトリ AWS アカウント を別のアカウントの Amazon SageMaker AI Studio Classic に関連付ける](associate-an-aws-codecommit-repository-in-one-aws-account-with-sagemaker-studio-in-another-account.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 Batch を使用して Amazon RDS for PostgreSQL DBインスタンスのバックアップを自動化します](automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch.md) + [AWS SAM を使用してネストされたアプリケーションのデプロイを自動化](automate-deployment-of-nested-applications-using-aws-sam.md) + [CI/CD パイプラインを使用して Amazon EKS へのノード終了ハンドラーのデプロイを自動化する](automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.md) + [Amazon MQ で RabbitMQ 設定を自動化する](automate-rabbitmq-configuration-in-amazon-mq.md) + [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md) + [CI/CD パイプラインを使用して Amazon EKS へ Java アプリケーションを自動的にビルドし、デプロイする](automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.md) + [Python アプリケーションを使用して Amazon DynamoDB の PynamoDB モデルと CRUD 関数を自動的に生成する](automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.md) + [CodePipeline、IAM アクセスアナライザー、AWS CloudFormation マクロを使用して、IAM ポリシーとロールを自動的に検証してデプロイする](automatically-validate-and-deploy-iam-policies-and-roles-in-an-aws-account-by-using-codepipeline-iam-access-analyzer-and-aws-cloudformation-macros.md) + [の Stromasys Charon-SSP エミュレータで Sun SPARC サーバーをバックアップする AWS クラウド](back-up-sun-sparc-servers-in-the-stromasys-charon-ssp-emulator-on-the-aws-cloud.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) + [EC2 Image Builder と Terraform を使用して、強化されたコンテナイメージ用のパイプラインを構築する](build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform.md) + [Amazon SageMaker AI と Azure DevOps を使用して MLOps ワークフローを構築する](build-an-mlops-workflow-by-using-amazon-sagemaker-and-azure-devops.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) + [ステートファイルが失われた後、 AWS Account Factory for Terraform (AFT) リソースを安全にクリーンアップする](clean-up-aft-resources-safely-after-state-file-loss.md) + [NLog を使用して Amazon CloudWatch Logs 内の.NET アプリケーションのロギングを設定します](configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.md) + [AWS アカウント と 間で Amazon ECR コンテナイメージをコピーする AWS リージョン](copy-ecr-container-images-across-accounts-regions.md) + [SageMaker 用のカスタム Docker コンテナイメージを作成し、AWS Step Functions のモデルトレーニングに使用する](create-a-custom-docker-container-image-for-sagemaker-and-use-it-for-model-training-in-aws-step-functions.md) + [AWS CodePipeline に適用されない AWS リージョンにパイプラインを作成](create-a-pipeline-in-aws-regions-that-don-t-support-aws-codepipeline.md) + [Amazon CloudWatch 異常検知により、カスタムメトリクスのアラームを作成](create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.md) + [AWS CDK アスペクトとエスケープハッチを使用してデフォルトのロール名をカスタマイズする](customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.md) + [複数のコード成果物のセキュリティ問題を一斉に検出するパイプラインをデプロイする](deploy-a-pipeline-that-simultaneously-detects-security-issues-in-multiple-code-deliverables.md) + [インフラストラクチャをコードとして使用して、AWS クラウドにサーバーレスデータレイクをデプロイして管理する](deploy-and-manage-a-serverless-data-lake-on-the-aws-cloud-by-using-infrastructure-as-code.md) + [Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md) + [Amazon EKS と Amazon S3 の Helm チャートリポジトリを使用して Kubernetes のリソースとパッケージをデプロイする](deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3.md) + [AWS CDK と TypeScript を使用してマルチスタックのアプリケーションをデプロイする](deploy-multiple-stack-applications-using-aws-cdk-with-typescript.md) + [Kiro やその他のコーディングアシスタントで MCP サーバーを使用してリアルタイムのコーディングセキュリティ検証をデプロイする](deploy-real-time-coding-security-validation-by-using-an-mcp-server-with-kiro-and-other-coding-assistants.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) + [RAG と ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md) + [AWS CloudFormation テンプレートを使用して Amazon GuardDuty を条件付きで有効にする](enable-amazon-guardduty-conditionally-by-using-aws-cloudformation-templates.md) + [Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする](event-driven-auto-scaling-with-eks-pod-identity-and-keda.md) + [Amazon Personalize を使用して、パーソナライズされ再ランク付けされたレコメンデーションを生成します](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md) + [AWS KMS キーのキーの状態が変更されたときに Amazon SNS 通知を受け取る](get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.md) + [Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する](govern-permission-sets-aft.md) + [Amazon ECR リポジトリに移行するときに、重複するコンテナイメージを自動的に識別する](identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.md) + [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md) + [AWS CDK を使用して複数の AWS リージョン、アカウント、OU にわたって Amazon DevOps Guru を有効にすることで、運用パフォーマンスを向上させます。](improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.md) + [Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします](install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset.md) + [Stonebranch ユニバーサルコントローラーと AWS Mainframe Modernizationを統合](integrate-stonebranch-universal-controller-with-aws-mainframe-modernization.md) + [メインフレームのモダナイゼーション: Rocket Software Enterprise Suite AWS を使用した での DevOps](mainframe-modernization-devops-on-aws-with-micro-focus.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 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) + [appcmd.exe を使用して IIS がホストするアプリケーションを Amazon EC2 に移行する](migrate-iis-hosted-applications-to-amazon-ec2-by-using-appcmd.md) + [複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md) + [を使用して、検証、変換、パーティショニングで ETL パイプラインをオーケストレーションする AWS Step Functions](orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.md) + [IaC 原則を使用して Amazon Aurora Global Database のブルー/グリーンデプロイを自動化する](p-automate-blue-green-deployments-aurora-global-databases-iac.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) + [AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.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) + [Terraform を使用してデータベース移行用の CI/CD パイプラインを設定する](set-up-ci-cd-pipeline-for-db-migration-with-terraform.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) + [AWS CloudFormation を使用して Amazon EC2 に UiPath RPA ボットを自動的にセットアップする](set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.md) + [Application Load Balancer を使用して Amazon ECS の相互 TLS でアプリケーション認証を簡素化する](simplify-application-authentication-with-mutual-tls-in-amazon-ecs.md) + [C\$1 と AWS CDK を使用するサイロモデル用の SaaS アーキテクチャでのテナントオンボーディング](tenant-onboarding-in-saas-architecture-for-the-silo-model-using-c-and-aws-cdk.md) + [Terraform を使用すると、組織の Amazon GuardDuty が自動的に有効になります。](use-terraform-to-automatically-enable-amazon-guardduty-for-an-organization.md) + [Amazon Bedrock エージェントを使用してテキストベースのプロンプトで Amazon EKS でのアクセスエントリコントロールの作成を自動化する](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md) + [Account Factory for Terraform (AFT) のコードをローカルで検証する](validate-account-factory-for-terraform-aft-code-locally.md) + [フラスコと AWS Elastic Beanstalk を使用して AI/ML モデルの結果を視覚化](visualize-ai-ml-model-results-using-flask-and-aws-elastic-beanstalk.md) # インフラストラクチャ **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) + [GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で 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) + [AWS 上の SQL Server の Always On アベイラビリティグループで読み取り専用ルーティングを構成する](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) + [組織間でのデータ共有を目的として、最小実行可能データスペースを設定する](minimum-viable-data-space-share-data-organizations.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) # ウェブアプリとモバイルアプリ **Topics** + [Amazon Cognito と AWS Amplify UI を使用して、React アプリケーションの既存ユーザーを認証する](authenticate-react-app-users-cognito-amplify-ui.md) + [AWS Amplify を使用して React アプリケーションを作成し、Amazon Cognito による認証を追加する](create-a-react-app-by-using-aws-amplify-and-add-authentication-with-amazon-cognito.md) + [、Angular AWS Amplify、および Module Federation を使用してマイクロフロントエンド用のポータルを作成する](create-amplify-micro-frontend-portal.md) + [React ベースのシングルページアプリケーションを Amazon S3 と CloudFront にデプロイする](deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.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) + [Amazon Cognito と IaC オートメーションを使用して Amazon Quick Sight ビジュアルコンポーネントをウェブアプリケーションに埋め込む](embed-quick-sight-visual-components-into-web-apps-cognito-iac.md) + [Green Boost を使用したフルスタックのクラウドネイティブなウェブアプリケーション開発を探索する](explore-full-stack-cloud-native-web-application-development-with-green-boost.md) + [AWS CodeBuild を使用して GitHub から Node.js アプリケーションのユニットテストを実行する](run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.md) + [AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する](structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.md) + [その他のパターン](websitesandwebapps-more-patterns-pattern-list.md) # Amazon Cognito と AWS Amplify UI を使用して、React アプリケーションの既存ユーザーを認証する *Amazon Web Services、Daniel Kozhemyako* ## 概要 このパターンでは、 AWS Amplify UI ライブラリと Amazon Cognito ユーザープールを使用して、既存のフロントエンドの React アプリケーションに認証機能を追加する方法を紹介します。 このパターンは、Amazon Cognito を使用して、アプリケーションの認証、認可、ユーザー管理機能を提供します。また、 の機能をユーザーインターフェイス ([UI) 開発に拡張するオープンソースライブラリである Amplify](https://ui.docs.amplify.aws/react/getting-started/introduction) UI のコンポーネントも使用します。 AWS Amplify [Authenticator UI](https://ui.docs.amplify.aws/react/connected-components/authenticator/advanced) のコンポーネントは、ログインセッションを管理し、Amazon Cognito でユーザーを認証するクラウド接続のワークフローを実行します。 このパターンを実装すると、ユーザーは次の認証情報のいずれかを使用してサインインできます。 + ユーザー名とパスワード + Apple、Facebook、Google、Amazon などのソーシャル ID プロバイダー + SAML 2.0 互換または OpenID Connect (OIDC) 互換のエンタープライズ ID プロバイダー **注記** カスタムの認証 UI コンポーネントを作成するには、Authenticator UI コンポーネントをヘッドレスモードで実行します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + React 18.2.0 以降のウェブアプリケーション + Node.js および npm 6.14.4 以降が[インストール済み](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)であること **制限事項** + このパターンは React Web アプリケーションのみに適用されます。 + このパターンは、事前構築済みの Amplify UIコンポーネントを使用します。このソリューションには、カスタム UI コンポーネントの実装に必要な手順は含まれません。 **製品バージョン** + Amplify UI 6.1.3 以降 (Gen 1) + Amplify 6.0.16 以降 (Gen 1) ## アーキテクチャ **ターゲットアーキテクチャ** 以下の図は、Amazon Cognito を使用して React ウェブアプリケーションのユーザーを認証するアーキテクチャを示しています。 ![\[Amazon Cognito が React ウェブアプリケーションのユーザーを認証する。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b2cea053-6931-4404-8aa8-c623ce2024ac/images/b7f69f20-a39d-4a78-8605-7dab73c59052.png) ## ツール **AWS のサービス** + [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理機能を提供します。 **その他のツール** + [Amplify UI](https://ui.docs.amplify.aws/react/getting-started/introduction) は、クラウドに接続できるカスタマイズ可能なコンポーネントを提供するオープンソースの UI ライブラリです。 + [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 + [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。 ## ベストプラクティス 新しいアプリケーションを構築する場合は、Amplify Gen 2 を使用することを推奨します。 ## エピック ### Amazon Cognito ユーザープールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ユーザープールの作成 | [Amazon Cognito ユーザープールを作成します](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-user-pool.html)。ユーザープールのサインインオプションとセキュリティ要件を、お使いのユースケースに合うように設定します。 | アプリ開発者 | | アプリクライアントを追加します。 | [ユーザープールアプリクライアントを設定します](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html)。このクライアントは、アプリケーションが Amazon Cognito ユーザープールとインタラクトするために必要です。 | アプリ開発者 | ### Amazon Cognito ユーザープールを Authenticator UI コンポーネントと統合する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 依存関係をインストールします。 | `aws-amplify` および `@aws-amplify/ui-react` パッケージをインストールするには、アプリケーションのルートディレクトリから次のコマンドを実行します。
npm i @aws-amplify/ui-react aws-amplify
| アプリ開発者 | | ユーザープールを設定します。 | 次の例を参考に、`aws-exports.js` ファイルを作成して `src` フォルダに保存します。このファイルには次の情報が含まれています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/authenticate-react-app-users-cognito-amplify-ui.html)
// replace the user pool region, id, and app client id details
const awsmobile = {
    "aws_project_region": "put_your_region_here",
    "aws_cognito_region": "put_your_region_here",
    "aws_user_pools_id": "put_your_user_pool_id_here",
    "aws_user_pools_web_client_id": "put_your_user_pool_app_id_here"
}

export default awsmobile;
| アプリ開発者 | | Amplify サービスをインポートして設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/authenticate-react-app-users-cognito-amplify-ui.html) | アプリ開発者 | | Authenticator UI コンポーネントを追加します。 | `Authenticator` UI コンポーネントを表示するには、アプリケーションのエントリポイントファイル (`App.js`) に次のコード行を追加します。
import { Authenticator } from '@aws-amplify/ui-react';
import '@aws-amplify/ui-react/styles.css';
サンプルのコードスニペットは、`Authenticator` UI コンポーネントと Amplify UI styles.css ファイル (コンポーネントの事前ビルド済みテーマを使用するときに必要) をインポートします。`Authenticator` UI コンポーネントは 2 つの戻り値を提供します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/authenticate-react-app-users-cognito-amplify-ui.html)次のコンポーネント例を参照してください。
function App() {
    return (
        
            {({ signOut, user }) => (
                

                    
Welcome {user.username}

                    
                

            )}
        
    );
}
`App.js` ファイルの例については、このパターンの[追加情報](#authenticate-react-app-users-cognito-amplify-ui-additional)セクションを参照してください。 | アプリ開発者 | | (オプション) セッション情報を取得します。 | ユーザーが認証されると、AAmplify クライアントからセッションに関するデータを取得できます。たとえば、ユーザーのセッションから JSON Web トークン (JWT) を取得して、そのユーザーのセッションからバックエンド API への要求を認証できます。JWT を含む要求ヘッダーの次の例を参照してください。
import { fetchAuthSession } from 'aws-amplify/auth';
(await fetchAuthSession()).tokens?.idToken?.toString();
| アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 新規ユーザーはアプリケーションにサインアップできません。 | 次のとおり、ユーザーがユーザープールにサインアップできるよう Amazon Cognito ユーザープールが設定されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/authenticate-react-app-users-cognito-amplify-ui.html) | | v5 から v6 にアップグレードしたら認証コンポーネント動作しなくなりました。 | `Auth` カテゴリは Amplify v6 の機能アプローチと名前付きパラメータに移行しました。今後は、機能 API は `aws-amplify/auth` パスから直接インポートする必要があります。詳細については、Amplify ドキュメントの「[Migrate from v5 to v6](https://docs.amplify.aws/gen1/react/build-a-backend/auth/auth-migration-guide/)」を参照してください。 | ## 関連リソース + [Amazon Cognito の開始方法](https://aws.amazon.com/cognito/getting-started/) (AWS ウェブサイト) + [新しい React アプリを作成する](https://reactjs.org/docs/create-a-new-react-app.html) (React ドキュメント) + [Amazon Cognito とは](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) (Amazon Cognito ドキュメント) + [Amplify UI library](https://ui.docs.amplify.aws/) (Amplify ドキュメント) ## 追加情報 `App.js` ファイルには次のコードが含まれています。 ``` import './App.css'; import { Amplify } from 'aws-amplify'; import awsExports from './aws-exports'; import { fetchAuthSession } from 'aws-amplify/auth'; import { Authenticator } from '@aws-amplify/ui-react'; import '@aws-amplify/ui-react/styles.css'; Amplify.configure({ ...awsExports }); let token = (await fetchAuthSession()).tokens?.idToken?.toString(); function App() { return ( {({ signOut, user }) => (

Welcome {user.username}

Your token is: {token}

)} ); } export default App; ``` # AWS Amplify を使用して React アプリケーションを作成し、Amazon Cognito による認証を追加する *Amazon Web Services、Rishi Singla* ## 概要 このパターンは、AWS Amplify を使用して React ベースのアプリケーションを作成する方法と、Amazon Cognito を使用してフロントエンドに認証を追加する方法を説明しています。AWS Amplify は、AWS でのモバイルアプリとウェブアプリケーションの開発を加速するための一連のツール (オープンソースフレームワーク、ビジュアル開発環境、コンソール) とサービス (ウェブアプリと静的ウェブサイトホスティング) から構成されています。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + マシンにインストールされている「[Node.js](https://nodejs.org/en/download/)」と「[npm](https://www.npmjs.com/get-npm)」 **製品バージョン** + Node.js バージョン 10.x 以降 (バージョンを確認するにはターミナルウィンドウで `node -v` を実行) + npm バージョン 6.x 以降 (バージョンを確認するにはターミナルウィンドウで `npm -v` を実行) ## アーキテクチャ **ターゲットテクノロジースタック** + 「AWS Amplify」 + Amazon Cognito ## ツール + 「[Amplify コマンドラインインターフェイス (CLI)](https://docs.amplify.aws/cli/)」 + 「[Amplify ライブラリ](https://docs.amplify.aws/lib/q/platform/react-native/)」(オープンソースのクライアントライブラリ) + 「[Amplify Studio](https://docs.amplify.aws/console/)」(ビジュアルインターフェイス) ## エピック ### AWS Amplify CLI をインストール | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amplify CLI をインストールします。 | Amplify CLI は、React アプリケーション用の AWS クラウドサービスを作成するための統合ツールチェーンです。Amplify CLI をインストールするには、実行
npm install -g @aws-amplify/cli
npm は、新しいメジャーバージョンが利用可能になると通知します。その場合は、次のコマンドを使用して npm のバージョンをアップグレードします。
npm install -g npm@9.8.0
9.8.0 はインストールしたいバージョンを指します。 | アプリ開発者 | ### React アプリを作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | React アプリを作成します。 | 新しい React アプリを作成するには、コマンドを使用します。
npx create-react-app amplify-react-application
`ampify-react-application` はアプリの名前です。アプリが正常に作成されたら、次のメッセージが表示されます。
Success! Created amplify-react-application
React アプリ用にさまざまなサブフォルダーを含むディレクトリーが作成されます。 | アプリ開発者 | | ローカルマシンでアプリを起動します。 | 前のステップで作成したディレクトリ `amplify-react-application` に移動し、以下のコマンドを実行します。
amplify-react-application% npm start
ローカルマシンで React アプリが起動します。 | アプリ開発者 | ### Amplify CLI の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS アカウントに接続するように Amplify を設定します。 | 次のコマンドを実行して Amplify を設定します。
amplify-react-application % amplify configure
Amplify CLI では、次の手順に従い、AWS アカウントへのアクセスを設定するように求められます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-react-app-by-using-aws-amplify-and-add-authentication-with-amazon-cognito.html)このシナリオでは、プログラムによるアクセスと長期的な認証情報を持つ IAM ユーザーが必要ですが、これにはセキュリティ上のリスクがあります。このリスクを軽減するために、これらのユーザーにはタスクの実行に必要な権限のみを付与し、不要になったユーザーは削除することをお勧めします。アクセスキーは、必要に応じて更新できます。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)」の「*アクセスキーを更新する*」を参照してください。これらのステップは、ターミナルに次のように表示されます。
Follow these steps to set up access to your AWS account:
Sign in to your AWS administrator account:
https://console.aws.amazon.com/
Press Enter to continue
Specify the AWS Region
? region:  us-east-1
Follow the instructions at
https://docs.amplify.aws/cli/start/install/#configure-the-amplify-cli
to complete the user creation in the AWS console
https://console.aws.amazon.com/iamv2/home#/users/create
Press Enter to continue
Enter the access key of the newly created user:
? accessKeyId:  ********************
? secretAccessKey:  ****************************************
This would update/create the AWS Profile in your local machine
? Profile Name:  new

Successfully set up the new user.
これらの手順の詳細については、Amplify Dev Center の「[ドキュメント](https://docs.amplify.aws/cli/start/install/#configure-the-amplify-cli)」を参照してください。 | AWS 全般、アプリ開発者 | ### Amplify を初期化 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amplify を初期化します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-react-app-by-using-aws-amplify-and-add-authentication-with-amazon-cognito.html) | アプリ開発者、AWS 全般 | ### フロントエンドに認証を追加します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 認証を追加します。 | `amplify add ` コマンドで、ユーザーログインやバックエンド API などの機能を追加できます。このステップでは、コマンドで認証を追加します。Amplify は、Amazon Cognito、フロントエンドライブラリ、およびドロップイン認証システム UI コンポーネントを備えたバックエンド認証サービスを提供します。ユーザーサインアップ、ユーザーサインイン、多要素認証、ユーザーサインアウト、パスワードレスサインインなどの機能があります。Amazon、Google と Facebook などのフェデレーションアイデンティティプロバイダーと統合してユーザーアイデンティティを認証することもできます。Amplify 認証カテゴリは、API、分析、ストレージなどの他のAmplify カテゴリとシームレスに統合されるため、認証されたユーザーと認証されていないユーザーとの認可ルールを定義できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-react-app-by-using-aws-amplify-and-add-authentication-with-amazon-cognito.html) | アプリ開発者、AWS 全般 | ### ［App.js］ファイルを変更してください。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | App.js ファイルを変更してください。 | この `src` フォルダーで、`App.js` ファイルを開いて修正します。変更されたファイルは以下のようになります。
{  App.Js File after modifications:
import React from 'react';
import logo from './logo.svg';
import './App.css';
import { Amplify } from 'aws-amplify';
import { withAuthenticator, Button, Heading } from '@aws-amplify/ui-react';
import awsconfig from './aws-exports';
Amplify.configure(awsconfig);
function App({ signOut }) {
  return (
      

      
Thankyou for doing verification

      
My Content

       
    

  );
}
export default withAuthenticator(App);
| アプリ開発者 | | React パッケージをインポートします。 | この `App.js` ファイルは 2 つの React パッケージをインポートされます。次のコマンドを使用してパッケージをインストールします。
amplify-react-application1 % npm install --save aws-amplify @aws-amplify/ui-react
| アプリ開発者 | ### React アプリを起動し、認証を確認します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリを起動します。 | ローカルマシンで React アプリを起動します。
amplify-react-application1 % npm start
| アプリ開発者、AWS 全般 | | 認証を確認します。 | アプリが認証パラメータの入力を求めるメッセージを表示するかを確認します。(この例では、サインイン方法として電子メールを設定しています)。フロントエンド UI では、ログイン認証情報の入力が求められ、アカウントを作成するオプションが表示されるはずです。Amplify ビルドプロセスを設定して、継続的デプロイメントワークフローの一部としてバックエンドを追加することもできます。ただし、このパターンではそのオプションは対象外です。 | アプリ開発者、AWS 全般 | ## 関連リソース + 「[開始方法](https://docs.npmjs.com/getting-started)」(npm ドキュメント) + 「[スタンドアロンの AWS アカウントを作成する](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html)」(AWS アカウント管理のドキュメント) + 「[AWS Amplify のドキュメント](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html)」 + 「[Amazon Cognito のドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)」 # 、Angular AWS Amplify、および Module Federation を使用してマイクロフロントエンド用のポータルを作成する *Amazon Web Services、Milena Godau および Pedro Garcia* ## 概要 マイクロフロントエンドアーキテクチャを使用すると、複数のチームがフロントエンドアプリケーションのさまざまな部分を独立して作業できます。各チームは、アプリケーションの他の部分に干渉することなく、フロントエンドの一部分を開発、構築、展開できます。エンドユーザーの観点から見ると、単一のまとまりのあるアプリケーションのように見えますが、実際は、他のチームによって公開された複数の独立したアプリケーションと相互にやり取りしています。 このドキュメントでは、[AWS Amplify](https://docs.amplify.aws/gen1/angular/)、[Angular](https://angular.dev/overview) フロントエンドフレームワーク、および [Module Federation](https://webpack.js.org/concepts/module-federation/) を使用してマイクロフロントエンドアーキテクチャを作成する方法について説明します。このパターンでは、マイクロフロントエンドはシェル (または*親*) アプリケーションによってクライアント側で結合されます。シェルアプリケーションは、マイクロフロントエンドを取得、表示、統合するコンテナとして機能します。シェルアプリケーションは、さまざまなマイクロフロントエンドをロードするグローバルルーティングを担当します。[@angular-architects/module-federation](https://www.npmjs.com/package/@angular-architects/module-federation) プラグインは、Module Federation を Angular と統合します。を使用して、シェルアプリケーションとマイクロフロントエンドをデプロイします AWS Amplify。エンドユーザーはウェブベースのポータルからアプリケーションにアクセスします。 ポータルは垂直に分割されます。つまり、マイクロフロントエンドはビュー全体またはビューのグループであり、同じビューの一部ではありません。したがって、シェルアプリケーションは一度に 1 つのマイクロフロントエンドのみをロードします。 マイクロフロントエンドはリモートモジュールとして実装されます。シェルアプリケーションはこれらのリモートモジュールをゆっくりとロードします。これにより、マイクロフロントエンドの初期化は、それが必要となるまで保留されます。このアプローチでは、必要なモジュールのみをロードすることで、アプリケーションのパフォーマンスを最適化します。これにより、初期ロード時間が短縮され、全体的なユーザー体験が向上します。さらに、webpack 設定ファイル (**webpack.config.js**) を介してモジュール間で共通の依存関係を共有します。この手法は、コードの再利用を促進し、重複を減らし、バンドルプロセスを合理化します。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Node.js と npm が[インストール済み](https://nodejs.org/en/download/) + Amplify CLI が[インストール済み](https://docs.amplify.aws/gen1/angular/tools/cli/) + Angular CLI が[インストール済み](https://angular.io/cli) + を使用するアクセス[許可](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsamplify.html) AWS Amplify + 「アンギュラーに精通していること」 **製品バージョン** + Angular CLI バージョン 13.1.2 以降 + @angular-architects/module-federation バージョン 14.0.1 以降 + webpack バージョン 5.4.0 以降 + AWS Amplify 生成 1 **制限事項** マイクロフロントエンドアーキテクチャは、拡張性と柔軟性のあるウェブアプリケーションを構築するための強力なアプローチです。しかしながら、このアプローチを採用する前に、以下の潜在的な課題を理解することが重要です。 + **統合** – 主な課題の 1 つは、モノリシックフロントエンドと比較して複雑さが増す可能性があることです。複数のマイクロフロントエンドのオーケストレーション、マイクロフロントエンド間の通信の処理、および共有依存関係の管理は、より複雑になることがあります。さらに、マイクロフロントエンド間の通信に関連するパフォーマンスオーバーヘッドが発生する場合もあります。この通信では、遅延時間が増加し、パフォーマンスが低下する可能性があります。そのため、効率的なメッセージングメカニズムとデータ共有戦略による対処が必要です。 + **コードの重複** – 各マイクロフロントエンドは個別に開発されるため、共通機能または共有ライブラリのコードが重複するリスクがあります。これにより、アプリケーション全体のサイズ増加やメンテナンスの課題が発生する可能性があります。 + **調整と管理** – 複数のマイクロフロントエンドで開発とデプロイのプロセスを調整することは容易ではありません。分散アーキテクチャでは、一貫したバージョニングの確保、依存関係の管理、コンポーネント間の互換性の維持がさらに重要となります。スムーズな共同作業と引き渡しには、明確なガバナンス、ガイドライン、自動化されたテストとデプロイの一連のプロセスを確立することが不可欠です。 + **テスト** – マイクロフロントエンドアーキテクチャのテストは、モノリシックフロントエンドのテストよりもさらに複雑になる場合があります。コンポーネント間の統合テストとプロセス全体のテストを実行し、複数のマイクロフロントエンドにわたって一貫したユーザー体験を検証するには、追加の労力と特殊なテスト戦略が必要です。 マイクロフロントエンドアプローチにコミットする前に、[マイクロフロントエンドの理解と実装 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/introduction.html)を確認することをお勧めします。 ## アーキテクチャ マイクロフロントエンドアーキテクチャでは、各チームが個別に機能を開発およびデプロイします。次の画像は、複数の DevOps チームがどのように連携するかを示しています。ポータルチームがシェルアプリケーションを開発します。シェルアプリケーションはコンテナとして機能します。それは、他の DevOps チームによって公開されたマイクロフロントエンドアプリケーションを取得、表示、統合します。を使用して AWS Amplify 、シェルアプリケーションとマイクロフロントエンドアプリケーションを公開します。 ![\[ユーザーがウェブポータルを介してアクセスするシェルアプリケーションに、複数のマイクロフロントエンドを公開します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ddf82a69-bf1b-4ad1-8e60-3dd375699936/images/cf045bf1-11ea-46d9-93cb-3c603122450d.png) この図表は、次のワークフローを示しています: 1. ポータルチームがシェルアプリケーションの開発および維持を行います。シェルアプリケーションは、ポータル全体を構成するために、マイクロフロントエンドの統合と可視化の調整を行います。 1. チーム A と B は、ポータルに統合されている 1 つ以上のマイクロフロントエンドまたは機能の開発および維持を行います。各チームは、それぞれのマイクロフロントエンドで個別に作業することができます。 1. エンドユーザーは Amazon Cognito を使用して認証されます。 1. エンドユーザーがポータルにアクセスすると、シェルアプリケーションがロードされます。ユーザーが移動すると、シェルアプリケーションは経路制御を処理し、要求されたマイクロフロントエンドを取得し、そのバンドルをロードします。 ## ツール **AWS のサービス** + [AWS Amplify](https://docs.amplify.aws/angular/start/) は、フロントエンドのウェブデベロッパーやモバイルデベロッパーがフルスタックアプリケーションをすばやく構築するのに役立つ、専用のツールと機能のセットです AWS。このパターンでは、Amplify CLI を使用して Amplify マイクロフロントエンドアプリケーションを展開します。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。 **その他のツール** + [@angular-architects/module-federation](https://github.com/angular-architects/module-federation-plugin) は、Angular を Module Federation と統合するプラグインです。 + [Angular](https://angular.dev/overview) は、モダンで拡張性があり、テスト可能な単一ページアプリケーションを構築するためのオープンソースのウェブアプリケーションフレームワークです。これは、コードの再利用とメンテナンスを促進するモジュール式のコンポーネントベースアーキテクチャに従っています。 + [Node.js](https://nodejs.org/en/docs/) は、拡張性のあるネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 + [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。 + [Webpack Module Fedration](https://webpack.js.org/concepts/module-federation/) は、マイクロフロントエンドやプラグインなど、個別にコンパイルおよび展開されたコードをアプリケーションにロードするのに役立ちます。 **コードリポジトリ** このパターンでのコードは、「[Micro-frontend portal using Angular and Module Federation](https://github.com/aws-samples/angular-module-federation-mfe)」GitHub リポジトリにあります。このリポジトリには、次の 2 つのフォルダがあります。 + `shell-app` には、シェルアプリケーションのコードがあります。 + `feature1-app` には、サンプルのマイクロフロントエンドがあります。シェルアプリケーションはこのマイクロフロントエンドを取得し、ポータルアプリケーション内の 1 ページとして表示します。 ## ベストプラクティス マイクロフロントエンドアーキテクチャには多くの利点がありますが、一方で複雑さも生じます。以下に、スムーズな開発、高品質のコード、優れたユーザー体験を実現するための最良の手法を紹介します。 + **計画とコミュニケーション** – 共同作業を合理化するには、事前計画、設計、明確なコミュニケーションチャネルに時間と労力を投資します。 + **設計の一貫性** – 設計システム、スタイルガイド、およびコンポーネントライブラリを使用して、マイクロフロントエンド全体で一貫したビジュアルスタイルを適用します。これにより、一貫したユーザー体験の提供ができて、開発が加速されます。 + **依存関係管理** – マイクロフロントエンドは独立して進化するため、標準化された契約とバージョニング戦略を採用して、依存関係を効果的に管理し、互換性の問題を防止します。 + **マイクロフロントエンドアーキテクチャ** – 独立した開発とデプロイを可能にするには、各マイクロフロントエンドがカプセル化された機能に対する明確に定義された責任を担う必要があります。 + **統合と通信** – スムーズな統合を促進し、衝突を最小限に抑えるには、明確な契約と、API、イベント、共有データモデルなどのマイクロフロントエンド間の通信プロトコルを定義します。 + **テストと品質保証** – マイクロフロントエンドのテストの自動化と継続的な統合のための一連のプロセスを実践します。これにより、全体的な品質が向上し、手動テストの労力が削減され、マイクロフロントエンド間のやり取りに関する機能が検証されます。 + **パフォーマンスの最適化** –** **パフォーマンスメトリックを継続的に監視し、マイクロフロントエンド間の依存関係を追跡します。これにより、ボトルネックを特定し、最適なアプリケーションパフォーマンスを維持することができます。これを行うには、パフォーマンス監視と依存関係分析ツールを使用します。 + **開発者エクスペリエンス** – 明確なドキュメント、ツール、事例を提供し、開発者エクスペリエンスに焦点を当てます。これにより、開発を合理化し、新しいチームメンバーを受け入れることができます。 ## エピック ### シェルアプリケーションの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | シェルアプリケーションを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | プラグインをインストールします。 | Angular CLI で、[@angular-architects/module-federation](https://www.npmjs.com/package/@angular-architects/module-federation) プラグインをインストールするために、次のコマンドを入力します。
ng add @angular-architects/module-federation --project shell --port 4200
| アプリ開発者 | | マイクロフロントエンドの URL を環境変数として追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | 経路制御を定義します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | `mfe1` モジュールを宣言します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | マイクロフロントエンドのプリロードの準備をします。 | マイクロフロントエンドをプリロードすると、Webpack は共有ライブラリおよびパッケージと適切に協議できるようになります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | HTML コンテンツを調整します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | ### マイクロフロントエンドアプリケーションの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マイクロフロントエンドを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | プラグインをインストールします。 | @angular-architects/module-federation プラグインをインストールするには、次のコマンドを入力します。
ng add @angular-architects/module-federation --project mfe1 --port 5000
| アプリ開発者 | | モジュールとコンポーネントを作成します。 | 次のコマンドを入力してモジュールとコンポーネントを作成し、リモートエントリモジュールとしてエクスポートします。
ng g module mfe1 --routing
ng g c mfe1
| アプリ開発者 | | デフォルトのルーティングパスを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | `mfe1` ルートを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | **webpack.config.js** ファイルを編集します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | HTML コンテンツを調整します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | ### 手元でのアプリケーションの実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | `mfe1` アプリケーションを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | シェルアプリケーションを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | ### マイクロフロントエンドロードエラーを処理するようにシェルアプリケーションをリファクタリングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | モジュールとコンポーネントを作成します。 | シェルアプリケーションのルートフォルダで次のコマンドを入力して、エラーページ用のモジュールとコンポーネントを作成します。
ng g module error-page --routing
ng g c error-page
| アプリ開発者 | | HTML コンテンツを調整します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | デフォルトのルーティングパスを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | マイクロフロントエンドをロードする関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | | エラー処理をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | ### を使用してアプリケーションをデプロイする AWS Amplify | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マイクロフロントエンドをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者、AWS DevOps | | シェルアプリケーションを展開します | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者、アプリオーナー | | CORS を有効にします。 | シェルアプリケーションとマイクロフロントエンドアプリケーションは異なるドメインで個別に実行環境が提供されるため、マイクロフロントエンドでクロスオリジンリソース共有 (CORS) を有効にする必要があります。これにより、シェルアプリケーションは別のオリジンからコンテンツをロードできます。CORS を有効にするには、カスタムヘッダーを追加します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者、AWS DevOps | | シェルアプリケーションで書き換えルールを作成します。 | Angular シェルアプリケーションは、HTML5 ルーティングを使用するように設定されています。ユーザーが強制再読み込みを実行すると、Amplify は現在の URL からページをロードしようとします。これにより、403 エラーが生成されます。これを回避するには、Amplify コンソールに書き換えルールを追加します。書き換えルールを作成するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者、AWS DevOps | | ウェブポータルをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | アプリ開発者 | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションを削除します。 | シェルアプリケーションとマイクロフロントエンドアプリケーションが不要になった場合は、削除してください。削除することで、使用していないリソースが課金されなくなります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | AWS 全般 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | `amplify init` コマンドの実行時にプロファイルを AWS 使用できません | AWS プロファイルを設定していない場合でも、 `amplify init` コマンドを続行できます。ただし、認証方法の入力を求められたら、`AWS access keys` オプションを選択する必要があります。 AWS アクセスキーとシークレットキーを使用可能にします。または、 AWS CLI用の名前付きプロファイルを設定することもできます。手順については、 AWS CLI ドキュメントの[「設定と認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」を参照してください。 | | リモートエントリのローディングエラー | シェルアプリケーションの **main.ts** ファイルでリモートエントリをロードするときにエラーが発生した場合は、`environment.mfe1URL` 変数が正しく設定されていることを確認してください。この変数の値は、マイクロフロントエンドの URL である必要があります。 | | マイクロフロントエンドにアクセスするときの 404 エラー | `http://localhost:4200/mfe1` 等でのローカルマイクロフロントエンドにアクセスしようとしたときに 404 エラーが発生した場合は、以下を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-amplify-micro-frontend-portal.html) | ## 追加情報 **AWS ドキュメント** + [でのマイクロフロントエンドの理解と実装 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/introduction.html) (AWS 規範ガイダンス) + 「[Amplify CLI](https://docs.amplify.aws/gen1/angular/tools/cli/)」 (「Amplify ドキュメント」) + 「[Amplify ホスティング](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html)」 (「Amplify ドキュメント」) **その他のリファレンス** + 「[Module Federation](https://webpack.js.org/concepts/module-federation/)」 + [Node.js](https://nodejs.org/en/) + [角度](https://angular.io/) + 「[@angular-architects/module-federation](https://www.npmjs.com/package/@angular-architects/module-federation)」 # React ベースのシングルページアプリケーションを Amazon S3 と CloudFront にデプロイする *Amazon Web Services、Jean-Baptiste Guillois* ## 概要 シングルページアプリケーション (SPA) は、JavaScript API を使用して表示される Web ページのコンテンツを動的に更新する Web サイトまたは Web アプリケーションです。このアプローチでは、Web ページ全体をサーバーからリロードするのではなく、新しいデータのみを更新するため、Web サイトのユーザーエクスペリエンスとパフォーマンスが向上します。 このパターンは、Amazon Simple Storage Service (Amazon S3) と Amazon CloudFront で React に記述された SPA のコーディングとホスティングに段階的にアプローチします。このパターンの SPA は、Amazon API Gateway で設定され、Amazon CloudFront ディストリビューションを介して公開される REST API を使用して、[クロスオリジンリソース共有 (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) 管理を簡素化します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + Node.js と `npm`、インストールおよび設定済み。詳細については、Node.js ドキュメントの[ダウンロード](https://nodejs.org/en/download/)セクションを参照してください。 + Yarn がインストールされ、設定されている。詳細については、[Yarn ドキュメント](https://classic.yarnpkg.com/lang/en/docs/install/#windows-stable)を参照してください。 + Git、インストールおよび設定済み。詳細については、[GitHub ドキュメント](https://github.com/git-guides/install-git)を参照してください。 ## アーキテクチャ ![\[React ベースの SPA を Amazon S3 とCloudFront にデプロイするアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/970a9d13-e8a2-44ac-aca5-a066e4be60e8/images/96061e05-8ac8-446e-b1da-baa6fc1cc7b6.png) このアーキテクチャは、 AWS CloudFormation (infrastructure as code) を使用して自動的にデプロイされます。また、静的アセットを保存する Amazon S3、リージョナル API (REST) エンドポイントを公開する Amazon API Gateway を使用する Amazon CloudFront などの、リージョナルサービスを使用します。アプリケーションログは Amazon CloudWatch を使用して収集されます。すべての AWS API コールが監査されます AWS CloudTrail。すべてのセキュリティ設定 (ID やアクセス許可など) は AWS Identity and Access Management (IAM) で管理されます。静的コンテンツは Amazon CloudFront コンテンツ配信ネットワーク (CDN) で配信され、DNS クエリは Amazon Route 53 によって処理されます。 ## ツール **AWS サービス** + 「[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)」は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。 + [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。 + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、 のガバナンス、コンプライアンス、運用リスクを監査するのに役立ちます AWS アカウント。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) は、高可用性でスケーラブルな DNS ウェブサービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/) は、任意の量のデータを保存、保護、取得する上で役立つクラウドベースのオブジェクトストレージサービスです。 **コード** このパターンのサンプルアプリケーションコードは、GitHub の[React ベースの CORS シングルページアプリケーション](https://github.com/aws-samples/react-cors-spa)のリポジトリにあります。 ## ベストプラクティス Amazon S3 オブジェクトストレージを使用すると、アプリケーションの静的アセットを、安全性、回復力、性能、コスト効率に優れた方法で保存できます。このタスクには、専用のコンテナや Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用する必要はありません。 Amazon CloudFront コンテンツ配信ネットワークを使用すると、ユーザーがアプリケーションにアクセスするときに発生する可能性のあるレイテンシーを低減できます。ウェブアプリケーションファイアウォール ([AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html)) を付加して、悪意のある攻撃からアセットを保護することもできます。 ## エピック ### アプリケーションをローカルにビルドおよびデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを実行して、サンプルアプリケーションのリポジトリを複製します。
git clone https://github.com/aws-samples/react-cors-spa react-cors-spa && cd react-cors-spa
| アプリ開発者、AWS DevOps | | アプリケーションをローカルにデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | アプリ開発者、AWS DevOps | | アプリケーションにローカルでアクセスします。 | ブラウザウィンドウを開き、`http://localhost:3000` URL を入力してアプリケーションにアクセスします。 | アプリ開発者、AWS DevOps | ### アプリケーションをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation テンプレートをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | アプリ開発者、AWS DevOps | | アプリケーションソースファイルをカスタマイズします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | アプリ開発者 | | アプリケーションパッケージをビルドします。 | プロジェクトディレクトリで `yarn build` コマンドを実行して、アプリケーションパッケージをビルドします。 | アプリ開発者 | | アプリケーションパッケージをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | アプリ開発者、AWS DevOps | ### アプリケーションをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションにアクセスしてテストします。 | ブラウザウィンドウを開いてから、CloudFront ディストリビューションドメイン (以前にデプロイした CloudFormation スタックからの `SPADomain` 出力) を貼り付けてアプリケーションにアクセスします。 | アプリ開発者、AWS DevOps | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットのコンテンツを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | AWS DevOps、アプリ開発者 | | CloudFormation スタックを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) | AWS DevOps、アプリ開発者 | ## 関連リソース ウェブアプリケーションをデプロイおよびホストするには、[AWS Amplify ホスティング](https://docs.aws.amazon.com/amplify/latest/userguide/getting-started.html)を使用して、継続的なデプロイでフルスタックかつサーバーレスのウェブアプリをホストする Git ベースのワークフローを提供することもできます。Amplify ホスティングは の一部であり[AWS Amplify](https://docs.aws.amazon.com/amplify/latest/userguide/welcome.html)、フロントエンドのウェブおよびモバイル開発者がフルスタックアプリケーションを迅速かつ簡単に構築できるようにする専用のツールと機能を提供します AWS。 ## 追加情報 ユーザーによってリクエストされ、403 エラーを生成する可能性のある無効な URL を処理するために、CloudFront ディストリビューションに設定されたカスタムエラーページが 403 エラーをキャッチし、アプリケーションエントリポイント (`index.html`) にリダイレクトします。 CORS の管理を簡素化するために、REST API は CloudFront ディストリビューションを通じて公開されます。 # プライベートエンドポイントと Application Load Balancer を使用して、Amazon API Gateway API を内部 Web サイトにデプロイする *Amazon Web Services、Saurabh Kothari* ## 概要 このパターンは、オンプレミスネットワークからアクセスできる内部 Web サイトに Amazon API Gateway API をデプロイする方法を示しています。プライベートエンドポイント、Application Load Balancer、AWS PrivateLink、Amazon Route 53 で設計されたアーキテクチャを使用して、プライベート API のカスタムドメイン名を作成する方法を学習します。このアーキテクチャは、API でのドメインベースのルーティングに役立つカスタムドメイン名とプロキシサーバーの使用の意図しない結果を防ぎます。たとえば、ルーティングできないサブネットに仮想プライベートクラウド (VPC) エンドポイントをデプロイする場合、ネットワークは API ゲートウェイに到達できません。一般的な解決策は、カスタムドメイン名を使用してからルーティング可能なサブネットに API をデプロイすることですが、プロキシ設定でトラフィック (`execute-api.{region}.vpce.amazonaws.com`) が AWS Direct Connect に渡されると、他の内部サイトが機能しなくなる場合があります。最後に、このパターンは、インターネットからアクセスできないプライベート API とカスタムドメイン名を使用するための組織の要件を満たす上で役立ちます。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + Web サイトと API のサーバー名表示 (SNI) 証明書 + オンプレミス環境から AWS Direct Connect または AWS Site-to-Site VPN を使用して設定された AWS アカウントへの接続 + オンプレミスネットワークから解決され、DNS クエリを Route 53 に転送する、対応するドメイン (domain.com など) を含む[プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) + オンプレミスネットワークからアクセス可能なルーティング可能なプライベートサブネット **制限** ロードバランサー、ルール、その他のリソースのクォータ（以前は制限と呼ばれてい）の詳細にについては、Elastic Load Balancing ドキュメントの [Application Load Balancer のクォータ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)を参照してください。 ## アーキテクチャ **テクノロジースタック** + Amazon API Gateway + Amazon Route 53 + Application Load Balancer + AWS Certificate Manager + AWS PrivateLink **ターゲットアーキテクチャ** 次の図は、Application Load Balancer のリスナールールに基づき、Web トラフィックを Web サイトターゲットグループ、または API ゲートウェイターゲットグループに誘導するApplication Load Balancer を VPC にデプロイする方法を示しています。API ゲートウェイのターゲットグループは、API ゲートウェイの VPC エンドポイントの IP アドレスのリストです。API ゲートウェイは、API をそのリソースポリシーでプライベートにするように設定されています。このポリシーは、特定の VPC エンドポイント以外からの呼び出しをすべて拒否します。API ゲートウェイのカスタムドメイン名は API とそのステージに api.domain.com を使用するように更新されました。Application Load Balancer のルールが追加され、ホスト名に基づきトラフィックがルーティングされます。 ![\[Application Load Balancer リスナールールを使用してウェブトラフィックを誘導するアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/83145062-4535-4ad0-8947-4ea8950cd174/images/12715186-26ea-4123-b9ef-e3105a934ff3.png) この図表は、次のワークフローを示しています: 1. オンプレミスネットワークのユーザーが内部 Web サイトにアクセスします。リクエストは ui.domain.com と api.domain.com に送信されます。次に、リクエストはルーティング可能なプライベートサブネットの内部 Application Load Balancer に解決されます。SSL は ui.domain.com と api.domain.com の Application Load Balancer で終了します。 1. Application Load Balancer に設定されたリスナールールは、ホストヘッダーをチェックします。 a. ホストヘッダーが api.domain.com の場合、リクエストは API ゲートウェイのターゲットグループに転送されます。Application Load Balancer は、ポート 443 を介して API ゲートウェイへの新しい接続を開始します。 b. ホストヘッダーが ui.domain.com の場合、リクエストは Web サイトのターゲットグループに転送されます。 1. リクエストが API ゲートウェイに到達すると、API ゲートウェイに設定されたカスタムドメインマッピングによってホスト名と実行する API が決定されます。 **自動化とスケール** このパターンの手順は、AWS CloudFormation または AWS Cloud Development Kit (AWS CDK) を使用することで自動化できます。API ゲートウェイコールのターゲットグループを設定するには、カスタムリソースを使用して VPC エンドポイントの IP アドレスを取得する必要があります。[describe-vpc-endpoints](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-vpc-endpoints.html) と [describe-network-interfaces](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-network-interfaces.html) への APIコールは IP アドレスとセキュリティグループを返し、これを使用して IP アドレスの API ターゲットグループを作成できます。 ## ツール + [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) は、任意のスケールで REST、HTTP、WebSocket API を作成、公開、維持、監視、保護する上で役立ちます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 + [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は、 AWS Web サイトとアプリケーションを保護するパブリックおよびプライベート SSL/TLS X.509 証明書とキーの作成、保存、更新に役立ちます。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、VPC から VPC の外部サービスへのプライベート接続の作成に役立ちます。 ## エピック ### SNI 証明書を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SNI 証明書を作成し、その証明書を ACM にインポートします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | ネットワーク管理者 | ### VPC エンドポイントをルーティングできないプライベートサブネットにデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | API Gateway にインターフェイス VPC エンドポイントを作成します。 | インターフェイス VPC エンドポイントを作成するには、Amazon Virtual Private Cloud (Amazon VPC) ドキュメントの[インターフェイス VPC エンドポイントを使用して AWS サービスにアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)の指示に従います。 | クラウド管理者 | ### Application Load Balancer を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションのターゲットグループを作成します。 | アプリケーションの UI リソースの[ターゲットグループを作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)します。 | クラウド管理者 | | API ゲートウェイエンドポイントのターゲットグループを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | クラウド管理者 | | Application Load Balancer を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | クラウド管理者 | | リスナールールを作成します。 | [リスナールール](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-rules)を作成して、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | クラウド管理者 | ### Route 53 を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライベートホストゾーンを作成します。 | domain.com の[プライベートホストゾーンを作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-creating.html)します。 | クラウド管理者 | | ドメインレコードを作成します。 | 以下の [レコードセットを作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | クラウド管理者 | ### API ゲートウェイにプライベート API エンドポイントを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライベート API エンドポイントを作成して設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | アプリ開発者、クラウド管理者 | | カスタムドメイン名を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-an-amazon-api-gateway-api-on-an-internal-website-using-private-endpoints-and-an-application-load-balancer.html) | クラウド管理者 | ## 関連リソース + [Amazon API Gateway](https://aws.amazon.com/api-gateway/) + [Amazon Route 53](https://aws.amazon.com/route53/) + [Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) + [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) # Amazon Cognito と IaC オートメーションを使用して Amazon Quick Sight ビジュアルコンポーネントをウェブアプリケーションに埋め込む *Ishita Gupta、Saurabh Singh、Srishti Wadhwa、Amazon Web Services* ## 概要 このパターンは、登録済みユーザー埋め込みと合理化された Amazon Cognito 認証を使用して、Amazon Quick Sight ビジュアルコンポーネントを React アプリケーションに埋め込むための特殊なアプローチを提供します。これらのリソースは、Infrastructure as Code (IaC) テンプレートを通じてデプロイされます。従来のダッシュボード埋め込みとは異なり、このソリューションは特定のグラフとグラフを分離して React アプリケーションに直接統合するため、パフォーマンスとユーザーエクスペリエンスの両方が大幅に向上します。 このアーキテクチャは、Amazon Cognito ユーザー管理と Quick Sight アクセス許可の間に効率的な認証フローを確立します。ユーザーは Amazon Cognito を介して認証し、Quick Sight のダッシュボード共有ルールに基づいて承認されたビジュアライゼーションにアクセスします。この合理化されたアプローチにより、堅牢なセキュリティコントロールを維持しながら、Quick Sight コンソールに直接アクセスする必要がなくなります。 完全な環境は、以下を含むすべての必要なインフラストラクチャコンポーネントをプロビジョニングする単一の AWS CloudFormation テンプレートを介してデプロイされます。 + AWS Lambda と Amazon API Gateway を使用するサーバーレスバックエンド + Amazon CloudFront、Amazon Simple Storage Service (Amazon S3)、および AWS WAF + Amazon Cognito を使用した ID 管理 すべてのコンポーネントは、最小特権 AWS Identity and Access Management (IAM) ポリシー、 AWS WAF 保護、end-to-end暗号化によるセキュリティのベストプラクティスに従って設定されます。 このソリューションは、ユーザーアクセスをきめ細かく制御しながら、安全でインタラクティブな分析をアプリケーションに統合したい開発チームや組織に最適です。このソリューションは、 AWS マネージドサービスとオートメーションを使用して、埋め込みプロセスを簡素化し、セキュリティを強化し、進化するビジネスニーズを満たすスケーラビリティを確保します。 対象者とユースケース: + React アプリに分析を埋め込む**フロントエンド開発者** + ユーザーまたはロールベースのデータ視覚化を提供する **Software as a Service (SaaS) 製品チーム** + AWS 分析をカスタムポータルに統合したい**ソリューションアーキテクト** + ダッシュボードへのフルアクセスを必要とせずに、認証されたユーザーにビジュアルを公開したい**ビジネスインテリジェンス (BI) 開発者** + インタラクティブなクイックサイトチャートを内部ツールに埋め込む**エンタープライズチーム** ## 前提条件と制限 **前提条件** このパターンを正常に実装するには、以下が設定されていることを確認してください。 + **アクティブ AWS アカウント** – CloudFormation スタックをデプロイし、Lambda、API Gateway、Amazon Cognito、CloudFront、Amazon S3 リソースを作成するアクセス許可 AWS アカウント を持つ 。 + **Amazon Quick Sight アカウント** – ビジュアルを含むダッシュボードが少なくとも 1 つあるアクティブな Quick Sight アカウント。セットアップ手順については、[「Amazon Quick ドキュメント」の「チュートリアル: サンプルデータを使用して Amazon Quick Sight ダッシュボードを作成する](https://docs.aws.amazon.com/quicksuite/latest/userguide/example-analysis.html)」を参照してください。 + 以下で構成される**開発環境**。 + Node.js (バージョン 16 以降) + npm または yarn がインストールされている + React ビルドツールとしての Vite + React (バージョン 19.1.1) + **ダッシュボード共有** – ダッシュボードは Quick Sight で共有する必要があり、実装者は埋め込みビジュアルまたはダッシュボードにアクセスするにはログインする必要があります。 **制限事項** + このパターンでは、登録されたユーザー埋め込み方法を使用します。そのため、実装者はアクティブな Quick Sight アカウントを持っている必要があります。 + アクセスは、このパターンを実装している認証された Quick Sight ユーザーと明示的に共有されているダッシュボードとビジュアルに制限されます。実装者に正しいアクセス権がない場合、埋め込み URL の生成は失敗し、ビジュアルはロードされません。 + CloudFormation スタックは、Quick Sight、API Gateway、Amazon Cognito AWS リージョン がサポートされている にデプロイする必要があります。利用可能なリージョンについて、詳しくは「[AWS のサービス by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」をご確認ください。 **製品バージョン** + [Quick Sight Embedding SDK](https://www.npmjs.com/package/amazon-quicksight-embedding-sdk) バージョン 2.10.1 + [React](https://www.npmjs.com/package/react) バージョン 19.1.1 + このソリューションで使用される最新の React および Vite バージョンとの互換性を確保するための [Node.js](https://nodejs.org/en/download) バージョン 16 以降 ## アーキテクチャ **ターゲットアーキテクチャ** 次の図は、本パターンのアーキテクチャとワークフローを示したものです。 ![\[Quick Sight ビジュアルを React アプリケーションに埋め込むためのアーキテクチャとワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/75ad12b1-caaa-4532-b709-8f3eaf3f9cc0/images/d0905f61-9055-49cf-887d-f46f5ca6c871.png) このワークフローでは、次の操作を行います。 1. **ユーザーはアプリケーションにアクセスします**。ユーザーはブラウザを使用して React ウェブアプリケーションを開きます。リクエストは CloudFront ディストリビューションにルーティングされ、アプリケーションのコンテンツ配信ネットワークとして機能します。 1. は**AWS WAF 悪意のあるリクエストをフィルタリング**します。** **リクエストが CloudFront に到達する前に、トラフィックを検査し、セキュリティルールに基づいて悪意のあるリクエストや疑わしいリクエストをブロック AWS WAF AWS WAF します。 1. **Amazon S3 は静的ファイル**を提供します。リクエストがクリーンの場合、CloudFront はオリジンアクセスコントロール (OAC) を使用してプライベート S3 バケットから静的フロントエンドアセット (HTML、JS、CSS) を取得し、ブラウザに配信します。 1. **ユーザーがサインインします**。アプリケーションがロードされると、ユーザーは Amazon Cognito を通じてサインインします。Amazon Cognito はユーザーを認証し、承認された API アクセス用の安全な JSON ウェブトークン (JWT) を返します。 1. **アプリケーションは API リクエストを行います**。ログイン後、React アプリケーションは API Gateway 上の`/get-embed-url`エンドポイントに安全な呼び出しを行い、認証のためにリクエストヘッダーに JWT トークンを渡します。 1. **トークンが検証**されます。API Gateway は、Amazon Cognito オーソライザーを使用してトークンを検証します。トークンが有効な場合、リクエストは続行されます。それ以外の場合は、401 (未承認) レスポンスで拒否されます。 1. **リクエストは処理のために Lambda に送信されます**。その後、検証されたリクエストはバックエンドの Lambda 関数に転送されます。この関数は、リクエストされた Quick Sight ビジュアルの埋め込み URL の生成を担当します。 1. **Lambda は Quick Sight から埋め込み URL を生成します**。IAM は、適切なアクセス許可を持つ IAM ロールを使用して Quick Sight `GenerateEmbedUrlForRegisteredUser` API を呼び出し、安全でユーザースコープのビジュアル URL を生成します。 1. **Lambda は API Gateway に埋め込み URL を返します**。Lambda は、生成された埋め込み URL を JSON レスポンスの一部として API Gateway に送信します。その後、このレスポンスはフロントエンドに配信される準備が整います。 1. **埋め込み URL がブラウザに送信されます**。埋め込み URL は API レスポンスとしてブラウザに返されます。 1. **ビジュアルがユーザーに表示されます**。** **React アプリケーションはレスポンスを受け取り、Quick Sight Embedding SDK を使用して特定のビジュアルをユーザーにレンダリングします。 **自動化とスケール** バックエンドとフロントエンドのデプロイは、 を使用して完全に自動化されます。これにより CloudFormation、Amazon Cognito、Lambda、API Gateway、Amazon S3、CloudFront AWS WAF、IAM ロール、Amazon CloudWatch など、必要なすべての AWS リソースが 1 回のデプロイでプロビジョニングされます。 この自動化により、すべての環境で一貫した反復可能なインフラストラクチャが確保されます。すべてのコンポーネントは自動的にスケーリングされます。Lambda は関数呼び出しに合わせて調整し、CloudFront はキャッシュされたコンテンツをグローバルに提供し、API Gateway は受信リクエストに合わせてスケーリングします。 ## ツール **AWS のサービス** + [Amazon Quick Sight](https://aws.amazon.com/quicksuite/quicksight/) は、インタラクティブなダッシュボードやビジュアルの作成、管理、埋め込みに役立つクラウドネイティブのビジネスインテリジェンスサービスです。 + [Amazon API Gateway](https://aws.amazon.com/api-gateway/) はAPIs を管理します。 + [AWS Lambda](https://aws.amazon.com/lambda/)は、このパターンが安全な Quick Sight 埋め込み URLs動的に生成するために使用するサーバーレスコンピューティングサービスであり、リクエストに基づいて自動的にスケーリングされます。 + [Amazon Cognito](https://aws.amazon.com/cognito/) はユーザーに認証と認可を提供し、API アクセス用の安全なトークンを発行します。 + [Amazon S3](https://aws.amazon.com/s3/) は、このパターンの静的フロントエンドアセットをホストし、CloudFront を通じて安全に提供します。 + [Amazon CloudFront ](https://aws.amazon.com/cloudfront/getting-started/)は、低レイテンシーでフロントエンドコンテンツをグローバルに配信し、トラフィックフィルタリング AWS WAF のために と統合します。 + [AWS WAF](https://aws.amazon.com/waf/) セキュリティルールとレート制限を適用することで、 はウェブアプリケーションを悪意のあるトラフィックから保護します。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)は、すべてのアプリケーションリソースのプロビジョニングと設定を 1 回のデプロイで自動化します。 + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) は、Lambda、API Gateway、および からログとメトリクスを収集し、モニタリングとトラブルシューティング AWS WAF を行います。 **開発ツール** + [React JS](https://react.dev/) は、このパターンがウェブアプリケーションを構築し、埋め込み Quick Sight ビジュアルを統合するために使用されるフロントエンドフレームワークです。 + [Vite](https://vite.dev/) は、React アプリケーションの迅速な開発と最適化された本番稼働用ビルドに使用されるビルドツールです。 + [Quick Sight Embedding SDK](https://www.npmjs.com/package/amazon-quicksight-embedding-sdk/v/2.10.1) は、Quick Sight ビジュアルを React アプリケーションに埋め込むことを容易にし、アプリケーションとビジュアル間のシームレスなやり取りを可能にします。 **コードリポジトリ** このパターンのコードは、React リポジトリの GitHub Amazon Quick Sight Visual Embedding で入手できます。 [https://github.com/aws-samples/sample-quicksight-visual-embedding](https://github.com/aws-samples/sample-quicksight-visual-embedding) ## ベストプラクティス このパターンでは、次のセキュリティのベストプラクティスが自動的に実装されます。 + JWT ベースの認証に Amazon Cognito ユーザープールを使用し、オプションの多要素認証 (MFA) を使用します。 + Amazon Cognito オーソライザーで APIs を保護し、すべてのサービスに最小特権の IAM ポリシーを適用します。 + Quick Sight に登録されたユーザーの埋め込みを実装し、リーダーロールを使用してユーザーを自動プロビジョニングします。 + CloudFront と HTTPS を介して TLS 1.2 以降のバージョンをサポートする転送中の暗号化を適用します。 + バージョニングと OAC で Amazon S3 の AES-256 を使用して、保管中のデータを暗号化します。 + スロットリングとクォータを使用して API Gateway 使用量プランを設定します。 + リザーブド同時実行と環境変数保護を使用して Lambda を保護します。 + Amazon S3、CloudFront、Lambda、API Gateway のログ記録を有効にします。CloudWatch を使用してサービスをモニタリングします。 + ログを暗号化し、アクセスコントロールを適用し、HTTPS 以外のアップロードまたは暗号化されていないアップロードに対して拒否ポリシーを適用します。 さらに、以下をお勧めします。 + CloudFormation を使用してデプロイを自動化し、環境間で一貫した設定を維持します。 + 各ユーザーに、埋め込みビジュアルにアクセスするための正しい Quick Sight アクセス許可があることを確認します。 + Amazon Cognito オーソライザーで API Gateway エンドポイントを保護し、すべての IAM ロールに最小特権の原則を適用します。 + Amazon リソースネーム (ARNs) や IDs などの機密情報は、ハードコーディングするのではなく、環境変数に保存します。 + 依存関係を減らし、コールドスタートのパフォーマンスを向上させることで、Lambda 関数を最適化します。詳細については、 AWS ブログ記事[「Optimizing cold start performance of AWS Lambda using advanced priming strategies with SnapStart](https://aws.amazon.com/blogs/compute/optimizing-cold-start-performance-of-aws-lambda-using-advanced-priming-strategies-with-snapstart/)」を参照してください。 + CloudFront ドメインを Quick Sight 許可リストに追加して、安全なビジュアル埋め込みを有効にします。 + CloudWatch と を使用してログ記録、アラート、トラフィック保護 AWS WAF を行い、パフォーマンスとセキュリティをモニタリングします。 **その他の推奨されるベストプラクティス** + からの SSL 証明書でカスタムドメインを使用して AWS Certificate Manager 、安全でブランド化されたユーザーエクスペリエンスを提供します。 + カスタマーマネージド AWS Key Management Service (AWS KMS) キーを使用して Amazon S3 データおよび CloudWatch ログを暗号化し、暗号化をより詳細に制御します。 + ジオブロッキング、SQL インジェクション (SQLi)、クロスサイトスクリプティング (XSS) 保護、カスタムフィルターを使用して AWS WAF ルールを拡張し、脅威の防止を強化します。 + CloudWatch アラーム、および を有効に AWS CloudTrail して AWS Config、リアルタイムのモニタリング、監査、設定コンプライアンスを実現します。 + きめ細かな IAM ポリシーを適用し、API キーローテーションを適用し、絶対に必要な場合にのみクロスアカウントアクセスを許可します。 + System and Organization Controls 2 (SOC 2)、General Data Protection Regulation (GDPR)、Health Insurance Portability and Accountability Act (HIPAA) などのコンプライアンスフレームワークとの整合性を確保するため、定期的なセキュリティ評価を実施します。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | このソリューションの GitHub リポジトリをローカルシステムにクローンし、プロジェクトディレクトリに移動します。
git clone https://github.com/aws-samples/sample-quicksight-visual-embedding.git

cd sample-quicksight-visual-embedding
このリポジトリには、ソリューションをデプロイするために必要な CloudFormation テンプレートと React ソースコードが含まれています。 | アプリ開発者 | ### CloudFormation スタックをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テンプレートのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) 詳細については、 CloudFormation ドキュメントの[「スタックの作成と管理](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html)」を参照してください。 | AWS 管理者 | | スタックの作成をモニタリングします。 | ステータスが **CREATE\$1COMPLETE** になるまで、**イベント**タブでスタックをモニタリングします。 | AWS 管理者 | | スタック出力を取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | AWS 管理者 | ### フロントエンド環境を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Quick Sight ビジュアル識別子を取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | Quick Sight 管理者 | | ローカル React 環境を設定します。 | ローカル React 環境をセットアップして AWS リソースにリンクするには、ローカル GitHub リポジトリの `my-app/`フォルダに `.env` ファイルを作成します。ファイルに以下を入力します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)`.env` ファイルの例を次に示します。
VITE_AWS_REGION=us-east-1

# Cognito Configuration (from CloudFormation outputs)
VITE_USER_POOL_ID=us-east-1_xxxxxxxxx VITE_USER_POOL_WEB_CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxxxx

# API Configuration (from CloudFormation outputs)
VITE_API_URL=https:/your-api-id.execute-api.us-east-1.amazonaws.com/prod

# QuickSight Visual Configuration
VITE_DASHBOARD_ID=your-dashboard-id 
VITE_SHEET_ID=your-sheet-id 
VITE_VISUAL_ID=your-visual-id
| アプリ開発者 | ### ユーザー認証を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Cognito でユーザーを作成または管理する | 埋め込み Quick Sight ビジュアルへの認証されたユーザーアクセスを有効にするには、まず Amazon Cognito でユーザーを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | AWS 管理者 | | Quick Sight ダッシュボードへのアクセスを提供する | Quick Sight ビジュアルへのアクセスを提供するには、認証されたユーザーにビューワーアクセス許可を付与します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)各ユーザーには、ダッシュボードへのリンクが記載された E メールが送信されます。アクセス許可は、**共有**メニューからいつでも変更できます。詳細については、[Amazon Quick ドキュメントの「個々の Amazon Quick Sight ユーザーとグループに Amazon Quick Sight のダッシュボードへのアクセス権を付与](https://docs.aws.amazon.com/quicksuite/latest/userguide/share-a-dashboard-grant-access-users.html)する」を参照してください。 | Quick Sight 管理者 | ### React フロントエンドを構築およびデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 依存関係をインストールし、プロジェクトを構築します。 | React アプリケーションディレクトリで、次のコマンドを実行して、最適化された本稼働ファイルを生成します。
cd my-app
npm install
npm run build
| アプリ開発者 | | ビルドファイルを Amazon S3 にアップロードします。 | ディレクトリから によってプロビジョニングされた S3 バケット`my-app/dist/`にすべてのファイルをアップロードします CloudFormation (フォルダ自体はアップロードしないでください）。 | アプリ開発者 | | CloudFront の無効化を作成します。 | [CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v4/home)で、デプロイ後にキャッシュされたコンテンツ`/*`を更新するパスの無効化を作成します。手順については、CloudFront ドキュメントの[「ファイルの無効化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation_Requests.html)」を参照してください。 | AWS 管理者 | ### Quick Sight 許可リストを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFront ドメインを Quick Sight 許可リストに追加します。 | CloudFront ドメインで Quick Sight ビジュアルを安全に埋め込むには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | Quick Sight 管理者 | ### アプリケーションにアクセスして機能を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | React アプリケーションを開きます。 | **CloudFront ドメイン** ( CloudFormation 出力から) を使用して、デプロイされた React ウェブアプリケーションをブラウザで開きます。 | アプリ所有者 | | 認証を確認します。 | Amazon Cognito 認証情報を使用してアプリケーションにサインインし、API Gateway を介して認証フローと JWT 検証を検証します。 | アプリ所有者 | | 埋め込みビジュアルを確認します。 | Quick Sight ビジュアルが、ユーザー固有のアクセス許可に基づいてアプリケーション内で正しくロードされていることを確認します。 | アプリ所有者 | | API と Lambda の接続を検証します。 | アプリケーションが `/get-embed-url` API を正常に呼び出し、エラーなしで有効な Quick Sight 埋め込み URLs を取得できることを確認します。 | アプリ所有者 | ### アプリケーションのモニタリングと保守 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch を使用してモニタリングします。 | AWS オブザーバビリティツールを使用してアプリケーションをモニタリングし、本番環境で安全でスケーラブルなパフォーマンスを維持できます。CloudWatch で Lambda ログ、API Gateway メトリクス、Amazon Cognito 認証イベントを確認して、アプリケーションの正常性を確認し、異常を検出します。 | AWS 管理者 | | ログ AWS WAF と CloudFront ログを追跡します。 | AWS WAF ログにブロックされたリクエストや疑わしいリクエストがないか、CloudFront アクセスログにパフォーマンスとキャッシュメトリクスがないかを検査します。 | AWS 管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 「ドメインが許可されません」エラー | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | | 認証エラー | 考えられる原因:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)解決方法:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | | API Gateway エラー | 考えられる原因:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)解決方法:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | | Quick Sight ビジュアルはロードされません | 考えられる原因:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)解決方法:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | | 「ユーザーにアクセスできません」エラー | 考えられる原因:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html)解決策:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/embed-quick-sight-visual-components-into-web-apps-cognito-iac.html) | ## 関連リソース ** AWS ドキュメント** + [Amazon Quick サブスクリプションにサインアップする](https://docs.aws.amazon.com/quicksight/latest/user/signing-up.html) + [Amazon Quick Sight の埋め込み分析](https://docs.aws.amazon.com/quicksuite/latest/userguide/embedded-analytics.html) + [Quick Sight API リファレンス – GenerateEmbedUrlForRegisteredUser](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_GenerateEmbedUrlForRegisteredUser.html) + [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools.html) + [AWS Lambda デベロッパーガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [Amazon API Gateway デベロッパーガイド](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) + [CloudWatch での基本的なモニタリングと詳細なモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html) + [AWS CloudFormation ユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [Amazon CloudFront 開発者ガイド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) + [AWS WAF デベロッパーガイド](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) **チュートリアルと動画** + [Amazon Quick Sight の埋め込み分析](https://docs.aws.amazon.com/quicksight/latest/user/embedded-analytics.html) + [Amazon Quick Sight YouTube チュートリアル](https://www.youtube.com/results?search_query=amazon+quicksight+embedding) # Green Boost を使用したフルスタックのクラウドネイティブなウェブアプリケーション開発を探索する *Ben Stickley と Amiin Samatar、Amazon Web Services* ## 概要 変化する開発者のニーズに対応するため、Amazon Web Services（AWS は、クラウドネイティブなウェブアプリケーションを効率的に開発するための重要なニーズを認識しています。AWS は、AWS クラウドへのウェブアプリケーションのデプロイに関連する一般的な障害を克服できるようサポートすることに重点を置いています。このパターンは、TypeScript、AWS Cloud Development Kit (AWS CDK)、React、Node.js などの最新テクノロジーの機能を活用することで、開発プロセスを合理化および迅速化することを目的としています。 Green Boost (GB) ツールキットを基盤としたこのパターンは、AWS の広範な機能を最大限に活用するウェブアプリケーションをコンストラクトするための実践的なガイドとなります。Amazon Aurora PostgreSQL 互換エディションと統合された基本的な CRUD (作成、読み取り、更新、削除) ウェブアプリケーションをデプロイするプロセスを案内する、包括的なロードマップして機能します。これは、Green Boost コマンドラインインターフェイス (Green Boost CLI) を使用して、ローカル開発環境を確立することによって実現されます。 アプリケーションのデプロイが成功した後、このパターンではインフラストラクチャ設計、バックエンドとフロントエンドの開発、視覚化のための cdk-dia などの基本的なツールを含む、ウェブアプリケーションの主要なコンポーネントを詳細に調査し、効率的なプロジェクト管理を促進します。 ## 前提条件と制限 **前提条件** + インストール済み[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + [Visual Studio Code (VS Code)](https://code.visualstudio.com/download) をインストール済み + [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) をインストール済み + [AWS CDK ツールキット](https://docs.aws.amazon.com/cdk/v2/guide/cli.html) をインストール済み + [Node.js 18](https://nodejs.org/en/download) をインストール済み、または [pnpm を搭載した Node.js 18](https://pnpm.io/cli/env) がアクティブ + [pnpm](https://pnpm.io/installation) をインストール済み (Node.js のインストールに含まれない場合) + TypeScript、AWS CDK、Node.js、React に関する基本的な知識 + [アクティブな AWS アカウント](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) + `us-east-1` の AWS CDK を使用して、[ブートストラップされた AWS アカウント](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)。Amazon CloudFront Lambda @Edge 関数をサポートするには `us-east-1` AWS リージョンが必要です。**** + ターミナル環境における [AWS セキュリティ認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html) (`AWS_ACCESS_KEY_ID` を含む) の適切な設定 + Windows ユーザーの場合、管理者モードのターミナル (pnpm がノードモジュールを処理する方法に対応） **製品バージョン** + AWS SDK for JavaScript バージョン 3 + AWS CDK バージョン 2 + AWS CLI バージョン 2.2 + Node.js バージョン 18 + React バージョン 18 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Aurora PostgreSQL 互換エディション + Amazon CloudFront + Amazon CloudWatch + Amazon Elastic Compute Cloud (Amazon EC2) + AWS Lambda + AWS Secrets Manager + Amazon Simple Notification Service (Amazon SNS) + Amazon Simple Storage Service (Amazon S3) + AWS WAF **ターゲット アーキテクチャ** 次の図は、ユーザーリクエストが Amazon CloudFront、AWS WAF、AWS Lambda を通過し S3 バケット、Aurora データベース、EC2 インスタンスとやり取りされ、最終的に開発者に届くことを示しています。一方、管理者は通知とモニタリングの目的で Amazon SNS と Amazon CloudWatch を使用します。 ![\[Green Boost CLI を使用して、Amazon Aurora PostgreSQL と統合された CRUD ウェブアプリケーションをデプロイするプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bacafc47-07c0-494b-8bbf-24bdc9b54f6a/images/129691e9-7fd3-4208-ab8c-05b9f40a5c4c.png) デプロイ後のアプリケーションをより詳しく表示するには、次の例のように [cdk-dia](https://github.com/pistazie/cdk-dia) を使用して図を作成できます。 ![\[最初の図はユーザー中心のビュー、cdk-dia 図は技術インフラストラクチャビューを示しています。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bacafc47-07c0-494b-8bbf-24bdc9b54f6a/images/5e4c3321-47bd-44e7-bf14-f470eed984c1.png) これらの図は、ウェブアプリケーションのアーキテクチャを 2 つの異なる視点から示しています。cdk-dia 図では、AWS CDK インフラストラクチャの詳細な技術情報を示しており、Amazon Aurora PostgreSQL 互換や AWS Lambda などの特定の AWS サービスが強調されています。これとは対照的に、もう 1 つの図は、データの論理的な流れとユーザーとのやり取りを強調した、より広い視点を採用しています。主な違いは詳細レベルにあります。cdk-dia は技術的な複雑さについて詳しく調べていますが、最初の図はよりユーザー中心のビューを提供しています。 cdk-dia 図の作成については、「*AWS CDK を使用してアプリケーションのインフラストラクチャを理解する*」というエピックで説明しています。 ## ツール **AWS サービス** + [Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)は、PostgreSQL デプロイのセットアップ、運用、スケーリングを支援する、フルマネージド型で ACID 互換のリレーショナルデータベースエンジンです。 + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。 + 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。 + [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。 + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、AWS のリソースや、AWS で実行されるアプリケーションをリアルタイムにモニタリングします。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。 + 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。アプリケーションとリソースの管理が簡略化され、オペレーション上の問題の検出と解決時間が短縮され、AWS リソースを大規模かつセキュアに管理できるようになります。このパターンは、AWS Systems Manager Session Manager を使用します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意の数のデータを保存、保護、検索できるクラウドベースのオブジェクトストレージサービスです。[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、ウェブサーバーやメールアドレスを含む、パブリッシャーとクライアント間のメッセージの交換を調整して管理するのに役立ちます。 + [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html) は、保護されたウェブアプリケーションリソースに転送される HTTP と HTTPS リクエストをモニタリングするのに役立つウェブアプリケーションのファイアウォールです。 **その他のツール** + [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。 + [Green Boost](https://awslabs.github.io/green-boost/overview/intro) は、AWS でウェブアプリケーションを構築するためのツールキットです。 + [Next.js](https://nextjs.org/docs) は、機能を追加したり最適化したりするための React フレームワークです。 + [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。 + [pgAdmin](https://www.pgadmin.org/) は PostgreSQL 用のオープンソース管理ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。 + [pnpm](https://pnpm.io/motivation) は Node.js プロジェクトの依存関係を管理するパッケージマネージャーです。 ## ベストプラクティス 以下の推奨事項の詳細については、[エピック](#explore-full-stack-cloud-native-web-application-development-with-green-boost-epics) セクションを参照してください。 + Amazon CloudWatch ダッシュボードとアラームを使用してインフラストラクチャをモニタリングします。 + cdk-nag を使用して静的 Infrastructure as Code (IaC) 分析を実行することで、AWS のベストプラクティスを実施します。 + Systems Manager セッションマネージャを使用して、SSH (Secure Shell) トンネル経由でデータベースポートの転送を確立します。これは、公開 IP アドレスを使用するよりもセキュアです。 + `pnpm audit` を実行して脆弱性を管理します。 + [ESLint](https://eslint.org/) を使用して静的な TypeScript コード分析を実行し、[Prettier](https://prettier.io/) を使用してコードフォーマットを標準化することでベストプラクティスを実施します。 ## エピック ### Aurora PostgreSQL 互換の CRUD ウェブアプリケーションのデプロイ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Green Boost CLI をインストールします。 | Green Boost CLI をインストールするには、次のコマンドを実行します。
pnpm add -g gboost
| アプリ開発者 | | GB アプリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | 依存関係をインストールしてアプリをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)デプロイが完了するまでお待ちください (約 20 分)。待っている間、CloudFormation コンソールで AWS CloudFormation スタックをモニタリングできます。コードマップで定義されたコンストラクトが、デプロイされたリソースにどのようにマッピングされるかに注目してください。CloudFormation コンソールの [CDK コンストラクトツリービュー](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)を確認してください。 | アプリ開発者 | | アプリにアクセスします。 | GB アプリをローカルにデプロイしたら、CloudFront URL を使用してアクセスできます。URL はターミナル出力に表示されますが、見つけるのは少し難しいかもしれません。URL を素早く見つけるには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)代わりに、Amazon CloudFront コンソールにアクセスして、Amazon CloudFront URL を確認することもできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)ディストリビューションに関連付けられた**ドメイン名**をコピーします。`your-unique-id.cloudfront.net` のようになります。 | アプリ開発者 | ### Amazon CloudWatch を使用してモニタリングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudWatch ダッシュボードを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | アラートを有効にします。 | CloudWatch ダッシュボードは、ウェブアプリケーションをアクティブにモニタリングするのに役立ちます。ウェブアプリを受動的にモニタリングするには、アラートを有効にします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | ### AWS CDK を使用してアプリのインフラストラクチャを理解する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アーキテクチャ図を作成します。 | [cdk-dia](https://github.com/pistazie/cdk-dia) を使用して、ウェブアプリのアーキテクチャ図を生成します。アーキテクチャを視覚化することで、チームメンバー間の理解とコミュニケーションが向上します。システムコンポーネントとその関係の明確な概要が示されています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | cdk-nag を使用してベストプラクティスを実施します。 | [cdk-nag](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/check-aws-cdk-applications-or-cloudformation-templates-for-best-practices-by-using-cdk-nag-rule-packs.html) を使用すると、ベストプラクティスを実施し、セキュリティの脆弱性や設定ミスのリスクを軽減することで、セキュアでコンプライアンスを確保したインフラストラクチャを維持できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | ### データベース設定とスキーマを評価する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 環境変数を追加します。 | 必要な環境変数を取得するには、以下の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | ポート転送を確立します。 | ポート転送を確立するには、以下の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | Systems Manager Session Manager のタイムアウトを調整します。 | (オプション) デフォルトの 20 分のセッションタイムアウトが短すぎる場合は、Systems Manager コンソールで [**セッションマネージャ**]、[**設定**]、[**編集**]、[**アイドルセッションタイムアウト**] の順に選択して、最大 60 分まで増やすことができます。 | アプリ開発者 | | データベースを視覚化します。 | pgAdmin は、PostgreSQL データベースを管理するための使いやすいオープンソースツールです。データベースタスクを簡素化し、データベースを効率的に作成、管理、最適化できるようにします。　 このセクションでは、[pgAdmin のインストール](https://www.pgadmin.org/download/)から、その機能を PostgreSQL データベース管理に使用する方法について説明します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | ### Node.js でデバッグする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アイテム作成のユースケースをデバッグします。 | アイテム作成のユースケースをデバッグするには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | ### フロントエンドを開発する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 開発サーバーを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | ### Green Boost を使用したツーリング | タスク | 説明 | 必要なスキル | | --- | --- | --- | | monorepo と pnpm パッケージマネージャーを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | pnpm スクリプトを実行します。 | リポジトリのルートで以下のコマンドを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)これらのコマンドが、すべてのワークスペースでどのように実行されるかに注目してください。これらのコマンドは、各ワークスペースの `package.json#scripts` フィールドで定義されます。 | アプリ開発者 | | ESLint を使用して静的コード分析を行います。 | ESLint の静的コード分析機能をテストするには、以下の作業を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | 依存関係と脆弱性を管理します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリ開発者 | | Husky を使用してフックをプリコミットします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html)これらのツールは、不正なコードがアプリケーションに侵入するのを防止するためのメカニズムです。 | アプリ開発者 | ### インフラストラクチャをティアダウンする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アカウントからデプロイを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/explore-full-stack-cloud-native-web-application-development-with-green-boost.html) | アプリデベロッパー | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ポート転送を確立できない | AWS 認証情報が正しく設定され、必要な権限があることを確認してください。踏み台ホスト ID (`DB_BASTION_ID`) とデータベースエンドポイント (`DB_ENDPOINT`) の環境変数が正しく設定されていることを再確認してください。それでも問題が解決しない場合は、[SSH 接続と Session Manager のトラブルシューティングに関する](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html) AWS ドキュメントを参照してください。 | | `localhost:3000` で、ウェブサイトが読み込まれない | ターミナルの出力に、転送アドレスを含めてポート転送が成功したことが示されていることを確認します。ローカルマシンでポート 3000 を使用しているプロセスが競合していないことを確認します。Green Boost アプリケーションが正しく設定され、想定されるポート (3000) で実行されていることを確認します。ウェブブラウザで、ローカル接続をブロックする可能性のあるセキュリティ拡張機能や設定がないか確認してください。 | | ローカルデプロイ中のエラーメッセージ (`pnpm deploy:local`) | エラー メッセージを注意深く確認して、問題の原因を特定します。必要な環境変数と設定ファイルが正しく設定されていることを確認します。 | ## 関連リソース + [AWS SDK ドキュメント](https://docs.aws.amazon.com/cdk/latest/guide/home.html) + [Green Boost ドキュメント](https://awslabs.github.io/green-boost/learn/m1-deploy-gb-app) + [Next.js ドキュメント](https://nextjs.org/docs) + [Node.js ドキュメント](https://nodejs.org/en/docs/) + [React ドキュメント](https://reactjs.org/docs/getting-started.html) + [TypeScript ドキュメント](https://www.typescriptlang.org/docs/)   # AWS CodeBuild を使用して GitHub から Node.js アプリケーションのユニットテストを実行する *Thomas Scott と Jean-Baptiste Guillois、Amazon Web Services* ## 概要 このパターンは、Node.js ゲーム API のサンプルソースコードと主要ユニットテストコンポーネントを提供します。また、継続的インテグレーションおよび継続的デリバリー (CI/CD) ワークフローの一環として、AWS CodeBuild を使用した、GitHub リポジトリーからのこれらのユニットテストの実行方法も含まれます。 ユニットテストは、*ユニット*と呼ばれるアプリケーションのさまざまな部分が個別に独立してテストされ、正しく動作するかどうかがテストされるソフトウェア開発プロセスです。テストはコードの品質を検証し、期待どおりに機能することを確認します。テストを参考にすれば、他の開発者も簡単にコードベースに慣れることができます。ユニットテストは、将来のリファクタリング時間を短縮し、エンジニアがコードベースに素早く慣れるようにする上で役立ち、期待される動作に自信を与えます。 ユニットテストでは、AWS Lambda 関数など、個々の関数をテストします。ユニットテストを作成するには、テストフレームワークとテスト (アサーション) を検証する方法が必要です。このパターンのコード例では、[Mocha](https://mochajs.org/) テストフレームワークと [Chai アサーションライブラリ](https://www.chaijs.com/)を使用します。  ユニットテストとテストコンポーネントの例の詳細については、「[追加情報](#run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild-additional)」セクションを参照してください。 ## 前提条件と制限事項 + 正しい CodeBuild 権限があるアクティブな AWS アカウント + GitHub アカウント (「[サインアップの手順](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account)」を参照) + Git (「[インストール手順](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」を参照) + 変更を行い、コードを GitHub にプッシュする Code Editor ## アーキテクチャ このパターンは、次の図に示すアーキテクチャを実装します。 ![\[CodeBuild と GitHub リポジトリでユニットテストを実行する AWS クラウドアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e18428ce-9ecf-4204-9f1f-5a6683a720b2/images/4f4a3d1a-705a-45a6-b937-9212b188d226.png) ## ツール **ツール** + [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) はコード開発に使用できるバージョン管理システムです。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/) はフルマネージド型の継続的統合サービスであり、このサービスによりソースコードをコンパイルし、テストを実行し、デプロイ可能なソフトウェアパッケージを作成します。CodeBuild を使用すると、ビルドサーバーのプロビジョニング、管理、スケーリングが不要になります。CodeBuild では、継続的にスケーリングされ、複数のビルドが同時にプロセスされるため、ビルドの実行までキューで待機することはありません。パッケージ済みのビルド環境を使用、またはご自分のビルドツールを使用するカスタムビルド環境を作成できることですぐに開始できます。CodeBuild では毎分ごとに使用するコンピューティングリソースの使用量が有料になります。 **コード** このパターンのソースコードは、GitHub の[サンプルゲームユニットテストアプリケーション](https://github.com/aws-samples/node-js-tests-sample)リポジトリにあります。このサンプルから独自の GitHub リポジトリを作成 (オプション 1)、またはこのパターンのサンプルリポジトリを直接使用 (オプション 2) できます。次のセクションの各オプションの指示に従います。従うオプションは、ユースケースによって異なります。 ## エピック ### オプション 1 - CodeBuild を使用して個人用 GitHub リポジトリでユニットテストを実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サンプルプロジェクトに基づいて独自の GitHub リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html) | アプリ開発者、AWS 管理者、AWS DevOps | | 新しい CodeBuild プロジェクトを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html) | アプリ開発者、AWS 管理者、AWS DevOps | | ビルドを開始します。 | **確認** ページで、[**Start build（ビルドの開始）**] を選択してビルドを実行します。 | アプリ開発者、AWS 管理者、AWS DevOps | ### オプション 2 - CodeBuild を使用してパブリック GitHub リポジトリでユニットテストを実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しい CodeBuild ビルドプロジェクトを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html) | アプリ開発者、AWS 管理者、AWS DevOps | | ビルドを開始します。 | **確認** ページで、[**Start build（ビルドの開始）**] を選択してビルドを実行します。 | アプリ開発者、AWS 管理者、AWS DevOps | ### ユニットテストの分析 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テスト結果を表示します。 | CodeBuild コンソールで、CodeBuild ジョブのユニットテスト結果を確認します。結果は[追加情報](#run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild-additional)セクションに表示されている結果と一致するはずです。これらの結果は、GitHub リポジトリと CodeBuild の統合を検証します。  | アプリ開発者、AWS 管理者、AWS DevOps | | Webbook を適用します。 | これで Webhook を適用できるようになったため、コードの変更をリポジトリのメインブランチにプッシュするたびに自動的にビルドを開始できます。手順については、[CodeBuild ドキュメント](https://docs.aws.amazon.com/codebuild/latest/userguide/github-webhook.html)を参照してください。 | アプリ開発者、AWS 管理者、AWS DevOps | ## 関連リソース + [サンプルゲームユニットテストアプリケーション](https://github.com/aws-samples/node-js-tests-sample)(サンプルコードを含む GitHub リポジトリ) + [AWS CodeBuild ドキュメント](https://docs.aws.amazon.com/codebuild/) + [GitHub Webbook イベント](https://docs.aws.amazon.com/codebuild/latest/userguide/github-webhook.html)(CodeBuild ドキュメント) + [新しいリポジトリの作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-new-repository)(GitHub ドキュメント) ## 追加情報 **ユニットテスト結果** プロジェクトが正常にビルドされると、CodeBuild コンソールに次のテスト結果が表示されるはずです。  ![\[ユニットテストから期待される結果\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e18428ce-9ecf-4204-9f1f-5a6683a720b2/images/db861831-cfed-4e87-a498-0216606941f8.png) **ユニットテストコンポーネントの例** このセクションでは、ユニットテストで使用される 4 種類のテストコンポーネント (アサーション、スパイ、スタブ、モック) について説明します。各コンポーネントの簡単な説明とコード例が含まれています。  **アサーション** アサーションは期待される結果の検証に使用されます。これは特定の関数からの期待される応答を検証するため、重要なテストコンポーネントです。次のサンプルアサーションは、新しいゲームを初期化するときに、返される ID が 0 から 1000 の間であることを検証します。 ``` const { expect } = require('chai'); const { Game } = require('../src/index'); describe('Game Function Group', () => { it('Check that the Game ID is between 0 and 1000', function() { const game = new Game(); expect(game.id).is.above(0).but.below(1000) }); }); ``` **スパイ** スパイは関数を実行中に何が起きているかの観察に使用されます。例えば、関数が正しく呼び出されたことを確認する必要があります。次の例は、**Game** クラスオブジェクトで開始メソッドと停止メソッドが呼び出されることを示しています。 ``` const { expect } = require('chai'); const { spy } = require('sinon'); const { Game } = require('../src/index'); describe('Game Function Group', () => { it('should verify that the correct function is called', () => { const spyStart = spy(Game.prototype, "start"); const spyStop = spy(Game.prototype, "stop"); const game = new Game(); game.start(); game.stop(); expect(spyStart.called).to.be.true expect(spyStop.called).to.be.true }); }); ``` **スタブ** スタブは関数のデフォルトレスポンスのオーバーライドに使用されます。これは関数が外部リクエストをする場合に特に便利です。ユニットテストから外部リクエストをしないようにするためです。(外部リクエストは、異なるコンポーネント間のリクエストを物理的にテストできる統合テストにより適しています)。次の例では、スタブが **getId** 関数からのリターン ID を強制します。 ``` const { expect } = require('chai'); const {.stub } = require('sinon'); const { Game } = require('../src/index'); describe('Game Function Group', () => { it('Check that the Game ID is between 0 and 1000', function() { let generateIdStub = stub(Game.prototype, 'getId').returns(999999); const game = new Game(); expect(game.getId).is.equal(999999); generateIdStub.restore(); }); }); ``` **モック** モックは、さまざまなシナリオをテストする動作があらかじめプログラムされたフェイクメソッドです。モックはスタブの拡張版と見なすことができ、複数のタスクを同時に実行できます。以下の例では、モックを使用して 3 つのシナリオを検証します。 + 関数の呼び出し  + 引数による関数の呼び出し + 関数は整数 9 を返す ``` const { expect } = require('chai'); const {.mock } = require('sinon'); const { Game } = require('../src/index'); describe('Game Function Group', () => { it('Check that the Game ID is between 0 and 1000', function() { let mock = mock(Game.prototype).expects('getId').withArgs().returns(9); const game = new Game(); const id = get.getId(); mock.verify(); expect(id).is.equal(9); }); }); ``` # AWS Lambda を使用して六角形アーキテクチャで Python プロジェクトを構築する *Amazon Web Services、Furkan Oruc、Dominik Goby、Darius Kunce、Michal Ploski* ## 概要 このパターンは、AWS Lambda を使用して Python プロジェクトを六角形アーキテクチャで構築する方法を示しています。このパターンでは、Infrastructure as Code (IaC) ツールとして AWS Cloud Development Kit (AWS CDK)、REST API として Amazon API Gateway、パーシスタンスレイヤーとして Amazon DynamoDB を使用しています。六角形アーキテクチャは、ドメイン主導型の設計原則に従っています。六角形アーキテクチャでは、ソフトウェアはドメイン、ポート、アダプターの 3 つのコンポーネントで構成されます。六角形アーキテクチャとその利点の詳細については、「[ で六角形アーキテクチャを構築する](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/)」ガイドを参照してください。** ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + Python の使用経験 + AWS Lambda、AWS CDK、Amazon API Gateway、DynamoDB に精通していること + GitHub アカウント (「[サインアップの手順](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account)」を参照) + Git (「[インストール手順](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」を参照) + 変更を加えたり、コードを GitHub にプッシュしたりするためのコードエディタ ([Visual Studio Code](https://code.visualstudio.com/)、[JetBrains PyCharm](https://www.jetbrains.com/pycharm/) など) + Docker がインストールされ、Docker デーモンが起動して実行されていること **製品バージョン** + Git バージョン 2.24.3 以降 + Python バージョン 3.7 以降。 + AWS CDK v2 + Poetry バージョン 1.1.13 以降 + Python バージョン 1.25.6 以降向け AWS Lambda Powertools + pytest バージョン 7.1.1 以降 + Moto バージョン 3.1.9 以降 + pPydantic バージョン 1.9.0 以降 + Boto3 バージョン 1.22.4 以降 + mypy-boto3-dynamodb バージョン 1.24.0 以降 ## アーキテクチャ **ターゲットテクノロジースタック** ターゲットテクノロジースタックは、API Gateway、Lambda、および DynamoDB を使用する Python サービスで構成されます。このサービスは DynamoDB アダプターを使用してデータを保持します。エントリポイントとして Lambda を使用する関数を提供します。このサービスは Amazon API Gateway を使用して REST API を公開します。API は AWS Identity and Access Management (IAM) を使用して[クライアントの認証を行います](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)。 **ターゲットアーキテクチャ** 実装を説明するために、このパターンではサーバーレスターゲットアーキテクチャをデプロイします。クライアントは API Gateway エンドポイントにリクエストを送信できます。API Gateway は、六角形アーキテクチャパターンを実装するターゲット Lambda 関数にリクエストを転送します。Lambda 関数は、DynamoDB テーブルで作成、読み取り、更新、および削除 (CRUD) 操作を実行します。 | | | このパターンは PoC 環境でテストされました。アーキテクチャを実稼働環境にデプロイする前に、セキュリティレビューを実施して脅威モデルを特定し、安全なコードベースを作成する必要があります。 | | --- | ![\[Python プロジェクトを六角形アーキテクチャで構築するためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/25bd7169-ea5e-4a21-a865-c91c30a3c0da/images/de0d4f0d-ad19-43ec-bd10-676b25477b64.png) API は、製品エンティティに対する 5 つの操作をサポートします。 + `GET /products` はすべての製品を返します。 + `POST /products` は新しい製品を作成します。 + `GET /products/{id}` は特定の商品を返します。 + `PUT /products/{id}` は特定の製品を更新します。 + `DELETE /products/{id}` は特定の製品を削除します。 以下のフォルダ構造を使用して、六角形アーキテクチャパターンに従ってプロジェクトを整理できます。   ``` app/ # application code |--- adapters/ # implementation of the ports defined in the domain |--- tests/ # adapter unit tests |--- entrypoints/ # primary adapters, entry points |--- api/ # api entry point |--- model/ # api model |--- tests/ # end to end api tests |--- domain/ # domain to implement business logic using hexagonal architecture |--- command_handlers/ # handlers used to execute commands on the domain |--- commands/ # commands on the domain |--- events/ # events triggered via the domain |--- exceptions/ # exceptions defined on the domain |--- model/ # domain model |--- ports/ # abstractions used for external communication |--- tests/ # domain tests |--- libraries/ # List of 3rd party libraries used by the Lambda function infra/ # infrastructure code simple-crud-app.py # AWS CDK v2 app ``` ## ツール ** サービス** + [Amazon API Gateway](https://aws.amazon.com/api-gateway/) は、デベロッパーがあらゆる規模で API の公開、保守、モニタリング、セキュリティ保護を簡単に行えるフルマネージドサービスです。 + [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) は、あらゆる規模で高性能アプリケーションを実行できるように設計された、完全マネージド型のサーバーレスのキーバリュー型 NoSQL データベースです。 + [AWS Lambda](https://aws.amazon.com/lambda/) は、サーバーレスのイベント駆動型のコンピューティングサービスで、サーバーのプロビジョニングや管理を行わなくても、実質あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。200 以上の Software as a Service (SaaS) アプリケーションから Lambda 関数を起動できます。お支払いいただくのは使用した分のみです。 **ツール** + このパターンでは、コード開発のバージョン管理システムとして [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) が使用されます。 + このパターンのプログラミング言語には [Python](https://www.python.org/) が使用されています。Python は、高レベルのデータ構造とオブジェクト指向プログラミングへのアプローチを提供します。AWS Lambda には Python サービスの操作を簡素化する組み込みの Python ランタイムが用意されています。 + このパターンの開発とテストには、[Visual Studio Code](https://code.visualstudio.com/) が IDE として使用されています。Python 開発のサポートには、任意の IDE ([PyCharm](https://www.jetbrains.com/pycharm/) など) を使用できます。 + [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義できるオープンソースのソフトウェア開発フレームワークです。このパターンでは、CDK を使用してクラウドインフラストラクチャをコードとして記述し、デプロイします。 + [Poetry](https://python-poetry.org/) はパターン内の依存関係を管理するために使用されます。 + [Docker](https://www.docker.com/) は AWS CDK が Lambda パッケージとレイヤーを構築するために使用します。 **コード** このパターンのコードは、GitHub 内の「[Lambda 六角形アーキテクチャのサンプル](https://github.com/aws-samples/lambda-hexagonal-architecture-sample)」リポジトリで利用できます。 ## ベストプラクティス 実稼働環境でこのパターンを使用するには、次のベストプラクティスに従ってください。 + AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用して [Amazon CloudWatch Logs グループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)と [Amazon DynamoDB テーブル](https://docs.aws.amazon.com/kms/latest/developerguide/services-dynamodb.html)を暗号化します。 + 組織のネットワークからのアクセスのみを許可するように [Amazon API Gateway 用 WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) を構成します。 + IAM がニーズを満たさない場合は、API Gateway 認可の他のオプションを検討してください。たとえば、[Amazon Cognito ユーザープール](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)や [API Gateway Lambda オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)を使用できます。 + [DynamoDB バックアップ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)の使用 + [仮想プライベートクラウド (VPC) のデプロイ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html)で Lambda 関数を構成し、ネットワークトラフィックをクラウド内に維持します。 + [クロスオリジンリソースシェアリング (CORS) プリフライト](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)の許可オリジン構成を更新して、リクエスト元のオリジンドメインのみにアクセス制限します。 + [cdk-nag](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/check-aws-cdk-applications-or-cloudformation-templates-for-best-practices-by-using-cdk-nag-rule-packs.html) を使用して、AWS CDK コードのセキュリティベストプラクティスを確認します。 + コードスキャンツールを使用して、コードの一般的なセキュリティ問題を見つけることを検討してください。たとえば、[Bandit](https://bandit.readthedocs.io/en/latest/) は Python コードの一般的なセキュリティ問題を検出するために設計されたツールです。[Pip-audit](https://pypi.org/project/pip-audit/) は Python 環境をスキャンして、既知の脆弱性があるパッケージを探します。 このパターンでは、[AWS X-Ray](https://aws.amazon.com/xray/?nc1=h_ls) を使用して、アプリケーションのエントリポイント、ドメイン、アダプタを通じてリクエストをトレースします。AWS X-Ray は、開発者がボトルネックを特定して高いレイテンシーを洗い出し、アプリケーションのパフォーマンスを向上させるのに役立ちます。 ## エピック ### プロジェクトを初期化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 独自のリポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | IDE を構成する。 | Visual Studio Code をお勧めしますが、Python をサポートする任意の IDE でもかまいません。次の手順は、Visual Studio Code 用です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | ユニットテストを実行する。オプション 1: Visual Studio コードを使用する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | ユニットテストを実行する。オプション 2: シェルコマンドを使用する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | ### アプリケーションをデプロイしてテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 一時的な認証情報をリクエストします。 | `cdk deploy` の実行時にシェルに AWS 認証情報を保存するには、AWS IAM アイデンティティセンター (AWS シングルサインオンの後継) を使用して一時的な認証情報の作成を行います。手順については、ブログ記事「[ IAM アイデンティティセンター で CLI を使用するための短期認証情報を取得する方法](https://aws.amazon.com/blogs/security/aws-single-sign-on-now-enables-command-line-interface-access-for-aws-accounts-using-corporate-credentials/)」を参照してください。 | アプリ開発者、AWS DevOps | | アプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者、AWS DevOps | | API をテストする。オプション 1: コンソールを使用する。 | [API Gateway コンソール](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-test-method.html)を使用して API メソッドをテストします。API の操作とリクエスト/レスポンスメッセージの詳細については、GitHub リポジトリの 「[readme ファイルの API 使用状況セクション](https://github.com/aws-samples/lambda-hexagonal-architecture-sample/blob/main/README.md#api-usage)」を参照してください。 | アプリ開発者、AWS DevOps | | API をテストする。オプション 2: Postman を使用する。 | [Postman](https://www.postman.com/) などのツールを使用する場合:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者、AWS DevOps | ### サービスの開発 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ビジネスドメインのユニットテストを書きます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | コマンドとコマンドハンドラーを実装します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | セカンダリアダプターの統合テストを書く。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | セカンダリアダプタを実装する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | エンドツーエンドテストを作成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | | プライマリアダプタを実装する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/structure-a-python-project-in-hexagonal-architecture-using-aws-lambda.html) | アプリ開発者 | ## 関連リソース **APG ガイド** + [ で六角形アーキテクチャを構築する](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/) **AWS リファレンス** + [AWS Lambda ドキュメント](https://docs.aws.amazon.com/lambda/) + [AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/) + [初めての CDK アプリケーション](https://docs.aws.amazon.com/cdk/v2/guide/hello_world.html) + [API Gateway ドキュメント](https://docs.aws.amazon.com/apigateway/) + [IAM アクセス許可により API へのアクセスを制御する](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) + [API Gateway コンソールを使用して REST API メソッドをテストする](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-test-method.html) + [Amazon DynamoDB ドキュメント](https://docs.aws.amazon.com/dynamodb/) **ツール** + [git-scm.com ウェブサイト](https://git-scm.com/) + [Git のインストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + [新しい GitHub リポジトリの作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-new-repository) + [Python ウェブサイト](https://www.python.org/) + 「[AWS Lambda Powertools for Python](https://docs.powertools.aws.dev/lambda/python/latest/)」 + [Postman ウェブサイト](https://www.postman.com/) + [Python モックオブジェクトライブラリ](https://docs.python.org/3/library/unittest.mock.html) + [Poetry ウェブサイト](https://python-poetry.org/) **IDE** + [Visual Studio Code ウェブサイト](https://code.visualstudio.com/) + [PyCharm ウェブサイト](https://www.jetbrains.com/pycharm/) # その他のパターン **Topics** + [AWS Fargate、AWS PrivateLink、Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします。](access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.md) + [AWS PrivateLink と Network Load Balancer を使用して、Amazon ECS 上のコンテナ アプリケーションにプライベートにアクセスします](access-container-applications-privately-on-amazon-ecs-by-using-aws-privatelink-and-a-network-load-balancer.md) + [ある の AWS CodeCommit リポジトリ AWS アカウント を別のアカウントの Amazon SageMaker AI Studio Classic に関連付ける](associate-an-aws-codecommit-repository-in-one-aws-account-with-sagemaker-studio-in-another-account.md) + [AWS CloudFormation スタックと関連リソースの削除を自動化する](automate-deletion-cloudformation-stacks-associated-resources.md) + [を使用して IP アドレスまたは位置情報に基づいてアクセスを制限する AWS WAF](aws-waf-restrict-access-geolocation.md) + [AWS Amplify を使用してサーバーレスの React Native モバイルアプリを構築する](build-a-serverless-react-native-mobile-app-by-using-aws-amplify.md) + [AWS CodeCommit、AWS CodePipeline、AWS Device Farm を使用して iOS アプリを構築してテストする](build-and-test-ios-apps-with-aws-codecommit-aws-codepipeline-and-aws-device-farm.md) + [NLog を使用して Amazon CloudWatch Logs 内の.NET アプリケーションのロギングを設定します](configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.md) + [静的 IP アドレスに関連付けられたエンドポイントを使用して、Amazon S3 の署名付き URL の生成とオブジェクトのダウンロードを統合する](consolidate-amazon-s3-presigned-url-generation-and-object-downloads-by-using-an-endpoint-associated-with-static-ip-addresses.md) + [Amazon ECS タスク定義を作成し、Amazon EFS を使用して EC2 インスタンスにファイルシステムをマウントする](create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.md) + [gRPC ベースのアプリケーションを Amazon EKS クラスターにデプロイし、Application Load Balancer でアクセスする](deploy-a-grpc-based-application-on-an-amazon-eks-cluster-and-access-it-with-an-application-load-balancer.md) + [ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation](deploy-chatops-solution-to-manage-sast-scan-results.md) + [Terraform を使用して CloudWatch Synthetics Canary をデプロイする](deploy-cloudwatch-synthetics-canaries-by-using-terraform.md) + [AWS Fargate を使用して Amazon ECS に Java マイクロサービスをデプロイする](deploy-java-microservices-on-amazon-ecs-using-aws-fargate.md) + [Terraform と Amazon Bedrock を使用して AWS に RAG ユースケースをデプロイする](deploy-rag-use-case-on-aws.md) + [Terraform を使用して リソースを AWS Wavelength ゾーンにデプロイする](deploy-resources-wavelength-zone-using-terraform.md) + [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md) + [メッセージキューを Microsoft Azure Service Bus から Amazon SQS に移行](migrate-a-messaging-queue-from-microsoft-azure-service-bus-to-amazon-sqs.md) + [.NET アプリケーションを Microsoft Azure App Serviceから AWS Elastic Beanstalk に移行](migrate-a-net-application-from-microsoft-azure-app-service-to-aws-elastic-beanstalk.md) + [バイナリメソッドを使用してオンプレミスの Go ウェブアプリケーションを AWS Elastic Beanstalk に移行します](migrate-an-on-premises-go-web-application-to-aws-elastic-beanstalk-by-using-the-binary-method.md) + [AWS を使用してオンプレミス SFTP サーバーを に移行する AWS Transfer for SFTP](migrate-an-on-premises-sftp-server-to-aws-using-aws-transfer-for-sftp.md) + [IBM WebSphere アプリケーションサーバーから Amazon EC2 の Apache Tomcat に移行](migrate-from-ibm-websphere-application-server-to-apache-tomcat-on-amazon-ec2.md) + [IBM WebSphere アプリケーションサーバーから Amazon EC2 上の Apache Tomcat への自動スケーリングによる移行](migrate-from-ibm-websphere-application-server-to-apache-tomcat-on-amazon-ec2-with-auto-scaling.md) + [AWS App2Container を使用したオンプレミスの Java プリケーションの AWS への移行](migrate-on-premises-java-applications-to-aws-using-aws-app2container.md) + [ACM を使用して Windows SSL 証明書をApplication Load Balancer に移行](migrate-windows-ssl-certificates-to-an-application-load-balancer-using-acm.md) + [ASP.NET ウェブフォームアプリケーションを AWS で最新化](modernize-asp-net-web-forms-applications-on-aws.md) + [CloudWatch Logs Insights を使用してアプリケーションアクティビティをモニタリングする](monitor-application-activity-by-using-cloudwatch-logs-insights.md) + [Amazon EC2 Linux インスタンスで ASP.NET Core ウェブ API Docker コンテナを実行する](run-an-asp-net-core-web-api-docker-container-on-an-amazon-ec2-linux-instance.md) + [Amazon Cognito にカスタム属性を送信し、トークンに挿入する](send-custom-attributes-cognito.md) + [Amazon CloudFront を使用して Amazon S3 バケットの静的なコンテンツを VPC 経由で配信する](serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.md) + [AWS で可用性の高い PeopleSoft アーキテクチャを設定する](set-up-a-highly-available-peoplesoft-architecture-on-aws.md) + [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md) + [Amazon Bedrock AWS Step Functions を使用して の状態をトラブルシューティングする](troubleshooting-states-in-aws-step-functions.md) + [Network Firewall を使用して、アウトバウンドトラフィックのサーバー名表示から DNS ドメイン名をキャプチャする](use-network-firewall-to-capture-the-dns-domain-names-from-the-server-name-indication-sni-for-outbound-traffic.md) + [フラスコと AWS Elastic Beanstalk を使用して AI/ML モデルの結果を視覚化](visualize-ai-ml-model-results-using-flask-and-aws-elastic-beanstalk.md)