ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。
「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。
過去の記事はこちらになります。

• ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』
• ガバメントクラウド活用のヒント『ガバメントクラウド上で CIDR 重複を起こさないために！』
• ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 当記事

少し発展的な内容となっておりますので、ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。

本ブログでは、見積もりで注意すべきポイントについて扱っていきます。見積もりを作成したいベンダーの方々や、ベンダーから提出された見積もりに過不足がないかチェックしたい自治体の方々を対象としています。

※このブログは、地方公共団体の基幹業務システムを構成する代表的な AWS サービスを対象として、見積もりのポイントを示すための参考情報であり、実際に構成するサービスは利用する ASP ベンダーのアプリケーションに依存しますのでご留意ください。

以下のセクションで構成されています。

• コンピューティング費用の見積もり
• ネットワーク費用の見積もり
• ガバナンス・セキュリティ費用の見積もり
• バックアップ費用の見積もり
• AWS Pricing Calculator への入力
• コスト削減のヒント
• まとめ

※本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。

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

クラウド費用全体のうち、コンピューティング費用が大部分を占めるので、コンピューティングサービスの見積もりは非常に重要です。現行システムの OS/CPU/メモリや、CPU 使用率・メモリ使用率の情報があれば、それを参考にインスタンスを選定していきます。

Amazon EC2 の見積もり

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

インスタンスタイプには、インスタンスファミリー、インスタンス世代、インスタンスの追加機能、インスタンスサイズなどの情報が含まれます。例えば、 c7gn.xlarge というインスタンスタイプでは、インスタンスファミリーが c、インスタンス世代が 7、追加機能が g と n、インスタンスサイズが xlarge であるということがわかります。

EC2 のインスタンスタイプの選択の詳細については、詳しくは「AWS における効率的なコンピュートサービス活用入門」の資料もご覧ください。

インスタンスファミリーの選択
インスタンスファミリーはメモリ・I/O・CPU クロック重視・GPU・FPGA 搭載などの種類を表します。多くの種類がありますが、一般的にはメモリ要件に合わせて、メモリは少なくてもよいときはコンピューティング最適化の C インスタンス、より大きいメモリ量が必要なときはメモリ最適化の R インスタンス、その他のときは汎用の M インスタンスを選択することが多いです。 定常的な CPU 性能が不要な検証環境などでは、安価に利用できる T インスタンスを選択する場合もあります。

例えば、インスタンスサイズとしては同じ medium を利用した場合でも、vCPU 数やメモリの大きさに以下のような違いがあります。

※コストは東京リージョン、Linux のインスタンス

インスタンス世代の選択
同じインスタンスファミリーでも、世代が進むにつれて数字が大きくなります。一般的には新しい世代の方が高性能でコストパフォーマンスもよいので、要件に合わせてできるだけ新しい世代のもののご利用をお勧めします。

インスタンスの追加機能の選択
第 6 世代以降では、すべてのインスタンスタイプで CPU タイプを表す記号が付与されています。例えば、　Intel Xeon 搭載なら i、AMD EPYC 搭載なら a、 AWS Graviton (Arm ベースの CPU) 搭載なら g です。ご利用のアプリケーションパッケージがご利用のインスタンスの CPU に対応しているか確認すると良いでしょう。
その他の情報については、インスタンスタイプのページなどをご参照ください。

インスタンスサイズの選択
インスタンスサイズが増加すると、 vCPU 数とメモリ、EBS 帯域幅、ネットワーク帯域幅が増加します。移行対象となるシステムで現在利用している vCPU 数やメモリサイズを参考にして選択してください。

計算命令を多用するシステムであれば、CPU 数やクロック数を基準に見積もりを考えた方が良いでしょう。それに対し、I/O (データアクセス) が主体なものは、高速ストレージを主体に見積もりをする方が良いでしょう。データアクセス処理をメモリ領域で処理することで、高額な I/O コストを支払う場合に比べてメモリを増やす方が安価にすることが出来る場合があります。

