Go to Qiita Advent Calendar 2024 Top
LoginSignup
14
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ガバメントクラウドAdvent Calendar 2024

Day 25
@tsurunoqiita(Yuma Tsurugasaki)inNTT DATA P&S TSG Cloud Community

AWSシステム構築時の見積もり時の注意ポイント

Last updated at Posted at 2024-12-26

0.はじめに

NTTデータの鶴ヶ崎です。
公共分野の技術戦略組織に所属しており、普段はクラウド（主にAWS）を用いたシステム構築等を行っています。

業務でAWSを使用することが多いため、自身の育成のためにもAWSでのシステム構築における見積もり時の注意ポイントをガバメントクラウド活用のヒント『見積もりで注意すべきポイント』を参考に備忘として纏めようと思います。

※本ブログに記載した内容は個人の見解であり、所属する会社・組織とは関係ありません。また、誤った情報が含まれる可能性もありますのでご留意ください。

目次

1.コンピューティング費用の見積もり

コンピューティング費用はクラウド費用全体の大部分を占めます。
そのため、見積もり結果に大きく影響する部分となるため、現行システムのサーバやリソース情報を読み取りインスタンスを選定/見積もりしていきます。

1.1 EC2

はじめにコンピューティング費用のうちEC2の見積もりポイントを説明します。

1.1.1インスタンスタイプの選択

インスタンスタイプには以下の4つの情報が含まれます。

  1. インスタンスファミリー
  2. インスタンス世代
  3. インスタンスの追加機能
  4. インスタンスサイズ

例えばc7gn.xlargeは以下のようになります。
image.png

1.1.1.1インスタンスファミリーの選択

image.png
インスタンスファミリーはメモリ・I/O・CPU クロック重視・GPU・FPGA 搭載などの種類を表します。

タイプ 概要 例
汎用 CPU/メモリ/ネットワークのリソースバランスが取れている t,mシリーズ等
コンピューティング最適化 汎用タイプよりCPUが高性能
搭載メモリサイズは下がる		 cシリーズ
ストレージ最適化 大量のI/Oトランザクションに対して低レイテンシーで利用可 iシリーズ
メモリ最適化 汎用タイプより搭載メモリサイズ増 rシリーズ
高速コンピューティング ハードウェアアクセラレーターを使用して、浮動小数点計算/グラフィックス処理/データパターン照合などの機能を、CPUで実行中のソフトウェアよりも効率的に実行 g,pシリーズ

それぞれのユースケースは以下で、ユースケースに合ったタイプの選択/見積もりを行います。

  • 汎用
    他のインスタンスファミリーを要する場合以外
    ※tシリーズは安価だが、一定の時間帯のみリソース負荷がスパイクするユースケースに適している
    　
  • コンピューティング最適化
    メモリは少なくてもよい場合
    高性能/高負荷なWebサーバ、バッチ処理など
    　
  • ストレージ最適化
    I/Oトランザクションが多い場合
    インメモリDB、NoSQL DB、データウェアハウスなど
    　
  • メモリ最適化
    より大きいメモリ量が必要な場合
    　
  • 高速コンピューティング
    アクセラレータ利用の場合
    機械学習、画像解析など
    image.png

1.1.1.2インスタンス世代の選択

image.png
同じインスタンスファミリーでも、世代が進むにつれて数字が大きくなります。
数字が大きい方が高性能かつコストパフォーマンスも良いので、要件に合わせて可能な限り新世代の利用が良い
image.png

1.1.1.3インスタンスの追加機能の選択

image.png

第 6 世代からは、全インスタンスタイプでCPUタイプを表す記号が付与されるので、要件に応じて追加機能の選択/見積もりを行う

  • Intel Xeon 搭載：　i
    　
  • AMD EPYC 搭載：　a
    　
  • AWS Graviton (Arm ベースの CPU) 搭載：　g
    　
  • 標準インスタンに対してインスタンスストア付加：　d
    　
  • 標準インスタンスに対してネットワークを強化：　n
    　
  • 標準インスタンスに対して高いCPUクロック：　z
    　
  • 標準インスタンスに対してEBS帯域を強化：　b
    image.png
    image.png

1.1.1.4インスタンスサイズの選択

image.png
インスタンスの大きさを表します。
以下図のようにインスタンスサイズが増加すると、各キャパシティも増加します。
移行対象となるシステムで現在利用しているリソースを参考にして選択/見積もりを行います。
image.png

  • 計算命令の多用、I/Oが主体、などユースケースや要件/システム特性に応じて基準を定めて見積を行う
    　
  • 現行サーバリソース使用率を加味しダウンサイジングすることで、より適切かつコスト最適なインスタンスを使用可能

1.1.2Amazon EBS の見積もり

