Amazon Web Services ブログ

AWS Control Tower アクションの追跡、およびワークフローの自動トリガーへのライフサイクルイベントの使用

現在、新規アカウントの作成やプロビジョニングに、 AWS Control Towerをご利用になっているお客様が多く見受けられます。こういったお客様は、環境の作成に、AWS のネイティブなソリューションの使用をご希望されます。それが明文化された AWS のベストプラクティスに則っていることをご存知だからです。お客様は、作成したアカウントのスケーリングを行う際に、アカウントをさらに強化できる Control Tower の追加的な機能を利用することもできます。今回の記事では、 ライフサイクルイベントの使用方法をご紹介していきます。これは、Control Tower’s Account Factory を使用して新しいアカウントを作成するなどのアクションが完了したことを追跡できるようにする、Control Tower における機能の 1 つです。今回は、このライフサイクルイベントで、自動化したワークフローをトリガーする方法についても、合わせてご紹介します。この記事では、次のようなサービスを使用しています。

背景

AWS Control Tower では、Well-Architected なマルチアカウントの AWS 環境構築のために、AWS Organizations、AWS IAM、AWS Config、AWS CloudTrail、および AWS Service Catalog などの AWS のサービスを複数使用します。これにより、組織単位 (OU) の中のアカウントでガードレールを有効化するなどのアクションを Control Tower が実行する際には、多くのプロセスが実行され、各サービスに対しては膨大な数の API 呼び出しが送られることになります。

ライフサイクルイベントにより、こういった Control Tower で実行中のアクションが完了したことを知ることができます。Control Tower は、起点となるアクションと関連しているサブタスクがすべて完了した時点で、ライフサイクルイベントを作成します。次の図に示すように、ライフサイクルイベントは CloudTrail イベントとして記録されると同時に、Amazon CloudWatch Events (および Amazon EventBridge) にもイベントとして配信されます。ライフサイクルイベントログでは、実行中の Control Tower アクションが正常に完了したかどうかについても知ることができます。

Control Tower のライフサイクルイベントが生成および記録される様子を示すワークフロー図

Control Tower では、次の各アクションが完了した時点で、ライフサイクルイベントを作成します。

  • 新しいランディングゾーンの作成。
  • ランディングゾーンの更新。
  • Control Tower を使用しての OU の作成。
  • OU の Control Tower からの登録解除。
  • Account Factory を使用してのアカウントの作成およびプロビジョニング。
  • Account Factory を使用して作成されたアカウントの更新。
  • OU におけるガードレールの有効化および
  • ガードレールの無効化。

AWS CloudTrail でのライフサイクルイベントの記録。

ライフサイクルイベントは、Control Tower により内部的に作成され、AWS サービスイベントとして CloudTrail に記録されます (eventType = AwsServiceEvent) 。ユーザーは、CloudTrail のイベント履歴ページにおいてライフサイクルイベントを確認することができます (このイベントでは、Source IP addressが AWS Internal となっており、Event sourceが controltower.amazonaws.com となっています) 。

例: OU でのガードレールの有効化

Control Tower の管理者としてログインします。Control Tower ダッシュボードから、My-Custom-OU という名前で新しい OU を作成します。その後、この新規 OU のガードレールを有効にします。

CloudTrail コンソールを開き、イベント名が EnableGuardrail となっている 2 つのイベントを CloudTrail が記録していることを確認します。次にそのスクリーンショットを示します。

ユーザーアクションと、それに対応するライフサイクルイベントを表示している、AWS CloudTrail コンソールのスクリーンショット

1 つめの EnableGuardrail イベントには、ログインした [User name] と [Source IP address] が表示されています。これが、ガードレールを有効化した際のアクションを記録しているイベントです。

2 つめの EnableGuardrail イベントでは、[Source IP address] として AWS Internal が表示されています。こちらのイベントが、ガードレール有効化のアクションに対応したライフサイクルイベントです。

これら 2 つの EnableGuardrail イベントについてログエントリを表示させ、CloudTrail によりそれぞれが異なる形で記録された様子を確認してみます。

1 つめの EnableGuardrail イベントのログエントリを抽出してみると、CloudTrail により event type が AwsApiCall として記録されたことが分かります。次にそのスクリーンショットを示しています。これにより、ユーザーが起動したアクションが、最終的に AWS API を呼び出したことが表示されています。

ユーザーアクションに関する AWS CloudTrail ログのスクリーンショット

