AWS のコスト最適化の進め方について

多くのシステム運用担当者や管理者は、クラウド（特に AWS）のコストや最適な設定に関する不安や課題を持っています。AWS の従量課金制は、使用するリソースに応じてコストが発生するため、適切に管理しないと予想外の高コストにつながりがちです。また、為替の変動もコスト増の大きな原因となっています。

本ブログでは、AWS 環境の見直し、課題の特定、改善の進め方といったクラウドのコスト削減とパフォーマンス向上を目的とした運用最適化の方法をご紹介します。これにより、持続可能な最適な情報システム環境の維持を目指します。

改めてオンプレミスと AWS で発生するコストの違いの整理から

まず発生するコストの捉え方を再確認する意味も含めて、オンプレミスとクラウドサービスにおける各種費用の違いについて改めて整理しておきます。

初期費用

オンプレミスは、導入初期の段階における投資として、自社で物理サーバーや関連する周辺装置などを用意する必要があり、また人手による設計や構築費用など多額の費用が発生します。

一方、AWS（クラウド環境）は従量課金制となっており、初期投資を低く抑えることができます。

ランニングコスト

オンプレミスの場合には、サーバーや周辺装置を起動、維持運用するための電力、運用には保守を行う際のいわゆる人件費など様々な費用が発生します。

一方、AWS の運用費用は、サービスを利用した分の費用のみが発生することとなり、その利用用途に応じて費用が変動するため、オンプレミスで発生するような名目は発生しない料金形態となっています。

そのため、この料金形態にメリットを感じてクラウド移行を検討される方も多く存在します。

AWS が考えるコスト最適化 7つのポイント

AWS 公式サイトの記事に、コスト最適化を考えるときのヒントを見つけました。

以下の図は、「AWS でのコスト最適化の進め方」というタイトルで連載されている記事の第 1 回「7つのポイントとコスト最適化に活用できる新ツールとは？」からの引用です。

Category	No.	Law	概要
Design	法則 I	Make Cost a Non-functional Requirement.	コストも非機能要件のうちの一つとして考えよう !
	法則 II	Systems that Last Align Cost to Business.	コストはビジネスと整合性が取れていないといけない !
	法則 III	Architecting is a Series of Trade-offs.	設計はトレードオフの連続である !
Measure	法則 IV	Unobserved Systems Lead to Unknown Costs.	監視されていないシステムは使途不明金につながる !
	法則 V	Cost Aware Architectures Implement Cost Controls.	コストが分かる仕組みだけでなくビジネス側がコストをコントロールする仕組みが必要 !
Optimize	法則 VI	Cost Optimization is Incremental.	コスト最適化は段階的な取り組み。 継続的な取り組みが重要 !
	法則 VII	Unchallenged Success Leads to Assumptions.	挑戦なき成功は思い込みにつながる。 「いつもこういう風にやっている」は危険 !

引用元：  AWS でのコスト最適化の進め方 第 1 回 ~ 7 つのポイントとコスト最適化に活用できる新ツールとは ? ~

昨年開催された AWS re:Invent 2023 のキーノートで Amazon.com の VP および CTO の Werner Vogels が「Frugal Atchitect」について語っていて、その中で 設計者がどのようにコストを意識するべきかの7つのポイント を説明しています。

この7つの法則として整理されている内容でとくに興味深いのは、法則Ⅳに記載されている「監視されていないシステムは使途不明金につながる！」と、法則Ⅵの「コスト最適化は段階的な取り組み。継続的な取り組みが重要！」です。

確かに、「監視されていないシステム」はどこでどのように利用されているのか？その実態が見えないため、コストを把握することができずに「使途不明金」扱いになってしまう、、という解釈は納得できます。この点を良くない言葉で捉えた場合、「監視していなければ利用実態が把握できないものが発生し、放っておくと勝手に増えてしまう」ような状況も起こり得ることになるため、注意が必要となります。

