Slack Metrics API用のLambdaの
周辺リソースを作成する

01作るのは Lambda 本体ではなく、その土台

教材の順序は ECR → イメージ push → IAM ロール → Security Group → 次の Lesson で Lambda 作成。ここで関数を先に作らないことに意味がある。

02ECR は「実行場所」ではなくイメージの届け先

ECR リポジトリ名は slack-metrics-lambda-stg。Terraform の内部識別子 ecr_slack_metrics_lambda と、AWS コンソールに表示される名前は役割が違う。前者はコード上の参照名、後者は AWS リソース名である。

local → stg：教材では backend ディレクトリを起点に実行する。

cd services/slack-metrics-lambda
ENV=stg make release-image

このコマンドで ECR へ push するのは、ローカルの Docker であり、その時点で有効な AWS 認証情報を使う。Lambda 実行ロールを作っても push 権限にはならない。push には呼び出し元に ECR の認証・アップロード権限が必要で、実行ロールは Lambda サービスの VPC 準備と、起動したアプリケーションの AWS API 操作に使われる。

push の失敗は、止まった段階で切り分ける

• NoCredentials：AWS CLI が認証情報を見つけていない。AWS_PROFILE とログイン状態を確認する。
• ECR の URL が違う：AWS_ACCOUNT_ID はイメージの宛先、AWS_PROFILE は操作する人の認証設定。片方の指定だけでは両方は揃わない。
• docker.sock に接続できない：docker context show と docker info で接続先と起動状態を確認する。OrbStack が動いていれば、Colima を追加起動する必要はない。

自分の環境を明示する実行例。アカウントIDは実行前に置き換える。

AWS_PROFILE=cp-terraform-stg \
AWS_ACCOUNT_ID='<自分のAWSアカウントID>' \
ENV=stg make release-image

03実行ロールは Lambda の準備と実行に使う

ロール名は cp-slack-metrics-lambda-stg。既存の ECS 用 cp-slack-metrics-backend-stg は使い回さない。誰がロールを使えるかを決める信頼ポリシーで lambda.amazonaws.com を指定し、必要なアクセスも ECS タスクとは異なるからである。

ENI は Lambda が VPC へ接続するために管理する仮想ネットワークカードであり、呼び出しごとに「専用 ENI が 1 枚」作られるものではない。ロールはその管理 API を許可し、Security Group は実際のネットワーク通信を制御する。両者は代替関係ではない。

04DB への許可は Lambda SG を送信元にする

Lambda 用 Security Group cp-slack-metrics-lambda-stg を作り、DB のインバウンドに TCP 5432、送信元としてその SG を追加する。これは「Lambda の SG を DB に付ける」設定ではない。このルールが、この SG を持つネットワークインターフェースからの PostgreSQL 接続を許可するという意味であり、既存の踏み台サーバーなどからの接続許可は維持される。

Lambda 側では外向きの通信、DB 側では入ってくる通信の両方を許可する。Lambda 側の送信許可だけでは DB 側の受信許可を代わりに満たせない。SG が通っても、ネットワーク経路と PostgreSQL のユーザー認証は別に必要になる。

Security Group は関数名そのものを識別するものではない。複数の Lambda が同じ SG を使えば、DB から見える許可単位もその SG になる。関数単位のネットワーク境界が必要になった時点で SG を分ける。

05Terraform は出力を渡して、次のモジュールにつなぐ

IAM / Security Group / ECR の各モジュールがロール ARN、Security Group ID、リポジトリ URL を出力し、stg/aws.tf の親モジュールが将来の Lambda module に渡す。これらの output は AWS リソースでもコスト発生要因でもなく、モジュール間で値を受け渡す名前付きの出口である。まだ Lambda module が無いことは欠落ではなく、Lesson 05 が周辺資源だけを作る段階だからである。

output は、値を持っているモジュールに置く

IAM の ARN は iam_role/outputs.tf、SG の ID は security_group/outputs.tf に書く。別のモジュールにあるリソースを、lambda/outputs.tf から直接参照することはできない。

# modules/aws/iam_role/outputs.tf
output "role_arn_cp_slack_metrics_lambda" {
  value = aws_iam_role.cp_slack_metrics_lambda.arn
}

# modules/aws/security_group/outputs.tf
output "id_slack_metrics_lambda" {
  value = aws_security_group.slack_metrics_lambda.id
}

親の stg/aws.tf からは module.iam_role.role_arn_cp_slack_metrics_lambda のように参照できる。次の課題で Lambda を Terraform 化する際、受け取る側の変数につなぐ。

ECRの実体を保ったまま、Terraformの名前を揃える

AWS 上の名前を変えなくても、Terraform 内部の module 名だけ変えると、state との対応が外れる。state mv は AWS の実体を作り直さず、その対応先の住所を移す操作である。2026-09-06 時点では、旧 slack_metrics_lambda を ecr_slack_metrics_lambda へ state mv した後、対象を絞った plan は No changes だった。これは当時の状態移行の記録であり、現在の環境を保証するものではない。terraform state mv の公式ドキュメントも参照する。

06この Lesson の確認と、次のチェックポイント

1. ECR コンソールで slack-metrics-lambda-stg に対象のイメージが存在する。
2. IAM で cp-slack-metrics-lambda-stg が Lambda を信頼し、必要なポリシーを持つ。
3. Security Group で Lambda 用 SG があり、DB のインバウンド TCP 5432 がその SG を送信元としている。

次の Lesson 06 は、これらを選んで API 用 Lambda を手動作成し、テストタブで API Gateway 形式のイベントを実行する段階である。アプリケーションは ENV により共有の slack-metrics-${ENV} Parameter Store を読み、MODE は API / batch / SQS で直接指定して起動処理を選ぶ。

VPC 内 Lambda と ENI の詳細は AWS Lambda の VPC 設定ドキュメント、Security Group のルールは AWS の Security Group ルールドキュメントで確認できる。