Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみた

データアナリティクス事業本部のueharaです。

今回は、Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみたいと思います。

はじめに

2023年の10月に、Serverless FrameworkがV.4から有料化されることが発表されました。

ライセンス費用を支払いV.4を利用するというのも1つの手ではあるのですが、今回はAWS CDKとAWS SAMへの移行を検討してみたいと思います。

結論

まずは、移行を検討した結果の表を以下にまとめます。

個別の内容については以降の章で説明を実施します。

総論に記載していますが、「移行コストを考えると別にライセンス料を払っても良いよ」という方はV.4を利用し、そうでない場合は小規模アプリケーションならAWS SAMに、中〜大規模アプリケーションであればAWS CDKへの移行を検討するのが良いと思います。

移行無し（Serverless Framework V.4を利用）について

メリット

言わずもがなですが、V.4への更新に伴う変更差分のみの確認で済むため移行工数は最小になります。

デメリット

冒頭でも述べたように、V.4の利用にはライセンス料金がかかります。

サブスクリプションはServerless Framework DashboardまたはAWSマーケットプレイスから購入可能です。

多くの企業ではAWSマーケットプレイス経由で購入するのが社内手続きの申請上は楽なのかなと推察しますが、Serverless Framework Dashbordからの場合は年間購入もできるので、その場合はライセンス費用が安くなります。（参考）

なおこの「Credits」という単位は serverless.yml ファイルのregion,stage,serviceパラメータの組み合わせによって定義されるようです。

したがって、例えば開発者やチケット毎の検証環境をstageで分けている場合は、その分Creditsが嵩むという形になります。

また、serviceもどのように分割するかで総Credit数が変わってきますので、この辺は見積りのし辛さに繋がってくるのかなと思います。

例えばregionとして東京, シンガポールを用意し、stageとしてprod, stg, dev, user1, user2があり、serviceとしてxxx, yyyがある場合、単純に掛け算をすると2x5x2の20 Creditsとなります。

また、Serverless Dashboardの機能を使うと、トレース50,000あたりで1 Credit、メトリクス400万あたりで1 Credit必要となるようです。（CLIのみの利用であればこちらは課金対象外です）

AWS CDKへの移行について

メリット

AWS謹製のため無償で利用できます。

そもそもAWS側が自社のサービスを利用してもらうために開発しているものですので、そのようなバックボーンがあるのはやはり強力だと思います。

また、AWS CDKにはCDK Migrateというものがあり、これを利用することでCloudFormationスタックからAWS CDKアプリケーションを作成することができますので、Serverless Frameworkでデプロイしたスタックから移行することができます。

$ cdk migrate --language typescript --from-scan --stack-name "myCloudFormationStack"

ただし、移行に関する注意点もあるので、詳しくはAWS公式のドキュメントをご確認ください。

例えば、移行したものは「L1コンストラクトで定義される」というものがあります。（CloudFormationのテンプレートベースから移行するので、当然と言えば当然かもしれません）

ここでは詳細な説明は割愛しますが、AWS CDKは抽象化の概念としてL1〜L3とConstructのレイヤーが分かれています。

（引用元）

L1はほぼCloudFormationの設定値を書く形でプロパティを設定する必要があるので、普通に開発する分にはコードがシンプルになるL2を使うケースが多いのかなと思います。

この場合、リソースによっては「移行したものはL1で書かれており移行後の通常開発はL2が使われている」というような平仄が取れない状況も発生する可能性があります。

また、AWS CDKはディレクトリのパスの切り方が開発・運用のしやすさの面で非常に重要になって来ますので、単にCDK Migrateで移行したプロジェクトの状態が最適なものになっているとは言えません。（CDK Migrateを利用した場合、1つの.tsファイルに全てのリソースが記載されます）

上記より、CDK Migrateはあくまで「今後は追加の開発はほぼ想定してない/あっても少ない改修」くらいの状況であれば良いのかなと思いますが、Serverless FrameworkからAWS CDKに移行する銀の弾丸ではないことをご留意ください。

また、TypescriptやPythonというプログラミング言語でリソースを定義できるという都合上、変数の管理やファイル分割がしやすく、中〜大規模アプリケーション開発に向いていると言えます。

デメリット

メリットの裏返しになる部分が多分にありますが、デメリットとしてまず移行工数が高いことが挙げられます。

Serverless Frameworkではyamlで定義していたものを、AWS CDKではTypescriptやPythonなどプログラミング言語ベースに変換する必要があるので、移行工数はそれなりに高くなると思います。

