こんにちは。技術本部 アーキテクチャ＆テクノロジー部の髙橋 洋樹です。AWSのコスト最適化をテーマに、複数回に渡ってご紹介している本ブログシリーズ。前回はコストの「可視化」方法をご紹介しました。まだお読みでない方は是非、こちらからご覧ください。
さて、今回と次回では、Ⅰ.可視化の次ステップとして「Ⅱ.最適化」の具体的な方法についてご紹介していきます。
可視化の結果、想定外のコストが発生していることが明らかになった場合、主に下記6つの対策方法を駆使しながら、対策を施していくことになります。
【6つの対策方法】
今回は、このうち前半3つ（1/2/3）について、私がやってしまうミスや、意外と知られていないかも、と感じる点なども交えながら解説していきます。
なお、本文中の価格情報については2024年1月時点の内容であり、今後変更になる可能性もございますのでお含みおきください。
従量課金を前提とするクラウドでは、利用されていないリソースを特定し削除するのが、最もシンプルで効果的なコスト削減手段です。削除対象のリソースかどうかを確認していくためには、タグ付けとモニタリングを活用しましょう。
まずタグ付けについてです。誰が管理しているか不明なリソースを勝手に削除することはできないですよね？管理者が不明な場合には、監査ログを引っ張り出し、作成者を特定することになりますが、リソース毎にそのような対応をしていては作業効率が非常に悪くなってしまいます。そのため、タグで管理者とリソースの使用用途を把握しておくことで「このテストプロジェクトはもう終了しているので、管理者のXさんに要否を確認しよう」と具体的なアクションに移すことができます。
次にモニタリングについては、利用されていないリソースを手動で特定していくのではなく、自動で特定できる環境を整えておくことが望ましいです。その方法は3rd PartyのSaaSの利用を含めて複数ありますが、AWSのサポートレベルがビジネスレベル以上の場合には、AWS Trusted Advisorの利用がおすすめです。例えば以下のようなリソースを自動で検出することが可能です。
ここで、私がたまにやってしまうミスを共有します。リソースが不要だと確認出来たら、必要に応じてバックアップを取得して削除となるわけですが、重要なのはバックアップの取得時にメタデータを控えておくことです。例えばRDSのスナップショットは復元時に紐づけているパラメーターグループが初期化されます。そのため、パラメーターグループを控えておかないと復元時に前と挙動が違って、削除後に困ることがあります。面倒な結果になりますのでご注意ください。
需要に応じてリソースを増減させるのも削除と同様に効果的な手段です。EC2インスタンスやRDSインスタンス、Redshiftクラスタなどは停止に対応しているため、使わない曜日や時間帯にリソースを停止するようにします。Amazon EC2とAmazon RDSは様々な自動停止の方法がネット上に存在しますが、個人的にはまずはAmazon EventBridgeスケジューラの利用を検討し、複雑なスケジューリングが必要であればAWS Instance Schedulerを利用するのが良いと思います。Amazon Redshiftはサービス自体にスケジューリングの仕組みを備えているので基本的にそれを利用するのがお勧めです。また、AutoScalingを利用している場合には、負荷に応じて適切にリソースが増減しているか確認し、問題があればスケーリングルールを調整します。
また、たまに知られていないかもと感じるのですが、EC2では停止のオプションとしてハイバネーションを選択できます。シャットダウン前にメモリの内容をディスクに書き出して、再開時に復元する機能です。そのため、休日を挟んで検証作業をそのまま再開したい場合などにはとても便利なので、私も利用しています。利用にあたってはルートボリュームの暗号化とハイバネーションの有効化が事前に必要となりますがよければ是非利用してみてください。
インスタンスで動かすワークロードに応じて、適切なインスタンス種別等を選択します。ご参考までに、最適化の観点を4つ共有します。
AWSにリソースをデプロイした当初は実際に必要なスペックよりも大きなスペックを持つインスタンスを選択しがちです。実際に観察した負荷の状況に基づいてインスタンスサイズやファミリーを選択しましょう。
AWSではCPUのラインナップとしてIntel、AMD、 ARM（Graviton）があります。特にARMはAWSがチップを自社開発していることもあり安価な傾向があります。OSやMWの互換性等の問題がなければ採用を検討するとよいでしょう。
m7*.largeの時間単価の比較（us-east-2）
基本的に最新世代の方が価格性能比も優れています。以下表はm7g.largeとm6g.largeの比較になります。CPUは変化がないように見えますがプロセッサがGraviton 2から全体的な性能が25％優れるGraviton 3に変わっており性能が向上しています。
m7g.large v.s. m6g.largeの比較（us-east-2）
横にスクロールできます
利用リージョンに制約がない場合、日本以外のリージョンを選択すると利用料を抑えられる可能性があります。米国のリージョンは他のリージョンと比較して新機能がいち早く利用可能になることからも検証用のリージョンとして一定の需要があります。
us-east-2 v.s. ap-northeast-1の時間単価の比較（m7g.large）
今回は6つあるAWSのコスト最適化方法のうち、前半3つを紹介しました。何かのご参考になれば幸いです。次回は、後半の3つについてご紹介できればと思います。コスト最適化の継続的な活動は、知見・経験やSEリソースの観点から、多くの企業で実行できていないと感じています。当社ではAWSのコスト可視化・削減サービスや運用サービスを提供しており、お客様のご利用環境やニーズに合わせてコスト最適化をご提案することが可能です。また、コスト以外にもAWSに関する包括的なソリューションを提供しているのでこちらも是非お気軽にご相談ください。ではまた、近いうちにお会いしましょう！
