

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

# 管理
<a name="management-pattern-list"></a>

**Topics**
+ [コスト管理](costmanagement-pattern-list.md)
+ [エンドユーザーコンピューティング](endusercomputing-pattern-list.md)
+ [ハイパフォーマンスコンピューティング](highperformancecomputing-pattern-list.md)
+ [ハイブリッドクラウド](hybrid-pattern-list.md)
+ [管理とガバナンス](governance-pattern-list.md)
+ [メッセージとコミュニケーション](messagingandcommunications-pattern-list.md)
+ [マルチアカウント戦略](multiaccountstrategy-pattern-list.md)

# コスト管理
<a name="costmanagement-pattern-list"></a>

**Topics**
+ [AWS Cost Explorer を使用して、AWS Glue ジョブの詳細なコストと使用状況レポートを作成します。](create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer.md)
+ [AWS Cost Explorer を使用して Amazon EMR クラスターの詳細なコストと使用状況レポートを作成する](create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer.md)
+ [その他のパターン](costmanagement-more-patterns-pattern-list.md)

# AWS Cost Explorer を使用して、AWS Glue ジョブの詳細なコストと使用状況レポートを作成します。
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer"></a>

*Amazon Web Services、Parijat Bhide、Aromal Raj Jayarajan*

## 概要
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer-summary"></a>

