はじめに
Rehabの久良木です。
AWSには数多のサービスがありますが、その中でも私はLambdaが一番気に入っています。Lambdaはサーバーレスで処理を動かせて、インフラをあまり意識せずに済み、しかも分散・並列実行もしやすいところが魅力です。AIサービスやバッチ処理、社内業務効率化のためのツールなど、様々な用途で活用しています。
一方で、Lambda を運用していると、エラー発生時やタイムアウト時の通知をどう設計するかで意外と悩みます。Amazon Q Developer（旧 Chatbot）などの選択肢もありますが、「まずはシンプルに Slack に飛ばしたいだけ」という場面も多いのではと思います。
そこで、Lambda の運用に最低限あるとうれしい機能をひとまとめにしたテンプレートを用意しました。この記事では、その中身を紹介します。
ターゲット
- AWS Lambda をこれから本格的に使いたい方
- Lambda の運用でエラー通知やタイムアウト検知に困っている方
- Terraform で Lambda 環境を構築したい方
- aws_lambda_powertools を使ってログを整えたい方
要約
このテンプレートは、Python 3.12 のコンテナイメージで実装した AWS Lambda をデプロイし、失敗（エラー／タイムアウト）を Slack に通知する仕組みを提供します。インフラは Terraform でまとめて構築でき、ログは aws_lambda_powertools で JSON 形式に統一しているので、CloudWatch Logs Insights でのデバッグがしやすくなります。
テンプレートの概要
ディレクトリ構成
| パス | 用途 |
|---|---|
src/lambda_sample/ |
メインの Lambda 関数（Python 3.12、コンテナ化） |
src/notify_slack/ |
SNS トリガーの通知専用 Lambda（Block Kit で整形） |
infra/ |
Terraform による IaC 定義 |
tests/ |
ユニットテスト |
docs/ |
設計ドキュメント |
Dockerfile |
Lambda 用コンテナイメージ定義 |
Makefile |
コンテナのビルド・プッシュ用コマンド |
技術スタック
- 言語: Python 3.12
-
インフラ: Terraform >= 1.6（AWS Provider
~> 6.5） -
コンテナ: Docker（ベースイメージ:
public.ecr.aws/lambda/python:3.12） - ログ: aws_lambda_powertools
主な機能
1. Slack 通知機能
このテンプレートの特徴は、Lambda の処理内エラーだけでなく、タイムアウトした場合等にも Slack にアラートを飛ばせる点です。
通知フロー
CloudWatch Alarm (AWS/Lambda:Errors)
↓
SNS Topic (lambda-alerts)
↓
notify-slack Lambda
↓
Slack Incoming Webhook
CloudWatch アラームで Lambda の Errors メトリクスを監視し、閾値を超えたら SNS 経由で通知用 Lambda を起動します。タイムアウトも Errors に含まれるため、コード上の例外と同じ経路で検知できます。
通知用 Lambda（notify-slack）は Block Kit でメッセージを整形し、Slack Incoming Webhook に POST するだけのシンプルな実装です。
Block Kit による整形
通知メッセージには次の情報を含めています。
- アラーム名と状態
- 発生理由（どのメトリクスが閾値を超えたか）
- リージョン・アカウント情報
- CloudWatch Logs へのリンク
Slack から直接 CloudWatch Logs を開けるようにしてあるので、アラートを見てすぐに原因調査へ入れます。
2. aws_lambda_powertools によるログ統一
aws_lambda_powertools を使って、アプリケーション側のログを構造化しています。
これにより、例えば次のようなメリットがあります。
- ログフォーマットの統一: JSON 形式で 1 行 1 レコードになるため、CloudWatch Logs Insights でクエリを書きやすい
- トレーサビリティ向上: correlation_id などのコンテキストを含めることで、1 リクエストの流れを追いやすい
-
デバッグ効率の向上: 手書きの
printログに比べて、必要な情報をフィルタしやすくなる
ログ周りのベストプラクティスを自前で組み立てるのは意外と大変なので、最初から powertools を前提にしておけるのは地味に便利です。
3. Terraform による環境構築
Terraform で、次のリソースを一括で構築します。
- Lambda 関数（メイン + 通知用）
- ECR リポジトリ
- CloudWatch Alarm
- SNS Topic
- IAM ロール・ポリシー
主要な設定項目（terraform.tfvars）
region = "ap-northeast-1"
ecr_repository_name = "lambda-sample"
image_tag = "v1"
slack_webhook_url = "https://hooks.slack.com/services/xxx/yyy/zzz"
ecr_repository_name と image_tag は、後述の Makefile で使う REPO / TAG と合わせる前提です。
ECR イメージ管理
Terraform 側で ecr_repository_name と image_tag から ECR のイメージダイジェストを解決するようにしており、同じタグで新しいイメージを docker push したあとに terraform apply を実行すると、ダイジェストの差分を検知して Lambda の image_uri（...@sha256:<digest>）を更新する、という流れです。
使い方
1. 事前準備
- AWS アカウントと AWS CLI v2 のセットアップ
- Docker のインストール（Buildx 利用を推奨）
- Terraform >= 1.6 のインストール
- Slack Incoming Webhook URL の取得（Slack App の設定が必要）
2. デプロイ手順
# 1. コンテナをビルドして ECR にプッシュ
make build push REGION=ap-northeast-1 REPO=lambda-sample TAG=v1
# 2. Terraform で環境構築
cd infra
terraform init -upgrade
terraform apply
# 3. 動作確認
aws lambda invoke --function-name <function-name> out.json
ECR リポジトリが存在しない場合は、Makefile 側で自動作成される想定です。
3. エラー・タイムアウトのテスト
テスト用の環境変数を設定することで、意図的にエラーやタイムアウトを発生させて、通知の動きを確認できます。
-
FORCE_ERROR=1: アプリケーション内で例外を投げてエラーを発生させる -
FORCE_TIMEOUT=1: 意図的に処理を待たせてタイムアウトさせる（Lambda のtimeout設定は短めにしておく）
まとめ
AWS Lambda を本番運用する際に毎回考えることになる、エラー通知やログ設計を、このテンプレートでひとまとめにしました。
- インフラは Terraform でまとめて構築
- ログは aws_lambda_powertools で構造化
- 失敗時は Slack にアラートを飛ばす
「まずはこの辺りを一式そろえてから Lambda を書き始めたい」というときのスターターとして、使ってもらえたらうれしいです。
(追伸)
この記事はClaude CodeとChatGPTを活用して執筆しました。
Claude Codeに記事の概要、方向性をmarkdown形式で指示し、下書きを生成。その後、ChatGPTで文章のブラッシュアップを行ってます。
Discussion