また、現在のサーバリソースの使用率を加味することで、より適切なインスタンスの使用を検討できます。例えば、現行システムが AMD プロセッサを利用したオンプレミスサーバーで動いており、そのサーバーの CPU コア数が 8 で CPU 使用率が 20%、メモリが 32GiB で使用率が 70% の時、必要な vCPU 数が 2 、メモリが23GiB となるので、r6a.xlarge を選定する、ダウンサイジングという考え方も検討することが可能です。

Amazon EBS の見積もり

EBS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります (マグネ ティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。 実際に利用しているサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパ シティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることが出来ます。

Amazon EBS ボリュームの種類については、ドキュメントもご覧ください。

IOPS/スループットの追加

gp3 タイプを例に挙げて、IOPS/スループットの追加の考え方についてご説明いたします。gp3 では、デフォルトで 3,000 IOPS、125 MiB/秒のスループットを一貫したベースラインパフォーマンスとして提供しています。追加料金を支払うことで、最大で16,000 IOPS、1,000 MiB/秒のスループットまでプロビジョニングできます。また、EC2 のインスタンスごとに IOPS およびスループットの上限もございますのでご注意ください。

IOPS およびスループット追加は、実際に稼働した上で Amazon CloudWatch などで監視し、IOPS やスループットがボトルネックとなっている場合にご検討いただくことになると思います。

gp3 タイプの IOPS およびスループットの詳細についてはドキュメントもご覧ください。

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

スナップショットの料金に関わってくるパラメータには、以下のようなものがあります。

• スナップショットを取得する頻度
• 初期スナップショットの容量（=EBS の容量）
• 増分スナップショットあたりの増加容量

フルバックアップではなく増分バックアップですので、前回のスナップショットからの変更分のみ新たに保存されます。

RDS の見積もり

RDSでは以下の要素に応じて料金が発生します。

利用するノード数
利用するノード数には、マルチ AZ 構成、リードレプリカ構成(数)なども含みます。

構築するインスタンスタイプ
RDS のインスタンスタイプは、EC2 と同様に主に「汎用」、「メモリ最適化」、「コンピューティング最適化」、その他があり、RDS で実行するワークロードの特性により選択することになります。

既存システムから現状ワークロード指標を検討する場合、現状のワークロードを分析し、必要リソースを確認し初期見積もり値を決定します。繁忙期が存在する場合、繁忙期のワークロード量もさらに分析を行い加味することが必要です。パフォーマンス分析レポートを定期的に取得している場合は、そのレポートを基に分析を行うことも可能です。
新規システムとして検討する場合で、類似のシステム (利用者数や業務数・機能要件の観点に基づき) がある場合は、該当システムのリソース状況から選定し初期見積もりを行います。類似のシステムが無い場合、小規模・中規模想定のシステムとしてインスタンスタイプを見積もり、その後、パフォーマンステスト実施後に再度、ワークロードを分析し、改めて見積もりを行います。

初期見積もりが終わった後、早期に見積もりの妥当性を確認するための PoC を実施します。その結果を踏まえ、改めて必要なインスタンスタイプの見積もりを行います。

詳細については、以下のページもご覧ください。

• Amazon RDS インスタンスタイプ | AWS
• DB インスタンスクラス – Amazon Relational Database Service

RDS プロキシ利用有無
RDS プロキシは、基となるインスタンスの容量に基づいて料金が設定されています。サーバーレスアプリケーション (例: Amazon Lambda など) を開発している場合、データベース接続をプールおよび共有することでセッション接続・切断が効率的に行えます。

詳細については、以下のページもご参照ください。

• Amazon RDS Proxy | 高可用性データベースプロキシ | Amazon ウェブサービス

商用ライセンス利用の有無
RDS で商用データベースを利用する際は、ライセンス費用も発生します。ライセンスの支払い体系としては、ライセンス持ち込み (BYOL) とライセンスインクルード (LI) があります。

データベースストレージボリュームサイズ
RDS で利用できるストレージのタイプは、汎用 SSD (gp2,gp3) 、プロビジョンド IOPS SSD があります(マグネティックは、下位互換用となります)。プロビジョンド IOPS SSD は、汎用 SSD よりも高速ですが、費用も高額になります。

データベースストレージのボリュームは、実際のレコード件数に基づくサイズではなく、プロビジョニングされているストレージのサイズにより料金が決定されます。オンプレミスのデータベースでは、初期導入時に想定キャパシティーサイズのストレージを購入・設置することが一般的ですが、AWS クラウドサービスでは、ストレージの増加が容易 (RDS ストレージの自動スケーリング) なため、必要な際に必要な分だけストレージを追加でき、初期費用も抑えることができます。

詳細については、以下のページもご参照ください。

• Amazon RDS DB インスタンスストレージ – Amazon Relational Database ServiceAmazon R…
• Amazon RDS DB インスタンスのストレージを使用する – Amazon Relational Database Service

モニタリングとしての Performance Insights 利用有無と保存期間
データベースのモニタリング方法としては、Amazon CloudWatch メトリクスや、Enhanced Monitoring があります。

さらに、データベースアクティビティのモニタリング方法として Performance Insights が挙げられます。データベース内のパフォーマンスデータを蓄積してボトルネックを特定するのに役立ちます。直近で 7 日間のパフォーマンス履歴は、無料で保存できますが、それ以前のデータベースアクティビティを確認したい場合、料金が発生します。アプリケーションの実行サイクルを加味して、日・週・月・半期・年度の単位でデータベースアクティビティを分析する必要があるかをあらかじめ想定する必要があります。

詳細については、以下のページもご参照ください。

• Amazon RDS の Amazon CloudWatch メトリクス – Amazon Relational Database Serv…
• 拡張モニタリングを使用した OS メトリクスのモニタリング – Amazon Relational Database Service
• Performance Insights（RDSのパフォーマンスを分析、チューニング）| AWS
• 料金 – Performance Insights | AWS

バックアップストレージサイズ
自動バックアップが保持される日数として 1 日～ 35 日が選択できます。保存期間によりバックアップ料金が異なります。

CloudWatch を利用したRDSの監視・ログ出力
CloudWatch を利用し RDS の CPUUtilization、FreeableMemory などの監視や通知設定が可能となります。また、各ログの収集も可能となります。メトリックの数やダッシュボード利用数、アラーム設定数、ログサイズ等により CloudWatch の料金は異なります。

詳細は、料金 – Amazon CloudWatch | AWS　をご確認ください。

最後に
合わせて、以下の公式サイト情報もご確認ください。

• 料金 – Amazon RDS | AWS
• 料金 – Amazon Aurora | AWS
• Amazon RDS の月額費用を計算する方法を教えてください。
• Amazon RDS のコスト見積もり

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

ガバメントクラウドの AWS アカウントでは、庁舎と AWS 環境を閉域で接続するために、AWS Direct Connect や AWS Transit Gateway などのサービスを活用します。ガバメントクラウドでよくある構成 3 パターンについて 2024 年 4 月時点での料金をまとめましたので、近いパターンをご参照ください。地方公共団体からガバメントクラウドへの接続パターンや、ネットワークアカウントとそれを管理するネットワーク構築運用補助者のタスクの詳細については、ガバメントクラウドの道案内『ネットワーク構築運用補助者編』のブログをご覧ください。また、現在の価格や詳しい情報については、それぞれのサービスの料金ページをご覧ください。

利用する AWS アカウントの整理

以下で説明するそれぞれのパターンについて、以下の 2 つのアカウントが出現します。

• ネットワークアカウント：自治体庁舎からの専用線接続を集約するために存在するアカウントです。AWS Direct Connect で庁舎と AWS 環境を接続し、AWS Transit Gateway をハブとして、アプリケーションアカウント内の VPC との通信を実現しています。AWS Direct Connect や AWS Transit Gateway はこのネットワークアカウントに集約し、ネットワーク構築運用補助者が運用管理を行います。
• アプリケーションアカウント：アプリケーションが動作しているコンピューティングリソースが存在するアカウントです。異なるベンダーの管理するアプリケーションアカウントが複数存在する場合が一般的です。

VPN や AWS PrivateLink なしの構成

ネットワークアカウントでは以下の課金が発生します。

• AWSと外部: 帯域に応じた Direct Connect のポート料金 （契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます）
• AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB
• AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間

それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。

• AWSと外部: VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB
• AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間
• AWS内: Transit Gateway アタッチメント から Transit Gateway に送信されたデータ量に対して 0.02USD/GB

AWS PrivateLink を利用した構成

共同利用方式 (アプリケーション分離) などで自治体庁舎の IP アドレス範囲とアプリケーションが存在する IP アドレス範囲が重複してしまう場合、通信するために AWS PrivateLink というサービスを用いることがあります。

ネットワークアカウントでは以下の課金が発生します。

• AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます)
• AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB
• AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間
• AWS内: AWS PrivateLink を設置してアプリケーション VPC 通信を中継させる VPC について、VPC から Direct Connect を経由して自治体庁舎方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB
• AWS内: AWS PrivateLink のインターフェイスエンドポイントについて、時間単位で 0.014USD/時間、データ処理料金として 0.01USD/GB

それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。 (AWS PrivateLink 経由で通信するアカウントの場合)

• AWS内: ネットワークロードバランサー (NLB) の料金。詳しくは料金ページをご覧ください。

VPN を利用した構成

情報ハイウェイや地域データセンターなどで複数の自治体庁舎からの通信を集約する場合、 Site-to-Site VPN などを利用してネットワークスライシング (物理ネットワークを仮想的に分割すること) を行うことがあります。この場合ネットワークアカウントは複数の団体で共用になりますが、今回は 1 つ目の団体 (団体 A) が負担する料金についてまとめました。

※一般的に Site-to-Site VPN はインターネット経由で用いるため、Direct Connect が必ずしも必要ではない点にご注意ください。今回 Direct Connect 経由で Site-to-Site VPN を利用しているのは、現行の自治体システムでは基本的に閉域を採用しているためです。

ネットワークアカウントでは以下の課金が発生します。

• AWSと外部: 帯域に応じた Direct Connect のポート料金 (契約形態によって、LGWAN やガバメントクラウド接続サービスなどの料金に含まれます)
• AWSと外部: Site-to-Site VPN の料金 0.048USD/時間
• AWSと外部: Site-to-Site VPN を経由して AWS 外部に送信されたデータ量に対して 0.114USD/GB
• AWS内: Direct Connect から Transit Gateway に送信されたデータ量に対して 0.02USD/GB
• AWS内: Transit Gateway の AWS Direct Connect ゲートウェイアタッチメントに対して、 0.07USD/時間
• AWS内: Transit Gateway の Private IP VPN アタッチメントに対して 0.07USD/時間

