Windowsの塩漬けをどうAWSに載せるか｜EOL・ライセンス・移行方式の判断

「動いてるから触らないで」——塩漬けのWindows Serverを、EOLを機にどうAWSへ載せるか。塩漬けの背景を汲みつつ、EOLのリスク・移行方式・ライセンス・AD・可用性の判断を、二次請けの現場目線で率直に整理します。まず載せて時間を買い、段階的に最適化する、という順番の話です。

01「動いてるから触らないで」

二次請けで現場に入ると、必ず一度は言われます。「このサーバは動いてるから、触らないで」——十数年前に構築され、作った人はもういない。仕様書もない。けれど毎日業務を支えている、そんなWindows Serverです。

触りたくない気持ちは分かります。止めれば業務が止まり、壊せば責任問題。塩漬けは怠慢ではなく、たいてい合理的な判断の積み重ねです。ですが、その合理を崩すものがひとつあります——EOL（サポート終了）です。

先に結論だけ言うと、「まずリホストで載せて時間を買い、載った後に段階的に最適化する」。そしてライセンスとActive Directoryは、方式を決める前に握っておく。この2つを外すと、あとで必ず揉めます。

02なぜWindowsは塩漬けになるのか

責める前に、なぜ塩漬けになるのかを分解します。ここを理解しないと、移行の会話が「なぜ今さら」という感情論になります。

• 動いているから触らない。止めるリスクの方が、更新しないリスクより目の前で大きく見える。
• ブラックボックス化。作った人がいない、仕様書がない、依存関係（.NET Frameworkのバージョン、特定DLL、共有フォルダのパス、ドメイン依存）が読めない。
• 過去の失敗体験。一度パッチや更新で壊した経験があると、以降は「もう触らない」に倒れる。
• 予算と稟議。塩漬けは「先送りできるコスト」。EOLという期限が来て初めて予算が付く——これが二次請けの現実です。

だから塩漬けサーバは、技術課題であると同時に、組織とお金の課題でもあります。移行を「単なる引っ越し」として見積もると、この依存関係の棚卸しコストを丸ごと落とします（見積もりが外れる理由はAWS移行見積もりが外れる本当の理由で詳しく書きました）。

03EOLのリスク — 「動いている」は安全ではない

塩漬けが問題になる最大の理由がEOLです。すでにWindows Server 2012 / 2012 R2は延長サポートが終了しており、2016も終盤に差しかかっています。EOLが何を意味するかを、実務のリスクに翻訳します。

• セキュリティパッチが出ない。新しい脆弱性が見つかっても修正が提供されない。ネットに近い層にいるほど致命的です。
• 監査・コンプラで減点。PCI DSSをはじめ、EOLのOS/ミドルを使い続けている事実は指摘対象になります。「承知の上で使っていた」は通りません。
• ハードの老朽化・部品枯渇。オンプレの場合、載っている物理サーバ自体が寿命を迎え、壊れたら終わり、という状態も珍しくない。

EOL後の延命策としてESU（拡張セキュリティ更新プログラム）があります。ここは金額に踏み込まず考え方だけ言うと、ESUは有償が原則で、載せ先によって扱いが変わります。たとえばAzure上で動かす場合は追加費用なしで受けられる、という整理があり、AWSやオンプレでは有償になる——この違いは「どこに載せるか」の判断材料のひとつになります。正確な条件はライセンス状況で変わるので、必ず個別に確認します。

04移行方式の選択肢 — まず載せる、を基本に

AWSに載せる方式は、大きく3つに整理できます。リホスト（そのまま載せる）／リプラットフォーム（一部マネージド化）／作り直し（リアーキ）。塩漬け案件では、この選び方に持論があります。

ただし注意点がひとつ。可用性はリホストでも「移す」ことができません。オンプレのフェイルオーバークラスタやS2D（Storage Spaces Direct）で作った冗長構成は、共有ストレージや物理前提に依存していて、そのままAWSには載りません（このあたりの設計判断はWindows S2D×Hyper-V の設計判断（事例）に書いています）。可用性はAWS側で作り直す前提で計画します。

05ライセンスの考え方 — 込みか、持ち込みか