「コスト最適化は段階的な取り組み」についても上述と同様の解釈で捉えると、「一旦整理したものの、また時間の経過とともに同様もしくは別の要素での使途不明金が発生する」と捉えることができ、注意が必要となります。

AWS コスト最適化の手法を７つのポイントで検証してみました

AWS のコスト最適化については IT ベンダーなどから様々な方法が数多く紹介されていますが、実際に対応方法を検討する際には「何が正しいか？」ではなく、「何から始めるか」が重要ではないかと考えます。

そこで、AWS の公式ページや IT ベンダーのホームページで紹介されているコスト最適化の手法が、先ほどの「7つのポイント」にどのように適合しているかを検証してみました。

【 AWS 公式ページで紹介されているコスト最適化の手法 】

• 必要な時にリソースをオンにし、不要な時にはオフにする。EC2 インスタンスの自動停止や、開発/テスト環境の夜間・休日シャットダウンなどで節約できます。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• 適切なインスタンスタイプを選択する。ワークロードに適したサイズのインスタンスを使うことで無駄なコストを削減できます。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• スポットインスタンスの活用。オンデマンド価格に比べ最大90%割引で利用可能です。中断の可能性がある用途に適しています。

　→ 法則Ⅲ：設計はトレードオフの連続である！

• リザーブドインスタンスで長期利用コストを削減。1年または3年利用することで、オンデマンド価格に比べ大幅な割引が得られます。

　→ 法則Ⅲ：設計はトレードオフの連続である！

• データ転送料を最小限に抑える。同一リージョン内の転送は無料です。Direct Connect を使えば、オンプレミスとの専用接続でデータ転送コストを節約できます。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

【 IT ベンダーのホームページで紹介されているコスト最適化の手法 】

• 適切なインスタンスタイプの選択
  ワークロードに適したインスタンスタイプを選ぶことで、コストを最適化できます。
  使用率の低いインスタンスはダウンサイジングを検討しましょう。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• 予約インスタンスの活用
  1年または3年の期間で予約インスタンスを購入することで、大幅な割引を受けられます。
  長期的に安定した使用が見込めるインスタンスには予約インスタンスの利用を検討しましょう。

　→ 法則Ⅲ：設計はトレードオフの連続である！

• スポットインスタンスの利用
  オンデマンド価格と比べて大幅な割引価格で利用できるスポットインスタンス。
  一時的な処理や中断可能なバッチ処理などに適しています。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• 不要なリソースの削除
  使用していないEBSボリュームやスナップショット、EIPなどのリソースは削除しましょう。不要なリソースを放置するとコストがかさみます。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• データ転送料金の最適化
  同一リージョン内のデータ転送は無料です。
  大量のデータ転送が発生する場合は、同一リージョン内に収めることを検討しましょう。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

• タグ付けによる可視化
  すべてのリソースにタグ付けし、プロジェクトや部門ごとのコストを可視化。
  コストの無駄を発見しやすくなります。

　→ 法則Ⅱ：コストはビジネスと整合性が取れていないといけない！

以上の結果を通じて理解できたこととして、それぞれ各社で紹介されている削減方法を「AWS が考えるコスト最適化 7つのポイント」にあてはめてみると、概ね、「法則Ⅱ：コストはビジネスと整合性が取れていないといけない！」もしくは、「法則Ⅲ：設計はトレードオフの連続である！」ばかりにあてはまる内容となっています。この結果が示すのは、各社とも法則Ⅱ、Ⅲが属する分類としてのデザイン（設計）面を重視しているということかと思われます。

当然これらはどれも妥当で、できるかぎり実施するべき方策ばかりです。また各社における内容もほぼ同様の方法となっており、これは裏を返すとできること、やるべきことは大体決まっているかのようです。

