【レポート】開発者のためのAWSコスト最適化テクニック「Optimize AWS Costs: Developer Tools and Techniques」に参加しました！#AWSreInvent #DEV318

AWS re:Invent 2025
2025.12.02
こんにちは！クラウド事業本部のおつまみです。
今回はre:Invent2025のセッション「Optimize AWS Costs: Developer Tools and Techniques」に参加してきたので、内容をご紹介します！
 セッションの概要 タイトルOptimize AWS Costs: Developer Tools and Techniques
 概要As cloud applications grow in complexity, optimizing costs becomes crucial for developers. This session explores AWS-native tools and coding practices that reduce expenses without compromising performance or scalability. Learn to identify resource inefficiencies using AI-powered recommendations and cost analysis tools. Discover how to implement cost-aware architectures across compute, serverless, and observability services. The presentation covers practical techniques for identifying and automating optimization practise using Amazon Q Developer and Kiro CLI. Developers will gain actionable insights to build cost-efficient applications and optimize cloud spending.
クラウドアプリケーションの複雑化が進むにつれ、開発者にとってコストの最適化が不可欠になっています。このセッションでは、パフォーマンスやスケーラビリティを損なうことなく費用を削減するAWSネイティブツールとコーディングプラクティスを紹介します。AIを活用した推奨事項とコスト分析ツールを使用して、リソースの非効率性を特定する方法を学びます。コンピューティング、サーバーレス、オブザーバビリティサービス全体にわたって、コストを考慮したアーキテクチャを実装する方法を学びます。プレゼンテーションでは、Amazon Q DeveloperとKiro CLIを使用して最適化プラクティスを特定し、自動化するための実用的な手法を紹介します。開発者は、コスト効率の高いアプリケーションを構築し、クラウド支出を最適化するための実用的なインサイトを得ることができます。
 スピーカーSteph Gooch, Sr. Solution Architect Advocate, AWS
Kenneth Attard, Enterprise Architect, Betsson Group
 レベル300
 Session TypeBreakout session
 セッションの内容 イントロダクション：よくある悪夢のシナリオ金曜日の朝、のんびりとした一週間を過ごしていたところ、突然予算アラートのメールが届く。上司やチーム全体から「何が起きたの？」と問い合わせが殺到。パニックになりながらデータを調べてみると、実は何も問題が起きていたわけではなく、単にリソースを作り続けていた結果、予算を予想より早く使い切ってしまっただけだった。
このセッションでは、このような状況を防ぐためのコスト最適化の手法を、シンプルなものから高度なものまで紹介されていました。
 Betsson Groupの紹介スピーカーのKenneth AttardさんはBetsson Groupに所属しており、複数の市場・リージョンを持つことで、コスト最適化の機会も複雑になると述べていました。
 シンプルなコスト最適化まずは基本的で実装しやすいコスト最適化から紹介されました。
 1. CloudTrailの最適化CloudTrailはAPI呼び出しをキャプチャするサービスで、基本的には無料だが、複数の証跡を使用するとコストが発生します。

Betsson Groupでは、各アカウントに個別のCloudTrail証跡があったが、ベストプラクティスに従い、Organizations全体で1つの証跡にまとめた。

よって、各アカウントの余分な証跡を削除することでコストを削減した。
 2. 未使用のEBSボリュームの削除何らかの理由でアタッチされていないEBSボリュームが多数存在していた。

EBSボリュームは使用していなくてもコストが発生するため、不要なボリュームをすべて削除した。

コンプライアンス上必要なものについては、バックアップを取得してから削除した。
 3. ネットワークリソースの整理Elastic IP

多数のElastic IPが存在し、そのほとんどが公開用だった。つ

まり、パブリックIPとElastic Load Balancerの両方に対して課金されていた。

不要なElastic IPを削除することで、二重のコストを削減した。
NAT Gateway

複数のNAT Gatewayが存在していたため、後述する高度な最適化手法を適用した。
Transit Gateway

余分なTransit Gatewayを削除してコストを削減した。
 4. ライトサイジングライトサイジングは最もお気に入りの最適化手法の1つ。