Windowsを載せるとき、方式と同じくらい早く握るべきなのがライセンスです。金額には踏み込みませんが、考え方は「込み」か「持ち込み」かの2択に整理できます。

• ライセンス込み（License Included）：WindowsライセンスをEC2料金にまとめてもらう形。調達が楽で、Software Assurance（SA）も不要、従量で使えるのが利点。まず載せるフェーズと相性が良い。
• 持ち込み（BYOL）：既存のWindows/SQL Serverライセンスを活かす形。既に資産があるなら有利になり得るが、条件が付きます。

BYOLで押さえる肝は2点です。ひとつ、Windows ServerのBYOLは原則Dedicated Host（占有ホスト）が必要になります。物理コア単位でライセンスを管理する仕組みのためです。もうひとつ、SQL ServerなどはSA付きのLicense Mobilityで共有テナンシーに持ち込める場合があり、Windows Server本体とは扱いが違います。コンプラ追跡にはAWS License Managerを使います。

06Active Directory と認証 — サーバより先に決める

Windowsワークロードは、ほぼ必ずActive Directoryにぶら下がっています。ドメイン参加、GPO、Kerberos、共有フォルダの権限——ここを軽く見ると、サーバを載せた直後に認証で詰まります。だから実務では、サーバの引っ越しより先にADの置き場所を設計します。

AWS側の選択肢は主に3つです。

• AWS Managed Microsoft AD：実体がMicrosoft AD Domain Servicesのマネージド版。GPOも信頼関係も使え、Windows寄りの本命。
• AD Connector：AWS上のワークロードの認証を、既存オンプレADへプロキシする。ADを移さず使い続けたいときに。
• Simple AD：小規模・限定用途向けの簡易ディレクトリ。フル機能のADが要らない場合の選択肢。

よく取る構成は、(1) 既存オンプレADを正として専用線/VPNでつなぎ、AD Connectorや信頼関係で使う、(2) AWS Managed Microsoft ADを立ててオンプレADと信頼関係を張る、(3) 完全にAWS側へ移設する、の3パターン。FSx for Windows File Serverもドメイン統合が前提なので、ファイルサーバを移すならADの設計は避けて通れません。

07載せた後 — 可用性・パッチ・監視・最適化

移行は「載せて終わり」ではありません。むしろ載せた後にやることを設計に含めていないと、クラウドの上で新しい塩漬けが始まります。ここは端折れません。

• 可用性の再設計：オンプレのS2D／フェイルオーバークラスタはそのまま載りません。Multi-AZ、FSxのMulti-AZ、DBはRDS Multi-AZなど、AWSの作法で冗長化を組み直す。可用性は「移設」ではなく「再設計」です。
• パッチ：SSM Patch Managerで定期パッチとメンテナンスウィンドウを回す。ここを運用に組み込むのが、塩漬け再発の防止策そのものです。
• 監視：CloudWatch AgentでメトリクスとWindowsイベントログを収集し、EventBridgeで検知につなぐ。
• 最適化（載せた後にやる）：Compute Optimizerでインスタンスを右サイズ化。定常稼働のWindowsはSavings Plans/RIでコストを圧縮。ライセンス構成も稼働実績を見て見直す。

08まとめ — 背景を汲み、期限から逆算する

塩漬けWindowsをAWSに載せる勘所を、順番に並べ直します。

• 塩漬けには理由がある。まず責めず、依存関係を棚卸しする。
• EOLは期限。「動いている」は安全ではない。日付から逆算して動く。
• まずリホストで載せて時間を買い、段階的にリプラットフォーム。一気の作り直しは体力を見てから。
• ライセンス（込み/BYOL）とADは、方式より先に握る。後回しにすると必ず揉める。
• 可用性の再設計・パッチ・監視・最適化まで含めて「移行」。載せて終わりにしない。

EMWは札幌の二次請けで、設計から構築・テスト・移行まで、Windowsやレガシーの現場を実務で回してきました。S2D×Hyper-Vのような可用性設計の判断（Windows S2D×Hyper-V の設計判断（事例））も、見積もりが外れる勘所（AWS移行見積もりが外れる本当の理由）も、身をもって知っています。塩漬けの解き方を、御社の事情に合わせて一緒に設計します。

09よくある質問（FAQ）