TerraformとLambdaの管理を分離する構成について

構成概要

以下のような2つのリポジトリ構成を検討しています：

リポジトリA：Terraform専用

VPC、サブネット、EventBridge等の共通AWSリソース
Lambda関数の雛形（空の状態）だけのデプロイ
インフラ全体の一括管理

リポジトリB：Lambda関数実装用

Lambda関数のソースコード実装・修正
GitHub Actions等によるデプロイ

想定メリット

Terraformによる一括管理でインフラ全体を統制
Lambda関数の存在もTerraformで管理し、管理漏れを防止
インフラとアプリケーションコードの責務分離

懸念点

リポジトリAでLambda関数の雛形を作成後、リポジトリBから同じLambda関数をデプロイする際に、管理が衝突するのではないか

具体的には：

Terraformが管理している雛形Lambda関数リソースに対して
別のデプロイプロセス（GitHub Actions等）からコードをデプロイする
この時にTerraformの管理状態と実際のリソース状態が乖離する可能性

質問

このような構成は一般的に適切でしょうか？
また、他により良いアプローチがあれば教えてください

該当のソースコード

特になし

試したこと・調べたこと

teratailやGoogle等で検索した
ソースコードを自分なりに変更した
知人に聞いた
その他

上記の詳細・結果

「Lambda関数のリリースは、雛形だけではなく
追加実装などもTerraformで行うべき」という情報もありました。
一方で、「Lambda関数のリリース用にGitHubリポジトリを分離しても良いが、
AWS CLIでデプロイを書くべき」という情報もありました。
自分の知識、経験不足が原因だとは思いますが、
どうするべきかの整理ができていない状態です。

補足

特になし

行動規範の内容に同意します

回答1件

ベストアンサー

Lambda関数の雛形（空の状態）だけのデプロイ
GitHub Actions等によるデプロイ

ここの解像度を上げたほうが良い気がしますね。
たとえばリポジトリBでのデプロイ時にリポジトリAのTerraformを落としてきてそれを使ってデプロイするのなら設定は衝突しません。
※共通のtfstateを参照するようにしている前提です。

リポジトリAの設定とは別の方法でリポジトリBでデプロイするなら、Terraformの管理外での変更が発生するため当然衝突します。
また、どのみちデプロイではリポジトリAに入っているLambdaの設定とリポジトリBにあるLambdaのソースを組み合わせる必要があり、空の状態でデプロイするということができないと思います。（適当なソースを上げるという意味かもしれませんが、それをしてしまうとTerraformが管理しているLambdaの状態と実際のLambdaの状態が以後必ず乖離しそうです）

個人的には、TerraformでLambdaを管理することはあまりおすすめしません。
Terraform（厳密に言うとterraform-aws-provider）で管理できるのはAWS上の設定までであり、Lambdaのコードの中身の変更までは管理しきれないからです。
一応、デプロイパッケージのハッシュ値を与えてそれにより変更があったかどうかを判断させることはできるのですが、自分が過去にやったときは実際には変更が発生していないにも関わらず毎度のようにterraform planでの差分が発生するということがありました。（結構前の話なので今は改善されている可能性はあります）
Lambdaのデプロイをソースコードのzipを上げる形式ではなくコンテナで行うならECRのイメージとバージョンさえ指定すればよいのですが、ECR上のイメージが更新されたことをTerraformのLambdaリソースで検知できないので、何らかの方法でそれを連携する必要があります。
参考
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function

自分としてはその部分だけTerraformを使わずSAMに任せるか、sam packageでSAMでビルドしたものをS3に配置し、それを使ってTerraformでデプロイするようにするか、以下を参考にTerraformとSAMを組み合わせて使うかをおすすめします。
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/gs-terraform-support.html

AWS CLIでデプロイを書くべき

ここは明示的にAWS CLIを使うよりSAMを使うことをおすすめします。
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/what-is-sam.html
SAMはLambdaを含むサーバレスアーキテクチャに必要なAWSのサービスに対応しており、特にLambdaを扱うには非常に便利です。

投稿2025/08/13 22:34