様々なツールを活用してインフラを最適化する機会が多く得られる。

これにより、次の2つの項目（ストレージとGraviton移行）につながった。
 5. ストレージの最適化S3
不要なデータを削除
必要だが頻繁にアクセスしないデータをGlacierに移動
ライフサイクルポリシーを実装
EBSボリューム

ライトサイジングと合わせて最適化を実施。
 6. Gravitonへの移行GravitonはAWSが開発したArmベースのCPUで、コストとパフォーマンスの両面で非常に効率的である。

EC2だけでなく、様々なサービスで利用可能。
 7. RDSの最適化PostgreSQLとMySQL/MariaDBのデータベースが動作していたが、コスト効率が良くなかった。

Gravitonベースのインスタンスに変更することで、コストを削減し、パフォーマンスも向上させた。
 Cost Optimization Hubの活用Cost Optimization Hubは、コスト最適化の機会を一元的に確認できる無料サービス。リソースの削除、ライトサイジング、Gravitonへの移行など、様々な最適化案をまとめて表示してくれる。重要なのは、すべての推奨事項を合計すると膨らんだコストになってしまうため、このツールは実際に達成可能な現実的な削減額を表示してくれる点だ。
Cost Optimization Hubは常に更新されており、re:Inventでも新機能が発表されているため、定期的にチェックすることを推奨する。
 AIツールによる最適化の高速化 Amazon Q DeveloperとKiro CLI多くの開発者はコンソールで作業するのを好まないため、ターミナルやIDEで使えるAIツールを紹介された。
Amazon Q Developer: IDE内のプラグインやチャット機能
Kiro CLI: コマンドラインで使えるAIアシスタント
これらのツールを使用することで、コード最適化を様々な理由で効率化できる。
 MCPの活用MCP（Model Context Protocol）を設定することで、Cost Optimization Hubなどのツールに接続し、最適化作業を高速化できる。
デモ内容：
Kiro CLIを起動し、MCPが正しく設定されているか確認（/mcpコマンド）
「特定のアカウントのCompute Optimizer推奨事項をすべて見つけて」と質問
MCPが接続し、推奨事項のリストを返す
特定のリソース（例：workshop web server）を選択し、推奨される変更を適用するようKiroに依頼
Kiroがコードを検索し、推奨される変更（インスタンスタイプの変更など）を実施
CloudFormationの構文も自動で処理（CloudFormation MCPを使用）
更新用のCLIコマンドも生成してもらう
Kiroにそのコマンドを実行してもらう
コンソールでコスト最適化の推奨事項を確認するのと、Kiroを使って推奨事項を見つけて変更を適用するまでの時間がほぼ同じ。

これがAIツールの力であり、最適化の高速化とコスト削減の迅速化につながる。
 高度なコスト最適化次に、より高度で実装が複雑なコスト最適化手法を紹介する。
 1. CloudWatch Logsの最適化CloudWatchはログ記録に使用されるが、大量のログを保存するとコストが発生する。
最適化方法：
不要なログを削除し、適切な保持期間を設定
アプリケーションコードを最適化して、生成されるログの量を削減
Infrequent Access（低頻度アクセス）ストレージクラスに変更することで、大幅なコスト削減を実現
 2. AWS Configの最適化AWS Configはアカウント内で発生するイベントを継続的に記録する便利なツールだが、特にKubernetesのようにオートスケーリングが頻繁に発生する環境では、多数のイベントが生成される。
最適化方法：
記録頻度を「Continuous（継続的）」から「Daily（日次）」に変更
これによりコンテナ環境での大幅なコスト削減を実現
Betsson Groupのケースでは、ゲームの試合開始時にトラフィックが急増し、EKSがオートスケールを開始すると、AWS Configが大量のイベントを記録していた。日次記録に変更することで、この問題を解決した。
 3. データ転送コストの最適化AWSでは複数のタイプのデータ転送が存在し、それぞれ課金される。