2 つめの EnableGuardrail イベントのログエントリからは、CloudTrail が event type を AwsServiceEvent として記録したことが読み取れます。次にそのスクリーンショットを示しています。これからは、AWS のサービス (ここでは Control Tower) が、この EnableGuardrail というライフサイクルイベントを作成したことがわかります。

ライフサイクルイベントに関する AWS CloudTrail ログのスクリーンショット

前出のスクリーンショットでは、ライフサイクルイベントログの serviceEventDetails セクション内に、起点となった Control Tower アクションに関連する情報が含まれています。この例でのライフサイクルイベントログには、OU の名前と ID、そして、その OU で有効化したガードレールの名前と活動などが記載されています。また、ライフサイクルイベントログには、起点アクションの状態 (もしくは結果) も記載されます。今回の場合は、Control Tower がガードレールの有効化に成功したか失敗したかが確認できます。

例: Control Tower を使用しての新規アカウントの作成

Control Tower の Account Factory を (AWS Service Catalog 経由で) 使用し、新しいアカウントを my-custom-account-2 という名前で作成およびプロビジョニングします。その後、すでに作成済みの OU (My-Custom-OU) の中にそのアカウントを配置します。

CloudTrail コンソールに戻り、記録してあるイベントのサブセットを表示させます。Account Factory を使用してのアカウント作成アクションがあったことが、CreateManagedAccountというイベント名で CloudTrail により記録されたことが確認できます。そのスクリーンショットを次に示します。

AWS CloudTrail のイベント履歴ページのスクリーンショット

これに続く数分間、Control Tower では、my-custom-account-2 という名前の新規アカウントを作成およびプロビジョニングするために、他のサービスに対し非常に多数の API 呼び出しを行っています。前出のスクリーンショットのとおり、CloudTrail は最終的に、2 つのライフサイクルイベントを記録しています。

EnableGuardrail という名前の 1 つめのライフサイクルイベントからは、新規アカウントにある My-Custom-OU ですでに有効化済みのガードレールのデプロイを、Control Tower が完了したことが分かります。2 つめの CreateManagedAccount というライフサイクルイベントでは、この新規アカウントの作成とプロビジョニングに関するすべてのアクションを、Control Tower が完了したことが確認できます。

すでに述べたとおり、ライフサイクルイベントにより、Control Tower アクションが正常に完了したかどうかを追跡することが可能です。

また、ライフサイクルイベントは、Control Tower ダッシュボードにある Activities (アクティビティ) ページでも表示させることができます。次にスクリーンショットを示します。Activities ページには、ユーザーが Control Tower コンソールを利用する間に CloudTrail が記録した他のイベントも表示されます。

AWS Control Tower ダッシュボードの Activities ページのスクリーンショット

Amazon CloudWatch Events を使用しての自動ワークフローのトリガー

Control Tower アクションの完了は、アクションのタイプや、設定する必要のあるリソースの数などに応じて、数分間を要することがあります。ライフサイクルイベントにより、各 Control Tower アクションの完了が確定します。同時にこれは、次に続く一連のアクションの開始点としても機能します。これらのアクションでは、Control Tower リソース、もしくは以前の Control Tower アクションの結果を引き受けます。

たとえば、Account Factory によりアカウントを作成した際、対応するライフサイクルイベントを使用して、アカウント作成アクションの結果に合わせた追加のワークフローをトリガーすることができます。ライフサイクルイベントからアカウント作成の成功がレポートされれば、カスタムリソースを設定したアカウントを、さらにプロビジョニングします。逆に、ライフサイクルイベントがアカウント作成の失敗をレポートした場合には、その調査のために IT チームに対しチケットを提出します。

ライフサイクルイベントの使用にリンクした、一連のアクションを実行することもできます。たとえば、新しい OU の作成や、その OU でのガードレールの有効化を行い、複数のアカウントを作成した上で、それらをこの OU 上に配置できます。これらのアクションは、すべてライフサイクルイベントの使用にリンクするものです。

ここでは、ライフサイクルイベントにより追加の自動ワークフローを起動する方法を説明するために、Account Factory を使用してアカウントを作成する度に、InfoSec チームに対し自動的に通知が送られる例を用意しました。

