クラウド移行を完了した後、数ヶ月以内にコストが想定を超えるケースは珍しくありません。原因の多くは、移行作業そのものではなく、移行前の設計段階で決まっています。本稿では、実際の支援案件で繰り返し見つかる5つのパターンを整理します。
1. ストレージのライフサイクルポリシーが未設定 ¶
S3やGCSでは、オブジェクトの保持期間を設定しないと、不要になったデータが削除されずに蓄積し続けます。ログファイルやバックアップは特に増加しやすく、気づかないうちにストレージコストの大半を占めることがあります。移行時にライフサイクルポリシーを設定するタスクがスコープから漏れているケースが多いです。
2. データ転送コスト（egress）の見落とし ¶
クラウドの料金体系では、データの「入力」は無料または安価ですが、「出力」には費用がかかります。リージョン間の転送、インターネットへの転送、CDNとの連携など、設計段階でデータの流れを整理していないと、egress費用が予算外で発生します。アーキテクチャ図にデータフローを明示することで、事前に試算できます。
3. 開発環境と本番環境の設定が同一 ¶
本番環境の設定をそのままコピーして開発環境を作ると、マルチAZ設定やリザーブドインスタンスの適用外のインスタンスサイズが開発環境にも適用されます。開発環境は夜間・週末に停止するスケジュールを設定するだけで、月次コストを30〜40%削減できる場合があります。
4. 未使用リソースの放置 ¶
移行作業中に作成したテスト用インスタンス、スナップショット、ロードバランサーが、移行完了後も削除されずに残るケースがあります。タグ管理のルールを移行初期に決めておくことで、後から棚卸しがしやすくなります。月次でリソース一覧を確認する習慣が、コスト管理の基本です。
5. リザーブドインスタンスの適用範囲の誤解 ¶
リザーブドインスタンスやSavings Plansは、購入条件と実際の使用パターンが一致しないと割引が適用されません。インスタンスタイプ、リージョン、OSの組み合わせが異なると、オンデマンド料金が発生し続けます。購入前に、過去3ヶ月の使用パターンを確認することを推奨します。
コスト最適化は、ツールによる自動化だけでは完結しません。設計の意図と実際の設定の乖離を定期的に確認する仕組みが必要です。具体的な確認方法については、初回相談でお伝えできます。