また別のデメリットとして、AWS CDKはデプロイのため記載しないといけないスクリプトファイルが多かったり、リソースもクラスや関数で定義していく必要があるので小規模のアプリケーションに対しては少々過剰であることが挙げられます。

例えばcdk init --language typescriptコマンドを使用してmy-cdk-ts-projectディレクトリに作成されたプロジェクトは以下のようになっています。

my-cdk-ts-project
├── .git
├── .gitignore
├── .npmignore
├── README.md
├── bin
│   └── my-cdk-ts-project.ts
├── cdk.json
├── jest.config.js
├── lib
│   └── my-cdk-ts-project-stack.ts
├── node_modules
├── package-lock.json
├── package.json
├── test
│   └── my-cdk-ts-project.test.ts
└── tsconfig.json

ファイルは多いですがきめ細やかにリソースの定義や設定ができるため、中〜大規模アプリケーション向けかなと思います。

AWS SAMへの移行について

メリット

AWS CDKと同様、AWS謹製のため無償で利用できます。

また、Serverless Frameworkからの移行の大きなメリットとしてserverless.ymlの定義をある程度流用できたり、Serverless Frameworkに慣れていると記載が簡単ということが挙げられます。

例えば、同じLambda関数をデプロイするServerless FrameworkとAWS SAMの記述はそれぞれ以下の通りです。

Serverless Frameworkの場合（Lambda関数）

functions:
  MyLambdaFunction:
    handler: handler/test_func.lambda_handler
    name: "uehara-test-lambda"
    role: MyLambdaFunctionRole
    package:
      patterns:
        - 'handler/test_func.py'

AWS SAMの場合（Lambda関数）

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: "uehara-test-lambda"
      Role: !GetAtt MyLambdaFunctionRole.Arn
      CodeUri: handler/
      Handler: test_func.lambda_handler
      Runtime: python3.9

細かな違いはありますが、どちらもyamlベースで記載されているのでServerless Frameworkに慣れている人はAWS SAMもすぐに書けると思います。

また、IAM RoleなどはどちらもCloudFormationベースで記載をするので、Serverless Frameworkの記載内容をAWS SAMにそのまま流用することができます。

Serveless Frameworkの場合（IAM Role）

resources:
  Resources:
    MyLambdaFunctionRole:
      Type: AWS::IAM::Role
      Properties:
        RoleName: "uehara-test-lambda-role"
        AssumeRolePolicyDocument:
          Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action: sts:AssumeRole
              Principal:
                Service:
                  - lambda.amazonaws.com
        ManagedPolicyArns:
          - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

AWS SAMの場合（IAM Role）

Resources:
  MyLambdaFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: "uehara-test-lambda-role"
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action: sts:AssumeRole
            Principal:
              Service:
                - lambda.amazonaws.com
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

また、AWS SAMは最小で必要になるのが設定ファイルであるsamconfig.tomlとテンプレートファイルであるtemplate.yamlのみなので、準備も非常に楽です。

したがって、アプリケーションの規模がそこまで大きくなければServerless Frameworkからの移行はAWS SAMの方が簡単だと思います。

デメリット

小規模開発向けのフレームワークのため、共同開発がし辛いというのが挙げられます。

AWS SAMではtemplate.yamlとスタックが1対1なので、例えば1つのスタックでリソースをデプロイしたい場合は同じtemplate.yamlを複数人で触ることになるので競合が多発する可能性があります。

※以下のように、yqを使うことで無理やり分割することは可能です。

テンプレートを細かく分割してスタックをネストさせることもできますが、それはそれで管理の大変さがあります。

また、複雑な構成が定義しにくく、複雑になってくると「生のCFnを書くのと変わらないじゃん！」といった事態が発生し得ます。

その他、AWS SAMはAWS CDKと比較し情報が少なくトラブルシュートし辛いといったこともデメリットとして挙げられます。

その他参考

以前Lambda+Glue+Step Functionsの構成をServerless Framework, AWS CDK, AWS SAMでそれぞれデプロイしたブログを以下にまとめてますので、それぞれのフレームワークの書きっぷり等の参考にして頂ければと思います。

最後に

今回は、Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみました。

参考になりましたら幸いです。

参考文献

• Serverless Framework V4: A New Model
• AWS Cloud Development Kit (CDK)
• Lambda+Glue+Step Functionsの構成をServerless FrameworkとAWS SAMのそれぞれでデプロイしてみた
• Lambda+Glue+Step Functionsの構成をAWS CDKでデプロイしてみた