AWS Lambdaの構築はTerraformではなく、SAMで！

LambdaはSAMで

タイトルの通りですが、「Lambda は SAM で」ということです。
Terraform での構築は嫌いです。

なぜ

Lambda は関数リソース作成時に、関数コードが必要となるからです。

通常は、以下の 2 つのステップで構築します。

1. Terraform でのリソースの構築
2. CI/CD での継続的デプロイ

Lambda は 1 の段階で関数コードを指定する必要があります。
そのため、CI/CD での継続的デプロイが困難です。

Terraform での構築後に、Lambda の関数コードを更新可能ですが、そこまでする必要があるのか疑問です。

さらには、IaC(IaC: Infrastructure as Code)の考え方に反するとも言えます。
これは、Terraform によってインフラ以外のコードを管理することになるためです。

SAMでの構築

SAM は、AWS が提供している、Lambda の IaC ツールです。
SAM は Terraform とは異なり、AWS のサービスに特化したツールで、リソースの構築だけでなく、CI/CD の構築も容易です。

クラウドプロバイダ間の差異を吸収してくれる Terraform が好きですが、Lambda に関しては SAM を使うべきです。

---

Azure では Azure Functions を使うことが多いのですが、Azure Functions は Terraform での構築が可能です。
これは、Azure Functions は関数コードを指定する必要がないためです。

関数アプリと呼ばれる関数のコンテナリソースを Terraform で構築し、その中に関数を登録するという形になります。
したがって、リソース構築時に関数コードを指定する必要がないため、IaC としての Terraform の考え方に沿っています。
また、このように構築しても、CI/CD での継続的デプロイが可能です。