「とりあえずリフト&シフト」の代償｜移行後半年で効いてくるもの

まず現状のままAWSへ載せるリフト&シフトは、正しい第一歩です。問題はそこで"とりあえず"止まってしまうこと。移行後およそ半年で効いてくる代償——right-sizingしないコスト・マネージド化しない運用負荷・レガシー構成の塩漬け——と、いつ最適化・モダナイズを判断するかを、二次請けの現場目線で整理します。

01リフト&シフトは悪くない。ただし"止まる"と代償が出る

AWS移行の第一歩として、まず現状のままクラウドへ載せるリフト&シフト（リホスト）を選ぶのは、まっとうな判断です。オンプレのハードウェア保守期限が迫っている、データセンター契約の解約日が決まっている、まずは動かして撤収を優先したい——こういう現場で、最初からアプリを作り替えるモダナイズ全部盛りを狙うのは非現実的です。二次請けとして数多くの移行に入ってきた立場でも、「まずそのまま乗せる」は最初の一手として合理的だと考えています。

問題は、リフト&シフトそのものではありません。「とりあえず乗せた」で止まってしまうことです。移行の完了報告を出した瞬間にプロジェクトが解散し、誰も次の一手を持たないまま数か月が過ぎる。すると、オンプレのやり方をそのまま持ち込んだ構成の"つけ"が、じわじわと請求書と運用の現場に効いてきます。

この記事では、移行後およそ半年で効いてくる代償を3つに整理します。①right-sizing しないコスト、②マネージド化しない運用負荷、③レガシー構成の塩漬け。そのうえで、いつ最適化・モダナイズを判断するか、そして"とりあえず"で止まらないための段階的移行の型を、現場の実感で書きます。

02後で効くもの① right-sizing しないコスト

オンプレのサーバーサイジングは、たいてい過大です。5年償却を前提に、ピーク負荷＋将来の余裕＋安全マージンを積んで買います。買い切りなので、多少余っていても痛くない。むしろ「足りなくて増設」のほうが痛いので、過剰に倒すのが合理的でした。

その感覚のまま、オンプレVMの vCPU とメモリをそのままインスタンスタイプに写経すると何が起きるか。クラウドは買い切りではなく毎月課金です。過剰スペックは、毎月きっちり課金され続けます。オンプレでは見えなかった"余り"が、請求書に毎月顔を出すようになる——これが最初に効いてくる代償です。

ある製造業のお客様の移行を手伝ったときのことです。オンプレ仮想基盤の各VMを、スペックをそのままEC2へリホストしました。移行自体は順調でしたが、数か月後にCloudWatchを見ると、多くのインスタンスでCPU使用率は平均で一桁パーセント台のまま。メモリも大きく余っていました。そこで実測に合わせてインスタンスを1〜2段下げ、gp2ボリュームをgp3へ切り替え、構成が固まったところで Savings Plans を当てました。金額は断定しませんが、月額の"効き"は無視できない規模で軽くなりました。ポイントは、リフト直後は「測って落とす」余地が大きいのがむしろ普通だ、ということです。

効いてくるのはインスタンス料金だけではありません。オンプレの感覚のまま確保した大きめのEBS、こまめに増えていくスナップショットの保持世代、AZをまたぐ通信やインターネットへのデータ転送量——こうした"脇役"も、毎月の請求ではじわじわと積み上がります。オンプレでは電気代や減価償却に埋もれて見えなかった費目が、クラウドでは明細として一つひとつ姿を現す。だからこそ、まずはCost Explorerで内訳を分解し、どこが効いているのかを数字で押さえるのが最初の一歩になります。感覚で「クラウドは高い／安い」と語る前に、自社の明細を読むことです。

03後で効くもの② マネージド化しない運用負荷

リフト&シフトは、OSやミドルウェアの面倒をまるごと持ち込む移行です。EC2の上でDBを動かし、OSパッチを自前で当て、監視エージェントを自前で運用し、バックアップも自前スクリプトで回す。動くことは動きます。ただ、これだと「クラウドに来た意味」が半分ほど失われます。マネージドサービスに寄せれば手放せたはずの運用が、そっくり手元に残るからです。

ある業務システムでは、SQL Serverを載せたサーバーをEC2のまま持ち込みました。パッチ適用のためのメンテナンス窓の調整、フェイルオーバー構成の自前運用、バックアップの取得と復旧試験——ひとつひとつは地味ですが、積み上がると確実に人手を食います。これをRDSやAuroraに寄せられれば、パッチ・バックアップ・HA（Multi-AZ）はマネージド側の仕事になり、こちらは"運用しなくてよい領域"を増やせます。監視も同じで、オンプレのZabbixや監視サーバをそのまま持ち込むと、監視サーバ自体の面倒を延々と見続けることになります。CloudWatchやマネージドな監視へ寄せる判断は、つい先送りされがちです。

自前運用が残ると、地味な調整ごとも残ります。パッチ適用のたびに顧客と再起動の承認フローを回し、深夜のメンテ窓を確保し、当日は待機する。バックアップは取れているつもりでも、いざというときに戻せるかは復旧試験をしないと分からず、その試験もまた工数です。マネージド側に寄せれば、この手のオペレーションの多くはサービスの機能として吸収されます。手放したぶんの時間を、本来やるべき改善や監視の設計に振り向けられるようになります。

