AWSコスト最適化入門 ─ クラウドで「こんなにかかるはずじゃなかった！」を避けるツールと計測
「あれ？ AWSのコスト、高すぎ…？」そう感じたときには、そもそもコストを正しく見積れているのか、適切に計測できているのかから見直しましょう。クラウドならではのメリットを享受しながら、コストを適正な範囲にしていく上で役立つ機能やサービスを紹介します。
こんにちは。吉川功一郎と申します。 私はフリーランスのシステムエンジニアとしてあちこちの会社をお手伝いしていますが、その中で、AWS（Amazon Web Services）移行に関するさまざまな相談をいただきます。切り口はいろいろありますが、意外と多いのが「コスト」に関する相談です。
さすがに「クラウド破産」というケースを耳にしたことはありませんが、「クラウド移行で安くなると思ったのだけれど、思ったほどコスト削減効果が出ない」とか、「使い始めは安かったけれど、半年、1年と運用し続けていくうちに費用が膨らんでしまった」というお話が多いのです。
特に、オンプレミスのシステム、データセンターにあるものをそのままの形式でクラウドに持ってきたときに、コストメリットがあまり出ないことや、むしろムダが多くなってしまうこともあります。どうしてそんな状況になってしまうのでしょうか。
この記事では、AWSにおけるコスト管理において押さえるべきポイントと、クラウドならではのメリットを享受しながらコストを適正な範囲にしていく上で役立つ機能やサービスを説明したいと思います。
クラウドのコスト構造
PDCAという言葉はよく耳にすると思います。サイトやサービス、製品の品質について、最初に何らかの目標を立て、実際に作ってみて、パフォーマンスを計測し、チェックした結果に基づいて改善するサイクルをどんどん回しているのではないでしょうか。
クラウドについては、コストにもそのサイクルを適用すべきだと思います。思ったよりコストが高いというならば、まず「どのくらいならば適正範囲なのか」という基準を明らかにしなければなりません。
コンピューティング＋ストレージ＋ネットワーク
オンプレミスでは、サーバとストレージ、ネットワーク機器といったシステムを構成するハードウェアの費用に加え、データセンターを間借りする費用、それにメンテナンスに当たるエンジニアの人件費などがかかります。
これに対しクラウドの場合、データセンターのラック代や電気代といったファシリティ関連のコストはかからず、サービスの利用料を払えばよいだけです。クラウドのサービスにかかるコストは、大きく3つに分類できます。コンピューティングとストレージとネットワークです。
コンピューティングというのは、データセンターでいうところの「サーバの台数」や「スペック」に置き換えられます。ストレージも文字通り、利用する「HDDの容量」と考えればいいでしょう。ネットワークもその通りで、「インターネットとの通信がどれだけあるか」です。そして、それぞれにクラウド事業者のファシリティの費用が案分されて乗っています。
いずれも支払うのは使った分だけで、初期費用はかかりません。それが従量課金のいいところですが、逆に、顧客が増え、規模が大きくなればなるほどコストが増えます。問題は、そのコストの増え方の角度です。思ったよりも急激にコストが上がってしまった、という印象を持ってしまうことがあるようです。
こうした事態を避けるためにも、まずは自分なりに「このくらいの規模になれば、このくらいのコストがかかるだろう」という見積りを持っておくことが大事です。
AWSが提供するコスト見積りツールと注意点
見積りのためのツールを、AWS自身がいくつか提供しています。ただ、ちょっとクセがあるというか、使い方に配慮することが重要です。
1つは「AWS Simple Monthly Calculator」です。「どのサービスをどのくらい使うか」を入力すると、月額でいくらかかるかが出てきます。
▶ Amazon Web Services Simple Monthly Calculator
前提として、そもそも「AWSのサービスがどういうものか」「このサービスはどんなものか」を知っていなければ利用できません。ある程度AWSのサービスについて理解している人ならば、ざっくり見積りを作成するのに便利だと思います。
もう1つは「TCO計算ツール」です。AWS Simple Monthly Calculatorよりもシンプルなツールで、「今、データセンターにサーバがどのくらいあるか」を入力すると、それらをAWSに移行した場合の料金を計算してくれます。
ただし、英語のみで提供されている上、場合によってはうまく結果が出ず、エラーが返ってくることがあります。もしかするとAWS側で適宜サイジングを行って「インスタンスはこんなにいらないはず」と判断しているのかもしれませんが、うまくエラーを出さないように使うことが難しいため、私はほとんど使っていません。
クラウドのコストを事前に見積る難しさ
オンプレミスの場合、サーバを買う場合にしても何にしても、必ず事前にベンダーから見積書が来ます。ですから、「ああ、このくらいかかるんだ」というのが数字で事前に分かります。多少予算オーバーしたとしても、事前の見積りと比較して、事前の想定内ならば「まあ、このくらいならばしょうがない」となるでしょう。問題は想定外の場合です。
クラウドでは、事前に見積りを出すのが本質的に難しいという課題があります。オンプレミスでも、時にオーバースペックだったり、逆に全然足りないから買い足さなくてはいけないということがあります。クラウドでも似たようなことが起こり得ますが、その際の「拠り所」や「基準」になるものが出しにくいのです。
その結果、ときどき「想定したよりも高いんです」という相談をされるのですが、「では、想定はどれくらいだったんですか？」と聞いても、答えられないことがけっこうあります。つまり、明確な基準を持たず、「クラウドなら安くなる」というふわっとした感覚で移行してしまっている方も、少なからずいるのです。
背景には、クラウドならではの良さではあるのですが、「まずはお試しで使ってみよう」と始めるケースが多いこともあるでしょう。クラウド事業者側も、「小規模な範囲でしたら評価用に無償で提供します」「最初の1年は無料で提供しますから、いろいろ評価してみてください」というスタンスです。
評価の段階では、コストのことはあまり深く考えずに使ってみて、「いいね、このまま使っていこう」と判断して本格移行したころに無料期間が終わり、ぽーんとコストが跳ね上がる……なんてこともあるでしょう。
ですので「話と違った」ということにならないよう、まずは自社で「だいたいこのくらい」という見積りを立てておくことが第一歩になります。
見積りをもとにPDCAを回すための「計測」を
前述のツールも使ってしっかりと見積りを立て、使い始めたとします。ですが、その後「今どのくらいの料金がかかっているのか」をしっかり計測し、確認しなければ意味はありません。さもなければ、果たして見積り通りだったのかすら分かりません。
まずは請求書のチェックから
計測に使えるツールもいくつかありますが、まずは請求書をしっかりチェックすることです。一通り目を通してみて「自分が使った記憶のないサービス」や「使わないはずのリージョン」での費用が発生していないかを確認すべきでしょう。
バカバカしいように思えるかもしれませんが、これらは意外とよくあるケースです。特にAWSは管理画面の構造上、別リージョンのリソースを確認する際には画面の切り替えが必要となり、気付きにくい部分ですから、注意が必要です。
ちなみに、グローバルに人材を募って開発をしている会社では、不思議なことに、アメリカならばアメリカ、アジアならアジアとか、自分の出身地に近いリージョンでインスタンスを立ち上げがちという傾向があるようです。
AWSの請求書の例
リソースを調達するエンジニア自身が確認する
クラウドの最大の利点は「リソースの調達がしやすい」ことですが、それゆえ、いろんなユーザーが気楽にインスタンスを立ててしまい、気がついたら、「え、これって誰が作ったの？」となるパターンはよくあります。慌ててSlackで「この『野良インスタンス』に、誰か記憶ありませんか？」と確認する羽目になります。
それで持ち主が分かればいいのですが、時には立てた人が退職していることもあります。そんなときには、CPUの使用率やインスタンスの利用状況を確認して、もう使っていなそうだと判断してから実際に停止などのアクションを取ります。
クラウドサービスでは、Webベースの管理画面のほかに、自動化のためのコマンドが用意されています。デプロイツールなどと連携して、コマンドを1つポンと叩けば、例えば「launch instance」と入力するだけでインスタンスが立ち上がったり、さまざまなリソースをすぐに使えるとても便利な機能です。
これは裏を返せば、ちょっとしたミスで、想定外のリージョンでサーバが立ち上がってしまい、知らないうちにコストが発生していた、ということになりかねません。ですから面倒でも、請求書は定期的に確認すべきです。
AWSの場合、請求書払いではなくクレジットカード払いがデフォルトであることも、請求額に無頓着になりがちな要因の1つかもしれません。請求書ならば支払う前に金額をチェックされ、額が大き過ぎたらベンダーに確認することになるでしょう。
しかし、クレジットカードで自動的に引き落とされると、請求元はAmazonですし「このくらいかかるのかな、しかたないな」と経理の担当者に思われているかもしれません。やはり、技術の担当者が自発的に請求書を見にいくことが重要です。
AWSのコスト計測を手助けしてくれるツール
クラウドの場合は、固定額ではなく従量課金制なので、変化に気付くことも重要です。その意味で、毎月の請求書チェックに加えて便利なツールがあります。
Cost Explorer
Cost Explorerでは、請求書の内容をもとに、グラフィカルに費用が分かります。しかも時系列で金額が並ぶため、過去との比較が容易です。
このため、例えば「先月まで毎月何十ドルだったものが、今月になって突然何百ドルになっている」といった変化に気付きやすくなります。
Cost Explorer
Cost Explorerを使うには、あらかじめ管理画面で設定を行い、有効にしておかなくてはなりません。今から使い始めて、3カ月より過去に遡って確認するという使い方はできないことに注意が必要です。
また、何にどのくらい使われたのかをより詳細に分析したいならば、事前に各リソースにタグを付け、分類しやすいようにしておく方がいいでしょう。そうすれば、リソース利用状況をCSV形式で出力し、分析を行うことも可能です。
繰り返しになりますが、AWSは従量課金ですから、使ったら使った分、お金がかかるのは仕方がないところがあります。ただ、それが意図したものかどうかの確認は必要ですし、余分に使っていないか、想定以上に急に上がっていないかのチェックも重要です。
例えば、ユーザーが1人増えただけなのに、料金がいきなり跳ね上がってしまった場合、必要以上に高スペックのサーバ、要は高いサーバを用意してしまっていたというパターンがあります。スペックだけではなく、台数についても確認が必要です。
請求アラーム
もう1つはアラーム機能です。私も、突然何百ドルといった請求が来るのは怖いので、個人で使っているアカウントについては、毎月の請求書チェックに加え、「利用額が○○ドル以上になったら通知します」というアラームを設定しています。
アラームの設定額についてはユーザーによりけりで、これという基準はありません。前月の請求額、あるいは過去半年くらいの請求額を見て、実績を基に設定することになるでしょう。
例えば、1カ月で100ドルくらいの見積りを立てつつ、多少超えるのは前提で「15日の時点で80ドルを超えていたらまずい」と超えるタイミングを見るための閾値を設定したり、あるいは平均値よりちょっと多い120％の額を超過したら警告したり……といったケースが考えられます。
まずは、アラームが来たからチェックしなくちゃ、というきっかけとして使ってみるといいのではないでしょうか。想定外のリソース利用に加え、アカウントの不正利用による請求を見つけるのにも活用できると思います。
AWS Trusted Advisor
さらにAWS Trusted Advisorを有効にすれば、アカウントのリソース利用状況を調査し、パフォーマンス、セキュリティに加え、コスト、耐障害性、サービス数の上限という5つの観点から「こうした方がいいですよ」というアドバイスを表示してくれます。
ただし、標準で利用できる項目はサービス数の上限とセキュリティの2つだけで、コストも含む残り3つの要素を調査するにはAWSとの有償サポート契約が必要になります。
Cost Explorerによる現状把握から一歩踏み込んで、各サービス毎の利用率等を見た上で提言してくれるので、サポート契約を結んでいるならば、確認をオススメします。
利用状況をもとに、例えば「リザーブドインスタンスをこれだけ購入したのに、使っていませんよ」とか「このインスタンスは利用率が低いのでもったいないですよ」といったアドバイスを提供してくれます。
AWSのコストダウンに活用できる主なサービス
ここまでで、事前の見積額と実際の毎月の請求額をチェックする方法が分かったと思います。次は、これをいかに最適化するかです。クラウドをやめてしまうのは論外として、今の規模を維持しながら、どれだけ費用を下げられるかを考えなくてはなりません。
まずクラウド利用時の大前提ですが、「余計なもの」「オーバースペックのもの」は用意すべきではありません。適切なサイズのものを適切な数だけ用意し、必要になったときにはじめて拡張する、それが大原則です。
もちろん、ユーザーが増えればかかるコストも増えます。クラウドにはそうした「生き物」的なところがありますから、そこの変化はPDCAのサイクルを通してチェックする習慣をつけるしかありません。
その上で、どうやってコストを圧縮するかですが、実はAWS側もいろいろと割引機能を用意してくれています。
リザーブドインスタンス
中でも基本的で、まず採用を検討したいのが「リザーブドインスタンス」です。
これは言うなれば「予約前払いで、その分お安くしますよ」というものです。1年分もしくは3年分の予約をして、一定の金額をまとめて支払ってしまえば、その期間中は追加コストなしまたは月額の支払いが大幅に割引されます。逆に言えば、たとえ使っていなくても、前払いした分は返ってきません。
リザーブドインスタンスが利用できるサービスは、EC2とRDS、ElasticSearchなどに限定されています。とはいえ割引率は3割から5割と無視できない数字です。ですから、「この先腰を据えて使おう」と決断するのであれば、まずはリザーブドインスタンスを検討し、インスタンスのコストを下げるべきでしょう。
リザーブドインスタンスのメニューには1年と3年があり、当然ながら3年契約の方が割引率は高くなります。ただし、特に動きの速いWebサービスの世界で、3年後を見通して購入するとなると勇気がいるのも事実です。
例えば、新規サービスをローンチする場合、いったんサービスインしたなら、よほどのことがない限り半年くらいは続けるものと思います。一方、リザーブドインスタンスの料金は、半年から7、8カ月でペイでき、それ以降使えば安くなるので、そのあたりに損益分岐点があります。
このため、サービスローンチのタイミングで「まずは1年分を買ってみましょうか」と提案することがよくあります。
ただ、リザーブドインスタンスはあくまで「このスペックのサーバを何台、1年もしくは3年分購入する」という数に関する契約であって、特定のインスタンスを購入するものではありません。
購入時に利用していたサービスが1年足らずで終わってしまったとしても、代わりに同じスペックで利用できる別のサービスに適用することもできます。
クラウドのコストを構成する3つの要素のうち、コンピューティングについてはこのようにリザーブドインスタンスの購入がお勧めです。残りの2つについてはどうでしょうか。
ストレージではデータの保存先を最適に
ストレージについては、残念ながらそうした割引の仕組みはありません。利用する容量だけを適切に確保しておいて、足りなくなったらあとから増やせばいい、という考え方がまずは基本です。
AWSのストレージには、最も使用頻度が高いものが2種類あります。1つはEBSで、サーバに搭載されているHDDのようなイメージで使います。もう1つはS3で、これはただのデータ保管場所であり、外付けHDDやファイルサーバのようなものといえるでしょう。
このうちEBSはそのつど容量を変えられますから、あまり大きな容量を確保しないのが大前提です。また、リソースをこまめにチェックし、不要になったものがあれば適宜削除するのも基本です。
一方、S3には、データにアクセスする頻度や冗長性によって、いくつか異なる設定があります。標準サービスでは自動的に最低3カ所にコピーしてデータを確保しますが、なくなっても痛くないデータは1カ所に保管するだけの設定にすれば、その分安くなります。
また、法令遵守や監査の都合上、年1回アクセスするかしないかというデータについては、テープドライブのようなイメージで使えるGlacierという激安のストレージがありますから、データの性質や重要度に応じて、使うストレージを適切に設定するのがいいでしょう。
ただし、数が多くなると、自分たちで判断し、適用するのは大変な作業です。AWSのストレージには、あらかじめルールを定めておけば、それに沿って自動的にデータの保存先を変えてくれる「ライフサイクル機能」があるので、これをきちんと設定しましょう。
例えば「ファイルが作成されて30日たったら、アーカイブ用のGlacierに移す」といったルールを設定しておけば、あとはAWSがそれに従って自動的にデータを移してくれ、手間も省けますし、コストも削減できます。
データの中には、アーカイブやログのように、永久とまではいかなくても5年や7年といった長期間保管が求められるものがあります。それを全て同じように保管していては、じわじわとコストが増していきます。
AWSには、コストを最適化できる機能やツールがあるのですから、使わないのはもったいない話です。
ネットワークはアプリケーションで
最後の要素、ネットワークについては、「銀の弾丸」的なものは存在しません。インフラ側で頑張ってどうにかなる問題ではないことが多いです。
むしろ、アプリケーションやWebサーバ側で、テキストデータには圧縮をかけたり、スタイルシートやJavaScriptといった要素についてはきちんとminify（軽量化）して転送データ量を削るといった具合に、基本に忠実かつ丁寧に作ることによって、クラウドのネットワーク利用料を減らせますし、ユーザーにとってもやさしい作りになると思います。
あくまで1つの例ですが、1日に20万ページビューくらいある読み物系のサイトを、EC2の仮想サーバ上に立てたWebサーバとELB（ロードバランサ）で処理し、データベースにはマネージドサービスのRDSを利用する構成を考えた場合、何も最適化を考えずにAWS上でホストすると、月額で25～30万という額になってしまうケースもあります。
同じ規模のサービスをオンプレミスの環境で、データセンターに2～3台のサーバを立ててまかなうなら、だいたい月額は10～15万というイメージですから、そうすると「クラウドって意外と高いね」という印象につながりがちです（実際には、オンプレミス環境ではハードウェア初期費用等も必要になるので、トータルコスト的にはクラウドと同程度になります）。
ここで紹介した方法を採用することで、クラウドの費用を3～4割は押さえられるのではないでしょうか。
コスト計算もエンジニアのスキルの1つに
この記事では、AWSを利用する際の見積りと実際の請求額を把握し、コンピューティングとストレージ、ネットワークのコストを最適化する方法を紹介してきました。
クラウドを利用し始めるときに、使うこと、ちゃんと動かすことだけで精一杯になってしまい、その先のコスト最適化まで目が行き届かないのは仕方のないことだと思います。
ですが、中長期的にAWSを活用するならば、ぜひAWSが提供しているさまざまなツールやサービスのことを知り、いまの請求額をチェックして、クラウドならではの良さを生かしながら、コストも下げていってほしいと思います。
そもそもオンプレミスからクラウドに移行した場合には、人件費をはじめさまざまなコストがかかっているのですから、ぜひそれをムダにしないでください。
月に1回は請求の画面を見る習慣を
私自身もそうなのですが、エンジニアは技術に関する話となると喜んで食いつきますが、お金や契約に関する話となると苦手意識を持っている方が多いようです。そのため、毎月の請求書チェックも、やらないといけないことは分かっていながら、なかなか手を出せず、つい後回しになってしまうことが多いと思います。
ですが、AWSをはじめとするクラウドサービスの請求書は、紙の文書ではなく、ほかの設定と同じようにWebの管理画面で確認できます。まずは、毎月1回はチェックしてみてください。
そして3カ月、あるいは6カ月たてば、特に専門知識がなくても、推移をもとに「だいたいこのくらいなんだな」ということを把握し、「変に上がったり下がったりしていないかな」「この半年ずっと立ち上がっているインスタンスがあるから、これはリザーブドインスタンスを買おうかな」といった判断ができるようになると思います。
また、新しいサービスを試してみたら1週間後に「いくらくらいかかったのかな」とリアルタイムで確認して、「自分が作ったもののコスト」に興味を持つ入口として使ってもらうのもいいと思います。
アプリ作りと密接に結びつくコスト意識
コストの話はプロジェクトマネージャーが気にするもので、いちエンジニアにはあまり関係のない話題だと思われがちですが、私はそう思いません。
この先、クラウドを本格的に使おうとすれば、サーバレスやコンテナ、マイクロサービスといった開発・設計スタイルは避けて通れないでしょう。そんな形になれば、アプリの作りとコストは、より密接に結びついてくることになります。
今後は開発者にとっても、自分の作ったもののコストを意識する、ということが必須スキルの1つになっていくのではないかと思います。
もちろん、最初からコスト構造を念頭に置いてアプリを設計できればベストですが、いきなりそこまで要求するのがつらいことも分かります。ですから、まず「いまこれだけコストがかかっているのは、自分の作ったアプリ、自分の作ったサイトがこういう作りだからだよね」と、逆説的にコストに興味を持つきっかけにしていただけるといいのではないでしょうか。
お金の話というと苦手意識を持つかもしれませんが、定量的に数字が見えますから、意外と楽しい作業だと思います。オンプレミスからクラウドへの移行に伴って、コスト削減の階段が、より小刻みに、細かくなったため、少し頑張ればその結果がすぐ反映され、成果が出やすい、結果が見えやすい作業になっているといえるでしょう。
そんなふうに捉えると、クラウドのコスト最適化も楽しい作業になるかもしれません。
〈参考〉AWS公式サイトのコストについてのページ
以下は、コストの最適化に関するホワイトペーパー（英語）です。
▶ Cost optimization e-book（コスト最適化の戦略、PDF）
吉川功一郎（よしかわ・こういちろう） 
2011年から活動中のフリーランスエンジニア。大規模Webシステムから小規模事業所のLANまで、あらゆる規模のシステム・ネットワークに関わってきた経験をもとに「運用」を考えることが得意。クラウドの運用や導入に関わるコンサルティング（と子育て）が最近のメインワーク。技術書典6で技術系同人誌『Developers Magazine vol.1』に参加。
blog.yskw.info
blog.yskw.info
構成：高橋睦美
