「2.4 ランニングコストの最適化アプローチ」で整理した各アプローチの詳細を示す。
なお、既に構築・稼働しているシステムに対しては、各アプローチの実施前にCSPが提供するアセスメントサービスの活用を推奨する。

＜留意事項＞
優先度A・Bの項目については「アプローチを適用した場合のコスト削減効果例」としてアプローチを適用した場合のコスト削減効果例を併記するが、金額はあくまで試算であることに留意すること。

試算の前提は以下の通りである。

• 試算はサンプルであり、必ずしも記載する削減率が達成されるとは限らない。
• 試算は令和6年8月時点のAWSにおけるサービス仕様・利用料を例として提示、ガバメントクラウドの他CSPでも同じ考え方を適用可能である。
• コスト削減効果例については以下の前提で試算している。
  • 費用は年額
  • 為替は1ドル=150円
  • システム構成は以下の通り。

3.1 インスタンスサイズの選定

■ 概要
リソースの利用状況を踏まえ、より適切なインスタンスサイズに見直すことで、コスト削減を図ることができる。
クラウドではインスタンスサイズの引き上げが容易であるため、最初から安全マージン（バッファ）を含めた過剰なインスタンスで見積る必要はない。実際の使用量に合わせた必要最低限のCPUコア数を想定してインスタンスサイズを選定し、検証を通じて必要であればサイズを大きくする。

＜インスタンスサイズの見直しによるコスト削減効果イメージ＞

図3-1.アプローチ概要（インスタンス選定・サイズの変更）

■ アプローチの流れ

■ ポイント・注意点

• クラウドではインスタンスサイズを柔軟に変更可能（再起動を伴うのみ）である。
• 5年先の使用量予測やピーク時に合わせたサイジングは不要であり、通常時の使用量に基づきサイジングを行い、需要に応じてサイズを変更する。
• 通常時のインスタンスサイズを決定する際には、現行環境のCPU使用率等を確認し、実容量に基づいたサイジングを行う。
• インスタンスサイズ変更はクラウドサービスの機能で自動化するか、手動拡張する運用プロセスを事前に整備する。

■ アプローチを適用した場合のコスト削減効果例

*1 本例では1/2のサイズに変更した場合を想定している。

3.2 インスタンスタイプの選定

■ 概要
クラウドに移行する際は、CSPが提供する各種のインスタンスから適切なものを選択する必要がある。
コスト効率の高いインスタンスを選定することで、単位時間当たりのコストを低減することができる。

＜インスタンスタイプとユースケース＞
クラウドでは用途に応じてチューニングされたインスタンスが用意されている。システム特性に応じたインスタンスを選定することが重要である。

例えば、一時的に負荷が上がるシステムでは、バースト可能インスタンスを利用することで時間当たりの利用料を安価に抑えることができる。
また、機能面にフォーカスして利用される開発環境や検証環境、業務影響のない本番環境等、厳密に性能が求められないインスタンスでは、安価なバースト可能インスタンスの利用もコストを抑える有効な手段となり得る。ただし、安定した性能を提供しないバースト可能インスタンスを利用する際は、事前に十分な検証を行うこと。

＜世代の最新化＞
パブリッククラウドのインスタンスは、vCPUやメモリ容量が旧世代と同じであっても、最新世代の方が高性能、低価格になる傾向がある。
最新世代のインスタンスタイプを採用することでリソース利用料が安価になる他、インスタンスのサイズダウンが可能になるケースがあり、コスト削減を図ることが可能である。

• 継続してリソースの世代に係る最新情報を収集し、最適な世代について検討することが重要である。
• 設定内容やアプリケーション等との互換性、セキュリティパッチ情報等を事前に業務要件等に応じて確認することが重要である。

■ アプローチの流れ

3.3 稼働時間の調整

■ 概要
システム稼働時間を定義し、定義した稼働時間外はシステムの稼働を停止することで、コスト削減を図ることができる。

稼働時間の定義にあたっては、以下のようなシステムに関する要件・プロセスも含めて見直しの余地があるか検討する。

