ITシステムを構築するにあたって、AWS（Amazon Web Services)は、もはやなくてはならない存在でしょう。
AWSがもつ柔軟性と多彩さ、そして無料枠や従量課金性といったコストの低さに注目が集まり、大手ITサービスから個人のエンジニアまで、幅広くAWSが用いられています。

 

しかしながら、AWSを使い始めてしばらくすると何割かの人はこのような疑問をいだきます。
『思ったより料金が高い気がする』と。

 

本来コストの低さからAWSを選んだはずなのに、他社のパッケージングされた環境等と同等か、もしくはそれより高い金額が請求されているのです。

 

今回の記事では、そのような事態に陥ってしまった際に、ぜひ確認してほしい箇所についてご紹介します。
これらを確認することで、それまで異常に高くなっていたAWSのコストを、ぐっと下げることができるかもしれません。

 

なお、もちろんこれらは『今別に高くない』と思っている方にも有効な削減方法です。
AWSを使っているのであれば、ぜひ確認してみてください。

 

ELB（ロードバランサ）の削除

ELBとは『Elastic Load Balancing』の頭文字です。もっぱらロードバランサと呼ばれています。
ロードバランサには『ALB（Aplication Load Balancer）』や『NLB
（Network Load Balancer）』といった種類がいくつかありますが、それらの総称がELBという訳です。

 

さて、ご存知ない方のために説明しておくと、この『ロードバランサ』という機能は、負荷が高くなった際効果を発揮するすばらしい機能です。
本来、サーバは自身のキャパシティ以上の処理を行えません。なので、昔はウェブサイト等に想定以上のアクセスが殺到した場合、サーバが処理を行えなくなり、エンジニアが必死に復旧作業を行う、といった光景も見られました。


しかしロードバランスがサーバについているなら、問題はありません。
サーバやネットワークが処理できるよう負荷を分散し、決してサービスが途切れないようにしてくれます。
AWSについているロードバランサは更に多機能で、サーバのヘルスチェックや、障害対応時に別のサーバに振り分けたり等、更に便利な機能も付属しています。

 

……とはいいつつ、その機能はあなたのAWSに必要でしょうか？
もちろん、WEBサービス等をAWS上で運用しており、何かの拍子にバズっても対応できるようにするなら必要でしょう。
しかし、例えば社内のデータ共有や、業務管理ツール、バックアップ等であれば、急激にアクセスが増えることはほぼないでしょう。

 

もしくは企業の公式サイト等を運用していたとしても、最悪サーバ負荷が高まり500エラーが出たところで業務上の影響がないのであれば、わざわざELBを常時稼働させておく必要はありません。

 

なおELBは、負荷が高まらずともついているだけで料金が発生します。
執筆時点の料金設定では、Application Load Balancer 時間（または 1 時間未満）あたり、0.0243USD、LCU 時間（または 1 時間未満）あたり、0.008USDとなっています。

 

それだけ聞くと大した事がないように聞こえるかもしれませんが、ELBの一つ、ALBを一ヶ月つけっぱなしにした場合、18ドル（2,600円）程の費用がかかってしまいます。
更にNLBやCLBまでつけっぱなしにしていたら……それだけで１万円近く行きますね。

 

ちなみにELBでよくありがちなのが『永遠に無料枠がある』という勘違いです。
条件によりますが、基本ELBの無料枠は１年間しかありませんし、１年以内でも２台目には反映されません。
なので、気づいたら先に挙げたような料金が請求され続けている……といった事態がないよう、心当たりのある方は今すぐELBの設定を確認しましょう。

 

 

NATゲートウェイの削除

次に確認してほしいのは『NATゲートウェイ』です。

 

基本プライベートサブネットを利用するとしても、中で使っているシステムやツールのアップデートを行う場合は、外部に接続する必要があります。
その際NATゲートウェイという『仲介役』を通してアクセスを行うことで、安全にデータのやり取りを行える……という訳です。

 

しかし、これも『必要ないのに利用している』ケースがとても多い機能です。

 

ケースとしては以下のようなものがあげられます。
例えば『そもそもプライベートサブネットを利用する必要がないケース』です。一時的な処理を行うだけで、内部にセキュアな情報を保持していないシステムに対して、わざわざプライベートサブネットを使う必要はないでしょう。パブリックサブネットと通常のファイアウォールで十分です。

 

また『NATゲートウェイをわざわざ使わなくていいケース』もあります。
一時的に実験として作る環境や、完全に閉じた状態で使って構わないシステム等です。
NATゲートウェイはあくまで外部とのやり取りをセキュアにするための仲介者なので、そのやり取り自体が存在しないのであれば、NATゲートウェイも必要ありません。

 

