社内のサーバーからAWSなどのクラウドへ移したのに、毎月の請求額が移行前より増えている。「クラウドは安くなると聞いていたのに」と戸惑う担当者の方は少なくありません。
「クラウドに移行したらサーバー代が今より高くなった。移行前に何を比べておけばよかったのか知りたい」
先に結論をお伝えします。クラウドが高く見える一番の原因は、移行前に「サーバー代だけ」を比べてしまうことです。社内サーバーにかかっていた電気代・保守費・担当者の作業時間・買い替え費用まで含めて、同じ物差しで並べて初めて「安い・高い」が判断できます。
この記事では、クラウド移行前後で比べておきたい5つの費用と、移行後に請求額を見直すときの進め方を、開発会社にそのまま聞ける質問例とあわせて解説します（執筆時点：2026年10月）。なお、そもそも移行すべきかどうかの判断軸は、オンプレの業務システムをAWSへ移行すべき？費用とリスクを判断する5つの視点で整理しています。
移行後に「高くなった」と感じる3つの理由
見直しの前に、なぜ高く感じるのかを押さえましょう。原因が分かると、どこを確認すればいいかも見えてきます。
理由1：社内サーバーの「見えない費用」が比較に入っていない
社内サーバーは、購入したあとの電気代や空調、保守契約、担当者の作業時間が、請求書として「サーバー代」の名前で見えにくい形で存在します。一方、クラウドは使った分がすべて毎月の請求書に出てきます。見えていなかった費用が見えるようになっただけというケースもあります。
理由2：今の使い方より大きめの構成で動かしている
移行を急ぐと、社内サーバーと同じ性能（＝サーバーの大きさ）をそのままクラウドに用意しがちです。AWSは、アプリを変更せずそのまま移す方法（リホスト、いわゆる「リフト＆シフト」）について、クラウド向けの最適化を行わない分、後からの見直しがしやすくなると説明しています。
📰 出典：AWS Prescriptive Guidance「About the migration strategies」
つまり「まずそのまま移す」のは正しい選択肢の一つですが、移した直後は節約の余地を残したままの状態です。移行後の見直しまでを計画に入れておかないと、高いまま続いてしまいます。
理由3：使っていない時間も課金されている
クラウドは使った分だけ払う仕組みですが、サーバーを立ち上げている間は、誰も使っていない夜間や休日も課金されます。社内サーバーは「24時間つけっぱなしでも追加費用が増えない」感覚だったため、この違いに気づきにくいのです。
移行前に並べて比べておきたい5つの費用
1. 今のサーバーの「年あたり」の総額
購入費用だけでなく、1年あたりに直して並べます。
- サーバー本体・ストレージの購入費（耐用年数で割って1年分に）
- 電気代・空調・設置スペース
- 保守契約（ハードの保守、OSやソフトのライセンス更新）
- 数年ごとの買い替え・OS更新の費用
2. 運用する人の作業時間
バックアップ、更新作業、障害対応など、担当者が今かけている時間を洗い出します。情シス兼任の方の場合、本業の合間の作業ほど記録に残らず、見落としやすい項目です。
3. クラウドの毎月費用（使い方まで想定して）
AWSは、構成を決めたうえで費用を見積もるツールとして「AWS Pricing Calculator」を案内しています。サーバーの大きさ・台数・稼働時間・データ量・通信量を入れて試算します。
📰 出典：AWS「Cloud Cost Optimization」
ポイントは、サーバー本体だけでなく、データベース、バックアップ、通信料金（外へ出るデータ量）、監視なども含めて見積もることです。ここが抜けると、請求が始まってから想定外の項目が増えます。
4. 移行そのものの一回きりの費用
見落としやすいのが移行作業の費用です。
- 移行の作業費（開発会社への依頼分）
- 移行中、社内サーバーとクラウドを並行して動かす期間の二重払い
- 動作確認・社内説明・教育にかかる時間
5. 移行後も続く「見直し」の費用
クラウドは、移して終わりではなく、使い方に合わせて調整し続けるほど安くなる性質があります。AWS Well-Architectedフレームワークのコスト最適化の柱も、コスト管理を一度きりでなく継続して行う（Cloud Financial Management）考え方を示しています。
📰 出典：AWS Well-Architected Framework「Cost Optimization Pillar」
月に一度、請求の内訳を見て調整する作業を「誰が・月何時間やるか」まで決めておくと、後から困りません。
移行後に請求額を見直す4ステップ
すでに移行済みで、請求額が気になる方向けの進め方です。専門的な調整は開発会社に依頼する前提で、発注者は「何を頼むか」が分かれば十分です。
ステップ1：請求の内訳を項目別に見る
AWSには、費用を項目別・期間別に見られる「Cost Explorer」があります。まず「どのサービスにいくらかかっているか」を一覧にしてもらいましょう。大きい項目から順に確認すれば、見直す場所が絞れます。
ステップ2：使っていないものを止める
誰も使っていないサーバーや、移行時の一時的なコピーが残っていないかを確認します。AWSの移行ガイドでも、利用率が極端に低いアプリケーションは廃止（Retire）や維持（Retain）の候補として扱われています。使われていないものにお金を払い続けない、という基本の確認です。
ステップ3：サーバーの大きさと稼働時間を実際の使い方に合わせる
実際の使用量を見て、大きすぎるサーバーを小さくする、夜間や休日は止める、といった調整をします。業務システムは「平日の日中だけ使う」ものが多く、効果が出やすい部分です。ただし、止めることで業務に支障が出ないか、止める・起動する手順が誰でも分かるかは、事前に確認が必要です。
ステップ4：使う量が安定していれば、割引の仕組みを検討する
AWSには、一定期間の利用を約束する代わりに料金が下がる「Savings Plans」「リザーブドインスタンス」といった仕組みがあり、公式ページでは最大72%の割引と説明されています。ただし、これは使う量が長く安定している場合の話で、割引率は条件によって変わります。構成が固まる前に約束してしまうと、使わない分まで払う可能性があります。
やりがちな失敗
- サーバー代だけで比較する：運用の人件費や買い替え費を入れずに「高い・安い」を決めてしまう
- 移行後の見直しを誰もやらない：開発会社は移行までで契約が終わり、請求の確認は誰の仕事か決まっていない
- 予算の上限を決めずに始める：想定外の使いすぎに、請求書が届くまで気づけない（AWSには予算の上限を超えそうなときに通知する「AWS Budgets」があります）
- 最初から作り変えようとする：移行と同時に作り直すと、費用も期間も膨らみます。AWSの移行ガイドも、大規模な移行では移行後に段階的に作り変える進め方を勧めています
発注者がやること チェックリスト
- ☐ 今のサーバーの年間総額（購入費・電気代・保守費・買い替え費）を出した
- ☐ 運用担当者の作業時間（月あたり）を書き出した
- ☐ クラウドの月額見積もりに、データベース・バックアップ・通信料金・監視が入っている
- ☐ 移行の一回きりの費用と、並行稼働の期間・費用を確認した
- ☐ 移行後の見直し（月1回の請求確認）の担当者と頻度を決めた
- ☐ 予算の上限と、超えそうなときの通知先を決めた
- ☐ 夜間・休日にサーバーを止められるかを開発会社と確認した
開発会社への質問例
- 「社内サーバーの年間コストと、クラウドの月額見積もりを、同じ条件で並べた比較表を作っていただけますか」
- 「見積もりに、通信料金・バックアップ・監視・データベースは含まれていますか」
- 「移行後の請求を、誰がいつ確認し、どの頻度で見直す前提ですか。その費用は契約に含まれますか」
- 「請求が想定を超えたときに気づけるよう、予算アラートの設定をお願いできますか」
- 「今の構成は、実際の使用量に対して大きすぎませんか。小さくしたり夜間に止めたりした場合の節約額の目安を教えてください」
まとめ
- クラウド移行で「高くなった」と感じる多くの原因は、移行前に比べた範囲が狭かったこと
- 比べるのは、サーバー代だけでなく、電気代・保守費・運用の作業時間・買い替え費・移行の一回きりの費用
- 移行後も、請求の内訳を見て、使っていないものを止め、大きさと稼働時間を合わせる見直しで下げられる余地がある
- 見直しの担当者と頻度を、契約の段階で決めておく
クラウドの費用は、一度決めて終わりではなく、使いながら整えていくものです。「移行前の比較表」と「移行後の月1回の確認」の2点を開発会社と決めておけば、請求額に振り回されにくくなります。
あわせて読みたい関連記事