それぞれのアプリケーションが存在するアカウントでは以下の課金が発生します。

• AWSと外部: VPC から Direct Connect を経由して Direct Connect ロケーション方向に流れる (アウトバウンドの) 通信に対して 0.041USD/GB
• AWS内: 通信したい VPC 内の各 AZ に対して 1 個ずつ設置する必要がある Transit Gateway アタッチメントに対して、 0.07USD/時間
• AWS内: Transit Gateway アタッチメントから Transit Gateway に送信されたデータ量に対して 0.02USD/GB

ここにあげた AWS の費用以外にも自治体庁舎側の回線費用などが発生する場合があります。

また、Direct Connect の通信経路は要件によって冗長化する必要が生じます。この場合、Direct Connect のコストが大きくなりますので、合わせてご確認ください。Direct Connect の冗長化については、AWS Black Belt Online Seminar AWS Direct Connect の資料をご覧ください。

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

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

AWS CloudTrail
AWS を操作した際の証跡ログを半永久的に保存可能です。 データ処理やデータ保持に料金がかかります。詳細な料金体系については料金ページをご覧ください。

AWS Config
AWS リソースの構成変更記録、構成変更を管理します。リソースの設定や関係に変更があった際に配信される設定項目の数や、AWS Config ルールなど、評価の数に対して料金がかかります。詳細な料金体系については料金ページをご覧ください。

