AWS主要サービスの月間・年間コスト/価格目安、節約術を紹介

AWSをはじめクラウドのメリットの一つがオンデマンドです。使った時間や、容量、回数等に応じた課金によってコストを最適化することができます。

一方で、オンデマンドである為に、逆に費用を予想しにくいと思っている方は少なからずいるのではないでしょうか？

1ヶ月にいくら、あるいは、サーバ1台あたりいくらと明確に決まっている方が、コストを予め予想するという観点では、安心できるかもしれません。

ただ、実際にはある程度、予測することは可能ですし、サービス毎、構成毎に1ヶ月の利用料金が、だいたい頭に入っていると導入検討をする時にも話が早くなるかと思います。

今回は、何をどの程度使えば、どのくらいの金額になるのかを解説したいと思います。導入検討の一助になれば幸いです。

頭に入れておきたいAWS主要サービスのコスト/価格目安

ご存知のとおり、AWSは、一つのサービスを取っても、多くの種類がありますので、その全てを解説することはできませんが、使用頻度が特に多いと思われるサービスについて説明したいと思います。

なお今回、取り扱うサービスの利用料金は全て東京リージョン（ap-northeast-1）を前提に算出しています。リージョンによって、同じサービスでも料金も異なりますので、マルチリージョンでの導入を検討している方は、この点の考慮が必要です。

Amazon EC2のコスト/価格

それでは、まずは、EC2から見て行きましょう。様々なサービスでシステムを構成しても、利用料のかなりの割合をEC2とRDSが占めている、ということは珍しくありません。

それだけに、どのEC2インスタンスを、どのようなプランで購入するかは慎重に選びたいところです。

今回は最も汎用的でバランスのとれた「m5」をサンプルとして見てみたいと思います。

↓↓クリックすると拡大します↓↓

インスタンスサイズが上がると、利用料金は倍になる

まず、ここで覚えておくべきなのが、インスタンスサイズが上がると、基本的に利用料金は倍になるということです。
「m5.largeとm5.xlargeはどの程度、料金が異なるのか？」と考える場合、大した差では無いような印象を受けますが、実際はm5.xlargeの利用料金は、m5.largeの2倍になります。そしてm5.xlargeとその上のm5.2xlargeも料金には倍の差があります。

それよりも上位のインスタンスサイズについては、「xlarge」の前の数字に着目しましょう。その数字の大きさに金額も比例します。上記の表でも「m5.8xlarge」は「m5.2xlarge」の4倍の金額がになっていることがわかるでしょう。

EC2のコスト/価格目安（m5ファミリー）

実際に、本番環境で使用するWebサーバのインスタンスタイプを選定するとき、「m5.xlarge」あるいは、「ｍ5.2xlarge」あたりをまずは利用してみて、実態の負荷にあわせてインスタンスタイプを調整することもあるのではないでしょうか？

そのような場合を想定し、ざっくりと下記の金額を頭に入れておくと、コスト規模を素早く把握できるかと思います。

※下記金額は、あくまでも、m5.xlargeとm5.2xlargeの料金目安です。他のインスタンスファミリーやサイズでは、大きく金額が異なります（大幅に安価なEC2インスタンスも、高価なEC2インスタンスも存在します。）。開発用途や、高いパフォーマンスを想定されないEC2インスタンスであれば、下記金額の数十分の一程度のEC2インスタンスを選択することも可能です。

またEC2の場合は、リザーブドインスタンスの購入が可能です。表に記載している1年のスタンダードリザーブドインスタンスだけでなく、いくつかのリザーブドインスタンスの購入方法が可能で、例えば、3年のリザーブドインスタンスで購入すれば、さらに深い割引率が適用されます。

EC2の為のコスト/価格節約術

EC2の料金は、AWS料金全体に占める割合も大きいので、賢く、無駄なく使って行くことで、コストを抑えたいところです。また、EC2はうっかりすると、思いもよらないところで課金されていたりもします。
発生しがちな無駄なコスト、また、その節約術について紹介します。

