AWS SaaS Boost のデプロイで作成されるリソースを整理してみた

いわさです。

DevelopersIO ではいくつか AWS SaaS Boost に関する記事がありますが、私も以前 SaaS Boost を試したことがあります。

SaaS Boost を AWS 環境へデプロイすると CloudFormation によってたくさんのリソースが作成されます。
以前はそれらの数が多すぎて、以下のコメントを残して詳細の把握を後回しにしていました。

SaaS Boost環境は大量のCloudFormationスタックで構成されています。このあたりの構成は次回以降に整理しておきたいと思います。

今回 SaaS Boost 環境をまた作成する機会があったのでリソースを棚卸ししてみましたので紹介します。
また、新規 AWS アカウントで検証したので、テナント向けのアプリケーションをデプロイせずに純粋な SaaS Boost 環境のみでどの程度のランニングコストが発生するのかについても紹介します。

さきにまとめ

作成されるリソースの構成

リソースを棚卸しした結果を構成図のようなものにまとめてみました。
SNS や SQS、KMS や SSM パラメータなど補助する形でいくつか使われているものもあるのですがそれらは全体を捉える上では重要度が低いと思ったので一旦除外しました。

SaaS Boost でデプロイされるリソースは以下の３つのグループに分けることが出来ます。

管理機能（構成図の左上）

管理機能は SaaS 提供者がアクセスするための Web システムです。テナント利用者がアクセスするためのものではありません。 フロントエンドは CloudFront + S3 から配信される SPA で、バックエンドは API Gateway + Lambda です。
認証に Cognito を使い、管理画面の設定内容やテナント情報は DynamoDB へ保存しています。
また、管理機能から利用出来る分析機能はテナントごとにデプロイされる ALB のログを Athena 経由で取得した結果を表示しています。

完全にサーバーレスですね。
このあたりはアクセスがなければほぼ固定費のようなものは発生しなさそうです。
DynamoDB のいくつかのテーブルがプロビジョンドでしたが、かなり小さかったので利用料金としては後述の NAT Gateway などと比較するレベルのものではなさそうです。

SaaS 実行環境（構成図の下半分）

こちらは SaaS Boost デプロイ後はマルチ AZ な VPC と Transit Gateway がデプロイされます。
SaaS Boost でアプリケーションをデプロイする際にはサイロモデルが採用され、各テナントごとに VPC が作成されテナント分離された環境が作成されます。
どうやら各テナントの VPC からアウトバウンド通信を行う際には Transit Gateway を経由して Egress 用の VPC を行う方式となっているようで、デプロイされるテナントが一つもない状態でもこれらだけはデプロイされます。

これによって NAT Gateway と Transit Gateway のプロビジョニング費用は発生しそうです。

分析機能（構成図の右上）

こちらの分析機能ですが Athena + Glue + S3 の基本的なものについてはデフォルトで作成され、SaaS Boost 管理画面から利用します。
SaaS Boost のインストールオプションでは追加の分析機能を利用することが出来ます。
その場合は構成図に記載のとおり QuickSight と Redshift を利用する形となります。

今回私のアカウントでは QuickSight も Redshift も無料枠が適用されてコストが確認出来なかったのですが、これらもデプロイしただけで料金は発生し続けそうです。
ただ、オプションの分析機能についてはデプロイしないという選択肢もあります。

利用料金

利用料金ですが、デプロイ後 20 時間ほど放置した環境で以下のようになっていました。

ほとんど NAT Gateway と Transit Gateway の料金ですね。
さらに QuickSight と Redshift は無料枠が適用されてはいましたが実際には発生するはずです。

Pricing Calculator でそれら 4 つを計算してみたところ以下のようになりました。
Redshift は dc2.large です。

分析オプションなしで 141 ドル/月、分析オプションありで 395 ドル/月程度は SaaS Boost の環境維持だけで発生するということになります。
これに加えてテナントごとにプロビジョニングされるコンピューティングリソースやデータ通信料金といったところを考える必要があります。

リソースの棚卸ししてみる

Cost Explorer からどのリソースが使われているのかだいたいわかったので、ここからリソースを調べてみました。
最初 CloudFormation スタックやコードから解析しようと思ったのですがこちらのほうがサッと終わりそうなのでそうすることに。

VPC

VPC はまとめで触れたように Egress VPC が用意されています。
マルチ AZ で NAT Gateway がデプロイされています。