ただ一方で、私はこれらが属さない、他のカテゴリーの方法にも目を向けるべきではないか？と思っています。例えば、「法則Ⅳ：コストが分かる仕組みだけでなく、ビジネス側がコストをコントロールする仕組みが必要」であるとか、「法則Ⅶ：挑戦なき成功は思い込みにつながる。『いつもこういう風にやっている』は危険！」は、他の事柄にも通じる要素が大いにありますが、まさにクラウドサービスも日々進化や変化が著しいとされる世界にあり、思い込みが危険！というのはとても納得できる内容ですし、読者の方の中にも「ホントは実態としてはこうなんだけど、そう簡単にはいかないな」と思っておられる方も多く存在するのではないでしょうか。

私がオススメする AWS のコスト削減・最適化の方法

0．進め方「クラウドパフォーマンス最適化」

コスト削減やパフォーマンス最適化を目的として、社内の AWS 環境を点検し、最適な内容にアップグレードすることが可能です。その進め方として以下のステップをおすすめします。

> Step 1： 現状分析と評価

各企業の現行システム構成を深く理解するための詳細な分析を行います。このフェーズでは、使用中のインスタンスタイプ、ストレージ利用状況、ネットワークの構成、セキュリティ設定などを包括的に評価し、パフォーマンスとコストのバランスを精密に分析します。この評価により、過剰なリソース利用やコストの無駄が明らかになります。

> Step 2： 最適化戦略立案

現状分析を踏まえ、お客様特有のニーズと目標に合わせた最適化戦略を立案します。この戦略には、不要なリソースの削減、コスト効率の良いインスタンスへの移行、自動スケーリングの設定、リザーブドインスタンスやセービングスプランの利用などが含まれることがあります。また、運用効率の向上とセキュリティ強化のための推奨事項も提案します。最適化の目標は、コスト削減だけでなく、コストをコントロールする仕組みの検討やパフォーマンスの向上と運用管理の効率化にもあります。

> Step 3： 改善計画の実行

戦略立案後、具体的な改善計画に基づき、段階的な実行フェーズに移ります。このフェーズでは、提案された最適化アクションを計画に沿って実施し、変更管理プロセスを通じてリスクを最小限に抑えながら、効果的な移行を目指します。改善アクションには、インフラの再構築、リソースの再配置、パフォーマンスチューニング、セキュリ ティポリシーの更新などが含まれます。

> Step 4： 継続的な監視と評価

改善計画の実施後、当社では継続的な監視と評価を通じて、システムが最適化された状態を維持し、予期せぬ問題に迅速に対応できるよう支援します。このフェーズでは、パフォーマンス指標のモニタリング、コスト管理のための定期的なレビュー、セキュリティの監査と評価を行います。また、新たな最適化の機会を定期的に探し出し、お客様のビジネス成長と変化に合わせてインフラを進化させていきます。

1．Amazon EC2 のインスタンスタイプを見直す

「最初に選んだインスタンスタイプを長く使い続けている」という方も多いのではないでしょうか？

実際の運用状況に合わせて定期的に見直しを行うことで、現在利用中のインスタンスタイプよりも性能とコスト効率が良いものを利用することができます。

• 世代
  新しい世代のインスタンスが随時リリースされており、一般に、新しい世代ほど費用に対する性能費が高くなります。

• サイズ
  CPU の使用率が低い状態が続いている場合には、小さいサイズに変更することでコストの最適化を進めることができます。

• CPU
  同じインスタンスファミリーの中で、異なる CPU を選択することもできます。AWS Graviton プロセッサの利用が可能な場合は、大幅なコストパフォーマンスの向上も期待できます。

2．稼働時間を見直す

業務時間帯のみ利用するサーバーはスケジュールに合わせて停止することでコストの最適化につなげることができます。

例えば「非営業時間（週末、深夜時間帯等）に EC2 を停止する」という運用方法にした場合、EC2 の利用料はインスタンスタイプに対する時間単価と実際の稼働時間を掛け合わせて算出されるので、稼働時間を削減するとその分だけコストを下げることができます。

3．長期契約を活用する

Amazon EC2 では利用時間に応じた課金が行われるオンデマンドインスタンスの他にも、長期利用を想定した Savings Plans やリザーブドインスタンス (RI) といった購入方法があります。今までの運用から1年以上利用し続けることが確定しているインスタンスについては購入方法の見直しを行うことで大幅な値引きを受けられる可能性があります。