このパターンは、「[ユーザー定義のコスト配分タグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」を設定して、AWS Glue データ統合ジョブの使用コストを追跡する方法を示しています。これらのタグを使用して、複数のディメンションにわたるジョブの詳細なコストと使用状況レポートを AWS Cost Explorer で作成できます。たとえば、チーム、プロジェクト、またはコストセンターレベルで使用コストを追跡できます。

## 前提条件と制限
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ ユーザー定義タグが有効になっている 1 つ以上の[ AWS Glue ジョブ](https://docs.aws.amazon.com/glue/latest/dg/how-it-works.html)

## アーキテクチャ
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer-architecture"></a>

**ターゲットテクノロジースタック**
+ AWS Glue
+ AWS Cost Explorer

次の図は、タグを適用して AWS Glue ジョブの使用コストを追跡する方法を示しています。

![\[AWS Glue ジョブでタグを作成および適用し、AWS Cost Explorer で使用コストを追跡します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e0ae6643-713d-423a-9013-b41b30638053/images/f2b74ef1-494d-439b-9aec-5a9d601126a6.png)


この図表は、次のワークフローを示しています:

1. データエンジニアまたは AWS 管理者が AWS Glue ジョブ用のユーザー定義のコスト配分タグを作成します。

1. AWS 管理者がタグを有効化します。

1. タグはメタデータを AWS Cost Explorer に報告します。

## ツール
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer-tools"></a>
+ [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) は、フルマネージド型の抽出、変換、ロード (ETL) サービスです。これにより、データストアとデータストリーム間でデータを確実に分類、整理、強化、移動できます。
+ [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html) を使用すると、コストと使用状況を表示および分析できます。

## エピック
<a name="create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer-epics"></a>

### AWS Glue ジョブのタグの作成と有効化
<a name="create-and-activate-tags-for-your-aws-glue-jobs"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS Glue ジョブ用のユーザー定義のコスト配分タグを作成します。 | **既存の AWS Glue ジョブにタグを追加するには**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer.html)**新しい AWS Glue ジョブにタグを追加するには**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer.html)詳細については、「*AWS Glue 開発者ガイド*」の「[AWS Glue の AWS タグ](https://docs.aws.amazon.com/glue/latest/dg/monitor-tags.html)」を参照してください。 | データエンジニア | 
| ステップ 1： ユーザー定義のコスト配分タグを有効にする | 「*AWS 請求ユーザーガイド*」の「[ユーザー定義のコスト配分タグの有効化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」の手順に従ってください。 | AWS 管理者 | 

### AWS Glue ジョブのコストと使用状況のレポートを作成する
<a name="create-cost-and-usage-reports-for-your-aws-glue-jobs"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS Cost Explorer のタグフィルタを使用して、AWS Glue ジョブのコストと使用状況のレポートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-aws-glue-jobs-by-using-aws-cost-explorer.html)詳細については、「*AWS コスト管理ユーザーガイド*」の「[Cost Explorer を使用してデータを探索する](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-exploring-data.html)」を参照してください。 | 一般的な AWS、AWS 管理者 | 

# AWS Cost Explorer を使用して Amazon EMR クラスターの詳細なコストと使用状況レポートを作成する
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer"></a>

*Amazon Web Services、Parijat Bhide、Aromal Raj Jayarajan*

## 概要
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer-summary"></a>

このパターンは、「[ユーザー定義のコスト配分タグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」を設定して Amazon EMR クラスターの使用コストを追跡する方法を示しています。これらのタグを使用して、複数のディメンションにわたるクラスターの詳細なコストと使用状況レポートを AWS Cost Explorer で作成できます。たとえば、チーム、プロジェクト、またはコストセンターレベルで使用コストを追跡できます。

## 前提条件と制限
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ ユーザー定義タグが有効になっている 1 つ以上の「[EMR クラスター](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-gs.html)」

## アーキテクチャ
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer-architecture"></a>

**ターゲットテクノロジースタック**
+ Amazon EMR
+ AWS Cost Explorer

**ターゲットアーキテクチャ**

次の図は、タグを適用して特定の Amazon EMR クラスターの使用コストを追跡する方法を示しています。

![\[Amazon EMR クラスターのコスト配分タグの使用。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3e470077-e3b1-43cf-8cb9-0895fe39e664/images/fb6b78cb-47bb-4ba1-848a-98dba02bdbb2.png)


この図表は、次のワークフローを示しています:

1. データエンジニアまたは AWS 管理者が Amazon EMR クラスター用のユーザー定義のコスト配分タグを作成します。

1. AWS 管理者がタグを有効化します。

1. タグはメタデータを AWS Cost Explorer に報告します。

## ツール
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer-tools"></a>

**ツール**
+ 「[Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html)」は、AWS でビッグデータフレームワークの実行を簡素化して、ビッグデータを処理および分析するマネージドクラスタープラットフォームです。
+ 「[AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)」を使用すると、AWS コストと使用状況を表示および分析できます。

## エピック
<a name="create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer-epics"></a>

### Amazon EMR クラスターのタグの作成と有効化
<a name="create-and-activate-tags-for-your-amazon-emr-clusters"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Amazon EMR クラスター用のユーザー定義のコスト配分タグを作成します。 | 既存の Amazon EMR クラスターにタグを追加するには「*Amazon EMR 管理ガイド*」の「[既存のクラスターへのタグの追加](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags-add.html)」の指示に従います。新しい Amazon EMR クラスターにタグを追加するには「*Amazon EMR 管理ガイド*」の「[新しいクラスターへのタグの追加](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags-add-new.html)」の指示に従います。Amazon EMR クラスターの設定方法の詳細については、「*Amazon EMR 管理ガイド*」の「[クラスターの計画と設定](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html)」を参照してください。 | データエンジニア | 
| ステップ 1： ユーザー定義のコスト配分タグを有効にする | 「*AWS 請求ユーザーガイド*」の「[ユーザー定義のコスト配分タグの有効化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」の手順に従ってください。 | AWS 管理者 | 

### Amazon EMR クラスターのコストと使用状況レポートの作成
<a name="create-cost-and-usage-reports-for-your-amazon-emr-clusters"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS Cost Explorer のタグフィルタを使用して、Amazon EMR クラスターのコストと使用状況のレポートを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-amazon-emr-clusters-by-using-aws-cost-explorer.html)詳細については、「*AWS コスト管理ユーザーガイド*」の「[Cost Explorer を使用してデータを探索する](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-exploring-data.html)」を参照してください。 | 一般的な AWS、AWS 管理者 | 

# その他のパターン
<a name="costmanagement-more-patterns-pattern-list"></a>

**Topics**
+ [Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する](automate-aws-infrastructure-operations-by-using-amazon-bedrock.md)
+ [複数のアカウントとリージョンの AWS リソースを自動的にインベントリする](automate-aws-resource-inventory.md)
+ [を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation](automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.md)
+ [DynamoDB TTL を使用して項目を Amazon S3 に自動的にアーカイブする](automatically-archive-items-to-amazon-s3-using-dynamodb-ttl.md)
+ [AWS Systems Manager メンテナンスウィンドウを使用して Amazon RDS DB インスタンスを自動的に停止および起動する](automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.md)
+ [Amazon RDS と Amazon Aurora の詳細なコストと使用状況レポートを作成する](create-detailed-cost-and-usage-reports-for-amazon-rds-and-amazon-aurora.md)
+ [Amazon DynamoDB テーブルのストレージコストを推定](estimate-storage-costs-for-an-amazon-dynamodb-table.md)
+ [DynamoDB テーブルのコストをオンデマンドで見積る](estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.md)
+ [Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする](event-driven-auto-scaling-with-eks-pod-identity-and-keda.md)
+ [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md)

# エンドユーザーコンピューティング
<a name="endusercomputing-pattern-list"></a>

**Topics**
+ [Auth0 と を使用して Amazon WorkSpaces の SAML 2.0 認証を実装する Auth0 AWS Managed Microsoft AD](implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.md)
+ [その他のパターン](endusercomputing-more-patterns-pattern-list.md)

# Auth0 と を使用して Amazon WorkSpaces の SAML 2.0 認証を実装する Auth0 AWS Managed Microsoft AD
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad"></a>

*Amazon Web Services、Siva Vinnakota および Shantanu Padhye*

## 概要
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-summary"></a>

このパターンでは、Auth0 を と統合 AWS Directory Service for Microsoft Active Directory して、Amazon WorkSpaces 環境用の堅牢な SAML 2.0 認証ソリューションを作成する方法について説明します。ここでは、これら間のフェデレーションを確立 AWS のサービス して、シームレスなデスクトップアクセスを維持しながら、多要素認証 (MFA) やカスタムログインフローなどの高度な機能を有効にする方法について説明します AWS Managed Microsoft AD。少数のユーザーのみを管理する場合でも数千のユーザーを管理する場合でも、この統合により組織は柔軟性とセキュリティを得ることができます。このパターンでは、独自の環境にこのソリューションを実装できるように、セットアッププロセスの手順を説明します。

## 前提条件と制限事項
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ AWS Managed Microsoft AD
+ に関連付けられている Amazon WorkSpaces Personal のプロビジョニングされたデスクトップ AWS Managed Microsoft AD
+ Amazon Elastic Compute Cloud (Amazon EC2) インスタンス
+ Auth0 アカウント

**制限事項**

一部の 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)」ページを参照して、サービスのリンクを選択します。

## アーキテクチャ
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-architecture"></a>

WorkSpaces クライアントアプリケーションの SAML 2.0 認証プロセスは、次の図に示す 5 つのステップで構成されています。これらのステップは、ログインするための一般的なワークフローを表しています。このパターンの指示に従った後に、この分散型認証アプローチを使用することで、ユーザーアクセスのための構造化された安全な方法を提供できます。

![\[WorkSpaces クライアントアプリケーションの SAML 2.0 認証プロセスのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5a0f227c-c111-495b-9fde-98ae7832bb10/images/957b2a11-e898-4c4f-ae4e-c2e85bfa93a0.png)


 ワークフロー:

1. **登録**。ユーザーは WorkSpaces のクライアントアプリケーションを起動し、SAML 対応の WorkSpaces ディレクトリの WorkSpaces 登録コードを入力します。WorkSpaces は、Auth0 ID プロバイダー (IdP) の URL をクライアントアプリケーションに返します。

1. **ログイン**:WorkSpaces クライアントでは、Auth0 の URL を使用してユーザーのウェブブラウザにリダイレクトします。 ユーザーは、ユーザー名とパスワードを使用して認証します。Auth0 は、クライアントブラウザに SAML アサーションを返します。SAML アサーションとは、ユーザーの ID をアサートする暗号化されたトークンです。

1. **認証**: クライアントブラウザは SAML アサーションを AWS サインイン エンドポイントに投稿して検証します。 は発信者が AWS Identity and Access Management (IAM) ロールを引き受けること AWS サインイン を許可します。これにより、IAM ロールに関する一時的な認証情報を含むトークンが返されます。

1. **WorkSpaces ログイン**: WorkSpaces クライアントは、トークンを WorkSpaces サービスエンドポイントに提示します。WorkSpaces はトークンをセッショントークンと交換し、ログイン URL とともにセッショントークンを WorkSpaces クライアントに返します。WorkSpaces クライアントがログインページを読み込むと、ユーザー名の値が SAML レスポンスで渡された `NameId` 値によって入力されます。

1. **ストリーミング**。ユーザーは、パスワードを入力し、WorkSpaces ディレクトリに対して認証します。認証後、WorkSpaces はトークンをクライアントに返します。クライアントは WorkSpaces サービスにリダイレクトし、トークンを提示します。これは、WorkSpaces クライアントと WorkSpace の間のストリーミングセッションのブローカーとなります。

**注記**  
パスワードプロンプトを必要としないシームレスなシングルサインオンエクスペリエンスを設定するには、WorkSpaces ドキュメントの「[Certificate-based authentication and WorkSpaces Personal](https://docs.aws.amazon.com/workspaces/latest/adminguide/certificate-based-authentication.html)」を参照してください。

## ツール
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-tools"></a>

**AWS のサービス**
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) は、ハードウェアを調達してデプロイしたり、複雑なソフトウェアをインストールしたりすることなく、ユーザーにクラウドベースのデスクトップを提供する、フルマネージド型の仮想デスクトップインフラストラクチャ (VDI) サービスです。
+ [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 クラウド。

**その他のツール**
+ [Auth0](https://auth0.com/) は、アプリケーションへのアクセスの管理に役立つ認証および認可を行うプラットフォームです。

## エピック
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-epics"></a>

### Auth0 で Active Directory LDAP コネクタを構成する
<a name="configure-the-active-directory-ldap-connector-in-auth0"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Active Directory LDAP コネクタを Auth0 にインストールします AWS Managed Microsoft AD。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.html) | クラウド管理者、クラウドアーキテクト | 
| Auth0 でアプリケーションを作成し、SAML メタデータのマニフェストファイルを生成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.html) | クラウド管理者、クラウドアーキテクト | 

### IAM で SAML 2.0 の IdP、ロール、ポリシーを設定する
<a name="set-up-idp-role-and-policy-for-saml-2-0-in-iam"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM で SAML 2.0 IdP を作成します。 | SAML 2.0 を IdP として設定するには、IAM ドキュメントの「[IAM で SAML ID プロバイダーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html)」に記載されているステップに従います。 | クラウド管理者 | 
| SAML 2.0 フェデレーション用の IAM ロールとポリシーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.html) | クラウド管理者 | 

### Auth0 でアサーションを構成する
<a name="configure-assertions-in-auth0"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Auth0 および SAML アサーションを構成します。 | Auth0 アクションを使用して、SAML 2.0 レスポンス内のアサーションを構成できます。SAML アサーションは、ユーザーの ID をアサートする暗号化されたトークンです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.html)これで、WorkSpaces Personal デスクトップの SAML 2.0 認証の設定は完了です。「[アーキテクチャ](#implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-architecture)」セクションでは、セットアップ後の認証プロセスについて説明します。 | クラウド管理者 | 

## トラブルシューティング
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| WorkSpaces における SAML 2.0 認証の問題** ** | WorkSpaces Personal に SAML 2.0 認証を実装する際に問題が発生した場合は、SAML 2.0 認証のトラブルシューティングに関する [AWS re:Post の記事](https://repost.aws/knowledge-center/workspaces-saml-authentication-issues)に記載されているステップとリンクに従ってください。WorkSpaces へのアクセス中に発生する SAML 2.0 エラーの調査の追加情報については、以下を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad.html) | 

## 関連リソース
<a name="implement-saml-authentication-for-amazon-workspaces-by-using-auth0-and-aws-managed-microsoft-ad-resources"></a>
+ [Set up SAML 2.0 for WorkSpaces Personal](https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html) (WorkSpaces ドキュメント)
+ [Auth0 ドキュメント](https://auth0.com/docs)

# その他のパターン
<a name="endusercomputing-more-patterns-pattern-list"></a>

**Topics**
+ [を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation](automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.md)
+ [Amazon Connect コンタクトセンターのエージェントワークステーションの通話品質を向上](improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.md)
+ [AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.md)

# ハイパフォーマンスコンピューティング
<a name="highperformancecomputing-pattern-list"></a>

**Topics**
+ [Terraform と DRA を使用して、高性能のデータ処理用の Lustre ファイルシステムをデプロイする](deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra.md)
+ [AWS ParallelCluster 用の Grafana モニタリングダッシュボードを設定する](set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.md)
+ [その他のパターン](highperformancecomputing-more-patterns-pattern-list.md)

# Terraform と DRA を使用して、高性能のデータ処理用の Lustre ファイルシステムをデプロイする
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra"></a>

*Arun bagal と Ishwar Chauthaiwale、Amazon Web Services*

## 概要
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-summary"></a>

このパターンは、Lustre ファイルシステムを に自動的にデプロイ AWS し、Amazon Elastic Compute Cloud (Amazon EC2) および Amazon Simple Storage Service (Amazon S3) と統合します。

このソリューションは、統合されたストレージ、コンピューティングリソース、Amazon S3 データアクセスを備えたハイパフォーマンスコンピューティング (HPC) 環境を迅速にセットアップするのに役立ちます。Lustre のストレージ機能と、Amazon EC2 が提供する柔軟なコンピューティングオプション、Amazon S3 のスケーラブルなオブジェクトストレージの組み合わせにより、機械学習、HPC、ビッグデータ分析でデータ集約型のワークロードに取り組むことができます。

このパターンでは、HashiCorp Terraform モジュールと Amazon FSx for Lustre を使用して、次のプロセスを合理化します。
+ Lustre ファイルシステムのプロビジョニング
+ FSx for Lustre と S3 バケット間のデータリポジトリの関連付け (DRA) を確立して、Lustre ファイルシステムを Amazon S3 オブジェクトにリンクする
+ EC2 インスタンスの作成
+ Amazon S3 にリンクされた DRA を使用して Lustre ファイルシステムを EC2 インスタンスにマウントする

このソリューションには次のような利点があります。
+ モジュラー設計。このソリューションの個々のコンポーネントを簡単に維持および更新できます。
+ スケーラビリティ。整合性のある環境を AWS アカウント または リージョンにすばやくデプロイできます。
+ 柔軟性。特定のニーズに合わせてデプロイをカスタマイズできます。
+ ベストプラクティス。このパターンでは、 AWS ベストプラクティスに従う事前設定されたモジュールを使用します。

Lustre ファイルシステムの詳細については、[Lustre のウェブサイト](https://www.lustre.org/)を参照してください。

## 前提条件と制限事項
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ 最小特権 AWS Identity and Access Management (IAM) ポリシー ([手順](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)を参照)

**制限事項**

FSx for Lustre は、Lustre ファイルシステムを 1 つのアベイラビリティーゾーンに制限します。これは、高い可用性要件がある場合に懸念材料となる可能性があります。ファイルシステムを含むアベイラビリティーゾーンに障害が発生した場合、復旧するまでファイルシステムへのアクセスは中断されます。高可用性を実現するには、DRA を使用して Lustre ファイルシステムを Amazon S3 にリンクし、アベイラビリティーゾーン間でデータを転送します。

**製品バージョン**
+ [Terraform バージョン 1.9.3 以降](https://developer.hashicorp.com/terraform/install?product_intent=terraform)
+ [HashiCorp AWS Provider バージョン 4.0.0 以降](https://registry.terraform.io/providers/hashicorp/aws/latest)

## アーキテクチャ
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-architecture"></a>

次の図は、FSx for Lustre と補完的な AWS のサービス のアーキテクチャを示しています AWS クラウド。

![\[AWS KMS、Amazon EC2、Amazon CloudWatch Logs、Amazon S3 を使用した FSx for Lustre のデプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/51d38589-e752-42cd-9f46-59c3c8d0bfd3/images/c1c21952-fd6f-4b1d-9bf8-09b2f4f4459f.png)


このアーキテクチャには、以下の項目が含まれます。
+ S3 バケットは、耐久性、スケーラビリティ、コスト効率に優れたデータのストレージの場所として使用されます。FSx for Lustre と Amazon S3 の統合により、Amazon S3 とシームレスにリンクされた高性能ファイルシステムが実現されます。
+ FSx for Lustre は Lustre ファイルシステムを実行および管理します。
+ Amazon CloudWatch Logs は、ファイルシステムからログデータを収集してモニタリングします。これらのログから、Lustre ファイルシステムのパフォーマンス、状態、アクティビティに関する情報を取得できます。
+ Amazon EC2 は、オープンソースの Lustre クライアントを使用して Lustre ファイルシステムにアクセスするために使用されます。EC2 インスタンスでは、同じ仮想プライベートクラウド (VPC) 内の他のアベイラビリティーゾーンからファイルシステムにアクセスできます。ネットワーク設定により、VPC 内のサブネット間のアクセスが可能になります。Lustre ファイルシステムがインスタンスにマウントされたら、ローカルファイルシステムと同じように、ファイルやディレクトリを操作できるようになります。
+ AWS Key Management Service (AWS KMS) は、保管中のデータの暗号化を提供することで、ファイルシステムのセキュリティを強化します。

**自動化とスケール**

Terraform を使用すると、複数の環境にまたがる Lustre ファイルシステムのデプロイ、管理、スケーリングが容易になります。FSx for Lustre では、1 つのファイルシステムにサイズの制限があるため、複数のファイルシステムを作成して水平方向にスケールしなければならない場合があります。Terraform を使用して、ワークロードのニーズに基づいて複数の Lustre ファイルシステムをプロビジョニングできます。

## ツール
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-tools"></a>

**AWS のサービス**
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、 からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ [Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) を使用すると、高性能の Lustre ファイルシステムを簡単かつ費用効果の高い方法で起動し、実行し、スケールすることができます。
+ [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) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。

**コードリポジトリ**

このパターンのコードは、GitHub の「[Provision FSx for Lustre Filesystem using Terraform](https://github.com/aws-samples/provision-fsx-lustre-with-terraform)」リポジトリで入手できます。

## ベストプラクティス
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-best-practices"></a>
+ 次の変数は、Lustre ファイルシステムを定義します。[エピック](#deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-epics)セクションの指示に従い、お使いの環境に基づいてこれらを正しく設定してください。
  + `storage_capacity` – Lustre ファイルシステムのストレージ容量 (GiB 単位)。最小およびデフォルト設定は 1200 GiB です。
  + `deployment_type` – Lustre ファイルシステムのデプロイタイプ。2 つのオプションである `PERSISTENT_1` と `PERSISTENT_2` (デフォルト) の説明については、「[FSx for Lustre ドキュメント](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-fsx-lustre.html#persistent-file-system)」を参照してください。
  + `per_unit_storage_throughput` – 読み取りおよび書き込みスループット (1 TiB あたり MB/秒)。 
  + `subnet_id` – FSx for Lustre をデプロイするプライベートサブネットの ID。
  + `vpc_id` – FSx for Lustre をデプロイ AWS する仮想プライベートクラウドの ID。
  + `data_repository_path` – Lustre ファイルシステムにリンクされる S3 バケットへのパス。
  + `iam_instance_profile` – EC2 インスタンスの起動に使用する IAM インスタンスプロファイル。
  + `kms_key_id` – データ暗号化に使用される AWS KMS キーの Amazon リソースネーム (ARN)。
+ `security_group` 変数と `vpc_id` 変数を使用して、VPC 内の適切なネットワークアクセスと配置を確認します。
+ 「[エピック](#deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-epics)」セクションの説明に従って `terraform plan` コマンドを実行して、変更を適用する前にプレビューおよび検証します。これにより、潜在的な問題を検出し、デプロイされる内容を確実に把握することができます。
+ 「[エピック](#deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-epics)」セクションの説明に従って `terraform validate` コマンドを実行して、構文エラーをチェックし、設定が正しいことを確認します。

## エピック
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-epics"></a>

### 環境をセットアップします。
<a name="set-up-your-environment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Terraform をインストールします。 | ローカルマシンに Terraform をインストールするには、「[Terraform ドキュメント](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)」の指示に従ってください。 | AWS DevOps、DevOps エンジニア | 
|  AWS 認証情報を設定します。 | アカウントの AWS Command Line Interface (AWS CLI) プロファイルを設定するには、 [AWS ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)の指示に従います。 | AWS DevOps、DevOps エンジニア | 
| GitHub リポジトリのクローンを作成します。 | GitHub リポジトリを複製するには、コマンドを実行します。<pre>git clone https://github.com/aws-samples/provision-fsx-lustre-with-terraform.git</pre> | AWS DevOps、DevOps エンジニア | 

### FSx for Lustre の設定とデプロイ
<a name="configure-and-deploy-fsxlustre"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| デプロイ設定を更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra.html) | AWS DevOps、DevOps エンジニア | 
| Terraform 環境を初期化します。 | 環境を初期化して Terraform `fsx_deployment` モジュールを実行するには、以下を実行します。<pre>terraform init</pre> | AWS DevOps、DevOps エンジニア | 
| Terraform 構文を検証します。 | 構文エラーをチェックし、設定が正しいことを確認するには、以下を実行します。<pre>terraform validate </pre> | AWS DevOps、DevOps エンジニア | 
| Terraform 設定を検証します。 | Terraform 実行プランを作成し、デプロイをプレビューするには、以下を実行します。<pre>terraform plan -var-file terraform.tfvars</pre> | AWS DevOps、DevOps エンジニア | 
| Terraform モジュールをデプロイします。 | FSx for Lustre リソースをデプロイするには、以下を実行します。<pre>terraform apply -var-file terraform.tfvars</pre> | AWS DevOps、DevOps エンジニア | 

### AWS リソースをクリーンアップする
<a name="clean-up-aws-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  AWS リソースを削除します。 | FSx for Lustre 環境の使用が終了したら、Terraform によってデプロイされた AWS リソースを削除して、不要な料金が発生しないようにできます。コードリポジトリで提供される Terraform モジュールは、このクリーンアップを自動化します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra.html) | AWS DevOps、DevOps エンジニア | 

## トラブルシューティング
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| FSx for Lustre はエラーを返します。 | FSx for Lustre の問題に関するヘルプについては、FSx for Lustre ドキュメントの「[Amazon FSx for Lustre のトラブルシューティング](https://docs.aws.amazon.com/fsx/latest/LustreGuide/troubleshooting.html)」を参照してください。 | 

## 関連リソース
<a name="deploy-lustre-file-system-for-high-performance-data-processing-with-terraform-dra-resources"></a>
+ [Terraform を使用した Amazon FSx for Lustre の構築](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/fsx_lustre_file_system) (Terraform ドキュメントのAWS プロバイダーリファレンス)
+ [Amazon FSx for Lustre の使用開始](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started.html) (「FSx for Lustre ドキュメント」)
+ [AWS Amazon FSx for Lustre に関するブログ投稿](https://aws.amazon.com/blogs/storage/tag/amazon-fsx-for-lustre/)

# AWS ParallelCluster 用の Grafana モニタリングダッシュボードを設定する
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster"></a>

*Amazon Web Services、Dario La Porta、William Lu*

## 概要
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-summary"></a>

AWS ParallelCluster は、ハイパフォーマンスコンピューティング(HPC)クラスターのデプロイと管理をサポートします。AWS Batch と Slurm のオープンソースジョブスケジューラーをサポートしています。AWS ParallelCluster はログ記録とメトリクス用に Amazon CloudWatch と統合されていますが、ワークロードのモニタリングダッシュボードは提供されていません。

[AWS ParallelCluster (GitHub) の Grafana ダッシュボード](https://github.com/aws-samples/aws-parallelcluster-monitoring)は AWS ParallelCluster のモニタリングダッシュボードです。ジョブスケジューラーの分析情報とオペレーティングシステム (OS) レベルでの詳細なモニタリングメトリクスを提供します。このソリューションに含まれるダッシュボードの詳細については、GitHub リポジトリの「[ダッシュボードの例](https://github.com/aws-samples/aws-parallelcluster-monitoring#example-dashboards)」を参照してください。これらのメトリクスは、HPC ワークロードとそのパフォーマンスを詳しく理解するために役立ちます。ただし、ダッシュボードコードは最新バージョンの AWS ParallelCluster やソリューションで使用されているオープンソースパッケージに対しては更新されません。このパターンにより、ソリューションが強化され、以下の利点が得られます。
+ AWS ParallelCluster v3 をサポート
+ Prometheus、Grafana、Prometheus Slurm Exporter、NVIDIA DCGM-Exporter など、最新バージョンのオープンソースパッケージを使用しています。
+ Slurm ジョブが使用する CPU コアと GPU の数を増やします。
+ ジョブモニタリングダッシュボードを追加する
+ 4 つまたは 8 つのグラフィックプロセッシングユニット (GPU) を搭載したノードの GPU ノードモニタリングダッシュボードを強化します。

このバージョンの拡張ソリューションは、AWS のお客様の HPC 実稼働環境で実装および検証されています。

## 前提条件と制限
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-prereqs"></a>

**前提条件**
+ [AWS ParallelCluster CLI](https://docs.aws.amazon.com/parallelcluster/latest/ug/pcluster-v3.html) がインストールして設定済み。
+ AWS ParallelCluster でサポートされている[ネットワーク設定](https://docs.aws.amazon.com/parallelcluster/latest/ug/iam-roles-in-parallelcluster-v3.html)。このモードでは、[AWS ParallelCluster を使用した 2 つのサブネット](https://docs.aws.amazon.com/parallelcluster/latest/ug/network-configuration-v3.html#network-configuration-v3-two-subnets) 設定を使用します。これには、1 つのパブリック サブネット、プライベート サブネット、インターネットゲートウェイ、および NAT ゲートウェイが必要です。
+ すべての AWS ParallelCluster クラスターノードがインターネットにアクセスできる必要があります。これは、インストールスクリプトがオープンソースソフトウェアと Docker イメージをダウンロードできるようにするためです。
+ Amazon Elastic Compute Cloud (Amazon EC2) の[キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) このキーペアを持つリソースは、ヘッドノードへの Secure Shell (SSH) アクセス権があります。

**機能制限**
+ このパターンは Ubuntu 20.04 LTS をサポートするように設計されています。別のバージョンの Ubuntu を使用している場合、または Amazon Linux や CentOS を使用している場合は、このソリューションで提供されているスクリプトを変更する必要があります。　 これらの変更は、このパターンには含まれていません。

**製品バージョン**
+ Ubuntu 20.04 LTS
+ ParallelCluster 3.X

**請求とコストに関する考慮事項**
+ このパターンでデプロイされるソリューションは無料利用枠の対象外です。Amazon EC2、Amazon FSx for Lustre、Amazon VPC の NAT ゲートウェイ、Amazon Route 53 には料金がかかります。　

## アーキテクチャ
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-architecture"></a>

**ターゲット アーキテクチャ**

以下の図では、ユーザーがヘッドノードで AWS ParallelCluster のモニタリングダッシュボードにアクセスする方法を示しています。ヘッドノードは NICE DCV、Prometheus、Grafana、Prometheus Slurm Exporter、Prometheus Node Exporter、NGINX Open Source を実行します。　 コンピュートノードは Prometheus Node Exporter を実行します。ノードに GPU が含まれている場合は NVIDIA DCGM-Exporter も実行します。ヘッドノードはコンピュートノードから情報を取得し、そのデータを Grafana ダッシュボードに表示します。　

![\[ヘッドノードで AWS ParallelCluster のモニタリングダッシュボードにアクセスします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a2132c94-98e0-4b90-8be0-99ebfa546442/images/d2255792-f66a-4ef2-8f04-cc3d5482db5f.png)


ほとんどの場合、ジョブスケジューラは大量の CPU やメモリを必要としないので、ヘッドノードの負荷は大きくありません。ユーザーはポート 443 から SSL を使用してヘッドノードのダッシュボードにアクセスします。

権限のある閲覧者はすべて、モニタリングダッシュボードを匿名で閲覧できます。ダッシュボードを変更できるのは Grafana 管理者のみです。　 `aws-parallelcluster-monitoring/docker-compose/docker-compose.head.yml` ファイルで Grafana 管理者のパスワードを設定します。

## ツール
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-tools"></a>

**AWS サービス**
+ [NICE DCV](https://docs.aws.amazon.com/dcv/#nice-dcv) は、さまざまなネットワーク条件下で、任意のクラウドまたはデータセンターから任意のデバイスに、リモートデスクトップやアプリケーションストリーミングを配信するのに役立つ高性能リモート表示プロトコルです。
+ [AWS ParallelCluster](https://docs.aws.amazon.com/parallelcluster/latest/ug/what-is-aws-parallelcluster.html) は、ハイパフォーマンスコンピューティング(HPC)クラスターのデプロイと管理をサポートします。AWS Batch と Slurm のオープンソースジョブスケジューラーをサポートしています。
+ [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 リソースを起動できます。

**その他のツール**
+ [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。
+ [Grafana](https://grafana.com/docs/grafana/latest/introduction/) は、メトリクス、ログ、トレースのクエリ、可視化、アラート表示、探索に役立つオープンソースソフトウェアです。
+ [NGINX Open Source](https://nginx.org/en/docs/?_ga=2.187509224.1322712425.1699399865-405102969.1699399865) は、オープンソースのウェブサーバーで、リバースプロキシでもあります。
+ [NVIDIA データセンター GPU マネージャー (DCGM)](https://docs.nvidia.com/data-center-gpu-manager-dcgm/index.html) は、クラスター環境で NVIDIA データセンターのグラフィックプロセッシングユニット (GPU) を管理およびモニタリングするための一連のツールです。このパターンでは、Prometheus から GPU メトリクスをエクスポートするのに役立つ [DCGM-Exporter](https://github.com/NVIDIA/dcgm-exporter) を使用します。
+ [Prometheus](https://prometheus.io/docs/introduction/overview/) はオープンソースのシステム監視ツールキットで、*ラベル*と呼ばれる関連するキーと値のペアを含む、時系列データとしてメトリクスを収集して保存します。このパターンでは、[Prometheus Slurm Exporter](https://github.com/vpenso/prometheus-slurm-exporter) を使用してメトリクスを収集およびエクスポートし、[Prometheus Node Exporter](https://github.com/prometheus/node_exporter) を使用してコンピュートノードからメトリクスをエクスポートします。
+ [Ubuntu](https://help.ubuntu.com/) はオープンソースの Linux ベースのオペレーティングシステムで、エンタープライズサーバー、デスクトップ、クラウド環境、IoT 向けに設計されています。

**コードリポジトリ**

このパターンのコードは、GitHub 内の「[pcluster-monitoring-dashboard](https://github.com/aws-samples/parallelcluster-monitoring-dashboard)」リポジトリで利用できます。

## エピック
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-epics"></a>

### 必要なリソースを作成する
<a name="create-the-required-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| S3 バケットを作成する。 | Amazon S3 バケットを作成する。このバケットを使用して設定スクリプトを保存します。手順については、Amazon S3 ドキュメントの「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」を参照してください。 | AWS 全般 | 
| リポジトリのクローン作成 | 以下のコマンドを実行して GitHub [pcluster-monitoring-dashboard](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/tree/main/aws-parallelcluster-monitoring) リポジトリのクローンを作成します。<pre>git clone https://github.com/aws-samples/parallelcluster-monitoring-dashboard.git</pre> | DevOps エンジニア | 
| 管理者のパスワードを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.html) | Linux シェルスクリプト  | 
| 必要なファイルを S3 バケットにコピーします。 | [post\$1install.sh](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/blob/main/post_install.sh) スクリプトと [aws-parallelcluster-monitoring](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/tree/main/aws-parallelcluster-monitoring) フォルダーを、作成した S3 バケットにコピーします。手順については、Amazon S3 ドキュメントの「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。 | AWS 全般 | 
| ヘッドノードに追加のセキュリティグループを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.html) | AWS 管理者 | 
| ヘッドノードの IAM ポリシーを設定します。 | ヘッドノードの ID ベースのポリシーを作成します。このポリシーにより、ノードは Amazon CloudWatch からメトリクスデータを取得できます。　 GitHub リポジトリには、サンプル [ポリシー](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/blob/main/policies/head_node.json)が含まれています。手順については、AWS Identity and Access Management (IAM) ドキュメントの「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。 | AWS 管理者 | 
| コンピューティングノードの IAM ポリシーを設定します。 | コンピューティングノードの ID ベースのポリシーを作成します。このポリシーを使用すると、ノードはジョブ ID とジョブ所有者を含むタグを作成できます。GitHub リポジトリには、サンプル [ポリシー](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/blob/main/policies/compute_node.json)が含まれています。詳細については、IAM ドキュメントの「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。提供されているサンプルファイルを使用する場合は、次の値を置き換えます：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.html) | AWS 管理者 | 

### クラスターを作成する
<a name="create-the-cluster"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 提供されたクラスターテンプレートファイルを変更します。 | AWS ParallelCluster を作成します。提供されている [cluster.yaml](https://github.com/aws-samples/parallelcluster-monitoring-dashboard/blob/main/cluster.yaml) AWS CloudFormation テンプレートファイルを開始点として使用して、クラスターを作成します。提供されたテンプレートの次の値を置換します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.html) | AWS 管理者 | 
| クラスターを作成します。 | AWS ParallelCluster CLI で、以下のコマンドを入力します。これで、CloudFormation テンプレートがデプロイされ、クラスターが作成されます。このコマンドの詳細については、AWS ParallelCluster ドキュメントの [pcluster create-cluster](https://docs.aws.amazon.com/parallelcluster/latest/ug/pcluster.create-cluster-v3.html) を参照してください。<pre>pcluster create-cluster -n <cluster_name> -c cluster.yaml</pre> | AWS 管理者 | 
| クラスターの作成をモニタリングします。 | 以下のコマンドを入力して、クラスターの作成を監視します。このコマンドの詳細については、AWS ParallelCluster ドキュメントの [pcluster describe-cluster](https://docs.aws.amazon.com/parallelcluster/latest/ug/pcluster.describe-cluster-v3.html) を参照してください。<pre>pcluster describe-cluster -n <cluster_name></pre> | AWS 管理者 | 

### Grafana ダッシュボードを使用する
<a name="using-the-grafana-dashboards"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Grafana ポータルにアクセスします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.html) | AWS 管理者 | 

### ソリューションをクリーンアップして、関連コストの発生を防ぎましょう。
<a name="clean-up-the-solution-to-stop-incurring-associated-costs"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| クラスターを削除します。 | クラスターを削除するには、次のコマンドを入力します。このコマンドの詳細については、AWS ParallelCluster ドキュメントの [pcluster delete-cluster](https://docs.aws.amazon.com/parallelcluster/latest/ug/pcluster.delete-cluster-v3.html) を参照してください。<pre>pcluster delete-cluster -n <cluster_name></pre> | AWS 管理者 | 
| IAM ポリシーを削除します。 | ヘッドノードとコンピューティングノード用に作成したポリシーを削除します。ポリシーの削除の詳細については、IAM ドキュメントの「[IAM ポリシーの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-delete.html)」を参照してください。 | AWS 管理者 | 
| セキュリティグループとルールを削除するには | ヘッドノード用に作成したセキュリティグループを削除します。　 詳細については、Amazon VPC ドキュメントの「[セキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-groups.html#deleting-security-group-rules)」と「[セキュリティグループの削除](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-groups.html#deleting-security-groups)」を参照してください。 | AWS 管理者 | 
| S3 バケットを削除します。 | 設定スクリプトを保存するために作成した S3 バケットを削除します。　 詳細については、Amazon S3 ドキュメントの「[バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」を参照してください。 | AWS 全般 | 

## トラブルシューティング
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| ブラウザからヘッドノードにアクセスできません。 | セキュリティグループをチェックし、インバウンドポート 443 がオープンになっていることを確認します。 | 
| Grafana が開かない。 | ヘッドノードで、`docker logs Grafana` のコンテナログを確認してください。 | 
| 一部のメトリクスにデータがありません。 | ヘッドノードで、すべてのコンテナのコンテナログを確認します。 | 

## 関連リソース
<a name="set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster-resources"></a>

**AWS ドキュメント**
+ 「[Amazon EC2 の IAM ポリシー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html)」

**その他の AWS リソース**
+ [AWS ParallelCluster](https://aws.amazon.com/hpc/parallelcluster/)
+ 「[AWS ParallelCluster のモニタリングダッシュボード](https://aws.amazon.com/blogs/compute/monitoring-dashboard-for-aws-parallelcluster/)」 (AWS ブログ記事)

**その他のリソース**
+ [Prometheus 監視システム](https://prometheus.io/)
+ [Grafana](https://grafana.com/)

# その他のパターン
<a name="highperformancecomputing-more-patterns-pattern-list"></a>

**Topics**
+ [K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md)

# ハイブリッドクラウド
<a name="hybrid-pattern-list"></a>

**Topics**
+ [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)
+ [その他のパターン](hybrid-more-patterns-pattern-list.md)

# AWS CDK と GitLab を使用して、Amazon ECS Anywhere 上のハイブリッドワークロード用に CI/CD パイプラインを設定する
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab"></a>

*Rafael Ortiz、Amazon Web Services*

## 概要
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-summary"></a>

Amazon ECS Anywhere は、Amazon Elastic Container Service (Amazon ECS) の拡張機能です。オンプレミスサーバーや仮想マシン (VM) などの*外部インスタンス*を Amazon ECS クラスターに登録するためのサポートを提供します。この機能は、コストを削減し、ローカルコンテナの複雑なオーケストレーションやオペレーションを軽減します。ECS Anywhere を使用して、オンプレミス環境とクラウド環境の両方でコンテナアプリケーションをデプロイして実行できます。これにより、チームが複数のドメインやスキルセットを習得したり、複雑なソフトウェアを独自に管理したりする必要がなくなります。

このパターンは、Amazon Web Services (AWS) Cloud Development Kit (AWS CDK) スタックを使用して Amazon ECS Anywhere インスタンスで Amazon ECS クラスターをプロビジョニングする段階的なアプローチを説明しています。　 次に、AWS CodePipeline を使用して継続的な統合と継続的なデプロイ (CI/CD) パイプラインを設定します。次に、GitLab コードリポジトリを AWS CodeCommit に複製し、コンテナ化されたアプリケーションを Amazon ECS クラスターにデプロイします。

このパターンは、オンプレミスインフラストラクチャを使用してコンテナアプリケーションを実行したり、GitLab を使用してアプリケーションコードベースを管理するユーザーに役立つように設計されています。これらのワークロードは、既存のオンプレミスインフラストラクチャに影響を与えずに、AWS クラウドサービスで管理できます。

## 前提条件と制限
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ オンプレミスインフラストラクチャ上で実行されるコンテナアプリケーション。　
+ アプリケーションコードベースを管理する GitLab リポジトリ。　 詳細については、「[リポジトリ](https://docs.gitlab.com/ee/user/project/repository/)」 (GitLab) を参照してください。
+ AWS コマンドラインインターフェイス (AWS CLI) をインストールして設定済み。詳細については、「[AWS CLI の最新バージョンをインストールまたはアップデート](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」 (AWS CLIのドキュメント) を参照してください。
+ AWS CDK ツールキットがインストール済みおよびグローバルに設定済み 詳細については、「[AWS CDK をインストールする](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install)」 (AWS CDK ドキュメント) を参照してください。
+ npm、TypeScript で AWS CDK 用にインストールおよび設定されています。詳細については、「[Node.js と npm のダウンロードとインストール](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)」 (npm ドキュメント) を参照してください。

**機能制限**
+ 制限と考慮事項については、Amazon ECS ドキュメントの「[外部インスタンス (Amazon ECS Anywhere)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html#ecs-anywhere-considerations)」を参照してください。

**製品バージョン**
+ AWS CDK ツールキットバージョン 2.27.0 以降
+ npm バージョン 7.20.3 以降
+ Node.js バージョン 16.6.1 以降

## アーキテクチャ
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-architecture"></a>

**ターゲットテクノロジースタック**
+ AWS CDK
+ AWS CloudFormation
+ AWS CodeBuild
+ AWS CodeCommit
+ AWS CodePipeline
+ Amazon ECS Anywhere
+ Amazon Elastic Container Registry (Amazon ECR)
+ AWS Identity and Access Management (IAM)
+ AWS Systems Manager
+ GitHub リポジトリ

**ターゲット アーキテクチャ**

![\[Amazon ECS クラスターと CI/CD パイプラインをセットアップするためのアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b0f35986-a839-4b01-8eb0-4748182ddafc/images/85b8d4d9-3591-4d69-a54b-64aa543498f1.png)


この図は、このパターンで説明されている 2 つの主なワークフロー、つまり Amazon ECS クラスターのプロビジョニングと、CI/CD パイプラインをセットアップしてデプロイする CI/CD パイプラインの設定を以下のように表しています。

1. **Amazon ECS クラスターのプロビジョニング**

   1. AWS CDK スタックをデプロイする場合、AWS に CloudFormation スタックが作成されます。

   1. この CloudFormation スタックは Amazon ECS クラスターと関連する AWS リソースをプロビジョニングします。

   1. Amazon ECS クラスターに外部インスタンスを登録するには、仮想マシン (VM) に AWS Systems Manager Agent (SSM Agent) をインストールし、その VM を AWS Systems Manager 管理型のインスタンスとして登録する必要があります。 

   1. また、Amazon ECS コンテナエージェントと Docker を VM にインストールして、Amazon ECS クラスターの外部インスタンスとして登録する必要があります。

   1. 外部インスタンスを Amazon ECS クラスターに登録して設定すると、外部インスタンスとして登録された VM 上で複数のコンテナを実行できます。

   1. Amazon ECS クラスターはアクティブで、コンテナを介してアプリケーションワークロードを実行できます。　 Amazon ECS Anywhere コンテナインスタンスはオンプレミス環境で実行されますが、クラウドの Amazon ECS クラスターに関連付けられています。　

1. **CI/CD パイプラインのセットアップとデプロイ**

   1. 2 つ目の AWS CDK スタックをデプロイする場合、AWS に CloudFormation スタックが作成されます。

   1. この CloudFormation スタックは、CodePipeline および関連のある AWS リソースにパイプラインをプロビジョニングします。

   1. アプリケーションコードの変更をオンプレミスの GitLab リポジトリにプッシュしてマージします。 

   1. GitLab リポジトリは CodeCommit リポジトリに自動的に複製されます。　

   1. CodeCommit リポジトリを更新すると、CodePipeline が自動的に起動します。 

   1. CodePipeline は CodeCommit からコードをコピーし、CodeBuild にデプロイ可能なアプリケーションビルドを作成します。　

   1. CodePipeline は CodeBuild ビルド環境の Docker イメージを作成し、Amazon ECR リポジトリにプッシュします。

   1. CodePipeline は、Amazon ECR リポジトリからコンテナイメージをプルする CodeDeploy アクションを開始します。　

   1. CodePipeline は Amazon ECS クラスターにコンテナイメージをデプロイします。　

**自動化とスケール**

このパターンでは、AWS CDK をコードとしての Infrastructure as Code (IaC) ツールとして使用して、このアーキテクチャを設定してデプロイします。AWS CDK は、AWS リソースのオーケストレーションと Amazon ECS Anywhere と CI/CD パイプラインのセットアップに役立ちます。

## ツール
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-tools"></a>

**AWS サービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [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 サービスとやり取りすることができます。
+ [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) は、クラスターでコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。このパターンは、オンプレミスサーバーまたは VM を Amazon ECS クラスターに登録するためのサポートを提供する [Amazon ECS Anywhere](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html) も使用します。

**その他のツール**
+ [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。
+ [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。
+ [Vagrant](https://developer.hashicorp.com/vagrant/docs) は、ポータブルな仮想ソフトウェア開発環境を構築して保守するためのオープンソースユーティリティです。デモンストレーション用に、このパターンでは Vagrant を使用してオンプレミスの VM を作成します。

**コードリポジトリ**

このパターンのコードは、GitHub 内の「[AWS CDK を使用した Amazon ECS Anywhere の CI/CD パイプライン](https://github.com/aws-samples/amazon-ecs-anywhere-cicd-pipeline-cdk-sample)」リポジトリで利用できます。

## ベストプラクティス
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-best-practices"></a>

このパターンをデプロイする場合は、以下のベストプラクティスを考慮してください。
+ [「AWS CDK でクラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス」](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)
+ [「AWS CDK でクラウドアプリケーションを開発するためのベストプラクティス」](https://aws.amazon.com/blogs/devops/best-practices-for-developing-cloud-applications-with-aws-cdk/) (AWS ブログ記事)

## エピック
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-epics"></a>

### AWS CDK の設定を検証する
<a name="verify-the-aws-cdk-configuration"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS CDK のバージョンを検証します。 | 次のコマンドを実行して、AWS CDK Toolkit のバージョンを検証します。<pre>cdk --version</pre>このパターンには、バージョン 2.27.0 以降が必要です。以前のバージョンを使用している場合は、「[AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)」の指示に従って更新してください。 | DevOps エンジニア | 
| npm バージョンを検証します。 | 次のコマンドを実行して、npm のバージョンを検証します。<pre>npm --version</pre>このパターンには、バージョン 7.20.3 以降が必要です。以前のバージョンを使用している場合は、「[npm ドキュメント](https://docs.npmjs.com/try-the-latest-stable-version-of-npm)」の指示に従って更新してください。 | DevOps エンジニア | 
| AWS 認証情報を設定します。 | 認証情報を設定するには、`aws configure` のコマンドを実行し、プロンプトに従ってください。<pre>$aws configure<br />AWS Access Key ID [None]: <your-access-key-ID><br />AWS Secret Access Key [None]: <your-secret-access-key><br />Default region name [None]: <your-Region-name><br />Default output format [None]:</pre> | DevOps エンジニア | 

### AWS CDK 環境のブートストラップ
<a name="bootstrap-the-aws-cdk-environment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS SAM コードリポジトリを複製します。 | [\[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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.html) | DevOps エンジニア | 
| 環境を起動します。 | 次ののコマンドを実行して、使用したいアカウントと AWS リージョンに AWS CloudFormation テンプレートをデプロイします。<pre>cdk bootstrap <account-number>/<Region></pre>詳細については、AWS CDK ドキュメントの「[ブートストラップ](https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)」を参照してください。 | DevOps エンジニア | 

### Amazon ECS Anywhere 向けインフラストラクチャの構築とデプロイ
<a name="build-and-deploy-the-infrastructure-for-amazon-ecs-anywhere"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| パッケージの依存関係をインストールし、TypeScript ファイルをコンパイルします。 | パッケージの依存関係をインストールし、次のコマンドを実行して TypeScript ファイルをコンパイルします。<pre>$cd EcsAnywhereCdk<br />$npm install<br />$npm fund </pre>これらのコマンドは、すべてのパッケージをサンプルリポジトリからインストールします。詳細については、npm ドキュメントの「[npm ci](https://docs.npmjs.com/cli/v7/commands/npm-ci)」と「[npm install](https://docs.npmjs.com/cli/v7/commands/npm-install)」を参照してください。これらのコマンドを入力したときに、紛失したパッケージに関するエラーが表示された場合は、このパターンの[[トラブルシューティング](#set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-troubleshooting)]のセクションを参照してください。 | DevOps エンジニア | 
| プロジェクトをビルドします。 | プロジェクトコードをビルドするには、以下のコマンドを入力します。<pre>npm run build</pre>プロジェクトの構築とデプロイの詳細については、AWS CDK ドキュメントの「[初めての AWS CDK アプリケーション](https://docs.aws.amazon.com/cdk/latest/guide/hello_world.html#:~:text=the%20third%20parameter.-,Synthesize%20an%20AWS%20CloudFormation%20template,-Synthesize%20an%20AWS)」を参照してください。 | DevOps エンジニア | 
| Amazon ECS Anywhere 向けインフラストラクチャスタックをデプロイします | [\[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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.html) | DevOps エンジニア | 

### オンプレミス VM の設定
<a name="set-up-an-on-premises-vm"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| VM をセットアップします | Vagrantfile が配置されているルートディレクトリから `vagrant up` コマンドを実行して Vagrant VM を作成します。詳細については、「[Vagrant ドキュメント](https://developer.hashicorp.com/vagrant/docs/cli/up)」を参照してください。 | DevOps エンジニア | 
| VM を外部インスタンスとして登録します。 | [\[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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.html)[\[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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.html)これにより、VM が Amazon ECS Anywhere の外部インスタンスとして設定され、Amazon ECS クラスターに登録されます。詳細については、Amazon ECS のドキュメントの「[クラスターへの外部インスタンスの登録](https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/ecs-anywhere-registration.html)」を参照してください。問題が発生した場合は、「[トラブルシューティング](#set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-troubleshooting)」セクションを参照してください。 | DevOps エンジニア | 
| Amazon ECS Anywhere と外部 VM のステータスを検証してください。 | VM が Amazon ECS コントロールプレーンに接続され、稼働していることを検証するには、以下のコマンドを使用します。<pre>$aws ssm describe-instance-information<br />$aws ecs list-container-instances --cluster $CLUSTER_NAME</pre> | DevOps エンジニア | 

### CI/CD パイプラインをデプロイする
<a name="deploy-the-ci-cd-pipeline"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS CodeCommit リポジトリにブランチを作成します。 | 最初のリポジトリのコミットを作成して、CodeCommit リポジトリに `main` というブランチを作成します。AWS のドキュメントに従って、[CodeCommit にコミットを作成する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-commit.html#create-first-commit)ことができます。コマンドの例を次に示します。<pre>aws codecommit put-file \<br />  --repository-name EcsAnywhereRepo \<br />  --branch-name main \<br />  --file-path README.md \<br />  --file-content "Test" \<br />  --name "Dev Ops" \<br />  --email "devops@example.com" \<br />  --commit-message "Adding README."</pre> | DevOps エンジニア | 
| リポジトリのミラーリングを設定します。 | GitLab リポジトリを外部ソースとの間でミラーリングできます。　 ソースとして使用するリポジトリを選択できます。ブランチ、タグ、コミットは自動的に同期されます。アプリケーションをホストする GitLab リポジトリと CodeCommit リポジトリの間でプッシュミラーを設定します。手順については、「[GitLab から CodeCommit へのプッシュミラーの設定](https://docs.gitlab.com/ee/user/project/repository/mirror/push.html#set-up-a-push-mirror-from-gitlab-to-aws-codecommit)」（GitLab ドキュメント）を参照してください。デフォルトでは、ミラーリングによってリポジトリが自動的に同期されます。リポジトリを手動で更新する場合は、「[ミラーの更新](https://docs.gitlab.com/ee/user/project/repository/mirror/#update-a-mirror)」(GitLab ドキュメント) を参照してください。 | DevOps エンジニア | 
| CI/CD パイプラインスタックをデプロイする | 次のコマンドを実行して、`EcsAnywherePipelineStack` スタックをデプロイします。<pre>$cdk  deploy EcsAnywherePipelineStack</pre> | DevOps エンジニア | 
| CI/CD パイプラインをテストします。 | [\[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-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.html) | DevOps エンジニア | 

### クリーンアップ
<a name="clean-up"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リソースをクリーンアップして削除します。 | このパターンが完了したら、作成した概念実証リソースを削除する必要があります。クリーンアップするには、次のコマンドを実行します。<pre>$cdk destroy EcsAnywherePipelineStack<br />$cdk destroy EcsAnywhereInfraStack</pre> | DevOps エンジニア | 

## トラブルシューティング
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| パッケージ依存関係のインストール中にパッケージが見つからない場合のエラー。 | 次のコマンドのいずれかを実行して、見つからないパッケージを解析します。<pre>$npm ci</pre>または<pre>$npm install -g @aws-cdk/<package_name></pre> | 
| VM 上で `aws ssm create-activation` コマンドを実行すると、次のエラーが発生します。`An error occurred (ValidationException) when calling the CreateActivation operation: Nonexistent role or missing ssm service principal in trust policy: arn:aws:iam::000000000000:role/EcsAnywhereInstanceRole` | `EcsAnywhereInfraStack` スタックは完全にデプロイされておらず、このコマンドを実行するために必要な IAM ロールもまだ作成されていません。CloudFormation コンソールでスタックの状態を確認します。ステータスが `CREATE_COMPLETE` に変更したら、コマンドを再試行します。 | 
| Amazon ECS ヘルスチェックで `UNHEALTHY` が返され、Amazon ECS コンソール内でクラスターの [**サービス**] セクションに次のエラーが表示されます。`service EcsAnywhereService was unable to place a task because no container instance met all of its requirements. Reason: No Container Instances were found in your cluster.` | 次のコマンドを実行して、Vagrant VM の Amazon ECS エージェントを再起動します。<pre>$vagrant ssh<br />$sudo systemctl restart ecs<br />$sudo systemctl status ecs</pre> | 

## 関連リソース
<a name="set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab-resources"></a>
+ 「[Amazon ECS Anywhere マーケティングページ](https://aws.amazon.com/ecs/anywhere/)」
+ 「[Amazon ECS Anywhere のドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html#ecs-anywhere-considerations)」
+ 「[Amazon ECS Anywhere デモ](https://www.youtube.com/watch?v=-eud6yUXsJM)」(ビデオ)
+ 「[Amazon ECS Anywhere ワークショップサンプル](https://github.com/aws-samples/aws-ecs-anywhere-workshop-samples)」
+ [「リポジトリ ミラーリング」](https://docs.gitlab.com/ee/user/project/repository/mirror/) (GitLab ドキュメント)

# その他のパターン
<a name="hybrid-more-patterns-pattern-list"></a>

**Topics**
+ [Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md)
+ [AWS CDK で Amazon ECS Anywhere を設定して、オンプレミスコンテナアプリケーションを管理します。](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md)
+ [F5 から AWS のApplication Load Balancer に移行するときの HTTP ヘッダーを変更](modify-http-headers-when-you-migrate-from-f5-to-an-application-load-balancer-on-aws.md)
+ [AWS Cloud でオンプレミスワークロードをリホストする: 移行チェックリスト](rehost-on-premises-workloads-in-the-aws-cloud-migration-checklist.md)
+ [BMC ディスカバリークエリを使用して移行計画のために移行データを抽出](use-bmc-discovery-queries-to-extract-migration-data-for-migration-planning.md)

# 管理とガバナンス
<a name="governance-pattern-list"></a>

**Topics**
+ [Amazon Data Firehose リソースが AWS KMS キーで暗号化されていない場合の識別とアラート](identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key.md)
+ [AFT AWS アカウント を使用して新しい の Amazon VPC IPAM IPv4 CIDR 割り当てを自動化する](automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.md)
+ [AWS Systems Manager を使用して Windows レジストリエントリの追加または更新を自動化する](automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager.md)
+ [Python を使用して RFC を自動的に作成する](automatically-create-an-rfc-in-ams-using-python.md)
+ [AWS Systems Manager メンテナンスウィンドウを使用して Amazon RDS DB インスタンスを自動的に停止および起動する](automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.md)
+ [Terraform を使用して AWS Organizations でのソフトウェアパッケージの配布を一元化する](centralize-software-package-distribution-in-aws-organizations-by-using-terraform.md)
+ [NLog を使用して Amazon CloudWatch Logs 内の.NET アプリケーションのロギングを設定します](configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.md)
+ [AWS Service Catalog 製品を異なる AWS アカウントと AWS リージョンにコピー](copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.md)
+ [クラウド運用モデルの RACI または RASCI マトリックスを作成](create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.md)
+ [Amazon CloudWatch 異常検知により、カスタムメトリクスのアラームを作成](create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.md)
+ [デフォルトの暗号化で Amazon EBS ボリュームを使用する AWS Cloud9 IDE を作成](create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption.md)
+ [タグベースの Amazon CloudWatch ダッシュボードを自動的に作成する](create-tag-based-amazon-cloudwatch-dashboards-automatically.md)
+ [AWS のランディングゾーンの設計を文書化する](document-your-aws-landing-zone-design.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)
+ [Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する](govern-permission-sets-aft.md)
+ [ブートストラップパイプラインを使用して Account Factory for Terraform (AFT) を実装する](implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.md)
+ [複数の AWS アカウントと AWS リージョンで AWS Service Catalog 製品を管理](manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions.md)
+ [AWS のサービスを使用して SAP RHEL Pacemaker クラスターをモニタリングする](monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.md)
+ [CloudWatch Logs Insights を使用してアプリケーションアクティビティをモニタリングする](monitor-application-activity-by-using-cloudwatch-logs-insights.md)
+ [複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md)
+ [AWS アカウントまたは組織の EBS スナップショットの詳細を表示](view-ebs-snapshot-details-for-your-aws-account-or-organization.md)
+ [その他のパターン](governance-more-patterns-pattern-list.md)

# Amazon Data Firehose リソースが AWS KMS キーで暗号化されていない場合の識別とアラート
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key"></a>

*Amazon Web Services、Ram Kandaswamy*

## 概要
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-summary"></a>

コンプライアンスのために、一部の組織では Amazon Data Firehose などのデータ配信リソースの暗号化を有効にする必要があります。このパターンは、リソースがコンプライアンス違反になったときに監視、検出、通知する方法を示しています。

暗号化要件を維持するために、このパターンを で使用 AWS して、 AWS Key Management Service (AWS KMS) キーで暗号化されていない Amazon Data Firehose 配信リソースを自動的にモニタリングおよび検出できます。このソリューションはアラート通知を送信し、拡張して自動修復を実行することもできます。このソリューションは、ラン AWS ディングゾーンまたは を使用する環境など、個々のアカウントまたは複数アカウント環境に適用できます AWS Control Tower。

## 前提条件と制限事項
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-prereqs"></a>

**前提条件**
+ Amazon Data Firehose 配信ストリーム
+ このインフラストラクチャの自動化 CloudFormationで使用される十分なアクセス許可と に関する知識

**制限事項**
+ このソリューションは、検出に AWS CloudTrail イベントを使用するため、リアルタイムではありません。また、暗号化されていないリソースが作成されてから通知が送信されるまでに遅延が発生します。

## アーキテクチャ
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-architecture"></a>

**ターゲットテクノロジースタック**

このソリューションはサーバーレステクノロジーと以下のサービスを使用します。
+ AWS CloudTrail
+ Amazon CloudWatch
+ AWS Command Line Interface (AWS CLI)
+ AWS Identity and Access Management (IAM)
+ Amazon Data Firehose
+ AWS Lambda
+ Amazon Simple Notiﬁcation Service (Amazon SNS)

**ターゲットアーキテクチャ**

![\[Data Firehose リソースが暗号化されていない場合にアラートを生成するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/897ba8cf-d1c2-4149-98e7-09d3d90d13d6/images/d694f718-bd0c-4d14-a2e4-e0ea58dc048e.png)


この図は、以下のステップを示しています。

1. ユーザーが Amazon Data Firehose を作成または変更します。

1. CloudTrail イベントが検出され、照合されます。

1. Lambda が呼び出されます。

1. 非準拠のリソースが特定されます。

1. メールが送信されます。

**自動化とスケール**

 CloudFormation StackSets を使用して、1 つのコマンドで複数の AWS リージョン または アカウントにこのソリューションを適用できます。

## ツール
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-tools"></a>
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、 のガバナンス、コンプライアンス、運用およびリスク監査を有効にする AWS のサービス のに役立つ です AWS アカウント。ユーザー、ロール、または によって実行されたアクション AWS のサービス は、イベントとして CloudTrail に記録されます。イベントには AWS マネジメントコンソール、、 AWS CLI、 AWS SDKs、および API オペレーションで実行されたアクションが含まれます。
+ [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) は、 AWS リソースの変更を記述するシステムイベントのほぼリアルタイムのストリームを提供します。
+ [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 リソースへのアクセスを安全に制御するのに役立つウェブサービスです。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。 
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) は、リアルタイムのストリーミングデータを配信する、フルマネージド型サービスです。Firehose を使用すれば、アプリケーションを記述したり、リソースを管理したりする必要はありません。Firehose にデータを送信するデータプロデューサーを作成すると、それにより、指定した送信先にデータが自動配信されます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。使用したコンピューティング時間に対してのみお支払いいただきます。コードが実行中でなければ料金はかかりません。 
+ [Amazon Simple Notiﬁcation Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、パブリッシャーからサブスクライバー (またはプロデューサーからコンシューマー) へのメッセージ配信を提供するマネージドサービスです。

## エピック
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-epics"></a>

### コンプライアンスのために暗号化を強制
<a name="enforce-encryption-for-compliance"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  CloudFormation StackSets をデプロイします。 | で AWS CLI、`firehose-encryption-checker.yaml`テンプレート (添付) を使用して、次のコマンドを実行してスタックセットを作成します。 パラメータには有効な Amazon SNS トピック Amazon リソースネーム (ARN) を指定します。デプロイにより、テンプレートで説明されているように、CloudWatch イベントルール、Lambda 関数、および必要な権限を持つ IAM ロールが正常に作成されるはずです。<pre>aws cloudformation create-stack-set    --stack-set-name my-stack-set   --template-body file://firehose-encryption-checker.yaml </pre> | クラウドアーキテクト、システム管理者 | 
| がスタックインスタンスを作成する。 | スタックは、 AWS リージョン 選択した および 1 つ以上のアカウントで作成できます。 スタックインスタンスを作成するには、次のコマンドを実行します。スタック名、アカウント番号、リージョンは、実際に使用するものと置き換えてください。<pre>aws cloudformation create-stack-instances     --stack-set-name my-stack-set    --accounts 123456789012 223456789012   --regions us-east-1 us-east-2 us-west-1 us-west-2     --operation-preferences FailureToleranceCount=1 </pre> | クラウドアーキテクト、システム管理者 | 

## 関連リソース
<a name="identify-and-alert-when-amazon-data-firehose-resources-are-not-encrypted-with-an-aws-kms-key-resources"></a>
+ [Stack CloudFormation StackSets の使用](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)

## アタッチメント
<a name="attachments-897ba8cf-d1c2-4149-98e7-09d3d90d13d6"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/897ba8cf-d1c2-4149-98e7-09d3d90d13d6/attachments/attachment.zip)」

# AFT AWS アカウント を使用して新しい の Amazon VPC IPAM IPv4 CIDR 割り当てを自動化する
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft"></a>

*Amazon Web Services、Kien Pham、Alex Pazik*

## 概要
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-summary"></a>

このパターンは、Account Factory for Terraform (AFT) AWS アカウント を使用して、新しい の Amazon VPC IP Address Manager (IPAM) IPv4 CIDR 割り当てを自動化する方法を示しています。 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)この作業は、`aft-account-customizations` モジュールを使用して IPAM から新しい仮想プライベートクラウド (VPC) に IPv4 CIDR ブロックを割り当てる、アカウントレベルのカスタマイズを使用して行われます。

IPAM を使用すると、IP アドレスを大規模に整理、割り当て、モニタリング、監査できるため、 AWS ワークロードの IP アドレスを簡単に計画、追跡、モニタリングできます。アカウントベンディングの処理中に IPv4 CIDR ブロックを新しい VPC に割り当てる際に使用する、[IPAM を作成](https://docs.aws.amazon.com/vpc/latest/ipam/create-ipam.html)し IPAM プールを作成することができます。

## 前提条件と制限
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-prereqs"></a>

**前提条件**
+ サポートされている で AWS Control Tower 有効 AWS アカウント になっているアクティブな [AWS リージョン](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html)と、デプロイされた AFT
+ サポートされている[バージョン管理システム (VCS) プロバイダー](https://github.com/aws-ia/terraform-aws-control_tower_account_factory?tab=readme-ov-file#input_vcs_provider) (BitBucket、GitHub、GitHub Enterprise など)。
+ Terraform コマンドラインインターフェイス (CLI) を[インストール済み](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)。
+ AFT をインストールする Terraform モジュールを実行できるランタイム環境。
+ 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/getting-started-quickstart.html)

**制限事項**
+ 一部の 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 Control Tower ディングゾーン](https://docs.aws.amazon.com/controltower/latest/userguide/2022-all.html#version-3.0)バージョン 3.0 以降、バージョン 4.0 より前
+ [AFT](https://github.com/aws-ia/terraform-aws-control_tower_account_factory) バージョン 1.13.0 以降、2.0.0 より前
+ Terraform OSS バージョン 1.2.0 以降、2.0.0 より前
+ [Terraform AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (`terraform-provider-aws`) バージョン 5.11.0 以降、バージョン 6.0.0 より前
+ [Terraform module for IPAM](https://github.com/aws-ia/terraform-aws-ipam) (`aws-ia/ipam/aws`) バージョン 2.1.0 以降

## アーキテクチャ
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-architecture"></a>

次の図は、このパターンのワークフローとコンポーネントを示しています。

![\[Amazon VPC IPAM IPv4 CIDR 割り当てを作成するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/986cfc7d-058b-4490-9029-6cd1eadd1dd2/images/f90b84dd-0420-460e-ac0f-9f22b4a9fdc4.png)


ワークフローは、主に次のタスクから構成されています。

1. **トリガーの変更** – Terraform と IPAM のカスタマイズへの変更は GitHub リポジトリにコミットされてプッシュされます。このタスクは AWS CodeBuild パイプラインを自動的にトリガーします。

1. **ビルドの自動化** – CodeBuild 内では、複数のビルドプロジェクトがトリガーされます AWS Step Functions。

1. **カスタマイズの適用** – Step Functions は CodeBuild と連携して、Terraform の変更を計画して適用します。このタスクでは、AFT Terraform モジュールを使用して、提供されたアカウントへの IPAM プールの IP AWS 割り当てを調整します。

## ツール
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-tools"></a>

**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) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、 AWS Organizations AWS Service Catalogや など[AWS のサービス](https://docs.aws.amazon.com/controltower/latest/userguide/integrated-services.html)、他のいくつかの の機能を調整します AWS IAM アイデンティティセンター。これは、規範的なベストプラクティスに従って、 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) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。
+ [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のスケーラブルなインフラストラクチャを使用できるという利点があります。Amazon VPC IP Address Manager (IPAM) は、 AWS ワークロードの IP アドレスの計画、追跡、モニタリングを容易にする VPC 機能です。

**その他のツール**
+ [GitHub](https://docs.github.com/) は、開発者がコードの作成、保存、管理、共有に使用できる開発者用プラットフォームです。
+ [HashiCorp Terraform](https://www.terraform.io/)は、Infrastructure as Code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。これには、コンピューティングインスタンス、ストレージ、ネットワークなどの低レベルコンポーネント、DNS エントリや Software a Service (SaaS) 機能などの高レベルコンポーネントが含まれます。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。こちらを使用すると、[AWS クラウド](https://aws.amazon.com/developer/language/python/) でのアプリケーションの構築、タスクの自動化、サービスの開発を行うことができます。

**コードリポジトリ**
+ このパターンのコードは、GitHub の [AWS Control Tower Account Factory for Terraform](https://github.com/aws-ia/terraform-aws-control_tower_account_factory) リポジトリから入手できます。

## ベストプラクティス
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-best-practices"></a>

AFT をデプロイするときは、安全かつ効率的に実装を完了するために、ベストプラクティスに従うことが推奨されます。AFT の実装と運用に関する主要なガイドラインおよび推奨事項は次のとおりです。
+ **入力の徹底した確認**– [入力](https://github.com/aws-ia/terraform-aws-control_tower_account_factory)を毎回注意深く確認し理解します。AFT を設定し正しく機能させるには正確な入力設定が不可欠です。
+ テンプレートの**定期的な更新 **— テンプレートを最新の AWS 機能と Terraform バージョンで更新します。定期的に更新することで新機能を活用しセキュリティを維持することができます。
+ **バージョニング** – AFT モジュールのバージョンを固定し、可能であれば別の AFT デプロイを使用してテストします。
+ **スコープ** – AFT は、インフラストラクチャのガードレールとカスタマイズをデプロイするためにのみ使用します。アプリケーションのデプロイには使用しないでください。
+ **リンティングと検証** – AFT パイプラインには、リンティングおよび検証済みの Terraform 設定が必要です。この設定を AFT リポジトリにプッシュする前に、リンティング、検証、テストを実行します。
+ **Terraform モジュール** – 再利用可能な Terraform コードをモジュールとして構築し、常に組織の要件に合わせて Terraform と AWS プロバイダーのバージョンを指定します。

## エピック
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-epics"></a>

### AWS 環境のセットアップと設定
<a name="set-up-and-configure-your-aws-environment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| デプロイします AWS Control Tower。 |  AWS 環境 AWS Control Tower 内で をセットアップして設定し、 の一元管理とガバナンスを確保します AWS アカウント。詳細については、 AWS Control Tower ドキュメント[の「 の開始方法 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)」を参照してください。 | クラウド管理者 | 
| Account AWS Control Tower Factory for Terraform (AFT) をデプロイします。 | 新しい、専用の AFT 管理アカウントで AFT をセットアップします。詳細については、 AWS Control Tower ドキュメントの「[Configure and launch your AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html#aft-configure-and-launch)」を参照してください。 | クラウド管理者 | 
| AFT のデプロイ後のステップを完了します。 | AFT インフラストラクチャのデプロイが完了したら、 AWS Control Tower ドキュメントの[デプロイ後のステップ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)を完了します。 | クラウド管理者 | 

### IPAM を作成する
<a name="create-ipam"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IPAM の管理者として委任する |  AWS 組織内の IPAM 管理者アカウントを委任するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html)または、 を使用して次のコマンド AWS CLI を実行できます。<pre>aws ec2 enable-ipam-organization-admin-account \<br />    --delegated-admin-account-id 012345678901</pre>詳細については、「Amazon VPC ドキュメント」の[「IPAM を AWS 組織内のアカウントと統合](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html)する」および AWS CLI 「 コマンドリファレンス」の[enable-ipam-organization-admin-account](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-ipam-organization-admin-account.html)」を参照してください。 引き続き IPAM を使用するには、委任管理者用アカウントにサインインする必要があります。次のステップで指定する SSO プロファイルまたは AWS 環境変数では、そのアカウントにサインインし、IPAM トップレベルおよびリージョンプールを作成するアクセス許可を付与する必要があります。 | AWS 管理者 | 
| IPAM の最上位プールとリージョンプールを作成します。 | 本パターンの GitHub リポジトリには、IPAM 最上位プールとリージョンプールの作成に使用できる Terraform テンプレートが含まれています。その後、 AWS Resource Access Manager () を使用して、プールを組織、組織単位 (OU) AWS アカウント、またはその他のリソースと共有できますAWS RAM。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html)作成後に出力されるリソースプール ID を書き留めます。アカウントリクエストを送信するときはこの ID が必要になります。リソースプール ID を忘れた場合は、後で AWS マネジメントコンソールから取得できます。 作成したプールの CIDR が、使用中のリージョンの他のプールと重複していないことを確認します。CIDR なしでプールを作成することもできますが、CIDR をプロビジョニングするまで、そのプールを割り当てに使用することはできません。プールを編集することで、いつでも CIDR をプールに追加できます。 | AWS 管理者 | 

### IPAM と AFT の統合
<a name="integrate-ipam-with-aft"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| アカウントのカスタマイズの作成を開始します。 | 新しいアカウントのカスタマイズを開始するには、ターミナルから次のコマンドを実行します。<pre># Default name for customization repo<br />cd aft-account-customizations # Replace with your actual repo name if different than the default<br />mkdir -p APG-AFT-IPAM/terraform # Replace APG-AFT-IPAM with your desired customization name<br />cd APG-AFT-IPAM/terraform</pre> | DevOps エンジニア | 
| `aft-providers.jinja` ファイルを作成します。 | 動的コードを、使用する Terraform バックエンドとプロバイダーを指定する `aft-providers.jinja` ファイルに追加します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| `backend.jinja` ファイルを作成します。 | 動的コードを、使用する Terraform バックエンドとプロバイダーを指定する `backend.jinja` ファイルに追加します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| `main.tf` ファイルを作成します。 | 新しい`main.tf`ファイルを作成し、 AWS Systems Manager (`aws_ssm`) から 2 つの値を取得して VPC を作成する 2 つのデータソースを定義するコードを追加します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| `variables.tf` ファイルを作成します。 | Terraform モジュールで使用される変数を宣言する `variables.tf` ファイルを作成します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| `terraform.tfvars` ファイルを作成します。 | `main.tf` ファイルに渡される変数の値を定義する `terraform.tfvars` ファイルを作成します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| `outputs.tf` ファイルを作成します。 | CodeBuild でいくつかの値を公開する新しい `outputs.tf` ファイルを作成します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 
| カスタマイズをコミットします。 | 新しいカスタマイズをアカウントカスタマイズリポジトリにコミットするには、次のコマンドを実行します。<pre># Assumes you are still in the /terraform directory<br />cd .. # Skip if you are in the account customization root directory (APG-AFT-IPAM)<br />git add .<br />git commit -m "APG customization"<br />git push origin</pre> | DevOps エンジニア | 
| カスタマイズを適用します。 | 新しく作成されたアカウントのカスタマイズを使用して、新しいアカウントをリクエストするコードを `account-requests.tf` ファイルに追加します。カスタムフィールドは、適切な IPAM 割り当て IPv4 CIDR を持つ VPC を作成するために必要なベンディングアカウントに、Systems Manager パラメータを作成します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | AWS DevOps | 
| カスタマイズを検証します。 | 新しいベンディングアカウントにサインインし、カスタマイズが正常に適用されたことを確認します。以下のステップを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft.html) | DevOps エンジニア | 

## トラブルシューティング
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
|  アクセス権限が不十分であるためリソースの作成または管理に障害が発生した。 |  Step Functions、CodeBuild、およびデプロイに関連するその他のサービスにアタッチされている AWS Identity and Access Management (IAM) ロールとポリシーを確認します。必要なアクセス権限があることを確認します。アクセス権限に問題がある場合は、IAM ポリシーを調整して必要なアクセス許可を付与します。 | 
|  デプロイ中に AWS のサービス クォータに達します。 |  パイプラインをデプロイする前に、Amazon Simple Storage Service (Amazon S3) AWS のサービス バケット、IAM ロール、 AWS Lambda 関数などのリソースのクォータを確認します。必要に応じて、クォータの増加をリクエストします。詳細については、「*AWS 全般リファレンス*」の「[AWS のサービス Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。 | 

## 関連リソース
<a name="automate-amazon-vpc-ipam-ipv4-cidr-allocations-for-new-aws-accounts-by-using-aft-resources"></a>

**AWS のサービス ドキュメント**
+ [AWS Control Tower ユーザーガイド](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [IPAM の仕組み](https://docs.aws.amazon.com/vpc/latest/ipam/how-it-works-ipam.html)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)

**その他のリソース**
+ [Terraform AWS プロバイダーのドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)

# AWS Systems Manager を使用して Windows レジストリエントリの追加または更新を自動化する
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager"></a>

*Amazon Web Services、Appasaheb bagali*

## 概要
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-summary"></a>

AWS Systems Manager は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのリモート管理ツールです。Systems Manager は、Amazon Web Services のインフラストラクチャの可視性と制御を提供します。この汎用性の高いツールを使用すると、セキュリティ脆弱性スキャンレポートで脆弱性と特定された Windows レジストリの変更を修正できます。 

このパターンでは、環境の安全のために推奨されるレジストリの変更を自動化することで、Windows オペレーティングシステムを実行している EC2 インスタンスの安全を保つ、手順について取り上げます。このパターンでは Run コマンドを使用してコマンドドキュメントを実行します。コードは添付されており、その一部は*コード*セクションに含まれます。

## 前提条件と制限事項
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-prereqs"></a>
+ アクティブなAWS アカウント
+ EC2 インスタンスと Systems Manager にアクセスする権限

## アーキテクチャ
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-architecture"></a>

**ターゲットテクノロジースタック**
+ 2 つのサブネットとネットワークアドレス変換 (NAT) ゲートウェイがある仮想プライベートクラウド (VPC)
+ レジストリ名と値を追加または更新する Systems Manager Command ドキュメント
+ 指定された EC2 インスタンス上で コマンドドキュメントを実行する Systems Manager Run コマンド

**ターゲットアーキテクチャ**

![\[AWS Systems Manager を使用して Windows レジストリエントリの追加または更新を自動化する方法\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2ecf680d-9f36-4070-8a19-2af262db7fcc/images/c992bcb0-d894-4aa7-9bb3-3d60c9c79e8d.png)


 

## ツール
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-tools"></a>

**ツール**
+ [IAM ポリシーとロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) – AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスのセキュアな制御に役立つ Web サービスです。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。
+ [Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) — Amazon Simple Storage Service (Amazon S3) は、インターネット用のストレージです。Web スケールのコンピューティングを開発者が容易にできるように設計されています。このパターンでは、S3 バケットを使用して Systems Manager ログを保存します。
+  [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) – AWS Systems Manager は、 AWS でインフラストラクチャの表示と制御に使用できる AWS サービスです。Systems Manager を使用すると、*マネージドインスタンス*をスキャンし、検出されるポリシー違反を報告（または是正措置を講じる）して、セキュリティとコンプライアンスを維持できます。
+ [AWS Systems Manager Command ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html) — AWS Systems Manager コマンドドキュメントは Run Command により使用されます。ほとんどのコマンドドキュメントは、Systems Manager でサポートされているすべての Linux および Windows Server オペレーティングシステムでサポートされています。
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) — AWS Systems Manager Run Command では、マネージドインスタンスの設定を安全にリモートで管理する方法を得られます。Run Command を使用すると、一般的な管理タスクを自動化し、一度限りの設定変更を大規模に実行できます。

**コード**

次のコード例を使用して、Microsoft Windows レジストリ名を `Version` に、レジストリパスを `HKCU:\Software\ScriptingGuys\Scripts` に、値を `2` に追加または更新できます。

```
#Windows registry path which needs to add/update
$registryPath ='HKCU:\\Software\\ScriptingGuys\\Scripts'
#Windows registry Name  which needs to add/update
$Name = 'Version'
#Windows registry value  which needs to add/update
$value = 2
# Test-Path cmdlet to see if the registry key exists. 
IF(!(Test-Path $registryPath))
        {
           New-Item -Path $registryPath -Force | Out-Null
           New-ItemProperty -Path $registryPath -Name $name -Value     $value ` -PropertyType DWORD -                 Force | Out-        Null 
        } ELSE {
                      New-ItemProperty -Path $registryPath -Name $name -Value $value ` -PropertyType            DWORD        -Force | Out-Null
            }
echo 'Registry Path:'$registryPath
 echo 'Registry Name:'$registryPath
 echo 'Registry Value:'(Get-ItemProperty -Path $registryPath -Name $Name).version
```

完全な Systems Manager コマンドドキュメントの JavaScript Object Notation (JSON) コード例が添付されています。 

## エピック
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-epics"></a>

### VPC をセットアップする
<a name="set-up-a-vpc"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| VPC を作成します。 | AWS マネジメントコンソールで、パブリックおよびプライベートのサブネットと NAT ゲートウェイがある VPC を作成します。詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/batch/latest/userguide/create-public-private-vpc.html)を参照してください。 | クラウド管理者 | 
| セキュリティグループを作成します。 | 各セキュリティグループが、ソース IP アドレスからのリモートデスクトッププロトコル (RDP) へのアクセスを許可していることを確認します。 | クラウド管理者 | 

### IAM ポリシーと IMA ロールを作成する
<a name="create-an-iam-policy-and-an-iam-role"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM ポリシーを作成します。 | Amazon S3、Amazon EC2、および Systems Manager へのアクセスを提供する IAM ポリシーを作成します。 | クラウド管理者 | 
| IAM ロールを作成します。 | IAM ロールを作成して、Amazon S3、Amazon EC2、および Systems Manager へのアクセスを提供する IAM ポリシーをアタッチします。 | クラウド管理者 | 

### 自動化を実行する
<a name="run-the-automation"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Systems Manager コマンドドキュメントを作成します。 | Microsoft Windows レジストリの変更をデプロイして追加または更新する Systems Manager コマンドドキュメントを作成します。 | クラウド管理者 | 
| Systems Manager Run Command を実行します。 | Systems Manager Run Command を実行し、コマンドドキュメントと Systems Manager ターゲットインスタンスを選択します。これにより、選択したコマンドドキュメント内の Microsoft Windows レジストリの変更がターゲットインスタンスにプッシュされます。 | クラウド管理者 | 

## 関連リソース
<a name="automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager-resources"></a>
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)

## アタッチメント
<a name="attachments-2ecf680d-9f36-4070-8a19-2af262db7fcc"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/2ecf680d-9f36-4070-8a19-2af262db7fcc/attachments/attachment.zip)」

# Python を使用して RFC を自動的に作成する
<a name="automatically-create-an-rfc-in-ams-using-python"></a>

*Gnanasekaran Kailasam (Amazon Web Services)*

## 概要
<a name="automatically-create-an-rfc-in-ams-using-python-summary"></a>

AWS Managed Services (AMS) は、Amazon Web Services (AWS) インフラストラクチャを継続的に管理することで、クラウドベースのインフラストラクチャをより効率的かつ安全に運用できるよう支援します。管理環境に変更するには、特定のオペレーションまたはアクションの変更タイプ (CT) ID を含む新しい変更リクエスト (RFC) を作成して送信する必要があります。

ただし、RFC を手動で作成するには約 5 分かかる場合があり、組織内のチームは毎日複数の RFC を提出する必要がある場合があります。このパターンは、RFC 作成プロセスを自動化し、各 RFC の作成時間を短縮し、手作業によるエラーを排除する上で役立ちます。  

このパターンでは、Python コードを使用して、AMS アカウントで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを停止する `Stop EC2 instance` RFCを自動的に作成する方法を説明します。その後、このパターンのアプローチと Python オートメーションを他の RFC タイプに適用できます。 

## 前提条件と制限
<a name="automatically-create-an-rfc-in-ams-using-python-prereqs"></a>

**前提条件**
+ AMS 詳細アカウント。詳細については、AWS Managed Services ドキュメントの「[AMS オペレーションプラン](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/what-is-ams-op-plans.html)」を参照してください。
+ AMS アカウントの 1 つ以上の既存の EC2 インスタンス。
+ AMS で RFC を作成して提出する方法の理解。
+ Python に精通していること。

**制限**
+ RFC は AMS アカウントの変更にのみ使用できます。AWS アカウントは、同様の変更するためにさまざまなプロセスを使用します。

## アーキテクチャ
<a name="automatically-create-an-rfc-in-ams-using-python-architecture"></a>

**テクノロジースタック**
+ AMS
+ AWS コマンドラインインターフェイス (AWS CLI)
+ 「AWS SDK for Python (Boto3)」
+ Python とそれに必要なパッケージ (JSON および Boto3)

**自動化とスケール**

このパターンは `Stop EC2 instance` RFC を自動化するためのサンプルコードを提供しますが、このパターンのサンプルコードとアプローチを他の RFC にも使用できます。

## ツール
<a name="automatically-create-an-rfc-in-ams-using-python-tools"></a>
+ [AWS Managed Services](https://docs.aws.amazon.com/managedservices/latest/ctexguide/ex-rfc-use-examples.html) – AMS は AWS インフラストラクチャをより効率的かつ安全に運用する上で役立ちます。
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) – AWS コマンドラインインターフェイス (AWS CLI) は、AWS のサービスを管理するための統合ツールです。AMS では、変更管理 API が RFC を作成および管理するための操作を提供します。
+ [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk/) — Python 用 SDK を使用すると、Python アプリケーション、ライブラリ、またはスクリプトを AWS のサービスと簡単に統合できます。

**コード**

`AMS Stop EC2 Instance.zip` ファイル (添付) には、`Stop EC2 instance` RFC を作成するための Python コードが含まれています。複数の EC2 インスタンスに対して 1 つの RFC を送信するようにこのコードを設定することもできます。

## エピック
<a name="automatically-create-an-rfc-in-ams-using-python-epics"></a>

### オプション 1 — macOS または Linux 用の環境をセットアップする
<a name="option-1-ndash-set-up-environment-for-macos-or-linux"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  Python をインストールして検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-create-an-rfc-in-ams-using-python.html) | AWS システム管理者 | 
|  AWS CLI をインストールします。 | `pip install awscli --upgrade –user` コマンドを実行して、AWS CLI をインストールします*。* | AWS システム管理者 | 
|  Boto3 をインストールします。 | `pip install boto3` コマンドを実行して、Boto3 をインストールします。 | AWS システム管理者 | 
| JSON をインストールします。 | `pip install json` コマンドを実行して、JSON をインストールします。 | AWS システム管理者 | 
| AMS CLI をセットアップします。 | AWS マネジメントコンソールにサインインし、AMS コンソールを開いてから、[**Documentation（ドキュメント）**] を選択します。AMS CLI を含む.zip ファイルをダウンロードし、解凍してから、ローカルマシンにインストールします。AMS CLI をインストールしたら、 `aws amscm help` コマンドを実行します。出力では、AMS 変更管理プロセスに関する情報が提供されます。 | AWS システム管理者 | 

### オプション 2 — Windows 用の環境をセットアップする
<a name="option-2-ndash-set-up-environment-for-windows"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  Python をインストールして検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-create-an-rfc-in-ams-using-python.html) | AWS システム管理者 | 
| AWS CLI をインストールします。 | `pip install awscli --upgrade –user` コマンドを実行して、AWS CLI をインストールします。 | AWS システム管理者 | 
|  Boto3 をインストールします。 | `pip install boto3` コマンドを実行して、Boto3 をインストールします。 | AWS システム管理者 | 
| JSON をインストールします。 | `pip install json` コマンドを実行して、JSON をインストールします。 | AWS システム管理者 | 
| AMS CLI をセットアップします。 | AWS マネジメントコンソールにサインインし、AMS コンソールを開いてから、[**Documentation（ドキュメント）**] を選択します。AMS CLI を含む.zip ファイルをダウンロードし、解凍してから、ローカルマシンにインストールします。AMS CLI をインストールしたら、 `aws amscm help` コマンドを実行します。出力では、AMS 変更管理プロセスに関する情報が提供されます。 | AWS システム管理者 | 

### RFC の CT ID と実行パラメータを抽出する
<a name="extract-the-ct-id-and-execution-parameters-for-the-rfc"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| RFC の CT ID、バージョン、実行パラメータを抽出します。 | 各 RFC には異なる CT ID、バージョン、実行パラメーターがあります。この情報は、次のいずれかのオプションを使用して抽出できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-create-an-rfc-in-ams-using-python.html)このパターンの Python オートメーションを他の RFC に適用するには、`AMS Stop EC2 Instance.zip` ファイル (添付) の `ams_stop_ec2_instance` Python コードファイル内の CT タイプとパラメータ値を抽出したものに置き換えます。 | AWS システム管理者 | 

### Python オートメーションを実行します。
<a name="run-the-python-automation"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Python オートメーションを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-create-an-rfc-in-ams-using-python.html) | AWS システム管理者 | 

## 関連リソース
<a name="automatically-create-an-rfc-in-ams-using-python-resources"></a>
+ [変更タイプとは?](https://docs.aws.amazon.com/managedservices/latest/ctexguide/understanding-cts.html)
+ [CLI チュートリアル: 高可用性 2 層スタック (Linux/RHEL)](https://docs.aws.amazon.com/managedservices/latest/ctexguide/tut-create-ha-stack.html)

## アタッチメント
<a name="attachments-2b6c68fd-a27e-4c8b-934d-caec50c196ed"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/2b6c68fd-a27e-4c8b-934d-caec50c196ed/attachments/attachment.zip)」

# AWS Systems Manager メンテナンスウィンドウを使用して Amazon RDS DB インスタンスを自動的に停止および起動する
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows"></a>

*Ashita Dsilva (Amazon Web Services)*

## 概要
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-summary"></a>

このパターンは、 AWS Systems Manager メンテナンスウィンドウを使用して、特定のスケジュールで Amazon Relational Database Service (Amazon RDS) DB インスタンスを自動的に停止および開始する方法 (例: 営業時間外に DB インスタンスをシャットダウンしてコストを削減する) を示しています。この目的で、Systems Manager は一般的なユースケースでコスト効率に優れています。

AWS Systems Manager Automation は、`AWS-StopRdsInstance`Amazon RDS DB インスタンスを停止および起動するための および `AWS-StartRdsInstance`ランブックを提供します。つまり、 AWS Lambda 関数を使用してカスタムロジックを記述したり、Amazon CloudWatch Events ルールを作成したりする必要はありません。

Systems Manager は、タスクをスケジュールするための 2 つの機能、[State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-state-about.html) と [Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) を提供します。State Manager は、Amazon Web Services (AWS) アカウント内のリソースに必要な状態設定を 1 回だけ、または特定のスケジュールで設定、管理します。Maintenance Windows は、特定の時間枠にアカウント内のリソースに対してタスクを実行します。このパターンのアプローチはステートマネージャーまたはメンテナンスウィンドウで使用できますが、割り当てられた優先度に基づいて 1 つ以上のタスクを実行でき、 AWS Lambda 関数と AWS Step Functions タスクを実行できるため、メンテナンスウィンドウを使用することをお勧めします。State Manager と Maintenance Windows の詳細については、Systems Manager ドキュメントの「[State Manager または Maintenance Windows の選択](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-vs-maintenance-windows.html)」を参照してください。

このパターンでは、cron 式を使用して Amazon RDS DB インスタンスを停止してから起動する 2 つのメンテナンスウィンドウを個別に設定する詳細な手順を示しています。 

## 前提条件と制限
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-prereqs"></a>

**前提条件**
+ アクティブ AWS アカウント。
+ 特定のスケジュールで停止して開始したい既存の Amazon RDS DB インスタンス。
+ 必要なスケジュールの Cron 式。例えば、式 `cron(0 9 ? * MON-FRI *)` は毎週月曜日、火曜日、水曜日、木曜日、金曜日の午前 9 時にタスクを実行します。詳細は、「Systems Manager のドキュメント」の「[メンテナンスウィンドウの関連付けに使用する cron 式および rate 式](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html#reference-cron-and-rate-expressions-maintenance-window)」を参照してください。
+ Systems Manager に精通しています。
+ RDS インスタンスを起動および停止するアクセス許可。詳細については、「[エピック](#automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-epics)」セクションを参照してください。

**制限事項**
+ Amazon RDS DB インスタンスは一度に最大 7 日間停止できます。7 日後、DB インスタンスは自動的に再起動し、必要なメンテナンスアップデートを確実に受け取ることができます。
+ リードレプリカである DB インスタンス、またはリードレプリカを持つ DB インスタンスを停止することはできません。
+ マルチ AZ 設定では Amazon RDS for SQL Server DB インスタンスを停止できません。
+ Service Quotas は、Maintenance Windows と Systems Manager Automation に適用されます。サービスクォータの詳細については、 AWS 全般のリファレンス ドキュメントの[AWS Systems Manager 「エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ssm.html)」を参照してください。 
+ 一部の 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)」ページを参照して、サービスのリンクを選択します。

## アーキテクチャ
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-architecture"></a>

次の図では、Amazon RDS DB インスタンスを自動的に停止して開始するワークフローを示します。

![\[自動的に Amazon RDS DB インスタンスを停止して開始するワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/45b81621-5674-4bcf-bf7c-75ae6f62524e/images/7d943830-716e-46a3-be44-7e668c3c01ff.png)


 

ワークフローには次の手順があります。

1. メンテナンスウィンドウを作成し、cron 式を使用して Amazon RDS DB インスタンスの停止と開始のスケジュールを定義します。

2. `AWS-StopRdsInstance` または `AWS-StartRdsInstance` ランブックを使用して Systems Manager 自動化タスクをメンテナンスウィンドウに登録します。

3. Amazon RDS DB インスタンスのタグベースのリソースグループを使用して、メンテナンスウィンドウにターゲットを登録します。

**テクノロジースタック**
+ AWS CloudFormation
+ AWS Identity and Access Management (IAM)
+ Amazon RDS
+ Systems Manager

**自動化とスケール**

必要な Amazon RDS DB インスタンスにタグを付け、タグ付けされたすべての DB インスタンスを含むリソースグループを作成し、このリソースグループをメンテナンスウィンドウのターゲットとして登録することで、複数の Amazon RDS DB インスタンスを同時に停止および起動できます。

## ツール
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-tools"></a>
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースのモデル化とセットアップに役立つサービスです。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、 AWS リソースへのアクセスを安全に制御するのに役立つウェブサービスです。
+ [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) は、 AWS クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングすることのできるウェブサービスです。
+ [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html) は、 AWS リソースをグループに整理し、リソースにタグを付け、グループ化されたリソースのタスクを管理、モニタリング、自動化するのに役立ちます。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、インフラストラクチャを表示および制御するために AWS のサービス 使用できる です AWS。このパターンでは、次の Systems Manager の機能を使用します。
  + [AWS Systems Manager 自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)により、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスやその他の AWS リソースの一般的なメンテナンスおよびデプロイタスクが簡素化されます。
  + [AWS Systems Manager メンテナンスウィンドウ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)は、インスタンスで破壊的になり得るアクションを実行するスケジュールを定義するのに役立ちます。

## エピック
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-epics"></a>

### Systems Manager Automation の IAM サービスロールを作成および設定する
<a name="create-and-configure-the-iam-service-role-for-sys-automation"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Systems Manager Automation の IAM サービスロールを設定します。 | にサインイン AWS マネジメントコンソール し、Systems Manager Automation のサービスロールを作成します。次の 2 つのメソッドのいずれかを使用して、このサービスロールを作成できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html)Systems Manager 自動化ワークフローは、サービスロールを使用して Amazon RDS DB インスタンスで開始アクションと停止アクションを実行することで Amazon RDS を呼び出します。サービスロールは、Amazon RDS DB インスタンスを起動および停止する権限を持つ以下の[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)で設定する必要があります。<pre>{<br />    "Version": "2012-10-17",		 	 	 <br />    "Statement": [<br />        {<br />            "Sid": "RdsStartStop",<br />            "Effect": "Allow",<br />            "Action": [<br />                "rds:StopDBInstance",<br />                "rds:StartDBInstance"<br />            ],<br />            "Resource": "<RDS_Instance_ARN>"               <br />        },<br />        {<br />            "Sid": "RdsDescribe",<br />            "Effect": "Allow",<br />            "Action": "rds:DescribeDBInstances",<br />            "Resource": "*"<br />        }<br />    ]<br />}</pre>必ず `<RDS_Instance_ARN>` を Amazon RDS DB インスタンスの Amazon リソースネーム (ARN) で置き換えます。IAM ポリシーとロールの使用に慣れていない場合は、「[Schedule Amazon RDS stop and start using AWS Systems Manager](https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-systems-manager/)」の「*Solution Overview*」セクションの指示に従ってください。サービスロールの ARN を必ず記録してください。 | AWS 管理者 | 

### リソースグループの作成
<a name="create-a-resource-group"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Amazon RDS DB インスタンスにタグを付けます | [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、リソースグループに追加する Amazon RDS DB インスタンスにタグを付けます。タグは AWS リソースに割り当てられたメタデータであり、キーと値のペアで構成されます。*[アクション]* を **[タグキー]** として使用し、*[StartStop]* を **[値]** として使用することをお勧めします。詳細については、Amazon RDS ドキュメントの「[タグの追加、リスト化、削除](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html#Tagging.HowTo)」を参照してください。 | AWS 管理者 | 
| タグを付加した Amazon RDS DB インスタンス用のリソースグループを作成します。 | [AWS Resource Groups コンソール](https://console.aws.amazon.com/resource-groups)を開き、Amazon RDS DB インスタンス用に作成したタグに基づいてリソースグループを作成します。**[グループ化基準]** で、必ずリソースタイプに **[AWS:: RDS:: DBInstance]** を選択し、タグのキーと値のペア (「Action-StartStop」など) を指定してください。これにより、サービスは Amazon RDS DB インスタンスのみをチェックし、このタグを持つその他のリソースはチェックしないことが保証されます。****リソースグループの名前は必ず記録してください。詳細と詳細な手順については、 AWS Resource Groups ドキュメントの[「タグベースのクエリを構築する」および「グループを作成する](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-query.html#gettingstarted-query-tag-based)」を参照してください。  | AWS 管理者 | 

### Amazon RDS DB インスタンスを停止するメンテナンスウィンドウを設定する
<a name="configure-a-maintenance-window-to-stop-the-rds-db-instances"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| メンテナンスウィンドウを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html)DB インスタンスを停止するタスクは開始するとほぼ瞬時に実行され、メンテナンスウィンドウ全体には適用されません。このパターンでは、タスクの開始**期間**と**開始タスクの停止**の最小値が提供されます。これは、これらがメンテナンス時間枠に必要なパラメータであるためです。詳細と詳細な手順については、Systems Manager ドキュメントの「[コンソールを使用してメンテナンスウィンドウを作成する](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-create-mw.html)」を参照してください。 | AWS 管理者 | 
| ターゲットをメンテナンスウィンドウに割り当てます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html)詳細と詳細な手順については、Systems Manager ドキュメントの「[コンソールを使用してメンテナンスウィンドウにターゲットを割り当てる](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-assign-targets.html)」を参照してください。 | AWS 管理者 | 
| メンテナンスウィンドウにタスクを割り当てるには | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html)******サービスロール**オプションでは、メンテナンスウィンドウでタスクを実行するために必要なサービスロールを定義します。ただし、このロールは、以前に Systems Manager Automation 用に作成したサービスロールと同じではありません。詳細と詳細な手順については、Systems Manager ドキュメントの「[コンソールを使用してメンテナンスウィンドウにタスクを割り当てる](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-assign-tasks.html)」を参照してください。 | AWS 管理者 | 

### Amazon RDS DB インスタンスを起動するメンテナンスウィンドウを設定する
<a name="configure-a-maintenance-window-to-start-the-rds-db-instances"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Amazon RDS DB インスタンスを起動するメンテナンスウィンドウを設定します。 | 「*Amazon RDS DB インスタンスを停止するメンテナンスウィンドウを設定する*」の手順を繰り返し、スケジュールされた時間に Amazon RDS DB インスタンスを起動する別のメンテナンスウィンドウを設定します。DB インスタンスを起動するようにメンテナンスウィンドウを設定するときは、次の変更を行う必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html) | AWS 管理者 | 

## 関連リソース
<a name="automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows-resources"></a>
+ [Systems Manager Automation ドキュメントを使用してインスタンスを管理し、時間外にコストを削減する](https://aws.amazon.com/blogs/mt/systems-manager-automation-documents-manage-instances-cut-costs-off-hours/) (AWS ブログ記事)

# Terraform を使用して AWS Organizations でのソフトウェアパッケージの配布を一元化する
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform"></a>

*Amazon Web Services、Pradip kumar Pandey、Chintamani Aphale、T.V.R.L.Phani Kumar Dadi、Pratap Kumar Nanda、Aarti Rajput、Mayuri Shinde*

## 概要
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-summary"></a>

多くの場合、ワークロード間に強力な分離障壁を構築 AWS リージョン するために、企業は複数の にまた AWS アカウント がる複数の を維持します。管理チームはセキュリティとコンプライアンスを維持するために、セキュリティスキャン用には [CrowdStrike](https://www.crowdstrike.com/falcon-platform/)、[SentinelOne](https://www.sentinelone.com/platform/)、[TrendMicro](https://www.trendmicro.com/en_sg/business.html) ツールなどのエージェントベースのツール、モニタリング用には [Amazon CloudWatch エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)、[Datadog エージェント](https://www.datadoghq.com/)、または [AppDynamics エージェント](https://www.appdynamics.com/product/how-it-works/agents-and-controller)をインストールします。こうした大規模な環境全体で、ソフトウェアパッケージの管理と配布を一元的に自動化しようとする場合、管理チームはしばしば課題に直面します。

[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) の一機能である [Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) は、単一の簡素化されたインターフェイスを通じて、クラウドおよびオンプレミスサーバー全体のマネージド Microsoft Windows および Linux インスタンスに対し、ソフトウェアをパッケージ化して公開するプロセスを自動化します。このパターンは、Terraform を使用してソフトウェアのインストールの管理プロセスをさらに簡素化し、最小限の労力 AWS Organizations で 内の多数のインスタンスとメンバーアカウントでスクリプトを実行する方法を示しています。

このソリューションは、Systems Manager によって管理される Amazon、Linux、および Windows インスタンスで機能します。

## 前提条件と制限事項
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-prereqs"></a>
+ インストール対象のソフトウェアを含む [Distributor パッケージ](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor-working-with-packages-create.html)
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) バージョン 0.15.0 以降
+ [Systems Manager によって管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/managed_instances.html)され、ターゲットアカウントの [Amazon Simple Storage Service (Amazon S3) にアクセスするための基本的なアクセス許可](https://repost.aws/knowledge-center/ec2-instance-access-s3-bucket)を持つ Amazon Elastic Compute Cloud (Amazon EC2) インスタンス
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) を使用して設定する組織のランディングゾーン
+ (オプション) [Account Factory for Terraform (AFT)](https://catalog.workshops.aws/control-tower/en-US/customization/aft)

## アーキテクチャ
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-architecture"></a>

**リソースの詳細**

このパターンでは[、Account Factory for Terraform (AFT) ](https://catalog.workshops.aws/control-tower/en-US/customization/aft)を使用してすべての必要な AWS リソースを作成し、コードパイプラインを使用してデプロイアカウントにリソースをデプロイします。コードパイプラインは、次の 2 つのリポジトリで実行されます。
+ **グローバルカスタマイズ**は、AFT に登録されているすべてのアカウントで実行される Terraform コードを対象とします。
+ **アカウントのカスタマイズ**には、デプロイアカウントで実行される Terraform コードが含まれます。

アカウントカスタマイズフォルダで [Terraform](https://developer.hashicorp.com/terraform/intro) コマンドを実行することで、AFT を使用せずにこのソリューションをデプロイすることもできます。

Terraform コードにより、次のリソースがデプロイされます。
+ AWS Identity and Access Management (IAM) ロールとポリシー
  + [SystemsManager-AutomationExecutionRole](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html) は、ターゲットアカウントで自動化を実行するためのアクセス許可をユーザーに付与します。
  + [SystemsManager-AutomationAdministrationRole](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html) は、複数のアカウントと組織単位 (OU) で自動化を実行するためのアクセス許可をユーザーに付与します。
+ パッケージの圧縮ファイルと manifest.json
  + Systems Manager では、1 つの[パッケージ](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor-working-with-packages-create.html)に、ソフトウェアまたはインストール可能なアセットの .zip ファイルが 1 つ以上含まれます。
  + JSON マニフェストには、パッケージコードファイルへのポインタが含まれます。
+ S3 バケット
  + 組織全体で共有されている分散パッケージは、Amazon S3 バケットに安全に保存されます。
+ AWS Systems Manager ドキュメント (SSM ドキュメント)
  + `DistributeSoftwarePackage` には、メンバーアカウントのすべてのターゲットインスタンスにソフトウェアパッケージを配布するためのロジックが含まれています。
  + `AddSoftwarePackageToDistributor` には、インストール可能なソフトウェアアセットをパッケージ化し、その機能である Automation に追加するロジックが含まれています AWS Systems Manager。
+ Systems Manager の関連付け
  + Systems Manager の関連付けは、ソリューションのデプロイに使用されます。

**アーキテクチャとワークフロー**

![\[AWS Organizations でソフトウェアパッケージの配布を一元化するためのアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da584449-e12b-4878-a61d-00d8cea3d3d7/images/2718f2c4-f816-4e34-89b8-8182c128e6db.png)


この図は、以下のステップを示しています。

1. 一元化されたアカウントからソリューションを実行するために、デプロイステップに従って、パッケージまたはソフトウェアを S3 バケットにアップロードします。

1. カスタマイズされたパッケージは、Systems Manager コンソールの **[自分が所有]** タブの[[ドキュメント]](https://ap-southeast-2.console.aws.amazon.com/systems-manager/documents?region=ap-southeast-2) セクションから利用可能になります。

1. Systems Manager の一機能であるステートマネージャーは、組織全体でパッケージの関連付けを作成、スケジュール、実行します。関連付けを行うことで、ソフトウェアパッケージをマネージドノードにインストールして実行してからでないと、このパッケージをターゲットノードにインストールできなくなります。

1. 関連付けにより、Systems Manager はターゲットノードにパッケージをインストールするように指示されます。

1. これ以降にインストールまたは変更を行う場合、ユーザーは同じ関連付けを 1 つの場所から定期的に、または手動で実行することで、アカウント間でデプロイを実行できます。

1. メンバーアカウントでは、Automation がデプロイコマンドを Distributor に送信します。

1. Distributor は、インスタンス間にソフトウェアパッケージを配布します。

このソリューションでは、 内の管理アカウントを使用しますが AWS Organizations、組織に代わってこれを管理するためのアカウント (委任管理者) を指定することもできます。

## ツール
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-tools"></a>

**AWS サービス**
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、量にかかわらず、データを保存、保護、取得するのに役立つクラウドベースのオブジェクトストレージサービスです。このパターンでは、Amazon S3 を使用して分散パッケージを一元化し、安全に保存します。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。このパターンでは、次の Systems Manager 機能を使用します。
  + [Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) は、ソフトウェアをパッケージ化して、Systems Manager のマネージドインスタンスに公開するのに役立ちます。
  + [自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)により、多くの AWS サービスの一般的なメンテナンス、デプロイ、修復タスクが簡素化されます。
  + [Documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) は、組織とアカウント全体で、Systems Manager のマネージドインスタンスに対するアクションを実行します。
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する組織に複数の AWS アカウントを統合するのに役立つアカウント管理サービスです。

**その他のツール**
+ [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

**コードリポジトリ**

このパターンの手順とコードは、GitHub [Centralized Package Distribution](https://github.com/aws-samples/aws-organization-centralised-package-distribution) リポジトリで入手できます。

## ベストプラクティス
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-best-practices"></a>
+ 関連付けにタグを割り当てるには、[AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) または [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html) を使用します。Systems Manager コンソールを使用して関連付けにタグを追加することはできません。詳細については、Systems Manager ドキュメントの「[Tagging Systems Manager resources](https://docs.aws.amazon.com/systems-manager/latest/userguide/tagging-resources.html)」を参照してください。
+ 別のアカウントから共有されたドキュメントの新しいバージョンを使用して関連付けを実行する場合は、ドキュメントバージョンを `default` に設定する必要があります。
+ ターゲットノードにのみタグを付けるには、1 つのタグキーを使用します。複数のタグキーを使用してノードをターゲットにするには、リソースグループオプションを使用します。

## エピック
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-epics"></a>

### ソースファイルとアカウントを設定する
<a name="configure-source-files-and-accounts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リポジトリのクローンを作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 
| グローバル変数を更新 | `global-customization/variables.tf` ファイルで、以下の入力パラメータを更新します。これらの変数は、AFT によって作成および管理されるすべてのアカウントに適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 
| アカウント変数を更新 | `account-customization/variables.tf` ファイルで、以下の入力パラメータを更新します。これらの変数は、AFT によって作成および管理される特定のアカウントにのみ適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 

### パラメータとデプロイファイルのカスタマイズ
<a name="customize-parameters-and-deployment-files"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ステートマネージャーの関連付けの入力パラメータを更新 | `account-customization/association.tf` ファイル内の次の入力パラメータを更新して、インスタンスで維持する状態を定義します。ユースケースに対応している場合は、デフォルトのパラメータ値をそのまま使用できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 
| 圧縮ファイルと `manifest.json` ファイルをパッケージ用に準備する | このパターンでは、PowerShell のインストール可能ファイル (Windows の場合は .msi、Linux の場合は .rpm) のサンプルと、インストールおよびアンインストールスクリプトが `account-customization/package` フォルダに提供されています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 

### Terraform コマンドを実行してリソースをプロビジョニングする
<a name="run-terraform-commands-to-provision-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Terraform の設定を初期化する | AFT を使用してソリューションを自動的にデプロイするには、コードを AWS CodeCommitにプッシュします。<pre>$ git add *<br />$ git commit -m "message"<br />$ git push</pre>`account-customization` フォルダから Terraform コマンドを実行して、AFT を使用せずにこのソリューションをデプロイすることもできます。Terraform ファイルを含む作業ディレクトリを初期化するには、以下を実行します。<pre>$ terraform init</pre> | DevOps エンジニア | 
| 変更のプレビュー | Terraform がインフラストラクチャに加える変更をプレビューするには、次のコマンドを実行します。<pre>$ terraform plan</pre>このコマンドは、Terraform 設定を評価して、宣言されたリソースの望ましい状態を決定します。また、ワークスペース内でプロビジョニングする実際のインフラストラクチャを、その望ましい状態と比較します。 | DevOps エンジニア | 
| 変更を適用 | 次のコマンドを実行して、`variables.tf` ファイルに加えた変更を実装します。<pre>$ terraform apply</pre> | DevOps エンジニア | 

### リソースを検証する
<a name="validate-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| SSM ドキュメントの作成を検証する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html)`DistributeSoftwarePackage` および `AddSoftwarePackageToDistributor` パッケージが表示されます。 | DevOps エンジニア | 
| オートメーションのデプロイが成功したことを検証する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 
| パッケージがターゲットのメンバーアカウントインスタンスにデプロイされたことを確認する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralize-software-package-distribution-in-aws-organizations-by-using-terraform.html) | DevOps エンジニア | 

## トラブルシューティング
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| ステートマネージャーの関連付けが失敗しているか、保留中のステータスのままになっています。 |  AWS ナレッジセンターの[トラブルシューティング情報](https://repost.aws/knowledge-center/ssm-state-manager-association-fail)を参照してください。 | 
| スケジュールされた関連付けの実行に失敗しました。 | スケジュール仕様が無効である可能性があります。現在、ステートマネージャーでは、関連付けの cron 式での月の指定はサポートされていません。[cron 式または rate 式](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)を使用してスケジュールを確認してください。 | 

## 関連リソース
<a name="centralize-software-package-distribution-in-aws-organizations-by-using-terraform-resources"></a>
+ [Centralized package distribution](https://github.com/aws-samples/aws-organization-centralised-package-distribution) (GitHub リポジトリ)
+ [Account Factory for Terraform (AFT)](https://catalog.workshops.aws/control-tower/en-US/customization/aft)
+ [ユースケースとベストプラクティス](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-best-practices.html) (AWS Systems Manager ドキュメント)

# NLog を使用して Amazon CloudWatch Logs 内の.NET アプリケーションのロギングを設定します
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog"></a>

*Bibhuti Sahu and Rob Hill (AWS) (Amazon Web Services)*

## 概要
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-summary"></a>

このパターンでは、NLog オープンソースのロギングフレームワークを使用して、.NET アプリケーションの使用状況とイベントを「[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」に記録する方法について説明します。CloudWatch コンソールでは、アプリケーションのログメッセージをほぼリアルタイムで見ることができます。メトリックスを設定し、「[メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)」のしきい値を超えた場合に通知するように「[アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」を設定することもできます。CloudWatch Application Insights を使用すると、監視対象アプリケーションの潜在的な問題を示す自動またはカスタムのダッシュボードを表示できます。CloudWatch Application Insights は、アプリケーションとインフラストラクチャに関する進行中の問題をすばやく切り分けることができるように設計されています。

CloudWatch Logs にログメッセージを書き込むには、`AWS.Logger.NLog` NuGet パッケージを.NET プロジェクトに追加します。次に、CloudWatch Logs をターゲットとして使用するように `NLog.config` ファイルを更新します。

## 前提条件と制限
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ .NET ウェブアプリケーションまたはコンソールアプリケーション:
  + サポートされている.NET Framework バージョンまたは.NET Core バージョンを使用します。詳細については、「*製品バージョン*」を参照してください。
  + NLog を使用してログデータをアプリケーションインサイトのに送信します。
+ AWS サービスの IAM ロールを作成するアクセス許可。詳細については、「[サービスロールのアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#id_roles_create_service-permissions)」を参照してください。
+ AWS サービスにロールを渡すためのアクセス許可。詳細については、[Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) を参照してください。

**製品バージョン**
+ .NET Framework バージョン 3.5 またはそれ以降
+ .NET Core バージョン 1.0.1、2.0.0、またはそれ以降

## アーキテクチャ
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-architecture"></a>

**ターゲットテクノロジースタック**
+ NLog
+ Amazon CloudWatch Logs

**ターゲットアーキテクチャ**

![\[.NET アプリケーションのログデータを Amazon CloudWatch ログに書き込む NLog のアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0ac9c3ad-2a28-415f-afc3-7fe3494b2b63/images/daea9f2f-7242-4ed2-843e-655d843dcfdf.png)


1. .NET アプリケーションは NLog ロギングフレームワークにログデータを書き込みます。

1. NLog は CloudWatch Logs にログデータを書き込みます。

1. CloudWatch アラームとカスタムダッシュボードを使用して .NET アプリケーションをモニタリングします。

## ツール
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-tools"></a>

**AWS サービス**
+ 「[Amazon CloudWatch Application Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html)」は、アプリケーションと、その基盤となる AWS のリソースに対するオブザーバビリティを実現します。
+ 「[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」は、すべてのシステム、アプリケーション、 からのログを一元化するのに役立ちます。一元化により、ログを監視して安全にアーカイブできます。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ 「[AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html)」は PowerShell モジュールのセットで、PowerShell コマンドラインから AWS リソースに対するオペレーションのスクリプトを作成できます。

その他のツール
+ 「[Logger.nLog](https://www.nuget.org/packages/AWS.Logger.NLog)」は、ログデータを CloudWatch Logs に記録する NLog ターゲットです。
+ 「[NLog](https://nlog-project.org/)」は .NET プラットフォーム用のオープンソースのロギングフレームワークで、データベース、ログファイル、コンソールなどのターゲットにログデータを書き込むのに役立ちます。
+ 「[PowerShell](https://learn.microsoft.com/en-us/powershell/)」は Windows、Linux、および macOS で動作するMicrosoft の自動化および構成管理プログラムです。
+ 「[Visual Studio](https://docs.microsoft.com/en-us/visualstudio/get-started/visual-studio-ide?view=vs-2022)」は、コンパイラー、コード補完ツール、グラフィカルデザイナー、およびソフトウェア開発をサポートするその他の機能を含む統合開発環境 (IDE) です。

## ベストプラクティス
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-best-practices"></a>
+ ターゲットロググループの「[保存ポリシー](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)」を設定します。これは NLog 設定の外部で行う必要があります。デフォルトでは、ログデータは CloudWatch Logs に無期限に保存されます。
+ 「[AWS アクセスキーを管理するためのベストプラクティス](https://docs.aws.amazon.com/accounts/latest/reference/credentials-access-keys-best-practices.html)」を遵守します。

## エピック
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-epics"></a>

### アクセスとツールのセットアップ
<a name="set-up-access-and-tools"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM ポリシーを作成します。 | IAM ドキュメントの「[JSON エディタを使ったポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」の指示に従ってください。次の JSON ポリシーを入力します。このポリシーには、CloudWatch Logs にログの読み取りと書き込みを許可するのに必要な最小特権のアクセス権限があります。<pre>{<br />    "Version": "2012-10-17",		 	 	 <br />    "Statement": [<br />        {<br />            "Effect": "Allow",<br />            "Action": [<br />                "logs:CreateLogGroup",<br />                "logs:CreateLogStream",<br />                "logs:GetLogEvents",<br />                "logs:PutLogEvents",<br />                "logs:DescribeLogGroups",<br />                "logs:DescribeLogStreams",<br />                "logs:PutRetentionPolicy"<br />            ],<br />            "Resource": [<br />                "*"<br />            ]<br />        }<br />    ]<br />}</pre> | AWS 管理者、AWS DevOps | 
| IAM ロールを作成します。 | IAM ドキュメントの「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」の手順に従ってください。前に作成したポリシーを選択します。これは、CloudWatch Logs がロギングアクションを実行するために引き受けるロールです。 | AWS 管理者、AWS DevOps | 
| AWS Tools for PowerShellのセットアップ。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.html) | AWS 全般 | 

### NLog を設定
<a name="configure-nlog"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| NuGet パッケージをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.html) | アプリ開発者 | 
| ロギングターゲットを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.html)設定ファイルのサンプルについては、このパターンの「[追加情報](#configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-additional)」セクションを参照してください。アプリケーションを実行すると、NLog がログメッセージを書き込んで CloudWatch Logs に送信します。 | アプリ開発者 | 

### ログの検証とモニタリング
<a name="validate-and-monitor-logs"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ロギングを検証する。 | CloudWatch Logs ドキュメントの「[CloudWatch Logs に送信されたログデータを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)」の指示に従ってください。.NET アプリケーションのログイベントが記録されていることを確認します。ログイベントが記録されていない場合は、このパターンの「[トラブルシューティング](#configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-troubleshooting)」セクションを参照してください。 | AWS 全般 | 
| .NET アプリケーションスタックを監視します。 | ユースケースの必要に応じて CloudWatch でモニタリングを設定します。「[CloudWatch ログインサイト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」、「[CloudWatch メトリクスインサイト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)」、および「[CloudWatch アプリケーションインサイト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html)」を使用して、.NET ワークロードをモニタリングできます。アラートを受信できるように「[アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を設定したり、1 つのビューからワークロードを監視するためのカスタム「[ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を作成したりすることもできます。 | AWS 全般 | 

## トラブルシューティング
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| ログデータは CloudWatch Logs には表示されません。 | IAM ポリシーが CloudWatch Logs が引き受ける IAM ロールにアタッチされていることを確認します。手順については、「[エピック](#configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-epics)」セクションの「*アクセスとツールのセットアップ*」セクションを参照してください。 | 

## 関連リソース
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-resources"></a>
+ 「[ロググループとログストリームの操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」(CloudWatch Logsドキュメント)
+ 「[Amazon CloudWatch Logs と.NET ロギングフレームワーク](https://aws.amazon.com/blogs/developer/amazon-cloudwatch-logs-and-net-logging-frameworks/)」(AWS ブログ記事)

## 追加情報
<a name="configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog-additional"></a>

次に、サンプル `NLog.config` ファイルを示します。

```
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog" />
  </configSections>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
  </startup>
  <nlog>
    <extensions>
      <add assembly="NLog.AWS.Logger" />
    </extensions>
    <targets>
      <target name="aws" type="AWSTarget" logGroup="NLog.TestGroup" region="us-east-1" profile="demo"/>
    </targets>
    <rules>
      <logger name="*" minlevel="Info" writeTo="aws" />
    </rules>    
  </nlog>
</configuration>
```

# AWS Service Catalog 製品を異なる AWS アカウントと AWS リージョンにコピー
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions"></a>

*Sachin Vighe、Santosh Kale (Amazon Web Services)*

## 概要
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-summary"></a>

AWS Service Catalog はリージョナルサービスです。つまり、AWS Service Catalog の[ポートフォリオと製品](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/what-is_concepts.html) は、それらが作成された AWS リージョンでのみ表示されます。新しいリージョンに [AWS Service Catalog ハブ](https://aws.amazon.com/about-aws/whats-new/2020/06/aws-service-catalog-now-supports-sharing-portfolios-across-an-organization-from-a-delegated-member-account/) をセットアップする場合、既存の製品を再作成する必要があり、これには時間がかかる場合があります。

このパターンのアプローチは、ソース AWS アカウントまたはリージョンの AWS Service Catalog ハブからターゲットアカウントまたはリージョンの新しいハブに製品をコピーする方法を説明することで、このプロセスを簡素化するのに役立ちます。AWS Service Catalog のハブとスポークモデルの詳細については、AWS 管理とガバナンスブログの[AWS Service Catalog のハブとスポークモデル：AWS Service Catalog の多数のアカウントへのデプロイと管理を自動化する方法](https://aws.amazon.com/blogs/mt/aws-service-catalog-hub-and-spoke-model-how-to-automate-the-deployment-and-management-of-service-catalog-to-many-accounts/)を参照してください。 

このパターンでは、AWS Service Catalog 製品をアカウント間でコピーしたり、他のリージョンにコピーしたりするのに必要な個別のコードパッケージも用意されています。このパターンを使用することにより、組織は時間を節約し、既存および以前の製品バージョンを新しい AWS Service Catalog ハブで利用できるようにし、手動エラーのリスクを最小限に抑え、複数のアカウントまたはリージョンにわたってアプローチを拡大できます。

**注記**  
このパターンの「*エピック*」セクションでは、製品をコピーするための 2 つのオプションを紹介しています。オプション 1 を使用すると、アカウントをまたいで製品をコピーでき、オプション 2 を使用すると、リージョン間で製品をコピーできます。

## 前提条件と制限事項
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ ソースアカウントまたはリージョンの既存の AWS Service Catalog 製品。
+ 移行先のアカウントまたはリージョンの既存の AWS Service Catalog ハブ。
+ アカウントをまたいで製品をコピーする場合は、製品を含む AWS Service Catalog ポートフォリオを共有してから宛先アカウントにインポートする必要があります。詳細については、AWS Service Catalog ドキュメントの[ポートフォリオの共有とインポート](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing.html) を参照してください。

**機能制限**
+ リージョンまたはアカウント間でコピーする AWS Service Catalog 製品は、複数のポートフォリオに属することはできません。

## アーキテクチャ
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-architecture"></a>

次の図は、移行元アカウントから移行先アカウントへの AWS Service Catalog 製品のコピーを示しています。

![\[リージョン 1 のクロスアカウントロール、リージョン 2 の Lambda 実行ロールおよび Lambda 関数。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7ede5d17-89eb-4455-928f-6953d145ac9f/images/26738220-1ed2-4f84-911b-3c88e954b60e.png)


 次の図は、ソースリージョンからターゲットリージョンへの AWS Service Catalog 製品のコピーを示しています。

![\[リージョン 2 の Lambda scProductCopy 関数を使用してコピーされた製品。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7ede5d17-89eb-4455-928f-6953d145ac9f/images/0a936792-3bdc-45c2-ba05-17e828615061.png)


**テクノロジースタック**
+ Amazon CloudWatch
+ AWS Identity and Access Management (IAM)
+ AWS Lambda
+ AWS Service Catalog

**自動化とスケール**

このパターンのアプローチは、受信したリクエストの数やコピーする必要がある AWS Service Catalog 製品の数に応じてスケーリングできる Lambda 関数を使用することでスケーリングできます。このプロパティに関する詳細については、AWS Lambda 開発者ガイドの[AWS Lambda 関数スケーリング](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html)を参照してください。

## ツール
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-tools"></a>
+ 「[AWS コマンドラインインターフェイス (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) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、では、AWS で承認された IT サービスのカタログを一元管理できます。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。

**コード**

` cross-account-copy` パッケージ (添付済み) を使用して、アカウント間で AWS Service Catalog 製品をコピーするか、 `cross-region-copy` パッケージ (添付) を使用してリージョン間で製品をコピーできます。

`cross-account-copy` パッケージには以下のファイルが含まれています。
+ `copyconf.properties` — アカウント間で製品をコピーするためのリージョンと AWS アカウント ID パラメータを含む設定ファイル。
+ `scProductCopyLambda.py` — アカウント間で製品をコピーするための Python 関数。
+ `createDestAccountRole.sh` — 宛先アカウントに IAM ロールを作成するスクリプト。
+ `createSrcAccountRole.sh` — ソースアカウントに IAM ロールを作成するスクリプト。
+ `copyProduct.sh` — アカウント間で製品をコピーするための Lambda 関数を作成し、呼び出すスクリプトです。

`cross-region-copy`パッケージには以下のファイルが含まれています。
+ `copyconf.properties` — リージョン間で製品をコピーするためのリージョンと AWS アカウント ID パラメータを含む設定ファイル。
+ `scProductCopyLambda.py` — リージョン間で製品をコピーするための Python 関数。
+ `copyProduct.sh` — IAM ロールを作成し、リージョン間で製品をコピーするための Lambda 関数を作成して呼び出すスクリプト。

## エピック
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-epics"></a>

### オプション 1 — アカウント間で AWS Service Catalog 製品をコピー
<a name="option-1-ndash-copy-aws-service-catalog-products-across-accounts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  設定ファイルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| ソースアカウントで AWS CLI の認証情報を設定します。 | `aws configure` コマンドを実行して次の値を指定して、宛先アカウントで AWS CLI にアクセスするための認証情報を設定します。<pre>$aws configure <br />AWS Access Key ID [None]: <your_access_key_id> <br />AWS Secret Access Key [None]: <your_secret_access_key> <br />Default region name [None]: Region<br />Default output format [None]:</pre>詳細については、AWS コマンドラインインターフェイスドキュメントの[設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) を参照してください。  | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| ソースアカウントで AWS CLI の認証情報を設定します。 | `aws configure` コマンドを実行して次の値を指定して、ソースアカウントで AWS CLI にアクセスするための認証情報を設定します。 <pre>$aws configure<br />AWS Access Key ID [None]: <your_access_key_id><br />AWS Secret Access Key [None]: <your_secret_access_key><br />Default region name [None]: Region<br />Default output format [None]:</pre>詳細については、AWS コマンドラインインターフェイスドキュメントの[設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) を参照してください。  | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| 宛先アカウントで Lambda 実行ロールを作成します。 | `createDestAccountRole.sh ` 移行先アカウントでスクリプトを実行します。スクリプトには、以下のアクションが含まれます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| ソースアカウントにクロスアカウント IAM ロールを作成します。 | `createSrcAccountRole.sh ` ソースアカウントでスクリプトを実行します。スクリプトには、以下のアクションが実施されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| 移行先のアカウントで CopyProduct スクリプトを実行します。 |  `copyProduct.sh ` 移行先アカウントでスクリプトを実行します。スクリプトには、以下のアクションが実施されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 

### オプション 2 — ソースリージョンからターゲットリージョンに AWS Service Catalog 製品をコピー
<a name="option-2-ndash-copy-aws-service-catalog-products-from-a-source-region-to-a-destination-region"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  設定ファイルを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| AWS 認証情報で CLI を設定します。 |  `aws configure` コマンドを実行して次の値を指定して、ソースアカウントで AWS CLI にアクセスするための認証情報を設定します。<pre>$aws configure<br />AWS Access Key ID [None]: <your_access_key_id><br />AWS Secret Access Key [None]: <your_secret_access_key><br />Default region name [None]: Region<br />Default output format [None]:</pre>詳細については、AWS コマンドラインインターフェイスドキュメントの[設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) を参照してください。  | AWS 管理者、クラウド管理者、AWS システム管理者 | 
| CopyProductスクリプトを実行します。 | 移行先リージョンで `copyProduct.sh` スクリプトを実行します。スクリプトには、以下のアクションが実施されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions.html) | AWS 管理者、クラウド管理者、AWS システム管理者 | 

## 関連リソース
<a name="copy-aws-service-catalog-products-across-different-aws-accounts-and-aws-regions-resources"></a>
+ [Lambda 実行ロールを作成](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) (AWS Lambda ドキュメント)
+ [ラムダ関数を作成](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-awscli.html) (AWS Lambda ドキュメント)
+ [AWS Service Catalog API リファレンス](https://docs.aws.amazon.com/servicecatalog/latest/dg/API_Operations_AWS_Service_Catalog.html)
+ [AWS Service Catalog ドキュメント](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/what-is_concepts.html)

## アタッチメント
<a name="attachments-7ede5d17-89eb-4455-928f-6953d145ac9f"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、[attachment.zip](samples/p-attach/7ede5d17-89eb-4455-928f-6953d145ac9f/attachments/attachment.zip) ファイルを解凍してください。

# クラウド運用モデルの RACI または RASCI マトリックスを作成
<a name="create-a-raci-or-rasci-matrix-for-a-cloud-operating-model"></a>

*Amazon Web Services、Teddy Germade、Jerome Descreux、Florian Leroux、および Josselin LE MINEUR*

## 概要
<a name="create-a-raci-or-rasci-matrix-for-a-cloud-operating-model-summary"></a>

Cloud Center of Excellence (CCoE) またはCEE（クラウドイネーブルメントエンジン）は、クラウドの運用準備にフォーカスして、権限を与えられ、説明責任を果たせるチームです。彼らの主なフォーカスは、情報IT組織をオンプレミスの運用モデルからクラウドの運用モデルに変革することです。CCoE は、インフラストラクチャ、アプリケーション、運用、セキュリティの代表者を含む部門横断型のチームです。

クラウド運用モデルの主要コンポーネントの 1 つは *RACI マトリックス* または *RASCI マトリックス*.です。このデータを使用して、移行活動とクラウド運用に関わるすべての関係者の役割と責任を定義します。マトリックスの名前は、マトリックスで定義されている責任の種類、すなわち責任(R)、説明責任(A)、サポート(S)、協議(C)、情報提供(I)に由来します。サポートタイプは任意です。これを含める場合、 *RASCI マトリックス*と呼ばれ、サポートを除外すると、 *RACI マトリックス*と呼ばれます。

添付のテンプレートから始めれば、CCoE チームは組織の RACI または RASCI マトリックスを作成できます。テンプレートには、クラウド運用モデルに共通するチーム、役割、タスクが含まれています。このマトリックスの基礎は、運用統合と CCoE 機能に関連するタスクです。ただし、組織の構造やユースケースのニーズに合わせてこのテンプレートをカスタマイズできます。

RACI マトリックスの実装には制限はありません。このアプローチでは、大規模な組織、新興企業、およびその間のあらゆる組織に有効です。小規模な組織では、同じリソースが複数の役割を担うことがあります。

## エピック
<a name="create-a-raci-or-rasci-matrix-for-a-cloud-operating-model-epics"></a>

### マトリックスを作成
<a name="create-the-matrix"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 主要な利害関係者を識別します。 | クラウド運用モデルの戦略的目標に関連する主要なサービスマネージャーとチームマネージャーを識別します。 | プロジェクトマネージャー | 
| マトリックステンプレートをカスタマイズします。 | [添付ファイル](#attachments-b3df3d2c-c596-4736-bbaa-8edbcf335352) セクションでテンプレートをダウンロードし、RACI または RASCI マトリックスを次のように更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html) | プロジェクトマネージャー | 
| 会議の計画を立てます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html) | プロジェクトマネージャー | 
| マトリックスを完成します。 | すべての利害関係者との会議では、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html) | プロジェクトマネージャー | 
| RASCI マトリックスを共有します。 | RACI または RASCI マトリックスが完成した後、経営陣の承認を取得します。すべての利害関係者がアクセスできる共有リポジトリまたは一元的な場所に保存します。マトリックスの改訂を記録して承認するには、標準の文書管理プロセスを使用することを推薦します。 | プロジェクトマネージャー | 

## 関連リソース
<a name="create-a-raci-or-rasci-matrix-for-a-cloud-operating-model-resources"></a>
+ [AWS責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)

## アタッチメント
<a name="attachments-b3df3d2c-c596-4736-bbaa-8edbcf335352"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/b3df3d2c-c596-4736-bbaa-8edbcf335352/attachments/attachment.zip)」

# Amazon CloudWatch 異常検知により、カスタムメトリクスのアラームを作成
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection"></a>

*Ram Kandaswamy および Raheem Jiwani、Amazon Web Services*

## 概要
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-summary"></a>

Amazon Web Services (AWS) クラウドでは、Amazon CloudWatch を使用して、メトリクスをモニタリングし、閾値を超えたときに通知を送信し、またはアラームを自動的に変更するアラームを作成できます。

「[静的な閾値](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」による制限を避けるため、過去のパターンに基づいてアラームを作成し、特定のメトリックスが通常の運用時間外になった場合に通知するようにできます。例えば、Amazon API Gateway から API の応答時間をモニタリングし、サービスレベルアグリーメント (SLA) を満たすことを妨げる異常に関する通知を受信することができます。

このパターンは、CloudWatch 異常検出により、カスタムメトリックスを使用する方法を説明します。このパターンは、Amazon CloudWatch Logs Insights でカスタムメトリクスを作成する方法、または AWS Lambda 関数によりカスタムメトリックスを公開する方法を示しています。次に、Amazon Simple Notiﬁcation Service (Amazon SNS) により、異常検出を設定し、通知を作成する方法を示しています。

## 前提条件と制限事項
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ SNS トピックは、電子メール通知を送信するように設定できます。詳細については、Amazon SNS ドキュメントの「[Amazon SNS の使用開始](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)」を参照してください。
+ 「[CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)」で設定された既存のアプリケーション。

**制限事項**
+ CloudWatch メトリックスはミリ秒の時間間隔をサポートしていません。レギュラーメトリクスとカスタムメトリクスの粒度の詳細については、「[Amazon CloudWatchのよくある質問](https://aws.amazon.com/cloudwatch/faqs/)」を参照してください。

## アーキテクチャ
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-architecture"></a>

![\[CloudWatch は Amazon SNS トピックを使用して、アラームの開始時に E メール通知を送信します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d47e6f7f-e469-4cb9-b34b-8c4b78d71820/images/49f30340-9552-430a-893a-d0608bb09e38.png)


 この図表は、次のワークフローを示しています:

1. CloudWatch Logs により作成し、更新されたメトリックスを使用するログは CloudWatch にストリーミングされます。

1. アラームは閾値に基づき開始され、SNS トピックにアラートを送信します。

1. Amazon SNS からメール通知が送信されます。

テクノロジースタック
+ CloudWatch
+ AWS Lambda
+ Amazon SNS

## ツール
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-tools"></a>
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、信頼性、スケーラビリティ、および柔軟性に優れたモニタリングソリューションを提供します。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーを準備したり管理したりしなくてもコードを実行できるコンピューティングサービスです。
+ [Amazon Simple Notiﬁcation Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、パブリッシャーからサブスクライバーへのメッセージ配信を提供するマネージドサービスです。

## エピック
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-epics"></a>

### カスタムメトリクスの異常検知を設定
<a name="set-up-anomaly-detection-for-a-custom-metric"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| オプション 1-Lambda 関数により、カスタムメトリクスを作成します。 | `lambda_function.py` ファイル (添付) をダウンロードして、「AWS Documentation GitHub」で「[aws-lambda-developer-guide](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-python/function)」リポジトリにあるサンプル `lambda_function.py` ファイルを置き換えます。これにより、カスタムメトリクスを CloudWatch Logs に送信するサンプル Lambda 関数が得られます。Lambda 関数は Boto3 API により、CloudWatch と統合します。 Lambda 関数を実行した後、AWS マネジメントコンソールにサインインして CloudWatch コンソールを開くと、公開されたメトリクスは公開された名前空間で使用できます。 | DevOps エンジニア、AWS DevOps | 
| オプション 2 — CloudWatch ロググループからカスタムメトリックスを作成します。 | AWS マネジメントコンソールにサインインし、CloudWatch コンソールを開いて、**[ロググループ]** を選択します。メトリックを作成するロググループを選択します。 **[アクション]** と **[メトリクスフィルターの作成]** を順に選択します。**[フィルターパターン]** に、使用するフィルターパターンを入力します。詳細については、CloudWatch ドキュメントの「[フィルターとパターンの構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)」を参照してください。 フィルターパターンをテストするには、**[テストパターン]** に 1 つ以上のログイベントを入力します。**[ログイベントメッセージ]** ボックスのログイベントを区切るために改行が使用されるため、各ログイベントは 1 行以内である必要があります。パターンをテストしたら、**[メトリクスの詳細]** にメトリクスの名前と値を入力できます。 カスタムメトリクスを作成する手順と詳細については、「CloudWatch のドキュメント」の「[ロググループのメトリクスフィルターの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)」を参照してください。 | DevOps エンジニア、AWS DevOps | 
| カスタムメトリクスのアラームを作成します。 | CloudWatch コンソールで **[アラーム]** と **[アラームの作成]** を順に選択します。**[メトリクスの選択]** をクリックし、前に作成したメトリクスの名前を検索ボックスに入力します。**[グラフ化したメトリクス]** タブを選び、要件に応じてオプションを設定します。**[条件]** で、**[静的閾値]** の代わりに **[異常検知]** を選択します。これにより、2 つの標準デフォルト偏差に基づくバンドが表示されます。要件に応じて、閾値を設定できます。**[次へ]** を選択します。バンドは動的で、データポイントの質によって異なります。さらにデータを集約し始めると、バンドと閾値は自動的に更新されます。  | DevOps エンジニア、AWS DevOps | 
| SNS 通知のセットアップ | **[通知]** で、アラームが `ALARM` 状態、`OK` 状態、または `INSUFFICIENT_DATA` 状態のときに通知する SNS トピックを選択します。同じアラーム状態または複数の異なるアラーム状態について複数の通知を送信するには、**[Add notification (通知の追加)]** を選択します。**[次へ]** を選択します。アラームの名前と説明を入力します。名前には ASCII 文字のみを含める必要があります。次いで、**[次へ]** を選択します。**[プレビューと作成]** で、情報と条件が正しいことを確認し、**[アラームの作成]** を選択します。 | DevOps エンジニア、AWS DevOps | 

## 関連リソース
<a name="create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection-resources"></a>
+ 「[カスタムメトリクスの CloudWatch への公開](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」
+ 「[CloudWatch 異常検出の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)」
+ 「[アラームイベントと Amazon EventBridge](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html)」
+ 「[Cloud Watch にカスタムメトリクスをプッシュする際に従うべきベストプラクティスにはどのようなものですか?](https://www.youtube.com/watch?v=mVffHIzIL60)」(ビデオ)
+ 「[CloudWatch Application Insightsの紹介](https://www.youtube.com/watch?v=PBO636_t9n0)」(ビデオ)
+ 「[CloudWatch による異常検知](https://www.youtube.com/watch?v=8umIX-pUy3k)」(ビデオ)

## アタッチメント
<a name="attachments-d47e6f7f-e469-4cb9-b34b-8c4b78d71820"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/d47e6f7f-e469-4cb9-b34b-8c4b78d71820/attachments/attachment.zip)」

# デフォルトの暗号化で Amazon EBS ボリュームを使用する AWS Cloud9 IDE を作成
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption"></a>

*Amazon Web Services、Janardhan Malyala および Dhrubajyoti Mukherjee*

## 概要
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-summary"></a>

**注意**: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)

「[デフォルトで暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)」を使用して、Amazon Elastic Block Store (Amazon EBS) ボリュームとAmazon Web Services (AWS) クラウド上のスナップショットコピーを強制的に暗号化できます。 

デフォルトで暗号化された EBS ボリュームを使用する AWS Cloud9 統合開発環境 (IDE) を作成できます。ただし、AWS Cloud9 の AWS Identity and Access Management (IAM)「[サービスにリンクされたロールには](https://docs.aws.amazon.com/cloud9/latest/user-guide/using-service-linked-roles.html)」、これらの EBS ボリュームの AWS Key Management Service (AWS KMS) キーにアクセスする必要があります。アクセスが提供されない場合、AWS Cloud9 IDE の起動に失敗し、デバッグが困難になる場合があります。 

このパターンでは、EBS ボリュームで使用される AWS KMS キーにAWS Cloud9のサービスにリンクされたロールを追加する手順を提供します このパターンでデフォルトで暗号化された EBS ボリュームを使用する IDE を正常に作成し、起動するための設定を説明します。

## 前提条件と制限事項
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ EBS ボリュームではデフォルトの暗号化が有効になっています。デフォルトの暗号化の詳細については、「Amazon Elastic Compute Cloud (Amazon EC2) のドキュメント」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)」を参照してください。
+ EBS ボリュームを暗号化するための既存「[カスタマーマネージド KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」。

**注記**  
AWS Cloud9 用のサービスにリンクされたロールを作成する必要はありません。AWS Cloud9 開発環境を作成すると、AWS Cloud9 によってサービスにリンクされたロールが作成されます。

## アーキテクチャ
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-architecture"></a>

![\[AWS Cloud9 IDE を使用して EBS ボリュームとスナップショットの暗号化を実施します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/dd98fbb4-0949-4299-b701-bc857e13049c/images/6b22b8d1-75d9-4f06-b5d6-5fff7397f22d.png)


**テクノロジースタック**
+ AWS Cloud9
+ IAM
+ AWS KMS

## ツール
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-tools"></a>
+ 「[AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)」は、ソフトウェアのコーディング、ビルド、実行、テスト、およびデバッグを支援する統合開発環境 (IDE) です。また、ソフトウェアを AWS クラウドにリリースするのにも役立ちます。
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで使用するブロックレベルストレージのボリュームを提供します。
+ 「[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) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。

## エピック
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-epics"></a>

### デフォルトの暗号化キー値を検索
<a name="find-the-default-encryption-key-value"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| EBS ボリュームのデフォルトの暗号化キー値を記録します。 | AWS マネジメントコンソールにサインインし、Amazon SNS コンソールを開きます。**[EC2 ダッシュボード]** を選択後、**[アカウントの属性]** で **[データ保護とセキュリティ]** を選択します。**[EBS 暗号化]** セクションで、**[デフォルトの暗号化キー]** の値をコピーして記録します。 | クラウドアーキテクト、DevOps エンジニア | 

### AWS KMS キーへのアクセスを提供
<a name="provide-access-to-the-aws-kms-key"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS Cloud9 に EBS ボリュームの KMS キーへのアクセスを提供します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption.html)キーポリシー更新の詳細については、「[キーポリシーを変更する方法](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-how-to)」(AWS KMS のドキュメント)を参照してください。AWS Cloud9 のサービスにリンクされたロールは、最初の IDE を起動したときに自動的に作成されます。詳細については、「AWS Cloud9 のドキュメント」の「[サービスにリンクされたロールの作成](https://docs.aws.amazon.com/cloud9/latest/user-guide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。  | クラウドアーキテクト、DevOps エンジニア | 

### IDE を作成して起動
<a name="create-and-launch-the-ide"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS Cloud9 IDE を作成し、起動します。 | AWS Cloud9 コンソールを開き、**[環境を作成]** を選択します。****AWS Cloud9 ドキュメントの「[EC2 環境を作成する](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment-main.html)」の手順に従い、要件に応じて IDE を設定します。  | クラウドアーキテクト、DevOps エンジニア | 

## 関連リソース
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-resources"></a>
+ 「[AWS Cloud9 に使用される EBS ボリュームを暗号化する](https://docs.aws.amazon.com/cloud9/latest/user-guide/move-environment.html#encrypting-volumes)」
+ 「[AWS Cloud9 のサービスにリンクされたロールの編集](https://docs.aws.amazon.com/cloud9/latest/user-guide/using-service-linked-roles.html#create-service-linked-role)」
+ 「[AWS Cloud9 に EC2 環境の作成](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment-main.html)」

## 追加情報
<a name="create-an-aws-cloud9-ide-that-uses-amazon-ebs-volumes-with-default-encryption-additional"></a>

AWS KMS キーポリシーの更新

`<aws_accountid>` は自分の AWS アカウント ID に置き換えます。

```
{
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<aws_accountid>:role/aws-service-role/cloud9.amazonaws.com/AWSServiceRoleForAWSCloud9"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<aws_accountid>:role/aws-service-role/cloud9.amazonaws.com/AWSServiceRoleForAWSCloud9"
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        }
```

**クロスアカウントキーを使用する**

クロスアカウント KMS キーを使用する場合は、KMS キーポリシーと組み合わせて権限を使用する必要があります。これにより、キーへのクロスアカウントアクセスが可能になります。Cloud9 環境の作成に使用したアカウントと同じアカウントを使用し、ターミナルで次のコマンドを実行します。

```
aws kms create-grant \
 --region <Region where Cloud9 environment is created> \
 --key-id <The cross-account KMS key ARN> \
 --grantee-principal arn:aws:iam::<The account where Cloud9 environment is created>:role/aws-service-role/cloud9.amazonaws.com/AWSServiceRoleForAWSCloud9 \
 --operations "Encrypt" "Decrypt" "ReEncryptFrom" "ReEncryptTo" "GenerateDataKey" "GenerateDataKeyWithoutPlaintext" "DescribeKey" "CreateGrant"
```

このコマンドを実行したら、別のアカウントのキーで EBS 暗号化を使用して Cloud9 環境を作成できます。

# タグベースの Amazon CloudWatch ダッシュボードを自動的に作成する
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically"></a>

*Amazon Web Services、Janak Vadaria、Vinodkumar Mandalapu、RAJNEESH TYAGI*

## 概要
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-summary"></a>

さまざまな Amazon CloudWatch ダッシュボードを手動で作成すると、特に環境を自動的にスケールするために複数のリソースを作成および更新する必要がある場合、時間がかかることがあります。CloudWatch ダッシュボードを自動的に作成および更新するソリューションを使用すると、時間を節約できます。このパターンは、タグ変更イベントに基づいて AWS リソースの CloudWatch ダッシュボードを作成および更新する完全自動化された AWS Cloud Development Kit (AWS CDK) パイプラインをデプロイして、Golden Signals メトリクスを表示するのに役立ちます。

サイト信頼性エンジニアリング (SRE) では、Golden Signals は、ユーザーまたは消費者の観点からサービスの広範な視点を提供する包括的なメトリックのセットを指します。これらのメトリックは、遅延時間、通信量、エラー、飽和度で構成されます。詳細については、 AWS ウェブサイトの[「サイト信頼性エンジニアリング (SRE) とは](https://aws.amazon.com/what-is/sre/)」を参照してください。

このパターンが提供するソリューションは、イベント駆動型です。ソルーションの展開後、タグ変更イベントを継続的にモニタリングし、CloudWatch ダッシュボードとアラームを自動的に更新します。

## 前提条件と制限事項
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-prereqs"></a>

** 前提条件 **
+ アクティブな AWS アカウント
+ AWS Command Line Interface (AWS CLI)、[インストールおよび設定](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)済み
+ v2 AWS CDK [の前提条件](https://docs.aws.amazon.com/cdk/v2/guide/work-with.html#work-with-prerequisites) 
+ の[ブートストラップされた環境](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) AWS
+ [Python バージョン 3](https://www.python.org/downloads/)
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html)、インストール済み
+ [Node.js](https://nodejs.org/en/download/current) バージョン 18 以降
+ 用に[インストールおよび設定された](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)ノードパッケージマネージャー (npm) AWS CDK
+  AWS CDK および に関する中程度 (レベル 200) の知識 AWS CodePipeline

**制限事項**

このソリューションは現在、次の AWS サービスのみに対して自動ダッシュボードを作成します。
+ [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/)
+ [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)
+ [AWS Lambda](https://aws.amazon.com/lambda/)

## アーキテクチャ
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-architecture"></a>

**ターゲットテクノロジースタック**
+ [CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)

**ターゲットアーキテクチャ**

![\[タグベースの CloudWatch ダッシュボードを作成するためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/f234fe30-87db-446f-a291-d33928ca2ccb/images/f63ca697-f252-416d-8a1b-0239f38c10c5.png)


1. 設定されたアプリケーション AWS タグまたはコード変更のタグ変更イベントは、更新された CloudWatch ダッシュボードを構築およびデプロイ AWS CodePipeline するためのパイプラインを で開始します。

1. AWS CodeBuild は Python スクリプトを実行してタグを設定したリソースを検索し、リソース IDs を CodeBuild 環境のローカルファイルに保存します。

1. CodeBuild は **cdk 同期**を実行して、CloudWatch ダッシュボードとアラームをデプロイする CloudFormation テンプレートを生成します。

1. CodePipeline は、指定された AWS アカウント およびリージョンに CloudFormation テンプレートをデプロイします。

1.  CloudFormation スタックが正常にデプロイされると、CloudWatch ダッシュボードとアラームを表示できます。

**自動化とスケール**

このソリューションは、 を使用して自動化されています AWS CDK。このコードは、GitHub の「[Amazon CloudWatch の Golden Signals ダッシュボード](https://github.com/aws-samples/golden-signals-dashboards-sample-app)」リポジトリにあります。追加のスケーリングとカスタムダッシュボードを作成するために、複数のタグキーと値を設定できます。

## ツール
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-tools"></a>

**Amazon サービス**
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/) は、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなど、さまざまなソースからのリアルタイムデータにアプリケーションを接続するのに役立つサーバーレスイベントバスサービスです AWS アカウント。
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/) は、ソフトウェアリリースのさまざまなステージを迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/) は完全な管理型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐに展開できるアーティファクトの生成に役立ちます。
+ [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://aws.amazon.com/iam/) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。

## ベストプラクティス
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-best-practices"></a>

安全に関する最良の手法として、パイプラインに接続するソースリポジトリには暗号化と認証が使用できます。その他の最良の手法については、「CodePipeline ドキュメント」の「[CodePipeline のベストプラクティスとユースケース](https://docs.aws.amazon.com/codepipeline/latest/userguide/best-practices.html)」を参照してください。

## エピック
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-epics"></a>

### サンプルアプリケーションを設定して展開する
<a name="configure-and-deploy-the-sample-application"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| サンプルアプリケーションを設定して展開する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-tag-based-amazon-cloudwatch-dashboards-automatically.html) | AWS DevOps | 
| ダッシュボードとアラームを自動的に作成する。 | サンプルアプリケーションを展開した後、このソリューションが対応する任意のリソースを予定したタグ値で作成できます。これにより、指定したダッシュボードとアラームが自動的に作成されます。このソリューションをテストするには、 AWS Lambda 関数を作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-tag-based-amazon-cloudwatch-dashboards-automatically.html) | AWS DevOps | 

### サンプルアプリケーションを削除する
<a name="remove-the-sample-application"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| `golden-signals-dashboard` コンストラクトを削除する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-tag-based-amazon-cloudwatch-dashboards-automatically.html) | AWS DevOps | 

## トラブルシューティング
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| Python コマンドが見つかりません (`findresources.sh` の 8 行目を参照)。 | Python インストールのバージョンを確認します。Python バージョン 3 をインストールしている場合は、`resources.sh` ファイルの 8 行目で `python` を `python3` に置き換え、`sh deploy.sh` コマンドを再度実行してソリューションを展開します。 | 

## 関連リソース
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-resources"></a>
+ [ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) (AWS CDK ドキュメント)
+ [名前付きプロファイルの使用](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods) (AWS CLI ドキュメント)
+ [AWS CDK ワークショップ](https://cdkworkshop.com/)

## 追加情報
<a name="create-tag-based-amazon-cloudwatch-dashboards-automatically-additional"></a>

次の図は、このソリューションの一部として作成された Amazon RDS のサンプルダッシュボードを示しています。

![\[Amazon RDS のサンプルダッシュボード\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/f234fe30-87db-446f-a291-d33928ca2ccb/images/706a262f-8650-47ff-ac44-e04ce5f4023e.png)


# AWS のランディングゾーンの設計を文書化する
<a name="document-your-aws-landing-zone-design"></a>

*Amazon Web Services、Michael Daehnert、Florian Langer、および Michael Lodemann*

## 概要
<a name="document-your-aws-landing-zone-design-summary"></a>

*ランディングゾーン*は、セキュリティとコンプライアンスのベストプラクティスに基づく、優れたアーキテクチャ設計のマルチアカウント環境です。これは、すべての組織単位 (OUs) AWS アカウント、ユーザー、およびその他のリソースを保持するエンタープライズ全体のコンテナです。ランディングゾーンは、あらゆる規模のエンタープライズのニーズに合わせてスケーリングできます。 AWS には、 を使用するサービスベースのランディングゾーン[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)と、構築するカスタマイズされたランディングゾーンの 2 つのオプションがあります。オプションごとに異なるレベルの AWS 知識が必要です。

AWS ランディングゾーンのセットアップを自動化することで時間を節約 AWS Control Tower するために作成された 。 AWS Control Tower は によって管理 AWS され、 のベストプラクティスとガイドラインを使用して基盤環境を作成します。 は、 [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)や などの統合サービス AWS Control Tower を使用してランディングゾーンにアカウントをプロビジョニングし[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)、それらのアカウントへのアクセスを管理します。

AWS ランディングゾーンプロジェクトは、要件、実装の詳細、運用アクション項目によって異なります。ランディングゾーンの実装ごとに処理する必要があるカスタマイズがあります。これには、アクセス管理の処理方法、使用するテクノロジースタック、運用における優秀性のモニタリング要件の詳細が含まれます (ただし、これらに限定されません)。このパターンでは、ランディングゾーンプロジェクトを文書化するのに役立つテンプレートを提供します。テンプレートを使用すると、プロジェクトをより迅速に文書化でき、開発チームと運用チームにランディングゾーンを理解してもらいやすくなります。

## 前提条件と制限事項
<a name="document-your-aws-landing-zone-design-prereqs"></a>

**制限事項**

このパターンは、ランディングゾーンの詳細や、ランディングゾーンの実装方法を説明するものではありません。これらのトピックの詳細については、「[関連リソース](#document-your-aws-landing-zone-design-resources)」セクションを参照してください。

## エピック
<a name="document-your-aws-landing-zone-design-epics"></a>

### 設計ドキュメントを作成する
<a name="create-the-design-document"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 主要な利害関係者を特定する。 | ランディングゾーンにリンクされている主要なサービスとチームマネージャーを特定します。 | プロジェクトマネージャー | 
| テンプレートをカスタマイズする。 | 「[添付ファイル](#attachments-9e39a05a-8f51-4fe3-8999-522feafed6ca)」セクションでテンプレートをダウンロードし、テンプレートを次のように更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/document-your-aws-landing-zone-design.html) | プロジェクトマネージャー | 
| テンプレートを完了する。 | ステークホルダーとの会議で、または write-and-review プロセスを使用して、次のようにテンプレートを完了します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/document-your-aws-landing-zone-design.html) | プロジェクトマネージャー | 
| 設計ドキュメントを共有する。 | ランディングゾーンの設計ドキュメントが完了したら、すべてのステークホルダーがアクセスできる共有リポジトリまたは一元的保管場所に保存します。設計ドキュメントの改訂を記録して承認するには、標準の文書管理プロセスを使用することをお勧めします。 | プロジェクトマネージャー | 

## 関連リソース
<a name="document-your-aws-landing-zone-design-resources"></a>
+ [AWS Control Tower ドキュメント](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
  + [AWS Control Tower ランディングゾーンを計画する](https://docs.aws.amazon.com/controltower/latest/userguide/planning-your-deployment.html)
  + [AWSAWS Control Tower ランディングゾーンのマルチアカウント戦略](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)
  + [ランディングゾーンのセットアップに関する管理上のヒント](https://docs.aws.amazon.com/controltower/latest/userguide/tips-for-admin-setup.html)
  + [ランディングゾーン設定の期待値](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-configure.html)
+ (AWS ソリューションライブラリ) [のカスタマイズ AWS Control Tower](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 
+ [安全でスケーラブルなマルチアカウント AWS 環境のセットアップ](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/welcome.html) (AWS 規範ガイダンス)

## アタッチメント
<a name="attachments-9e39a05a-8f51-4fe3-8999-522feafed6ca"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/9e39a05a-8f51-4fe3-8999-522feafed6ca/attachments/attachment.zip)」

# AWS CDK を使用して複数の AWS リージョン、アカウント、OU にわたって Amazon DevOps Guru を有効にすることで、運用パフォーマンスを向上させます。
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk"></a>

*Amazon Web Services、Dr. Rahul Sharad Gaikwad*

## 概要
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-summary"></a>

このパターンは、TypeScript の AWS Cloud Development Kit (AWS CDK) を使用して、複数のAmazon Web Services (AWS) リージョン、アカウント、および組織単位 (OU) にわたって Amazon DevOps Guru サービスを有効にする手順を示しています。各アカウントにログインしてアカウントごとに個別に DevOps Guru を有効にする代わりに、AWS CDK スタックを使用して管理者 (プライマリ) AWS アカウントから AWS CloudFormation StackSets をデプロイし、複数のアカウントで Amazon DevOps Guru を有効にすることができます。

Amazon DevOps Guru は、アプリケーションの可用性を向上させ、運用上の問題をより迅速に解決するのに役立つ人工知能運用 (AIOps) 機能を提供します。DevOps Guru は、機械学習 (ML) を活用したレコメンデーションを適用することで、機械学習の専門知識を必要とせずに手作業を軽減します。DevOps Guru はリソースと運用データを分析します。異常を検出すると、問題への対処に役立つ指標、イベント、および推奨事項が表示されます。

このパターンでは、Amazon DevOps Guru を有効にするための 3 つのデプロイオプションについて説明します。
+ 複数のアカウントとリージョンですべてのスタックリソース用
+ OU のすべてのスタックリソース用
+ 複数のアカウントとリージョンで特定のスタックリソース用

## 前提条件と制限
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-prereqs"></a>

**前提条件**
+ アクティブなAWS アカウント
+ AWS コマンドラインインターフェイス (AWS CLI)は、「インストール」および「設定」されています。(AWS CLI ドキュメントの「[AWS CLI のインストール、更新、アンインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください)。
+ AWS CDK ツールキット、インストールおよび設定 ([AWS CDK ドキュメントの AWS CDK ツールキットを参照してください](https://docs.aws.amazon.com/cdk/latest/guide/cli.html))。
+ ノードPackage マネージャー (npm)。TypeScript で AWS CDK 用にインストールおよび構成されています。詳細については、npm ドキュメントの [[Node.js と npm のダウンロードとインストール]](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) を参照してください。
+ Python3 をインストールして設定し、Python スクリプトを実行してサンプルのサーバーレスアプリケーションにトラフィックを注入します。([Python ドキュメントの「Python の設定と使用方法](https://docs.python.org/3/using/index.html)」を参照してください)。
+ Pip、Python リクエストライブラリをインストールするようにインストールおよび設定されています。(PyPL Web サイトの「[pip インストール手順](https://pypi.org/project/pip/)」を参照してください)。

**製品バージョン**
+ AWS CDK ツールキットバージョン 1.107.0 またはそれ以降
+  バージョン 7.9.0 以降
+ Node.js バージョン 15.3.0 以降

## アーキテクチャ
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-architecture"></a>

**テクノロジー**

このパターンのアーキテクチャには以下のサービスが含まれます。
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)

**AWS CDK スタック**

このパターンでは、次の AWS CDK スタックを使用します。 
+ `CdkStackSetAdminRole`— AWS Identity and Access Management (IAM) 管理者ロールを作成して、管理者とターゲットアカウントの間に信頼関係を確立します。
+ `CdkStackSetExecRole`— 管理者アカウントを信頼する IAM ロールを作成します。
+ `CdkDevopsGuruStackMultiAccReg`— すべてのスタックで DevOps Guru を有効にし、すべてのスタックで DevOps Guru を有効にし、Amazon Simple Notiﬁcation Service (Amazon SNS) 通知を設定します。
+ `CdkDevopsGuruStackMultiAccRegSpecStacks`— 特定のスタックの複数の AWS リージョンとアカウントで DevOps Guru を有効にし、Amazon SNS 通知を設定します。
+ `CdkDevopsguruStackOrgUnit`— 複数の OU で DevOps Guru を有効にし、Amazon SNS 通知を設定します。 
+ `CdkInfrastructureStack`— API ゲートウェイ、Lambda、DynamoDB などのサンプルサーバーレスアプリケーションコンポーネントを管理者アカウントにデプロイして、フォールトインジェクションとインサイト生成を実演します。

**サンプルアプリケーションのアーキテクチャ**

次の図は、複数のアカウントとリージョンでデプロイされたサンプルサーバーレスアプリケーションのアーキテクチャを示しています。このパターンでは、管理者アカウントを使用してすべての AWS CDK スタックをデプロイします。また、管理者アカウントを DevOps Guru をセットアップするためのターゲットアカウントの 1 つとして使用します。

1. DevOps Guru を有効にすると、まず各リソースの動作のベースラインを設定し、次に CloudWatch が販売するメトリクスから運用データを取り込みます。

1. 異常を検出すると、CloudTrail からのイベントと関連付けてインサイトを生成します。

1. このインサイトでは、相関関係のある一連のイベントと規定された推奨事項が提供されるため、オペレーターは犯人のリソースを特定できます。

1. Amazon SNS は通知メッセージをオペレータに送信します。

![\[複数のアカウントとリージョンでデプロイされたサンプルサーバーレスアプリケーション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6075ca48-862a-4aa0-93c6-10bad8195a5c/images/beeb0992-aaa8-4f08-b983-685b6b8b8d5e.png)


**自動化とスケール**

このパターンで提供される「[GitHub リポジトリ](https://github.com/aws-samples/amazon-devopsguru-cdk-samples.git)」は、AWS CDK をinfrastructure as code (IaC ツールとして使用して、このアーキテクチャの設定を作成します。AWS CDK は、リソースを調整し、複数の AWS アカウント、リージョン、OU にわたって DevOps Guru を有効にするのに役立ちます。

## ツール
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-tools"></a>

**AWS サービス**
+ [AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/home.html) — AWS Cloud Development Kit (AWS CDK) は、サポートされている 5 つのプログラミング言語 (TypeScript、JavaScript、Python、Java、C\$1) のいずれかのコードとしてクラウドインフラストラクチャを定義するのに役立ちます。
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) — AWS コマンドラインインターフェイス (AWS CLI) は、AWS のサービスやリソースを操作するための一貫したコマンドラインインターフェイスを提供する統合ツールです。

**コード**

このパターンのソースコードは、GitHub の「[Amazon DevOps Guru](https://github.com/aws-samples/amazon-devopsguru-cdk-samples.git)」CDK サンプルリポジトリにあります。AWS CDK コードはTypeScript で記述されています。リポジトリを複製して使用するには、次のセクションの指示に従います。

**重要**  
このパターンのストーリーには、UNIX、Linux、macOS 向けにフォーマットされた AWS CDK および AWS CLI コマンドの例が含まれています。Windows の場合は、各行末のバックスラッシュ (\$1) Unix 連結文字をキャレット (^) に置き換えてください。

## エピック
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-epics"></a>

### デプロイ用の AWS リソースの準備
<a name="prepare-the-aws-resources-for-deployment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS の名前付きプロファイルを設定します。 | マルチアカウント環境にスタックをデプロイするには、以下のように AWS の名前付きプロファイルを設定します。 管理者アカウントの変更<pre>$aws configure --profile administrator<br />AWS Access Key ID [****]: <your-administrator-access-key-ID><br />AWS Secret Access Key [****]: <your-administrator-secret-access-key><br />Default region name [None]: <your-administrator-region><br />Default output format [None]: json</pre>ターゲットアカウントの場合：<pre>$aws configure --profile target<br />AWS Access Key ID [****: <your-target-access-key-ID><br />AWS Secret Access Key [****]: <your-target-secret-access-key><br />Default region name [None]: <your-target-region><br />Default output format [None]: json</pre>詳細については、AWS CLI ドキュメントの「[名前を指定されたプロファイルを使用する](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles)」を参照してください。 | DevOps エンジニア | 
| AWS プロファイル設定を確認します。 | (オプション) AWS CLI ドキュメントの「[設定の設定と表示](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)」の手順に従って、`credentials`および`config`ファイル内の AWS プロファイル設定を確認できます。 | DevOps エンジニア | 
| AWS CDK のバージョンを確認してください。 | 次のコマンドを実行して、AWS CDK Toolkit のバージョンを確認します。<pre>$cdk --version</pre>このパターンには、バージョン 1.107.0 以降が必要です。以前のバージョンの AWS CDK を使用している場合は、「[AWS CDK ドキュメント](https://docs.aws.amazon.com/cdk/latest/guide/cli.html)」の指示に従って更新してください。 | DevOps エンジニア | 
| プロジェクトコードをクローニングします。 | 以下のコマンドを使用して、このパターンの GitHub リポジトリをクローンします。<pre>$git clone https://github.com/aws-samples/amazon-devopsguru-cdk-samples.git</pre> | DevOps エンジニア | 
| パッケージの依存関係をインストールし、TypeScript ファイルをコンパイルします。 | パッケージの依存関係をインストールし、次のコマンドを実行して TypeScript ファイルをコンパイルします。<pre>$cd amazon-devopsguru-cdk-samples<br />$npm install<br />$npm fund</pre>これらのコマンドは、すべてのパッケージをサンプルリポジトリからインストールします。パッケージが見つからないというエラーが表示される場合は、以下のいずれかのコマンドを使用してください。<pre>$npm ci</pre>または<pre>$npm install -g @aws-cdk/<package-name></pre>パッケージ名とバージョンのリストは、`/amazon-devopsguru-cdk-samples/package.json`ファイルの`Dependencies`セクションにあります。詳細については、npm ドキュメントの「[npm ci](https://docs.npmjs.com/cli/v7/commands/npm-ci)」と「[npm install](https://docs.npmjs.com/cli/v7/commands/npm-install)」を参照してください。 | DevOps エンジニア | 

### AWS CDK スタックをビルド (合成) する
<a name="build-synthesize-the-aws-cdk-stacks"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Amazon SNS 通知用の E メールアドレスを設定します。 | Amazon SNS 通知用の E メールアドレスを指定するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html) | DevOps エンジニア | 
| Go プロジェクトを構築します。 | 以下のコマンドを実行してプロジェクトコードをビルドし、スタックを合成します。<pre>npm run build && cdk synth </pre>次のような出力が表示されます: <pre>$npm run build && cdk synth<br />> cdk-devopsguru@0.1.0 build<br />> tsc<br />Successfully synthesized to ~/amazon-devopsguru-cdk-samples/cdk.out<br />Supply a stack id (CdkDevopsGuruStackMultiAccReg,CdkDevopsGuruStackMultiAccRegSpecStacks, CdkDevopsguruStackOrgUnit, CdkInfrastructureStack, CdkStackSetAdminRole, CdkStackSetExecRole) to display its template.</pre>詳細と手順については、AWS CDK ドキュメントの「[初めての AWS CDK アプリケーション](https://docs.aws.amazon.com/cdk/latest/guide/hello_world.html)」を参照してください。 | DevOps エンジニア | 
| AWS CDK スタックを一覧表示します。 | 以下のコマンドを実行して、全てのAWS CDK スタックをリストアップします。<pre>$cdk list</pre>コマンドによって、次のリストが表示されます。<pre>CdkDevopsGuruStackMultiAccReg<br />CdkDevopsGuruStackMultiAccRegSpecStacks<br />CdkDevopsguruStackOrgUnit<br />CdkInfrastructureStack<br />CdkStackSetAdminRole<br />CdkStackSetExecRole</pre> | DevOps エンジニア | 

### オプション 1-複数のアカウントのすべてのスタックリソースで DevOps Guru を有効にする
<a name="option-1---enable-devops-guru-for-all-stack-resources-across-multiple-accounts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM ロールを作成するための AWS CDK スタックをデプロイします。 | このパターンでは、「[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」を使用して複数のアカウントにわたってスタックオペレーションを実行します。初めてスタックセットを作成する場合は、次の IAM ロールを作成して、必要な権限を AWS アカウントに設定する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html)ロールにはこれらの正確な名前が必要です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html)詳細については、AWS CloudFormation ドキュメントの「[自己管理型のアクセス許可の承認](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html)」を参照してください。 | DevOps エンジニア | 
| 複数のアカウントで DevOps Guru を有効にするための AWS CDK スタックをデプロイします。 | AWS CDK `CdkDevopsGuruStackMultiAccReg` スタックは、複数のアカウントとリージョンにスタックインスタンスをデプロイするためのスタックセットを作成します。スタックをデプロイするには、指定されたパラメータを使用して次の CLI コマンドを実行します。<pre>$cdk deploy CdkDevopsGuruStackMultiAccReg \<br />  --profile administrator \<br />  --parameters AdministratorAccountId=<administrator-account-ID> \<br />  --parameters TargetAccountId=<target-account-ID> \<br />  --parameters RegionIds="<region-1>,<region-2>"</pre>現在、Amazon DevOps Guru は「[DevOps Guru に関するよくある質問](https://aws.amazon.com/devops-guru/faqs/)」に記載されている AWS リージョンでご利用いただけます。 | DevOps エンジニア | 

### オプション 2-OU 全体のすべてのスタックリソースで DevOps Guru を有効にする
<a name="option-2---enable-devops-guru-for-all-stack-resources-across-ous"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| OU ID を抽出します。 | 「[AWS Organizations](https://console.aws.amazon.com/organizations/v2/home/accounts)」コンソールで、DevOps Guru を有効にする組織ユニットの ID を特定します。 | DevOps エンジニア | 
| OU のサービス管理権限を有効にします。 | アカウント管理に AWS Organizations を使用している場合は、サービス管理のアクセス権限を付与して DevOps Guru を有効にする必要があります。IAM ロールを手動で作成する代わりに、「[組織ベースの信頼できるアクセスとサービスにリンクされたロール (SLR](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html)」) を使用してください。 | DevOps エンジニア | 
| AWS CDK スタックをデプロイして、複数の OU で DevOps の達人を活用しましょう。 | AWS CDK `CdkDevopsguruStackOrgUnit` スタックにより、OU 間で DevOps Guru サービスを有効にすることができます。スタックをデプロイするには、指定されたパラメータを使用して次のコマンドを実行します。<pre>$cdk deploy CdkDevopsguruStackOrgUnit \<br />  --profile administrator \ <br />  --parameters RegionIds="<region-1>,<region-2>" \<br />  --parameters OrganizationalUnitIds="<OU-1>,<OU-2>"</pre> | DevOps エンジニア | 

### オプション 3-複数のアカウントにわたる特定のスタックリソースの DevOps Guru を有効にする
<a name="option-3---enable-devops-guru-for-specific-stack-resources-across-multiple-accounts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM ロールを作成するための AWS CDK スタックをデプロイします。 | 最初のオプションで示した必要な IAM ロールをまだ作成していない場合は、まず作成してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html)詳細については、AWS CloudFormation ドキュメントの「[自己管理型のアクセス許可の承認](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html)」を参照してください。 | DevOps エンジニア | 
| 既存のスタックを削除します。 | 最初のオプションを使用してすべてのスタックリソースで DevOps Guru を有効にしている場合は、次のコマンドを使用して古いスタックを削除できます。<pre>$cdk destroy CdkDevopsGuruStackMultiAccReg --profile administrator </pre>あるいは、スタックを再デプロイするときに` RegionIds`パラメータを変更することで、「*スタックはすでに存在している*」エラーを回避することができます。 | DevOps エンジニア | 
| AWS CDK スタックをスタックリストで更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html) | データエンジニア | 
| AWS CDK スタックをデプロイして、複数のアカウントにまたがる特定のスタックリソースで DevOps Guru を有効にします。 | AWS CDK `CdkDevopsGuruStackMultiAccRegSpecStacks` スタックにより、DevOps Guru は複数のアカウントにまたがる特定のスタックリソースに対応できるようになります。以下のコマンドを実行して、API をデプロイします。<pre>$cdk deploy CdkDevopsGuruStackMultiAccRegSpecStacks \<br />  --profile administrator  \<br />  --parameters AdministratorAccountId=<administrator-account-ID> \<br />  --parameters TargetAccountId=<target-account-ID> \<br />  --parameters RegionIds="<region-1>,<region-2>"</pre>以前にオプション 1 でこのスタックをデプロイしたことがある場合は、「*スタックが既に存在している*」エラーを回避するために `RegionIds` パラメータを変更してください (必ず[利用可能なリージョン](https://aws.amazon.com/devops-guru/faqs/)から選択してください)。 | DevOps エンジニア | 

### AWS CDK インフラストラクチャスタックをデプロイ
<a name="deploy-the-aws-cdk-infrastructure-stack"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| サンプルのサーバーレスインフラストラクチャースタックをデプロイします。 | AWS CDK `CdkInfrastructureStack` スタックは API ゲートウェイ、Lambda、DynamoDB テーブルなどのサーバーレスコンポーネントをデプロイして、DevOps Guru のインサイトを実証します。以下のコマンドを実行して、API をデプロイします。 <pre>$cdk deploy CdkInfrastructureStack --profile administrator</pre> | DevOps エンジニア | 
| DynamoDB にサンプルレコードを挿入します。 | 次のコマンドを実行して、DynamoDB テーブルにサンプルレコードを設定します。`populate-shops-dynamodb-table.json`スクリプトの正しいパスを指定します。<pre>$aws dynamodb batch-write-item \<br />  --request-items file://scripts/populate-shops-dynamodb-table.json \<br />  --profile administrator</pre>コマンドによって以下の出力が表示されます。<pre>{<br />    "UnprocessedItems": {}<br />}</pre> | DevOps エンジニア | 
| DynamoDB に挿入されたレコードを確認します。 | DynamoDB テーブルに`populate-shops-dynamodb-table.json`ファイルのサンプルレコードが含まれていることを確認するには、AWS CDK スタックの出力として公開されている `ListRestApiEndpointMonitorOperator` API の URL にアクセスします。この URL は、`CdkInfrastructureStack`スタックの AWS CloudFormation コンソールの「**出力**」タブにもあります。出力は次の例のようになります：<pre>CdkInfrastructureStack.CreateRestApiMonitorOperatorEndpointD1D00045 = https://oure17c5vob.execute-api.<your-region>.amazonaws.com/prod/<br /><br />CdkInfrastructureStack.ListRestApiMonitorOperatorEndpointABBDB8D8 = https://cdff8icfrn4.execute-api.<your-region>.amazonaws.com/prod/</pre> | DevOps エンジニア | 
| リソースのベースラインが完了するまでお待ちください。 | このサーバーレススタックには、いくつかのリソースがあります。2 時間待ってから次のステップを実行することをお勧めします。このスタックを本番環境にデプロイした場合、DevOps Guru で監視対象として選択したリソースの数によっては、ベースラインが完了するまでに最大 24 時間かかる場合があります。 | DevOps エンジニア | 

### DevOps Guru のインサイトの生成
<a name="generate-devops-guru-insights"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS CDK インフラストラクチャスタックを更新します。 | DevOps Guru のインサイトを試すには、設定を変更して一般的な運用上の問題を再現できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html) | DevOps エンジニア | 
| API に HTTP リクエストを注入します。 | HTTP リクエストの形式で`ListRestApiMonitorOperatorEndpointxxxx` API にイングレストラフィックを注入します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.html) | DevOps エンジニア | 
| DevOps Guru Insight の表示 | 標準的な条件下では、DevOps Guru ダッシュボードの継続的なインサイトカウンターにはゼロが表示されます。異常を検出すると、インサイトという形でアラートが生成されます。ナビゲーションペインで「**インサイト**」を選択すると、概要、集計指標、関連イベント、推奨事項など、異常の詳細が表示されます。インサイトのレビューの詳細については、「[Amazon DevOps Guru を使用して AIOps で運用上の洞察を得る](https://aws.amazon.com/blogs/devops/gaining-operational-insights-with-aiops-using-amazon-devops-guru/)」というブログ投稿を参照してください。 | DevOps エンジニア | 

### クリーンアップ
<a name="clean-up"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リソースをクリーンアップして削除する。 | このパターンを確認したら、追加料金が発生しないように、作成したリソースを削除する必要があります。以下のコマンドを実行します。<pre>$cdk destroy CdkDevopsGuruStackMultiAccReg --profile administrator<br />$cdk destroy CdkDevopsguruStackOrgUnit --profile administrator<br />$cdk destroy CdkDevopsGuruStackMultiAccRegSpecStacks --profile administrator<br />$cdk destroy CdkInfrastructureStack --profile administrator<br />$cdk destroy CdkStackSetAdminRole --profile administrator<br />$cdk destroy CdkStackSetExecRole --profile administrator<br />$cdk destroy CdkStackSetExecRole --profile target</pre> | DevOps エンジニア | 

## 関連リソース
<a name="improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk-resources"></a>
+ [Amazon DevOps Guru を使用して AIOps による運用上の洞察を得る](https://aws.amazon.com/blogs/devops/gaining-operational-insights-with-aiops-using-amazon-devops-guru/)
+ [AWS CloudFormation StackSets を使用して、複数のアカウントとリージョンにわたって Amazon DevOps Guru を簡単に設定できます](https://aws.amazon.com/blogs/devops/configure-devops-guru-multiple-accounts-regions-using-cfn-stacksets/)
+ [DevOps の達人ワークショップ](https://aiops-using-devops-guru.workshop.aws/)

# Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する
<a name="govern-permission-sets-aft"></a>

*Amazon Web Services、Anand Krishna Varanasi と Siamak Heshmati*

## 概要
<a name="govern-permission-sets-aft-summary"></a>

このパターンは、[AWS Control Tower Account Factory Terraform (AFT) ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)を と統合[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)して、複数の に対するアクセス許可を AWS アカウント 大規模に設定するのに役立ちます。このアプローチでは、カスタム AWS Lambda 関数を使用して、組織として管理 AWS アカウント される への[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)の割り当てを自動化します。これにより、プラットフォームエンジニアリングチームによる手動介入が必要なくなるため、プロセスが合理化されます。このソリューションでは、運用効率、セキュリティ、一貫性を高めることができます。これにより、 の安全で標準化されたオンボーディングプロセスが促進され AWS Control Tower、クラウドインフラストラクチャの俊敏性と信頼性を優先する企業にとって不可欠です。

## 前提条件と制限
<a name="govern-permission-sets-aft-prereqs"></a>

**前提条件**
+ AWS アカウント、 で管理されます AWS Control Tower。詳細については、[「 の開始方法 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)」を参照してください。
+ Account Factory for Terraform が環境内の専用アカウントにデプロイされていること。詳細については、「[Deploy AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)」を参照してください。
+ IAM アイデンティティセンターインスタンスが環境内でセットアップされていること。詳細については、「[Getting started with IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してください。
+ アクティブな IAM アイデンティティセンター[グループ](https://docs.aws.amazon.com/singlesignon/latest/userguide/users-groups-provisioning.html#groups-concept)が設定されていること。 詳細については、「[Add groups to your IAM アイデンティティセンターディレクトリ](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)」を参照してください。
+ Python 3.9 以降がインストールされている

**制限事項**
+ このソリューションは、 AWS Control Towerを通じて管理されているアカウントでのみ使用できます。このソリューションは、Account Factory for Terraform を使用してデプロイされます。
+ このパターンには、ID ソースとの ID フェデレーションをセットアップする手順は含まれません。このセットアップを完了する方法の詳細については、IAM アイデンティティセンターのドキュメントの「[IAM Identity Center identity source tutorials](https://docs.aws.amazon.com/singlesignon/latest/userguide/tutorials.html)」を参照してください。

## アーキテクチャ
<a name="govern-permission-sets-aft-architecture"></a>

**AFT の概要**

AFT は、 AWS Control Towerでアカウントのプロビジョニングとカスタマイズを支援する Terraform パイプラインをセットアップします。AFT は、アカウントプロビジョニングのプロセスを自動化する GitOps モデルに従います AWS Control Tower。*アカウントリクエストの Terraform ファイル*を作成し、それをリポジトリにコミットします。これにより、アカウントプロビジョニングのための AFT ワークフローが開始されます。アカウントプロビジョニングが完了すると、AFT は追加のカスタマイズ手順を自動的に実行できます。詳細については、 AWS Control Tower ドキュメントの[「AFT アーキテクチャ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-architecture.html)」を参照してください。

AFT には、次のメインリポジトリが用意されています。
+ `aft-account-request` – このリポジトリには、 AWS アカウントを作成または更新するための Terraform コードが格納されています。
+ `aft-account-customizations` – このリポジトリには、アカウントごとにリソースを作成またはカスタマイズするための Terraform コードが格納されています。
+ `aft-global-customizations` – このリポジトリには、すべてのアカウントのリソースを大規模に作成またはカスタマイズするための Terraform コードが格納されています。
+ `aft-account-provisioning-customizations` – このリポジトリは、AFT によって作成され、管理される特定のアカウントにのみ適用されるカスタマイズを管理します。例えば、このリポジトリを使用して、IAM アイデンティティセンターでユーザーまたはグループの割り当てをカスタマイズしたり、アカウント閉鎖を自動化したりできます。

**ソリューションの概要**

このカスタムソリューションには、 AWS Step Functions ステートマシンと、複数のアカウントのユーザーとグループに権限セットを割り当てる AWS Lambda 関数が含まれています。このパターンでデプロイされたステートマシンは、既存の AFT `aft_account_provisioning_customizations` ステートマシンと一緒に動作します。ユーザーは、新しい AWS アカウント の作成時またはアカウントの作成後に、IAM Identity Center のユーザーとグループの割り当てを更新するリクエストを送信します。そのために、`aft-account-request` リポジトリの変更をプッシュします。アカウントの作成または更新のリクエストを送信すると、[Amazon DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) でストリームが開始されます。これにより、ターゲットの IAM Identity Center ユーザーとグループを更新する Lambda 関数が開始されます AWS アカウント。

以下に示すのは、ターゲットユーザーとグループへのアクセス許可セットの割り当てのために Lambda 関数で指定できるパラメータの例です。

```
custom_fields = {
    "InstanceArn"         = "<Organization ID>",
    "PermissionSetArn"    = "<Permission set ARN>",
    "PrincipalId"         = "<Principal ID>",
  }
```

このステートメントのパラメータは次のとおりです。
+ `InstanceArn` - 組織の Amazon リソースネーム (ARN)
+ `PermissionSetArn` - アクセス許可セットの ARN
+ `PrincipalId` - アクセス許可セットが適用される IAM アイデンティティセンターのユーザーまたはグループの識別子

**注記**  
このソリューションを実行する前に、ターゲットのアクセス許可セット、ユーザー、グループを作成する必要があります。

`InstanceArn` 値は一定とする必要がありますが、Lambda 関数は、複数のターゲット ID に複数のアクセス許可セットを割り当てるように変更することができます。アクセス許可セットのパラメータは `PermissionSetArn` で終わる必要があり、ユーザーとグループのパラメータは `PrincipalId` で終わる必要があります。両方の属性を定義する必要があります。以下に、複数のアクセス許可セットとターゲットユーザーおよびグループを定義する方法の例を示します。

```
custom_fields = {
    "InstanceArn"                    = "<Organization ID>",
    "AdminAccessPermissionSetArn"    = "<Admin privileges permission set ARN>",
    "AdminAccessPrincipalId"         = "<Admin principal ID>",
    "ReadOnlyAccessPermissionSetArn" = "<Read-only privileges permission set ARN>",
    "ReadOnlyAccessPrincipalId"      = "<Read-only principal ID>",
  }
```

次の図は、ソリューションがターゲット内のユーザーとグループのアクセス許可セットを AWS アカウント 大規模に更新する方法のstep-by-stepのワークフローを示しています。ユーザーがアカウント作成リクエストを開始すると、AFT は `aft-account-provisioning-framework` Step Functions ステートマシンを起動します。このステートマシンは `extract-alternate-sso` Lambda 関数を開始します。Lambda 関数は、ターゲット内のユーザーとグループに権限セットを割り当てます AWS アカウント。これらのユーザーまたはグループは、IAM アイデンティティセンターで設定された任意の ID ソースから取得できます。ID ソースの例としては、Okta、Active Directory、Ping Identity などがあります。

![\[アカウントが作成または更新されたときのアクセス許可セットの更新ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/14751255-3781-48db-a6b7-1a03e28c1020/images/d1de252d-8ac9-4f7d-a559-4ab3e852f325.png)


この図に、新しいアカウントが作成されたときの次のワークフローを示します。

1. ユーザーが `aft-account-request` リポジトリに `custom_fields` 変更をプッシュします。

1. AWS CodePipeline は、ユーザー定義メタデータを `aft-request-audit` Amazon DynamoDB テーブルに記録する AWS CodeBuild ジョブを開始します。このテーブルには、ユーザー定義メタデータを記録する属性があります。`ddb_event_name` 属性では、AFT オペレーションのタイプを定義します。
   + 値が の場合`INSERT`、ソリューションは新しい AWS アカウント の作成時にターゲット ID に設定されたアクセス許可を割り当てます。
   + 値が の場合`UPDATE`、ソリューションは の作成後にターゲット ID に設定されたアクセス許可を割り当て AWS アカウント ます。

1. Amazon DynamoDB Streams が `aft_alternate_sso_extract` Lambda 関数を開始します。

1. `aft_alternate_sso_extract` Lambda 関数は、 AWS Control Tower 管理アカウントで AWS Identity and Access Management (IAM) ロールを引き受けます。

1. Lambda 関数は、IAM アイデンティティセンターに an AWS SDK for Python (Boto3) [create\$1account\$1assignment](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sso-admin/client/create_account_assignment.html) API コールを実行して、アクセス許可セットをターゲットユーザーとグループに割り当てます。`aft-request-audit` Amazon DynamoDB テーブルからアクセス許可セットと ID の割り当てを取得します。

1. Step Functions ワークフローが完了すると、アクセス許可セットがターゲット ID に割り当てられます。

**自動化とスケール**

AFT は、スケーラビリティの高い CodePipeline、 AWS CodeBuild、DynamoDB、Lambda AWS のサービス などを使用して大規模に動作します。さらなる自動化のために、このソリューションを Jira などのチケットまたは問題管理システムと統合できます。詳細については、このパターンの「[追加情報](#govern-permission-sets-aft-additional)」セクションを参照してください。

## ツール
<a name="govern-permission-sets-aft-tools"></a>

**AWS のサービス**
+ [Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) は、このソリューションの主要なツールです。`aft-account-provisioning-customizations` リポジトリには、カスタム IAM Identity Center ユーザーやグループの割り当てなど AWS アカウント、 のカスタマイズを作成するための Terraform コードが含まれています。
+ [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) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数と他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。

**その他のツール**
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

**コードリポジトリ**

AFT のコードリポジトリは、GitHub の [AWS Control Tower Account Factory for Terraform](https://github.com/aws-ia/terraform-aws-control_tower_account_factory) リポジトリで入手できます。このパターンのコードは、[Account Factory for Terraform (AFT) リポジトリ AWS アカウント を使用するための SSO 割り当ての管理](https://github.com/aws-samples/aft-custom-sso-assignment)で使用できます。

## ベストプラクティス
<a name="govern-permission-sets-aft-best-practices"></a>
+ [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を理解します。
+ のセキュリティに関する推奨事項に従ってください AWS Control Tower。詳細については、[「 のセキュリティ AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/security.html)」を参照してください。
+ 最小権限の原則に従います。詳細については、「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
+ グループとビジネスユニット向けに、特定の焦点を絞ったアクセス許可セットと IAM ロールを構築します。

## エピック
<a name="govern-permission-sets-aft-epics"></a>

### 解決策をデプロイする
<a name="deploy-the-solution"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM ロールを作成します。 |  AWS Control Tower 管理アカウントで、Terraform を使用して IAM ロールを作成します。このロールは、クロスアカウントアクセスと、ID プロバイダーからのフェデレーションアクセスを許可する信頼ポリシーを備えています。また、 を介して他の アカウントへのアクセスを許可するアクセス許可も付与されます AWS Control Tower。Lambda 関数がこのロールを引き受けます。以下の操作を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/govern-permission-sets-aft.html) | AWS DevOps、クラウドアーキテクト | 
| 環境に合わせてソリューションをカスタマイズします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/govern-permission-sets-aft.html) | AWS DevOps、クラウドアーキテクト | 
| ソリューションのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/govern-permission-sets-aft.html) | AWS DevOps、クラウドアーキテクト | 
| コードリポジトリ接続をセットアップします。 | 設定ファイルを保存するコードリポジトリと 間の接続を設定します AWS アカウント。手順については、 AWS CodePipeline ドキュメントの[CodeConnections を使用してパイプラインにサードパーティーのソースプロバイダーを追加する](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-connections.html)」を参照してください。 | AWS DevOps、クラウドアーキテクト | 

### ソリューションを使用する
<a name="use-the-solution"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AFT パイプラインを開始して新しいアカウントをデプロイします。 |  AWS Control Tower 環境に[新しい を作成するパイプラインを開始するには、「AFT を使用して新しいアカウントをプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)する AWS アカウント 」の手順に従います。アカウントの作成プロセスが完了するのを待機します。 | AWS DevOps、クラウドアーキテクト | 
| 変更を検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/govern-permission-sets-aft.html) | AWS DevOps、クラウドアーキテクト | 

## トラブルシューティング
<a name="govern-permission-sets-aft-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| アクセス許可セットの割り当てが機能しません。 | グループ ARN、組織 ID、Lambda パラメータが正しいことを確認します。例については、このパターンの「*ソリューションの概要*」セクションを参照してください。 | 
| リポジトリ内のコードを更新しても、パイプラインが開始されません。 | この問題は、 AWS アカウント と リポジトリ間の接続に関連しています。で AWS マネジメントコンソール、接続がアクティブであることを確認します。詳細については、 AWS CodePipeline ドキュメントの[GitHub 接続](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-github.html)」を参照してください。 | 

## 追加情報
<a name="govern-permission-sets-aft-additional"></a>

**チケット管理ツールとの統合**

このソリューションを Jira や ServiceNow などのチケットまたは問題管理ツールと統合することを選択できます。次の図に、このオプションのワークフロー例を示します。チケット管理ツールと AFT ソリューションリポジトリを統合するには、ツールのコネクタを使用します。Jira コネクタについては、「[Integrate Jira with GitHub](https://support.atlassian.com/jira-cloud-administration/docs/integrate-jira-software-with-github/)」を参照してください。ServiceNow コネクタについては、「[Integrating with GitHub](https://www.servicenow.com/docs/bundle/washingtondc-it-asset-management/page/product/software-asset-management2/concept/integrate-with-github.html)」を参照してください。プルリクエストの承認の一環としてユーザーにチケット ID の提供を求めるカスタムソリューションを構築することもできます。AFT AWS アカウント を使用して新しい を作成するリクエストが承認された場合、そのイベントは `aft-account-request` GitHub リポジトリにカスタムフィールドを追加するワークフローを開始できます。ユースケースの要件を満たすカスタムワークフローを設計できます。

![\[GitHub Actions とチケット管理ツールを使用するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/14751255-3781-48db-a6b7-1a03e28c1020/images/83763f65-32ea-4de0-932f-14a1b2d1d3ad.png)


この図表は、次のワークフローを示しています:

1. ユーザーが、Jira などのチケット管理ツールでカスタムアクセス許可セットの割り当てをリクエストします。

1. ケースが承認されると、アクセス許可セットの割り当てを更新するワークフローが開始されます。(オプション) このステップのカスタム自動化に向けたプラグインを使用できます。

1. オペレーターが、`aft-account-request` リポジトリへの更新済みのアクセス許可セットパラメータを含む Terraform コードを develop ブランチまたは feature ブランチに送信します。

1. GitHub Actions は、OpenID Connect (OIDC) 呼び出しを使用して開始 AWS CodeBuild します。CodeBuild は、[tfsec](https://aquasecurity.github.io/tfsec/v1.20.0/) や [checkov](https://www.checkov.io/) などのツールを使用して、Infrastructure as Code (IaC) セキュリティスキャンを実行します。セキュリティ違反があれば、オペレーターに警告します。

1. 違反が検出されない場合、GitHub Actions は自動プルリクエストを作成し、コード所有者にコードレビューを割り当てます。また、プルリクエストのタグも作成します。

1. コード所有者がコードレビューを承認すると、別の GitHub Actions ワークフローが開始されます。以下を含むプルリクエストの基準がチェックされます。
   + プルリクエストのタイトルが要件を満たしているかどうか。
   + プルリクエスト本文に承認済みのケース番号が含まれているかどうか。
   + プルリクエストに適切にタグが付けられているかどうか。

1. プルリクエストが基準を満たしている場合、GitHub Actions は AFT 製品ワークフローを開始します。を使用して`ct-aft-account-request`パイプラインが開始されます AWS CodePipeline。このパイプラインは Step Functions で `aft-account-provisioning-framework` カスタムステートマシンを起動します。このステートマシンは、本パターンの「*ソリューションの概要*」セクションで説明したとおりに動作します。

# ブートストラップパイプラインを使用して Account Factory for Terraform (AFT) を実装する
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline"></a>

*Amazon Web Services、Vinicius Elias と Edgar Costa Filho*

## 概要
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-summary"></a>

このパターンは、 の管理アカウントから AWS Control Tower Account Factory for Terraform (AFT) をデプロイするためのシンプルで安全な方法を提供します AWS Organizations。このソリューションの中核となるのは、Terraform パイプラインを作成して AFT 設定を自動化する CloudFormation テンプレートです。このパイプラインは、最初のデプロイやその後の更新に簡単に適応できるように設計されています。

セキュリティとデータの整合性が最優先事項であるため AWS、マネージドインフラストラクチャと設定の状態を追跡する重要なコンポーネントである Terraform 状態ファイルは、Amazon Simple Storage Service (Amazon S3) バケットに安全に保存されます。このバケットには、サーバー側の暗号化やパブリックアクセスをブロックするポリシーなど、いくつかのセキュリティ対策が設定されており、Terraform の状態を不正アクセスやデータ侵害から保護するのに役立ちます。

管理アカウントは環境全体をオーケストレーションおよび監視するため、重要なリソースです AWS Control Tower。このパターンは AWS ベストプラクティスに従っており、デプロイプロセスが効率的であるだけでなく、セキュリティとガバナンスの標準にも準拠し、 AWS 環境に AFT をデプロイするための包括的で安全で効率的な方法を提供します。

AFT の詳細については、[AWS Control Tower のドキュメント](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)を参照してください。

## 前提条件と制限
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-prereqs"></a>

**前提条件**
+ 少なくとも管理アカウント、ログアーカイブアカウント、監査アカウント、および AFT 管理用の 1 つの追加アカウントを持つ基本的な AWS マルチアカウント環境。
+ 確立された AWS Control Tower 環境。CloudFormation テンプレートが管理アカウント内にデプロイされるため、管理アカウントが適切に設定されている必要があります。
+  AWS 管理アカウントに必要なアクセス許可。S3 バケット、 AWS Lambda 関数、 AWS Identity and Access Management (IAM) ロール、 AWS CodePipeline プロジェクトなどのリソースを作成および管理するには、十分なアクセス許可が必要です。
+ Terraform に精通していること。デプロイには Terraform 設定の生成と管理が含まれるため、Terraform の主要な概念とワークフローを理解していることが重要です。

**制限事項**
+ アカウントの [AWS リソースクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)に注意してください。デプロイでは複数のリソースが作成され、サービスクォータに達するとデプロイプロセスが妨げられる可能性があります。
+ テンプレートは、Terraform および AWS のサービスの特定のバージョン用に設計されています。バージョンのアップグレードまたは変更のために、テンプレートの変更が必要になる場合があります。
+ テンプレートは、GitHub Enterprise などのセルフマネージド型バージョン管理システム (VCS) サービスには対応していません。

**製品バージョン**
+ Terraform バージョン 1.6.6 以降
+ AFT バージョン 1.11 以降

## アーキテクチャ
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-architecture"></a>

**ターゲットテクノロジースタック**
+ CloudFormation
+ AWS CodeBuild
+ AWS CodeCommit
+ AWS CodePipeline
+ Amazon EventBridge
+ IAM
+ AWS Lambda
+ Amazon S3

**ターゲットアーキテクチャ**

以下の図に、このパターンで説明する実装を示します。

![\[ブートストラップパイプラインを使用して AFT を実装するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/944f9912-87c7-4cc5-8478-7070cf67f7ee/images/4ee74757-940d-4d92-a7f0-fb0db1476247.png)


ワークフローを構成する 3 つの主要なタスクは、リソースの作成、コンテンツの生成、パイプラインの実行です。

*リソースの作成*

[このパターンで提供する CloudFormation テンプレート](https://github.com/aws-samples/aft-bootstrap-pipeline/blob/main/code/aft-deployment-pipeline.yaml)は、テンプレートのデプロイ時に選択するパラメータに応じて、必要なすべてのリソースを作成してセットアップします。少なくとも、このテンプレートは次のリソースを作成します。
+ AFT を実装するための CodePipeline パイプライン
+ AFT 実装に関連付けられている Terraform ステートファイルを保存するための S3 バケット
+ Terraform プランを実装し、パイプラインのさまざまな段階でコマンドを適用するための 2 つの CodeBuild プロジェクト
+ CodeBuild および CodePipeline サービスのための IAM ロール
+ パイプラインランタイムアーティファクトを保存するための 2 番目の S3 バケット

選択した VCS プロバイダー (CodeCommit または外部 VCS) に応じて、テンプレートは次のリソースを作成します。
+ **CodeCommit** の場合:
  + AFT Terraform ブートストラップコードを保存するための CodeCommit リポジトリ
  + `main` ブランチで CodeCommit リポジトリの変更をキャプチャするための EventBridge ルール
  + EventBridge ルール用の別の IAM ロール
+ GitHub といった他の**外部 VCS プロバイダー**の場合:
  +  AWS CodeConnections 接続

また、VCS プロバイダーとして CodeCommit を選択した場合、`Generate AFT Files` パラメータに `true` を設定すると、テンプレートは次のコンテンツを生成するためにこれらの追加リソースを作成します。
+ 生成されたコンテンツを保存し、CodeCommit リポジトリのソースとして使用するための S3 バケット
+ 指定されたパラメータを処理し、適切なコンテンツを生成するための Lambda 関数
+ Lambda 関数を実行するための IAM 関数
+ テンプレートがデプロイされたときに Lambda 関数を実行する CloudFormation カスタムリソース

*コンテンツの生成*

AFT ブートストラップファイルとそのコンテンツを生成するために、ソリューションは Lambda 関数と S3 バケットを使用します。関数はバケット内にフォルダを作成し、フォルダ内に 2 つのファイル、つまり `main.tf` と `backend.tf` を作成します。関数は、提供された CloudFormation パラメータも処理し、これらのファイルに事前定義されたコードを入力し、それぞれのパラメータ値を置き換えます。

ファイルを生成するためのテンプレートとして使用されるコードを表示するには、ソリューションの [GitHub リポジトリ](https://github.com/aws-samples/aft-bootstrap-pipeline)を参照してください。基本的に、ファイルは次のように生成されます。

**main.tf**

```
module "aft" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory?ref=<aft_version>"

  # Required variables
  ct_management_account_id  = "<ct_management_account_id>"
  log_archive_account_id    = "<log_archive_account_id>"
  audit_account_id          = "<audit_account_id>"
  aft_management_account_id = "<aft_management_account_id>"
  ct_home_region            = "<ct_home_region>"

  # Optional variables
  tf_backend_secondary_region = "<tf_backend_secondary_region>"
  aft_metrics_reporting       = "<false|true>"

  # AFT Feature flags
  aft_feature_cloudtrail_data_events      = "<false|true>"
  aft_feature_enterprise_support          = "<false|true>"
  aft_feature_delete_default_vpcs_enabled = "<false|true>"

  # Terraform variables
  terraform_version      = "<terraform_version>"
  terraform_distribution = "<terraform_distribution>"

  # VCS variables (if you have chosen an external VCS)
  vcs_provider                                  = "<github|githubenterprise|gitlab|gitlabselfmanaged|bitbucket>"
  account_request_repo_name                     = "<org-name>/aft-account-request"
  account_customizations_repo_name              = "<org-name>/aft-account-customizations"
  account_provisioning_customizations_repo_name = "<org-name>/aft-account-provisioning-customizations"
  global_customizations_repo_name               = "<org-name>/aft-global-customizations"

}
```

**backend.tf**

```
terraform {
  backend "s3" {
    region = "<aft-main-region>"
    bucket = "<s3-bucket-name>"
    key    = "aft-setup.tfstate"
  }
}
```

CodeCommit リポジトリの作成中に `Generate AFT Files` パラメータを `true` に設定すると、テンプレートは、生成されたコンテンツを格納する S3 バケットを `main` ブランチのソースとして使用し、リポジトリを自動的に入力します。

*パイプラインの実行*

リソースが作成され、ブートストラップファイルが設定されると、パイプラインが実行されます。最初のステージ (*ソース*) ではリポジトリのメインブランチからソースコードを取得し、2 番目のステージ (*ビルド*) では Terraform plan コマンドの実行と、確認すべき結果の生成を行います。3 番目のステージ (*承認*) では、パイプラインは手動アクションが最後のステージ (*デプロイ*) を承認または拒否するまで待機します。最後のステージでは、パイプラインは前の Terraform `apply` コマンドの結果を入力として使用して Terraform `plan` コマンドを実行します。最後に、クロスアカウントロールと管理アカウントのアクセス許可を使用して、AFT 管理アカウントで AFT リソースを作成します。

**注記**  
外部 VCS プロバイダーを選択する場合は、VCS プロバイダー認証情報との接続を承認する必要があります。セットアップを完了するには、 AWS 「 デベロッパーツールコンソールドキュメント[」の「保留中の接続の更新](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html)」のステップに従います。

## ツール
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-tools"></a>

**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 CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [AWS CodeConnections](https://docs.aws.amazon.com/dtconsole/latest/userguide/welcome-connections.html) では、CodePipeline などの AWS リソースとサービスが GitHub などの外部コードリポジトリに接続できます。
+ [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 のサービス。

**その他のツール**
+ [Terraform](https://developer.hashicorp.com/terraform?product_intent=terraform) は、インフラストラクチャを安全かつ効率的に構築、変更、およびバージョニングできる Infrastructure as Code (IaC) ツールです。このツールには、コンピューティングインスタンス、ストレージ、ネットワークなどの下位レベルのコンポーネントと、DNS エントリや SaaS 機能などの上位レベルのコンポーネントが含まれます。
+ [Python](https://docs.python.org/3.9/tutorial/index.html) は、学習しやすく強力なプログラミング言語です。効率的な高レベルのデータ構造を備え、シンプルで効果的なアプローチによるオブジェクト指向プログラミングが可能です。

**コードリポジトリ**

このパターンのコードは GitHub 内の [AFT bootstrap pipeline](https://github.com/aws-samples/aft-bootstrap-pipeline) リポジトリで入手できます。

公式 AFT リポジトリについては、GitHub の「[AWS Control Tower Account Factory for Terraform](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)」を参照してください。

## ベストプラクティス
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-best-practices"></a>

提供された CloudFormation テンプレートを使用して AFT をデプロイする場合は、安全かつ効率的に実装を完了するために、ベストプラクティスに従うことが推奨されます。AFT の実装と運用に関する主要なガイドラインおよび推奨事項は次のとおりです。
+ **パラメータの詳細な確認**: CloudFormation テンプレートの各パラメータを慎重に確認し、理解します。AFT が正しくセットアップされ、機能するには、正確なパラメータ設定が不可欠です。
+ テンプレートの**定期的な更新**: テンプレートを最新の AWS 機能と Terraform バージョンで更新します。定期的に更新することで、新機能の活用やセキュリティの維持が可能になります。
+ **バージョニング**: AFT モジュールのバージョンを固定し、可能であれば別の AFT デプロイを使用してテストします。
+ **スコープ**: AFT は、インフラストラクチャのガードレールとカスタマイズをデプロイするためにのみ使用します。アプリケーションのデプロイには使用しないでください。
+ **リンティングと検証**: AFT パイプラインには、リンティングされ検証された Terraform 設定が必要です。この設定を AFT リポジトリにプッシュする前に、リンティング、検証、テストを実行します。
+ **Terraform モジュール**: 再利用可能な Terraform コードをモジュールとして構築し、常に組織の要件に合わせて Terraform と AWS プロバイダーのバージョンを指定します。

## エピック
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-epics"></a>

### AWS 環境のセットアップと設定
<a name="set-up-and-configure-the-aws-environment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  AWS Control Tower 環境を準備します。 |  AWS Control Tower AWS 環境で をセットアップして設定し、 の一元化された管理とガバナンスを確保します AWS アカウント。詳細については、 AWS Control Tower ドキュメント[の「 の開始方法 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)」を参照してください。 | クラウド管理者 | 
| AFT 管理アカウントを作成します。 |  AWS Control Tower Account Factory を使用して、AFT 管理アカウント AWS アカウント として機能する新しい を起動します。詳細については、 AWS Control Tower ドキュメントの[AWS Service Catalog 「Account Factory でアカウントをプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)する」を参照してください。 | クラウド管理者 | 

### 管理アカウントに CloudFormation テンプレートをデプロイする
<a name="deploy-the-cfnshort-template-in-the-management-account"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| CloudFormation のテンプレートを起動します。 | このエピックでは、このソリューションに付属の CloudFormation テンプレートをデプロイして、 AWS 管理アカウントに AFT ブートストラップパイプラインを設定します。パイプラインは、前のエピックで設定した AFT 管理アカウントに AFT ソリューションをデプロイします。**ステップ 1: CloudFormation コンソールを開く**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 2: 新しいスタックを作成する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 3: スタックパラメータを設定する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 4: ファイル生成設定を決定する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 5: アカウント AWS Control Tower の詳細と AFT アカウントの詳細を入力する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 6: AFT オプションを設定する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 7: バージョンを指定する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 8: スタックを確認して作成する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 9: スタックの作成をモニタリングする**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 10: デプロイを検証する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html) | クラウド管理者 | 

### AFT ブートストラップリポジトリとパイプラインの入力、検証をする
<a name="populate-and-validate-the-aft-bootstrap-repository-and-pipeline"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| オプション 1: 外部 VCS の AFT ブートストラップリポジトリを設定します。 | VCS プロバイダーを外部 VCS (CodeCommit ではなく) に設定する場合は、以下の手順に従います。(オプション) CloudFormation テンプレートをデプロイした後、新しく作成した AFT ブートストラップリポジトリの内容を設定または検証し、パイプラインが正常に実行されたかどうかをテストできます。**ステップ 1: 接続を更新する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 2: リポジトリに入力する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 2: 変更をコミットおよびプッシュする**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html) | クラウド管理者 | 
| オプション 2: CodeCommit の AFT ブートストラップリポジトリを設定します。 | VCS プロバイダーに CodeCommit を設定する場合は、以下の手順に従います。(オプション) CloudFormation テンプレートをデプロイした後、新しく作成した AFT ブートストラップリポジトリの内容を設定または検証し、パイプラインが正常に実行されたかどうかをテストできます。`Generate AFT Files` パラメータを `true` に設定した場合は、次のストーリー (パイプラインの検証) に進みます。**ステップ 1: リポジトリに入力する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 2: 変更をコミットおよびプッシュする**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html) | クラウド管理者 | 
| AFT ブートストラップパイプラインを検証します。 | **ステップ 1: パイプラインを表示する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 2: Terraform プランの結果を承認する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 3: デプロイを待機する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html)**ステップ 4: 作成されたリソースを確認する**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline.html) | クラウド管理者 | 

## トラブルシューティング
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| CloudFormation テンプレートに含まれるカスタム Lambda 関数がデプロイ中に失敗します。 | Lambda 関数の Amazon CloudWatch Logs をチェックして、エラーを特定します。ログは詳細情報を提供し、問題を特定するのに役立ちます。Lambda 関数に必要なアクセス許可が付与されていて、環境変数が正しく設定されていることを確認してください。 | 
| アクセス許可が不十分であることが原因で、リソースの作成または管理で障害が発生します。 | Lambda 関数、CodeBuild、およびデプロイに関連するその他のサービスにアタッチされている IAM ロールとポリシーを確認します。必要なアクセス許可が付与されていることを確認します。アクセス権限に問題がある場合は、IAM ポリシーを調整して必要なアクセス許可を付与します。 | 
| CloudFormation テンプレートの古いバージョンを新しいバージョン AWS のサービス または Terraform バージョンで使用している。 | CloudFormation テンプレートを定期的に更新して、最新の AWS および Terraform リリースと互換性を持たせます。バージョン固有の変更や要件については、リリースノートまたはドキュメントを確認してください。 | 
| デプロイ中に AWS のサービス クォータに達します。 | パイプラインをデプロイする前に、S3 AWS のサービス バケット、IAM ロール、Lambda 関数などのリソースのクォータを確認します。必要に応じてクォータの引上げをリクエストします。詳細については、 AWS ウェブサイトの[AWS のサービス 「クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。 | 
| CloudFormation テンプレートの入力パラメータが正しくないためにエラーが発生します。 | タイプミスや値の誤りがないか、すべての入力パラメータを再確認します。アカウント ID やリージョン名などのリソース識別子が正確であることを確認してください。 | 

## 関連リソース
<a name="implement-account-factory-for-terraform-aft-by-using-a-bootstrap-pipeline-resources"></a>

このパターンを正常に実装するには、次のリソースを確認してください。これらのリソースは、 CloudFormationを使用して AFT をセットアップおよび管理する際の貴重な追加情報とガイダンスを提供します。

**AWS** **ドキュメント:**
+ [AWS Control Tower ユーザーガイド](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)には、 のセットアップと管理に関する詳細情報が記載されています AWS Control Tower。
+ [CloudFormation ドキュメント](https://docs.aws.amazon.com/cloudformation/index.html)は、CloudFormation テンプレート、スタック、リソース管理に関するインサイトを提供します。

**IAM ポリシーとベストプラクティス:**
+ [IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)では、IAM ロールとポリシーを使用して AWS リソースを保護する方法について説明します。

**Terraform オン AWS:**
+ [Terraform AWS プロバイダードキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)には、 での Terraform の使用に関する包括的な情報が記載されています AWS。

**AWS のサービス クォータ:**
+ [AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)は、 AWS のサービス クォータの表示方法と引き上げをリクエストする方法に関する情報を提供します。

# 複数の AWS アカウントと AWS リージョンで AWS Service Catalog 製品を管理
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions"></a>

*Amazon Web Services、Ram Kandaswamy*

## 概要
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-summary"></a>

Amazon Web Services (AWS) Service Catalog は、企業向けの Infrastructure as Code (IaC) テンプレートのガバナンスと配布を簡単かつ迅速にします。AWS CloudFormation テンプレートで、製品に必要な AWS リソース (*スタック*) のコレクションを定義します。AWS CloudFormation StackSets は、複数のアカウントおよび AWS リージョンにまたがるスタックを単一の操作で作成、更新、削除できるようにすることで、スタックの機能を拡張します。

AWS Service Catalog の管理者は、開発者が作成した CloudFormation テンプレートで製品を作成し、公開します。その後、これらの製品はポートフォリオに関連付けられ、ガバナンスに制約が適用されます。他の AWS アカウントまたは組織単位 (OU) のユーザーが製品を利用できるようにするには、通常、彼らと「[ポートフォリオを共有](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing.html)」します。このパターンは、AWS CloudFormation StackSets に基づく AWS Service Catalog 製品の提供を管理するための代替アプローチを示しています。ポートフォリオを共有する代わりに、スタックセット制約により、製品をデプロイして使用できる AWS リージョンとアカウントを設定します。このアプローチを使用すると、ガバナンス要件を満たしながら、AWS Service Catalog 製品を複数のアカウント、OU と AWS リージョンにプロビジョニングし、一元的に管理できます。 

この方法の利点:
+ 製品はプライマリアカウントからプロビジョニング、管理され、他のアカウントと共有されることはありません。
+ この方法では、特定の製品に基づいてプロビジョニングされたすべての製品 (スタック) を統合して表示できます。
+ AWS Service Management Connector での設定は、1 つのアカウントのみを対象としているため、より簡単です。
+ AWS Service Catalog の製品のクエリと使用が簡単になりました。

## 前提条件と制限
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-prereqs"></a>

**前提条件**
+ IaC とバージョニング用の AWS CloudFormation テンプレート
+ AWS リソースのプロビジョニングと管理のためのマルチアカウント設定と AWS Service Catalog

**制限事項**
+ このアプローチでは AWS CloudFormation StackSets が使用され、StackSets 制限が適用されます。
  + StackSets は、マクロによる CloudFormation テンプレートのデプロイをサポートしません。マクロでテンプレートを前処理している場合、StackSets ベースのデプロイを使用することはできません。
  + StackSets では、スタックをスタックセットから切り離すことができるため、特定のスタックをターゲットにして問題を解決できます。ただし、関連付けを解除したスタックをスタックセットに再関連付けることはできません。
+ AWS Service Catalog は StackSet 名を自動的に生成します。カスタマイズは現在サポートされていません。

## アーキテクチャ
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-architecture"></a>

**ターゲットアーキテクチャ**

![\[ユーザーは、AWS CloudFormation テンプレートと StackSets を使用して AWS Service Catalog 製品を管理します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/16458fcd-861d-4ed4-8b91-47e19289a6bb/images/97d23325-b5c6-4ca9-8288-8dec1650c975.png)


1. ユーザーは、AWS リソースをプロビジョニングするための AWS CloudFormation テンプレートを JSON 形式または YAML 形式で作成します。

1. CloudFormation テンプレートは AWS Service Catalog に製品を作成し、ポートフォリオに追加します。

1. ユーザーは、ターゲットアカウントに CloudFormation スタックを作成するプロビジョニング済み製品を作成します。

1. 各スタックは、CloudFormationで指定されたリソースをプロビジョニングします。

## ツール
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-tools"></a>

**AWS サービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ 「[AWS コマンドラインインターフェイス (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 Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、AWS で承認された IT サービスのカタログを一元管理できます。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。

## エピック
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-epics"></a>

### アカウント間での製品のプロビジョニング
<a name="provision-products-across-accounts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ポートフォリオを作成します。 | ポートフォリオは、特定の基準に基づき、グループ化された 1 つ以上の製品を含むコンテナです。ポートフォリオを製品に使用すると、製品セット全体に共通の制約を適用しやすくなります。ポートフォリオを作成するには、「[AWS Service Catalog ドキュメント](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/portfoliomgmt-create.html)」の手順に従ってください。AWS CLI を使用している場合は、コマンドの例を挙げます。<pre>aws servicecatalog create-portfolio --provider-name my-provider --display-name my-portfolio</pre>詳細については、「[AWS CLI ドキュメント](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/servicecatalog/create-portfolio.html)」を参照してください。 | AWS Service Catalog、IAM | 
| CloudFormation テンプレートを作成します。 | リソースを説明する CloudFormation テンプレートを作成します。必要に応じて、リソースプロパティをパラメータ化する必要があります | AWS CloudFormation JSON/YAML | 
| バージョン情報を使用して製品を作成します。 | CloudFormation テンプレートは、AWS Service Catalog に公開すると製品になります。オプションのバージョン詳細パラメータ (バージョンタイトルや説明など) に値を指定することは、後で製品について問い合わせるときに役立ちます。ポートフォリオを作成するには、「[AWS Service Catalog ドキュメント](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/productmgmt-cloudresource.html)」の手順に従ってください。AWS CLI を使用している場合は、コマンドの例：<pre>aws servicecatalog create-product --cli-input-json file://create-product-input.json</pre>`create-product-input.json` は製品のパラメータを渡すファイルはどこですか。ファイルの例については、「*追加情報*」セクションを参照してください。詳細については、「[AWS CLI ドキュメント](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/servicecatalog/create-product.html)」を参照してください。 | AWS Service Catalog | 
| 制約を適用します。 | スタックセットの制約をポートフォリオに適用し、複数の AWS アカウント、リージョン、権限などの製品デプロイオプションを設定します。手順については、「[AWS Service Catalog のドキュメント](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints-stackset.html)」を参照してください。 | AWS Service Catalog | 
| アクセス許可を追加します。 | ユーザーがポートフォリオ内の製品を起動できるようにアクセス権限を付与します。コンソールの手順については、「[AWS Service Catalog のドキュメント](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_users.html)」を参照してください。AWS CLI を使用している場合は、コマンドの例を挙げます。<pre>aws servicecatalog associate-principal-with-portfolio \<br />    --portfolio-id port-2s6abcdefwdh4 \<br />    --principal-arn arn:aws:iam::444455556666:role/Admin \<br />    --principal-type IAM</pre>詳細については、「[AWS CLI ドキュメント](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/servicecatalog/associate-principal-with-portfolio.html)」を参照してください。 | AWS Service Catalog、IAM | 
| 製品をプロビジョニングします。 | プロビジョニングされた製品は、製品のリソースインスタンスです。例えば、CloudFormation テンプレートに基づいて製品をプロビジョニングすると、CloudFormation スタックとその基礎となるリソースが起動します。スタックセットの制約に基づき、該当する AWS リージョンとアカウントをターゲットにして製品をプロビジョニングします。AWS CLI でのコマンドの例は次のとおりです。<pre>aws servicecatalog provision-product \<br />    --product-id prod-abcdfz3syn2rg \<br />    --provisioning-artifact-id pa-abc347pcsccfm \<br />    --provisioned-product-name "mytestppname3"</pre>詳細については、「[AWS CLI ドキュメント](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/servicecatalog/provision-product.html)」を参照してください。 | AWS Service Catalog | 

## 関連リソース
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-resources"></a>

**リファレンス**
+ 「[AWS Service Catalog の概要](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/what-is_concepts.html)」
+ 「[AWS CloudFormation StackSetsの使用](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/using-stacksets.html)」

**チュートリアルと動画**
+ 「[AWS re: Invent 2019: すべてを自動化する:オプションとベストプラクティス](https://www.youtube.com/watch?v=bGBVPIpQMYk)」(ビデオ)

## 追加情報
<a name="manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions-additional"></a>

`create-product` コマンドを使用する場合、`cli-input-json` パラメータは製品所有者、サポートメール、CloudFormation テンプレートの詳細などの情報を指定するファイルを指します。以下にそのようなファイルの例を示します。

```
{
   "Owner": "Test admin",
      "SupportDescription": "Testing",
         "Name": "SNS",
            "SupportEmail": "example@example.com",
            "ProductType": "CLOUD_FORMATION_TEMPLATE",
               "AcceptLanguage": "en",
                  "ProvisioningArtifactParameters": {
                     "Description": "SNS product",
                        "DisableTemplateValidation": true,
                           "Info": {
                              "LoadTemplateFromURL": "<url>"
                     },
                           "Name": "version 1"
}
```

# AWS のサービスを使用して SAP RHEL Pacemaker クラスターをモニタリングする
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services"></a>

*Amazon Web Services、Harsh Thoria、Randy Germann、RAVEENDRA Voore*

## 概要
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-summary"></a>

このパターンでは、Amazon CloudWatch と Amazon Simple Notiﬁcation Service (Amazon SNS) を使用して、SAP アプリケーションおよび SAP HANA データベースサービス用の Red Hat Enterprise Linux (RHEL) ペースメーカークラスターのアラートをモニタリングおよび設定する手順の概要を示します。

この設定を行うことで、CloudWatch ログストリーム、メトリクスフィルター、アラームを使用して、SAP SCS または ASCS、エンキューレプリケーションサーバー (ERS)、SAP HANA クラスターリソースが「停止」状態になったときにモニタリングできます。Amazon SNS は、停止したクラスターのステータスに関する E メールをインフラストラクチャまたは SAP Basis チームに送信します。

このパターンの AWS リソースは、 AWS CloudFormation スクリプトまたは AWS サービスコンソールを使用して作成できます。このパターンではコンソールの使用を前提としています。CloudFormation スクリプトの提供や、CloudWatch および Amazon SNS のインフラストラクチャデプロイには対応しません。Pacemaker コマンドは、クラスターアラート設定を設定するために使用されます。

## 前提条件と制限
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ E メールまたはモバイル通知を送信するように Amazon SNS を設定します。
+ SAP ASCS/ERS for ABAP または SCS/ERS for Java、および SAP HANA Database RHEL Pacemaker クラスター。手順については、以下を参照してください。
  + [SAP HANA cluster setup](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-manual-deployment-of-sap-hana-on-aws-with-high-availability-clusters.html)
  + [SAP Netweaver ABAP/Java cluster setup](https://docs.aws.amazon.com/sap/latest/sap-netweaver/sap-netweaver-ha-configuration-guide.html)

**制限事項**
+ このソリューションは、現在 RHEL バージョン 7.3 以降の Pacemaker ベースのクラスターで動作します。SUSE オペレーティングシステムではテストされていません。

**製品バージョン**
+ RHEL 7.3 以降

## アーキテクチャ
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-architecture"></a>

**ターゲットテクノロジースタック**
+ RHEL Pacemaker アラートイベント駆動型エージェント
+ Amazon Elastic Compute Cloud (Amazon EC2)
+ CloudWatch アラーム
+ CloudWatch ロググループとメトリクスフィルター
+ Amazon SNS

**ターゲット アーキテクチャ**

次の図は、このソリューションのコンポーネントとワークフローを示しています。

![\[SAP RHEL Pacemaker クラスターをモニタリングするためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ca4d282e-eadd-43fd-8506-3dbeb43e4db6/images/bfc96678-1fd3-47b6-8f09-bf7cf7c4a92c.png)


**自動化とスケール**
+ CloudFormation スクリプトを使用して、 AWS リソースの作成を自動化できます。追加のメトリクスフィルターを使用して、複数のクラスターをスケールおよびカバーすることもできます。

## ツール
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-tools"></a>

**AWS サービス**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行するアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。
+  [Amazon Simple Notiﬁcation Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。

**ツール**
+ CloudWatch エージェント (統合) は、EC2 インスタンスからシステムレベルのメトリクス、ログ、トレースを収集し、アプリケーションからカスタムメトリクスを取得するツールです。
+ Pacemaker アラートエージェント (RHEL 7.3 以降に対応) は、Pacemaker クラスターでリソースが停止または再起動したときなど、変更があったときにアクションを開始するツールです。

## ベストプラクティス
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-best-practices"></a>
+ で SAP ワークロードを使用するためのベストプラクティスについては AWS、 AWS 「 Well-Architected フレームワークの [SAP レンズ](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/sap-lens.html)」を参照してください。
+ SAP HANA クラスターの CloudWatch モニタリングの設定に関連するコストをご検討ください。詳しくは「[CloudFront ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_billing.html)」をご確認ください。
+ Amazon SNS アラートへのページャーまたはチケット発行メカニズム導入をご検討ください。
+ **pcs**、Pacemaker、およびフェンシングエージェントの RPM パッケージの RHEL 高可用性 (HA) AWS バージョンを必ず確認してください。

## エピック
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-epics"></a>

### Amazon SNS をセットアップする
<a name="set-up-sns"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| SNS トピックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html) | AWS 管理者 | 
| SNS トピックのアクセスポリシーを変更します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html) | AWS システム管理者 | 
| SNS トピックにサブスクライブします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html)ウェブブラウザに Amazon SNS の確認画面が表示されます。 | AWS システム管理者 | 

### クラスターの設定を確認する
<a name="confirm-the-setup-of-the-cluster"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| クラスターのステータスを確認します。 | **pcs status** コマンドを使用して、リソースがオンラインであることを確認します。 | SAP ベーシス管理者 | 

### Pacemaker アラートを設定する
<a name="configure-pacemaker-alerts"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| プライマリクラスターインスタンスで Pacemaker アラートエージェントを設定します。 | プライマリークラスターの EC2 インスタンスにログインし、次のコマンドを実行します。<pre>install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample<br />touch /var/lib/pacemaker/alert_file.sh<br />touch /var/log/pcmk_alert_file.log<br />chown hacluster:haclient /var/log/pcmk_alert_file.log<br />chmod 600 /var/log/pcmk_alert_file.log<br />pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh<br />pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log</pre> | SAP ベーシス管理者 | 
| セカンダリクラスターインスタンスで Pacemaker アラートエージェントを設定します。 | セカンダリクラスターのセカンダリクラスター EC2 インスタンスにログインし、次のコマンドを実行します。<pre>install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample<br />touch /var/lib/pacemaker/alert_file.sh<br />touch /var/log/pcmk_alert_file.log<br />chown hacluster:haclient /var/log/pcmk_alert_file.log<br />chmod 600 /var/log/pcmk_alert_file.log</pre> | SAP ベーシス管理者 | 
| RHEL アラートリソースが作成されていることを確認します。 | 設定が作成されたことを確認するには、次のコマンドを使用します。<pre>pcs alert</pre>コマンドの出力は次のようになります。<pre>[root@xxxxxxx ~]# pcs alert <br />Alerts:<br /> Alert: alert_file (path=/var/lib/pacemaker/alert_file.sh)<br />  Description: Log events to a file.<br />  Recipients:<br />   Recipient: my-alert_logfile (value=/var/log/pcmk_alert_file.log)</pre> | SAP ベーシス管理者 | 

### CloudWatch エージェントを設定する
<a name="configure-the-cw-agent"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| CloudWatch エージェントをインストールします。 | EC2 インスタンスに CloudWatch エージェントをインストールするには、いくつかの方法があります。コマンドラインを使う場合[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html)詳しくは「[CloudFront ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)」をご確認ください。 | AWS システム管理者 | 
| IAM ロールを EC2 インスタンスにアタッチする | CloudWatch エージェントで、インスタンスのデータを送信できるようにするには、IAM **CloudWatchAgentServerRole** ロールを各インスタンスにアタッチする必要があります。または、CloudWatch エージェントのポリシーを既存の IAM ロールに追加することもできます。詳しくは「[CloudFront ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent-commandline.html)」をご確認ください。 | AWS 管理者 | 
| プライマリクラスターインスタンスの Pacemaker アラートエージェントのログファイルをモニタリングするように CloudWatch エージェントを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html) | AWS 管理者 | 
| プライマリクラスターインスタンスとセカンダリクラスターインスタンスで CloudWatch エージェントを起動します。 | エージェントを起動するには、プライマリクラスターとセカンダリクラスターの EC2 インスタンスで次のコマンドを実行します。<pre>sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m<br />ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json</pre> | AWS 管理者 | 

### CloudWatch リソースをセットアップする
<a name="set-up-cw-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| CloudWatch ロググループを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html)CloudWatch エージェントは、Pacemaker アラートファイルをログストリームとして CloudWatch ロググループに転送します。 | AWS 管理者 | 
| CloudWatch メトリクスフィルターを設定します。 | メトリクスフィルターは、CloudWatch ログストリームで `stop <cluster-resource-name>` などのパターンを検索するのに役立ちます。このパターンが特定されると、メトリクスフィルターはカスタムメトリクスを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html)メトリクスフィルターは、ステップ 4 でパターンを識別すると、CloudWatch カスタムメトリクスの値 `sapcluster_abc` を **1** に更新します。CloudWatch アラーム `SAP-Cluster-QA1-ABC` はメトリクス `sapcluster_abc` をモニタリングし、メトリクスの値が **1** に変わったときに SNS 通知を送信します。これは、クラスターリソースが停止し、アクションを実行する必要があることを示します。 | AWS 管理者、SAP ベーシス管理者 | 
| SAP ASCS/SCS および ERS メトリクスの CloudWatch メトリクスアラームを設定します。 | 単一のメトリクスに基づいてアラームを作成する場合: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html) | AWS 管理者 | 
| SAP HANA メトリクスの CloudWatch メトリクスアラームを設定します。 | 前のタスクの CloudWatch メトリクスアラームを設定する手順を繰り返し、これらの変更を加えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-sap-rhel-pacemaker-clusters-by-using-aws-services.html) | AWS 管理者 | 

## 関連リソース
<a name="monitor-sap-rhel-pacemaker-clusters-by-using-aws-services-resources"></a>
+ [Triggering Scripts for Cluster Events](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/high_availability_add-on_reference/index#ch-alertscripts-HAAR) (RHEL ドキュメント)
+ [ウィザードを使用して CloudWatch エージェント設定ファイルを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) (CloudWatch ドキュメント)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html) (CloudWatch ドキュメント)
+ [静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) (CloudWatch ドキュメント)
+ [高可用性クラスターを使用した AWS への SAP HANA の手動デプロイ](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-manual-deployment-of-sap-hana-on-aws-with-high-availability-clusters.html) ( AWS ウェブサイトの SAP ドキュメント)
+ [SAP NetWeaver ガイド ](https://docs.aws.amazon.com/sap/latest/sap-netweaver/welcome.html)( AWS ウェブサイトの SAP ドキュメント)

## アタッチメント
<a name="attachments-ca4d282e-eadd-43fd-8506-3dbeb43e4db6"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/ca4d282e-eadd-43fd-8506-3dbeb43e4db6/attachments/attachment.zip)」

# CloudWatch Logs Insights を使用してアプリケーションアクティビティをモニタリングする
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights"></a>

*Amazon Web Services、Ram Kandaswamy*

## 概要
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-summary"></a>

このパターンでは、Amazon CloudWatch Logs Insights を使用することで、アプリケーションにおける課題の自動検出とアラートを実装する手法を説明します。自動のログ分析とアラートを実装することで、本番環境のアプリケーションの問題をすばやく特定して対応できます。

ログは、システム動作のモニタリング、問題の特定、最適なパフォーマンスの確保において重要な役割を果たします。移行プロセス中、ログファイルは、新しい環境でのシステムの機能検証、互換性の問題の検出、予期しない動作の特定に役立ちます。発生する問題は、オペレーションやセキュリティに起因するものがほとんどです。セキュリティ関連の問題において、不正アクセスの試みや疑わしいアクティビティの早期検出は、セキュリティと規制の遵守に不可欠です。機密データや重要なシステムを扱う際には特に重要な要素となります。

このパターンは、以下を行う必要があるチームにとって特に重要です。
+ アプリケーションの高可用性を維持します。
+ 本番環境の問題に迅速に対応します。
+  AWS のサービス ログでキャプチャされないアプリケーション固有のエラーを分析します。
+ 事前構築されたインフラストラクチャなしでオンデマンドログ分析を実行します。

CloudWatch Logs Insights は、アプリケーションコード内にのみエラーコンテキストが存在するアプリケーション生成ログを分析するのに最適です。CloudWatch Logs Insights は、次のタスクに優れています。
+ 非構造化または半構造化ログデータをクエリします。
+ インシデント対応中にオンデマンド分析を実行します。
+ 複数のロググループ間でイベントを関連付けます。
+ 外部ツールを使用せずにクイックビジュアライゼーションを作成します。

## 前提条件と制限
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-prereqs"></a>

**前提条件**
+ アクティブにデプロイされた本稼働アプリケーション AWS アカウント
+ 本番環境のアプリケーションにおけるログの記録形式と例外パターンの基本理解
+ Amazon CloudWatch Logs へのストリーミング設定を行ったアプリケーションログ

**制限事項**
+ 一部の 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)」を参照して、サービスのリンクを選択してください。

## アーキテクチャ
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-architecture"></a>

次の図は、CloudWatch Logs Insights がリソースログを評価し、関連する視覚データを CloudWatch ダッシュボードに送信する流れを示しています。

![\[CloudWatch Logs Insights はリソースログを評価し、視覚データをダッシュボードに送信します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/082ff4b6-9303-42e6-bc62-263e2254f232/images/b1cbb699-07cd-45e6-ac06-839159bafa6b.png)


この図表は、次のワークフローを示しています:

1. リソースが CloudWatch Logs にログを発行します。リソースには、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや Amazon Simple Storage Service (Amazon S3) バケットなどの AWS リソースを含めることができます。もう一方の例では、CloudWatch にログを発行できる CloudWatch Agent がインストールされたオンプレミスシステムが含まれます。

1. CloudWatch Logs Insights は、関連するパターン文字列をフィルタリングします。検索パターン文字列の例には「エラー」や「例外」、あるいは特定の正規表現が含まれます。

1. 視覚パターンの CloudWatch ダッシュボードへの追加は、通常、本番環境のサポートチームおよび開発者が行います。

**自動化とスケール**

開発者は AWS Cloud Development Kit (AWS CDK)、、、または AWS SDKs を使用して複数の文字列パターンを処理することで AWS CloudFormation、このパターンのソリューションを自動化できます。また、この自動化プロセスは継続的インテグレーションやデプロイ (CI/CD) DevOps プロセスに組み込むこともできます。

## ツール
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-tools"></a>

**AWS のサービス**
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、 からのログを一元化 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) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。

## ベストプラクティス
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-best-practices"></a>

**クエリ効率**
+ [ロググループ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)の定義・設定を行うことで、関連するログデータの分析ができます。
+ フィールドエクスプローラーを使えば、ログデータで利用可能な構造とフィールドに対する理解を深めることができます。
+ [CloudWatch Logs Insights のクエリ構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_LogsInsights.html)を使用することで、クエリを効率的に記述できます。
+ [サンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)を特定の要件に合わせて調整すれば、迅速な分析が可能です。
+ クエリの時間範囲を制限して、スキャンされるデータを減らし、パフォーマンスを向上させます。
+ [クエリを保存](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Saving-Queries.html)しておけば、将来的に再利用でき、時間の節約と安定した分析に寄与します。

**セキュリティ**
+ CloudWatch Logs Insights とロググループに適切な IAM [ポリシー](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-access-control-overview-cwl.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)」を参照してください。
+ 機密ログデータを扱う際には、[AWS KMSを使用してデータ暗号化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Encrypt.html)を有効にします。

**コスト最適化**
+ CloudWatch Logs Insights は、クエリごとにスキャンされたデータの GB ごとに課金されます。時間範囲を絞り込み、特定のロググループをターゲットにしてコストを削減します。
+ 適切なログ保持ポリシーを設定して、ストレージコストを管理します。
+ 大規模な履歴データセットを頻繁に分析するには、ログを Amazon S3 にエクスポートしAmazon Athena を使用することを検討してください。
+ [CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)を確認して、ユースケースのコストへの影響を理解します。

## エピック
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-epics"></a>

### ロググループを作成し、ダッシュボード上に表示されるように設定します。
<a name="create-log-group-and-configure-logs-to-view-in-dashboard"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| IAM 許可を設定します。 | 次の設定を行い、IAM のアクセスを許可してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-application-activity-by-using-cloudwatch-logs-insights.html)IAM ポリシーを作成する方法、または既存のポリシーにアクセス許可を追加する方法について、詳しくは *IAM ユーザーガイド*の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」および「[IAM ポリシーを編集する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」をご確認ください。さらに詳しくは、*Amazon CloudWatch Logs ユーザーガイド*の「[Identity and access management for Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/auth-and-access-control-cwl.html)」および「[CloudWatch Logs permissions reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/permissions-reference-cwl.html)」をご確認ください。 | AWS 管理者、AWS DevOps、AWS システム管理者、クラウド管理者、クラウドアーキテクト、DevOps エンジニア | 
| ロググループを作成します。 | ロググループの作成には次のいずれかの作業を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-application-activity-by-using-cloudwatch-logs-insights.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-application-activity-by-using-cloudwatch-logs-insights.html) | AWS 管理者、AWS DevOps、AWS システム管理者、クラウド管理者、クラウドアーキテクト、DevOps エンジニア | 
| CloudWatch Logs Insights クエリを作成します。 | CloudWatch Logs Insights クエリを作成して保存するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-application-activity-by-using-cloudwatch-logs-insights.html) | AWS 管理者、AWS DevOps、AWS システム管理者、クラウド管理者、クラウドアーキテクト、DevOps エンジニア | 
| CloudWatch ダッシュボードで視覚データを作成します。 | 以下の手順に従い、CloudWatch ダッシュボードで視覚データを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-application-activity-by-using-cloudwatch-logs-insights.html)ダッシュボードのオプションと機能について、詳しくは *Amazon CloudWatch Logs ユーザーガイド*の「[Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」および「[ダッシュボード変数を使用した柔軟な CloudWatch ダッシュボードの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)」をご確認ください。 | AWS 管理者、AWS DevOps、AWS システム管理者、クラウド管理者、クラウドアーキテクト、DevOps エンジニア | 

## トラブルシューティング
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| クエリ結果を表示できない、またはクエリが破損している | [サンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)を修正した作業クエリを確認します。クエリの一部 (フィルターやフィールドなど) に小さな増分変更を実行し、CloudWatch Logs の[クエリジェネレーター機能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html)を活用します。 | 
| ロググループがログストリームを生成しない | IAM ポリシーで、[CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html) オペレーションと [CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) オペレーションのリソースにワイルドカード文字 `(*)` の値が提供されていることを確認します。このワイルドカードアクセス許可がないと、`create ` オペレーションは成功しません。 | 
| クエリのタイムアウトまたはパフォーマンスの低下 | 時間範囲を短縮するか、特定のロググループをターゲットにするか、クエリを簡素化します。複雑な正規表現 (`regex`) パターンと大きな時間範囲により、クエリ時間が長くなります。 | 
| 有効な時間範囲のデータは返されません | ロググループの選択を検証し、ログが取り込まれていることを確認し (ログストリームのレビュー）、フィルターパターンがログ形式と一致することを確認します。 | 

## 関連リソース
<a name="monitor-application-activity-by-using-cloudwatch-logs-insights-resources"></a>
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch のよくある質問](https://aws.amazon.com/cloudwatch/faqs/#topic-0)
+ [ダッシュボード変数を使用した柔軟な CloudWatch ダッシュボードの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)
+ [Logs Insights QL の使用を開始する: クエリチュートリアル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Tutorials.html)
+ [自然言語を使用して CloudWatch Logs Insights クエリを生成および更新する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html)
+ [AWS SDK または CLI で PutDashboard を使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/example_cloudwatch_PutDashboard_section.html)
+ [ロググループとログストリームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)

# 複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts"></a>

*Amazon Web Services、Naveen Suthar、Sandeep Gawande*

## 概要
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-summary"></a>

[Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) は、Amazon Web Services (AWS) 環境で Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成するために使用されます。AMI は、一つの集中管理された AWS アカウントで作成できます。このパターンでは、これを*作成者アカウント*と呼びます。その後、同じ にある複数の 間で AMI を共有できます AWS アカウント 。これは AWS リージョン、このパターンでは*コンシューマーアカウント*と呼ばれます。1 つのアカウントから AMI を管理することでスケーラビリティが向上し、ガバナンスを簡単に行うことができます。コンシューマーアカウントでは、Amazon EC2 Auto Scaling「[起動テンプレート](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html)」と Amazon Elastic Kubernetes Service (Amazon EKS)「[ノードグループ](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)」の共有 AMI を参照できます。

共有 AMI が「[非推奨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html)」、「[登録解除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html)」または「[共有解除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)」になると、コンシューマーアカウントでその AMI を参照する AWS のサービス はこの AMI を使用して新しいインスタンスを起動できなくなります。自動スケーリングイベントまたは同じインスタンスの再起動は失敗します。これにより、アプリケーションのダウンタイムやパフォーマンスの低下など、本番環境で問題が生じる可能性があります。AMI 共有イベントと使用状況イベントが複数の で発生する場合 AWS アカウント、このアクティビティをモニタリングするのは難しい場合があります。

このパターンは、同じリージョンのアカウント間での共有 AMI の使用状況とステータスをモニタリングするのに役立ちます。Amazon EventBridge AWS のサービス、Amazon DynamoDB、Amazon Simple Email Service ( AWS Lambda Amazon SES) などのサーバーレスを使用します。HashiCorp Terraform を使用して、Infrastructure as Code (IaC) としてプロビジョニングします。このソリューションは、コンシューマーアカウントのサービスが登録解除または共有されていない AMI を参照したときにアラートを発行します。

## 前提条件と制限
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-prereqs"></a>

**前提条件**
+ 2 つ以上のアクティブ AWS アカウント: 1 つの作成者アカウントと 1 つ以上のコンシューマーアカウント
+ クリエーターアカウントからコンシューマーアカウントに共有される 1 つ以上の AMI
+ 「[インストール済み](https://developer.hashicorp.com/terraform/cli)」Terraform CLI(Terraform のドキュメント)
+ Terraform AWS Provider、[設定](https://hashicorp.github.io/terraform-provider-aws/)済み (Terraform ドキュメント)
+ (オプションであるが、推奨)「[設定済み](https://developer.hashicorp.com/terraform/language/backend)」Terraform バックエンド(Terraform のドキュメント)
+ 「[インストール済み](https://github.com/git-guides/install-git)」Git

**制限事項**
+ このパターンは、アカウント ID を使用して特定のアカウントと共有されている AMI をモニタリングします。このパターンでは、組織 ID を使用して組織と共有されている AMI はモニタリングされません。
+ AMI は、同じ AWS リージョン内のアカウントにのみ共有できます。このパターンは、単一のターゲットリージョン内の AMI をモニタリングします。複数のリージョンでの AMI の使用状況をモニタリングするには、このソリューションを各リージョンにデプロイします。
+ このパターンでは、このソリューションがデプロイされる前に共有されていた AMI はモニタリングされません。以前に共有していた AMI をモニタリングしたい場合は、AMI 共有を解除してからコンシューマーアカウントと再共有できます。

**製品バージョン**
+ Terraform バージョン 1.2.0 以降
+ Terraform AWS プロバイダーバージョン 4.20 以降

## アーキテクチャ
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-architecture"></a>

**ターゲットテクノロジースタック**

以下のリソースは Terraform を通じて IaC としてプロビジョニングされます。
+ Amazon DynamoDB テーブル
+ Amazon EventBridge ルール
+ AWS Identity and Access Management (IAM) ロール
+ AWS Lambda 関数
+ Amazon SES

**ターゲットアーキテクチャ**

![\[共有 AMI の使用状況をモニタリングし、AMI が共有解除または登録解除された場合にユーザーに警告するアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2d709249-0c68-47d7-be5d-46e8a73071ed/images/8c48c4dd-d681-4c32-9ba8-8f5ad2d66f64.png)


この図表は、次のワークフローを示しています:

1. クリエーターアカウントのすべての AMI は、同じ AWS リージョンのコンシューマーアカウントと共有されます。

1. AMI が共有されると、作成者アカウントの EventBridge ルールが `ModifyImageAttribute` イベントをキャプチャし、作成者アカウントで Lambda 関数を開始します。

1. Lambda 関数は、作成者アカウントの DynamoDB テーブルに AMI に関連するデータを格納します。

1. コンシューマーアカウントの AWS のサービス が共有 AMI を使用して Amazon EC2 インスタンスを起動する場合、または共有 AMI が起動テンプレートに関連付けられている場合、コンシューマーアカウントの EventBridge ルールは共有 AMI の使用をキャプチャします。

1. EventBridge ルールは、コンシューマーアカウントで Lambda 関数を起動します。Lambda 関数は以下を実行します。

   1. Lambda 関数は、作成者アカウントの DynamoDB テーブルに AMI 関連データを格納します。

   1. Lambda 関数は作成者アカウントの IAM ロールを引き受け、作成者アカウントの Lambda テーブルを更新します。`Mapping` テーブルでは、インスタンス ID または起動テンプレート ID をそれぞれの AMI ID にマッピングする項目を作成します。

1. 作成者アカウントで一元管理されている AMI は非推奨、登録解除または共有解除されました。

1. 作成者アカウントのEventBridge ルールは、`remove` アクションを含む `ModifyImageAttribute` または `DeregisterImage` イベントをキャプチャし、Lambda関数を起動します。

1. Lambda 関数は DynamoDB テーブルをチェックして、AMI がいずれかのコンシューマーアカウントで使用されているかを判断します。AMI に関連付けられているインスタンス ID または起動テンプレート ID が `Mapping` テーブルにない場合は、プロセスは完了です。

1. インスタンス ID または起動テンプレート ID が `Mapping` テーブル内の AMI に関連付けられている場合、Lambda 関数は Amazon SES を使用して、設定したサブスクライバーにメール通知を送信します。

## ツール
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-tools"></a>

**AWS のサービス**
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。
+ 「[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 リソースへのアクセスを安全に管理するのに役立ちます。
+ [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)」はユーザー自身のメールアドレスとドメインを使用してメールを送受信する上で役立ちます。

**その他のツール**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのを支援する Infrastructure as Code (IaC) ツールです。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。

**コードリポジトリ**

このパターンのコードは、GitHub 内の「[cross-account-ami-monitoring-terraform-samples](https://github.com/aws-samples/cross-account-ami-monitoring-terraform-samples)」リポジトリで利用できます。

## ベストプラクティス
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-best-practices"></a>
+ [AWS Lambda 関数を使用する際のベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)に従ってください。
+ 「[AMI 構築のベストプラクティス](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html)」に従ってください。
+ IAM ロールを作成するときは、最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、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)」を参照してください。
+  AWS Lambda 関数のモニタリングとアラートを設定します。詳細については、「[Lambda 関数をモニタリングおよびトラブルシューティングする](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)」を参照してください。

## エピック
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-epics"></a>

### Terraform 設定ファイルをカスタマイズします。
<a name="customize-the-terraform-configuration-files"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  AWS CLI 名前付きプロファイルを作成します。 | 作成者アカウントと各コンシューマーアカウントで、 AWS Command Line Interface (AWS CLI) という名前のプロファイルを作成します。手順については、 AWS 「 入門リソースセンター」の[「 のセットアップ AWS CLI](https://aws.amazon.com/getting-started/guides/setup-environment/module-three/)」を参照してください。 | DevOps エンジニア | 
| リポジトリのクローン作成 | 次のコマンドを入力します。これにより、SSH を使用して GitHub から「[ cross-account-ami-monitoring-terraform-samples ](https://github.com/aws-samples/cross-account-ami-monitoring-terraform-samples)」リポジトリのクローンが作成されます。<pre>git clone git@github.com:aws-samples/cross-account-ami-monitoring-terraform-samples.git</pre> | DevOps エンジニア | 
| プロバイダーの.tf ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html)プロバイダーの構成について、詳細は、Terraform ドキュメントの「[複数のプロバイダー設定](https://developer.hashicorp.com/terraform/language/providers/configuration#alias-multiple-provider-configurations)」を参照してください。 | DevOps エンジニア | 
| テラフォーム.tfvars ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 
| メイン.tf ファイルを更新します。 | この手順は、このソリューションを複数のコンシューマーアカウントにデプロイする場合にのみ実行します。このソリューションを 1 つのコンシューマーアカウントにのみデプロイする場合、このファイルを変更する必要はありません。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 

### Terraform を使用してソリューションをデプロイ
<a name="deploy-the-solution-by-using-terraform"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ソリューションのデプロイ | Terraform CLI で、次のコマンドを入力して、作成者アカウントとコンシューマーアカウントに AWS リソースをデプロイします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 
| メールアドレス ID を検証します。 | Terraform プランをデプロイすると、Terraform は Amazon SES のコンシューマーアカウントごとにメールアドレス ID を作成しました。該当メールアドレスに通知を送信する前に、メールアドレスを検証する必要があります。手順については、「Amazon SES ドキュメント」の「[メールアドレスアイデンティの検証](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#just-verify-email-proc)」を参照してください。 | AWS 全般 | 

### リソースデプロイを検証
<a name="validate-resource-deployment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| クリエイターアカウントによるデプロイを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 
| コンシューマアカウントによるデプロイを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 

### モニタリング検証
<a name="validate-monitoring"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| クリエイターアカウントで AMI を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 
| コンシューマーアカウントで AMI を使用します。 | コンシューマーアカウントで、共有 AMI を使用して Amazon EC2 インスタンスを作成するか、テンプレートを起動します。手順については、[「カスタム AMI から Amazon EC2 インスタンスを起動する方法](https://repost.aws/knowledge-center/launch-instance-custom-ami)」 (AWS re:Post Knowledge Center) または[Auto Scaling グループの起動テンプレートを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)」 (Amazon EC2 Auto Scaling ドキュメント) を参照してください。 | DevOps エンジニア | 
| モニタリングとアラートを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 

### (オプション) 共有 AMI のモニタリングを停止
<a name="optional-stop-monitoring-shared-amis"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リソースを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | DevOps エンジニア | 

## トラブルシューティング
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| メールアラートを受信していません。 | Amazon SES の電子メールが送信されなかった理由は複数考えられます。以下をチェックしてください:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.html) | 

## 関連リソース
<a name="monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts-resources"></a>

**AWS ドキュメント**
+ 「[Python による Lambda 関数の構築](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)」(Lambda のドキュメント)
+ 「[AMI を作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami.html)」(Amazon EC2 のドキュメント)
+ 「[特定の AWS アカウントとの AMI の共有](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)」(Amazon EC2 ドキュメント)
+ 「[AMI の登録の解除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html)」(Amazon EC2 のドキュメント)

Terraformのドキュメント
+ 「[Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)」
+ 「[Terraform バックエンド設定](https://www.terraform.io/language/settings/backends/configuration)」
+ 「[Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)」
+ 「[Terraform バイナリのダウンロード](https://developer.hashicorp.com/terraform/install)」

# AWS アカウントまたは組織の EBS スナップショットの詳細を表示
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization"></a>

*Amazon Web Services、Arun Chandapillai と Parag Nagwekar*

## 概要
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-summary"></a>

このパターンでは、Amazon Web Services (AWS) アカウントまたは AWS Organizations の組織単位 (OU) にあるすべての Amazon Elastic Block Store (Amazon EBS) スナップショットのオンデマンドレポートを自動的に生成する方法を示します。 

Amazon EBS は、Amazon Elastic Compute Cloud (Amazon EC2) のために設計された、使いやすくスケーラブルな高性能ブロックストレージサービスです。EBS ボリュームは、耐久性に優れた永続的なストレージで、EC2 インスタンスに添付することができます。EBS ボリュームをデータのプライマリストレージとして使用し、スナップショットを作成することで EBS ボリュームのポイントインタイムバックアップを作成します。AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、特定の EBS スナップショットの詳細を表示します。このパターンでは、AWS アカウントまたは OU 内のすべての EBS スナップショットに関する情報をプログラムで取得する方法を提供します。

このパターンで提供されるスクリプトを使用して、各スナップショットに関するアカウント ID、スナップショット ID、ボリューム ID とサイズ、スナップショットの作成日、インスタンス ID、説明などの情報を含むカンマ区切り値 (CSV) ファイルを生成できます。EBS スナップショットにタグが付いている場合、レポートには所有者属性とチーム属性も含まれます。

## 前提条件と制限
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-prereqs"></a>

**前提条件**
+ アクティブなAWS アカウント
+ [インストール済み](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#getting-started-install-instructions) 、及び[設定済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」のAWS CLI バージョン2
+ 適切な権限 (特定のアカウント、または AWS Organizations からスクリプトを実行する予定の場合、 OU のすべてのアカウントのアクセス許可) を持つ AWS アイデンティティおよびアクセス管理 (IAM) ロール

## アーキテクチャ
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-architecture"></a>

次の図表には、OU の複数の AWS アカウントに分散している EBS スナップショットのオンデマンドレポートを生成するスクリプトワークフローを示しています。

![\[OU 全体の EBS スナップショットのオンデマンドレポートの生成。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4e8b1812-2731-4f46-8385-0dd4d92f2d03/images/62d10408-7c85-46cf-a6a4-fe87a6e446f2.png)


## ツール
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-tools"></a>

**AWS サービス**
+ 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) は、EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。 
+ 「[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 アカウントを組織に統合するためのアカウント管理サービスです。

**コード**

このパターンで使用されているサンプルアプリケーションのコードは、GitHub の [aws-ebs-snapshots-awsOrganizations](https://github.com/aws-samples/aws-ebs-snapshots-awsorganizations) リポジトリにあります。次のセクションの指示に従って、サンプルファイルを使用します。

## エピック
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-epics"></a>

### スクリプトをダウンロードします。
<a name="download-the-script"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Python スクリプトをダウンロードします。 | [GitHub リポジトリ](https://github.com/aws-samples/aws-ebs-snapshots-awsorganizations)からスクリプト [GetSnapshotDetailsAllAccountsOU.py](https://github.com/aws-samples/aws-ebs-snapshots-awsorganizations/blob/main/GetSnapshotDetailsAllAccountsOU.py) をダウンロードします。 | AWS 全般 | 

### AWS アカウントの EBS スナップショットの詳細を取得
<a name="get-ebs-snapshot-details-for-an-aws-account"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  Python スクリプトを実行します。 |  コマンドを実行します。<pre>python3 getsnapshotinfo.py --file <output-file>.csv --region <region-name> </pre>ここで、`<output-file>` は、配置された EBS スナップショットに関する情報が必要な CSV 出力ファイルを指し、`<region-name>` スナップショットが保存されている AWS リージョンを指します。例：<pre>python3 getsnapshotinfo.py --file snapshots.csv --region us-east-1 </pre> | AWS 全般 | 

### 組織の EBS スナップショットの詳細を取得
<a name="get-ebs-snapshot-details-for-an-organization"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
|  Python スクリプトを実行します。 |  コマンドを実行します。<pre>python3 getsnapshotinfo.py --file <output-file>.csv --role <IAM-role> --region <region-name> </pre>ここで、`<output-file>` は EBS スナップショットに関する情報を格納する CSV 出力ファイルを指し、`<IAM-role>` はAWS Organizations にアクセスするための権限を提供するロールで、`<region-name>` はスナップショットが保存されている AWS リージョンを指します。例：<pre>python3 getsnapshotinfo.py --file snapshots.csv --role <IAM role> --region us-west-2</pre> | AWS 全般 | 

## 関連リソース
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-resources"></a>
+ [Amazon EBS ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon EBS アクション](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/OperationList-query-ebs.html)
+ [Amazon ECS API リファレンス](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ebs/index.html)
+ [Amazon EBS パフォーマンスの向上](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+ [Amazon EBS リソース](https://aws.amazon.com/ebs/resources/)
+ [EBS スナップショットの料金](https://aws.amazon.com/ebs/pricing/)

## 追加情報
<a name="view-ebs-snapshot-details-for-your-aws-account-or-organization-additional"></a>

**EBS スナップショットタイプ**

Amazon EBS には、所有権とアクセスに基づいて 3 種類のスナップショットが用意されています。
+ **Owned by you** –** **デフォルトでは、自分が所有するスナップショットからのみボリュームを作成できます。
+ **パブリックスナップショット** – スナップショットは他のすべての AWS アカウントとパブリックに共有できます。スナップショットの権限を変更することで、指定した AWS アカウントとスナップショットを共有できます。許可を受けたユーザーは、共有するスナップショットを使用して自分の EBS ボリュームを作成できますが、元のスナップショットは影響を受けません。必要に応じて、暗号化されていないスナップショットをすべての AWS ユーザーに一般公開することもできます。暗号化されたスナップショットを公開することはできません。パブリックスナップショットは、個人データや機密データを公開する可能性があるため、重大なセキュリティリスクをもたらします。EBS スナップショットをすべての AWS アカウントと共有しないことを推薦します。DB スナップショットをコピーする方法については、[AWS ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html)を参照してください。
+ **プライベートスナップショット** – 指定した個々の AWS アカウントとスナップショットをプライベートに共有できます。スナップショットを特定の AWS アカウントと**プライベート**に共有するには、AWS ドキュメントの[指示](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-unencrypted-snapshot) に従い、権限設定でプライベートを選択します。許可を受けたユーザーは、共有するスナップショットを使用して自分の EBS ボリュームを作成できますが、元のスナップショットは影響を受けません。

**概要と手順**

次のテーブルには、未使用のスナップショットを見つけて削除することで EBS ボリュームコストを削減する方法や、頻繁または高速に取得する必要のない、ほとんどアクセスされないスナップショットをアーカイブする方法など、EBS スナップショットに関する詳細情報へのリンクが記載されています。 


| 
| 
| 参考情報 | 「」を参照してください | 
| --- |--- |
| **スナップショット、その機能、制限事項** | [Amazon EBS スナップショットの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) | 
| **スナップショットを作成する方法** | コンソール：[スナップショットの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html#ebs-create-snapshot)AWS CLI： [スナップショット作成コマンド](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-snapshot.html)例：<pre>aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description " volume snapshot"</pre> | 
| **スナップショットの削除 (一般情報)** | [Amazon EBS スナップショットの削除](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-deleting-snapshot.html) | 
| **スナップショットを削除するには** | コンソール：[スナップショットを削除](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-deleting-snapshot.html#ebs-delete-snapshot)AWS CLI：[スナップショットの削除コマンド](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-snapshot.html)例：<pre>aws ec2 delete-snapshot --snapshot-id snap-1234567890abcdef0</pre> | 
| **スナップショットのアーカイブ (一般情報)** | [Amazon EBS スナップショットのアーカイブ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/snapshot-archive.html)[Amazon EBS Snapshots Archive](https://aws.amazon.com/blogs/aws/new-amazon-ebs-snapshots-archive/)（ブログ投稿） | 
| **スナップショットをアーカイブするには** | コンソール：[スナップショットをアーカイブ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/working-with-snapshot-archiving.html#archive-snapshot)AWS CLI：[modify-snapshot-tierコマンド](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-snapshot-tier.html) | 
| **アーカイブされたスナップショットを取得する方法** | コンソール：[アーカイブされたスナップショットの復元](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/working-with-snapshot-archiving.html#restore-archived-snapshot)AWS CLI：[restore-snapshot-tier コマンド](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/restore-snapshot-tier.html) | 
| **スナップショットの料金** | [Amazon EBS の料金](https://aws.amazon.com/ebs/pricing/) | 

**よくある質問**

**最小アーカイブ期間は？**

最小アーカイブ期間は 90 日です。

**アーカイブされたスナップショットを復元するにはどのくらいの時間がかかりますか?**

スナップショットのサイズによっては、アーカイブ階層から標準階層にアーカイブスナップショットを復元するのに最大 72 時間かかる場合があります。

**アーカイブされるスナップショットは、完全なスナップショットですか。**

アーカイブされるスナップショットは、常に完全なスナップショットです。

**ユーザーはどのスナップショットをアーカイブできますか?**

アーカイブできるのは、アカウント内で所有しているスナップショットだけです。

**登録済みの Amazon マシンイメージ (AMI) ルートデバイスボリュームにあるスナップショットは、アーカイブできますか。**

登録済みの AMI ルートデバイスボリュームにあるスナップショットは、アーカイブできません。

**スナップショットを共有する場合のセキュリティ上の考慮事項は?**

スナップショットを共有すると、スナップショットのすべてのデータに他人がアクセスできるようになります。スナップショットの共有は、委託できる人とだけ行ってください。

**スナップショットを別の AWS リージョンと共有する方法は?**

スナップショットは、スナップショットが作成されたリージョンに制限されます。別のリージョンとスナップショットを共有するには、そのリージョンにスナップショットをコピーして、そのコピーを共有します。

**暗号化されたスナップショットの共有方法?**

デフォルトの AWS 管理キーで暗号化されたスナップショットを共有することはできません。共有できるのは、カスタマーマネージド型キーを使用して暗号化されたスナップショットだけです。暗号化されたスナップショットを共有する場合は、スナップショットの暗号化に使用するカスタマーマネージド型キーも共有する必要があります。

**暗号化されていないスナップショットについてはどうですか?**

暗号化されていないスナップショットのみをパブリックに共有できます。

# その他のパターン
<a name="governance-more-patterns-pattern-list"></a>

**Topics**
+ [で Landing Zone Accelerator を使用してアカウントの作成を自動化する AWS](automate-account-creation-lza.md)
+ [Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する](automate-aws-infrastructure-operations-by-using-amazon-bedrock.md)
+ [AWS リソース評価を自動化する](automate-aws-resource-assessment.md)
+ [複数のアカウントとリージョンの AWS リソースを自動的にインベントリする](automate-aws-resource-inventory.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)
+ [Terraform を使用して Amazon Managed Grafana での Amazon MWAA カスタムメトリクスの取り込みと視覚化を自動化する](automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.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)
+ [既存および新規の Amazon EBS ボリュームを自動的に暗号化する](automatically-encrypt-existing-and-new-amazon-ebs-volumes.md)
+ [MongoDB Atlas を含む AWS ランディングゾーンを構築する](build-aws-landing-zone-that-includes-mongodb-atlas.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)
+ [Amazon ECS タスク定義を作成し、Amazon EFS を使用して EC2 インスタンスにファイルシステムをマウントする](create-an-amazon-ecs-task-definition-and-mount-a-file-system-on-ec2-instances-using-amazon-efs.md)
+ [AWS CloudFormation Guard ポリシーを使用して AWS Config カスタムルールを作成する](create-aws-config-custom-rules-by-using-aws-cloudformation-guard-policies.md)
+ [AWS CDK アスペクトとエスケープハッチを使用してデフォルトのロール名をカスタマイズする](customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.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)
+ [AWS CodePipeline、AWS CodeCommit、AWS CodeBuild を使用して、複数の AWS リージョンにコードをデプロイする](deploy-code-in-multiple-aws-regions-using-aws-codepipeline-aws-codecommit-and-aws-codebuild.md)
+ [Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md)
+ [AWS CloudFormation テンプレートを使用して Amazon GuardDuty を条件付きで有効にする](enable-amazon-guardduty-conditionally-by-using-aws-cloudformation-templates.md)
+ [IBM Db2 データベースで Amazon S3 への DB2 ログアーカイブを直接有効にする](enable-db2-logarchive-directly-to-amazon-s3-in-ibm-db2-database.md)
+ [PowerShell を使用して AWS IAM アイデンティティセンターのアイデンティティとその割り当てに関するレポートをエクスポートする](export-a-report-of-aws-iam-identity-center-identities-and-their-assignments-by-using-powershell.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)
+ [Stonebranch ユニバーサルコントローラーと AWS Mainframe Modernizationを統合](integrate-stonebranch-universal-controller-with-aws-mainframe-modernization.md)
+ [Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md)
+ [Terraform を使用して AWS アクセス許可セットを動的に管理する](manage-aws-permission-sets-dynamically-by-using-terraform.md)
+ [appcmd.exe を使用して IIS がホストするアプリケーションを Amazon EC2 に移行する](migrate-iis-hosted-applications-to-amazon-ec2-by-using-appcmd.md)
+ [ACM を使用して Windows SSL 証明書をApplication Load Balancer に移行](migrate-windows-ssl-certificates-to-an-application-load-balancer-using-acm.md)
+ [IAM ルートユーザーのアクティビティを監視する](monitor-iam-root-user-activity.md)
+ [Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する](multi-region-ipam-architecture.md)
+ [AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する](optimize-multi-account-serverless-deployments.md)
+ [非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md)
+ [ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする](provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.md)
+ [Amazon SES を使用して 1 つの E メールアドレス AWS アカウント に複数の を登録する](register-multiple-aws-accounts-with-a-single-email-address-by-using-amazon-ses.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)
+ [Amazon Macie を使用して CloudWatch Logs で機密データを保護する](secure-cloudwatch-logs-using-macie.md)
+ [オンプレミスの SMTP サーバーとデータベースメールを使用して、Amazon RDS for SQL Server データベースインスタンスに通知を送信します。](send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.md)
+ [AWS ParallelCluster 用の Grafana モニタリングダッシュボードを設定する](set-up-a-grafana-monitoring-dashboard-for-aws-parallelcluster.md)
+ [Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する](set-up-centralized-logging-at-enterprise-scale-by-using-terraform.md)
+ [AWS の IBM Db2 に SAP のディザスタリカバリをセットアップ](set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.md)
+ [Amazon Bedrock エージェントと を使用して Amazon EC2 コンプライアンス管理を合理化する AWS Config](streamline-amazon-ec2-compliance-management-with-amazon-bedrock-agents-and-aws-config.md)
+ [AWS Organizations を使用して Transit Gateway アタッチメントに自動的にタグを付ける](tag-transit-gateway-attachments-automatically-using-aws-organizations.md)
+ [BMC ディスカバリークエリを使用して移行計画のために移行データを抽出](use-bmc-discovery-queries-to-extract-migration-data-for-migration-planning.md)
+ [を使用して PCI DSS 4.0 の運用上のベストプラクティスを検証する AWS Config](verify-ops-best-practices-pci-dss-4.md)
+ [Splunk を使用して AWS Network Firewall のログとメトリクスを表示する](view-aws-network-firewall-logs-and-metrics-by-using-splunk.md)
+ [Amazon Quick Sight を使用してすべての AWS アカウントの IAM 認証情報レポートを視覚化する](visualize-iam-credential-reports-for-all-aws-accounts-using-amazon-quicksight.md)

# メッセージとコミュニケーション
<a name="messagingandcommunications-pattern-list"></a>

**Topics**
+ [Amazon MQ で RabbitMQ 設定を自動化する](automate-rabbitmq-configuration-in-amazon-mq.md)
+ [Amazon Connect コンタクトセンターのエージェントワークステーションの通話品質を向上](improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.md)
+ [その他のパターン](messagingandcommunications-more-patterns-pattern-list.md)

# Amazon MQ で RabbitMQ 設定を自動化する
<a name="automate-rabbitmq-configuration-in-amazon-mq"></a>

*Yogesh Bhatia、Afroz Khan (Amazon Web Services)*

## 概要
<a name="automate-rabbitmq-configuration-in-amazon-mq-summary"></a>

[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/) は、多くの人気メッセージブローカーとの互換性を提供するマネージドメッセージブローカーサービスです。RabbitMQ で Amazon MQ を使用すると、複数のブローカーと設定オプション AWS クラウド を備えた で管理される堅牢な RabbitMQ クラスターが提供されます。 RabbitMQ Amazon MQ は、可用性、安全性、スケーラビリティの高いインフラストラクチャを提供し、毎秒多数のメッセージを簡単に処理します。複数のアプリケーションが、さまざまな仮想ホスト、キュー、交換でインフラストラクチャを使用できます。ただし、これらの設定オプションの管理またはインフラストラクチャの手動作成には、時間と労力が必要になることがあります。このパターンでは、単一ファイルで、RabbitMQ の構成を 1 つの手順で管理する方法について説明します。このパターンで提供されるコードは、Jenkins または Bamboo などの継続的インテグレーション（CI）ツールに組み込みできます。 

このパターンを使用して、任意の RabbitMQ クラスターを設定できます。必要なのはクラスターへの接続のみです。RabbitMQ 設定を管理する方法は他にも多くありますが、このソリューションではアプリケーション全体の設定をワンステップで作成するため、キューやその他の詳細を簡単に管理できます。

## 前提条件と制限
<a name="automate-rabbitmq-configuration-in-amazon-mq-prereqs"></a>

**前提条件**
+ AWS Command Line Interface (AWS CLI) [がインストールされ、 を指すように設定](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html)されている AWS アカウント
+ Ansible がインストールされている（プレイブックを実行して構成を作成できる）
+ **rabbitmqadmin** がインストールされている (手順については、[RabbitMQ ドキュメント](https://www.rabbitmq.com/management-cli.html)を参照)
+ 正常な Amazon CloudWatch メトリクスで作成されたAmazon MQ の RabbitMQ クラスター

**その他の要件**
+ JSON の一部としてではなく、仮想ホストとユーザーの設定を別に作成します。
+ 設定 JSON がリポジトリの一部であり、バージョン管理されていることを確認します。
+ **rabbitmqadmin** CLI のバージョンは RabbitMQ サーバーのバージョンと同じである必要があるため、最善のオプションは RabbitMQ コンソールから CLI をダウンロードすることです。
+ パイプラインの一部として、各実行前に JSON 構文が検証されていることを確認します。

**製品バージョン**
+ AWS CLI バージョン 2.0
+ Ansible バージョン 2.9.13
+ **rabbitmqadmin** バージョン 3.9.13 (RabbitMQ サーバーバージョンと同じである必要があります)

## アーキテクチャ
<a name="automate-rabbitmq-configuration-in-amazon-mq-architecture"></a>

**ソーステクノロジースタック**
+ 既存のオンプレミス仮想マシン (VM) または Kubernetes クラスター (オンプレミスまたはクラウド) で実行中の RabbitMQ クラスター

**ターゲットテクノロジースタック**
+ Amazon MQ for RabbitMQ での RabbitMQ の自動設定

**ターゲットアーキテクチャ**

RabbitMQ を設定する方法は多くあります。このパターンでは、単一 JSON ファイルにすべての設定が含まれるインポート設定機能を使用します。このファイルにはすべての設定が適用され、Bitbucket または Git などのバージョン管理システムで管理できます。このパターンは Ansible を使用して、**rabbitmqadmin** CLI で設定を実装します。

![\[Amazon MQ で RabbitMQ 設定を自動化する\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/294120b6-c95f-4cc5-bf85-5ad7e2abdad5/images/292e1284-5c9e-4c82-bb41-010fa84d8d74.png)


## ツール
<a name="automate-rabbitmq-configuration-in-amazon-mq-tools"></a>

**AWS サービス**
+ [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/) は、クラウドでメッセージブローカーを簡単にセットアップして操作できるマネージドメッセージブローカーサービスです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS Infrastructure as Code を使用してインフラストラクチャをセットアップし、クラウドプロビジョニングを高速化するのに役立ちます。
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) では、コマンドラインシェルでコマンド AWS のサービス を使用して を操作できます。 

**その他のツール**
+ [rabbitmqadmin](https://www.rabbitmq.com/management-cli.html) は RabbitMQ HTTP ベースの API 用のコマンドラインツールです。RabbitMQ ノードとクラスターの管理と監視に使用されます。
+ [Ansible](https://www.ansible.com/) は、アプリケーションと IT インフラストラクチャを自動化するオープンソースツールです。

**コードリポジトリ**

このパターンで使用する JSON 設定ファイルと Ansible プレイブックのサンプルが添付ファイルで提供されます。

## エピック
<a name="automate-rabbitmq-configuration-in-amazon-mq-epics"></a>

### AWS インフラストラクチャを作成する
<a name="create-your-aws-infrastructure"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| で RabbitMQ クラスターを作成します AWS。 | RabbitMQ クラスターがまだない場合は、 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用してスタックを作成できます AWS。または、[CloudFormation Ansible の モジュール](https://docs.ansible.com/projects/ansible/latest/collections/amazon/aws/cloudformation_module.html)を使用してスタックを作成できます。後者のアプローチでは、Ansible は、RabbitMQ インフラストラクチャの作成と設定の管理の両方のタスクに使用できます。  | AWS 全般、Ansible | 

### Amazon MQ for RabbitMQ 設定を作成する
<a name="create-the-amqlong-for-rabbitmq-configuration"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| プロパティファイルを作成します。 | 添付ファイルの JSON 設定ファイル (`rabbitmqconfig.json`) をダウンロード、または RabbitMQ コンソールからエクスポートします。 変更して、キュー、交換、バインドを設定します。この設定ファイルでは、以下が示されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-rabbitmq-configuration-in-amazon-mq.html)これらの設定は、**rabbitmqadmin** が要求するルート (/) 仮想ホストで実行されます。  | JSON | 
| Amazon MQ for RabbitMQ インフラストラクチャの詳細を取得します。 | で RabbitMQ インフラストラクチャの以下の詳細を取得します AWS。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-rabbitmq-configuration-in-amazon-mq.html) AWS マネジメントコンソール または を使用して、この情報 AWS CLI を取得できます。これらの詳細により、Ansible プレイブックは に接続 AWS アカウント し、RabbitMQ クラスターを使用してコマンドを実行できます。Ansible プレイブックを実行するコンピュータは、*「前提条件*」セクションで説明されているように AWS アカウント、 にアクセスできる必要があり、既に設定されている AWS CLI 必要があります。 | AWS 全般 | 
| `hosts_var` ファイルの作成 | Ansible の `hosts_var` ファイルを作成し、すべての変数がファイルで定義されていることを確認します。Ansible Vault を使用してパスワードを保存することを検討します。`hosts_var` ファイルは次のように設定できます（アスタリスクと情報を入れ替えます）。<pre>RABBITMQ_HOST: "***********.mq.us-east-2.amazonaws.com"<br />RABBITMQ_VHOST: "/"<br />RABBITMQ_USERNAME: "admin"<br />RABBITMQ_PASSWORD: "*******"</pre> | Ansible | 
| Ansible プレイブックを作成します。 | サンプルプレイブックについては、添付の `ansible-rabbit-config.yaml` を参照してください。このファイルをダウンロードして保存します。Ansible プレイブックは、アプリケーションが必要とするキュー、交換、バインドなどのすべての RabbitMQ 設定をインポートして、管理します。 パスワードの保護など、Ansible プレイブックのベストプラクティスに従います。パスワードの暗号化には Ansible Vault を使用し、暗号化されたファイルから RabbitMQ パスワードを取得します。 | Ansible | 

### 設定をデプロイする
<a name="deploy-the-configuration"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| プレイブックを実行します。 | 前のエピックで作成した Ansible プレイブックを実行します。<pre>ansible-playbook ansible-rabbit-config.yaml</pre>RabbitMQ コンソールで新しい設定を確認できます。 | 一般的な AWS、RabbitMQ、Ansible | 

## 関連リソース
<a name="automate-rabbitmq-configuration-in-amazon-mq-resources"></a>
+ [RabbitMQ から Amazon MQ への移行](https://aws.amazon.com/blogs/compute/migrating-from-rabbitmq-to-amazon-mq/) (AWS ブログ記事)
+ [管理コマンドラインツール](https://www.rabbitmq.com/management-cli.html) (RabbitMQ ドキュメント)
+ [AWS CloudFormation スタックの作成または削除](https://docs.ansible.com/ansible/latest/collections/amazon/aws/cloudformation_module.html) (Ansible ドキュメント)
+ [メッセージ駆動型アプリケーションを Amazon MQ for RabbitMQ に移行する](https://aws.amazon.com/blogs/compute/migrating-message-driven-applications-to-amazon-mq-for-rabbitmq/) (AWS ブログ記事)

## アタッチメント
<a name="attachments-294120b6-c95f-4cc5-bf85-5ad7e2abdad5"></a>

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/294120b6-c95f-4cc5-bf85-5ad7e2abdad5/attachments/attachment.zip)」

# Amazon Connect コンタクトセンターのエージェントワークステーションの通話品質を向上
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers"></a>

*Amazon Web Services、Ernest Ozdoba*

## 概要
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-summary"></a>

通話品質の問題は、コンタクトセンターでトラブルシューティングするのが最も難しい問題の1つです。音声品質の問題や複雑なトラブルシューティング手順を回避するには、エージェントの作業環境とワークステーションの設定を最適化する必要があります。このパターンは、Amazon Connect コンタクトセンターのエージェントワークステーションの音声品質最適化手法を説明しています。以下の領域での推奨事項が記載されています。
+ 作業環境の調整。エージェントの周囲は、ネットワーク上での音声の伝送方法には影響しませんが、通話品質には影響します。 
+ エージェントワークステーションの設定 コンタクトセンターワークステーションのハードウェアとネットワークの構成は、通話品質に大きな影響を与えます。
+ ブラウザ設定。エージェントはウェブブラウザを使用して Amazon Connect コンタクトコントロールパネル (CCP) ウェブサイトにアクセスし、顧客と通信します。そのため、ブラウザの設定が通話品質に影響する可能性があります。

次のコンポーネントも通話品質に影響する可能性がありますが、これらはワークステーションの範囲外であり、このパターンには含まれていません。
+ AWS Direct Connect、フルトンネル VPN、またはスプリットトンネル VPN を介したAmazon Web Services (AWS) クラウドへのトラフィックフロー  
+ 会社のオフィス内外で作業する場合のネットワーク条件
+ 公衆電話交換網 (PSTN) 接続
+ お客様のデバイスとテレフォニーキャリア
+ 仮想デスクトップインフラストラクチャ (VDI) セットアップ

これらの分野に関する詳細については、Amazon Connect ドキュメントの「[コンタクトコントロールパネル (CCP) に関する一般的な問題](https://docs.aws.amazon.com/connect/latest/adminguide/common-ccp-issues.html)」と「[エンドポイントテストユーティリティの使用](https://docs.aws.amazon.com/connect/latest/adminguide/check-connectivity-tool.html)」を参照してください。

## 前提条件と制限
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-prereqs"></a>

**前提条件**
+ ヘッドセットとワークステーションは、「[Amazon Connect 管理者ガイド](https://docs.aws.amazon.com/connect/latest/adminguide/ccp-agent-hardware.html)」で指定されている要件に準拠している必要があります。 

**制限事項**
+ このパターンの最適化手法は、ソフトフォンの音声品質にも適用されます。Amazon Connect CCP をデスクフォンモードに設定した場合は適用されません。ただし、ソフトフォンの設定で通話に適した音質が得られない場合は、デスクフォンモードを使用できます。

**製品バージョン**
+ サポートされているブラウザとバージョンについては、「[Amazon Connect 管理者ガイド](https://docs.aws.amazon.com/connect/latest/adminguide/browsers.html)」を参照してください。

## アーキテクチャ
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-architecture"></a>

このパターンはエージェントワークステーションの設定を対象としているため、アーキテクチャに依存しません。次の図が示すように、エージェントから顧客への音声パスは、エージェントのヘッドセット、ブラウザ、オペレーティングシステム、ワークステーションハードウェア、ネットワークの影響を受けます。

![\[Amazon Connect ワークステーションコールにおけるエージェントから顧客への音声パス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/04ac4c80-30c4-4a48-8411-e3aac7bc2887/images/04e94efc-39d1-424d-a299-89ea17d40153.png)


Amazon Connect コンタクトセンターでは、ユーザーの音声接続は WebRTC で確立されます。音声は [Opus インタラクティブオーディオコーデックでエンコードされ](https://opus-codec.org/)、転送中はセキュア・リアルタイム・トランスポート・プロトコル (SRTP) で暗号化されます。VPN、プライベート WAN/LAN、ISP ネットワークなど、他のネットワークアーキテクチャも可能です。

## ツール
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-tools"></a>
+ [Amazon Connect エンドポイントテストユーティリティ](https://tools.connect.aws/endpoint-test/) — このユーティリティは、ネットワーク接続とブラウザの設定をチェックします。
+ WebRTC 設定用のブラウザ設定エディター：
  + Firefox の場合：「**設定に関する**」
  + クロームの場合：「**chrome： //フラグ**」
+ [CCP ログパーサー](https://tools.connect.aws/ccp-log-parser/index.html) — このツールは、トラブルシューティングを目的として CCP ログを分析するのに役立ちます。

## エピック
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-epics"></a>

### 作業環境を調整します。
<a name="adjust-the-work-environment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| バックグラウンドノイズを軽減。 | 騒がしい環境は避けてください。それが不可能な場合は、以下の防音対策のヒントを参考にして環境を最適化してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | エージェント、マネージャー | 

### エージェントワークステーションの設定を最適化
<a name="optimize-agent-workstation-settings"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 適切なヘッドセットを選択する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | エージェント、マネージャー | 
| ヘッドセットを意図したとおりに使用してください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | [エージェント] | 
| ワークステーションのリソースを確認してください。 | エージェントのコンピューターのパフォーマンスが高いことを確認してください。リソースを消費するサードパーティのアプリケーションを使用している場合、そのコンピュータは CCP を実行するための最小「[ハードウェア要件](https://docs.aws.amazon.com/connect/latest/adminguide/ccp-agent-hardware.html)」を満たしていない可能性があります。エージェントが通話品質に問題を抱えている場合は、CCP に十分な処理能力 (CPU)、ディスク容量、ネットワーク帯域幅、メモリがあることを確認してください。担当者は、CCP のパフォーマンスと通話品質を向上させるために、不要なアプリケーションやタブをすべて閉じてください。 | 管理者 | 
| オペレーティングシステムのサウンド設定を行います。 | 通常、マイクレベルとブーストのデフォルト設定は正常に機能します。発信音声が小さい場合や、マイクの音量が大きすぎる場合は、これらの設定を調整すると役立つ場合があります。マイクの設定は、コンピュータのシステムサウンド設定 (「**サウンド**」、「[macOS](https://support.apple.com/en-gb/guide/mac-help/mchlp2567/12.0/mac/12.0)」では「**入力**」、「[Windows](https://support.microsoft.com/en-us/windows/fix-microphone-problems-5f230348-106d-bfa4-1db5-336f35576011)」では「**マイクのプロパティ**」) にあります。音声品質に影響する可能性のある詳細設定には、システムツールまたはサードパーティアプリケーションからアクセスできます。確認できる設定の一部を以下に紹介します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html)音声品質に問題がある場合は、詳しく調べる前にこれらの値をデフォルト設定に戻してみてください。これらや他の調整可能な設定の詳細については、デバイスのマニュアルを参照してください。 | エージェント、管理者 | 
| 有線ネットワークを使用する。 | 通常、有線イーサネットは遅延が少ないため、音声データ伝送に必要な一貫した伝送品質を実現しやすくなります。 1 コールあたり最低 100 KB の帯域幅を推奨します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | ネットワーク管理者、エージェント | 
| ハードウェアドライバーを更新します。 | USB など、独自のファームウェアを備えたヘッドセットを使用する場合は、常に最新バージョンに更新しておくことをお勧めします。補助ポートを使用するシンプルなヘッドセットは、コンピューターの内蔵オーディオデバイスを使用するため、オペレーティングシステムのハードウェアドライバーが最新であることを確認してください。まれに、オーディオドライバーを更新するとオーディオの問題が発生し、ロールバックが必要になることがあります。ファームウェアとドライバーのバージョン変更の詳細については、デバイスのマニュアルを参照してください。 | 管理者 | 
| USB ハブやドングルは避けてください。 | ヘッドセットを接続するときは、ドングル、ポートタイプコンバーター、ハブ、延長ケーブルなどの追加のデバイスを避けてください。これらのデバイスは通話品質に影響する可能性があります。代わりに、デバイスをコンピューターのポートに直接Connect してください。 | [エージェント] | 
| CCP ログの確認 | CCP ログパーサーを使用すると、アプリケーションログを簡単にチェックできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | エージェント (上級スキル) | 

### ブラウザ設定の最適化
<a name="optimize-browser-settings"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| デフォルトの WebRTC 設定を復元します。 | CCP でソフトフォンコールを行うには、WebRTC を有効にする必要があります。WebRTC 関連機能のデフォルト設定のままにすることをお勧めします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers.html) | 管理者 | 
| トラブルシューティングの際はブラウザ拡張機能を無効にしてください。 | ブラウザ拡張機能の中には、通話品質に影響を与えたり、通話が正しく接続されなかったりするものもあります。ブラウザのシークレットウィンドウまたはプライベートモードを使用し、すべての拡張機能を無効にしてください。これで問題が解決したら、ブラウザの拡張機能を見直して疑わしいアドオンを探すか、個別に無効にしてください。 | エージェント、管理者 | 
| ブラウザーのサンプルレートを確認してください。 | マイク入力が最適な 48 kHz サンプルレートに設定されていることを確認します。手順については、[Amazon Connect 管理者ガイド](https://docs.aws.amazon.com/connect/latest/adminguide/verify-sample-rate.html) を参照してください。 | エージェント、管理者 | 

## 関連リソース
<a name="improve-call-quality-on-agent-workstations-in-amazon-connect-contact-centers-resources"></a>

このパターンの手順を実行しても通話品質に問題がある場合は、以下のリソースを参照してトラブルシューティングのヒントを確認してください。
+ [問い合わせコントロールパネル (CCP) の一般的な問題](https://docs.aws.amazon.com/connect/latest/adminguide/common-ccp-issues.html)を参照してください。
+ 「[エンドポイントテストユーティリティ](https://docs.aws.amazon.com/en_us/connect/latest/adminguide/check-connectivity-tool.html)」で接続を確認してください。
+ その他の問題については、「[トラブルシューティングガイド](https://docs.aws.amazon.com/connect/latest/adminguide/troubleshooting.html)」に従ってください。 

トラブルシューティングと調整を行っても通話品質の問題が解決しない場合、根本原因はワークステーションの外部にある可能性があります。詳細なトラブルシューティングについては、IT サポートチームにお問い合わせください。 

# その他のパターン
<a name="messagingandcommunications-more-patterns-pattern-list"></a>

**Topics**
+ [CQRS とイベントソーシングを使用してモノリスをマイクロサービスに分解する](decompose-monoliths-into-microservices-by-using-cqrs-and-event-sourcing.md)
+ [ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation](deploy-chatops-solution-to-manage-sast-scan-results.md)
+ [Amazon API Gateway を Amazon SQS と統合して非同期 REST API を処理する](integrate-amazon-api-gateway-with-amazon-sqs-to-handle-asynchronous-rest-apis.md)
+ [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md)

# マルチアカウント戦略
<a name="multiaccountstrategy-pattern-list"></a>

**Topics**
+ [AWS メンバーアカウントを から に移行する AWS Organizations AWS Control Tower](migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower.md)
+ [AWS Organizations のプログラムによるアカウント閉鎖のアラートを設定する](set-up-alerts-for-programmatic-account-closures-in-aws-organizations.md)
+ [その他のパターン](multiaccountstrategy-more-patterns-pattern-list.md)

# AWS メンバーアカウントを から に移行する AWS Organizations AWS Control Tower
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower"></a>

*Rodolfo Jr. Cerrada、Amazon Web Services*

## 概要
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-summary"></a>

このパターンでは AWS Organizations、管理アカウントによって管理されるメンバーアカウントである AWS アカウント から に移行する方法について説明します AWS Control Tower。アカウントを に登録することで AWS Control Tower、アカウントのガバナンスを合理化する予防的および検出的なコントロールと機能を活用できます。AWS Organizations 管理アカウントが侵害され、メンバーアカウントを管理対象の新しい組織に移動する場合は、メンバーアカウントを移行することもできます AWS Control TowerAWS Control Tower。 

AWS Control Tower は、マルチアカウント環境全体で一貫したコンプライアンスとガバナンスを確保する AWS のサービスなど AWS Organizations、他のいくつかの機能を組み合わせて統合するフレームワークを提供します。を使用すると AWS Control Tower、 の機能を拡張する一連の規定のルールと定義に従うことができます AWS Organizations。たとえば、コントロールを使用して、セキュリティログと必要なクロスアカウントアクセス許可が作成され、変更されないようにすることができます。

## 前提条件と制限事項
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ AWS Control Tower でターゲット組織に を設定する AWS Organizations (手順については、 AWS Control Tower ドキュメントの[「 のセットアップ](https://docs.aws.amazon.com/controltower/latest/userguide/setting-up.html)」を参照してください)
+  AWS Control Tower (**AWSControlTowerAdmins **グループのメンバー) の管理者認証情報
+ ソースの管理者認証情報 AWS アカウント

**制限事項**
+ のソース管理アカウントは、 のターゲット管理アカウントとは異なる AWS Organizations 必要があります AWS Control Tower。

**製品バージョン**
+ AWS Control Tower バージョン 2.3 (2020 年 2 月) 以降 ([リリースノート](https://docs.aws.amazon.com/controltower/latest/userguide/release-notes.html)を参照)

## アーキテクチャ
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-architecture"></a>

次の図は移行プロセスとリファレンスアーキテクチャを示しています。このパターンでは、 をソース組織 AWS アカウント から管理対象のターゲット組織に移行します AWS Control Tower。 

![\[別の組織に移行され、登録済みの OU に移動された AWS アカウントの AWS Control Tower 登録プロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1fc2c2f0-fa5d-4068-a2b2-9e57cea2aff5/images/0654d242-0faa-4810-9e53-40ef89305b5b.png)


登録プロセスは、3 つの手順があります。

1. ターゲット組織は組織に参加するようアカウントの招待を送信します。 

1. アカウントは招待を受け入れ、ターゲット組織のメンバーになります。

1. アカウントは に登録 AWS Control Tower され、登録された組織単位 (OU) に移動されます。( AWS Control Tower ダッシュボードを確認して登録を確認することをお勧めします）。この時点で、登録された OU で有効になっているすべてのコントロールが有効になります。

## ツール
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-tools"></a>

**AWS サービス**
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する単一のエンティティ (*組織*) AWS アカウント に複数の を統合することができるアカウント管理サービスです。
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、セキュリティ AWS Organizations、運用 AWS IAM アイデンティティセンター、コンプライアンスのガバナンスルールを AWS Service Catalog内のすべての組織とアカウントで大規模に適用および管理できるように、 を含む他の サービスの機能を統合します AWS クラウド。

## エピック
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-epics"></a>

### アカウントを招待して新しい組織に参加する AWS Control Tower
<a name="invite-the-account-to-join-the-new-organization-with-ctower"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| にサインインします AWS Control Tower。 | 管理者として AWS Control Tower コンソールにサインインします。 現在、 をソース組織 AWS アカウント から管理対象の OU 内の組織に直接移動する方法はありません AWS Control Tower。ただし、すでに管理されている OU に登録 AWS アカウント するときに、ガバナンス AWS Control Tower を既存の に拡張できます AWS Control Tower。そのため、このステップ AWS Control Tower では にログインする必要があります。 | AWS Control Tower 管理者 | 
| メンバーアカウントを招待します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower.html)アカウントの移管によってアプリケーションまたはネットワーク接続が影響を受けないことを確認します。このアクションで、メンバーアカウントへのリンクを記載した招待メールを送信します。アカウント管理者がリンクをたどって招待を受け入れると、メンバーアカウントが**AWS アカウント**ページに表示されます。詳細については、 AWS Organizations ドキュメントの[「アカウント招待の管理](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)」を参照してください。 | AWS Control Tower 管理者 | 
| アプリケーションと接続性をテストします。 | メンバーアカウントが新しい組織に登録されると、ルート内の OU に表示されます。また、 AWS Control Tower 登録された OU にまだ登録されていないため、 アカウントに登録されていないというフラグが付けられた[AWS Control Tower コンソール](https://console.aws.amazon.com/controltower)にも表示されます。以下について確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower.html) | AWS Control Tower 管理者、メンバーアカウント管理者、アプリケーション所有者 | 

### 登録用アカウントを準備する
<a name="prepare-the-account-for-enrollment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| コントロールを確認し、違反を修正します。 | ターゲット OU で定義されているコントロール、特に予防コントロールを確認し、違反を修正します。 ラン AWS Control Tower ディングゾーンを設定すると[、いくつかの必須の予防コントロール](https://docs.aws.amazon.com/controltower/latest/controlreference/preventive-controls.html)がデフォルトで有効になります。これらは無効化できません。アカウントを登録する前に、これらの必須コントロールを確認し、メンバーアカウントを (手動またはスクリプトを使用して) 修正する必要があります。予防的コントロールは、 AWS Control Tower 登録されたアカウントを準拠させ、ポリシー違反を防止します。予防コントロールに違反すると、登録に影響する可能性があります。検出コントロール違反は AWS Control Tower 、登録が成功するとダッシュボードに表示されます。登録プロセスには影響しません。詳細については、 AWS Control Tower ドキュメントの[「コントロールについて](https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html)」を参照してください。 | AWS Control Tower 管理者、メンバーアカウント管理者 | 
| コントロール違反を修正した後、接続の問題がないか確認します。 | 場合によっては、コントロール違反を修正するために、特定のポートを閉鎖するか、サービスを無効にする必要があります。アカウントを登録する前に、それらのポートやサービスを使用するアプリケーションが修正されていることを確認します。 | アプリ所有者 | 

### アカウントを に登録する AWS Control Tower
<a name="enroll-the-account-into-ctowerlong"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| にサインインします AWS Control Tower。 | [AWS Control Tower コンソール](https://console.aws.amazon.com/controltower) にサインインします。管理者権限を持つサインイン認証情報を使用します AWS Control Tower。ルートユーザー (管理アカウント) 認証情報を使用して AWS Organizations アカウントを登録しないでください。エラーメッセージが表示されます。 | AWS Control Tower 管理者 | 
| アカウントを登録します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower.html)詳細については、 AWS Control Tower ドキュメントの[「既存のアカウントの登録について](https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html)」を参照してください。 | AWS Control Tower 管理者 | 

### 登録後にアカウントを確認する
<a name="verify-the-account-after-enrollment"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| アカウントを検証します。 | から AWS Control Tower、**アカウント**を選択します。登録したばかりのアカウントの初期状態は [**Enrolling（登録中）**] です。登録が完了すると、状態は [**Enrolled（登録済み）**] に変わります。 | AWS Control Tower 管理者、メンバーアカウント管理者 | 
| コントロール違反を確認します。 | OU で定義されたコントロールは、登録されたメンバーアカウントに自動的に適用されます。 AWS Control Tower ダッシュボードの違反をモニタリングし、それに応じて修正します。詳細については、 AWS Control Tower ドキュメントの[「コントロールについて](https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html)」を参照してください。 | AWS Control Tower 管理者、メンバーアカウント管理者 | 

## トラブルシューティング
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| [**An unknown error occurred（不明のエラーが発生しました）] というエラーメッセージが表示されます。後で再試行するか、 AWS サポートにお問い合わせください。** | このエラーは、 でルートユーザー認証情報 (管理アカウント) AWS Control Tower を使用して新しいアカウントを登録する場合に発生します。 AWS Service Catalog は Account Factory ポートフォリオまたは製品をルートユーザーにマッピングできず、エラーメッセージが発生します。このエラーを修正するには、ルート以外のフルアクセスユーザー (管理者) 認証情報を使用して新しいアカウントを登録します。管理ユーザーに管理アクセスを割り当てる方法の詳細については、IAM Identity Center ドキュメントの[「開始](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)方法」を参照してください。 | 
|  AWS Control Tower **アクティビティ**ページには**、致命的なドリフトの取得**アクションが表示されます。 | このアクションはサービスのドリフトチェックを反映し、 AWS Control Tower セットアップの問題を示すものではありません。アクションは必要ありません。 | 

## 関連リソース
<a name="migrate-an-aws-member-account-from-aws-organizations-to-aws-control-tower-resources"></a>

**ドキュメント**
+ [用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations ドキュメント)
+ [とは AWS Control Tower(](https://docs.aws.amazon.com/controltower/latest/userguide/)AWS Control Tower ドキュメント)
+ [組織からメンバーアカウントを削除する](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html#leave-without-all-info) (AWS Organizations ドキュメント)
+ [のセットアップ](https://docs.aws.amazon.com/controltower/latest/userguide/setting-up.html#setting-up-iam) (AWS Control Tower ドキュメント)

**チュートリアルと動画**
+ [AWS Control Tower ワークショップ](https://catalog.workshops.aws/control-tower/) (セルフペースワークショップ)
+ [とは AWS Control Tower(](https://www.youtube.com/watch?v=daLvEb44d5Q)ビデオ)
+ [でのユーザーのプロビジョニング AWS Control Tower](https://www.youtube.com/watch?v=y_n9xN5mg1g) (ビデオ)

# AWS Organizations のプログラムによるアカウント閉鎖のアラートを設定する
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations"></a>

*Amazon Web Services、Richard Milner–Watts、Debojit Bhadra、Manav Yadav*

## 概要
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-summary"></a>

[CloseAccount API](https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html) for [AWS Organizations](https://aws.amazon.com/organizations/) を使用すると、ルート認証情報を使用してアカウントにログインしなくても、組織内のメンバーアカウントをプログラムで閉鎖できます。[RemoveAccountFromOrganization API](https://docs.aws.amazon.com/organizations/latest/APIReference/API_RemoveAccountFromOrganization.html) は AWS Organizations 内の組織からアカウントをプルするので、スタンドアロンアカウントになります。

これらの API により、AWS アカウントを閉鎖または削除できるオペレーターの数が増加する可能性があります。AWS Organizations 管理アカウントの AWS Identity and Access Management (IAM) を通じて組織にアクセスできるすべてのユーザーは、これらの API を呼び出すことができるため、関連する多要素認証 (MFA) デバイスを持つアカウントのルート メールの所有者にアクセスが限定されません。

このパターンでは、`CloseAccount` および `RemoveAccountFromOrganization` API が呼び出されるとアラートが実装されるため、これらのアクティビティを監視できます。アラートは、「[Amazon Simple Notiﬁcation Service (Amazon SNS)](https://aws.amazon.com/sns/)」のトピックを使用します。[ウェブフック](https://api.slack.com/messaging/webhooks)経由で Slack 通知を設定することもできます。

## 前提条件と制限事項
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント
+ AWS Organizations 内の組織
+ 組織のルート下にある組織管理アカウントにアクセスして、必要なリソースを作成します。

**機能制限**
+ 「[AWS Organizations API リファレンス](https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html)」で説明されているように、`CloseAccount` API では 30 日以内に閉鎖できるのは、アクティブなメンバーアカウントの 10% のみです。
+ AWS アカウントが閉鎖されると、ステータスは SUSPENDED に変わります。このステータスに移行した後 90 日間、AWS サポートはアカウントを再開できます。保留になったアカウントは 90 日後に完全に削除されます。
+ AWS Organizations 管理アカウントと API にアクセスできるユーザーには、これらのアラートを無効にする権限もあります。誤った削除ではなく悪意のある行為が主な懸念事項である場合は、このパターンで作成されたリソースを「[IAM のアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」で保護することを検討してください。
+ API `CloseAccount ` および `RemoveAccountFromOrganization` は、米国東部 (バージニア北部) リージョン (`us-east-1`) で呼び出します。したがって、イベントを観察するには、このソリューションを `us-east-1` でデプロイする必要があります。

## アーキテクチャ
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-architecture"></a>

**ターゲットテクノロジースタック**
+ AWS Organizations
+ AWS CloudTrail
+ Amazon EventBridge
+ AWS Lambda
+ Amazon SNS

**ターゲット アーキテクチャ**

このパターンのソリューションアーキテクチャを次の図に示します。

 

![\[AWS Organizations でアカウント閉鎖のアラートを設定するためのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ba9d9db1-fab8-4e3b-a1bb-f0be91ade5c6/images/92caee55-2722-4ba2-bdd2-66f1af35dce5.png)


1. AWS Organizations は `CloseAccount` または `RemoveAccountFromOrganization` のリクエストを処理します。

1. Amazon EventBridge は AWS CloudTrail と統合されており、これらのイベントをデフォルトのイベントバスに渡します。

1. カスタム Amazon EventBridge ルールは AWS Organizations のリクエストを照合し、AWS Lambda 関数を呼び出します。

1. Lambda 関数は、ユーザーがメールでアラートを受信したり、さらに処理するためにサブスクライブできる SNS のトピックにメッセージを渡します。

1. Slack 通知が有効になっている場合、Lambda 関数は Slack ウェブフックにメッセージを配信します。

## ツール
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-tools"></a>

**AWS サービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) では、インフラストラクチャをコードとして扱うことで、関連する AWS リソースやサードパーティリソースのコレクションをモデル化し、迅速かつ一貫したプロビジョニングを行い、ライフサイクル全体を通じて管理できます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースからのデータに接続するために使用できるサーバーレスのイベントバスサービスです。EventBridge は、環境の変化の指標であるイベントを受信し、イベントをターゲットにルーティングするルールを適用します。ルールは、*イベントパターン*と呼ばれるイベントの構造、またはスケジュールのいずれかに基づいて、イベントをターゲットにマッチングさせます。
+ 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。支払いは、使用したコンピューティング時間に対する料金のみになります。コードが実行されていないときに料金は発生しません。
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、AWS リソースの成長や拡張に伴い、環境の一元管理およびガバナンスを支援します。AWS Organizations を使用すると、プログラムによる AWS アカウントの新規作成、リソースの割り当て、ワークロードを整理するためのアカウントのグループ化、ガバナンスのアカウントまたはアカウントグループへのポリシーの適用、すべてのアカウントに単一の支払い方法を使用した請求の簡素化が可能になります。
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、AWS インフラストラクチャ全体のアカウントアクティビティをモニタリングして記録し、ストレージ、分析、修復アクションを制御できるようにします。
+ [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、アプリケーション間 (A2A) およびアプリケーションと人間の間 (A2P) の通信の両方に対応するフルマネージド型のメッセージングサービスです。

**その他のツール**
+ [AWS Lambda Powertools for Python ライブラリ](https://docs.powertools.aws.dev/lambda/python/latest/) は、Lambda 関数のトレース、ロギング、メトリクス、およびイベント処理機能を提供するユーティリティのセットです。

**コード**

このパターンのコードは、GitHub 内の「[AWS アカウント閉鎖通知](https://github.com/aws-samples/aws-account-closure-notifier)」リポジトリで利用できます。

このソリューションには、このパターンのアーキテクチャをデプロイする CloudFormation テンプレートが含まれています。[AWS Lambda Powertools for Python ライブラリ](https://docs.powertools.aws.dev/lambda/python/latest/)を使用してログ記録とトレースを行います。

## エピック
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-epics"></a>

### アーキテクチャをデプロイする
<a name="deploy-the-architecture"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ソリューションスタック用の CloudFormation テンプレートを起動します。 | このパターンの CloudFormation テンプレートは [GitHub リポジトリ](https://github.com/aws-samples/aws-account-closure-notifier)のメインブランチにあります。IAM ロール、EventBridge ルール、Lambda 関数、および SNS トピックをデプロイします。テンプレートを起動するには:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-alerts-for-programmatic-account-closures-in-aws-organizations.html)CloudFormation スタックの起動に関する詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)を参照してください。 | AWS 管理者 | 
| ソリューションが正常に起動したことを検証します。　 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-alerts-for-programmatic-account-closures-in-aws-organizations.html) | AWS 管理者 | 
| SNS トピックにサブスクライブします。 | (オプション) SNS トピックをサブスクライブする場合:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-alerts-for-programmatic-account-closures-in-aws-organizations.html)SNS 通知をセットアップする詳しい方法については、「[Amazon SNS ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)」を参照してください。 | AWS 管理者 | 

### ソリューションを検証する
<a name="verify-the-solution"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| デフォルトのイベントバスにテストイベントを送信します。 | [GitHub リポジトリ](https://github.com/aws-samples/aws-account-closure-notifier)には、テスト用に EventBridge のデフォルトイベントバスに送信できるサンプルイベントが用意されています。EventBridge ルールは、カスタムイベントソース `account.closure.notifier` を使用するイベントにも反応します。AWS サービスとしてイベントを送信することはできないため、CloudTrail イベントソースを使用してこのイベントを送信することはできません。テストイベントを送信するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-alerts-for-programmatic-account-closures-in-aws-organizations.html) | AWS 管理者 | 
| メール通知を受信したことを確認します。 | SNS トピックをサブスクライブしているメールボックスに通知が届いていることを確認します。閉鎖されたアカウントと API コールを実行したプリンシパルの詳細が記載されたメールが届きます。 | AWS 管理者 | 
| Slack 通知を受信したことを検証します。 | (オプション) CloudFormation テンプレートをデプロイした際に `SlackWebhookEndpoint` パラメータにウェブフック URL を指定した場合は、ウェブフックにマッピングされている Slack チャネルを確認してください。閉鎖されたアカウントと API コールを実行したプリンシパルの詳細が記載されたメッセージが表示されます。 | AWS 管理者 | 

## 関連リソース
<a name="set-up-alerts-for-programmatic-account-closures-in-aws-organizations-resources"></a>
+ 「[CloseAccountアクション](https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html)」 (AWS Organizations API リファレンス)
+ 「[RemoveAccountFromOrganization アクション](https://docs.aws.amazon.com/organizations/latest/APIReference/API_RemoveAccountFromOrganization.html)」 (AWS Organizations API リファレンス)
+ 「[AWS Lambda Powertools for Python](https://docs.powertools.aws.dev/lambda/python/latest/)」

# その他のパターン
<a name="multiaccountstrategy-more-patterns-pattern-list"></a>

**Topics**
+ [で Landing Zone Accelerator を使用してアカウントの作成を自動化する AWS](automate-account-creation-lza.md)
+ [AWS CloudFormation スタックと関連リソースの削除を自動化する](automate-deletion-cloudformation-stacks-associated-resources.md)
+ [AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.md)
+ [Amazon DataZone を使用してエンタープライズデータメッシュを構築する AWS CDK AWS CloudFormation](build-enterprise-data-mesh-amazon-data-zone.md)
+ [Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用してモニタリングを一元化](centralize-monitoring-by-using-amazon-cloudwatch-observability-access-manager.md)
+ [Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する](govern-permission-sets-aft.md)
+ [マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する](implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.md)
+ [マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する](implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.md)
+ [マルチアカウント DevOps 環境に Trunk 分岐戦略を実装する](implement-a-trunk-branching-strategy-for-multi-account-devops-environments.md)
+ [Terraform を使用して AWS アクセス許可セットを動的に管理する](manage-aws-permission-sets-dynamically-by-using-terraform.md)
+ [Terraform を使用して AWS で階層型のマルチリージョン IPAM アーキテクチャを作成する](multi-region-ipam-architecture.md)
+ [マルチリージョン、マルチアカウント組織で CloudFormation ドリフト検出を設定する](set-up-aws-cloudformation-drift-detection-in-a-multi-region-multi-account-organization.md)
+ [マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する](set-up-dns-resolution-for-hybrid-networks-in-a-multi-account-aws-environment.md)