【ITニュース解説】The same account after cleanup: $9,800 a month

クラウドサービスの利用費を大幅に削減した事例について解説する。この事例では、毎月24,000ドルかかっていた利用費が、9,800ドルまで削減された。提供する製品やサービス、ユーザー数、機能は全く変わっていないにもかかわらず、これほどの削減が実現できたのは、主にクラウド環境の適切な管理と運用に「注意」を払った結果である。技術的な複雑さではなく、基本的な管理を徹底することで大きな効果が得られた点が重要だ。

まず、一貫した命名規則を徹底した。これは、クラウド環境で利用するサーバーやデータベース、ネットワークなどのリソースに、誰が見てもその役割がわかるような名前をつけるということだ。例えば、「サービス名-環境名-リージョン-目的」といったルールに従う。このように命名することで、リソースがどのサービスに属し、どの環境（開発用、本番用など）で使われ、どの地域（データセンターの場所）にあり、どのような目的で使われているのかが、名前を見ただけで一目でわかるようになる。これにより、管理者は大量のリソースの中から目的のリソースを素早く特定し、誤って操作するリスクを減らせる。結果的に、無駄なリソースの発生を防ぎ、運用の効率を高めることにもつながる。

次に、あらゆるリソースにタグ付けを行った。タグとは、リソースに自由に追加できるラベルのようなもので、例えば「チーム名」「サービス名」「環境」「コストセンター」「作成日」「所有者」といった情報を設定する。これらのタグを付けることで、誰がどのリソースを使っているのか、どのサービスがどのくらいの費用を使っているのかを、詳細に追跡できるようになる。請求ダッシュボードで、これらのタグを使ってチーム別、サービス別、環境別に利用状況と費用を可視化できるため、もしどこかの費用が急に増えた場合でも、すぐに原因となっているリソースや担当者を特定し、対応できる。これにより、無駄な出費を早期に発見し、対処することが可能になる。

アクティブなリージョンを二つに絞り込んだことも大きな削減要因だ。クラウドサービスは世界各地にデータセンター（リージョン）を持っているが、この事例では本番環境を「Us-east-1」に、災害時などに切り替えるための予備（フェイルオーバー）環境を「Us-west-2」に限定した。これ以外のリージョンで実験的に作成されたリソースや、過去に使われていたが現在は不要なリソースはすべて削除された。結果として、アクティブなリソースの総数は、運用開始時点から40パーセントも削減されたにもかかわらず、提供しているサービスの負荷（ワークロード）は変わっていない。これは、不必要な場所に作られたり、忘れ去られたりしていたリソースが大量にあったことを示している。利用するリージョンを限定することで、管理の複雑さを減らし、不要なリソースの発生を抑制できる。

さらに、孤立したリソースの削除を定期的に実施する仕組みを導入した。孤立したリソースとは、本来であれば他のリソースと組み合わせて使われるべきなのに、その関連付けがなくなってしまい、宙に浮いた状態になっているリソースのことだ。例えば、サーバーが削除されたのに、そのサーバーに紐付いていたストレージだけが残っていたり、使われていないIPアドレス、ターゲットが設定されていないロードバランサー、どのサーバーにも関連付けられていないセキュリティグループなどがこれにあたる。これらのリソースは、使われていなくても費用が発生し続けるため、無駄なコストになる。この事例では、四半期に一度、約2時間かけてアカウント内をスキャンし、このような孤立したリソースを自動的に検出し、削除するプロセスを確立した。これにより、無駄なリソースが蓄積される前に効率的に排除できるようになった。

ログの保持ポリシーを適切に設定したことも、コスト削減に大きく貢献した。クラウドサービスでは、アプリケーションの動作ログやインフラのログ、システムへのアクセス履歴（監査ログ）など、様々なログが記録される。これらのログはデバッグやトラブルシューティング、セキュリティ監査のために重要だが、無限に保存し続けるとストレージ費用がかさむ。この事例では、アプリケーションログは30日間、インフラログは90日間、監査ログは365日間といったように、種類ごとに必要な期間だけ保存するようにポリシーを設定した。また、本番環境のログレベルは、詳細すぎる「デバッグ」レベルではなく、必要な情報に絞った「情報（インフォ）」レベルに設定した。これにより、ログの量が大幅に削減され、その結果、ログ保存サービスの費用が75パーセントも削減された。

RDS（リレーショナルデータベースサービス）インスタンスのサイジングも最適化された。RDSはクラウド上で利用できるデータベースサービスで、サーバーの処理能力やメモリサイズなどをインスタンスタイプとして選ぶ。この事例では、実際のデータベースの利用状況に合わせて、適切なサイズに調整した。過剰なスペックのインスタンスを選んでいた場合、それに見合った費用が発生してしまうため、実際の利用状況に合わせた適切なサイジングはコスト削減に直結する。また、データベースの自動バックアップの保存期間も、AWSのデフォルト設定ではなく、実際の復旧要件に合わせて短縮した。さらに、古い手動スナップショット（特定の時点のデータベースのコピー）も、不要であることを確認した上で削除された。これもストレージ費用を削減するための重要な施策だ。

最後に、リザーブドインスタンスとSavings Plansの活用だ。これらは、クラウドサービスプロバイダーが提供する、長期間の利用を約束することで割引を受けられる料金体系である。安定して稼働するサーバーやデータベースなど、継続的に利用する見込みのあるベースラインのワークロードに対しては、これらの割引プランを適用した。一方、急な需要変動に対応するために一時的に追加するような可変的なキャパシティ（容量）に対しては、必要な時に必要なだけ利用できる「オンデマンド」料金モデルを利用した。これにより、全体的な利用コストを抑えつつ、柔軟性も確保できるようになった。

これらの施策は、いずれも特別な技術や複雑なシステムを導入したわけではない。日々の運用において、「注意深く監視し、無駄を見つけ出し、改善していく」という基本的な管理プロセスを徹底した結果である。最初の状態は、誰もクラウド環境をきちんと見ていなかったために、無駄なコストが積み重なっていた状態であり、二番目の状態は、誰かが責任を持って監視し、管理することで、効率的で無駄のない状態に改善されたことを示している。システムエンジニアを目指す上では、このような運用管理の重要性を理解し、常にコスト意識を持ってシステムを設計・運用することが求められる。