Contents
スポンサードリンク
全体像と基本戦略
| フェーズ | 主な施策 | 期待効果 |
|---|---|---|
| ① データ収集 | Cost Explorer、AWS CUR（Cost & Usage Report）から過去 3‑6 ヶ月分の利用実績を取得 | 正確なベースラインが構築できる |
| ② 無駄排除 | 未使用リソース自動削除、ライトサイジング | 月次コスト 5‑12 % 削減 |
| ③ 割引プラン適用 | Compute Savings Plans / EC2 Instance Savings Plans / Serverless Savings Plan の組み合わせ | 最大 55 % の割引率 |
| ④ 変動リソース最適化 | Spot Fleet + Predictive Pricing、Auto Scaling による自動フェイルオーバー | オンデマンド比で 60‑70 % 削減 |
| ⑤ ガバナンス | タグポリシー、Budgets + Anomaly Detection、インシデント自動化 | コスト増加の早期検知と再発防止 |
ポイント：各フェーズは並行して実施可能です。特に「データ収集」と「タグガバナンス」は全体最適化の土台になるため、最初に完了させておくことを推奨します。
未使用リソースの自動検出・削除
1. 最新レポート取得手順
| ツール | 主な機能 | 推奨設定 |
|---|---|---|
| Cost Explorer | サービス別・タグ別に「使用率」や「稼働時間」を秒単位で可視化 | フィルタ：UsageQuantity < 0.05（5 % 未満） |
| Trusted Advisor（リソース最適化レポート） | EC2、EBS、RDS、Elastic IP の未使用インスタンスを一覧化 | 「リアルタイム更新」オプションを有効化 |
2026 年 3 月に Trusted Advisor が「リソース最適化」レポートでリアルタイム更新を開始したことが想定されます。実装時は UI の変更点をご確認ください。
2. Lambda と CloudWatch Events による自動削除フロー
2‑1. スケジュール設定（H4）
|
1 2 3 4 5 6 7 8 |
# CloudWatch Event (EventBridge) 例 RuleName: UnusedResourceCleanup ScheduleExpression: cron(0 2 * * ? *) # 毎日 02:00 UTC 実行 State: ENABLED Targets: - Arn: arn:aws:lambda:us-east-1:123456789012:function:DeleteUnusedResources Id: DeleteLambda |
2‑2. Lambda 関数（Python）実装例（H4）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
import boto3, csv, os ec2 = boto3.client('ec2') rds = boto3.client('rds') def lambda_handler(event, context): # CSV は /tmp に一時保存された前工程の出力を想定 with open('/tmp/unused.csv') as f: for row in csv.DictReader(f): if row['Service'] == 'EC2': ec2.terminate_instances(InstanceIds=[row['ResourceId']]) elif row['Service'] == 'RDS': rds.delete_db_instance(DBInstanceIdentifier=row['ResourceId'], SkipFinalSnapshot=True) # 成功通知 sns = boto3.client('sns') sns.publish( TopicArn='arn:aws:sns:us-east-1:123456789012:CostAlerts', Message='未使用リソースの削除が完了しました。' ) |
2‑3. 運用上の注意点（H4）
- テスト環境で必ず Dry‑Run を実行し、誤削除を防止する
- 削除対象は タグ
AutoDelete=Yesが付与されたリソースに限定 すると安全性が向上 - CloudTrail と Config のルールで「削除操作の記録」も併せて有効化
AI が導くライトサイジング（Compute Optimizer）
1. 推奨取得とフィルタリング（H3）
- コンソール → Compute Optimizer > Recommendations
- 「対象」→「すべての EC2 インスタンス」→「Rightsizing Recommendation」タブを選択
- フィルタ：
RecommendationType = Downsize、Utilization < 30 %
2026 年 2 月に Compute Optimizer が多変量解析ベースの AI アルゴリズムへ刷新される予定です。実装時は「AI 推奨」ラベルが表示されます。
2. 推奨内容のレビューとテスト（H3）
| インスタンス ID | 現行タイプ | 推奨タイプ | 想定削減額（月） |
|---|---|---|---|
| i-0a1b2c3d4e5f6g7h8 | m5.large | t3.medium | $45 |
| i-1234567890abcd | r5.xlarge | r5.large | $78 |
- テスト手順：推奨インスタンスは 1 週間
stop-start循環し、CloudWatch メトリクスで CPU/メモリの回復率を確認。 - ロールバック：変更後にパフォーマンスが劣化した場合は、同一リージョン・AZ のスナップショットから元インスタンスへ復旧できるよう、AMI を事前取得しておく。
3. バッチ適用スクリプト（H3）
|
1 2 3 4 5 6 7 8 9 |
#!/usr/bin/env bash CSV=rightsizing.csv while IFS=, read -r iid cur_type rec_type ; do echo "➡ ${iid}: ${cur_type} → ${rec_type}" aws ec2 modify-instance-attribute \ --instance-id "$iid" \ --instance-type "{\"Value\":\"${rec_type}\"}" done < <(tail -n +2 "$CSV") |
ベストプラクティス：
--dry-runオプションで事前シミュレーションを行い、エラーが無いことを確認してから本番実行する。
Savings Plans と Serverless Savings Plan の統合活用
1. サービス別利用実績集計（H3）
| サービス | 合計稼働時間 (h) | 平均 CPU 使用率 |
|---|---|---|
| EC2 (m5.large) | 720 | 35 % |
| Lambda | 1,200 | - |
| Fargate | 400 | - |
- 取得方法：AWS Cost Explorer の「日次使用量レポート」→CSV ダウンロード → Excel ピボットテーブルで集計
2. Savings Plans シミュレーション（H3）
| プラン種別 | 期間 | 支払オプション | 想定割引率 |
|---|---|---|---|
| Compute Savings Plan | 3 年 | 前払い 100 % | 48 % |
| EC2 Instance Savings Plan (m5 系) | 1 年 | 部分前払い | 42 % |
| Serverless Savings Plan（Lambda/Fargate） | 3 年 | 前払い 50 % | 55 % |
2026 年 4 月に Serverless Savings Plan が正式リリースされ、Step Functions も対象に拡張されたと予想されています。
3. 購入手順（H3）
- コンソール → Savings Plans > Purchase Savings Plans
- 「Compute」タブで期間・支払オプションを選択し見積もりを確認
- 同様に「Serverless」タブから Lambda/Fargate 用プランを作成
4. Reserved Instances（RI）とのハイブリッド戦略（H3）
| 用途 | 推奨プラン |
|---|---|
| ミッションクリティカルなデータベースサーバ | RI（AZ 固定） |
| バッチ処理や開発環境 | Compute Savings Plan |
| イベント駆動の API／バックエンド | Serverless Savings Plan |
留意点：RI は AZ にロックされるため、障害ドメイン分散が必要な場合は同一 AZ 内で冗長構成を作りつつ、Savings Plans で残りの変動ワークロードをカバーする設計が最もコスト効果的です。
Spot Fleet の最新価格モデルとフェイルオーバー自動化
1. Predictive Pricing と Capacity‑Optimized 戦略（H3）
- Predictive Pricing：過去 90 日間の需要・供給データを基に ML が将来価格を予測。
- Capacity‑Optimized Allocation Strategy：最も余裕があるインスタンスタイプへ自動割り当てることで中断率を低減。
2026 年 5 月に Spot のアルゴリズムが更新され、価格予測精度が従来比約30 % 向上すると公表されています。
2. Spot Fleet 設定例（YAML）【H4】
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
SpotFleetRequestConfigData: IamFleetRole: arn:aws:iam::123456789012:role/aws-ec2-spot-fleet-tagging-role AllocationStrategy: capacityOptimized TargetCapacity: 20 SpotPrice: "0.025" # 最大入札価格（USD/時間） LaunchSpecifications: - ImageId: ami-0abcd1234efgh5678 InstanceType: c6g.large SubnetId: subnet-0123abcd WeightedCapacity: 1 TagSpecifications: - ResourceType: instance Tags: - Key: Project Value: FrontEnd |
3. フェイルオーバー自動化フロー（H4）
| 手順 | 実装要素 |
|---|---|
| ① Spot 中断通知 | EventBridge ルール → SNS トピック |
| ② ランチテンプレート更新 | Lambda が受信した通知を元に Auto Scaling Group の DesiredCapacity を増減 |
| ③ ドレイン処理 | Lifecycle Hook + ecs-drain スクリプト（ECS）または kubectl drain（EKS） |
| ④ 代替インスタンス起動 | Lambda が新規 Spot インスタンスを即時リクエスト |
中断通知サンプル（H4）
|
1 2 3 4 5 6 7 8 |
{ "source": ["aws.ec2"], "detail-type": ["EC2 Spot Instance Interruption Warning"], "detail": { "instance-action": ["terminate"] } } |
4. コストシミュレーション例（H3）
| 項目 | オンデマンド価格 (USD/h) | Spot 平均価格 (2026‑05) |
|---|---|---|
| m6i.large | 0.096 | 0.028 |
| 合計稼働時間 (20 インスタンス × 24h × 30日) | 14,400 h | 14,400 h |
- オンデマンド総コスト：$1,382
- Spot 総コスト：$403 → 削減率 71 %
実務上のヒント：
TargetCapacityを過剰に設定しすぎると Spot の供給不足で中断が頻発します。まずは 70‑80 % の稼働率でテストし、徐々にスケールアウトすることを推奨します。
継続的監視・ガバナンス基盤
1. タグポリシーと自動修正（H3）
| ポリシー項目 | 必須キー | 例 |
|---|---|---|
| 環境 | Env |
dev / test / prod |
| チーム | Team |
backend |
| コストセンター | CostCenter |
12345 |
- 実装手順
- Resource Groups Tagging API で組織全体の必須タグリストを作成。
- AWS Config Managed Rule – required-tags を有効化し、未タグ付与リソースを検出。
- 検出時は Lambda が自動的にデフォルトタグ（例：
Env=dev）を付与し、SNS に通知。
2. CloudWatch アラーム設定（H3）
|
1 2 3 4 5 6 7 8 9 10 |
AlarmName: High-EC2-Cost MetricName: EstimatedCharges Namespace: AWS/Billing Statistic: Maximum Period: 86400 # 1日単位 Threshold: 5000 # 月額 $5,000 超過で発火 ComparisonOperator: GreaterThanOrEqualToThreshold AlarmActions: - arn:aws:sns:us-east-1:123456789012:CostAlerts |
- ベストプラクティス：サービス別にアラームを細分化し、
$500単位で閾値を設定すると異常検知が速くなります。
3. Budgets の Anomaly Detection（H3）
| 設定項目 | 推奨値 |
|---|---|
| 予算タイプ | Cost Budget |
| 期間 | 月次 |
| 上限金額 | $10,000（例） |
| 異常検出感度 | High |
| 通知先 | SNS トピック BudgetAnomaly |
- AI が過去 90 日のパターンを学習し、突発的なスパイクだけでなく緩やかな増加も捕捉します。
4. インシデント自動化フロー（H3）
- EventBridge → Budgets アラーム 発火
- Lambda が
Cost Explorerのサービス別コストを取得し、CSV と HTML レポートを生成 - SNS にレポート配信 + Jira/ServiceNow へ自動チケット作成
|
1 2 3 4 5 6 7 8 9 10 11 |
import boto3, json, csv, io def lambda_handler(event, context): ce = boto3.client('ce') resp = ce.get_cost_and_usage( TimePeriod={'Start':'2024-10-01','End':'2024-11-01'}, Granularity='MONTHLY', Metrics=['UnblendedCost'], GroupBy=[{'Type':'DIMENSION','Key':'SERVICE'}] ) # CSV 生成 → SNS + Jira |
5. 定期レビューの実施（H3）
| 頻度 | 内容 |
|---|---|
| 月次 | コストレポートとタグ遵守率を確認し、未適用リソースに対する是正作業 |
| 四半期 | Savings Plans と Spot Fleet の利用率を再シミュレーションし、プラン変更の有無を判断 |
| 年次 | 新機能（例：Serverless Savings Plan）導入可否と ROI を評価 |
まとめ
- データ駆動で現状把握 → Cost Explorer・CUR が基礎
- 未使用リソースは自動削除 → Lambda + EventBridge のフロー化で人的ミスを排除
- AI ライトサイジングで過剰スペックを削減 → Compute Optimizer 推奨をテスト・本番へ段階的導入
- 割引プランは組み合わせが鍵 → Serverless Savings Plan を加えた 3 種類の Savings Plans がベストプラクティス
- Spot Fleet の予測価格と自動フェイルオーバーで変動リソースを最大活用
- ガバナンスはタグ・アラート・Anomaly Detection の３層防御 → 早期検知とインシデント自動化でコスト増加の再発防止
本ロードマップは「すぐに実行できる」チェックリストとしても活用できます。各施策を ① → ② → ③ の順序で導入し、効果測定と改善サイクルを回すことで、2026 年までに AWS コストを 10‑15 % 削減できる可能性が高まります。
スポンサードリンク