そして一番無駄なのは、『AWS上にあるサービスとのやり取りにNATゲートウェイを経由しているケース』です。
自身が管理しているS3やDB等とのやり取りに、わざわざNATゲートウェイを通してしまっていては、非常に無駄な費用がかかってしまいます。
この場合はInternet GatewayやVPC Endpoint経由で接続を行ってください。

 

なお、NATゲートウェイは起動しているだけでも、月々数千円のコストが発生します。
更に、先程挙げたような『無駄なデータ転送』をおこなっている場合は、もっと利用料が膨らんでしまっているでしょう。
こちらの設定も必ず見直してみてください。

 

 

パブリック公開のIPv4確認

ネットワーク関連について詳しい方なら、IPv4が枯渇し始めていることはご存知でしょう。
43億通りしかないIPv4は年々希少価値が高まっており、あらゆるサービスで取得費用の値上げや有料化が進められています。

 

AWSも例外ではありません。2024年2月よりIPv4アドレスに対して課金が行われることが、先日発表されました。

 

AWS Public IPv4 Address Charge + Public IP Insights

 

なので現時点（執筆時点）ではまだ有料にはなっていませんが、来年以降は1年あたり約6,000円ほどのコストが、IPv4に対して掛かる予定です。

 

なおIPv4の希少価値は今後更に高まっていく一方かと思われますので、この約6,000円という金額も、それに比例して高くなることが予想されます。
特に大きな理由がなければ、ぜひ今のうちにIPv6体制への移行等を進めてください。

 

 

EC2やRDSの不要なインスタンスを削除

そして最も無駄な費用がかかってしまいやすい例が、この『不要なインスタンス』です。

 

たとえば勉強用に作ったEC2のインスタンスを、単に停止だけして放置していませんか？
といってもEC2自体は、停止状態でお金はかかりません。
しかし、それは停止状態のEC2インスタンスにお金が掛からないだけであり、インスタンスにアタッチされたEBS・Elastic IP等の料金は掛かります。

 

また、同じくRDS（Amazon Relational Database Service）を使った場合も悲劇が起こりやすいです。
RDSを勉強等のために一時的に使い、用が済んだからと停止したとしましょう。
実はRDSは7日間しか停止ができません。7日経ったRDSがどうなるかと言えば、自動で起動し、課金が継続されるのです。

 

なのでクレジットの明細をあまり見ない場合、まったく使っていないAWSのサービスに延々とお金を払い続けている人もいるでしょう。

 

そのような事態を避けるためにも、不要なインスタンスは必ず削除してください。
なお、『また使うかもしれない』『年に１回程度使う』ようなインスタンスは、AMI（Amazonマシンイメージ）を使って、スナップショットを取っておきましょう。
ただし、ややこしいことにこれも無料ではありませんので、どの方式が一番料金が掛からないか、比較検討する必要があります。

 

EC2やRDSなどのインスタンスタイプを見直す

EC2やRDS、EBS・S3等のインスタンスを継続して利用している場合、定期的にインスタンスタイプの見直しを行いましょう。

 

というのも、AWSは常に最適化が図られています。
なので昔選んだインスタンスを新しいものと交換するだけでも、コストが下がった……ということが有り得るのです。

 

また、最初に選んだインスタンスが、実際の稼働率と見合っていないこともあります。
オーバースペックなまま利用してしまった場合、余計なコストを払い続けることになるのです。
それを避けるためには、AWS内の『Cost Explorer』を確認してみましょう。『サイズ最適化に関する推奨事項』という欄を見れば、もっと最適なスペックが提案されているかもしれません。

 

更には、『最初からインスタンスを多く借りるのではなく、Auto Scalingを使って不可が増大したときだけ増やす』
『サーバを利用しない時間帯は、インスタンスが停止するようInstance Schedulerで設定する』といったテクニックもあります。

 

長年稼働しているシステムならば下手に触りたくないかもしれませんが、場合によってはかなりのコストダウンを見込むことができますので、今一度そのインスタンスタイプが適切かどうか、見直してみてください。

 

バッチなどはLambda等のサーバレスを利用

Lambdaは、AWSが提供するサーバレスのクラウドサービスです。

 

単にバッチ処理を行うだけならば、わざわざLambdaを使わずとも、EC2インスタンス上で実行させることができますが、それでもLambdaのほうが遥かに優れていると言えます。

 

例えば毎日深夜に、大量のデータ行を処理するバッチジョブがあるとしましょう。
もちろんこれをEC2にやらせることもできますが、それではバッチ処理をしていない時間帯のインスタンス料金は、ほぼ無駄な状態です。

 

一方で、Lambdaは関数が実行されている間だけ起動され、その他の時間帯では料金がかかりません。

 