• 夜間の定期処理を業務時間内で実行
• 依存関係を確認し、定期処理を並列で実行

■ アプローチの流れ

検討の結果、停止運用ができず稼働時間が長くなる場合、損益分岐点を考慮し、長期継続割引（Savings Plans等）の適用を検討する。
ガバメントクラウドでは、長期継続割引購入にあたる利用条件（購入プランの制約等）があるため、詳細はGCASガイド（メンバー専用ページ）を参照すること。

図3-2.稼働時間と長期継続割引における損益分岐点
（東京リージョンを条件としたAWS EC2 Instance Savings Plansの割引率をもとに作成）

■ ポイント・注意点

• クラウドでは利用時間に対して料金が発生するため、リソースを停止することが利用料の削減に大きく影響する。
• システムが遊休状態（システムが必要な処理をしていない時間が多い状態）になっている場合は、システムの稼働時間を極力削減することでコスト削減を図る。
• 稼働時間の調整にあたっては事前にテストを実施する等、業務や連携先システムへの影響を与えないことを確認する。
• 稼働時間は運用フェーズにおいても定期的に見直しを行い、不要なリソースの停止、処理データの増加や業務時間の変更が発生した場合には、稼働時間を再検討する。
• クラウド側のキャパシティ不足によるエラーが発生しリソースを起動できない場合があるため、稼働時間の調整に当たっては、コスト削減効果と業務への影響とのバランスを慎重に見極める必要がある。開発環境や検証環境については、稼働時間の調整を検討しやすい領域である一方で、本番環境や運用環境については、利用頻度の低い踏み台サーバーや夜間バッチ処理用サーバー等、通常業務への影響が小さいものについて稼働時間の調整を検討する。
• クラウド側のキャパシティ不足によるエラーの発生頻度は限定的だが、業務上重要なサーバーについて起動停止する場合は、当該リスクを考慮して、以下のいずれか、または複数の対応を含むリソース起動の自動化の仕組みを検討する。なお、業務開始直前（日本時間7時00分から9時00分など）、月末月初、きりのよい時間（日本時間の9時00分など）等の需要の集中が想定される時間帯においては、起動リクエストを避けることも有用である。
• クラウドのキャパシティは頻繁に変動する場合があるため、数分待ってから、起動リクエストを再送信する（リトライ）。
• 一回で起動するインスタンス数を減らし、新しい起動リクエストを送信する。例えば、15 のインスタンスを起動する単一の起動リクエストを送信している場合は、5つずつ3回の起動リクエスト、または1つずつ15回の起動リクエストに分割する。
• 同一スペックのインスタンスの起動時に、複数回キャパシティ不足となる場合は、CPU（コア）数、メモリサイズを変更して新しい起動リクエストを送信する。
• 起動可能なゾーン（ドメイン）を複数指定し新しい起動リクエストを送信する。または、現在指定しているゾーンが1つである場合は、現在と異なるゾーンへインスタンスの起動リクエストを送信する。

■ アプローチを適用した場合のコスト削減効果例

3.4 ストレージ選定・容量の変更

■ 概要
最低限必要なデータ容量から利用を開始することで、不要なストレージ利用料を抑止し、コスト削減を図ることができる。
クラウドでは必要に応じてストレージ容量を拡張できるため、数年後を見据えた大きな容量を利用開始時点で確保しておく必要はない。最低限のストレージ容量に変更し、年次または隔年で容量を拡張していく。

図3-3.アプローチ概要（ストレージ選定・容量の変更）

■ アプローチの流れ

■ ポイント・注意点

• クラウドはストレージサイズの拡張が容易なため、数年先を見越した容量のサイジングは不要であり、実使用量に数%のバッファを持たせてサイジングする。
• 可用性はCSP側で担保するため、RAIDを考慮したストレージ構成（RAID分のストレージ容量等）やスペアディスクの考慮は不要である。
• ログや一時ファイルの保管場所となるストレージについては「3.9 不要なログの削減 」も参照すること。