最適化方法：
アベイラビリティゾーン間のトラフィックを削減
一部のアカウントでは、異なるAZ間でRDSインスタンスが配置されていた
可能な限り、リソースを同じAZ内に配置することで、AZ間のデータ転送コストを削減
S3ゲートウェイエンドポイントの活用
Kinesis Data Firehoseなどのサービスは、デフォルトでパブリックIPスペースを経由してS3にアクセスする
つまり、NAT Gatewayを経由してインターネットゲートウェイに到達し、S3エンドポイントにアクセスして戻ってくるため、余分なデータ転送コストが発生
S3ゲートウェイエンドポイント（無料機能）をVPCに実装することで、S3トラフィックはNAT Gatewayを経由せず、直接S3エンドポイントにアクセスできる
DynamoDBゲートウェイエンドポイントも同様に利用可能
 4. Lambdaの最適化最適化方法：
Gravitonアーキテクチャ（ARM64）に変更することでコスト削減
コードの最適化により、Lambda関数の実行時間を短縮
実行時間が短縮されることで、さらなるコスト削減を実現
 5. NAT Gatewayの高度な最適化NAT Gatewayはプライベートサブネット内のリソースがインターネットにアクセスするために必要だが、コストが高い。
一般的な構成の問題点：
各AZにNAT Gatewayを配置する標準的な構成では、3つのAZで3つのNAT Gatewayが必要
NAT Gatewayには「稼働時間料金」と「データ処理料金」の2種類のコストがかかる
3つのNAT Gatewayで月額約$190のコストが発生
最適化された構成：集中型NAT Gateway
S3ゲートウェイエンドポイントの実装
S3へのトラフィックが直接ルーティングされ、NAT Gatewayを経由しない
Network ACLsの活用
不要なトラフィックをNetwork ACLsでブロックし、複数のAWSネットワーク要素を経由しないようにする
Transit Gatewayとの組み合わせ
各VPCをTransit Gatewayに接続
1つのAZに1つのNAT Gatewayのみを配置
全VPCからのトラフィックをこの1つのNAT Gatewayに集約
コスト比較（2TBのデータ処理を想定）：


項目
標準構成
集中型構成


NAT Gateway料金
$190
$0 (1つのみなので固定費に含む)

Transit Gateway固定費
-
$218

Transit Gatewayデータ処理
-
$192

合計
$190
$410

一見すると集中型の方が高く見えるが、重要なのはデータ量が増えると大きな差が出る点。
損益分岐点とメリット：
S3ゲートウェイエンドポイントとNetwork ACLsにより、NAT Gatewayを経由するトラフィックを35-45%削減
AZの数が増えるほど、集中型の方がコスト効率が良くなる
最大80%のコスト削減が可能
このアプローチにより、複数のコンポーネントを組み合わせてNAT Gatewayのコストを削減できる。
 6. リージョン選択によるコスト最適化AWSのネットワーク構成において、リージョン間のデータ転送経路が重要になる。
例：ヨーロッパからサンパウロへのデータ転送
AWSのネットワーク構造上、ヨーロッパ（アイルランドなど）からサンパウロへのトラフィックは、米国を経由する
つまり、ヨーロッパ → 米国 → サンパウロという経路になる
Database Migration Service（DMS）のコスト比較：

サンパウロへ1TBのデータを転送する場合：


リージョン
月額コスト


フランクフルト（eu-central-1）
$2,573

アイルランド（eu-west-1）
$2,300

米国東部（us-east-1）
$1,800

最適化方法：
データの送信元がヨーロッパでも、DMSインスタンスを米国東部（us-east-1）に配置することで、最大30%のコスト削減が可能
この原則は、DMSだけでなく、複数リージョンにまたがる環境を持つ他のサービスにも適用できる
 7. AWS WAF（Web Application Firewall）の最適化WAFはHTTPSエンドポイントを保護するために使用されるが、機能には「標準機能」と「プレミアム機能」の2種類がある。
