ROBOT PAYMENT Engineers Blog

株式会社ROBOT PAYMENTのテックブログです

新規プロダクトのAWSサービスコスト見積もり

こんにちは。ROBOT PAYMENT (以下、ロボペイ)でエンジニアをしているtakamoriです。 私が所属しているチームでは、新規SaaSプロダクトを開発しており、その中でAWSサービスのコスト見積もりを行いました。 そこで今回は、AWSサービスのコスト見積もり方法を書いていきたいと思います。

※ 注意 ※ 今回の見積もりでは、無料利用枠を考慮していません。 無料利用枠を加味すると、実際の使用料金は見積もりより安くなる可能性があります。 また、見積もりの入力値は、実際のプロダクトで利用する値とは異なる参考値です。

対象のAWSサービス

今回はプロダクトの構成に従って下記のAWSサービスを対象に見積もりを行いました。 - AWS Amplify - Amazon Simple Storage Service (S3) - Amazon Elastic Container Registry (ECR) - Amazon Aurora - Amazon Virtual Private Cloud (VPC) - AWS App Runner

プロダクトの構成は、こちらの牧野さんの記事で詳しく紹介しています。 tech.robotpayment.co.jp

AWSサービスの見積もり方法

AWSはコスト見積もり用のツール「AWS Pricing Calculator」を公開しています。 基本的にはこのツールを利用して見積もりを行いますが、今回、App Runnerのみ非対応となっていたため、自身で計算を行いました。

AWS_Pricing_Calculator index

AWSサービス見積もりの難しいポイント

利用するデータ量やコンピューティングリソースの見積もりは難しいポイントで、今回の見積もり対象ではS3やECR、Aurora、VPCが該当します。 特にS3やAuroraといったデータストレージでは、毎月、容量の増加が想定されますので、利用想定が変更になる度に再見積もりが必要になると思います。 今回はロボペイで類似プロダクトを提供していますので、その値を参考に見積もりました。

見積もり詳細

AWS Amplify

必要なパラメーター
  • 静的ウェブホスティング
    • ビルドの分数 : 1ヶ月あたりのアプリケーションビルドに必要な時間
    • 保存されたデータ/月 : 1ヶ月あたりのビルド時に利用されるストレージ容量
    • 提供されたデータ/月 : 1ヶ月あたりのアプリケーションからデータを提供した容量
パラメーター試算
  • ビルドの分数 : 600 ビルド分/月
    • 前提 : 平均ビルド時間 = 3 分、作業日数/月 = 20
    • 1 か月の合計ビルド時間 = 開発者数 x コミット回数/日 x 日数 x 平均ビルド時間 = 5 x 2 x 20 x 3 = 600 ビルド分/月
  • 保存されたデータ/月 : 4.88 GB
    • 前提 : ウェブアプリケーションのサイズ = 25 MB
    • 保存されたデータ/月 = ウェブアプリケーションのサイズ x 月間ビルド数 = (25/1024) x (5 x 2 x 20) = 4.88 GB
  • 提供されたデータ/月 : 13.18 GB
    • 前提 : リクエストされるページの平均サイズ = 1.5 MB
    • 提供されたデータ/月 = 1 日あたりのアクティブユーザー数 x 平均ページサイズ x 日数 = 300 x (1.5/1024) x 30 = 13.18 GB
結果

Amplify結果

Amazon Simple Storage Service (S3)

必要なパラメーター
  • S3標準
    • S3 標準ストレージ : 1ヶ月あたりの保村されたオブジェクトの合計容量
    • S3 標準に対する PUT、COPY、POST、LIST リクエスト
    • S3 標準からの GET、SELECT、および他のすべてのリクエスト
    • S3 Select によって返されたデータ
    • S3 Select によってスキャンされたデータ
  • データ転送
    • 受信データ転送 : 1ヶ月あたりのS3へ転送するデータ量
    • 送信データ転送 : 1ヶ月あたりのS3から転送するデータ量
