【実践】AWSランニングコストの見積もり方と考え方

AWS
2025.02.09

要件定義や運用の中でAWSの新規システム構築やシステム変更の検討の中でAWSのランニングコストの見積もりをしなくてはならない場面があるかと思います。

今回、新規システムの要件定義の中でAWSランニングコストを久しぶりに見積もりしたので、備忘録もかねてどのように検討したのかを書いておきたいと思います。

今回の見積もり時の構成

今回のシステム構成はWEBサービスを提供するもので以下AWSサービスを利用しています。

  • SPA（シングルページアプリケーション）：CloudFront + S3 + API Gateway + ECS Fargate
  • APIサーバ：API Gateway + ECS Fargate + Aurora

見積もり時のインプット情報

見積もりのインプット情報は、システムの稼働時間や性能のユーザ数や同時アクセス数などの非機能要件やAWSのアーキテクチャ（システム構成図）です。

見積もりツール

おなじみのAWS Pricing Calculator（https://calculator.aws/#/）を使い、プロジェクトで利用されているExcelに書いていくスタイルでやりました。

見積もりの構成要素

主な見積もりの構成要素としては以下となると想定しています。

  • サーバやDBのインスタンスタイプ
    • 現行サーバから移行するタイプのプロジェクトであれば、現行分析結果から推測できますが、新規システムの場合は、非機能要件からサーバの負荷量を見定めて検討しておく必要があります。
  • ネットワーク通信料
    • 正確な見積もりは難しいですが、非機能要件の性能要件より想定通信料を決めることが重要と考えます。つまり、非機能要件をちゃんと決めておかないと見積もりができないので、後工程に回さずに要件定義工程で顧客と数値レベルですり合わせしておくことがポイントになると考えます。
    • 特に料金が高いものとしてVPCエンドポイント（インタフェース型）があります。冗長性を考慮すると、一つのVPCエンドポイント毎に各VPCのAZ毎に必要となるため、東京リージョンですと3つ配置することになり、3つ分料金が発生します。
      コスト削減案として以下リンクのようにVPCエンドポイントを集約するアーキテクチャもありますので、プロジェクトの設計方針や顧客先のガイドラインを参考にしつつ検討いただければと思います。
      https://aws.amazon.com/jp/blogs/news/govcloud-vpc-endpoint-configuration/
  • AWSサポート量
  • ログ
    • 今回は、各AWSサービスやセキュリティ関連のサービス、アプリケーションログなどをCloudWatchやS3に出力する想定です。ログの見積もりは難しいので、サービス規模に合わせて○○GBと仮定したり、もしくは全体の料金の○○%と置く感じで見積もりをしました。
    • GuardDutyでは全体料金の2%となるという実績ベースの情報もありますので、実績値があればそれをもとに見積もると納得感も得やすいかと思います。
      https://dev.classmethod.jp/articles/guardduty-si-strongest-thread-detection/

まとめ

  • 今回は小規模のランニングコストを見積もりましたが、非機能要件とシステム構成がしっかりと決まっている必要があります。
  • 通信料など実績がないと見積もりづらいものもありますが、非機能要件含めて後回しにせず合意しておくことが大事だと感じています。
  • 見積もりの根拠を残しておけば、再見積もり時はスムーズに見積もれます！

コメント

タイトルとURLをコピーしました