標準機能（基本料金に含まれる）：
地理的制限ルール
AWS管理ルールの一部
IPレピュテーションルール
レート制限ルール
プレミアム機能（追加料金が発生）：
Bot Control（ボット対策）
Account Takeover Prevention（アカウント乗っ取り防止）
Fraud Prevention（不正防止）
最適化方法：
標準機能を最大限活用
地理ブロッキングルール、カスタムルール、レート制限ルールなどを使用
標準機能でブロックできるトラフィックを可能な限り除外
ラベルとカスタムルールでスコープを絞る
プレミアム機能にヒットするトラフィックを最小限に抑える
標準機能でブロックされるべきトラフィックがプレミアム機能に到達しないようにする
ChallengeとCAPTCHAの使い分け
CAPTCHA:
ユーザーに画像パズルなどを表示
ユーザー体験への影響が大きい
料金: $0.40/1000リクエスト
Challenge:
バックグラウンドで自動的にチェック（サイレントチェック）
ユーザー体験への影響が少ない
料金: $0.10/1000リクエスト（CAPTCHAの1/4）
推奨: 本当にCAPTCHAが必要な場合以外は、Challengeを使用することでコストを75%削減できる
WAF Capacity Unitの最適化
標準構成:
デフォルトのWAF capacity limitは1,500 WCU
1,500 WCUまでは基本料金
5,000 WCUまで拡張可能
500 WCU追加ごとに追加料金が発生
例: 2,500 WCUが必要な場合
1,500 WCU: 基本料金
追加1,000 WCU: 追加料金（500 WCU × 2）
最適化された構成: CloudFrontとWAFの組み合わせ
CloudFront（グローバル配信）にWAFを関連付け → 1,500 WCU利用可能
CloudFrontをオリジン（API Gateway、ALBなど）に接続
オリジン側にも個別のWAFを設定 → さらに1,500 WCU利用可能
合計3,000 WCUを追加料金なしで使用可能
この構成により、2つのWAFを組み合わせることで、WAF capacity limitの追加料金を節約できる。
 AIを活用したアーキテクチャ全体の最適化個別のリソースだけでなく、アーキテクチャ全体を考慮した最適化も重要。Amazon Q Developerの機能を使用すると、大規模なコードベース全体を自動的に最適化できる。
 デモ: Amazon Q Developerの最適化機能IDE内で大きなCloudFormationテンプレートファイルを開く
ファイル全体を選択し、右クリック
「Amazon Q」→「Optimize」を選択
AIがファイルを分析し、最適化方法を提案
最適化されたバージョンの新しいファイルを生成
AIが提案する最適化内容：
ネットワークの最適化
ストレージの最適化
コンピューティングの最適化
削減可能なコストの概算も表示
重要なのは、すべての推奨事項を実装する必要はなく、実際に適用可能なものを選択できる点。
さらに、この機能はコスト最適化だけでなく、アーキテクチャやセキュリティの最適化も提案してくれる。大規模なアーキテクチャの初期レビューに非常に有用なツールだ。
 将来の無駄を防ぐ：Service Control Policies (SCPs)コスト最適化を実施しても、新しいリソースが非効率的な方法でデプロイされると、再び無駄が発生する。こ

れを防ぐのがService Control Policies（SCP）である。
 SCPの例：大型インスタンスタイプの制限{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:StartInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringLike": {
          "ec2:InstanceType": [
            "*.24xlarge",
            "*.metal"
          ]
        }
      }
    }
  ]
}
このSCPでは、アカウントまたはOU内で24xlargeやmetalインスタンスタイプの起動を禁止している。
ユースケース:
開発アカウントやサンドボックスアカウントでは、通常このような大型インスタンスは不要
誤って大型インスタンスをデプロイしてしまい、高額な請求が発生するのを防ぐ
必要な場合は、特定のバイパスロールを使用してデプロイ可能
このような「事故的な支出」は意外と多く、SCPで事前に防ぐことが重要だ。
 その他のSCP活用例
