資料公開|AWSコストを削減(最適化)するには?短期でできる改善策と長期的な運用負荷軽減への取り組み方を解説

公開 : 2023.03.02  最終更新 : 2023.04.17

2023年2月28日にオンラインセミナー『AWSコストを削減(最適化)するには?短期でできる改善策と長期的な運用負荷軽減への取り組み方を解説』を開催いたしました。
この記事では当日用いた資料を公開しています。

動画で見る

AWSのコスト最適化とは?

現在は円安の影響もあり、AWSコストが以前よりも増加しているため削減できないかと考える方が多いようです。NCDCにも下記のようなご相談をいただくケースが増えています。

  • AWSのどの部分にお金がかかっているかわからない
  • 削減できる無駄がありそうだとはわかっているが、忙しくてその対応に手が回らない
  • 自社で十分対策しているつもりだが、本当に無駄なコストがかからない最適な設定にできているのかわからない
  • アプリが乱立していて全体像が把握できないため、サーバー管理者の方で削減できる無駄があるのかどうかもわからない
  • アーキテクチャを見直すことでコストを減らせるのかどうかわからない

課題を認識しながらも、適切な対応ができている企業は多くありません。そのため、あきらかな無駄遣いをしていなくてもコスト削減余地がある場合がほとんどです。

この記事では、AWSコストを削減(最適化)するための「短期でできる設定の見直し」と「長期的に取り組むべきアーキテクチャの見直しなどを含めた運用負荷軽減への取り組み」の2つをご紹介します。

AWSコストに無駄が生じる理由

まずはAWSにおける無駄なコストとは何かを2つに分類します。

  1.  全く使用していないにもかかわらず、サーバーやDBを放置している状態を「無駄」
  2. 必要なリソースだが、必要以上のスペック・稼働時間になっていることにより余計にかかっているコストを「過剰」

この2つの観点で、コスト削減に取り組むことが有効です。とくに「無駄」だけに注目するのではなく、「過剰」の部分をいかに削るかが重要になります。

ここでは「無駄」や「過剰」が発生する理由を3つ紹介します。

まず1つ目に、AWSの運用ルールがない・徹底されていないことです。無駄や過剰を生む原因のほとんどはこれにあたると考えられます。
例えば、サイズを決める基準やサーバーの立て方、プロジェクト終了後のサーバーの閉じ方などの運用ルールが決まっていないと、使われていないサーバーが放置されていたり(無駄)、過剰なスペックのサーバーが動き続けていたり(過剰)という状況が発生します。
しかし、運用ルールがなくAWSの利用方法を現場の裁量に任せているケースは多いようです(=コスト削減余地があることが多い)。
サーバー管理者に依存せずエンジニアが自由にサービスを作れることはAWS利用のメリットの一つであるため、現場にある程度の自由を与えることは一概には否定できませんが、そのメリットを活かしつつも、利用状況に応じた定期的な見直しを行うことは重要です。

2つ目に、AWSの料金明細がわからない・見ていないことです。代理店経由でAWSを契約している場合、どこに多くの費用がかかっているか担当者が把握できないため無駄が発生していることがあります。もしこれにあたる場合は、まず料金明細を確認して分析するようにしましょう。

3つ目は「AWS運用担当者にコスト削減の知識がない」ことです。これも無駄や過剰を生む原因になります。もしこれにあたる場合は、この記事で知識を身につけてコスト削減に取り組んでみてください。

短期でできる改善方法

短期でできる改善方法として、「無駄」を洗い出す方法と「過剰」なリソースを見直す方法を紹介します。

AWSコストの「無駄」を見直す

まず無駄に対するアプローチは、「使っていないリソースを見つけて削除する」というシンプルな方法です。最終的に現場担当者に聞く必要がありますが、まずは使っていないリソースを確認しましょう。

  • 終了したプロジェクトの開発用リソース
  • 目的が不明なサーバーやDB

終了したプロジェクトのリソースが特定できれば、それは使っていない可能性が高いため見直しの対象です。また、テスト用や開発用として一時的に使うものは名前を適当につけて放置されていることもあります。目的がわからないものがあれば利用の有無を明らかにして、不要であれば削除するという処置が必要です。

より機械的に判断する場合、メトリクス(システムのパフォーマンスに関するデータ)を見る方法もあります。
AWSではさまざまなデータをAmazon CloudWatchで収集していますので、以下の2点を確認しましょう。

  • CPUの使用率:OSを動かしているだけのCPU使用率だとソフトウェアを動かしている可能性は少ないと判断できます
  • ネットワークIN/OUT:通信が一切発生していないサーバー・DBは使われていない可能性が高いと判断できます

そのほかに、AWS Trusted Advisorを使う方法もあります。
これはセキュリティやパフォーマンス向上、コスト削減に役立つAWSの公式サービスで、使っていない可能性が高いリソースを提案してくれる機能を持ちます。

このように、普段から情報を整理しておくことが、短期でできるコストの改善施策にとって重要な要素です。

AWSコストの「過剰」を見直す