■ アプローチを適用した場合のコスト削減効果例

*1 1TBのストレージ領域のうち50%を使用しており毎日10GBの更新があるストレージを毎日バックアップ（7世代保管）すると仮定し試算している。

3.5 運用のマネージドサービス化

■ 概要
バックアップや監視などの運用管理機能をマネージドサービスを用いて実現することで、バックアップサーバーや監視サーバー、運用管理系ソフトウェアが不要となり、コスト削減を図ることができる。

＜マネージドサービスで代替できる機能例＞

• バックアップ：CSPの標準機能を活用し、ストレージやシステムのバックアップを行うことで、サーバーの常時稼働が不要になりコストを削減できる。
• セキュリティ対策：システムの脆弱性を早期に発見し対策を講じることで、セキュリティインシデントを防止する。これにより、セキュリティ対策に必要な人材確保や研修、製品導入と運用、脆弱性調査等のコストを削減する。
• 監視：CSPが24時間365日の監視を提供する。これにより、内部のITチームが監視に費やす時間が削減され、他の重要な業務に集中できコストを削減する。
• ロギング：ログ管理ツール等を使用して、システムのログを自動的に収集し、分析する。これにより、システムのパフォーマンスの最適化、問題の迅速な特定、工数の低減等につながり、コストを削減する。

＜バックアップにおけるマネージドサービスの活用例＞
バックアップサーバーを用いたバックアップでは、サーバー構築に係る開発費や24時間365日サーバーを稼働させるための利用料金が発生する。
マネージドサービスを用いたバックアップに変更することで、マネージドサービスの設定のみで実現可能となり、バックアップ対象データ量等に応じて課金されるためコスト削減が可能となる。

■ アプローチの流れ

■ ポイント・注意点

• クラウドでは基本的な運用管理機能がマネージドサービスとして提供されており、サーバーを構築・運用する場合と比較してコスト減となる可能性が高い。
• マネージドサービスでの実現が難しい運用作業は、要件の見直しやマネージドサービスで実現可能な運用への変更を検討する。
• 独自の運用管理システム（バックアップ、ジョブ管理等）の構築は避け、可能な限りマネージドサービスへの置き替えを検討する。

■ アプローチを適用した場合のコスト削減効果例

3.6 DR構成の選定

■ 概要
クラウド利用時はIaC等の活用により環境構築が迅速に実現できるため、スタンバイ環境の削減が検討可能。オンプレミス環境と同様のDR構成を採用している場合、見直しにより費用削減が期待できる。

＜DR構成の種別例＞
システムが求める要件と許容可能なコストに応じてDR構成を検討する。
職員向けシステムや、一部領域や地域の国民向けサービスなど、停止することで即座に国民生活に影響のない「バックアップ」を検討することになると想定する。

DR構成の検討にあたっては[ ガバメントクラウド手続き概要 : GCASガイド（メンバー専用） > 全般的なガイド> 概要文書 > 02_ガバメントクラウド手続き概要]や地方公共団体向けの「ガバメントクラウド利用における推奨構成」も参照すること。

• ガバメントクラウド利用における推奨構成
  https://www.digital.go.jp/policies/local_governments#recommendationopen_in_newOpens in new tab

＜バックアップ構成のイメージ＞
DR構成のうち「バックアップ」について、AWS Backupのクロスリージョンバックアップを用いて以下データをS3バケットに格納する構成のイメージを示す。

• システムデータ：　AMI（OSイメージ）、プログラム、IaCコード等
• 業務データ：　RDSスナップショット、ファイル等

図3-4.バックアップ構成のイメージ

■ アプローチの流れ

■ ポイント・注意点

• DR構成の選定に当たっては、各ガバメントクラウド利用機関にて定める非機能要件を基に検討する。
• 災害対策関連要件の見直しを行い、災害時に必要となる業務継続性とそれに伴うコストを確認し、DR構成の検討・選定を行う。
• 本アプローチ及び試算では、本番環境と利用者拠点とのNW回線を考慮していないため、実際にDR構成を検討する場合にはNW回線の構成についても併せて検討を行う。

