こんにちは。2021 APN AWS Top Engineerのippeiです。

ギークフィードでは本番環境、開発環境、社内システム環境においてAWSアカウントを10個以上利用しています。

社内でAWSを本格的にメインクラウドとして利用し始めてから数年が経ち、終わったプロジェクト、継続しているプロジェクトのリソースが乱立しています。
また、AWS利用料全体のコストも年々上昇しています。

AWSは簡単に・早く・安く様々なサービスを利用することができますが、一方で「まだ使うかもしれないから・・・」といってリソースをそのままほったらかしにしてしまうことや、終了したプロジェクトのリソースが実はコストが発生していたということが多いです。

ひとつひとつのリソースは月額数ドルでも塵も積もれば山となりますし、うまく割引料金を適用できていないと利益率が大幅に落ちてしまいます。

月額10万円の売上をあげるより、無駄なリソースを10万円削るほうが簡単です。
そして、リソース管理とコスト最適化ができていないことは事業がスケールした際に非常に大きなリスクや損失となります。

今回私は社内の1エンジニアとして自発的にこの取り組みを行っています。
技術者には社内のコスト意識や自分のたてたリソースのコストへの視点というものを持ってもらいたいですし、マネージャー、営業にはインフラコストとリソース管理は継続的な見直しを行うことで原価と利益に大きく影響するという意識を持ってもらいたいです。

なんで今までできていなかったんだろうではなく、やろうと思ったときが初日です。

課題

ギークフィード内では以下のような課題がありました。

1. どれが必要でどれが不要なリソースなのかがわからない
2. 上記の原因として、誰が何のために作成したものかがわからない。誰が管理しているかもわからない
3. 無駄なリソースがおそらくたくさんあるだろうという管理職の共通認識
4. 定期的なリソースチェックは手間がかかってしんどいし、そもそも根本解決にならない

これまでの失敗談

今回のテコ入れを行うまでに以下のような施策を行いましたが定着しませんでした。

・AWS Budgetsでコストアラートを設定してみた！
→アラート更新ルールが形骸化して常時100%オーバーで誰も見ない状況になった?

・スプレッドシートでリソースとコストを見える化してみた！
→誰も見なくなった?
AWSリソースをLambda+Googleスプレッドシートで一括管理

・開発者の裁量に任せて請求がやばい時にだけ確認しよう！
→コストは右肩上がりに。請求明細だけをざっくり見ても明確におかしなコストはなさそう?

計画をたてる

ではゴールに向かってどのように進めていけば良いでしょうか。
現行環境のAWSリソースを変更するには組織内で承認が必要なことも多いと思います。
ですのでまずはどれくらい無駄が発生しているかを試算し、確認、承認を得てからリソースを触りましょう。

そして、重要なことは同じようなことが起こらないような仕組みを作ることです。
せっかくゴミ掃除をしたのに半年後にまたゴミだらけになったら悲しいので。

1. 現状のAWS利用状況を把握し、削減額を試算する　←いまここ
2. 無駄なコストが発生しているリソース、用途不明のリソースを担当者に確認する
3. リソースの変更
4. 無駄なコストが発生しないような仕組みを導入する　←後日~仕組み導入編~を書く予定です

Trusted Advisorを利用する

AWSサポートプランのビズネスプラン、エンタープライズプランを契約しているのであれば、まずはTrusted AdvisorでAWSが推奨する項目を見てみることをおすすめします。

以下のような感じでどれくらいコストが最適化できるかの金額と項目がひと目で分かります。

リザーブドインスタンスについては案件の都合で更新していないケースもあるので一概に問題だと言えるものではないですが、それ以外の活用できていないリソースについては見直しが必要そうだということがわかります。

この情報を頭に入れつつ、もっと細かいリソースを見ていきましょう。

サービス利用明細、AWSマネジメントコンソールとにらめっこをして削減コストを試算する

Trusted AdvisorではAWSから見た明らかにリークがありそうなところをピックアップしてくれます。
ですがあくまで第三者目線になるので、本当に要不要かを判断するのは社内の人間である必要があります。

AWS Cost Explorerや請求代行サービスの請求書と利用明細でどういったコストが発生しているのかをリストから見つけつつ、そのリソースが一体なんのリソースなのかをAWSマネジメントコンソール上で確認する作業を行います。

これは大変ですがやる価値ありです！集中すれば1日で終わります！
実際のシートは以下のようなものを作成しました。（データはマスクしてあります）

トップ３は下記でした。

1位 EC2

やはりEC2が一番コストが発生していました。

主な原因としては、

・利用していないインスタンスが立ち上げっぱなしになっている

・停止 or 終了しているEC2インスタンスのEBSボリュームが大量に残っている

・停止しているインスタンスへのElatic IPの紐付けが放置されている

・普段全く使っていないリージョンに用途不明のインスタンスが起動している

・Savings Plansを活用できていない

となります。インスタンスの起動状態はひと目見てすぐに分かるポイントですが、EBSやElasticIPは請求明細で見るとわかりやすいです。
また、普段利用していないリージョンにあるインスタンスは明細を見ないとほぼ確実に気づけません。

また、開発用アカウントであってもSavings Plansを利用することを強くおすすめします。
リザーブドインスタンスのように単一のインスタンスについてインスタンスタイプや期間のコミットメントができなくても、アカウント内でのEC2利用料金に対しての金額と期間のコミットメントがあれば良いので、複数のプロジェクトのインスタンスに対して割引を適用させることができます。