EBS で利用できるストレージのタイプは以下2つです。詳細はAmazon EBS ボリュームタイプ のドキュメントをご覧ください。

  • 汎用 SSD(gp2,gp3)
    さまざまなトランザクションワークロードに対して、料金とパフォーマンスのバランスが取れている
    　
  • プロビジョンドIOPS SSD
    汎用SSDよりも高速/高コスト
    実利用サイズでなく、プロビジョニングされているストレージサイズで料金が決定
    image.png

1.1.2.1 IOPS/スループットの追加

例えばgp3に対して、追加料金を支払うことで、最大で16,000 IOPS、1,000 MiB/秒のスループットまでプロビジョニング可能

1.1.2.2 EBS のスナップショットの考え方

スナップショット料金に関わるパラメータは以下

  • スナップショットを取得する頻度
    　
  • 初期スナップショットの容量（=EBS の容量）
    　
  • 増分スナップショットあたりの増加容量
    ※前回スナップショットからの差分のみ保存

AWSではストレージ容量の増加が容易のため必要に応じてストレージ追加可能
そのため、初期費用を抑えることが出来る

1.2 RDS

EC2の次は、RDSの見積もりポイントを説明します。

No 検討内容 ポイント
1 ノード数 プライマリだけでなく、マルチAZ・リードレプリカ構成も考慮
2 インスタンスタイプ EC2と同様に現状ワークロード特性から選択
3 RDS プロキシ利用有無 RDSインスタンス容量に基づき料金が設定
4 商用ライセンス利用の有無 商用DB利用時ライセンス費用も発生
5 データベースストレージボリュームサイズ EBSと同様にプロビジョニングされているストレージサイズにより料金が決定
6 Performance Insights 利用有無と保存期間 ・直近7日間のパフォーマンス履歴は無料
・8日以前は有料
7 バックアップストレージサイズ ・自動バックアップ保持期間は1～35日
保存期間によりバックアップ料金が異なる
8 CloudWatch を利用したRDSの監視・ログ出力 メトリック数等により料金は異なる

以下の手順で見積もりを行います。

  1. 現状のワークロードを分析から初期見積もり値を決定する
    ※繁忙期のワークロード量の分析も必要
    　
  2. 初期見積もり後、見積もり妥当性確認のPoCをし、PoC結果をから改めて必要なインスタンスタイプの見積もり

2.ネットワーク費用の見積もり

ここではガバメントクラウド活用のヒント『見積もりで注意すべきポイント』で取り上げているガバメントクラウドでよくある3パターンの見積もりを紹介します。
　
ガバメントクラウドでは、自治体庁舎とAWS環境を閉域で接続するために以下サービスを使用します。

  • AWS Direct Connect
image.png
  • AWS Transit Gateway
image.png

前提
以下 2 つのアカウントが登場します。

  • ネットワークアカウント
    自治体庁舎からの専用線接続を集約するためのアカウント
    　
  • アプリケーションアカウント
    アプリケーションが動作しているコンピューティングリソースが存在するアカウント

2.1 VPN や AWS PrivateLink なしの構成

image.png

ネットワークアカウントでの発生料金

  • ネットワークアカウント外
    • 帯域に応じた Direct Connect のポート料金
      　
  • ネットワークアカウント内
    • Direct Connect　→　Transit Gatewayへの送信データ量に対して
      • 0.02USD/GB
    • Transit GatewayのDXアタッチメントに対して
      • 0.07USD/時間
        　

アプリケーションアカウントでの発生料金

  • アプリケーションアカウント外
    • 自治体庁舎方向に流れるアウトバウンド通信に対して
      • 0.041USD/GB
    • Transit Gatewayアタッチメント　→　Transit Gatewayに送信されたデータ量に対して
      • 0.02USD/GB
  • アプリケーションアカウント内
    • Transit Gatewayアタッチメントに対して
      • 0.07USD/時間

2.2 AWS PrivateLink を利用した構成

共同利用方式などで自治体庁舎とアプリケーションアカウントのIPアドレス範囲が重複する場合、通信するために AWS PrivateLinkを用いる
image.png

ネットワークアカウントでの発生料金

  • ネットワークアカウント外
    • 帯域に応じた Direct Connect のポート料金
      　
  • ネットワークアカウント内
    • Direct Connect　→　Transit Gatewayへの送信データ量に対して
      • 0.02USD/GB
    • Transit GatewayのDXアタッチメントに対して
      • 0.07USD/時間
    • 自治体庁舎方向のアウトバウンド通信に対して
      • 0.041USD/GB
    • AWS PrivateLinkのインターフェイスエンドポイントに対して
      • 0.014USD/時間
      • 0.01USD/GB
        　

アプリケーションアカウントでの発生料金

  • アプリケーションアカウント内
    ネットワークロードバランサー (NLB) の料金