■ アプローチを適用した場合のコスト削減効果例

*1　毎日10GBのデータ更新がある場合、S3に対し月次500GBのフルバックアップ及び日次10GBの増分バックアップ（7世代保管）をすると仮定している。

3.7 ストレージクラス選定とライフサイクル管理

■ 概要
データのアクセス頻度・世代・保管期間に基づきデータ保管先として適切なストレージクラスを選定し、データのライフサイクルを管理することで不要なストレージ利用料を削減する。

＜ストレージクラスの特徴＞
適切なストレージクラスを選択し、過剰なスペックを備えないことが重要である。

＜ライフサイクル機能の利用イメージ＞
時間経過に伴いアクセス頻度が下がるデータはより安価なストレージへ自動移行し、保管期間が過ぎたデータは削除するようにライフサイクルを設定する。

図3-5.ライフサイクル機能の利用イメージ

■ アプローチの流れ

■ ポイント・注意点

• オブジェクトストレージ利用時は、アクセス頻度等に応じてバケット単位でデータ格納場所を分け、適切なストレージクラスを選定する。
• ライフサイクルの設定は、オブジェクトストレージの付随機能によってサードパーティー製品を導入せずに自動化可能である。
• データの種類、保存要件等を確認し、業務データ並びに運用管理上必要となるデータのライフサイクルを定め、適切な時期にデータを削除することでリソースを無駄に消費し続けることのないよう設計・構築する。

■ アプローチを適用した場合のコスト削減効果例

3.8 柔軟なリソース確保

■ 概要
負荷量に応じてリソースを柔軟に増減させ、余剰なリソースの発生を抑止することで、コスト削減を図ることが可能である。
オートスケーリング機能を使用すると、新しいインスタンスが自動的に作成され、既存のインスタンスが削除される可能性がある。これによりデータが損失することを防止するため、一部のサーバーに依存しない（各種リクエストの独立化等）構成が必要である。

• データはDBやオブジェクトストレージに保存することで、オートスケーリング時のデータ損失を防止する。
• セッション情報（ユーザーの状態等）は外部のストレージに保存する。ユーザーが複数のサーバー間で移動するときに、そのユーザーの状態を一貫して保持し可用性を向上させる。

＜オートスケーリング機能の利用イメージ＞

図3-6.オートスケーリング機能の利用イメージ

■ アプローチの流れ

■ ポイント・注意点

• インスタンスが負荷に応じて追加（スケールアウト）、削除（スケールイン）するため、アプリケーションが状態を保持しない（ステートレス）必要がある。 そのため、利用するアプリケーションがステートレスか確認し、セッション情報等が必要な場合には、外部に保持する改修が可能か検討する。
• アプリケーション負荷の最大と最小を確認し、インスタンスの最大値（サイズ、台数）と最小値を検討する。
• これまでの負荷状況を確認し、スケールアウト・スケールインするトリガーを決める。負荷の増減が不定期の場合は、CPU使用率やメモリ使用率をトリガーとし、定期的（例えば月末のみ等）の場合は、スケジューリングによるオートスケールも可能である。

■ アプローチを適用した場合のコスト削減効果例

3.9 不要なログの削減

■ 概要
必要なログ及びログの保存期間を再定義し、必要最低限のログをマネージドサービスに保存することで、コスト削減を図ることが可能である。
マネージドサービスは保存量に応じて課金されるため、サーバーには最低限のシステム運用に必要なデータのみを残し、保存の必要があるログの出力先は可能な限りマネージドサービスに移行する。

＜設計の見直し・マネージドサービスへの移行イメージ＞

ログや一時ファイル等、保管の必要がないデータは仮想サーバーに溜め込まず、削除・退避する設計を行う。

• 保管が必要なデータはブロックストレージでなくオブジェクトストレージに移動させることで、保管コストを抑えることができる。
• 不要な一時ファイルは定期的に削除する運用とし、格納データが単調増加することを前提とした過剰な見積りは行わない。

■ アプローチの流れ