この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
地味サービス大好き森永です。
CloudWatchを眺めていたら「Event Buses NEW」という項目が増えていることに気が付きました。
説明文を見てみると…
デフォルトのイベントバスは、AWS のサービス、PutEvents API コール、およびその他のアクセス権限が付与されたアカウントからイベントを受け入れます。デフォルトのイベントバスでアクセス許可を管理して、他のアカウントにアクセス許可を付与できます。他のアカウントは、お客様のデフォルトのイベントバスを彼らのルールのターゲットに追加することで、お客様とイベントを共有できます。
別のアカウントとイベントを共有できる！！？！？！？
これは試さねば！！
Sending and Receiving Events Between AWS Accounts - Amazon CloudWatch Events
CloudWatch Events adds cross account event delivery support
Event Busとは
アカウントAで発生したイベントをアカウントBへ伝えるバス（いわゆるデータバス）です。
アカウントAのCloudWatch Eventsでルールを設定し、そのイベントターゲットにEvent Busを設定することで別アカウントへイベントを転送できます。
アカウントBでもルールを作成し、イベントターゲットに任意のアクションを指定します。
いくら言葉で説明しても分かりづらいので実際に試してみましょう。
試してみる
アカウントAでEC2がpending状態になったら、アカウントBのSNSでメール通知するという簡単な構成を作ってみます。
クロスアカウントで設定しますので、アカウントを2つ用意してください。
イベントソースとなるアカウントをアカウントA、イベントターゲットとなるアカウントをアカウントBとして説明していきます。
権限設定
まず、アカウントBでEvent Busへの権限設定をします。
こちらを行うことで、アカウントAからアカウントBにイベントを転送できるようになります。
こちらからEvent Busの設定ページにいき、defaultのEvent Busに「アクセス許可の追加」を行います。
アカウントAのアカウントIDを入力するだけで設定完了です。
アカウントAでのルール作成
まずは、アカウントAでEvent Busをターゲットにしたルールを作成します。
以下の設定でイベントソースの設定をします。
- サービス名：EC2
- イベントタイプ：EC2 Instance State-change Notification
- 特定の状態：pending
次に、イベントターゲットの設定をします。
こちらでは、Event Busを指定します。
「アカウントID」にターゲットとなるアカウントBのアカウントIDを指定します。
後はウィザードに従ってルールを作成します。
アカウントBでのルール作成
最後にアカウントBでルールを作成します。
イベントソースはアカウントAで設定したものでもよいのですが、その場合、アカウントBでEC2がpending状態になった時にもイベントが発生してしまいますので少し変更を加えます。
カスタムイベントパターンを選択し、以下の内容を記述します。
アカウントAとの変更点は、accountの項目を追加し、アカウントAのみに限定した箇所です。
{
"source": [
"aws.ec2"
],
"account": [
"アカウントAのアカウントID"
],
"detail-type": [
"EC2 Instance State-change Notification"
],
"detail": {
"state": [
"pending"
]
}
}イベントターゲットではアカウントBでしたいアクションを選びます。
今回はSNSで通知するため、サブスクライブを設定したトピックを選択します。
こちらもその後の指示に従ってルールを作成します。
動作検証
では、アカウントAでEC2を起動してpending状態を作ってみます。
pending状態だと課金されないので、runningになる前に停止します。（ケチ）
すると、SNSでサブスクライブ登録していたメールアドレスにメールが届きました！！
最後に
今回はSNSでやりましたが、先日イベントターゲットとして追加されたKinesis Firehoseを使用して、複数アカウントの情報を一つに集めて分析するなどといった使い方が出来るのではないかと思います。
マルチアカウントでの管理もかなりやりやすくなりますね。
11
