Amazon CloudWatch Logsを別アカウントのKinesis Data Firehoseにプッシュする手順で脳内CPUが100%になったので図に描いてみた

こんにちは！コンサル部のinomaso(@inomasosan)です。

とある案件でAmazon CloudWatch Logsに保存したAmazon Auroraのログを、別アカウントのKinesis Data FirehoseにプッシュしS3に保存できるか調査しました。が、テキストだけ読んで理解しようとしたところ脳内CPUが高負荷で爆発しました。

そこで、今回は参考にした手順で作成するリソースを図に描いて、脳の負荷を軽減してみます。

まずはシングルアカウントでの手順を図にしてみる

理解を深めるために、まずはシングルアカウントでの手順から図にしてみます。
今回はAmazon Auroraの各種ログをCloudWatch LogsからS3に連携してみたを参考に、より詳細な図を描いてみました。

Amazon CloudWatch LogsとAmazon Kinesis Data Firehoseは他のサービスと連携するためのIAMロールが必要ということを覚えておいてください。

本題のクロスアカウントを図にしてみる

シングルアカウントでの図を理解できたので、本題のクロスアカウントを図にしていきます。
AWSナレッジセンターのブログを参考に、図を書いてみました。

シングルアカウントとの差異

順を追って理解するためにAccount Bから説明していきます。

Account B(送信先アカウント)

• CloudWatch LogsにAccount A用にクロスアカウント専用のサブスクリプション宛先を作成します。この際にアクセスポリシーでAccount Aからのサブスクリプション作成と更新を許可します。

Account A(ソースアカウント)

• CloudWatch LogsのサブスクリプションフィルターでAccount Bに作成したクロスアカウント専用の宛先を設定します。この宛先はAccount BのTaget ARN(Kinesis等)がカプセル化されているため、Destination ARNにはCloudWarch Logsのクロスアカウント専用の宛先を指定する必要があります。
• Account AのCloudWatch Logsから、Account BのAmazon Kinesis Data Firehoseへ直接連携しないためAccount AではIAMロールの作成は不要です。

あわせて読みたい

まとめ

クロスアカウントの経験があまりなかったので、どのAccountで何を作成すればいいのかをテキストのみで理解するのはあまりに酷でした。
検証の手が止まるようであれば、多少時間がかかっても図を描いた方が、自分の理解や他の方に説明する場合に有効だと感じました。

この記事が、どなたかのお役に立てば幸いです。それでは！