普段は東京で活動している私ですが、以前SaaSのイベントでお会いしたAWSの櫻谷さんが、イベントに参加されるのをConpassで発見したので、週末だし京都行くかぐらいの感覚でイベント参加してきました。SBTのハンズオンイベントも今までなかったので、貴重な経験でした。
AWS SBTとは
SBTとは SaaS Builder Toolkit の略称で、Service Provider が User Onboarding、認証、Metrics など SaaS 事業者が共通で必要であろう Component を切り出し、Control Planeとしてデプロイできるようにしたものです。
詳細に関しては、Github、AWSの資料や書籍があるため、参照してください。
また、現在AWS SBTは開発段階のものでり、stableではないため破壊的変更が発生する可能性があるため、ご注意してください。
1. 環境構築
環境構築ではSageMaker Studio Code Editorを導入するところから始まりました。
Cloud 9が去年新しいアカウントで利用できなくなったため、SageMaker Studio Code Editorで代用しようということなのだと思います。
環境構築でSageMaker Studio Code Editorを構築をする必要があったのですが、default VPCに問題があったようで、ここで少しつまづきました。サポートのAWSの方がデバッグのお手伝いをしてくれたので、環境構築は問題なくできました。
参考: SageMaker Studio Code Editor
2. CDK
環境構築の後にCDKで
今回のHandsonではCDKを使って、 LambdaとDynamoDBを利用して、ユーザー情報を登録、取得するシンプルなアプリケーションを体験しました。Lambda <-> DynamoDBのシンプルな構築ですが、CDKはTypeScriptを利用して構築するサービスの宣言、Read/Writeなどのポリシーの設定などができるため、TerraformのConfigurationを扱うより容易に構築できると思いました。Terraformもcdktfがあると思いますが、最新のTerraform Versionには対応していない( 私がcdktfを利用しようとした際にbedrockなどの構築はできなかった ) ため、AWSの構築をする際はAWS CDKを利用するのも良い選択かと思いました。
環境構築用のコードは事前に準備したものをデプロイするだけなので、問題なく動作しました。
3. サンプルのSaaSをデプロイ
次に saas-reference-architecture-ecs デプロイして、Control Planeの挙動を体験しました。
こちらのSaaS構築自体は40分ほどかかるとのことで、構築している間に今回デプロイしているアーキテクチャに関して解説をしていただきました。
Token Vending Machine
SBTには、Token Vending Machineと呼ばれる動的にスコープを絞り込む機構があるようです。( ソースはこちら )
この機構によって、特定のTenantしかアクセスできないリソースがある場合はこの機構を利用し、適切なスコープを設定することでTenantを分離することができます。設定の変更などは今回のハンズオンでは触れることができなかったので、別の機会に設定してみたいと思います。
Tier
今回デプロイしているサンプルのSaaSでは、Basic, Advanced, PremiumのTierに分かれており、Tierによって、AWSのリソース（ ECSなど ) をTenant専用にするかを決定しています。Tierとリソースの関係性は実際は今回デプロイしたもののように綺麗に分離することは難しいとは思いますが、実際に例を見ることで、SaaSを構築する際の足がかりになるものだと思いました。
4. 環境削除
SaaS 環境構築と同様に、SaaS環境削除も40分ほどかかるとのことで、少しデプロイしたサービスに触れて、今回は削除しました。
今回利用したSampleは1日1000円ほどかかるようなので、この記事を読んで個人でSBTを試してみようと思った方は費用には気をつけて利用してください。
削除する際にS3のコンテンツを完全に削除しないと、S3が削除できなかったため、今回のハンズオンではコンソールから対象のS3のコンテンツを削除しました。（対象のS3を探すにはCloud Formationのイベント一覧から探すことができます。)
感想
生成AIやMCPなどの台頭によってビジネスモデルがまた変化していくのではないかとこの数ヶ月感じていますが、今回ハンズオンで扱ったSBTのようなSaaSの構築のハードルを下げるサービスが広まることによって、企業間のSaaS利用だけではなく、社内の部署ごとやチームごとに社内向けのSaaSを構築をすることで、グループ間のやり取りもAPIで行うことができるのではないかと思いました。