4．運用の最適化によるコスト削減もあり

各設定の自動化をうまく活用することで、運用コストの削減や障害の早期復旧などを実現することが期待できます。

＜例＞

• 物理ホストの障害を自動復旧 - Auto Recovery（インスタンスの復旧）
  AWS のシステム障害（電源問題や仮想サーバーホスト機の障害）発生検知から、EC2 の停止→起動による復旧までを自動化。
• 障害発生時の一次対応を自動化 - CloudWatch Alarm
  メトリクスの閾値に対してアクションの設定が可能。これをうまく利用すると障害の1次対応を自動化することもできます。
• 負荷対策の自動化 - Auto Scaling
  システムへのアクセス数や需要に合わせて台数を変化させることができます。負荷に応じてインスタンスの台数が増加するのでアクセス遅延を最低限に抑え、不要になれば台数が減るのでコストは最小限にすることが可能になります。
• EC2 起動/停止の自動化 - cloud link for AWS
  弊社で提供している cloud link のサービスでは、EC2 起動/停止を曜日毎に時間設定して自動で行う事ができます。
• EC2 バックアップの自動化 - cloud link for AWS
  弊社で提供している cloud link のサービスでは、EC2 バックアップを自動で行う事ができます。クロスリージョン対応で、取得する時間、曜日、世代数を管理することができるため、いざという時にも安心です。

運用を外部に委託するとこんなメリットが

AWS の運用を自社内で実施する、いわゆる内製化におけるメリットは、システムのブラックボックス化の防止、ナレッジ、ノウハウの蓄積、開発スピードの向上など様々あります。一方デメリットとしては、IT エンジニアの採用が困難、離職リスクが発生、IT 技術者の人件費の高騰などコスト面においても、またその他計り知れない課題もあります。

一方 AWS の運用を外部に委託した場合のメリットは概ねコストに反映されるものばかりです。

例えば、企業のサーバーを24時間365日監視するとなると、自社では24時間体制における要員登用のやりくりが発生し、仮に実現可能であっても対応要員コストが膨大になります。またシステム運用中の再起動時や様々な操作対応などにも特別な要員の配備が常に必要となるため、ここでも発生するコストが少なくありません。もとより要員育成のための教育費、あるところでは資格取得に応じた福利厚生制度の対応、他コストに関連することばかりが企業側には必要となります。

これを外部に委託した場合の例として、以下のような作業を依頼することができます。

※すべてのベンダーが一様に対応できるサービス内容ではありません。

• 企業のサーバーを24時間365日監視する。
• 障害発生時に復旧作業まで実施する。
• 障害発生時の対応に特別な手順が必要な場合は、あらかじめ決められた手順に従って復旧を試みる。
• 異常があれば、電話もしくはメールにて連絡がはいる。

その他、様々な要求に対応するよう依頼することができます。

このような運用を外部に委託することで、自社内要員にて作業にあたる人件費を大幅に削減することも可能です。またそれにより企業側はコスト削減だけでなく、本来実施すべき優先順位の高い業務に集中する事も可能となり、合理的な業務進行が実現できる体制を構築できます。

AWS のコスト最適化の進め方について（まとめ）

以上、AWS 運用におけるコスト削減、最適化に触れてみました。

単にコストを見直すと言っても利用費だけを見直すのではなく、業務遂行における整合性からの判断、実行する体制、また継続的実行を可能とする計画なども含めた検討がキーポイントと言えそうです。更には既に発生している IT 技術者の人材不足や更なる少子高齢化による将来継続的に発生すると見られる人材不足、それに伴う人件費の高騰など、社内の人材確保や人材登用の在り方においてもその対応方法を検討する必要があるともいえます。　

これから各企業がどのような対応を進めるのか、ますます注目していく必要がありそうです。私も常にその動向を追いかけていきたいと思います。

それでは皆様ご一読ありがとうございました。