1. GP3ボリュームタイプの強制
GP3はGP2より20%安く、1TBまでは同じパフォーマンス
デフォルトでGP3を使用するようSCPで強制
2. NAT Gatewayの作成拒否
前述の最適化手法を適用した後、勝手にNAT Gatewayが作成されるのを防ぐ
3. 必須タグの強制
スケジューリング自動化、セキュリティ、コンプライアンスのための特定のタグを必須化
タグが設定されていないリソースのデプロイを防止
4. Gravitonやマネージドサービスの推奨
可能な限りGravitonインスタンスを使用
マネージドサービスを優先的に使用することで、約10%のコスト削減
5. リージョンの制限
誤って別のリージョンにリソースをデプロイするのを防ぐ
初心者や新入社員が間違ったリージョンにリソースを作成することは意外と多い
 AIを使ったSCPの作成とテストSCPの作成にもAIツールを活用できる。
デモ: Kiro CLIでSCPを作成
Kiro CLIで以下のようにプロンプトを入力:
Can you make me a service control policy that denies certain instance types in specific regions?
Kiroが自動的にSCPのJSONを生成
会話の保存機能
/save SCP.txt でこの会話を保存
後で /load SCP.txt で会話を再開可能
別の作業をしてから戻ってきても、以前のコンテキストを保持
SCPのテスト
CloudFormationテンプレートなどのコードを用意
Kiroに「このコードがSCPに違反しないかチェックして」と依頼
違反がある場合は、具体的にどの部分が問題かを指摘
SCPのテストの利点:
実際にOrganizationsにデプロイする前にテストできる
パイプラインに組み込んで自動チェックも可能
コードレビューの段階でSCP違反を検出できる
このように、SCPを事前にテストすることで、アカウントやOrganizationに影響を与える前に問題を発見できる。
 未来志向のAI活用：Context機能AIがインフラを構築する時代において、どうやってコスト最適化のベストプラクティスをAIに教えるのか？その答えが**Context（コンテキスト）**機能だ。
 Contextとは自分自身、プロジェクト、作業方法に関する情報をAIに提供する機能
AIツールとの関係を改善し、効率的に作業できる
Amazon Q Developer（IDE内） と Kiro CLI の両方で利用可能
毎回同じことを繰り返し説明する必要がなくなる
 Contextの設定方法
Amazon Q Developer（IDE内）:
「Rules」として設定
例: 「Lambda関数を作成する際は、常にGravitonアーキテクチャを使用し、CloudWatch Logsのログループと保持ポリシーを設定する」
Kiro CLI:
/context show で現在のコンテキストを確認
/context add <ファイルパス> でコンテキストファイルを追加
Amazon QのRulesとKiroのContextは重複する場合があるため注意
 デモ: Contextのbefore/after比較Before（Context設定前）:
「シンプルなLambda関数のCloudFormationテンプレートを作成して」とプロンプト
AIが基本的なLambda関数を生成
問題点:
Gravitonアーキテクチャ（ARM64）が使用されていない
CloudWatch Logsのログループが自動作成されていない

After（Context設定後）:
Amazon Q Developerの場合:
Rulesを作成: 「Lambda関数は常に最適化されている必要がある。Gravitonアーキテクチャを使用し、ログループと保持ポリシーを設定すること」
同じプロンプトで再度Lambda関数を作成
結果:
Architecture: arm64（Graviton）が自動的に設定される
CloudWatch Logsのログループが自動的に作成される
保持ポリシーも設定される

Kiro CLIの場合:
/context add optimization-rules.txt でコンテキストファイルを追加
/context show で設定を確認
同じプロンプトでLambda関数を作成
結果:
Amazon Q Developerと同様に、最適化された構成が自動適用される

 Contextの活用メリット繰り返し作業の削減: 毎回同じベストプラクティスを説明する必要がない
一貫性の確保: チーム全体で同じ最適化基準を適用できる
時間の節約: デプロイまでの時間を大幅に短縮
プロジェクト固有の設定: プロジェクトごとに異なるコンテキストを設定可能
言語やフレームワークの指定: 好みのプログラミング言語やフレームワークを事前に設定
このセッションで最も重要なポイントの1つが、このContext機能だ。AIアシスタントとの効率的な作業を実現するために、ぜひ活用してほしい。
 まとめ：予算アラートから成功へセッションの冒頭で紹介した「金曜日の朝の悪夢」のシナリオをこのセッションで紹介した手法を実践すれば、そのような状況は避けられる。
 目指すべきゴールコスト削減: 様々な最適化手法でAWSコストを削減