厄介なのは、この運用負荷が請求書に一行では出ないコストだという点です。EC2の料金としては見えず、人月・工数として跳ね返ります。二次請けの立場だと、これは運用フェーズの工数見積りに直撃します。「動いているから触らない」を続けるほど、"運用しない部分"を増やす機会を逃していきます。

04後で効くもの③ レガシー構成の塩漬け（可用性・セキュリティ）

現状のまま持ち込む、ということは、オンプレ時代の弱点もそのまま持ち込むということです。シングル構成、サポート切れ間近のOS、古いTLS設定、広すぎるセキュリティグループ、棚卸しされていない過剰な権限。これらが、移行のどさくさで温存されます。

可用性の面では、単一インスタンス・Single-AZのまま載せると、クラウドのMulti-AZという最大の武器を活かせていない状態になります。オンプレで冗長化していなかった構成が、クラウドでもそのまま冗長化されないまま動く。「クラウドだから止まらない」と誤解されがちですが、そう組んでいなければ止まります。

セキュリティの面では、塩漬けはEOL間近のOS、未適用のパッチ、フルオープンに近いSG、広すぎるIAM権限を、そのままクラウドに引き継ぎます。移行のタイミングで棚卸ししなければ、オンプレの負債をクラウドに移設しただけになりかねません。実際、サポート終了が近いWindows Serverを「まず動かす」を優先してそのまま移行し、移行後は「動いているから」と放置され、結局EOL対応が半年後に単独プロジェクトとして立ち上がって余計に高くついた——という現場を見てきました。

塩漬けの本当の怖さは、時間が経つほど動かしにくくなることです。移行直後なら関係者も構成を覚えていて、手も入れやすい。半年寝かせると担当者の記憶は薄れ、「触って壊れたら怖い」が先に立ち、誰も触りたがらなくなります。

05モダナイズの判断軸 — 費用対効果・リスク・タイミング

とはいえ、なんでもかんでもモダナイズすればよいわけではありません。全部を作り替えるのは非現実的ですし、費用対効果が見合わないものまで手を出すと、それこそ移行が終わりません。判断には軸が要ります。現場では次の3つで優先順位を付けています。

• ① 費用対効果：毎月効き続けるコスト（インフラ費＋運用工数）と、改修に必要な一度きりのコストを天秤にかける。毎月効くコストは、改修投資を正当化しやすい。逆に、安定して安く動いているものは急がない。
• ② リスク：そのまま放置したときの可用性・セキュリティ・EOLのリスク。止まると業務が止まるもの、監査で必ず指摘されるもの、サポート切れが迫るものは優先度が高い。
• ③ タイミング：ライセンス更新、OSのEOL、保守契約の更改、機能追加の開発——こうしたイベントに合わせると、モダナイズの追加コストが相対的に小さくなる。

優先順位の付け方はシンプルで、「毎月効くコストが大きい×高い」と「リスクが高い」を上に置くだけです。全部を一度にやろうとせず、効きの大きい順に、少しずつ。この見極めは移行の見積り精度とも地続きです（この関係はAWS移行見積もりが外れる本当の理由でも触れています）。

06"段階的移行"の型 — リホスト→計測→部分的リプラットフォーム

では、"とりあえず"で止まらないために、どう進めるか。現場で有効だと感じているのは、次の3ステップを回し続ける型です。

• ステップ1：リホスト。まず現状のままAWSへ載せる。期限とオンプレ撤収を最優先し、ここでは無理にモダナイズしない。第一歩を早く踏むことを優先する。
• ステップ2：計測。移行後1〜3か月、CloudWatchとCost Explorerで実測を取る。CPU/メモリ/IOの使用率、月額の内訳、運用にかかっている工数。数字で"効いている代償"を可視化する。
• ステップ3：部分的リプラットフォーム。効きの大きいところから手を入れる。DBをRDS/Auroraへ、監視をCloudWatchへ、ボリュームをgp3へ、構成が固まったところでRI/Savings Plansを購入。全部ではなく、効く順に。

そして、これを一度で終わらせず繰り返す。測って、直して、また測る。アプリを大きく作り替えるリアーキテクト（リファクタリング）は、費用対効果が明確に見合う一部だけに絞るのが現実的です。どのマネージドサービスに寄せるかの検討には、選定の観点を並べたAWS・Azure・GCP・オンプレ サービス対応表のような整理が役立ちます。

07まとめ — 測って、効く順に直す

リフト&シフトは、AWS移行の正しい第一歩です。否定する必要はありません。ただし「とりあえず」で止まると、半年ほどで代償が効いてきます。オンプレのサイジングを引きずったright-sizingしないコスト、マネージドに寄せなかった運用負荷、そして可用性とセキュリティを塩漬けにしたレガシー構成。どれも移行直後には見えにくく、時間差でやってきます。

対策はシンプルです。測って、効く順に直す。モダナイズは全部やるものではなく、費用対効果・リスク・タイミングの3軸で選ぶ。そして移行計画に見直しフェーズを工程として組み込み、移行完了をゴールにしない。これだけで、"とりあえず"の代償の多くは避けられます。

EMWは札幌のAWSコンサル／SIer二次請けとして、設計から構築・テスト・移行まで実務で回してきました。リフト後の実測にもとづく見直しや、効きの大きいところから進める段階的なモダナイズも、御社の事情と優先順位に合わせて一緒に組み立てます。

08よくある質問（FAQ）