クラウド利用料の予実管理と最適化(AWS編)
2023/03/06 公開
本書は、ガバメントクラウド利用におけるコストの予実管理及び、実績を踏まえたAWSが推奨するコスト最適化に関する運用を理解するための文書である。なお、予実管理については、一部PJMOが実施する作業も含む点に留意する事。
クラウド利用料の予実管理と最適化の全体像
クラウド利用料の予実管理と最適化では、クラウド利用料に対する予算の設定及び、実績の確認を行う「予実管理」と、運用状況を鑑みてコストを継続的に改善する「コストの最適化」について説明する。「予実管理」では、デジタル庁が連携する予算額をもとにAWS Budgets上に予算を設定、月次で実績を確認することで各利用システムにおける予実管理を実現する。「コストの最適化」では、ガバメントクラウドがモダンアーキテクチャに向けた想定構成として定義しているR1、R2で利用が想定される代表的なAWSサービスに対し、コストを最適化する基準と必要となる対策を定義し、コストの最適化を実現する。
ガバメントクラウドにおける予実管理
ガバメントクラウドが推奨する各利用システムで行うべき予実管理について、基本方針及び具体的な予実管理方法について説明する。
予実管理の基本方針
デジタル庁より各府省PJMO(各府省PMO経由)に連携された予算額(USD)を、事業者と連携し当該年度予算としてAWS Budgetsに設定する。
各府省PJMOは、月次でAWS Budgetsによりクラウド利用料実績を確認し、その予実管理を行い、その実績値については、各府省PMOに対し連携を行う。
なお、デジタル庁から連携された予算額については、利用時期の遅延等により不用となる額がある場合には、一括計上予算における執行管理の観点から将来的な執行見込みを勘案し適宜のタイミングで予算の引き上げを行う。
予実管理方法
予算の設定
デジタル庁より各府省PJMOに連携された予算額(USD)を事業者に連携し、事業者は必須適用テンプレートに予算設定を行う。
必須適用テンプレートの設定に関する詳細は、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。
予算設定は、月単位での設定を必須とし、その他四半期単位、年単位等での設定は任意とする。
デジタル庁より連携される予算額は、年度予算となるため、当該年度における利用月数で除算することで月次予算とする。
(例.7月にアカウントが払い出された場合、翌年3月までのシステム利用期間が9か月となるため予算を9で割った値を月次の予算とする)
予算を設定する際の留意点として、利用システム内に複数のAWSアカウントを持つ場合、アカウント別に予算の設定が必要となるため、各利用システムの判断でクラウド利用料割合を検討し、各AWSアカウント上で検討した割合に基づいた予算設定を行う。
予算の設定と合わせて、予算を実績が超過したことや年額予算を予測実績が超過することなどを検知するアラートの設定を推奨する。なお、閾値については、利用システム側の判断とする。
アラートの設定に関する詳細は、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。
実績の確認
各府省PJMOは、AWS Budgetsのコンソール画面を月次で以下手順を参考に、予算に対する実績の確認を行う。
1.AWSマネジメントコンソールへログインし、画面上部の検索より「AWS Budgets」と入力。検索結果に表示される「AWS Budgets」を押下。
図01:実績の確認手順1
2.表示された予算一覧の「名前」列にある「予算の設定」で定義した予算のリンクを押下。
図02:実績の確認手順2
3.表示された予算の詳細の画面下部にある、月次コスト履歴の「実際」に記載されている実績を確認する。
図03:実績の確認手順3
クラウド利用に伴う実績の確定は翌月3~7日が一般的であるため、確認対象月の実績は翌月の7日以降に確認することを推奨する。
得られた実績値を府省内のルールに従い各府省PMOに連携する。
実績が予算と比較して超過している場合には、後述しているコスト管理運用に従い、対応することで年間を通じて予算額の範囲内に収まるよう調整する。
ガバメントクラウドにおけるコスト管理運用
ガバメントクラウドが推奨する定常的に実施すべきコスト管理運用について、基本方針及び具体的なコスト管理運用のフローについて説明する。
コスト管理運用の基本方針
「定常的なコスト管理運用フロー」に従い、月次でコストを最適化するためのサイクルを実施する。
また、本運用はコストの最適化として、変化する運用状況を鑑みたコストの継続的な改善を目的としているため、設定した予算よりコスト実績が下回っているかに関わらず、月次での実施を推奨する。
管理工数削減・リアルタイム性の観点より運用報告などの形式で資料を別途作成することは極力せず、分析含めダッシュボード化することを推奨する。
アカウント利用状況などにより、コスト配分タグ機能を用いて、コストの確認や分析を行うことが可能である。コスト配分タグ詳細については、後述の「可視化」を参照。
定常的なコスト管理運用フロー
ガバメントクラウドが推奨する定常的なコスト管理運用フローとして、月次で「可視化」「分析」「コストの最適化」の順に実施する。
月次の基本フローとしては、コストの分析により選定したサービスに対して表中のコストの最適化基準の確認及び対策を実施するが、半期に一度、利用システムで利用する全てサービスに対してコストの最適化基準の確認及び対策の実施を推奨する。
なお、予算アラートにより費用実績の予算超過を検知した場合等については、利用システム側でアラートを踏まえてコストの最適化を実施する必要性を判断の上、任意のタイミングでコストの最適化を実施する。 詳細については、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。
図04:コスト管理運用フロー
コスト管理運用フローの詳細については以下のとおりである。
可視化
AWS Cost Explorerのコンソールで、グラフの「グループ化の条件」を「サービス(デフォルト)」とし、表示期間を月別における6か月前から分析時点とすることで、サービス別のコスト推移や費用実績におけるサービス別割合を可視化する。AWS Cost Explorerの詳細は以下を参照。
[AWSドキュメント:AWS Cost Explorer を用いてコストを分析する]
https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/ce-what-is.htmlOpens in new tab
リソースを利用シーンに合わせて分類しコストの確認や分析を行いたい場合、表のコスト配分タグが利用可能であるため、必要に応じて活用する。なお、表に記載されていないコスト配分タグを新規で追加したい場合はデジタル庁に申し出ること。ガバメントクラウド管理側で広く有用と判断した場合のみ追加を実施する。ただし、コストカテゴリは利用不可であるため、GCASダッシュボード(今後実装予定)を参照すること。
表:01 ガバメントクラウドで利用可能なコスト配分タグ
| タグのキー名 | 利用シーン | 説明 |
|---|---|---|
| Name | 基本的に全てのリソースに付加する | 付加対象リソースの名称と同じ内容を設定コスト配分タグで対象リソース単独の料金を確認可能 |
| SystemName | 同一アカウント内に複数システムが共存する場合 | 付加対象リソース群によって構成されるシステムの名前を設定コスト配分タグで対象システムにかかる料金を確認可能 |
| Environment | 同一アカウント内に複数環境(本番・ステージング・開発等)が共存する場合 | 付加対象リソースによって構成される環境(本番・ステージング・開発等)を設定コスト配分タグで対象環境にかかる料金を確認可能 |
| Owner | 同一アカウントを複数部門や事業者で共用する場合 | 付加対象リソースを管理している部門を識別する値を設定コスト配分タグで部門/事業者ごとにかかる料金を確認可能 |
| CostGroup1 CostGroup2 CostGroup3 | 上記以外の任意のグルーピングでコストを集計したい場合 | コスト配分タグで任意のグルーピングで料金を確認可能 |
| CostTag | 共同利用方式での費用按分計算をする場合 | 付加対象リソースを共同利用する団体(自治体)を識別する値をコスト配分タグで設定することで、団体(自治体)ごとにかかる料金を確認可能 |
分析
AWS Cost Explorerにより可視化するコスト状況について以下の1~3の観点で分析し、優先的に対策を実施するサービスを選定する。
分析の際は、コンソール内におけるデータセットのCSVファイルを活用することを推奨する。
なお、注意点として、AWS Cost Explorerにおいて、月末の分析時点でサービス単位の費用確認をする場合、サービス別費用が実際に当月発生する費用より下振れする可能性がある。そのため、利用システム側の運用に合わせて、必要に応じて分析は翌月の月初に行う。
また、 コストの分析としては、AWS Cost and Usage ReportsをAmazon QuickSightで分析を行う方法もあり、分析ダッシュボードを流用することで分析の効率化を見込めるため、必要に応じて利用を検討する。詳細は以下を参照。
[AWS
https://aws.amazon.com/jp/premiumsupport/knowledge-center/quicksight-cost-usage-report/Opens in new tab
なお、コストの分析はUSDで行い、為替変動は考慮しないものとする。
- 費用分析
当月における費用実績のサービス別割合を確認し、上位3位のAWSサービスの特定。 - 異常値分析
サービス単位に、直近3か月平均と当月の費用を比較し、平均月より10%以上費用が超過しているAWSサービスの特定。
なお、選定するAWSサービスは費用への影響度を鑑みて判断する。
また、サービス別コストの異常値を即座に検知したい場合は、AWS Cost Anomaly Detectionの利用を推奨する。 - 傾向分析
6か月前のコストと比較して、30%以上増加しているAWSサービスの特定。(毎月5%程度漸増している場合を想定。)
なお、選定するAWSサービスは費用への影響度を鑑みて判断する。
表の確認箇所及びコスト最適化の基準を確認し、該当する基準を選定する。
確認箇所に記載されている「サービスコンソール」は、サービス名に記載されたサービスのコンソールを対象としている。
コストの最適化
分析のフェーズで対象となったAWSサービスのコスト最適化の基準について、表のコストの最適化の対応に従い、コストの最適化を実施する。
表では、運用フェーズの対策を記載している。また、運用開始前の利用システムについては、開発フェーズから対応可能な項目について「開発フェーズ対象」列を参照する。
なお、表に記載するAWSサービスはR1、R2で利用を想定する代表的なサービスを対象としており、コスト最適化観点についても主要な観点を記載している。そのため、今後追加されるコスト最適化観点や記載外のAWSサービスについては、AWSが公開するベストプラクティスを参照の上、コストの最適化を実施する。
コストの最適化における効果測定は、次月の可視化フェーズで実施する。
表:02 コストの最適化の対応
| # | サービス種別 | サービス名 | 確認箇所 | コスト最適化の基準 | コスト最適化の対応 | 効果 | 開発フェーズ対象 |
|---|---|---|---|---|---|---|---|
| 1 | CDN | CloudFront | - | データ圧縮せず転送している | GZIP圧縮でデータ転送量を減らす | △ | - |
| 2 | CDN | CloudFront | サービスコンソール | 12 か月間以上、1 か月あたり最小 10 TB のデータ転送量を確実に利用する | カスタム料金設定の適用を検討する | △ | - |
| 3 | CDN | CloudFront | サービスコンソール | 利用量が予測可能、かつCloudFront Security Saving Bundleを使用していない | AWS WAFを適用している場合はCloudFront Saving Bundleの適用を検討する | △ | - |
| 4 | GW | APIGW | サービスコンソール | インターネット向けシステムで、かつREST APIほど高機能を必要としない | インターネット向けシステムの場合、RESTから機能は少ないが安価なHTTP APIへの変更を検討 | △ | - |
| 5 | GW | AppSync | サービスコンソール | メモリおよびネットワークパフォーマンスの要件に従ってキャッシュインスタンスを選択していない | GraphQLのキャッシュインスタンスの最適化 | △ | - |
| 6 | Web/AP/APIサーバ | EC2 | CloudWatchコンソール、サービスコンソール | インスタンスのメモリ使用率が月平均30%以下、インスタンスのCPU使用率が月平均30%以下、最新世代のインスタンスを使用していない、ワークロードが最適化されたインスタンスを使用していない | Compute Optimizer 等を利用し、EC2のインスタンスタイプ(最新のもの、適切な処理能力)と台数の見直し | ◎ | - |
| 7 | Web/AP/APIサーバ | EC2 | TrustedAdvisor、CloudWatchコンソール | インスタンスがアイドル状態である、ロードバランサーがアイドル状態である、接続していないElasticIPがある、接続していないロードバランサーがある、接続していないEBSがある、ニーズに準拠せず使用しているリソースがある、検証環境のインスタンスを24時間365日稼働させている | インスタンスの実行時間の見直し(停止運用、EC2インスタンススケジューラ活用) | ◎ | ● |
| 8 | Web/AP/APIサーバ | EC2 | AutoScalingコンソール | 稼働インスタンス数の自動調整をしていない | オートスケールの採用 | ◎ | ● |
| 9 | Web/AP/APIサーバ | EC2 | サービスコンソール | 利用量が予測可能、に関わらず購入オプションを使用していない | Savings Planの適用 | ◎ | - |
| 10 | Web/AP/APIサーバ | EC2 | TrustedAdvisor、CloudWatchコンソール | EBSのディスク使用量が分析時点で30%以下 | EBSのボリュームサイズ、I/O見直し | ◎ | - |
| 11 | Web/AP/APIサーバ | ECS/Fargate | CloudWatchコンソール | ECSのCPU使用率が月平均30%以下 | ECSのVCPU等処理能力の見直し | ◎ | - |
| 12 | Web/AP/APIサーバ | ECS/Fargate | サービスコンソール、CloudWatchコンソール | コンテナイメージの軽量化を行っていない | コンテナイメージの軽量化(イメージが大きいとイメージがプルされるのを待っている間、コンピューティングリソースを浪費する) | ○ | ● |
| 13 | Web/AP/APIサーバ | ECS/Fargate | サービスコンソール | 業務特性やピーク特性を考慮したコンテナの分割をしていない | 最適な単位でコンテナを分割する(業務特性、ピーク特性など) | ◎ | ● |
| 14 | Web/AP/APIサーバ | ECS/Fargate | - | 分散アプリケーション内で実行時間の長いプログラム(及びX-Ray でパフォーマンス分析を行っていない) | X-Ray でパフォーマンス分析を行うことで、不要に時間を要している(同期でマイクロサービスを呼び出す場合、インライン上に不要に時間を要しているサービスがある場合は、呼び出し元も実行時間を要するため)コンポーネントを特定し是正する | ◎ | - |
| 15 | Web/AP/APIサーバ | ECS/Fargate | - | 実行時間の長いプログラム(及びAmazon CodeGuruの対象言語の場合でコード分析を行っていない) | コンテナ上で稼働するAPについて、Amazon CodeGuruの対象言語の場合にプロファイラで実行にコストを要しているプログラムコードを特定し、見直す | ◎ | ● |
| 16 | Web/AP/APIサーバ | ECS/Fargate | CloudWatchコンソール | コンテナ最低稼働数が業務特性を鑑みて過剰性能となっている | タスク内のコンテナ最低稼働数の見直し | ◎ | - |
| 17 | Web/AP/APIサーバ | ECS/Fargate | サービスコンソール | 利用量がある程度予測可能、にも関わらず購入オプションを使用していない、または中断可能(ミッションクリティカルでない)かつスポットで必要となるワークロード(FargateSpot) | 購入オプションの変更(SavingsPlan、FargateSpot) | ◎ | - |
| 18 | Web/AP/APIサーバ | EKS/Fargate | CloudWatchコンソール | EKSのCPU使用率が月平均30%以下 | EKSのVCPU等処理能力の見直し | ◎ | - |
| 19 | Web/AP/APIサーバ | EKS/Fargate | サービスコンソール、CloudWatchコンソール | コンテナイメージの軽量化を行っていない | コンテナイメージの軽量化(イメージが大きいとイメージがプルされるのを待っている間、コンピューティングリソースを浪費する) | ○ | ● |
| 20 | Web/AP/APIサーバ | EKS/Fargate | サービスコンソール | 業務特性やピーク特性を考慮したコンテナの分割をしていない | 最適な単位でコンテナを分割する(業務特性、ピーク特性など) | ◎ | ● |
| 21 | Web/AP/APIサーバ | EKS/Fargate | - | 分散アプリケーション内で実行時間の長いプログラム(及びX-Ray でパフォーマンス分析を行っていない) | X-Ray でパフォーマンス分析を行うことで、不要に時間を要している(同期でマイクロサービスを呼び出す場合、インライン上に不要に時間を要しているサービスがある場合は、呼び出し元も実行時間を要するため)コンポーネントを特定し是正する | ◎ | - |
| 22 | Web/AP/APIサーバ | EKS/Fargate | - | 実行時間の長いプログラム(及びAmazon CodeGuruでコード分析を行っていない) | コンテナ上で稼働するAPについて、Amazon CodeGuru プロファイラで実行にコストを要しているプログラムコードを特定し、見直す | ◎ | ● |
| 23 | Web/AP/APIサーバ | EKS/Fargate | サービスコンソール | コンテナ最低稼働数が業務特性を鑑みて過剰性能となっている | Pod内のコンテナ最低稼働数の見直し | ◎ | - |
| 24 | Web/AP/APIサーバ | EKS/Fargate | サービスコンソール | 利用量がある程度予測可能、にも関わらず購入オプションを使用していない | 購入オプションの変更(SavingsPlan) | ◎ | - |
| 25 | Web/AP/APIサーバ | Lambda | Compute Optimizer | Compute Optimizerでの推奨値と異なるメモリ設定等(メモリ設定と、実行時間はトレードオフになるため、実行時間×性能単価にてコストが確定するLambdaは高度な分析が必要) | Compute OptimizerやLambda Power Tuningを利用して不必要なメモリまたは不要な実行時間に至る推奨にしたがう | ◎ | - |
| 26 | Web/AP/APIサーバ | Lambda | - | 実行時間の長いプログラム(及びX-Ray でパフォーマンス分析を行っていない) | X-Ray でパフォーマンス分析を行うことで、不要に時間を要している(同期でマイクロサービスを呼び出す場合、インライン上に不要に時間を要しているLambdaがある場合は、呼び出し元も実行時間を要するため)コンポーネントを特定し是正する | ◎ | - |
| 27 | Web/AP/APIサーバ | Lambda | - | 実行時間の長いプログラム(及びAmazon CodeGuruでコード分析を行っていない) | Amazon CodeGuruの対象言語の場合にプロファイラで実行にコストを要しているプログラムコードを特定し、見直す | ◎ | ● |
| 28 | Web/AP/APIサーバ | Lambda | サービスコンソール | 関数実行時に不要なデータも含めて取得している | データ転送量の最小化(クエリのフィルタ条件を指定し、データの全量ではなく必要な分だけ取得することで、データ取得待ち /データ処理の実行時間の短縮、必要メモリの削減を図る) | ◎ | - |
| 29 | Web/AP/APIサーバ | Lambda | - | Lambda関数から別のLambda関数の呼び出しを多用している(及び非同期呼び出しを採用していない) | 非同期化により実行時間を短縮する(Lambda関数からLambda関数を呼び出す場合に、関数内のコードロジックからinvokeせずにDestinationConfigurationを設定し非同期で呼び出すように構成することで、 invoke実行の待ち時間をなくし、余分な実行時間の削減を図る) | ◎ | ● |
| 30 | Web/AP/APIサーバ | Lambda | - | Lambda関数から別のLambda関数の呼び出しを多用している(及びオーケストレータを採用していない) | StepFunctionsなど外部オーケストレータの採用(別関数の呼び出しワークフローやエラーハンドリング (リトライ、ロールバック)等invokeやリトライに要する待ち時間をなくし、実行時間の短縮を図る(オーケストレータをLambdaが行うと、待ち時間も課金されるが、その部分を外部オーケストレータにオフロードする)) | ○ | ● |
| 31 | Web/AP/APIサーバ | Lambda | - | LambdaにおいてAWS API呼び出しを多用している | ダイレクトでAWSのAPIを呼ぶ方式に変更(他の AWS サービスとの統合中に Lambda 関数がカスタム ロジックを実行していない場合、その必要がない可能性がある。 API Gateway、AWS AppSync、Step Functions、EventBridge、および Lambda の宛先は、多数のサービスと直接統合して、より多くの価値を提供し、運用上のオーバーヘッドを削減できる) | ◎ | ● |
| 32 | Web/AP/APIサーバ | Lambda | TrustedAdvisor | エラー率の高いLambda関数がある | TrustedAdvisorでエラー率の高いLambdaを見直す | ◎ | - |
| 33 | Web/AP/APIサーバ | Lambda | サービスコンソール | 性能が要求されない場合にもProvisioned Concurrencyを利用している | 性能が要求されない場合の、Provisioned Concurrency(プロビジョンに課金される)を見直しする | ◎ | - |
| 34 | コンテナレジストリ | ECR | サービスコンソール | ECRのライフサイクルポリシーを使用していない | ECRのライフサイクルポリシーによる不要なコンテナイメージの削除 | ○ | - |
| 35 | コンテナレジストリ | ECR | サービスコンソール、CloudWatchコンソール | コンテナイメージの軽量化を行っていない | コンテナイメージの軽量化 | ○ | ● |
| 36 | キャッシュサーバ | ElastiCache | CloudWatchコンソール | ElastiCatheのCPU使用率が月平均30%以下 | インスタンスタイプ、サイズの最適化 | ○ | - |
| 37 | DBサーバ | Aurora | サービスコンソール | リードレプリカ(インスタンス)の自動調整をしていない | Auroraオートスケーリング(台数の最適化) | ◎ | - |
| 38 | DBサーバ | Aurora | サービスコンソール | 業務特性を鑑みてAuroraサーバレスの検討をしていない | Auroraサーバレスの採用(稼働が少ないノードなど) | ◎ | - |
| 39 | DBサーバ | Aurora | CloudWatchコンソール | インスタンスのメモリ使用率が月平均30%以下、インスタンスのCPU使用率が月平均30%以下 | インスタンスタイプの最適化 | ◎ | - |
| 40 | DBサーバ | Aurora | CloudWatchコンソール | ディスク使用量が分析時点で30%以下 | ストレージI/O、ボリュームサイズの見直し | ◎ | - |
| 41 | DBサーバ | Aurora | - | データ処理をキャッシュ層にオフロード可能な処理 | ElastiCache適用による負荷分散 | ○ | ● |
| 42 | DBサーバ | Aurora | - | データ処理をキューにオフロード可能な処理 | SQS/Amazon MQ適用による負荷分散 | ○ | ● |
| 43 | DBサーバ | Aurora | - | 可用性や性能が高度に要求されない | RDS PostgreSQL/MySQLへの乗せ換え(性能が要求されない場合など) | ◎ | - |
| 44 | DBサーバ | Auroraサーバレス | - | - | 特になし(V2かV1かは利用特性により適正なものにする、必要に応じてProvisionedへ) | △ | - |
| 45 | DBサーバ | RDS | TrustedAdvisor | RDSがアイドル状態である | 不必要なインスタンスの停止運用 | ◎ | ● |
| 46 | DBサーバ | RDS | CloudWatchコンソール | ディスク使用量が分析時点で30%以下 | ストレージI/O、ボリュームサイズの見直し | ◎ | - |
| 47 | DBサーバ | RDS | CloudWatchコンソール | インスタンスのメモリ使用率が月平均30%以下、インスタンスのCPU使用率が月平均30%以下 | インスタンスタイプの最適化 | ◎ | - |
| 48 | DBサーバ | DynamoDB | サービスコンソール | 予測不可能なアプリケーショントラフィックなのにリザーブドキャパシティやプロビジョニング済みキャパシティモードを使用している | リザーブドキャパシティやプロビジョニング済みキャパシティモードの使用をやめ、オンデマンドキャパシティの利用を検討する | ◎ | - |
| 49 | DBサーバ | DynamoDB | サービスコンソール | 予測可能なアプリケーショントラフィックなのにオンデマンドキャパシティモードを利用している | 過去のトラフィックからプロビジョニング済みキャパシティモードで適切なWCU/RCUの利用を検討する | ◎ | - |
| 50 | DBサーバ | DynamoDB | - | あまり使用しないデータを長期間保存している | テーブルクラスの最適化(Standard-Infrequent Accessの適用) | ◎ | - |
| 51 | DBサーバ | DynamoDB | - | 削除運用を決めていない、保管用途のみでDynamoDBで処理する必要がない | 過去データのS3への退避や削除運用の追加 | ◎ | - |
| 52 | DBサーバ | DynamoDB | サービスコンソール | Scanを使い、全件検索で不要なデータを取得している | GSI/LSI利用による不要データ取り出しの防止 | ◎ | - |
| 53 | DBサーバ | DynamoDB | サービスコンソール | アプリケーションからのアクセスに利用していないGSIが設定されている | 利用していないGSIを削除 | ◎ | - |
| 54 | ファイルサーバ | EFS | サービスコンソール | 用途にかかわらずAmazon EFSを使用している | 低頻度アクセスファイルのコスト最適化(EFSスタンダード-IAの利用を検討する) | △ | - |
| 55 | ファイルサーバ | EFS | サービスコンソール | 業務特性を考慮したストレージクラスとなっていない | スループットの見直し | △ | - |
| 56 | ファイルサーバ | EFS | サービスコンソール | 不要ファイルが多い、必要以上にファイル容量を確保している | 不要ファイルの削除、容量の見直し | △ | - |
| 57 | ファイルサーバ | FsxforWindows | サービスコンソール | 不要ファイルが多い、必要以上にファイル容量を確保している | 不要ファイルの削除、容量の見直し | △ | - |
| 58 | ファイルサーバ | FsxforWindows | サービスコンソール | データ重複排除を有効化していない | データ重複排除の適用 | △ | - |
| 59 | ファイルサーバ | FsxforWindows | サービスコンソール | 業務特性を考慮したストレージクラスとなっていない | スループットの見直し | △ | - |
| 60 | ファイルサーバ | FsxforWindows | サービスコンソール | 用途にかかわらずSSDディスクを使用している | SSD→HDDへの変更検討 | △ | - |
| 61 | ファイルサーバ | S3 | サービスコンソール | 月次での容量、利用量の漸増が顕著(不要なスナップショットがある、ライフサイクルを設定していない) | 容量の削減(不要なスナップショットなど、ライフサイクルにおける保持期間や頻度の見直し) | △ | ● |
| 62 | ファイルサーバ | S3 | サービスコンソール | 用途にかかわらずS3 Standardを使用している | S3のストレージクラスの最適化、Intelligent Tieringの適用 | △ | - |
| 63 | ファイルサーバ | S3 | S3 Storage Lens | 利用アカウント全体のオブジェクトストレージを可視化していない | Amazon S3 Storage Lensを確認した分析 | △ | - |
| 64 | 通信 | NATGW | - | VPCの数が多く、VPCごとにNATGWを用意している | NATGWの集約VPCを設けることで複数台のNATGW費用を適正にする | △ | ● |
| 65 | 通信 | NetworkFW | - | VPCの数が多く、VPCごとにNWFWを用意している | NetworkFWの集約VPCを設けることで複数台のNetworkFW費用を適正にする | △ | ● |
| 66 | 運用管理 | CloudWatch | CloudWatchLogsコンソール | サービスログはすべてCloudWatch Logsに転送している | 一概に言えないが、コストの大部分はCloudWatch Logs転送料金が占めるため、コンテナ等の場合はFireLens等を利用し、Kinesisを経由してS3に出力する | △ | - |
コスト最適化ハブの利用
コスト最適化を行う方法としてコスト最適化ハブの使用も可能である。
コスト最適化ハブを使用すると、EC2 インスタンスの適正サイズ化の推奨事項、Graviton 移行の推奨事項、アイドル状態のリソースの推奨事項、Savings Plans の推奨など、AWS コスト最適化の推奨事項を、1 つのダッシュボードで簡単に特定、フィルタリング、集約可能となる。コスト最適化ハブを使用すると、リザーブドインスタンスや Savings Plans などの AWS での特定の割引を考慮に入れて、これらの推奨事項による推定節約額を定量化できるため、推奨事項を簡単に比較して優先順位を付けることが可能となる。
[Cost Optimization Hub]
https://aws.amazon.com/jp/aws-cost-management/cost-optimization-hub/Opens in new tab
[コスト最適化ハブの紹介]
https://aws.amazon.com/jp/about-aws/whats-new/2023/11/cost-optimization-hub/Opens in new tab
改訂履歴
| 改訂年月日 | 改訂理由 |
|---|---|
| 2023年3月6日 | 新規作成 |
| 2023年6月30日 | 予実管理の追記 |
| 2023年7月24日 | コスト配分タグの追記 |
| 2023年8月25日 | タイトルの変更、および予実管理の文言修正 |
| 2023年11月27日 | メンバー専用ページで公開されているドキュメントに対する参照の文言修正 |
| 2024年2月2日 | コスト配分タグについて説明を追記 |
| 2024年3月29日 | コスト最適化ハブについて追記 |
| 2025年3月28日 | 表:01にコスト配分タグを追加 |