未使用のインスタンスの停止/削除

EC2を様々な用途で使っていると、「あれ、このEC2は何用だったかな？」ということは良くあります。開発サーバーでも「あとから使うし。」と思っていて、ずっと使わないまま、稼働させてしまった経験はないでしょうか？
EC2本体は稼働している時間で課金されますので、できるだけこまめにStop（停止）/Terminate（削除）することを、おすすめします。
ただし、後述するとおり、Stop（停止）だけでは、EC2にアタッチされたEBSで課金され続ける場合もありますので、注意が必要です。

インスタンスサイズの変更

CloudWatchなどで、CPU使用率等をモニタリングし、過剰に大きなインスタンスを利用しているようであれば、サイズを変更することでコストを削減することができます（前述のとおり、インスタンスサイズにより、コストは倍/半分になります。）。特に、市販のアプリケーションは、そのアプリケーションが十分に動かせるよう、過剰では？と思えるようなEC2スペックを推奨環境に指定している場合がありますので、実態にあわせて、インスタンスサイズを調整することは重要です。

リザーブドインスタンスの購入

予め、「長期間」で「ある程度規則的な稼働」が想定されるのであれば、リザーブドインスタンスの購入をおすすめします。期間は、1年 or 3年、また、通常のリザーブドインスタンスだけでなく、スケジュールされたリザーブドインスタンスであれば、毎日、毎週、毎月等、スケジュール実行するような処理に最適化された買い方も可能です。さらに、前払いした場合には、割引率が深くなる等、支払条件によっても金額は変わってきます。

アタッチされていないElastic IPの開放

Elastic IPは起動しているEC2にアタッチされている場合には、課金されませんが、EC2にアタッチされていない場合、あるいは、アタッチされていても、EC2が起動していない場合、Elastic IPは課金対象となりますので、EC2の稼働状況を見ながら、不必要なElastic IPは開放しておきましょう。

インスタンスのTerminateによるEBSの削除

EC2には、一部、インスタンスストアボリュームをルートデバイスとしてサポートするインスタンスタイプもありますが、ほとんどは、EBSをルートデバイスとしています。そして、そのEBSをルートデバイスとするEC2をTerminate（終了）した場合、デフォルトでは、付随して、ルートデバイスであるEBSも削除されます。ところが、EC2をStop（停止）した場合は、EC2本体で課金されることはないものの、EBSは削除されず、課金され続けます。不要なEC2はこまめにTerminate（終了）しておきましょう。

アタッチされていないEBSの削除

前述のとおり、EBSをルートデバイスとするEC2をTerminate（終了）した場合、デフォルトでは、付随して、ルートデバイスであるEBSも削除されますが、ルート以外のボリュームとしてEBSをEC2にアタッチする場合、デフォルトでEBSは削除されませんので、注意が必要です。また、EC2起動時にストレージの「終了時に削除」 オプションを選択しない場合、ルートデバイスであっても、EBSを別途削除する必要があります。

Amazon RDSのコスト/価格

EC2のパートでも説明したように、RDSもEC2のように、構成によっては利用料金のうち、かなりの割合を占める程のコストインパクトを持つ場合があります。

EC2同様にリザーブドインスタンスの購入も可能ですので、稼働計画に基づいて賢く購入していきたいところです。

RDSの場合、かなりハイスペックになってしまうかもしれませんが、db.m5ファミリーを例に挙げたいと思います。

選択可能なデータベースタイプの中でも比較的安価なMySQLと高価なSQL Serverをサンプルとして見ていきましょう。その他、MariaDB、Oracle、PostgreSQL、Auroraについては、今回、説明を割愛します。

↓↓クリックすると写真を拡大できます。↓↓

利用料金の上がり方には若干のばらつきあり