次に、「過剰」に対するアプローチです。
特に3つのサービス(Amazon EC2・Amazon RDS・Amazon S3)において過剰なリソースが発生しやすい傾向にあります。
過剰なリソースを設定してしまいがちな4つの例をご紹介します。

1つ目がインスタンスサイズです。(Amazon EC2・Amazon RDS)
インスタンスサイズを確認して、スペックが余っているリソースがあれば最適なサイズに変更しましょう。

2つ目が、稼働時間です。(Amazon EC2・Amazon RDS)
これは見落としがちですが、重要なポイントです。週末や夜間を停めるだけで30~40%の稼働時間を削減することができます。ビジネス用のアプリケーションなど稼働時間が限られるものは、週末や夜間の自動停止設定などが有効だと考えられます。

3つ目がマルチAZです。(Amazon RDS)
DBは一つが落ちても大丈夫なように予備のDBを別の場所に作るマルチAZ体制にすることがよくあります。DBの障害に備えて本番環境をマルチAZ体制にすることは問題ありません。しかし、開発環境や社内サービスなどはシステムダウンが許容されることもあります。そこまでの備えが必要のないサービスにもマルチAZを適用していないか確認してみましょう。

4つ目は、アクセス頻度です。(Amazon S3)
アクセス頻度が低データはAmazon S3の中でも安いストレージを使うことが推奨されています。ただし、安いストレージはすぐにデータを取り出せないというデメリットがありますので、メリット・デメリットを理解した上で安いストレージを利用しましょう。

AWS Cost Explorerの活用

下図は、AWS Cost Explorerというツールの画面です。このグラフで「どの月にいくら、何のサービスに使っているか」を細かく分析することができます。

下図はグラフの内訳です。

このプロジェクトの場合、Amazon RDSの割合が大きいので、

  • インスタンスサイズ
  • 稼働時間
  • マルチAZ

の3つを見直せばよいことが分かります。
Amazon EC2の割合が大きければAmazon EC2を優先的に削減していくなど「効果が出やすいところ」や「無駄が多そうなところ」をAWS Cost Explorerで把握してコスト削減施策を実施することが可能です。

実際にAmazon RDSを削減してく手順を説明します。
最終的にはDBを一つずつ見ていく必要がありますが、Amazon RDSの内訳もAWS Cost Explorerで見ることができます。

例えば、DBのサイズ別で、どのDBにコストがかかっているかを分析することも可能です。
例示したプロジェクトでは、m5.largeサイズに一番コストがかかっているので、まずはここから改善していくのが良いと判断ができます。また、t3.mediumも同じくらいコストがかかっています。mediumの料金はlargeの半分ですが、largeと同じくらいコストがかかっていることから、mediumの数が多いという判断ができます。

AWS Cost Explorerで、プロジェクト別利用料金を見ることも可能です。コストタグを使うことで、利用目的別のコストを算出できます。
下図は、プロジェクトに関連するコストを抽出したもので、このプロジェクトではAWS Lambdaを中心に使われているのがわかります。

AWSの割引サービスを使ったコスト削減

Saving Plansとリザーブド・インスタンスというAWSの割引サービスがあります。AWSと今後の利用量をあらかじめ約束しておくことで、割引が受けられる仕組みです。
ただし、実際の利用量が少なくても約束した利用料を支払うことになるため、過剰に購入すると損をする可能性もあります。適切な購入量を心がけましょう。

さらに割引率を上げるオプションが2つあります。

  •  3年分の利用を約束する
  • 料金を前払いする

これらは割引率が非常に高く、DBで最大63%の割引が適用されます。
(正確な割引率等の情報はAWSの公式サイトを参照してください)

「過剰」は削るべきだが「バッファ」は必要

「過剰」なものを見直す方法を説明しましたが、その前提として「過剰」と「バッファ」を間違えないことがとても大切です。
一見スペックが過剰に大きく見えても、アクセス集中に耐えるため「あえて」大きくしている可能性があります。必要なバッファは残した上で削減していきましょう。

また、コストを下げるとその分スペックも下がってしまう可能性があります。「過剰」なスペックは削るべきですが、削減しすぎると不便になる・リスクがあることを理解しておくことも重要です。

不便なこと・リスクとして考えられる例

  • スペックが小さすぎて反応が遅くなってしまう
  • シングルAZだといざという時にすぐに使えないリスクがあがる
  • Saving Plans・リザーブドインスタンスも払い過ぎのリスクあり

コスト削減のステップ