Savings Plansの何がすごいのか。リザーブドインスタンスとの違いは？

2位 RDS

RDSは停止をしても7日後に自動で起動されます。EC2と同じ感覚で停止をすると思わぬコストが発生するリスクとなります。

DBのスナップショットを作成、もしくはデータをダンプしてインスタンスの削除を行います。

一時的に Amazon RDS DB インスタンスを停止する

3位 VPC

社内インフラとしてAWSを利用している場合は無駄なコストが発生しているということは少ないと思いますが、ギークフィードは開発会社なのでVPNをはじめとしたネットワークの検証を行うことが多いです。

検証後のSite to Site VPNやTransit Gateway、ELBがそのまま放置されていると利用していないのに結構な金額になります。

その他サービスのポイント

DynamoDB

ほとんどリクエストがないテーブルなのにリザーブドキャパシティユニットが設定されている。
→オンデマンドキャパシティに変更する。

Kinesis Data Streams

利用していないストリームのシャードが課金されている。（1シャードでも比較的高い）
→ストリームを削除する。

Lightsail

停止状態のインスタンスがある。
→Lightsailは停止状態でも課金されるため、不要であればスナップショットを作成して削除するか、スナップショットをEC2へ移行してインスタンスを立ち上げ後、停止状態にする。

S3

適切なストーレジティアが設定されていない。
→利用頻度の低い大量のデータをStandardのストレージで管理することは不要なコストが発生している。S3 Intelligent-Tieringを設定する。

[アップデート] Amazon S3 Intelligent-Tiering がより使いやすくなりました（最小ストレージ期間 / 小さなオブジェクトの監視・オートメーションコストの撤廃）

Amazon Connect

インスタンスに利用していないDIDがある。
→電話番号を保有しているだけでコストが発生するのでリリースする。

開発環境でToll Freeナンバー（0120, 0800）を利用している
→社内利用であればDIDに統一して、発信通話料を手当で払ったほうが100%安いのでDIDに変える。

各リソースについて社内で確認をする

前項で無駄なコストが発生しているであろうリソースのリストとコスト試算を行ったので、おそらくこの人だろうという担当者に確認します。
担当者がわからないリソースについては、社内全体で確認をします。

1. 現状のAWS利用状況を把握し、削減額を試算する
2. 無駄なコストが発生しているリソース、用途不明のリソースを担当者に確認する　←いまここ
3. リソースの変更
4. 無駄なコストが発生しないような仕組みを導入する　←後日~仕組み導入編~を書く予定です

Slackでこんな感じで聞いてみましょう。

いろいろな回答があると思いますが、大分すると以下の3つです。

常に利用しているリソース

そのまま変更をしません。

もしくは、毎日日中にのみ利用するインスタンスなどであれば、時間外は停止するようにSystems Manager + Event Bridgeの設定を提案します。

EC2 インスタンスの起動と停止を自動化することは出来ますか？

必要なときだけ利用するリソース

EC2であれば停止や、上記のスケジュール起動設定を行ってコスト削減を提案します。

Kinesis Data StreamsやALBなど、停止ができないものについては設定情報を残しておいてリソースを削除します。

もう使わないリソース

EC2、RDSはスナップショットを作成の上で削除します。念の為のバックアップは大事！

スナップショットをとったEBSは削除します。

確認、承認が完了したらリソースを変更しましょう。
リソース担当者と一緒に作業をして、サービスの料金体系やどのようにすることでコスト改善するかやこれからの運用方針について話し合うことが重要です。

おわりに

今回は社内のAWSリソース管理とコスト削減について、私が実際に行ったことをブログとして書いています。

1. 現状のAWS利用状況を把握し、削減額を試算する
2. 無駄なコストが発生しているリソース、用途不明のリソースを担当者に確認する
3. リソースの変更　←ここまでやった
4. 無駄なコストが発生しないような仕組みを導入する　←後日~仕組み導入編~を書く予定です

ただしこれは暫定対応です。

この後何もしなければまた同じことが再発してしまうため、恒久的な対応を行う必要がありますし、どちらかと言えばそちらが本題です。

次回は無駄なコストを発生させず、リソースを管理できる仕組みの導入を行いますので、そちらもぜひ読んでみてください。

後編へ続く・・・。（後日アップします）

参考文献

• AWSのコストを削減する９の方法
• Savings Plansの何がすごいのか。リザーブドインスタンスとの違いは？
• 一時的に Amazon RDS DB インスタンスを停止する
• [アップデート] Amazon S3 Intelligent-Tiering がより使いやすくなりました（最小ストレージ期間 / 小さなオブジェクトの監視・オートメーションコストの撤廃）
• EC2 インスタンスの起動と停止を自動化することは出来ますか？

The following two tabs change content below.

• この記事を書いた人
• 最近の記事

西山 一平

ギークフィード8年生です。

西山 一平 (全て見る)

• TEAMをv1.1.1にアップデートしカスタムドメインを設定する - 2024-02-17
• コールセンター白書2023とAmazon Connect - 2023-12-25
• Provide dynamic and personalized CX with in-app web call for Amazon Connect - 2023-12-16
• 脱IAMユーザー！ IAM Identity CenterとTEAMでセキュアにAWSを利用する - 2023-12-06
• Amazon ConnectのWebRTC通話をWebアプリケーションに実装する - 2023-12-06