結論
AWSでServerless Frameworkを利用するユーザには運用上重要な権限を与える必要があります。
今回、個人の開発アカウントならまだしも、私が担当しているようなマルチユーザかつシステム運用管理者とプログラム開発者の役割が明確に分かれているといった現場で利用するのは厳しい、という判断になりました。
サーバレスとは
雑に言うと、システムを運用するのにEC2ではなく、LambdaやAPI Gatewayを組み合わせて環境を構築すること。
Serverless Frameworkとは
文字通りサーバレスな環境を構築するためのフレームワークの一種。
様々なサービスの設定・連携を自動で処理してくれます。
何で採用を見送ったのか
私が担当している環境は開発者と運用管理者の役割が明確に分かれています。
Serverless Frameworkを組み込むとプログラム開発者にとってはメリットが大きいのですが、システム運用管理上問題になると考えたのが大きな理由です。
特に影響が大きそうなのが以下の2点です。
影響範囲が意外と広い
AWSでServerless Frameworkを利用する場合、Serverless Frameworkが自動設定するサービスは多岐にわたります。
- AWS Lambda
- AWS API Gateway
- AWS CloudFormation
- AWS DynamoDB
- AWS IAM
- AWS Cloudwatch Logs
- AWS S3
…etc
これらをプログラム開発者の方にきちんと把握してもらうのは学習コストがそこそこ高いと思われます。
何がどのように設定されたか、運用管理者からは非常にわかりづらく、トラブル時に手が出しにくくもあります。
セキュリティ的に許容できない
以下はServerless Frameworkを利用するにあたり必要な最小の権限です。
LambdaやAPI Gatewayのフルアクセス権限、IAMロールの操作権限が必要とされいます。(2021/11/16時点)
Minimum credential set for Serverless Framework ? GitHub
これらの権限を持つと以下の危険性があると考えました。
- 運用中の設定やコードを誤って削除してしまう可能性がある
- システム運用管理者の知らぬ所でプログラム開発者が危険な処理を実行してしまう可能性がある。
ということでServerless Frameworkの採用は見送りです
決してServerless Frameworkが使い物にならないというわけではありません。
開発・リリースのスピードを上げたい方にとっては有用なソリューションになりえるはずです。
権限周りについては今後改善される可能性もありますし、開発用/本番用でAWSアカウントを分けるなどの対策もあるかと思います。
手作業で各サービスの設定をするのは確かに手間ですので、運用改善を目指し引き続き注視していきたいフレームワークです。
