AWS Lambdaの構築はTerraformではなく、SAMで！
LambdaはSAMで
タイトルの通りですが、LambdaはSAMで！ということです。
Terraformでの構築は自分的には好きではありません。
なぜ？
Lambdaは関数リソース作成時に、関数コードが必要となるからです。
通常は、
- Terraformでのリソースの構築
- 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を使うべきだと思います。
補足
LambdaはLambda単体で使用することは少なく、他のAWSサービスと組み合わせて使用することが多いです。
その場合には、Terraformでの構築は非常に有用だと思います。
AzureではAzure Functionsを使うことが多いのですが、Azure FunctionsはTerraformでの構築が可能です。
これは、Azure Functionsは関数コードを指定する必要がないためです。
関数アプリと呼ばれる関数のコンテナリソースをTerraformで構築し、その中に関数を登録するという形になります。
したがって、リソース構築時に関数コードを指定する必要がないため、IaCとしてのTerraformの考え方に沿っています。
また、このように構築しても、CI/CDでの継続的デプロイが可能です。
Discussion