コスト削減の基本の「キ」～ コスト消費3大リソースへの対策 ～

2025/08/29（金）開催の「JAWS-UG 名古屋 8月会② 〜AWSのコスト削減・最適化LT大会〜」における私の発表資料「コスト削減の基本の『キ』～ コスト消費3大リソースへの対策 ～」の発表資料になります。 #jawsug #jawsug_nagoya

https://jawsug-nagoya.connpass.com/event/364596/

Transcript

1. コスト削減の基本の「キ」 ～ コスト消費3大リソースへの対策 ～ 2025.08.29 JAWS-UG 名古屋 8月会#2 AWSのコスト削減・最 適化LT大会 KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア サーバーレスとIaCが大好き。好きなAWSサービスはAWS LambdaとAWS CDK 主にJAWS-UG 名古屋 ＆ JAWS-UG CDK支部で活動 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder(serverless)（2023～） ◼ Scrum Inc. 認定スクラムマスター（2025/07～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 2 KDDI Agile Development Center Corporation 本日のアジェンダ • コスト消費3大サービスとその対策 • 共通対策：コスト系サービスの活用 • まとめ
4. 3 KDDI Agile Development Center Corporation 注意事項 • 本LTは、主に下記のようなシンプルな環境を前提としています（「大規模環境での数百万・数 千万のコストカット」のような事例はありません） ◦ 比較的小規模な環境・基本的なRest API環境/個人のAWS環境 • 本LTで出てくるサービスが別に「高い」とか「悪い」というわけではありません ◦ どんなサービスも「適切に」使うことが大切です ◦ またサービスを使う以上、それに対する対価を払うのは当然です • 文字数の関係上、一部AWSサービスの接頭辞（「AWS」「Amazon」）は省略しています • 本資料は、下記URLで公開しています。 ◦ この資料です
5. 4 KDDI Agile Development Center Corporation コスト消費3大サービスとその対策
6. 5 KDDI Agile Development Center Corporation コスト消費3大リソース • Amazon EC2/Amazon RDS ◦ オーバースペック＆稼働しっぱなし • Amazon CloudWatch Logs ◦ 塩漬けのログ • AWS Lambda ◦ 永久ループ＆得体知れずのLambdaの稼働
7. 6 KDDI Agile Development Center Corporation リソースその1：Amazon EC2/Amazon RDS • オーバースペックのEC2/RDS ◦ 実際の稼働状況に対し、明らかにオーバースペックなインスタンスが選択されている ◦ その結果、不要に高い（=不要な）コストが課金されている • 稼働しっぱなしのEC2/RDS ◦ 全く使っていない＆絶対に使われない状況にもかかわらず、インスタンスが起動しっぱなしになっている ◦ その結果、不要なインスタンスコストを払うことに… ◦ うっかり「インスタンスを停止し忘れた」際に起こりがち（うっかり「終了」するよりはマシだけど）
8. 7 KDDI Agile Development Center Corporation 対策：メトリクス監視＆自動で停止させる仕組みを作る • メトリクスを監視、明らかにスペック過剰な場合はスペックを下げる ◦ 「CPUUtilization」「MemoryUtilization」などスペックに関係するメトリクスを監視し、明らかにスペック過 剰の場合、より低スペックなインスタンスにして不要なコストを削減する ◦ ただしサービスローンチ直後・本番環境では多少コストは高くても多少余裕を持ったスペックにした方がいい • サービス直後にトラブルなどが多いと、それだけでユーザーの第一印象は悪くなる • お金より「ユーザーが離れる」損失のほうが、長い目で見たらダメージが大きい • 時間になったら自動で停止する仕組みを構築する（利用する） ◦ EventBridgeのスケジュールイベント（特定の時間に起動） ◦ AWS Instance Schedulerの活用 …etc. • https://aws.amazon.com/jp/solutions/implementations/instance-scheduler-on-aws/
9. 8 KDDI Agile Development Center Corporation リソースその2：Amazon CloudWatch Logs • 塩漬けのCloudWatch Logs ◦ ログを出力するのはよいが、そのログが出力しっぱなしになっている（アーカイブ・削除がされていない状態） ◦ その結果、アクセスされないログが塩漬けのまま放置され、保管料だけが課金され続けることに… • やたら出力されまくるログ ◦ 「それ本当に必要？」という過剰なログ出力 ◦ ログ出力自体はコストは控えめ＆調査に必要だけど、それがずっと保管されたままの状態に… ◦ 特に開発環境で起こりがち
10. 9 KDDI Agile Development Center Corporation 対策：ログの保持期間＆出力レベルを設定する • ログの保持期間を適切に設定し、期間が過ぎたら自動削除するようにする ◦ ログの保持期間を適切に設定し、期間が過ぎたら自動削除することで、保管コストを削減する • デフォルトだと「無期限」なので（これが原因）、まず保持期間を設定する • AWS CDKだと「LogGroup.retention」で設定可能 ◦ 「開発環境なら短く、本番環境なら長く…」など、業務に支障がない適切な期間を設定する • ログの出力レベル＆種類を正しく設定する ◦ 環境ごとに出力するログレベルを分けることで、不要なログの出力＆保管を防ぐ • 例：開発環境はDebugから、本番環境はErrorのみ…など（ここは運用次第） ◦ あまりアクセスしないようなログはログクラスを「低頻度アクセス」にすることでコストを削減可能 • ただし取り込み（=出力）コストのみ（保管料・Logs Insights料金は同じ） • ただし調査時に「必要なログがない」なんて事がないように注意（それでは本末転倒）
11. 10 KDDI Agile Development Center Corporation リソースその3：AWS Lambda • 永久ループ ◦ ソースコード内で意図せず永久ループが発生してしまい、毎回制限時間いっぱいまで動作し続けている • 当然、総実行時間が長くなりコストも増加 ◦ 何かのサービス（S3/DynamoDBなど）でLambdaトリガが設定されている場合に、意図せずLambda内でそれ らサービスのトリガ条件を満たしてしまい、結果永久ループに…なんてことも • 得体知れずのLambdaの稼働 ◦ やたらにLambda関数を作成した結果、自分でも覚えてないLambdaが稼働している…という事態も • CDKなどでCloudFormationスタックをあれこれ作成したり、いろんなリージョンに作成したりすると起こ りがち ◦ 特に個人環境・開発環境で発生しやすい
12. 11 KDDI Agile Development Center Corporation 対策：テストを行う＆各種AWSリソースの活用 • 事前にテストして確認する ＆「最大実行時間」を短く設定する ◦ デプロイ前に単体テストを行い、永久ループなどのバグをあらかじめ修正しておく • 永久ループに限らず、事前のテストは必ず行う ◦ 適切な「最大実行時間」を設定し、意図せず実行時間が長くなることを防ぐ • トリガ元をマネジメントコンソールで確認 ◦ Lambdaのマネジメントコンソールではトリガ元サービスを確認可能なので、それらをターゲットとした処理を 行う場合は、トリガ条件を満たさないように気を付ける（そもそもそういう処理自体を行わないのが理想） ◦ SNS/SQS/S3については「再帰ループ検出・停止機能」があるので、それを活用する • https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-recursion.html
13. 12 KDDI Agile Development Center Corporation 共通対策：コスト系サービスの活用
14. 13 KDDI Agile Development Center Corporation 共通対策：コスト系サービスの活用 • AWS Cost Explorerで、課金額を定期的に確認する ◦ Cost Explorerにて各サービスへの課金額を確認し、想定額と大きな差がないかを監視する • 明らかに想定額を大きく超えている場合、何か意図しない稼働が発生している可能性がある ◦ 可能であれば、メール・Slackなどに定期的に課金額を送信するようにすると便利（必須ではない） • AWS Budgetsで、想定額を超えた場合に通知するようにする ◦ AWS Budgetsには「課金額が一定の金額を超えた場合に通知する」機能があるので、それを活用 ◦ あらかじめこれを設定しておくことで、万が一の際の多額の課金を防ぐことができる（かも） ◦ 緊急度は低いかもしれないが、重要なことなので早めに対応しておく • 「定期的な確認」＆「想定外の課金に気付ける」仕組みを早めに構築する
15. 14 KDDI Agile Development Center Corporation まとめ
16. 15 KDDI Agile Development Center Corporation まとめ • 各種サービスで意図せずコストがかさむ状況があるので、気を付ける • そのような状況を防ぐ機能やツールがAWS側にも用意されているので、それらを活用する • 大事なのは「不要な」コストを削減する事であり、ただ「目の前の出費を少なくする」だけ のことを「コスト削減」とは言わない。 ◦ 結果「メンバーの作業負荷・時間が増えた」「処理時間が長くなった（使いにくくなった）」なんてのは論外！ • 「不要な」コストを削減し、その分を「必要な」サービスに充てる…というのが大切です
17. 札幌オフィス SAPPORO OFFICE 秋田オフィス AKITA OFFICE 高崎オフィス TAKASAKI OFFICE 金沢オフィス KANAZAWA OFFICE 舞鶴オフィス MAIZURU OFFICE 広島オフィス HIROSHIMA OFFICE 福岡オフィス FUKUOKA OFFICE 那覇オフィス NAHA OFFICE 仙台オフィス SENDAI OFFICE 東京本社 TOKYO MAIN OFFICE 三島オフィス MISHIMA OFFICE 名古屋オフィス NAGOYA OFFICE 大阪オフィス OSAKA OFFICE
18. 採用募集中！ エンジニア・デザイナー
19. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る