2026年版AWSコスト最適化ロードマップと5つの実践施策

Contents

1 全体像と基本戦略
2 未使用リソースの自動検出・削除
- 2.1 1. 最新レポート取得手順
- 2.2 2. Lambda と CloudWatch Events による自動削除フロー
3 AI が導くライトサイジング（Compute Optimizer）
4 Savings Plans と Serverless Savings Plan の統合活用
5 Spot Fleet の最新価格モデルとフェイルオーバー自動化
6 継続的監視・ガバナンス基盤
7 まとめ

スポンサードリンク

全体像と基本戦略

フェーズ	主な施策	期待効果
① データ収集	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）

# 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

# 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）

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='未使用リソースの削除が完了しました。'
    )

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）

#!/usr/bin/env bash
CSV=rightsizing.csv
while IFS=, read -r iid cur_type rec_type ; do
    echo &quot;&#x27a1; ${iid}: ${cur_type} → ${rec_type}&quot;
    aws ec2 modify-instance-attribute \
        --instance-id &quot;$iid&quot; \
        --instance-type &quot;{\&quot;Value\&quot;:\&quot;${rec_type}\&quot;}&quot;
done &lt; &lt;(tail -n +2 &quot;$CSV&quot;)

#!/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】

SpotFleetRequestConfigData:
  IamFleetRole: arn:aws:iam::123456789012:role/aws-ec2-spot-fleet-tagging-role
  AllocationStrategy: capacityOptimized
  TargetCapacity: 20
  SpotPrice: &quot;0.025&quot;          # 最大入札価格（USD/時間）
  LaunchSpecifications:
    - ImageId: ami-0abcd1234efgh5678
      InstanceType: c6g.large
      SubnetId: subnet-0123abcd
      WeightedCapacity: 1
      TagSpecifications:
        - ResourceType: instance
          Tags:
            - Key: Project
              Value: FrontEnd

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）

{
  &quot;source&quot;: [&quot;aws.ec2&quot;],
  &quot;detail-type&quot;: [&quot;EC2 Spot Instance Interruption Warning&quot;],
  &quot;detail&quot;: {
    &quot;instance-action&quot;: [&quot;terminate&quot;]
  }
}

{

"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）

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

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 へ自動チケット作成

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

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 % 削減できる可能性が高まります。

スポンサードリンク