Amazon GuardDuty
脅威の検知と継続的監視を行います。分析した CloudTrail イベント件数やログのデータ量などに対して料金がかかります。詳細な料金体系については料金ページをご覧ください。

AWS Security Hub
組織内のさまざまなセキュリティデータを集約して、一元的に可視化したり優先順位づけします。実行されたセキュリティチェックの件数や他サービスからの検出結果の取り込み件数などに対して料金がかかります。詳細な料金体系については料金ページをご覧ください。

AWS Trusted Advisor
お客様が AWS のベストプラクティスに準拠するための推奨事項を提供します。こちらはガバメントクラウドで加入しているサポートプラン (後述) に含まれております。

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

地方公共団体情報システム非機能要件の標準では、大規模災害が発生した際の標準的な復旧目標時間は「 1 か月以内に再開」とされています。これを満たしコストを抑えられる災害対策の手法として、セカンダリリージョン (東京リージョンを常時稼働させるリージョン (プライマリリージョン) とする場合は大阪リージョン) にバックアップを保持しておき、災害時はプライマリリージョンが復旧してから、データをセカンダリリージョンのバックアップから復元し、システムの稼働を再開するという手法が考えられます。
バックアップ戦略も含め、AWS でのディザスタリカバリ (DR) アーキテクチャとクラウドでのリカバリ戦略については、こちらのブログをご覧ください。どのようなDR戦略を取るかによって費用は変わってきますが、以下では一例としてバックアップ＆リストア方式を採用する場合の費用の計算方法について記載します。

バックアップ & リストア方式を採用する場合

自治体でよく用いられるバックアップ&リストア方式について、主にかかる費用としては以下のようになります。
東京リージョンにおいて追加でかかる費用

• EC2 と EBS のバックアップストレージ料金：大阪リージョンにコピーする EC2 と EBS のスナップショット (AMI) を取得しますが、それを保存する容量に対して料金がかかります。 0.05USD/ 月GB です。
• データベースのバックアップストレージ料金：大阪リージョンにコピーするデータベースのスナップショットを取得しますが、それを保存する容量に対して料金がかかります。ただし、料金がかからない場合もあります。例えば Amazon RDS for MySQL の場合は、データベースストレージの容量と同じ分だけ無料でバックアップに利用できます。
• 東京リージョンから大阪リージョンへのデータ転送料 USD 0.09/ GB がかかります。

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

• EC2 と EBS のバックアップストレージ料金：東京リージョンからコピーしてきたスナップショットを保存する容量に対して USD 0.05/ 月GB の料金がかかります。
• データベースのバックアップストレージ料金：東京リージョンからコピーしてきたデータベースのスナップショットを保存する容量に対して料金がかかります。例えば、Amazon RDS for MySQL の場合は USD 0.095/ 月GiB です。

料金試算例については、こちらの資料もご覧ください。
東京と大阪リージョンを活用して、バックアップ＆リストア戦略で災害対策 ( DR ) を実現する

AWS Pricing Calculator への入力

AWS Pricing Calculator で見積もりを作成する際の入力方法のヒントをご紹介します。

以下のヒントは、すべての項目について列挙しているわけではなく、迷うことが多いポイントについて整理したものですので、ご注意ください。

こちらの構成をもとに入力のヒントを作成しております。

EC2 関連費用の入力

