お金が漏れやすい AWS のサービスと設定 — 常設の点検リスト

前回が「急に跳ねた」料金の犯人探しだったとすれば、今回は反対側です。グラフに階段を作らず、ベースラインを静かに押し上げる無駄の数々です。急増は目立つので気づけますが、こちらは「もともとこのくらいだった気がする」という感覚の裏に隠れて、数か月、数年と続きます。四半期に一度見直す点検リストとして整理しました。金額は us-east-1 基準で、リージョンごとに異なります。

ストレージ — 最も確実で、最も放置される場所 #

gp2 ボリュームの残存 — gp3 は gp2 より GB あたり約 20% 安く(約 $0.08 vs $0.10/GB・月)、基本性能(3,000 IOPS、125MiB/s)がサイズと無関係に保証されます。gp2 から gp3 への変更は Elastic Volumes で無停止のオンラインでできるので、残しておく理由が事実上ありません。コンソールや CLI でボリュームタイプのフィルタで gp2 を並べて一括変換します。gp3 と io2 の選択基準は別の記事で扱います。

孤児ボリュームとスナップショット — インスタンス終了時に「delete on termination」が無効だったボリュームが available 状態で残って課金されます。スナップショットは前回の #3 で扱ったとおり、ライフサイクルポリシーが答えです。

S3 ストレージクラスの未活用 — アクセスパターンが不確実なバケットは Intelligent-Tiering へ移すだけで自動の節約が始まります(モニタリング費用はオブジェクトあたり少額)。ログやバックアップのようにアクセスがまれなデータが Standard のままなら、ライフサイクルルールで Standard-IA や Glacier 系へ移します。ただし最低保持期間(IA 30 日、Glacier 90 日など)と取り出し費用があるので、頻繁に取り出すデータは移しません。

ネットワーク — 構造が作った固定費 #

パブリック IPv4 アドレス — アドレスあたり月約 $3.6 が使用の有無と無関係に出ていきます。未接続の Elastic IP は即座に解放し、インスタンスごとにパブリック IP を付けていた習慣は NAT やロードバランサーの後ろへ整理します。Public IP Insights でアカウント全体のアドレス数を見られます。アドレスが数十個あれば、それだけで月数百ドルです。

NAT Gateway の常時経由 — 前回は急増の原因として扱いましたが、急増でなくても構造的な固定費になります。S3・DynamoDB のゲートウェイエンドポイントは無料なのに使っていないアカウントが多いのです。プライベートサブネットから AWS サービスへ向かうトラフィックがあるなら、まずエンドポイントを確認します。開発 VPC なら NAT Gateway そのもの(月約 $33 + 処理量)をなくして、パブリックサブネット構成や NAT インスタンスで代替する選択肢もあります。

放置されたロードバランサー — ALB はトラフィックが 0 でも時間料金だけで月 $16 以上かかります。実験の残りの ALB、サービスを畳んだのに残った ALB を、ターゲットグループの healthy ターゲット数 0 を基準に探して整理します。

コンピューティング — 単価と稼働時間の両方 #

旧世代インスタンス — 同じスペックでも新世代のほうがおおむね安くて速いのです。m4 や m5 をそのまま使っているなら、m7g・m8g(Graviton)や m7i 系への交換が単価と性能を同時に改善します。Graviton への移行は次の記事でチェックリストとして扱います。

RI・Savings Plans 未適用のオンデマンド — 1 年以上確実に動き続けるベースライン容量がオンデマンドで動いているなら、Compute Savings Plans を掛けるだけでその部分から数十パーセント下がります。Cost Explorer の推奨(Recommendations)がアカウントの実使用に基づいてコミット規模を提案してくれるので、勘で決める必要はありません。料金モデルの比較は SAA Domain 4-1 で扱いました。

開発環境の 24 時間稼働 — 平日 9〜19 時しか使わない環境をつけっぱなしにすると、時間の 70% を捨てている計算です。Instance Scheduler や簡単な Lambda + EventBridge で夜間・週末の停止を自動化します。RDS も開発環境なら停止の対象です(7 日後に自動で再起動される制約は、スケジューラーで再度停止させる方式で回避します)。

開発環境の Multi-AZ と過剰スペック — 本番のテンプレートをコピーして作った開発 RDS が、Multi-AZ・プロビジョンド IOPS までそのままというケースが多くあります。開発環境はシングル AZ、バースト型インスタンス、gp3 で十分な場合がほとんどです。

可観測性・ログ — デフォルトが無駄な場所 #

CloudWatch Logs の無期限保持 — ロググループの保持期間のデフォルトが「無期限」です。取り込み費用(前回の #2)とは別に、保存費用が際限なく膨らみ続けます。全ロググループに保持期間(例: 30〜90 日)を一括設定し、長期保管が必要なものだけ S3 へエクスポートして Glacier へ移します。S3 の保存は CloudWatch Logs の保存より GB あたり数倍安いのです。

高カーディナリティのカスタム指標と過剰なダッシュボード — 指標あたり月 $0.30 は小さく見えますが、インスタンス別 × 項目別に掛け算されると大きくなります。誰も見ないダッシュボード、鳴らないアラームに付いた指標を四半期ごとに整理します。

点検ルーティンを作る #

このリストの項目は、一度直せば終わるもの(gp2 変換、保持期間の設定)と、戻ってくるもの(孤児リソース、開発環境のスペック)に分かれます。後者のために次の二つをおすすめします。

• Trusted Advisor / Compute Optimizer — 未使用リソースとダウンサイジングの推奨を自動で出してくれます。四半期点検の出発点にします。
• タグによる所有者の指定 — リソースごとにチーム・環境タグを強制すれば、「誰のものか分からなくて消せない」リソースがなくなります。消せないリソースが無駄の最終形です。

まとめ #

• ベースラインの無駄は急増と違ってグラフに見えません。四半期 1 回の点検ルーティンでだけ見つかります。
• ストレージから見ます。gp2 → gp3 の変換は無停止で即約 20% の削減なので、最も手軽に得られる削減です。
• パブリック IPv4、放置 ALB、NAT の常時経由は、トラフィックと無関係に出ていく構造的な固定費です。
• 確実なベースライン容量には Savings Plans を、開発環境にはスケジュール停止を掛けます。
• CloudWatch Logs の保持期間はデフォルトが無期限です。全ロググループに期間を設定することから始めます。