パラメーター試算
  • S3 標準ストレージ : 100 GB / 月
  • S3 標準に対する PUT、COPY、POST、LIST リクエスト : 1,000,000 回
  • S3 標準からの GET、SELECT、および他のすべてのリクエスト : 2,000,000 回
  • S3 Select によって返されたデータ : 0 GB / 月
  • S3 Select によってスキャンされたデータ : 0 GB / 月
  • 受信データ転送 : 10 GB / 月
  • 送信データ転送 : 10 GB / 月
結果

S3結果

Amazon Elastic Container Registry (ECR)

必要なパラメーター
  • ストレージ設定
    • 保存されたデータ量
  • データ転送
    • 受信データ転送 : 1ヶ月あたりのECRへ転送するデータ量
    • 送信データ転送 : 1ヶ月あたりのECRから転送するデータ量
パラメーター試算
  • 保存されたデータ量 : 10 GB / 月
    • 前提 : コンテナイメージサイズ = 1 GB、コンテナイメージの最大保存数 = 10 個
    • 保存されたデータ量 = コンテナイメージサイズ x コンテナイメージの最大保存数 = 10 GB
  • 受信データ転送 : 5 GB / 月
    • 前提 : コンテナイメージサイズ = 1 GB
    • 受信データ転送 = コンテナイメージサイズ x コンテナイメージアップロード回数 = 1 x 5 = 5 GB
  • 送信データ転送 : 5 GB / 月
    • 前提 : コンテナイメージサイズ = 1 GB
    • 送信データ転送 = コンテナイメージサイズ x コンテナイメージダウンロード回数 = 1 x 5 = 5 GB
結果

ECR結果

Amazon Aurora

必要なパラメーター
  • インスタンスの仕様
    • 数量
    • インスタンスタイプ
    • 価格モデル
  • データベースストレージ
    • ストレージ量 : Aurora クラスターの合計ストレージサイズ
    • ベースラインIOレート : オフピーク期間中にワークロードが消費する 1 秒あたりの IO 数
    • ピーク時のIOレート : ピーク期間中にワークロードが消費する 1 秒あたりの IO の最大数
    • ピーク時のIOアクティビティ時間 : クラスターまたはインスタンスのワークロードがピーク時に動作する 1 か月あたりの時間数
パラメーター試算
  • 数量 : 2
  • インスタンスタイプ : db.r6g.large
  • 価格モデル : OnDemand
  • ストレージ量 : 100 GB
  • ベースラインIOレート : 3 IO / 秒
    • 前提 : 1秒あたりのリクエスト数 = 1 回、1リクエストあたりの平均DBアクセス数 = 3 IO
    • ベースラインIOレート = 1秒あたりのリクエスト数 x 1リクエストあたりの平均DBアクセス数 = 3 IO / 秒
  • ピーク時のIOレート : 180 IO / 秒
    • 前提 : 1秒あたりのリクエスト数 = 60 回、1リクエストあたりの平均DBアクセス数 = 3 IO
    • ベースラインIOレート = 1秒あたりのリクエスト数 x 1リクエストあたりの平均DBアクセス数 = 180 IO / 秒
  • ピーク時のIOアクティビティ時間 : 20 時間 / 月
結果

Aurora結果

Amazon Virtual Private Cloud (VPC)

必要なパラメーター
  • Network Address Translation (NAT) Gateway
    • NATゲートウェイの数
    • NATゲートウェイごとに処理されたデータ
パラメーター試算
  • NATゲートウェイの数 : 2つ
  • NATゲートウェイごとに処理されたデータ : 100 GB / 月
結果

VPC結果

AWS App Runner

