aws-cost-optimization

AWS のコスト最適化と FinOps

AWS のコスト最適化と財務オペレーション管理のための体系的なワークフローです。

コスト最適化のワークフロー

1. 発見 — aws ec2 と aws ce の CLI コマンドを使って、未使用のリソースやコストの異常を特定し、無駄を見つけます
2. 分析 — aws compute-optimizer、aws cloudwatch、aws ce を使って、適正化、世代のアップグレード、Spot、RI の推奨事項など、コスト削減の機会を見つけます
3. 優先順位付け — まず、リスクが低く削減効果の高い手早く実施できる施策に取り組み、次に簡単に実行できる施策、最後に戦略的な改善に取り組みます
4. 実施 — 未使用のリソースを削除し、インスタンスを適正化し、コミットメントを購入し、世代を移行します
5. 監視 — 毎月のコストレビュー、タグの準拠状況、予算との差異を追跡します

---

コアワークフロー

ワークフロー 1：毎月のコスト最適化レビュー

頻度：毎月実施します（月の第 1 週）

ステップ 1：未使用のリソースを見つける

# Find unattached EBS volumes
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].{ID:VolumeId,Size:Size,Created:CreateTime}' --output table

# Find unused Elastic IPs
aws ec2 describe-addresses --filters Name=domain,Values=vpc \
  --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' --output table

# Find idle EC2 instances (low CPU over 14 days)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
  --metric-name CPUUtilization --period 86400 --statistics Average \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --dimensions Name=InstanceId,Value=INSTANCE_ID

# Find old snapshots (>90 days)
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-01-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' --output table

# Find unused load balancers (no healthy targets)
aws elbv2 describe-target-health --target-group-arn TARGET_GROUP_ARN

ステップ 2：コストの異常を分析する

# Get daily costs for the past 30 days
aws ce get-cost-and-usage \
  --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --granularity DAILY --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Get cost forecast for the next 30 days
aws ce get-cost-forecast \
  --time-period Start=$(date -u +%Y-%m-%d),End=$(date -u -v+30d +%Y-%m-%d) \
  --granularity MONTHLY --metric BLENDED_COST

# Compare month-over-month costs
aws ce get-cost-and-usage \
  --time-period Start=$(date -u -v-60d +%Y-%m-01),End=$(date -u +%Y-%m-%d) \
  --granularity MONTHLY --metrics BlendedCost

ステップ 3：適正化の機会を特定する

# Get Compute Optimizer rightsizing recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].{Instance:instanceArn,Finding:finding,Current:currentInstanceType,Recommended:recommendationOptions[0].instanceType}'