次に、これまでの説明を踏まえてコスト削減に取り組んでいただくための手順を紹介します。

  1. 全体の分析をする
    闇雲にコスト削減に取り組んでも、効果は期待できません。AWS Cost Explorerなどを活用しながら、どこにどのくらいのコストがかかっているか、まずは全体の分析を行います。

  2. コストがかかっている部分から削減余地を探す
    特に大きいインスタンスほど注意が必要です。余っている可能性が高いので大きいインスタンスから稼働率を確認しましょう。

  3. 「絶対に今後も使う」部分を特定し、Saving Plans/リザーブドインスタンスの導入をする
    2の削減余地を探す過程で使っていないインスタンスやサーバーを特定します。その中でも、1年、3年と将来を見据えたときに「必ず使う」ところを特定し、その使用量に応じてSaving Plansまたはリザーブドインスタンスを導入することが有効です。
    例えば、自社の売上の半分を占める主力サービスがあったとします。このようなサービスは3年後になくなっていることは考えにくいです。一方で、システム全体の更新が予定されているような場合は、数年後には使わなくなってしまう可能性があるので注意しましょう。

  4. 効果を測定する・分析を続ける
    一時的にコスト削減を実現したとしても、時間が経てば不要なインスタンスは増えていくものです。今後のために、効果の測定分析を継続していくことが、コスト削減においては重要なポイントです。

長期的な運用負荷軽減への取り組み方

先述した通り、AWSコストの無駄や過剰を予防するためにAWSの運用ルールを定めることは有効な解決策ですが、ルールが守られなければ意味がありません。また、ルールはあっても、忙しくてルール通りの運用をする余裕がないことも多いのではないでしょうか。
そこで、NCDCでは「運用ルールを守らせる仕組みを作る・自動化する」ことをおすすめしています。いくつかの例を紹介します。

  • 開発者には一定サイズ以上のインスタンスを作らせない、スポットインスタンスを使わせる
  • テスト用の資源にはタグをつけさせる・プロジェクト識別用のタグをつけさせる
  • 上記をIAMやAWS Configで強制する
  • AWS Cost ExplorerやAWS Budgets、Cost Anomaly Detectionなどのサービスを活用し利用料を監視・アラートする

また、コストが最適化しやすいアーキテクチャに変えることも有効です。
例えば、Amazon EC2でサーバーを立てると過剰スペックになりやすい傾向にあります。その対策としてサーバーレスアーキテクチャを導入すると、サーバーが常時稼働せず必要なときだけ動く仕組みになるため、コスト削減に繋がります。

コスト最適なアーキテクチャ

例えば、Amazon EC2を1台だけ用意してアクセスを捌く場合、アクセス増加時にキャパ不足が発生してしまいます。対処方法として、サイズを2倍にする、または2台目を立てる方法がありますが、これではスケールが大きすぎてしまいます。

それに対してコンテナやサーバーレスを使うと、アクセス数に応じて細い単位でサーバー処理量を増減できます。アクセスがないときはコンテナ1つで運用し、アクセスが増えたらコンテナ3つを動かすというようにコスト最適な動きができます。

AWSのコスト最適化とは

AWSのコストが気になったら、まずは「なぜAWSを使うのか?」を考えてみましょう。大きく分けると「DX推進・社内のIT化促進」「IT関連のコスト削減」という2つの目的がほとんどだと思います。

どちらの目的であっても、クラウドの活用が進むほどAWSの利用量は増えていくため、その分の費用が増えるのは当然です。
本来のAWS利用の目的を忘れて「AWSにかかる費用をいかに減らしたか」だけをKPIにすると本末転倒になってしまいます。

クラウドを活用してDXが進み業務効率が上がった、あるいはオンプレからの移行が進んでオンプレでかかっていたコストを削減した…。その結果としてAWSの利用量が増えたのであれば、AWSにかかる費用が増えても問題ないといえます。

注意しなければならないのは、オンプレとクラウドの費用を比較するときに、オンプレ時代の「サーバー費用」とクラウド移行後の「利用料」だけを見てしまうのは間違いだということです。
オンプレからクラウドに移行すると、多くの場合「サーバーの運用・保守の負荷が減る」「アプリ開発の柔軟性を得られる」などのメリットがあります。サーバーの運用・保守からアプリ開発に至るまで、さまざまな手間を減らせる(従来かかっていた人件費を削減できる)ので、費用の比較時はそれらの効果を考慮して考える必要があります。

このように、コストを削る努力は大切ですが、長いスパンで考えるとAWS費用を抑えることが必ずしも良いという訳ではありません。適切なコストでクラウドの恩恵を受け、コストに見合ったDXのメリットが享受できているかという観点を持ってコストを検討しましょう。
その中で、メリットが小さいのにコストがかかり過ぎているところがあれば、使い方を見直して費用を最適化していくことが、AWSを長期的にうまく活用するポイントです。

AWSコストの削減(最適化)のご相談はNCDCへ

NCDCでは、成果報酬型でお客様のAWSのコストを削減するサービスを提供しています。お客様に代わりAWSの利用状況を見直し、最適化により利用料の削減を図ります。成果報酬型のサービスなので、お客様は新たな負担なしでコスト削減に取り組むことが可能です。

NCDCの知見と実力に基づいたサービスである、成果が出せる自信があるがゆえのサービスです。ぜひお気軽にご相談ください。

ページトップへ

お問い合わせ

NCDCのサービスやセミナー依頼などのお問い合わせは
下記のお電話 また、お問い合わせフォームよりお気軽にご連絡ください。

050-3852-6483