なので特定の時間だけ稼働させたり、特定のトリガーが発生した場合のみ稼働するような処理については、Lambda等のサーバレスシステムに任せたほうが圧倒的にコストが安いのです。

 

他にもスケーリングを自動で行ってくれる、並列処理が容易といったメリットがあります。
この点は別記事で詳しく書いていますので、ぜひそちらも御覧ください。

 

S3 Intelligent-Tieringでストレージの費用を最適化する

オンラインストレージ部分もコスト削減が可能です。

 

AmazonS3はただのストレージではなく、いくつかの層に分かれています。

引用元(PDF)

上記の図、左から二番目にある『S3 Standard』、こちらが標準のS3です。
ではその右に並んでいるものは何かというと、そこまで頻繁にアクセスを行わないデータを格納する、アーカイブ用のストレージです。

 

これらのストレージは取り出すのに料金が掛かります。さらに、『Glacier Flexible Retrieval』と『Glacier Deep Archive』に至っては、データを取り出すまでに数分～48時間もの時間がかかる始末です。

 

それだけなら右側のストレージを使う意味はないように思えるかもしれませんが、これらのストレージは圧倒的にコストが低く設定されています。
なんと『標準のS3』と『Deep Archive』を比較した場合、GBあたりの月額費用は12倍もの差があるのです。

 

なのでデータを上手く分別して、アクセス頻度の低いデータは安いストレージへ移しましょう……と言いたい所ですが、それは難しいでしょう。
そもそもどのファイルのアクセス頻度が低く、アーカイブしていいものなのか、優先順位をつけて、アーカイブを移動して……というのは、あまりに退屈で面倒くさい作業でしょう。

 

そこでそういった作業を自動で行ってくれるのが、『Intelligent-Tiering』という訳です。

 

もちろん、これらの設定はファイルごとに手動で指定する事もできます。なので日頃まったく使わないが、緊急時は瞬時に必要となるデータは、S3標準ストレージに固定配置することも可能です。
更には、機能を有効にしたまま『ディープアーカイブアクセス階層』だけは使わない、といった設定もできます。それならば、全てのデータはいつでもミリ秒単位でアクセスすることができるため、不安なく安いストレージを利用できるでしょう。

 

定期バックアップファイルや、古いデータベースファイル等、めったに取り出さないデータのためにコストを支払い続ける必要はありません。
ぜひ『Intelligent-Tiering』も正しく活用し、ストレージ費用を削減してみましょう。

 

『コスト配分タグ』をつけて、プロジェクト別に幾ら掛かっているのかを把握する

そして、これは直接的なコスト削減方法ではないのですが、コスト管理をする上でとても大切な要素を最後にご紹介します。

 

AWSには各リソースに対して『タグ』を付けることができます。
タグにはいくつか種類があって、リソース整理やアクセス配分に使ったりするのですが、それをコスト配分に利用することも出来るのです。

 

細かいタグの付け方は公式のガイドを見ていただきたいのですが、これらの設定を正しく行うことにより、同じ機能を利用していても、プロジェクトや担当者ごとに料金を可視化することができ、非常にコスト管理がやりやすくなるのです。

 

例えば、とあるWEBサービスの本番環境とテスト環境を、AWS上に構築したとしましょう。
いざサービスをローンチして、AWSの費用が膨らんできました。
この時タグがついていなければ、『結構掛かるんだな』という感想だけで、何も異常を感じないかもしれません。
しかし、本番環境とテスト環境それぞれに『コスト配分タグ』をつけており、その２つの料金がほぼ同一金額だったらどうでしょうか。
まず間違いなく、テスト環境の方で誤った設定がなされているでしょう。

 

それ以外にも、例えば『すでに終了したはずのプロジェクトに、料金が発生し続けている』とか、『さほど大きなシステムに携わっていないはずの担当者が、なぜか一番料金を使っている』、もしくは『このプロジェクトは費用対効果が合っていない』等、
タグをつけておくだけで、コスト管理のトラブルや重要な点に、いち早く気付くことができます。

 

AWSは非常に便利で、柔軟で多機能なサービスですが、その分複雑で分かりにくく、ときに莫大なコストが瞬時に掛かってしまうような恐ろしさも秘めています。
だからこそ、日頃から徹底的にコスト管理を行い、『無駄な費用を支払っていないか』『もっと削減できる箇所があるのではないか』という点を意識して運用を行いましょう。

 

お問合せ＆各種リンク

お問合せ：GoogleForm

ホームページ：https://libproc.com

運営会社：TodoONada株式会社

Twitter：https://twitter.com/Todoonada_corp

Instagram：https://www.instagram.com/todoonada_corp/

Youtube：https://www.youtube.com/@todoonada_corp/

Tiktok：https://www.tiktok.com/@todoonada_corp


presented by