EFS緊急対応で1万円使った話 ― 知らなかったElastic Throughputのコスト差
TL;DR
JenkinsのEFS障害対応で、プロビジョンドスループット300 MiB/sを26時間使用し、約$69（1万円）のコストが発生しました。Elastic Throughputを選択していれば約$3.5（500円）で済んだ計算です。緊急時こそ冷静なコスト試算が重要だと学びました。
背景：EFS障害からの緊急対応
先日、「JenkinsがGitクローンできなくなった原因 - EFSメタデータIOPSとGit一時ファイルの蓄積」という記事を公開しました。EFSのメタデータIOPS枯渇によりJenkinsが停止し、緊急対応としてプロビジョンドスループット 300 MiB/s に変更した、という内容です。
技術的には解決できたのですが、翌日Cost Explorerを見て驚きました。
「$69.00」 — 26時間で約1万円です。
EFSの3つのスループットモード
改めて整理すると、EFSには以下の3つのスループットモードがあります：
1. バーストスループット
料金: ストレージ料金のみ
ストレージ容量に応じてスループットが決まります。クレジット制で、低負荷時に貯めて高負荷時に使う仕組みです。
- メリット: 追加料金なし
- デメリット: クレジット枯渇で性能低下（今回の問題）
2. プロビジョンドスループット
料金: ストレージ料金 + スループット料金
東京リージョンでは1 MiB/sあたり約$7.2/月です。
300 MiB/sの場合：
- 月額: 300 × $7.2 = $2,160
- 26時間: $2,160 × (26/720) ≈ $78
実測は$69だったので、ベースラインスループット分が差し引かれたと思われます。
- メリット: 安定した性能
- デメリット: 非常に高額
3. Elastic Throughput
料金: ストレージ料金 + 実際に使用したスループット分
東京リージョンでは：
-
読み込み: $0.04/GB
-
書き込み: $0.07/GB
-
メリット: 使った分だけ課金、自動スケール
-
デメリット: 使用量が読めないと予算管理が難しい
コスト比較
今回のケース（26時間、調査中に約50GB使用と仮定）で試算：
| モード | 26時間のコスト | 備考 |
|---|---|---|
| バースト | $5.6（月額分） | クレジット枯渇で調査不可 |
| プロビジョンド | $69 | 実際に選択 |
| Elastic | $3.5〜$5 | 知らなかった |
差額: 約$64〜$66（約9,000〜9,500円）
Elastic Throughputを選択していれば、約20分の1のコストで済みました。
なぜElastic Throughputを選ばなかったか
緊急対応時、私の頭にあった選択肢は以下の2つだけでした：
- バーストモード継続 → クレジット枯渇で調査不可
- プロビジョンドモード → 高いが確実
実は、Elastic Throughputは2022年に発表された比較的新しいモードです。ただ、知らなかったのは知識のアップデート不足でした。
緊急時だからこそ、「他に選択肢はないか？」と一度立ち止まって調べるべきでした。
判断の妥当性
ただし、費用対効果で見ると判断自体は悪くありませんでした。
回避できた損失（推定）:
- 開発チーム10名 × 3時間待機 = 30人時
- 時給5,000円として: 30人時 × 5,000円 = 150,000円
発生コスト:
- プロビジョンドスループット: 10,000円
ROI: 約15倍
ビジネス継続性を優先した判断は正しかったものの、より低コストな選択肢があったのも事実です。
学びと改善
1. Elastic Throughputの活用
今後はElastic Throughputを第一選択肢として運用します。
- スパイク対応に最適
- 使用量課金で予測可能
- 自動スケールで安心
2. 緊急時こそコスト試算
「とりあえず動かす」だけでなく：
- 選択肢を複数検討
- コストインパクトを比較
- 知らないオプションがあるかもしれないと疑う
3. 監視強化
- EFSメトリクスの定常監視
- スループット利用率75%超過でアラート
- 早期検知による予防保守
まとめ
$69（約1万円）は高い授業料でしたが、以下の価値を得られました：
- EFSの料金体系への深い理解
- 緊急時の意思決定プロセスの改善
- Elastic Throughputという最適解の発見
もし同じ状況に遭遇したら、次は迷わずElastic Throughputを選びます。
トラブル対応は技術的な解決だけでなく、コスト説明責任や組織への知見還元まで含めて「仕事」だと実感した事例でした。
こうした技術選定や実装の判断プロセスを、
エンジニア向けにもう少し整理して書いています。
Discussion