ライフサイクルイベントは、CloudWatch イベントとして Control Tower から配信されます。Account Factory と関連するライフサイクルイベントの検知には、CloudWatch イベントルールを作成します。このルールは、Amazon SNS トピックへのライフサイクルイベントの公開も行います。

  1. Control Tower の管理者としてログインします。Amazon SNS コンソールにおいて、lifecycle-events-sns という名前の Amazon SNS topic を作成し、その Amazon SNS トピックに InfoSec チームを登録します。次にそのスクリーンショットを示します。Amazon SNS のスクリーンショット
  2. CloudWatch Events を使用してイベントルールを作成します。
    1. CloudWatch Events コンソールから、Event Source (イベントソース) と Targets (ターゲット) の設定を行います。
    2. Event Source では、[Service Name (サービス名)] に [Control Tower] を設定し、[Event Type (イベントタイプ)] に [AWS Service Event via CloudTrail] を設定します。作成されたルールは、すべての、もしくは特定のライフサイクルイベントによりトリガーされるように指定できます。今回の例では、CreateManagedAccount というライフサイクルイベントがルールをトリガーするように作成しています。次がそのスクリーンショットです。Amazon CloudWatch Events ルール作成のスクリーンショット – Event Source
    3. ここでは、先に作成済みの Amazon SNS トピックを lifecycle-events-sns として設定しています。これは、CloudWatch Events が CreateManagedAccount というライフサイクルイベントを検知した時に呼び出される Target です。次にスクリーンショットを示します。Amazon CloudWatch Events ルール作成のスクリーンショット – Targets
  3. これで、CWE-rule-lifecycle-event-account という名前の CloudWatch Events ルールが作成できました。これは、Control Tower からの CreateManagedAccount というライフサイクルイベントを検知し、lifecycle-events-sns という Amazon SNS トピックに対し、そのイベントのログを公開します。次がそのスクリーンショットです。InfoSec チームの E メールアドレスは、この Amazon SNS トピックにすでに登録済みであるので、Account Factory を使用して新規のアカウントを作成するたびに、このチームに通知が届きます。Amazon CloudWatch Events ルールのスクリーンショット

再び、Control Tower コンソールを開きます。Account Factory により、新規アカウント (my-custom-account-3) を作成しまし、先に作成済みの OU (My-Custom-OU) 内にそれを配置します。数分後、その結果生じるライフサイクルイベントログが、InfoSec チームの受信箱への通達されるようになります。次がそのスクリーンショットです。

ライフサイクルイベントログの E メールのスクリーンショット

この時点で InfoSec チームは、アカウントが Control Tower により正常に作成され、プロビジョニングされたことを確認します。またチームでは、そのアカウントの ID および、それが配置された OU も知ることができます。CloudWatch Events は複数のターゲットをサポートできます。ここでは、CWE-rule-lifecycle-event-account というルールにより、AWS Lambda もしくは AWS CodePipeline を同時に起動させ、作成した新規アカウントに追加のカスタムリソース設定を使用しながら、さらなるプロビジョニングを行っています。

CloudWatch Events でライフサイクルイベントを使用することのもう 1 つの利点として、失敗した可能性のある Control Tower アクションに対する可視性が与えられることが挙げられます。

この点を示すため、Control Towerを使用して、新しい OU (My-Custom-OU-3) を作成します。Account Factory で、my-custom-account-7 という名前の新規アカウントを作成するように設定し、これを新しい OU に配置します。アカウントの作成プロセスを起動後、すぐに Organizations コンソールから My-Custom-OU-3 を削除します。これにより、アカウント作成とプロビジョニングのプロセスを失敗させることができます。

これで数分経過すると、Control Tower がアカウント (my-custom-account-7) の作成およびプロビジョニングを正常に完了できなかったことを伝える E メールが、InfoSec チームに届きます。次にそのスクリーンショットを示します。InfoSec チームでは、これを元に原因の調査を開始できます。仮に InfoSec チームが参照する対象が、起点となるユーザーアクションでの CloudTrail ログのみであるなら、彼らはそのユーザーアクションと関連するサブタスクが正常に完了したかどうかについては知ることができません。つまり、問題に対し適時的かつ適切に対処することも不可能になります。

ライフサイクルイベントログの E メールのスクリーンショット

まとめ

今回の記事では、Control Tower アクションの完了を追跡するための、Control Tower ライフサイクルイベントの使用方法をご紹介しました。加えて、事前定義済みアクションをライフサイクルイベントにトリガーさせるための、CloudWatch Events の使用方法も解説しました。

ライフサイクルイベントの詳細については「AWS Control Tower ユーザーガイド」をご参照ください。

著者について

ブログ筆者近影 Kalyan Ghatak は、AWS Control Tower チームのシニアテクニカルプロダクトマネージャーです。Kalyan は、困難な問題を解決しようとする AWS のお客様との協力に熱心で、お客様による AWS 上での構築を支援しています。余暇には、クラシック音楽を鑑賞したり、古典文学を読んだりしています。