API Gateway + LambdaをいろいろなIaCツールで構築したので比較する

この記事の趣旨

AWSのインフラを構築できるIaCツールっていろいろありますが、結局どれがいいのかよく分からないので、簡単なサーバレスAPIを作ってみて比較してみようと思いました。

アーキテクチャ

Amazon API Gateway + AWS Lambda で、超シンプルなサーバレスAPIを作ります。

作ったもの

https://github.com/k-ibaraki/aws-lambda-apigw-sample

この記事では作ってみて感じた違いを書いていくので、コードを触りたい人はこちらのGitHubを見てください。
コードが本体ですので、この記事は蛇足です。

今回使ったツール

• AWS CDK
  • プログラミング言語（TypeScript、Python、Java、C#、など）を使用して、AWSのインフラを構築できるツール
• Serverless Framework (文字を打つのが面倒なので以下slsと書きます)
  • サーバーレスアプリケーションを開発、デプロイ、および管理するためのオープンソースのツール
• AWS SAM
  • AWS上でサーバーレスアプリケーションを開発、デプロイ、および管理するためのツール
• AWS Amplify
  • AWSを利用してモダンなWebアプリやモバイルアプリを構築するためのツール

Terraformとかも試そうと思ったのですが面倒くさくなったので保留しています。
CFnは今どきはCDKでいいよねと思ったので優先順位下げました。
気が向いたら後から追加します。

個人的な比較

どのツールでもAWS上にAPI GatewayとLambdaを構築できたので、好きなの使えば良いんじゃないという感じですが、それだと記事にならないので、実際に作ってみた個人的な感想を書いていきます。

思想の違いが、コードの記述方法にも反映されている

各ツールの考え方の違いがコードの書き方の違いになっていると感じました。具体的には、、、

• SAMやslsは、Lambdaを先に作って、それにAPI Gatewayを紐付ける
• Amplifyは、API Gatewayを先に作って、それにLambdaを紐付ける
• CDKは、API GatewayとLambdaをそれぞれ作って、その後で2つを統合する

これは、前述の各ツールの説明に書いたそれぞれのツールの特徴がそのまま反映されており、

• SAMやslsはサーバレスであることが重要なので、Lambdaを中心に考える
• Amplifyはwebアプリで使用するAPIが欲しいので、API Gatewayを先に考える
• CDKは純粋なインフラ構築の手段なので、平等に扱う

ということなのかなと思いました。

LambdaのTSのビルドのしやすさ

SAM > sls > CDK >>>>>>>> Amplify

LambdaをTypeScriptで書いた場合、デプロイの前にビルドをする必要があります。なので、デプロイしたいときに自然にビルドできるツールが望ましいです。一方で、Lambda上で動くプログラムのコードとインフラのコードは分けて管理したいです。混乱するので。
という感じの前提のもと、ビルドのしやすさはの個人的な評価は上のようになりました。

SAM

SAMはコードを完全に分離しつつ、下記のような感じで設定ファイルにビルドの設定を書いておけば、sam build コマンドで、いい感じにビルドしてくれるので分かりやすいと思いました。
https://github.com/k-ibaraki/aws-lambda-apigw-sample/blob/2023-06-22/SAM/ibaraki-sam-sample-api/template.yaml#L29-L36

slsやSAM

slsやSAMも特に問題があるわけではないのですが、インフラのコードもLambdaのコードもTypeScriptで書いたので、SAMと比べて境界がちょっと分かりにくいという感じました。慣れれば大丈夫だとも思うので特に問題はないですが。

Amplify

どうしてこうなったの。。。？

https://docs.amplify.aws/cli/function/build-options/

英語のドキュメントを貼ってもよく分からないと思うので、使いにくいと感じるところを上げると、

• Lambdaのソースコードの階層がやたら深くて遠い
  • (root)/amplify/backend/function/[function name]/src
• srcの下にpackage.json
  • 普通はこうだよね

  [function name]
  ├── package.json
  └── src/
  

  • なんでこうなの？

  [function name]
  └── src/
      └── package.json
  

• ビルド結果のindex.jsもsrcの直下に置かなければならない
  • TypeScriptにおけるjsファイルはソースでは無いのでsrcに置きたくない
• ビルドコマンドを書く場所が、プロジェクトルートのpackage.json
  • Lambda用のpackage.jsonとは別に作らなければならなく、とても分かりにくい。
• amplify push時に、勝手に yarn コマンドを実行される
  • npmを使いたいんですけど。。。

動くようにしたやつはGitHubへ置いてあるので、興味があれば使ってください。
https://github.com/k-ibaraki/aws-lambda-apigw-sample/tree/2023-06-22/Amplify/ibaraki-amplify-sample-api

デプロイについて

正直どのツールでもコマンド1〜2回でデプロイで出来るので、どれが劣っているとかはないです。
他のツールと違う部分だけ書いていきます。

CDK

• npm run buildでビルドして、cdk deployでデプロイします。
• わかりやすくスタンダードな感じです。

sls

• sls deployだけで、デプロイしてくれます。
• 必要なものは、(コードに書いてなくても)自動でいい感じに構築してくれるので、とても助かります。
  • 逆に書いてないことはやって欲しくない人には要注意です。
• 公式ツールではないので、AWSのクレデンシャルやプロファイルの指定方法が違ったりするのも気をつけましょう。

SAM

• sam buildでビルドして、sam deployでデプロイします。
• 初回のdeployは手動で実施しないといけないのが、ちょっとだけ面倒に感じます。

Amplify

• amplify push でデプロイします。
  • 事前に amplify init　で初期設定しておく必要があります。
• Amplify自体がCI/CD機能を持っているので、それを使うととても楽にデプロイ出来るのが良いです。
  • ただし、Github Actionsなどで自力でCDを構築しようとするとamplify initするのが結構面倒くさいです。

まとめ

• Webアプリを爆速で作りたい時
  • AWS Amplify
• サーバレスアプリをいい感じに作りたい時
  • Serverless Framework
• サーバレスアプリを作りたい時でAWS公式ツールが良い時
  • AWS SAM
• AWS環境にスタンダードなインフラ構築をする時
  • AWS CDK

結局、用途によって使い分けたり自分にあっているツールを使うのが良いと思いますが、どれか1つだけ学びたいなら、とりあえず今ならCDKがいいんじゃないでしょうか。AWS前提なら汎用性高いですし。