EC2同様、インスタンスサイズの上がり方と金額の上がり方が比例している部分もある一方、一部、SQL Server側には若干ばらつきがあります。
MySQLの場合は比例しているように見えますが、データベースタイプ次第で、インスタンスサイズの上がり方と金額の上がり方は比例しない場合があるようです。

RDSのコスト/価格目安（db.m5ファミリー）

それでは、上記の表の中から、目安になる金額を見てみましょう。SingleAZでの金額になりますので、MultiAZの場合は金額が倍になることは留意しておきましょう。

※あくまでも、下記金額は、db.m5.xlargeとdb.m5.2xlargeの料金目安です。他のインスタンスファミリーやサイズでは、大きく金額が異なります（大幅に安価なRDSインスタンスも、高価なRDSインスタンスも存在します。）。開発用途や、高いパフォーマンスを想定されないデータベースであれば、下記金額の数十分の一程度のRDSインスタンスを選択することも可能です。

またRDSの場合も、リザーブドインスタンスの購入が可能ですので、上記の1年のスタンダードリザーブドインスタンスだけでなく、いくつかのリザーブドインスタンスの購入方法が可能で、例えば、3年のリザーブドインスタンスで購入すれば、EC2同様、さらに深い割引率が適用されます。

RDSの為のコスト/価格節約術

RDSの料金は、EC2同様にAWS料金全体に占める割合も大きいです。一方で、EC2よりも、無駄なコストが発生しうるポイントは少ないので、確実にコストを最適化していきたいところです。

未使用のインスタンスの停止/削除

RDSの場合、EC2とは異なったポイントで注意が必要です。特に、RDSで気をつけなければならないのは、一旦、手動で停止しても、7日後に自動的にインスタンスが起動されてしまうことです。これは、最初だれもが驚くのではないでしょうか。使う予定がないものは、停止ではなく、終了しましょう。

インスタンスサイズの変更

こちらもEC2と同様ですが、RDSインスタンスの負荷状況を見ながら、処理や、業務に最適化したインスタンスサイズに変更することは重要です。一見、かなりインスタンスの負荷に余裕があるように見えても、特定の時間、特定の曜日等、ピーク時にはギリギリ、ということもありますので、様々な方向性から妥当なインスタンスサイズを特定する必要があります。

リザーブドインスタンスの購入

EC2ほどの、購入形態にバリエーションがあるわけではありませんが、RDSインスタンスでも1年 or 3年、あるいは、「全額前払い」、「一部前払い」、「前払いなし」の 3 種類の支払い方法が可能ですので、将来的な使用見込みや、割引率等を考慮しながら、業務にあったリザーブドインスタンスの購入を検討しましょう。

Single AZへの変更

Multi AZをSingle AZにすると、料金は単純に半分になります。もちろん本番環境等、妥協できない環境では、Multi AZは必須かと思いますが、可能な限り、Single AZでも問題ない環境では、業務要件を見ながら変更も検討しましょう。

RDSスナップショットの削除

RDSでは、DBインスタンスの自動バックアップはデフォルトで Amazon S3に作成されて、指定した期間保存されます。こちらはAWS公式HPにも「リージョンの総データベースストレージの 100% に達するまで、バックアップストレージに対する追加料金は発生しません。」とありますので、油断してしまいますが、問題は、「DB クラスターの削除後に保存するバックアップストレージ、およびスナップショットには、料金がかかる」ということです。これは注意し、DBクラスター削除後には、スナップショットを削除することを忘れないようにしましょう。

Amazon S3のコスト/価格

利用料金全体に対して、S3の割合が大きな部分を占めるという話はあまり聞きませんが、ストレージクラスや保存するデータ容量を誤るとかなり大きな金額にもなり得ますので、注意は必要です。

↓↓クリックすると写真を拡大できます。↓↓

想定されるアクセス頻度によって単価が設定されている