# Check CPU utilization for a specific instance (past 30 days)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
  --metric-name CPUUtilization --period 3600 --statistics Average Maximum \
  --start-time $(date -u -v-30d +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --dimensions Name=InstanceId,Value=INSTANCE_ID

# Get RDS rightsizing recommendations
aws compute-optimizer get-ecs-service-recommendations 2>/dev/null || \
  echo "Check RDS CPU/memory in CloudWatch manually"

ステップ 4：月次レポートを作成する

# Use the template to compile findings
cp assets/templates/monthly_cost_report.md reports/$(date +%Y-%m)-cost-report.md

# Fill in:
# - Findings from AWS CLI analysis
# - Action items
# - Team cost breakdowns
# - Optimization wins

ステップ 5：チームレビューミーティング

• 調査結果をエンジニアリングチームに共有します
• 最適化タスクを割り当てます
• アクション項目の完了まで進捗を追跡します

---

ワークフロー 2：コミットメント購入の分析（RI／Savings Plans）

タイミング：四半期ごと、または使用状況が安定したとき

ステップ 1：現在の使用状況を分析する

# Get EC2 RI purchase recommendations
aws ce get-reservation-purchase-recommendation --service "Amazon Elastic Compute Cloud - Compute" \
  --lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT

# Get RDS RI purchase recommendations
aws ce get-reservation-purchase-recommendation --service "Amazon Relational Database Service" \
  --lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT

# Get Savings Plans recommendations
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP --lookback-period-in-days SIXTY_DAYS \
  --term-in-years ONE_YEAR --payment-option NO_UPFRONT

ステップ 2：推奨事項を確認する

推奨事項をそれぞれ評価します：

✅ Good candidate if:
  - Running 24/7 for 60+ days
  - Workload is stable and predictable
  - No plans to change architecture
  - Savings > 30%

❌ Poor candidate if:
  - Workload is variable or experimental
  - Architecture changes planned
  - Instance type may change
  - Dev/test environment

ステップ 3：コミットメントの種類を選ぶ

リザーブドインスタンス：

• Standard RI：最大の割引（63％）ですが、柔軟性はありません
• Convertible RI：中程度の割引（54％）で、インスタンスタイプを変更できます
• 最適な用途：特定のインスタンスタイプ、安定したワークロード

Savings Plans：

• Compute SP：インスタンスタイプやリージョンをまたいで柔軟に利用できます（66％の節約）
• EC2 Instance SP：同じファミリー内でサイズを柔軟に選べます（72％の節約）
• 最適な用途：制約の範囲内で変動するワークロード

判断マトリックス：

Known instance type, won't change → Standard RI
May need to change types → Convertible RI or Compute SP
Variable workloads → Compute Savings Plan
Maximum flexibility → Compute Savings Plan

ステップ 4：購入して追跡する

• AWS Console または CLI から購入します
• 購入日と所有者をコミットメントにタグ付けします
• 毎月、利用率を監視します
• 利用率 90％超を目指します

参考：コミットメント戦略の詳細については、references/best_practices.md を参照してください

---

ワークフロー 3：インスタンス世代の移行

タイミング：アーキテクチャレビュー中、または最適化スプリント中

ステップ 1：古いインスタンスを検出する

# Find old-generation instances (t2, m4, c4, r4, etc.)
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[?starts_with(InstanceType, `t2.`) || starts_with(InstanceType, `m4.`) || starts_with(InstanceType, `c4.`) || starts_with(InstanceType, `r4.`)].{ID:InstanceId,Type:InstanceType,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

# Find all running instance types to review generations
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table
# Look for: t2→t3, m4→m6i, c4→c6i, r4→r6i, Intel→Graviton (20% savings)

ステップ 2：移行の優先順位を決める

手早く実施できる施策（低リスク）：

t2 → t3: Drop-in replacement, 10% savings
m4 → m5: Better performance, 5% savings
gp2 → gp3: No downtime, 20% savings

中程度の作業（テストが必要）：

x86 → Graviton (ARM64): 20% savings
- Requires ARM64 compatibility testing
- Most modern frameworks support ARM64
- Test in staging first

ステップ 3：移行を実行する

EC2 の場合（x86 から x86）：

1. インスタンスを停止します
2. インスタンスタイプを変更します
3. インスタンスを起動します
4. アプリケーションを検証します

Graviton への移行の場合：

1. ARM64 AMI または Docker イメージを作成します
2. 新しい Graviton インスタンスを起動します
3. 十分にテストします
4. トラフィックを切り替えます
5. 古いインスタンスを終了します

ステップ 4：削減効果を検証する

• Cost Explorer で新しいコストを監視します
• パフォーマンスに問題がないことを確認します
• 他のチーム向けに移行内容を文書化します

参考：references/best_practices.md → Compute Optimization を参照してください

---

ワークフロー 4：スポットインスタンスの評価

対象：耐障害性が求められるワークロードや Auto Scaling グループ

ステップ 1：候補を特定する

# Check current Spot pricing vs On-Demand for target instance types
aws ec2 describe-spot-price-history --instance-types m5.large m5.xlarge m6i.large \
  --product-descriptions "Linux/UNIX" --start-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --query 'SpotPriceHistory[].{Type:InstanceType,AZ:AvailabilityZone,Price:SpotPrice}' --output table

# List Auto Scaling Groups (good Spot candidates)
aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[].{Name:AutoScalingGroupName,Min:MinSize,Max:MaxSize,Desired:DesiredCapacity}' --output table

# Check which ASGs already use mixed instances (Spot)
aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[?MixedInstancesPolicy!=null].AutoScalingGroupName'

スポットの候補：ASG 内のインスタンス、開発／テスト／ステージング環境、バッチ処理、CI/CD サーバーです。

ステップ 2：適性を評価する

スポットに最適：

• ステートレスアプリケーション
• バッチジョブ
• CI/CD パイプライン
• データ処理
• Auto Scaling グループ

スポットに不適：

• データベース（レプリカがない場合）
• ステートフルアプリケーション
• リアルタイムサービス
• ミッションクリティカルなワークロード

ステップ 3：実装戦略

オプション 1：Fargate Spot -- capacityProviderStrategy に FARGATE_SPOT の重み 70、FARGATE の重み 30 を設定します。

オプション 2：Spot を使用した EC2 Auto Scaling -- OnDemandBaseCapacity: 2、OnDemandPercentageAboveBaseCapacity: 30、SpotAllocationStrategy: capacity-optimized を指定した MixedInstancesPolicy を使用し、複数のインスタンスタイプのオーバーライド（m5.large、m5a.large、m5n.large）を設定します。

オプション 3：EC2 Spot Fleet -- aws ec2 request-spot-fleet --spot-fleet-request-config file://spot-fleet.json

ステップ 4：中断処理を実装する -- /latest/meta-data/spot/instance-action のインスタンスメタデータをポーリングし、2 分前の終了通知を確認します。通知を受けたら、正常にシャットダウンし、状態を保存して、接続をドレインしてから終了します。

参考資料：references/best_practices.md → Compute Optimization → Spot Instances

---

クイックリファレンス

AWS CLI コマンドを直接使用します。Claude Code は aws ce、aws ec2、aws cloudwatch、aws compute-optimizer コマンドを実行して、コスト分析を行えます。

月次レビュー用コマンド：

• aws ec2 describe-volumes --filters Name=status,Values=available（未使用のボリューム）
• aws ce get-cost-and-usage --granularity DAILY --metrics BlendedCost（コストの傾向）
• aws compute-optimizer get-ec2-instance-recommendations（適正サイズへの変更）

四半期ごとの最適化用コマンド：

• aws ce get-reservation-purchase-recommendation --service EC2（RI の分析）
• aws ec2 describe-instances にインスタンスタイプのフィルターを指定（旧世代のインスタンス）
• aws ec2 describe-spot-price-history（スポット料金）

必要に応じて、任意の AWS CLI コマンドに --region REGION と --profile PROFILE を追加します。

---

サービス別の最適化

コンピューティングの最適化

主なアクション：

• Graviton に移行する（20% の節約）
• 耐障害性が求められるワークロードに Spot を使用する（70% の節約）
• 安定したワークロードに RI を購入する（40～65% の節約）
• 過剰なサイズのインスタンスを適正化する

参考資料：references/best_practices.md → Compute Optimization

ストレージの最適化

主なアクション：

• gp2 から gp3 に変換する（20% の節約）
• S3 ライフサイクルポリシーを実装する（50～95% の節約）
• 古いスナップショットを削除する
• S3 Intelligent-Tiering を使用する

参考資料：references/best_practices.md → Storage Optimization

ネットワークの最適化

主なアクション：

• NAT Gateway を VPC エンドポイントに置き換える（各月 25～30 ドルの節約）
• CloudFront を使用してデータ転送コストを削減する
• 可能な場合は、同じ AZ 内にリソースを配置する

参考資料：references/best_practices.md → Network Optimization

データベースの最適化

主なアクション：

• RDS インスタンスのサイズを適正化する
• gp3 ストレージを使用する（gp2 より 20% 安価）
• ワークロードの変動が大きい場合は Aurora Serverless を評価する
• RDS リザーブドインスタンスを購入する

参考資料：references/best_practices.md → Database Optimization

---

サービス代替案の選択ガイド

サービスの選択でお困りですか？

質問：「EC2、Lambda、Fargate のどれを使うべきですか？」 回答：references/service_alternatives.md → Compute Alternatives を参照してください。

質問：「どの S3 ストレージクラスを使うべきですか？」 回答：references/service_alternatives.md → Storage Alternatives を参照してください。

質問：「RDS と Aurora のどちらを使うべきですか？」 回答：references/service_alternatives.md → Database Alternatives を参照してください。

質問：「NAT Gateway、VPC Endpoint、NAT Instance のどれを使うべきですか？」 回答：references/service_alternatives.md → Networking Alternatives を参照してください。

---

FinOps ガバナンスとプロセス

3 段階で導入します。（1）基盤 -- Cost Explorer を有効にし、Budgets を設定して、タグ付け戦略を定義します。（2）可視化 -- タグを適用し、AWS CLI のコスト分析コマンドを実行して、月次レビューを設定します。（3）文化 -- エンジニアリングの KPI にコスト指標を組み込み、アーキテクチャレビューや最適化スプリントを実施します。

ガイド全文：references/finops_governance.md

月次レビュープロセス

第 1 週：データ収集

• AWS CLI のコスト分析コマンドを実行します（ワークフロー 1 を参照）
• コストと使用状況レポートをエクスポートします
• 調査結果をまとめます

第 2 週：分析

• 傾向を特定します
• 改善の機会を探します
• 対応の優先順位を決めます

第 3 週：チームレビュー

• エンジニアリングチームに報告します
• 最適化について話し合います
• アクション項目を割り当てます

第 4 週：経営陣への報告

• 経営陣向けの概要を作成します
• 次の四半期を予測します
• 最適化の成果を報告します

テンプレート：assets/templates/monthly_cost_report.md を参照してください

詳細なプロセス：references/finops_governance.md → 月次レビュープロセスを参照してください

---

コスト最適化チェックリスト

すぐにできること（最初に実施）

• 未接続の EBS ボリュームを削除する
• 古い EBS スナップショット（90 日超）を削除する
• 使用していない Elastic IP を解放する
• gp2 ボリュームを gp3 に変換する
• アイドル状態の EC2 インスタンスを停止／終了する
• S3 Intelligent-Tiering を有効にする
• AWS Budgets とアラートを設定する

中程度の労力（今四半期に実施）

• 過剰なサイズのインスタンスを適正化する
• より新しい世代のインスタンスに移行する
• 安定したワークロード向けに Reserved Instances を購入する
• S3 ライフサイクルポリシーを実装する
• NAT Gateway を VPC エンドポイントに置き換える（該当する場合）
• リソースのスケジュールを自動化する（開発／テスト）
• タグ付け戦略と適用を実装する

戦略的な取り組み（継続的に実施）

• Graviton インスタンスに移行する
• 耐障害性のあるワークロードに Spot を導入する
• 月次コストレビュープロセスを確立する
• チームごとのコスト配分を設定する
• チャージバック／ショーバックモデルを実装する
• FinOps の文化と実践を築く

---

コストに関する問題のトラブルシューティング

「請求額が突然増加しました」

1. サービス別の日次コスト内訳を確認します：

   aws ce get-cost-and-usage \
     --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
     --granularity DAILY --metrics BlendedCost \
     --group-by Type=DIMENSION,Key=SERVICE
   

2. AWS コンソールの Cost Explorer で視覚的な内訳を確認します

3. CloudTrail でリソース作成イベントを確認します

4. Auto Scaling イベントを確認します

5. Reserved Instances の期限が切れていないことを確認します

「コストを X% 削減する必要があります」

最適化ワークフローに従います：

1. 上記のワークフロー 1 の検出コマンドを実行します（未使用のリソース、コストの異常、適正化）
2. 削減可能な総額を計算します
3. 削減額 ×（1 / 労力）で優先順位を決めます
4. まず、すぐにできることに集中します
5. 長期的な効果を得るために、戦略的な変更を実施します

「Reserved Instances が適切かどうか、どうすればわかりますか？」

RI 分析を実行します：

aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT

次の点を確認します：

• 60 日以上にわたり継続して稼働しているインスタンス
• 変更される予定のないワークロード
• 30% を超える削減効果

「安全に削除できるリソースはどれですか？」

未使用のリソースを見つけます：

aws ec2 describe-volumes --filters Name=status,Values=available --output table
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null]' --output table
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-01-01`]' --output table

通常、安全に削除できるもの：

• 未接続の EBS ボリューム（確認後）
• 90 日を超えるスナップショット（別の場所にバックアップがある場合）
• 未使用の Elastic IP（DNS で使用されていないことを確認後）
• 30 日を超えて停止している EC2 インスタンス（放棄されたことを確認後）

削除する前に、必ずリソースの所有者に確認してください！

---

追加リソース

参考資料：references/best_practices.md | references/service_alternatives.md | references/finops_governance.md

テンプレート：assets/templates/monthly_cost_report.md

CLI ツール：AWS CLI コマンドを直接使用します。Claude Code は aws ce、aws ec2、aws cloudwatch、aws compute-optimizer コマンドを実行して、コスト分析を行えます。追加の依存関係は必要ありません。