AWSコスト最適化
AWSのコストを継続的に最適化するための実践手法を学びます。料金モデルの理論ではなく、「何をどの順番で見て、どう判断するか」に焦点を当てます。
所要時間
約45分
前提知識
- AWS基礎（料金モデル）
- EC2（購入オプション）
- RDS・データベース（Aurora料金体系）
コスト最適化の基本方針
コスト最適化は「安くすること」ではなく、同じ成果をより少ないコストで達成することです。
優先順位:
- 不要なものを止める — 効果最大、リスク最小
- サイズを適正化する — Right Sizing
- 料金モデルを最適化する — RI / Savings Plans
- アーキテクチャを改善する — Graviton移行、キャッシュ活用等
上から順に取り組みます。1を飛ばして3に行くのはアンチパターンです。使っていないリソースにRIを買っても意味がありません。
ステップ1: 不要リソースの特定と停止
確認すべきもの
| 対象 | 確認方法 | よくある無駄 |
|---|---|---|
| EC2インスタンス | Cost Explorer → サービス別 | 開発/検証用が常時起動 |
| EBS ボリューム | EC2コンソール → ボリューム → available | 削除したEC2のボリュームが残存 |
| Elastic IP | VPCコンソール → 未関連付け | 確保したまま未使用（課金対象） |
| RDSスナップショット | RDSコンソール → スナップショット | 古い手動スナップショットの蓄積 |
| NAT Gateway | VPC Flow Logs → トラフィック量 | 不要なAZに配置 |
| ロードバランサー | ターゲットグループのヘルシーホスト数 | ターゲットが0のALB |
開発/検証環境のスケジュール運用
開発・検証環境を営業時間外に停止するだけで、コンピュートコストを約65%削減できます。
# EventBridge + Lambda で平日9-19時のみ起動するスケジュール例
# 開始: cron(0 0 ? * MON-FRI *) # UTC 0:00 = JST 9:00
# 停止: cron(0 10 ? * MON-FRI *) # UTC 10:00 = JST 19:00
EKSの場合は、Karpenter または Cluster Autoscaler でノード数を0まで縮小可能です。
ステップ2: Right Sizing（リソースの適正化）
AWS Compute Optimizer の活用
Compute Optimizer は過去14日間のメトリクスを分析し、最適なインスタンスタイプを推奨します。
# Compute Optimizer の推奨を確認
aws compute-optimizer get-ec2-instance-recommendations \
--filters name=Finding,values=OVER_PROVISIONED
判断基準
| メトリクス | 過剰プロビジョニングの兆候 | アクション |
|---|---|---|
| CPU平均使用率 | 常時20%以下 | 1サイズ下を検討 |
| メモリ使用率 | 常時40%以下 | メモリ少ないインスタンスを検討 |
| ネットワーク帯域 | 上限の10%以下 | 小さいインスタンスで十分 |
| EBSスループット | IOPS上限に全く達しない | gp3でIOPS/スループットを個別指定 |
IdPサーバーのサイジング目安
IdPサーバーはCPUバウンド（JWT署名、ハッシュ計算）が中心です。
| 負荷規模 | 推奨インスタンス | 理由 |
|---|---|---|
| 開発/検証 | t3.medium（2 vCPU, 4 GiB） | バースト性能で十分 |
| 小規模本番（〜100 req/s） | m7g.large（2 vCPU, 8 GiB） | Gravitonでコスト効率重視 |
| 中規模本番（〜500 req/s） | m7g.xlarge（4 vCPU, 16 GiB） | JWT署名にCPUを使う |
| 大規模本番（1000+ req/s） | c7g.xlarge（4 vCPU, 8 GiB） | コンピュート最適化 + Graviton |
上記はあくまで目安です。実際のサイジングは 負荷テスト で検証してください。推測でサイジングするのは過剰プロビジョニングの原因になります。
Aurora のサイジング
| 観点 | 確認すべきメトリクス | 対応 |
|---|---|---|
| CPU | CPUUtilization が常時30%以下 | 1サイズ下を検討 |
| メモリ | FreeableMemory が常に潤沢 | メモリ少ないクラスを検討 |
| I/O | ReadIOPS, WriteIOPS | Aurora I/O-Optimized への切り替え検討 |
Aurora I/O-Optimized: I/O料金が無料になる代わりにインスタンス料金が約30%高い。I/Oコストが全体の25%以上を占める場合に有効です。
ステップ3: 料金モデルの最適化
購入オプションの選択フロー
┌───────────────────────────────────────────────────────────────┐
│ 購入オプション選択フロー │
├───────────────────────────────────────────────────────────────┤
│ │
│ そのワークロードは常時稼働か？ │
│ ├── No → オンデマンド or スポット │
│ │ 中断されても問題ないか？ │
│ │ ├── Yes → スポット（最大90%割引） │
│ │ └── No → オンデマンド │
│ └── Yes → Savings Plans or RI │
│ インスタンスタイプを固定できるか？ │
│ ├── Yes → RI（最大60%割引） │
│ │ Aurora, ElastiCache はRI一択 │
│ └── No → Savings Plans（最大72%割引） │
│ インスタンスファミリーの変更に柔軟 │
│ │
└───────────────────────────────────────────────────────────────┘
IdPサービスへの適用
| リソース | 推奨購入オプション | 理由 |
|---|---|---|
| EKSノード（本番） | Compute Savings Plans（1年） | ノードのインスタンスタイプ変更に柔軟に対応 |
| Aurora（本番） | Reserved Instance（1年） | インスタンスクラスが安定。RIのみ対応 |
| ElastiCache（本番） | Reserved Instance（1年） | Aurora同様、RIのみ対応 |
| EKSノード（検証） | オンデマンド + スケジュール停止 | 常時稼働でないためRI/SPは不適 |
| CI/CDランナー | スポット | 中断時はジョブ再実行で対応可能 |
| 負荷テスト用ノード | スポット | 一時的な利用。中断されても再実行可能 |
Reserved Instance の詳細
RIはAurora、ElastiCache等のマネージドサービスで唯一の割引手段です。EC2でもインスタンスタイプが固定できるなら最もコスト効率が高い選択肢です。
支払いオプション:
| 支払い方式 | 割引率（1年） | 割引率（3年） | キャッシュフロー |
|---|---|---|---|
| 全前払い（All Upfront） | 最大40% | 最大60% | 初年度に全額。割引最大 |
| 一部前払い（Partial Upfront） | 最大35% | 最大55% | 初回50% + 月額。バランス型 |
| 前払いなし（No Upfront） | 最大25% | 最大40% | 月額のみ。初期投資不要 |
期間の選択基準:
| 条件 | 推奨期間 | 理由 |
|---|---|---|
| サービス成長期。構成変更の可能性あり | 1年 | 柔軟性を確保。1年後に再評価 |
| 本番環境が安定。構成変更の予定なし | 3年 | 割引率を最大化 |
| 初めてRIを購入する | 1年・一部前払い | リスクを抑えつつ効果を確認 |
Standard vs Convertible（EC2 RIのみ）:
| タイプ | 変更可否 | 割引率 | 推奨用途 |
|---|---|---|---|
| Standard | インスタンスファミリー変更不可 | 高い | 構成が確定している本番環境 |
| Convertible | 同等以上の価格のRIに交換可能 | やや低い | Graviton移行を 予定している場合 |
- Compute Optimizer で現在のインスタンスが適正サイズか確認する（過剰なインスタンスにRIを買うのは無駄）
- 過去3ヶ月のオンデマンド使用量 をCost Explorerで確認し、常時稼働分だけにRIを適用する
- 不要になった場合は RIマーケットプレイス で売却可能（Standard RIのみ）
Savings Plans vs Reserved Instance
| 観点 | Savings Plans | Reserved Instance |
|---|---|---|
| 柔軟性 | インスタンスファミリー・リージョン変更可 | 特定のインスタンスに固定 |
| 割引率 | やや低い（Compute SP: 最大66%） | 高い（全前払い3年: 最大72%） |
| 対象サービス | EC2, Fargate, Lambda | EC2, RDS, ElastiCache, Redshift |
| 推奨用途 | EKSノード等の柔軟性が必要な箇所 | Aurora, ElastiCache等の固定リソース |
使い分けの原則: Aurora・ElastiCacheはRI一択（Savings Plans非対応）。EC2/EKSノードはSavings Plansを優先し、インスタンスタイプが完全に固定できる場合のみStandard RIを検討。
ステップ4: アーキテクチャの改善
Graviton移行
Graviton（ARM）インスタンスは同等のx86インスタンスと比較して約20%安価で、同等以上の性能を発揮します。
移行チェックリスト:
- Java 21 はARM対応済み（追加対応不要）
- Dockerイメージをマルチアーキテクチャでビルド（
--platform linux/amd64,linux/arm64） - ネイティブライブラリ（JNI）がARM対応しているか確認
- 負荷テストで性能差異がないことを検証
# マルチアーキテクチャビルド
docker buildx build --platform linux/amd64,linux/arm64 -t idp-server:latest .
NAT Gatewayのコスト削減
NAT Gatewayはデータ処理量に応じた課金（$0.062/GB）があり、想定以上に高額になることがあります。
| 対策 | 効果 | 適用条件 |
|---|---|---|
| VPCエンドポイント（Gateway型） | S3/DynamoDBへの通信でNAT不要 | S3/DynamoDB利用時は必須 |
| VPCエンドポイント（Interface型） | ECR/CloudWatch等への通信でNAT不要 | データ転送量が多い場合 |
| NAT Gatewayの集約 | AZごとに1台→共有 | 可用性とのトレードオフ |
EBS最適化
| 現状 | 改善 | 効果 |
|---|---|---|
| gp2（汎用） | gp3に変更 | ベースライン性能が高く、20%安価 |
| io1/io2（高IOPS） | gp3でIOPS指定 | 必要なIOPSだけ確保し、コスト削減 |
| 大きすぎるボリューム | 実使用量 + 余裕で再作成 | ストレージ単価 × GBの削減 |
コスト監視の仕組み
AWS Budgets によるアラート
月額コストが閾値を超えたら通知する仕組みは必須です。
| アラート設定 | 閾値 | 通知先 |
|---|---|---|
| 月額予算の80%到達 | 予算 × 0.8 | Slack / メール |
| 月額予算の100%到達 | 予算 × 1.0 | Slack / メール + 電話 |
| 予測値が予算超過 | 予測 > 予算 | Slack / メール |
| 特定サービスの急増 | 前月比 +30% | Slack / メール |
Cost Explorer の定期確認
月次で以下を確認します。
確認項目:
- サービス別コスト推移（前月比で急増しているサービスはないか）
- 未使用のRI/Savings Plansがないか（カバレッジレポート）
- タグ別コスト（テナント別、環境別の按分が適切か）
コストタグ戦略
全リソースにタグを付与し、コストの可視化と按分を可能にします。
| タグキー | 値の例 | 用途 |
|---|---|---|
Environment | production, staging, development | 環境別コスト集計 |
Service | idp-server, control-plane | サービス別コスト集計 |
Team | platform, application | チーム別コスト按分 |
CostCenter | engineering, operations | 部門別コスト按分 |
コストの落とし穴
じわじわ増える系（放置による無駄）
| 落とし穴 | 症状 | 対策 |
|---|---|---|
| 放置されたEBSボリューム | EC2削除後もボリュームが残る | DeleteOnTermination: true をデフォルトに |
| 未使用のElastic IP | 関連付けなしのEIPに課金（$3.65/月） | 定期的にチェック、不要なら解放 |
| CloudWatch Logs の無制限保存 | ログが無期限に蓄積 | 保持期間を設定（例: 90日） |
| 過剰なクロスAZトラフィック | AZ間データ転送に$0.01/GB | トポロジ認識ルーティングの活用 |
| 本番同等の検証環境 | 本番と同じサイズのインスタンス | 検証は最小サイズ + スケジュール停止 |
| 未使用のRI | 使っていないRIに毎月課金 | 購入前にCompute Optimizerで分析、RIマーケットプレイスで売却 |
請求が爆発する系（従量課金の罠）
気づいたときには月額が数倍になっていた、というパターンです。共通点は従量課金のサービスをリミットなしで使っていること。
NAT Gateway のデータ処理課金
NAT Gatewayは存在するだけで$0.062/時（約$45/月）かかりますが、本当に痛いのはデータ処理料金（$0.062/GB）です。ECRからのイメージPull、外部API呼び出し、CloudWatch/S3へのログ送信がすべてNAT経由になると、トラフィック量に比例して課金が膨らみます。
- 具体例: ECRからの大きなDockerイメージ（1GB）を10ノードで日次Pull → 月間300GB × $0.062 = $18.60/月（NAT Gateway料金だけで）
- 対策: S3/DynamoDBはGateway型VPCエンドポイント（無料）、ECR/CloudWatch等はInterface型VPCエンドポイントを設置
CloudWatch Logs のデータ取り込み課金
ログの取り込みに$0.76/GBかかります。IdPサーバーのように高頻度でリクエストを処理するサービスでは、ログレベルやログ内容次第で請求が跳ね上がります。
- 具体例: DEBUGログを本番で有効にしたまま放置 → 1リクエスト1KB × 1000 req/s = 86GB/日 → $65/日 = $1,960/月
- 対策: 本番はINFO以上、ログにリクエスト/レスポンスボディを含めない、サンプリングの活用
KMS API呼び出し課金
KMSは$0.03/10,000リクエストです。安く見えますが、暗号化されたデータを扱う処理でリクエストごとにKMSを呼び出すと、API呼び出し数が膨大になります。
実際に起きた事例: Athenaのパーティショニング変更に伴うデータ移行で、S3上の暗号化データを読み出すたびにKMS Decryptが呼ばれ、移行対象のデータ量に比例してAPI呼び出しが爆発しました。AWS Budgetsアラートで運用チームが検知して発覚。通常運用では問題にならないKMS課金が、大量データの一括処理で一気に顕在化したケースです。
- 通常運用の例: 毎リクエストでKMS Decrypt × 1000 req/s = 月間26億回 → $7,800/月
- データ移行の例: 数億オブジェクトの読み出し × 各1回のKMS Decrypt → 移行期間だけで数千ドル
- 対策:
- 復号結果をメモリにキャッシュ（TTL付き）
- Data Key を使った Envelope Encryption でKMS呼び出しを最小化
- 大量データ移行の前にKMS APIコストを概算する（オブジェクト数 × $0.000003）
- S3バケットキー（S3 Bucket Key）を有効化し、同一バケット内のKMS呼び出しを最大99%削減
Secrets Manager の API呼び出し課金
シークレット1つにつき$0.40/月 + API呼び出し$0.05/10,000リクエスト。シークレットの値をリクエストごとにGetSecretValueで取得するとAPI課金が積み上がります。
- 具体例: DB接続文字列を毎リクエスト取得 × 500 req/s = 月間13億回 → $6,500/月
- 対策: 起動時に取得してメモリに保持、ローテーション時のみ再取得（Lambda Extensionまたはアプリ側キャッシュ）
CloudTrail のデータイベント
管理イベント（API呼び出し記録）は無料ですが、データイベント（S3オブジェクト操作、Lambda実行）を有効にすると$0.10/100,000イベントかかります。
- 具体例: S3データイベントを全バケットに有効化、Lambda実行イベントも記録 → 月間数億イベント → 数千ドル/月
- 対策: データイベントは監査要件のあるバケット/関数のみに限定、Advanced Event Selectors でフィルタリング
Aurora ストレージの自動拡張（縮小しない）
Auroraのストレージは自動拡張しますが、自動では縮小しません。一時的な大量データ投入（マイグレーション、負荷テスト等）でストレージが拡張された後、データを削除しても課金は減りません。
- 具体例: 負荷テストで100GB投入 → テスト後にデータ削除 → ストレージ課金は100GBのまま（$10/月が永続）
- 対策: 負荷テスト用はスナップショットから別クラスターを作成し、終了後にクラスター ごと削除
GuardDuty のイベント分析課金
GuardDutyはVPC Flow Logs、DNS Logs、CloudTrailイベントを分析します。EKSやS3の保護機能を追加で有効化すると、分析対象が増えて月額が急増します。
- 具体例: EKS Runtime Monitoring + S3 Protection を大規模環境で有効化 → 数百〜数千ドル/月
- 対策: 30日間の無料トライアルで実コストを確認してから本有効化、不要な保護機能は無効化
- AWS Budgets のアラートは初日に設定する — サービスを使い始める前に予算アラートを設定
- 従量課金のサービスは上限を意識する — 「1リクエストあたりいくらか × 想定リクエスト数」を必ず概算
- 本番と検証でログレベル・監視設定を分ける — 検証のDEBUGログを本番に持ち込まない
- 定期的にCost Explorerで前月比を確認する — 月次レビューで異常を早期発見
IdPサービスのコスト構造
IdPサービスの典型的なコスト構成比率です。どこに最適化の余地があるか把握するために使います。
| コスト項目 | 構成比率（目安） | 主な最適化手法 |
|---|---|---|
| EKSノード（EC2） | 30-40% | Graviton移行、Savings Plans、Right Sizing |
| Aurora | 25-35% | RI、I/O-Optimized検討、Right Sizing |
| ElastiCache | 10-15% | RI、Right Sizing |
| NAT Gateway | 5-10% | VPCエンドポイント |
| ALB | 5-8% | — （削減余地小） |
| データ転送 | 3-5% | CloudFront活用、AZ間通信削減 |
| その他（S3, CloudWatch等） | 5-10% | ログ保持期間設定、S3ライフサイクル |
まとめ
| ステップ | アクション | 期待効果 | 優先度 |
|---|---|---|---|
| 不要リソース停止 | 未使用EC2/EBS/EIP削除、検証環境スケジュール運用 | 10-30% | 最優先 |
| Right Sizing | Compute Optimizer分析、インスタンスサイズ見直し | 10-30% | 高 |
| 料金モデル最適化 | Savings Plans（EKS）、RI（Aurora/ElastiCache） | 20-40% | 高 |
| アーキテクチャ改善 | Graviton移行、VPCエンドポイント、gp3移行 | 15-25% | 中 |
| 監視体制構築 | Budgets、Cost Explorer定期確認、タグ戦略 | 継続的な改善基盤 | 必須 |
関連ドキュメント
- AWS基礎 — 料金モデルの基礎
- EC2 — 購入オプションの詳細
- RDS・データベース — Aurora料金体系
- Well-Architected Framework — コスト最適化の柱
- 負荷テスト — サイジング検証