「既存のロール」でLambda関数つくるときに気をつけること

サーバレスといえば、Lambdaだと、ポンポン作ってると、ふと、CloudWatchにログ出力されてない関数があることに気づきました。

正常動作してるときには、ログ出力されてなくても気にならないけど、トラブルシュートする時に見れないのは致命的。

あと個人的には、Pythonコードでエラーでたときの Traceback が切り捨てなく見れるのがポイント高い。

ちょっと過去の記憶を元に原因を探ってみました。

「既存のロール」選択時に注意

ログの出ない関数が２つになった時に、思い当たったのが、この設定。アクセス制限の実行ロールを「既存のロール」から選択していました。

新しい関数 "my_second_function" を作成する時に、直前に作った "my_first_function" のロールを選択しました。

既存のロール　選択時

選んだのは、新しいロールを増やしても、同じIAM設定を繰り返さないと行けないから、前に自動で作られたロールを選んだという理由。

でもこの画面下部にある

この Lambda 関数で使用するために作成した既存のロールを選択します。このロールには、Amazon CloudWatch Logs にログをアップロードするアクセス許可が必要です。

をスルーしていたのが原因でした。

Lambda関数作成時の新しいロール

そもそも、新しいロール を Lambda関数を作る時に自動作成させると、IAMロールが関数毎にユニークに作成されて、次のポリシーがアクセス制限に割り当たります。

• AWSLambdaBasicExecutionRole-*UUID*

前出のIAMロールの場合、こんな画面になってました。

Lambda関数作成時のIAMロール

この AWSLambdaBasicExecutionRole をクリックしてみると、次のようになってます。

ポリシーのサービスとリソース

リソースには、アクセスするCloudWatch LogのARNが個別記載されてます。

あ、個別記載されてますね。Lambda関数名のロググループが。

解決方法

AWSLambdaBasicExecutionRole- の「ポリシーの編集」を行い、CreateLogStream と PutLogEvents 権限 に、新しく作成した関数のロググループのARNを追記しましょう。

• "arn:aws:logs:ap-northeast-1:XXXXXXXXXXXX:log-group:/aws/lambda/my_second_function:*"

その後、新しい関数 "my_second_function" のコードを修正して保存、テストなどを実行すれば、ロググループの作成とともに、ログストリームも作成されてログが記録されます。

※TIPS：コードの修正・保存を行わないと、存在しないログストリームへの追記を続けてしまうようで、ロググループの作成等も行われません

その他

いやぁ、きれいですね。IAMロールと、AWSリソースの関係性。

きれいが故に、GUIはなれて、CUIいかなきゃ、本番サービスの運用回らないやと感じました。

クラウドサービスの設計力、あげなきゃですわ。