【新機能】APIレベルのイベント駆動処理を行うCloudWatch Eventsが発表されました!

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。
本日CloudWatchにイベント駆動型の処理を行える新しい機能が追加されました。早速試してみました。

CloudWatch Events

今回追加された機能はCloudWatch Eventsというイベント駆動で処理を行う機能となります。

条件に合致することで処理を行うということでCloudWatchのアラームやSNSに似ていますが異なっている点もあるようです。筆者が個人的に比較表を作成してみました。(内容は2016年1月15日の情報を元にしています)

項目 CloudWatch Events CloudWatch Alarm SNS
起動条件 EC2の状態遷移、スケジュール、API呼び出し、コンソールのログイン、Auto ScalingのEC2起動/削除の成功/失敗 CloudWatchのメトリクス 定義されている各機能のイベント
関連を記述する場所 CloudWatch Eventsに記述する CloudWatch Alarmに記述する 呼び出し元の各サービスに分散して記述する
後続の処理 AWS Lambda、SNS、Kinesis Stream、ビルトイン処理 SNS、Auto Scalingアクション、EC2アクション HTTPリクエスト、メール、SQS、プッシュ通知、AWS Lambda
起動するまでの時間 ほぼリアルタイム (APIや状態遷移) CloudWatch メトリクスの反映を待つ ほぼリアルタイム (各処理の終了を待つ事が多い)

類似した機能を比較してみると、様々な条件で、関連を一箇所に集約して記述でき、様々な処理を、ほぼリアルタイムで実行できる、という良い所取りな機能ということですね。

設定してみる

マネージメントコンソールでCloudWatchを見てみると、イベント が増えています。イベントのルールを作成します。

CloudWatch_Management_Console

Step 1: Create rule

起動条件の選択(Event selector)と起動する処理(Targets)を指定します。

CloudWatch_Management_Console

Event selectorでは、以下の5種類から選べます。

  • EC2 instance state change notification
  • スケジュール
  • AWS API call
  • AWS console sign-in
  • Auto Scaling

Targetsでは、以下の4種類から選べます。

  • Lambda function
  • SNS topic
  • Kinesis stream
  • Built-in target

EC2 instance state change notification

EC2の状態遷移が条件となります。EC2の状態は、Pending、Running、Shutting down、Stopped、Stopping、Terminatedの6種類となります。
EC2の状態遷移の詳細はインスタンスのライフサイクルを参照してください。

CloudWatch_Management_Console

スケジュール

Lambdaのスケジュールと同様に最短5分で繰り返し、cron形式で指定できます。

CloudWatch_Management_Console

AWS API call

API callでは、30種類以上のサービスのAPIに対応しています。基本的にリソースを変更するAPIが対象になっているようで、Describe系、List系、Get系などのAPIは対象外になっています。

CloudWatch_Management_Console

AWS console sign-in

マネージメントコンソールのサインインを条件にできます。ユーザの指定も行えます

CloudWatch_Management_Console

Auto Scaling

Auto Scaling対象のEC2で起動/削除の成功/失敗を指定できます。Auto Scaling Groupも指定できます。

CloudWatch_Management_Console

target

Built-in targetでは、Lambda Functionを書かなくても既存の処理を実行できます。現時点では、以下の4種類が使用できます。

  • Create a snapshot of an EBS volume
  • Reboot an EC2 instance
  • Terminate an EC2 instance
  • Stop an EC2 instance

CloudWatch_Management_Console_と_TweetDeck_と_投稿の編集_‹_Developers_IO_—_WordPress

今回は、以下のように設定しました。指定したEC2インスタンスでStartInstancesを実行するとEC2を停止する、という設定になります。

  • Event selector
    • Events:AWS EC2 call
    • Service Name:EC2
    • operation:StartInstances
  • Targets
    • Targets:Built-in target
    • action:Stop an EC2 instance
    • Instance ID:停止中のEC2インスタンスを指定

CloudWatch_Management_Console

Step 2: Configure rule details

Ruleの名前を付けて、Built-in targetを実行するAWS Roleを指定します。

CloudWatch_Management_Console

AWS Roleを作成していない場合、ここで作成可能です。Basic built-in targets role を選択するとIAM Roleを作成できます。
Roleのポリシーは、以下の内容です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:RebootInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:CreateSnapshot"
      ],
      "Resource": "*"
    }
  ]
}

実行してみる

指定したEC2インスタンスでStartInstancesを実行するとEC2を停止する設定を行いました。
停止しているEC2を開始します。

EC2_Management_Console_と_投稿の編集_‹_Developers_IO_—_WordPress

開始すると、pendingになります。

EC2_Management_Console

インスタンスの開始をハンドリングしているようで、stoppedとなり停止しました。10秒程度でstoppedになるので、高速に反応しています。

EC2_Management_Console

最後に

個人的にはCloudWatchからは外れて新サービスでも良い大きな機能だと思っています。 今回はBuilt-in targetを使用しましたが、AWS Lambdaを使用することで自由に処理を行うこともできます。LambdaはVPC内のリソースへアクセスできるアップデートも予定されているので、行うことが出来る幅も更に広がると思います。