登壇者の2人は、以下のサービスや手法を使ったコスト最適化について共有した。

「AWS CloudTrail」

　AWS CloudTrail（以下、CloudTrail）は、AWSアカウント内での設定変更履歴や、管理イベントの記録を提供するログ監視サービスだ。「Trail」（証跡）は、ログの収集単位を指す。CloudTrailには無料プランが用意されているが、以下に注意が必要だ。

• 2つ目以降のTrailを作成、運用するごとに料金が発生する。
• CloudTrailのイベントをSQLクエリで高速で分析できるツール「CloudTrail Lake」も有料だ。CloudTrail Lakeを、どのログを収集しているか整理しないまま使っていた場合、同一のログを何重にも保存して課金される恐れがある。

対策は？

• 組織に存在するAWSアカウントにひも付くCloudTrailの数とCloudTrail Lakeの使用実態を棚卸しする。
• 不要なCloudTrailを各アカウントから削除する。
• アカウント管理サービス「AWS Organizations」の管理アカウントで作成し、組織内全アカウントのイベントを一元記録するOrganization Trailに統合する。

「Amazon Elastic Block Store」

　AWSのブロックストレージサービスAmazon Elastic Block Store（以下、Amazon EBS）は、同社の仮想マシンサービス「Amazon Elastic Compute Cloud」（EC2）のインスタンス1台に1対1で接続して使う。Amazon EBSのボリューム（ストレージの論理的な保存領域）がEC2のインスタンスと接続していなくても、存在するだけで課金される。

対策は？

• EC2のインスタンスと接続していない（未アタッチ）状態のAmazon EBSを洗い出す。
• 重要なデータが格納されている場合、スナップショット（ファイルやストレージのある時点の状態を記録したもの）を取得する。
• それ以外は削除する。これにより、「保険として残していたAmazon EBS」が課金され続けないようにできる。

不要なネットワーク

　この目的は、通信経路を作り過ぎていないか確認することにある。

ロードバランサー

　AWSのロードバランサー（負荷分散装置）「Elastic Load Balancing」（ELB）は、「スキーム設定」で、インターネットからアクセス可能であることを意味する「Internet-facing」という設定を選択できる。インターネットからアクセス可能な、“PublicなELB”には、時間当たりの基本料金などの利用料だけでなく、「IPv4」アドレスの利用料も発生する。つまり、PublicなELBを立てることと、パブリックIPv4アドレス利用料の二重課金構造になる。

ネットワークアドレス変換（NAT）ゲートウェイ

　NATゲートウェイは、仮想ネットワーク内部での通信が可能なサブネット（IPアドレスの範囲）である「プライベートサブネット」と、インターネットの間に制限付きの一方向接続を構築する。このゲートウェイの問題は、起動中に毎時課金されることだ。

「AWS Transit Gateway」

　AWS Transit Gateway（以下、TGW）は、AWS内の論理的な隔離ネットワーク「Amazon Virtual Private Cloud」（Amazon VPC）と、オンプレミスのネットワークを接続するハブとなるサービスだ。「実験的に構築したTGWを本番移行し忘れたままにした」「複数のTGWを作成し、経路が重複した」といった場合も、利用時間で料金が発生する。

対策は？

• 使われていないロードバランサー
• 役目を終えたNATゲートウェイ
• 不要なTransitGW

を一括棚卸し、削除する。

Right-sizing

　「性能に対してインスタンスが大きすぎないか？」と疑問を持つことが出発点になる。例えば、

• CPUの使用率は5％なのに、m6i.4xlarge
• メモリも全然使っていない

といった場面だ。

　m6i.4xlargeは、EC2の汎用インスタンス（M6iファミリー）の「4xlargeサイズ」で、第3世代インテルXeonスケーラブルプロセッサを搭載した高性能サーバだ。m6i.4xlargeは以下のスペックを備える。

• 仮想CPU（vCPU）
  • 16コア（32スレッド）
• メモリ
  • 64GB

　m6i.4xlargeは大容量インスタンスであるにもかかわらず、CPUの使用率が平均5％という状態は、実使用率が極端に低い状態を指す。この状態はRight-sizing（適切なサイズ設定）を実施し、コストを削減できる可能性がある。

対策は？

• 「AWS Compute Optimizer」
  • AWSの各クラウドサービスのコスト削減を支援するツール
• 「Cost Optimization Hub」
  • AWSのコスト最適化ツール

を使用する。

• 過剰なサイズになっているEC2を小さくする。

Graviton

　サーバプロセッサを「Intelのままで放置していないか？」と立ち止まって考えるのがポイントだ。例えば、x86系プロセッサを搭載したサーバ（x86サーバ）を使い続けているのであれば、Armが設計した64bitのプロセッサアーキテクチャ「ARM64」を基盤とするサーバプロセッサ「Graviton」に変えるだけで以下のメリットを享受できるという。

• 価格の安さ
• 性能

対策は？

• EC2
• リレーショナルデータベース管理システム（RDBMS）の「Amazon Relational Database Service」（Amazon RDS）
• 「AWS Lambda」（サーバレスコンピューティングツール）

を以下のインスタンスタイプに置き換える。

• m6g
  • Graviton、Graviton 2を採用したインスタンスタイプ
• c7g
  • Graviton3を採用したインスタンスタイプ
• t4g
  • Graviton 2を採用したインスタンスタイプ

Amazon S3／EBSストレージ

• 何年も前のログ
• 二度と見ない検証データ

があった場合、「捨てられるデータを捨てているか？」という考え方を持つことが肝要だ。そこで、

• 不要な「Amazon Simple Storage Service」（Amazon S3）のデータを削除する。
• 必要だが低頻度なデータは「Amazon S3 Glacier」やAmazon S3の自動階層化機能「Intelligent-Tiering」へ移行する。

　登壇者の2人は他にもさまざまなコスト最適化手法を紹介している。