こんなに安く なっちゃっていいの？ コスト最適化の進め方と、課金リスクの回避

2026/09/03【現地開催】JAWS-UG福岡 #28 秋のイベントシーズン開幕直前SP
https://jawsug-fukuoka.connpass.com/event/403544/

Transcript

1. こんなに安く なっちゃっていいの？ コスト最適化の進め方と、課金リスクの回避 2026.09.03 JAWS-UG福岡 #28 Kento Suzuki 秋のイベントシーズン開幕直前SP
2. SPEAKER 鈴木 健斗 東京 所属 コラボスタイル 経歴 新卒でクラウド系SIer。 構築・運用保守 → 提案 → プロマネ 今年6月に転職。今はCCoEとしてクラウド環境の改善 最近 Kiro Crew が面白い 花びらを降らすために AI でスライドを作ってみたけど、 スライドの個性がなくて面白くない AWS Community Builder (Cloud Operations) 元 Japan AWS Top Engineer 元 Japan All AWS Certifications Engineer
3. 本日の内容 01 前提は利用状況の可視化 02 コンピューティングの最適化 03 予算アラートと成果報告 04 AWS Config でコストが爆発する3つの要因
4. PA RT 1 コスト最適化の進め方
5. 01 前提 全体を可視化し、金額の大きい順に手を付ける アカウント・リソース別の費用（例） 本番 A / EC2 42% 本番 B / RDS 26% 検証 / EC2 その他 19件 上位2つで全体の約7割。ここに工数を寄せる。 まず全体をひとつの表で見る Organizations で請求を集約し、 アカウント × サービスで並べる。 12% 20% 金額順に優先順位をつける 削減額 ÷ 手間で並べ替え、上位から着手する。 片っ端から対応しない。 小さい費用は後回しでよい 数%の項目に工数を使うより、 上位を1つ動かすほうが効く。
6. 02 コンピューティング 削減は「減らす → 止める → 買う」の順 STEP 1 STEP 2 STEP 3 インスタンスタイプの最適化 未使用時間帯の停止 RI / Savings Plans の適用 Compute Optimizer の推奨でサイズを 開発・検証環境は夜間と週末を停止。 最後に、残った定常稼働分だけを 合わせ、世代を上げる。 稼働を平日日中だけにするだけで コミットで買う。 過剰スペックを先に削る。 効果が大きい。 順番を逆にすると縛りが残る。
7. 03 予算アラート 下げた状態を維持する 仕組みを置く 50% 月中の進捗確認 80% 担当者へ通知・原因調査 AWS Budgets で月次予算と実績・予測の両方に アラートを設定する。 増加は必ず気づけるようにしておく。 100% 予測超過でエスカレーション
8. PA RT 2 AWS Config で コストが爆発する3つの要因 記録範囲、ルール評価、記録モード。どれも既定値のまま進めると効いてくる。
9. 前提 リソースに変更が1件 課金の単位は CI の件数 ↓ AWS Config は「リソースの変更を記録する番人」。 変化が起きるたびに Configuration Item（CI）が1件生成され、 その件数に比例して料金が発生する。 CI が増えすぎること ＝ コスト増大。 CI が生成される ↓ CI 件数 × 単価 増幅要因が掛け算で乗る構造になっている。
10. 要因 1 / 記録範囲 AllSupported で全部を記録している グローバルリソースの重複 高頻度変更リソース IAM はグローバル。 AWS::SSM::ManagedInstanceInventory のような 複数リージョンで有効化していると、 変化の激しいタイプも漏れなく記録され、 変更1件で有効化した全リージョン分の CI が生成される。 静かに積み上がる。 対策 記録スコープを EXCLUSION_BY_RESOURCE_TYPES に切り替え、 高頻度変更リソースとグローバルリソースの重複記録を明示的に除外する。
11. 要因 2 / ルール評価 1変更が「1 ＋ ルール数」倍に増幅される 仮に 20アカウント × 全リージョン（17）で有効化すると 変更1件 → 3,740 件の CI 1 ＋ ルール数 倍 リソース変更の CI ×1 ＋ ルール評価の CI ×（そのリソースに効くルール数）。 11倍（ルール10本）× 20アカウント × 17リージョン。 乗数はアカウント数とリージョン数の分だけ膨らむ。 コンプライアンス対応でルールを大量追加したタイミングで、 請求が跳ね上がる事故が起きやすい。 例：ルールが10本紐づいていれば、 変更1件で CI 11件。 対策 組織ルールやコンフォーマンスパックの追加前に、 変更頻度 × ルール数 × アカウント数 × リージョン数で試算する。
12. 要因 3 / 記録モード 既定の CONTINUOUS で記録し続けている CONTINUOUS DAILY リソースが変わるたびに即座に CI を生成。 1日1回、差分をまとめて CI を生成。 SSM Inventory 系が混じると、 多くのユースケースでは、 1日に何十件も積み重なる。 これで十分。 対策 StackSets のテンプレートに RecordingMode: DAILY を明示する。 展開後も棚卸しスクリプトで実際のモードを確認する。
13. 3つが重なると数十倍になる 要因 何が起きるか 対策 AllSupported ＋ グローバルリソース 変更1件 → リージョン数倍の CI スコープを明示的に除外設定 ルール評価による CI 増幅 変更1件 →「1 ＋ ルール数」倍の CI ルール追加前に乗数を試算 CONTINUOUS モード 高頻度リソースで CI が爆発 テンプレートに DAILY を明示 Config は有効化のハードルが低い分、設定の意味を理解せずに進めると後で痛い目を見る。
14. まとめ 01 削減の前に可視化。何にいくら使っているかを先に確定させる。 02 減らす → 止める → 買う。順番を逆にするとコミットに縛られる。 03 既定値を疑う。Config は記録範囲・ルール数・記録モードを必ず確認する。
15. 最後に 削減額を報告するまでが仕事。 測り方は着手前に決めておく Before After Report 着手前に、 同じ切り口で測り直す。 削減額と維持の仕組みを 何にいくら使っているかを 比較できない数字は セットで報告する。 確定させる。 成果にならない。
16. お知らせ JAWS FESTA 2026 in AKITA 懇親会 日時 2026年11月7日（土）18:30 - 20:30 会場 ANAクラウンプラザホテル秋田 秋田県秋田市中通2-6-1 参加費 5,000円（前払い・申込締切 11/7 16:30） jaws-ug.doorkeeper.jp/events/197595