課金要素
  • プロビジョニングされたコンテナインスタンス

    アプリケーションのデプロイ時には、各コンテナインスタンスでプロビジョニングされたメモリに対して費用が発生します。アプリケーションがアイドル状態のときにもコンテナインスタンスのメモリをプロビジョニングしておくことで、レイテンシーを常にミリ秒単位に抑えることができます。

  • アクティブなコンテナインスタンス

    アプリケーションがリクエストを処理する際には、プロビジョニングされたコンテナインスタンスから、アクティブなコンテナインスタンスに切り替わります。アクティブなコンテナインスタンスは、メモリリソースとコンピューティングリソースの両方を消費します。プロビジョニングされたコンテナインスタンスによって割り当てられたメモリを超えるコンピューティングと追加メモリを消費した分については、費用がお客様のご負担となります。App Runner は、アプリケーションの処理要件に応じてアクティブなコンテナインスタンスの数を自動的に増減させます。アプリケーションが使用するアクティブなコンテナインスタンスの数に上限を設定することもできるので、費用が予算を超えないように指定できます。アクティブなコンテナインスタンスがアイドル状態になると、App Runner はプロビジョニングされたコンテナインスタンスにスケールバックします (デフォルトはプロビジョニングされたコンテナインスタンス 1 つ)。

    コンテナインスタンスの処理はすべて 1 秒ごとに請求され、1 秒未満は切り上げられます。プロビジョニングされたコンテナインスタンスがリクエストの処理を開始するたびに、vCPU リソースに対して 1 分間分の最低料金が発生します。

  • ビルド料金

    App Runner がソースコードからアプリケーションを構築する際に要する時間分の構築料金が加算されます。構築料金は、アプリケーションの最初のデプロイ時に、またはソースコードに変更があった場合にのみ請求されます。

前提
  • アプリケーションの設定
    • コンテナインスタンスのサイズ : 1 vCPU、2 GB
    • 同時実行 : 100 リクエスト / アクティブなコンテナインスタンス
    • プロビジョニングされたコンテナインスタンス数 : 1
  • アプリケーションのビルド
    • 平均ビルド時間 : 5 min / 回
    • ビルド回数 : 10 回 / 月
  • トラフィック
    • 毎日 10時間、毎秒約 60 回のリクエストが散発的に発生
    • 受信したリクエストを処理するためにサービスをコンテナ 1 つ分のみスケールアップ
    • 毎日 24 時間、コンテナインスタンスのメモリをプロビジョニング
結果
  • 合計 : 37.48 USD / 月
    • アプリケーション料金 : 37.23 USD / 月
      • プロビジョニングされたコンテナインスタンス : 12.93 USD / 月
        • 24時間 x プロビジョニングされたコンテナインスタンス 1 x ( 2 GB x 0.009 ) = 0.431 USD / 日 = 12.93 USD / 月
      • アクティブなコンテナインスタンス : 24.3 USD / 月
        • 10時間 x アクティブなコンテナインスタンス 1 × ( 1 vCPU ×0.081 ) + ( 2 GB × 0.009 )) - 10 時間 x プロビジョニングされたコンテナインスタンス 1 x ( 2 GB × 0.009 ) = 0.81 / 日 = 24.3 USD / 月
    • ビルド料金 : 0.25 USD / 月
      • ビルド時間 x ビルド回数 x 0.005 USD/ビルド時間 ( 分 ) = 5 x 10 x 0.005 = 0.25 USD / 月

見積もり結果

最終的な見積もりは、手動計算したApp Runner分も含めて「404.46 USD / 月」となりました。 Pricing Calculatorは、全サービスの合計見積もりや作成した見積もりを簡単に共有できる機能もあり大変便利です。 是非、AWSサービスの見積もりの際はAWS Pricing Calculatorを利用してみてください!

見積もり結果

最後に

今回、見積もりに関して書いてきましたが、ここでの見積もりはあくまでも現状における見積もりであり、今後のプロダクト利用状況や方針によって随時更新していく必要があると思います。 特に見積もりが難しいコンピューティング系のサービスは高価なことが多く、利用状況により見直すことでコスト削減を見込めます。 見積もりして終わりではなく、その後も見積もりとの誤差をアップデートしながら利用サービスの最適化をすることでコスト削減を実現していきたいです。