CloudWatch LogsからKinesisにアクセスするためのIAMロールを作成したい

前書き

今回は、リアルタイムでログをS3に保管するために
CloudWatch Logs　→　Kinesis Data Firehose →　S3
というよくあるアーキテクチャ構成でシステムを実装しようとしていました。

初めてKinesisが触れるぞ！とウキウキしていました

実践

こちらの記事を参考に構築を進めていました。
めちゃくちゃわかりやすかったです。ありがとうございます。

少しややこしかったのが、掲題している「CloudWatch LogsからKinesisにアクセスするためのIAMロール」の作り方です。

上記ブログには以下のように書いてありました。

↓上記画像の「こちら」のリンク先

結論から言うと、マネコンからロールを作る際にCloudWatch Logsを「信頼されたエンティティ」として選択できないため、一旦適当にエンティティを選択してロールを作成した後、「信頼されたエンティティ」を設定しているJSONを書き換えることでCloudWatch Logs用のロールを作成する、という手順が必要になります。

この時点で言っていることが理解できた方はこの先の記事は読まなくても大丈夫です。
筆者は公式サイトを見てもすぐには理解できなかったので、作業証跡を記事として残しておきたいと思います。

リンク先はCognitoの話をしているんじゃないか？という疑念も上記リンクの内容を理解する妨げになったのですが、おそらくcognitoは関係ないです。

CloudWatch LogsからKinesisにアクセスするためのIAMロールを作成

いきなり難所が来ます。
ロール作成時の最初の画面でCloudWatch Logs信頼されたエンティティとしてCloudWatch Logsを選択できればいいのですが選択できないので、一旦EC2を選択します。
（ここではEC2としていますが、何を選択しても問題ありません）

続いてステップ2の許可を追加画面では「AmazonKinesisFirehoseFullAccess」を選択します。

最後にステップ3の名前、確認、および作成画面では信頼されたエンティティの箇所を編集したい気持ちをぐっとこらえて、一旦ロールを作成してしまいましょう。
ここで編集を押してしまうと、JSONを編集できるわけではなくステップ1の画面に戻されてしまいます。

一旦ロールを作成してから、当該ロールを選択し、信頼ポリシーを編集していきます。
記述するポリシーの内容は以下の通りです。
リージョンは適宜変更してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logs.ap-northeast-1.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

これでロールの作成が完了しました

まとめ

なぜマネコンからはCloudWatch Logsを信頼されたエンティティとして選択できないのかは謎のままでした。情報求む。

また、構築の手順を記している参考になる記事をいくつか探していたのですが、すべてAWS CLIを用いて構築している記事も見かけました。そちらの方では何の問題もなくロールが作成できていました。最近LinuxやKubernetesの勉強をしており、コマンドを巧みに操るエンジニアへの憧れが日に日に強くなっているので、AWS CLIにも手を出そうかなと思いました。

投稿後追記

社内のAWSと言えばこの人！という先輩から「カスタム信頼ポリシーを使えば一撃で作れるよ」というアドバイスをいただきました。

めちゃくちゃ簡単だった......

今回は間違いを投稿したわけではないですが、遠回りになる方法を投稿したおかげでより近道のルートを教えていただくことができました。カニンガムの法則ですね。ありがとうございます！

ちなみに、なぜAWSのサービスとして対応していないのかを尋ねたところ、「推測だが、あまりニーズがないのではないか。もしAWSのサポートに要望が出されれば実装される可能性がある。」という旨の回答をいただきました。AWSはまだまだ枯れた技術になっておらず、日進月歩で改善されているのだろうな、と思いました。