2.3 VPN を利用した構成

複数自治体庁舎からの通信を集約する場合、 Site-to-Site VPN などを利用して物理ネットワークを仮想的に分割するネットワークスライシングを行う

※一般的に Site-to-Site VPN はインターネット経由で用いるため、Direct Connectは必ず必要というわけではありません。今回はガバメントクラウド活用のヒント『見積もりで注意すべきポイント』を参考にしており、ガバメントクラウドでは自治体システムは基本的に閉域を採用しているため、Direct Connect×Site-to-Site VPNでの構成となります。
image.png

ネットワークアカウントでの発生料金

  • ネットワークアカウント外
    • 帯域に応じた Direct Connect のポート料金
    • Site-to-Site VPN の料金
      • 0.048USD/時間
    • Site-to-Site VPNでの外部送信データ量に対して
      • 0.114USD/GB
        　
  • ネットワークアカウント内
    • Direct Connect　→　Transit Gatewayへの送信データ量に対して
      • 0.02USD/GB
    • Transit GatewayのDXアタッチメントに対して
      • 0.07USD/時間
    • Transit Gatewayアタッチメントに対して
      • 0.07USD/時間
        　

アプリケーションアカウントでの発生料金

  • アプリケーションアカウント外
    • アウトバウンド通信に対して
      • 0.041USD/GB
        　
  • アプリケーションアカウント内
    • Transit Gateway アタッチメントに対して
      • 0.07USD/時間
    • Transit Gatewayアタッチメント　→　Transit Gatewayに送信されたデータ量に対して
      • 0.02USD/GB

3.ガバナンス・セキュリティ費用の見積もり

ガバメントクラウドでは必須適用テンプレートによって自動適用されるガバナンスやセキュリティのサービスには、以下のようなものがあります。
パブリッククラウドにおいても、以下サービス利用ケースは多いと思うので参考になるかと思います。
　

  • AWS CloudTrail
image.png

AWS を操作した際の証跡ログを半永久的に保存可能
データ処理やデータ保持に料金がかかる
　

  • AWS Config
image.png

AWS リソースの構成変更記録、構成変更を管理
AWS Config ルールなど評価数に対して料金がかかる
　

  • Amazon GuardDuty
image.png

脅威の検知と継続的監視
分析した CloudTrail イベント件数やログデータ量などに対して料金がかかる
　

  • AWS Security Hub
image.png

様々なセキュリティデータを集約して、一元的に可視化/優先順位づけ
実行されたセキュリティチェック件数、他サービスからの検出結果の取り込み件数などに対して料金がかかる
　

  • AWS Trusted Advisor
image.png

ベストプラクティスに準拠するための推奨事項の提供
AWSサポートの各プランに組み込まれているためAWS Trusted Advisor単体では料金は発生しません

4.バックアップ費用の見積もり

地方公共団体情報システム非機能要件の標準では、大規模災害発生時の標準的な復旧目標時間は「1 か月以内に再開」とされています。
　
上記を満たしコストを抑えられる災害対策の手法として、セカンダリリージョン（東京リージョンをプライマリリージョンとする場合は大阪リージョン）にバックアップを保持が考えられます。

そのことにより、災害時はプライマリリージョンが復旧後、セカンダリリージョンのバックアップからデータ復元し、システムの稼働を再開可能です。

image.png

4.1 東京リージョンにおいて追加でかかる費用

  • EC2 と EBS のバックアップストレージ料金
    • コピーするEC2/EBSスナップショットの保存容量に対して料金発生
      • 0.05USD/ 月GB
        　
  • データベースのバックアップストレージ料金
    • コピーするDBスナップショット保存容量に対して料金発生
      ※Amazon RDS for MySQLは、データベースストレージの容量と同じ分だけ無料
      　
  • 東京リージョン　→　大阪リージョンへのデータ転送料
    • USD 0.09/ GB

4.2 大阪リージョンにおいて追加でかかる費用

  • EC2 と EBS のバックアップストレージ料金
    • コピーしてきたスナップショットの保存容量に対して
      • USD 0.05/ 月GB
        　
  • データベースのバックアップストレージ料金
    • コピーしてきたDBスナップショット保存容量に対して
      • USD 0.095/ 月GiB(Amazon RDS for MySQLの場合)

5.コスト削減

コスト削減の手段として以下の4手法を紹介します。

  • ダウンサイジング
    　
  • 最新世代インスタンス・ストレージタイプ利用 / コスト効率の良いCPUへ変更
    　
  • 開発環境を不使用時は停止する運用への変更
    　
  • 低コストのストレージクラスの利用
    　

6.おわりに

ガバメントクラウド/パブリッククラウド問わず、AWSでの見積もり時の参考になれば幸いです。

参考URL

14
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
14
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?