• リージョンを選択します。
• テナンシー：通常、「共有インスタンス」を選択します。
• ワークロード：通常、「一定の使用量」を選択します。
• インスタンスタイプ：このブログの「コンピューティング費用の見積もり」の章を参考にして決定したインスタンスタイプを選択します。表示される表は、デフォルトではオンデマンド利用料が低い順に並んでいます。
• お支払いオプション：「使用状況」は常に起動させるサーバーでは 「 100 Utilization percent per month」 を選択します。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。
• 「Amazon Elastic Block Store (EBS) – オプション」の章では、Amazon EBSの章を読んでいただき、 EBS の詳細についてご記入ください。以下の説明は gp3 インスタンスを選択された場合のものです。
  • IOPS は、3,000 IOPS までは無料、それ以上は追加料金がかかります。
  • スループットは、125 MiB/ 秒までは無料、それ以上は追加料金がかかります。
  • スナップショット頻度を選択すると、スナップショットあたりの増分を入力できます。これは一般的には EBS 自体の容量よりも小さい値です。

RDS 関連費用の入力

• リージョンを選択します。
• ガバメントクラウドでは通常、「使用状況」は常に起動させるデータベースでは「 100 %Utilized/Month」を選択します。
• デプロイオプションは可用性などの要件に合わせてご選択ください。ガバメントクラウドで認められる購入オプションについては、デジタル庁にご確認ください。
• RDS プロキシを利用する必要があるかどうかは、こちらのページをご覧ください。
• インスタンスタイプやストレージ量は、このブログの「コンピューティング費用の見積もり」の章を参考にして決定したものを選択します。
• バックアップストレージは、保持したいバックアップの容量を入力してください。ただし、インスタンスのストレージ量と同じ容量が無料で提供されるので、追加分を入力してください。

ネットワーク費用の入力

AWS Transit Gateway の費用は、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。

• リージョンを選択します。
• Transit Gateway のアタッチメント数は、 Direct Connect や VPC、VPN など Transit Gateway と接続するものすべての個数です。例えば冒頭の図の構成の場合 2 個になります。
• 「Transit Gateway のアタッチメントごとに処理されたデータ」は、アタッチメントごとに Transit Gateway に送信するデータ量の推定値を入力してください。

AWS PrivateLink をご利用になる場合の費用も、Amazon Virtual Private Cloud (VPC) のサービスを選択した画面から入力できます。

AWS Direct Connect のポート料金や、AWS Direct Connect 経由で AWS の外に出る通信量にかかる費用については、AWS Direct Connect のサービスを選択した画面から入力してください。

• リージョンを選択します。
• 「サービスの設定」に関わるポート数などの値は、ネットワーク構築運用補助者にご質問ください。
• 「データ転送 (送信)」に、AWS Direct Connect 経由で AWS の外に出る通信量をご入力ください。

ガバナンス・セキュリティ費用の入力

高額になりやすい費用として、Amazon CloudWatch の費用がございますので、そちらについて目安をご紹介いたします。
EC2 インスタンスが EC2 詳細モニタリングで 12 個の追加メトリクスを公開する場合、そのインスタンスでは最高価格階層で月額最大 3.60 USD、最低価格階層で月額最大 0.24 USD の料金が発生します。詳しくは、こちらをご覧ください。

バックアップ費用の入力

東京リージョンから大阪リージョンへのデータ転送量については、「AWS Data Transfer」のメニューのうち送信データ転送から、「その他すべてのリージョン」を選択し、量を入力ください。

コスト削減のヒント

一般的には以下のような方法で、コストを削減できます。ぜひ参考にしていただいて、ガバメントクラウドの費用削減にお役立てください。

ダウンサイジング

