AWS コスト最適化の判断基準(購入オプション・Savings Plans・Cost Explorer・インスタンス選定)
Savings Plans は「使い放題」ではなく時間単位コミットの前払い。ベースラインだけコミットし、山は Spot とオンデマンドで吸収する。インスタンスは Graviton と最新世代、EBS は gp3。コスト配分タグは Billing で有効化しないと集計に出ず、過去には遡らない。
調査時点: 2026-07。料金・割引率・期間は当時の値。
Savings Plans は、1 時間あたりの利用額を 1 年または 3 年の契約期間中に支払うと約束する代わりに、対象の AWS 利用料金に割引を受ける料金プラン。
EC2 インスタンスの選定
t2.micro は「ファミリー.世代.サイズ」。サイズが 1 段上がると vCPU / メモリは通常 2 倍。
| カテゴリ | ファミリー | 覚え方 | 用途 |
|---|---|---|---|
| 汎用 | T、M、A、Mac | Turbo(バースト)、Middle(基準) | T は CPU クレジットで必要時だけバースト。M はバランス型 |
| 計算最適化 | C | Compute | バッチ、高負荷 Web、安定した計算 |
| メモリ最適化 | R、X、z | RAM | インメモリ DB、ビッグデータ |
| ストレージ最適化 | I、D、H | I/O | 高ランダム I/O(I)、大容量 HDD スループット(D / H) |
| 高速コンピューティング | P、G、F、Inf | Graphic / Inference | GPU / FPGA、機械学習、推論 |
コストで最終判断するときの優先順位: Arm(Graviton、A ファミリーや M6g など。当時最大 45% 削減)、定常負荷がなければ T、常に最新世代。
Dedicated Instance と Dedicated Host
| 比較 | ハードウェア専有インスタンス | 専有ホスト |
|---|---|---|
| 分離 | 他社アカウントとは物理ホストを共有しない。同一アカウント内の共有は可 | 物理サーバー 1 台を丸ごと専有 |
| 費用 | 安い | 高い |
| 用途 | 他社との物理分離が要件 | ソケット / コア単位のライセンス(BYOL) |
購入オプション
| オプション | 割引 | 縛り | 中断リスク | 用途 |
|---|---|---|---|---|
| オンデマンド | 0%(基準) | なし(秒課金) | なし | 短期、テスト、予測不能な負荷 |
| Savings Plans | 最大 72% | 1 年 / 3 年(金額の枠) | なし | 24 時間 365 日のベースライン |
| リザーブドインスタンス | 最大 72% | 1 年 / 3 年(台数の枠) | なし | 同上(柔軟な Savings Plans が主流) |
| Spot | 最大 90% | なし | あり(空き容量次第) | 耐障害性のあるバッチ、分散処理、コンテナ |
Savings Plans は「使い放題」ではない
全払い(All Upfront)でも、買ったのは「1 時間あたり $X 分」の時間単位コミットの前払い。回数券のまとめ買いであって、乗り放題ではない。
- コミット $1.00/時で $0.50 しか使わなかった時間 → 差額 $0.50 は消える(繰り越し・返金なし)
- $3.00 使った時間 → $1.00 分は割引適用、残り $2.00 はオンデマンド料金で秒課金
したがって Cost Explorer の推奨を見て「絶対に止めないベースライン(床)」の金額だけコミットし、スパイク(山)はオンデマンドや Spot でいなす。
| プラン | 範囲 | 柔軟性 | 割引(当時) |
|---|---|---|---|
| Compute SP | EC2、Fargate、Lambda | 最高。OS・ファミリー・リージョン変更に追従 | 最大 66% |
| EC2 Instance SP | EC2 のみ | リージョンとファミリーを固定。サイズ・OS は自由 | 最大 72% |
| SageMaker SP | SageMaker | 中 | 最大 64% |
| Database SP | RDS、Aurora、OpenSearch など | 中 | 最大 35% |
期間は 3 年が最安だが解約不可。支払いは全払い(最高割引)、半払い、なし(最低割引)。
Spot の中断設計
回収の 2 分前に警告が出る。この 2 分で退避する。
| 中断動作 | 挙動 |
|---|---|
| terminate(デフォルト) | 削除。ステートレス処理向け |
| stop | 停止。EBS は保持され、空きが戻れば再開 |
| hibernate | メモリを EBS ルートに書き出して一時停止。処理途中から復帰できる。ルート EBS の暗号化と対応 OS / インスタンスタイプが条件 |
検知は 2 通り。EventBridge で EC2 Spot Instance Interruption Warning を受けて Lambda で ALB から登録解除し代替を起動する(推奨)か、インスタンス内から IMDSv2 の /latest/meta-data/spot/instance-action をポーリングする。
Cost Explorer
- 標準で当月を含む過去 13 か月を分析でき、予測は将来 12 か月(履歴 + 予測で最大 25 か月)
- 複数年データ機能(無料でオプトイン)で月単位の履歴を最大 38 か月に延長
- 2025 年 11 月の更新で予測が最大 18 か月先に拡張され、履歴 38 + 予測 18 = 56 か月を一元分析できるようになったと記録(時系列は要確認)
- 有効化直後は当月データの表示に最大 24 時間、それ以外の履歴全体のインデックスに数日かかる
- 時間単位の分析や API クエリは有料
コスト配分タグ
普通のタグと文字列は同じで、Billing コンソールで「有効化(アクティベート)」したかどうかだけが違う。
- 有効化前の過去データには遡らない。タグでコストを見たいと分かった時点で先に有効化する
- CloudFormation の
Tagsプロパティで付与はできるが、「コスト配分タグとして有効化」は標準リソースでは自動化できない(カスタムリソースでUpdateCostAllocationTagsStatusを呼ぶか、デプロイ後に手動) - CloudFormation が自動付与する
aws:cloudformation:stack-nameを有効化するだけで、スタックごとの合計コストが見える
予算超過はAWS Budgets、異常な増加はコスト異常検出で、いずれも SNS 経由で通知する。
ストレージとネットワークのコスト
| 対象 | 手段 |
|---|---|
| EBS | gp2 → gp3(ベースライン性能とコストの両方で有利) |
| S3 | ライフサイクルで安価なストレージクラスへ自動移行。大規模復元は Glacier の Bulk 取り出し |
| EFS | IA へのライフサイクル |
| アウトバウンド(IPv6) | Egress-Only IGW は無料。NAT Gateway は時間 + 処理量課金 |
| AWS サービスへの通信 | プライベートサブネットからは VPC エンドポイントで NAT の処理料金を回避 |
| VPC 間接続 | 10 VPC 未満ならピアリング(無料)。TGW はアタッチメント固定費 + 処理量 |
| DNS | Route 53 エイリアスへのクエリは無料 |
| データ転送 | インターネットへの転送は当時月 100GB まで無料枠 |
監視系のコスト
- Managed Grafana は「1 ワークスペース × 1 アクティブユーザー」ごとの月額。ワークスペースを統合し、閲覧者は Viewer にする
- Metrics Insights はコンソール実行が無料、API 経由が従量、アラーム組み込みが固定。自動更新ダッシュボードは全メトリクスをスキャンし続ける。CloudWatch の監視設計
- CloudTrail のデータイベントは高度なイベントセレクターで対象を絞る。アクセス制御と監査
- Amazon Q Developer は無料枠と Pro(当時 19 USD/ユーザー/月。学習不使用の保証と Identity Center 連携)の 2 プラン
ElastiCache のメモリ不足対策
エビクション(追い出し)が急増し、ホットデータを保持したいとき。
- コストをかけない: パラメータグループでエビクションポリシーを
allkeys-lruにし、アクセスのない古いデータから捨てる - 容量の根本解決: ノードタイプをスケールアップ。クラスターモード有効ならシャード追加でスケールアウト
- 選ばない:
noeviction(メモリ不足で OOM エラーになる)、TTL の一律変更(ホットデータも消える、または古いデータが残る)、定期的なFLUSHALL(DB にアクセスが集中する)
Serverless と Redis 互換の Valkey が運用負荷の少ない選択肢になっている。
関連
更新履歴
- 2026-07-18: 初版(ローカル調査ノート)
- 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加
出典
同じトピック — AWS
- バックアップ・DR・可用性設計の判断基準(RTO/RPO・AWS Backup・RDS/Aurora・Auto Scaling)
- CloudFormation と CDK によるデプロイ設計(変更セット・DeletionPolicy・StackSets・Construct)
- CloudWatch の監視設計(メトリクス階層・アラーム・ログ分析の使い分け)
- コンテナ監視の設計(AMP / Managed Grafana / CloudWatch Observability / Fargate の制約)
- EventBridge と自動修復の設計パターン
- AWS のアクセス制御と監査の判断基準(IAM / SCP / KMS / CloudTrail)
- SOA-C03(AWS Certified CloudOps Engineer - Associate)の試験構成と学習の進め方
- Systems Manager の運用自動化(マネージドノード・Run Command・Automation・Patch Manager)
- VPC ネットワークとコンテンツ配信の設計判断(SG / NACL / NAT / TGW / CloudFront / Route 53)