再投資: 節約したコストを以下に再投資
新しいスタッフの採用
資格取得
新しいリソース
アプリケーションの新機能開発
ビジネスを改善するあらゆるもの

 そのために必要なことコスト追跡: 何を削減し、どこに再投資したかを追跡
成果の正当化: 削減した金額を明確にし、新しい場所への投資を正当化
AIツールの活用: このプロセスを高速化するためにAIツールを使用
 行動を起こすための3つのステップAIツールを導入する
Amazon Q Developer、Kiro CLI、MCPなどを使い始める
最適化プロセスを高速化
低労力の最適化を実施し、再発を防止
シンプルな最適化（未使用リソースの削除など）を実施
SCPやContextを使って、同じ問題が再発しないようにする
2週間後に同じ作業を繰り返さなくて済むようにする
Context機能で時間を節約
Amazon Q DeveloperのRulesやKiroのContextを設定
MCPを活用してさらに効率化
チームの生産性を向上
 最後に覚えておいてほしいことこのセッションでは多くの最適化手法を紹介した。すべてを一度に実装する必要はない。
まず1つ選んで実装してみよう。
興味を持った手法を1つ選び、自分の組織に実装してみてほしい。それが最初の一歩になる。
 最後に今回は、re:Invent2025のセッション「Optimize AWS Costs: Developer Tools and Techniques」の内容をご紹介しました。
このセッションでは、シンプルな最適化から高度な最適化、そしてAIツールを活用した自動化まで、幅広いコスト最適化手法を学ぶことができました。
特に印象的だったのは、Amazon Q DeveloperやKiro CLIといったAIツールを使うことで、コスト最適化の推奨事項の発見から実装までを大幅に高速化できる点です。このセッションでもKiro推しでしたね。
まだまだAIツールを実務に使いこなせていないため、今回紹介されたContext機能やMCPの活用方法は、自分の業務に取り入れてみたいと思いました！
最後までお読みいただきありがとうございました！
以上、おつまみ（＠AWS11077）でした！
 参考AWS Cost Optimization Hub
AWS Compute Optimizer
Amazon Q Developer
Service Control Policies (SCPs)
項目	標準構成	集中型構成
NAT Gateway料金	$190	$0 (1つのみなので固定費に含む)
Transit Gateway固定費	-	$218
Transit Gatewayデータ処理	-	$192
合計	$190	$410
リージョン	月額コスト
フランクフルト（eu-central-1）	$2,573
アイルランド（eu-west-1）	$2,300
米国東部（us-east-1）	$1,800
セッションの概要

タイトル

概要

スピーカー

レベル

Session Type

セッションの内容

イントロダクション：よくある悪夢のシナリオ

Betsson Groupの紹介

シンプルなコスト最適化

1. CloudTrailの最適化

2. 未使用のEBSボリュームの削除

3. ネットワークリソースの整理

4. ライトサイジング

5. ストレージの最適化

6. Gravitonへの移行

7. RDSの最適化

Cost Optimization Hubの活用

AIツールによる最適化の高速化

Amazon Q DeveloperとKiro CLI

MCPの活用

高度なコスト最適化

1. CloudWatch Logsの最適化

2. AWS Configの最適化

3. データ転送コストの最適化

4. Lambdaの最適化

5. NAT Gatewayの高度な最適化

6. リージョン選択によるコスト最適化

7. AWS WAF（Web Application Firewall）の最適化

AIを活用したアーキテクチャ全体の最適化

デモ: Amazon Q Developerの最適化機能

将来の無駄を防ぐ：Service Control Policies (SCPs)

SCPの例：大型インスタンスタイプの制限

その他のSCP活用例

AIを使ったSCPの作成とテスト

未来志向のAI活用：Context機能

Contextとは

Contextの設定方法

デモ: Contextのbefore/after比較

Contextの活用メリット

まとめ：予算アラートから成功へ

目指すべきゴール

そのために必要なこと

行動を起こすための3つのステップ

最後に覚えておいてほしいこと

最後に

参考

関連記事

EVENTS