インスタンスタイプを小さいサイズに変更すると、大きな費用削減効果が得られます。大きいインスタンスサイズが適用されている場合は、現行のシステムの CPU 使用率やメモリ使用率などを鑑みて、より小さいインスタンスサイズが適用できないかをご検討いただくことをお勧めします。また、AWS ではアセスメントを支援する無償のプログラムがありますので、ぜひアカウント営業経由でお声掛けください。
見積もりからは離れますが、運用中に AWS Cost Explorer の「サイズの適正化に関する推奨事項」や Performance Insights で低使用率のインスタンスを確認し、インスタンスタイプを小さいサイズに変更できます。

リザーブドインスタンス等の割引オプションの利用

Amazon EC2 では、リザーブドインスタンスなどの割引オプションを適用することで、割引を得ることができます。現状、ガバメントクラウドでも、条件を満たせばリザーブドインスタンスなどの割引オプションを利用することができます。ガバメントクラウドにおける割引オプションの詳しい条件については、デジタル庁にご確認ください。

最新世代インスタンス利用 / コスト効率の良いCPUへ変更

冒頭でご説明したように、EC2 や RDS のインスタンスタイプに書かれている数字が大きいインスタンスの方が最新世代のインスタンスであり、コスト効率が高いです。言い換えると、同料金の場合でもスペックが向上するため、新しい世代を使えばインスタンスタイプを小さくできる可能性があります。
また、AWS Graviton プロセッサはクラウドワークロードに最高のコストパフォーマンスを提供するように設計されたプロセッサであり、移行することでコストパフォーマンスも向上する場合がございます。 AWS Graviton プロセッサへの移行の際に気をつける点についてはこちらのページをご覧ください。

最新世代ストレージタイプ利用

インスタンスの世代と同様に、ストレージの世代も最新のものを利用した方がコストパフォーマンスが高いです。具体的には、gp2 ではなく gp3 を利用した方が良いでしょう。

開発環境を不使用時は停止する運用への変更

以下の 3 つの方法で、 EC2 の停止と起動をスケジューリングできます。

• Amazon EventBridge スケジューラと AWS Lambda : シンプルな実装方法にしたい場合はこちらが選択できます。
• AWS Systems Manager Resource Scheduler : 既に　AWS Systems Manager (SSM) をご利用の場合は、こちらの方法を使うことで SSM での管理に統一できます。ただし、提供された機能を利用するため少しカスタマイズはしにくくなっています。
• AWS Instance Scheduler : 複数のサービスを利用したソリューションです。複数のアカウントのインスタンスを管理できます。

また、負荷に時間や季節による変化があるようなシステムの場合、負荷に合わせて EC2 の台数を増減させたりインスタンスサイズを変化させたりすることで、負荷が小さい期間のコストを抑えることができます。合わせてご確認ください。

低コストのストレージクラスの利用

オブジェクトストレージである Amazon S3 では、スタンダードクラスのみでなく、アクセス頻度が少ない場合に費用削減効果を発揮する S3 Standard-Infrequent Access クラスや、アーカイブ保存用の S3 Glacier Deep Archive などがあります。保存するオブジェクトへのアクセス頻度を元に、最適なストレージクラスを選択されることをお勧めします。

増分バックアップの考慮

見積もり上でリージョン間転送料が多い場合、フルバックアップの想定で計算されていることがあります。実際には AWS Backup の機能などを用いることによって、フルバックアップではなく増分バックアップにすることができ、データ転送量を抑えることができる場合があります。

まとめ

本ブログでは、ガバメントクラウド上のシステムに関する見積もりで注意すべき点についてお伝えしました。
費用の大部分を占めるであろうコンピューティング費用の見積もりを中心に、見積もりに役立てていただけると幸いです。

自治体に所属している方または関連するベンダーの方で、このブログに関してご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へご連絡ください。

免責事項

• 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。
• 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。
• 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。
• 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。
• 本ブログに記されている具体的な料金は 2024 年 4 月時点のものであり、今後変更される可能性がございます。現在の料金はそれぞれのサービスの料金ページをご参照ください。

ガバメントクラウドに関するお問い合わせ

AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。
本記事で紹介した見積もりに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。
https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/