上記の表は上から、時間単価の高い順に並んでいますが、それは、想定されるアクセス頻度の高い順でもあります。日常的にアクセスされる頻度が高い程、高い単価が設定される一方、ただ、アーカイブしておくだけのようなアクセス頻度の低いストレージであればあるほど低い単価が設定されており、最大でS3標準とS3 Glacier Deep Archiveの間で12倍以上の単価差がありますので、データの特性に応じて使い分けが必要です。

各種リクエスト等の金額も考慮が必要

上記の表の前提で記載しているとおり、表の中の金額は純粋にストレージ容量に対する料金です。

ただ、実際にS3の支払いは、ストレージ容量以外に、「PUT、COPY、POST、LISTリクエスト」等、様々な項目も費用計算に含まれます。
例として、S3 Glacierの見積画面を御覧ください。ストレージ容量以外に多くの要素が金額に関連している事がわかります。

S3のコスト/価格目安

やはり、S3のストレージクラスの中で、最も日常的に使用頻度の高いのは、「S3標準」ですので、コスト規模についても大まかに把握しておくのが良いでしょう。

また目安として金額を把握する場合は、上記で説明した「PUT、COPY、POST、LISTリクエスト」等の項目も現実的な範囲で織り込んでおくべきかと思います。

S3の為のコスト/価格節約術

ライフサイクルポリシーの設定

S3では、ライフサイクルポリシーを設定することで、予め決めた日数でデータを削除したり、Amazon Glacier等、S3標準よりも料金がかからないアーカイブ用のストレージにデータを自動的に移動させることができます。S3に保管するオブジェクトのアクセス頻度や、業務上の必要性から賢くライフサイクルポリシーを設定して、無駄なデータ保管を最小限に留めましょう。

S3 Intelligent-Tieringの使用

確かに、データのアクセス頻度が予めわかっているのであれば、ライフサイクルポリシーを設定することは可能ですが、データによってアクセス頻度が想定できない場合もあります。その場合にはS3 Intelligent-Tieringがおすすめです。実際の利用頻度に応じて、対象データを低頻度アクセス階層（S3 標準 – 低頻度アクセスの料金を適用）、アーカイブアクセス階層（S3 Glacierの料金を適用）、ディープアーカイブアクセス階層（S3 Glacier Deep Archiveの料金を適用）に自動的に移動することで、無駄なコストを削減してくれます。
ただ、一点注意なのは、データのアクセス頻度を監視したり自動移行のための費用が”ほんの少し（オブジェクト 1,000 件あたり 0.0025USD/月）”かかるということです。ただ、それによって、無駄なコストが大幅に削減できるのであれば、決して高い金額ではありませんので、積極的に試したいところです。

使っていないバケットやオブジェクトの削除

実際にAWSで運用していくと、結局、S3に謎のバケットやデータが大量発生します。。（笑）
頭では、「ライフサイクルポリシーやS3 Intelligent-Tieringを使って費用を削減できる」とは分かっていても、いざ、日々の業務、運用、開発の中では、「ちょっとバケットを作って」のような場面が出てきます。そのような事が数年に亘り、重なっていくと、様々なバケット、フォルダ、オブジェクトが用途不明のまま残っていたりしますので、定期的に棚卸しすることで無駄なコストを抑えましょう。

まとめ

3つの主要サービス（EC2、RDS、S3）について説明しましたが、料金という一つの観点だけでも、説明するにはかなりのボリュームがありました。

使い方、購入・支払方法を再検討するだけで、コストは大きく異なる場合もありますので、何気なく使っているAWSサービスを今回取り上げたような観点から見直してみるのもいいかもしれません。

また、今回はAWSサービス単体を取り上げましたが、結果的に、このサービスはシステムとして構成されることになりますので、システム全体としても目安となる金額は把握しておきたいところです。

別の記事にはなりますが、定番構成毎に、料金目安が把握できるような記事についても執筆中ですのでご期待下さい。