また、Transit Gateway アタッチメントが 1 つデプロイされており、ルートテーブルでは 0.0.0.0/0を Egress VPC に向けています。

CloudFront + S3

S3 オリジンの CloudFront を使って管理機能を配信しています。
HTML や JavaScript などの静的コンテンツが格納されています。

他にもいくつか S3 バケットが作られていますが、テナントアプリケーションのアクセスログや、あるいは SaaS Boost デプロイ時に作成されたモジュール格納用のバケットだったりします。

CodeBuild

CodeBuild プロジェクトがデプロイされていますが、これを使って管理画面がデプロイされています。

BuildSpec はプロジェクト設定に直書きされていてyarn buildやs3 syncが実行されています。

version: 0.2
phases:
  pre_build:
    commands:
      - n 14
      - if [ "$REACT_APP_AWS_REGION" = "cn-northwest-1" ] || [ "$REACT_APP_AWS_REGION" = "cn-north-1" ]; then npm config set registry https://registry.npm.taobao.org; fi
      - aws s3 cp s3://$SOURCE_BUCKET/client/web/src.zip src.zip
      - unzip src.zip
  build:
    commands:
      - cd ./client/web
      - yarn
      - yarn build
      - cd ../../
  post_build:
    commands:
      - aws s3 sync ./client/web/build/ s3://$WEBSITE_BUCKET/ --delete --cache-control no-store --exclude "*" --include "index.html" --include "asset-manifest.json" --include "static/*"
      - aws s3 sync ./client/web/build/ s3://$WEBSITE_BUCKET/ --delete --include "*" --exclude "index.html" --exclude "asset-manifest.json" --exclude "static/*"

Lambda + API Gateway + SQS + SNS

Lambda はかなり数が多くて 73 個デプロイされていました。
中身を見るのはちょっとつらいなと思いました。なので関連リソースからどういうものか推測するまでに留めました。

SNS

SNS トピックがいくつか存在していますが、全て Lambda プロトコルのサブスクリプションでした。
SNS 経由で Lambda を実行する仕組みになっています。

SQS

SQS キューも同様にいくつか存在しており、Lambda トリガーが設定されています。

SNS と SQS はサーバーレスアプリケーションの繋ぎこみに使われていると考えて良さそうです。

API Gateway

API Gateway は API が 2 つデプロイされていました。
名前は Public と Private となっていましたがどちらもリージョナルです。

その 2 つは認可部分が違っていて、Public は Lambda オーソライザーが使われおり、Private は IAM　となっています。

おそらく Public はユーザーが Cognito トークンでアクセスし、Private は Lambda から実行ロールで呼び出される形でしょうおそらく。

Cognito

Cognito ユーザープールで管理画面へのアクセスユーザーが管理されています。

DynamoDB

DynamoDB は管理画面で登録したアプリケーション、サービス、Tier など様々な情報を保存する永続的なデータストアとして使用されています。

試しに Tier をいくつか構成してみたところ DynamoDB 上に項目が作成されていました。

QuickSight

QuickSight は分析結果を可視化する部分ですが、分析は存在していなくてデータセットまでが作成されていました。

データセットのデータソースは Redshift になっています。

分析やダッシュボードはもしかして自分で用意しろということだろうか...？
SaaS Boost の分析オプションがどういう使い方が出来るのかは次回以降にまとめたいと思いますのでそちらで確認出来ればと思います。

Redshift + Kinesis Firehose

QuickSight のデータソースとして使われる Redshift ですが Kinesis Firehose の配信ストリームを経由して Redshift へ COPY される方法が取られています。

おそらくメトリクスなどをテナントアプリケーション側から送信しないければいけない気がします。
このあたりは先程の QuickSight と併せてデータ分析オプションの確認を別途行いたいと思います。

さいごに

本日は AWS SaaS Boost のデプロイで作成されるリソースを整理してみました。

前まではかなりブラックボックスだったのですが、今回全体像をつかめたのでコントロール出来そうな気がしてきました。
利用料金については NAT Gateway と Transit Gateway のコストがちょっとかかってしまいますが、デプロイされるテナントが多くなればこちらの方が最適かもしれないですね。

データ分析追加オプションの使い方がまだわかっていないのでそのあたりを掘り下げたらまた紹介したいと思います。