オンプレミスから AWS への移行は、サーバーをクラウドへコピーするだけの作業ではありません。認証、データ、ネットワーク、運用手順、障害時の判断を含めて、業務が動く場所を段階的に変えるプロジェクトです。とくに Windows Server、Active Directory、データベース、基幹システムを担当する情シスには、個別製品の知識より先に、移行全体を分解する視点が必要です。
この記事では、AWS 移行の意思決定から移行計画書、本番切り替え、移行後の最適化までを一続きで整理します。特定の AWS サービスの上限値や料金単価には依存せず、構成が変わっても使える判断軸に絞ります。新規構築向けのサービス選定は姉妹記事の AWS ECS 入門 と AWS サーバーレス入門 で詳しく解説しているため、本記事では既存資産を安全に移す方法を中心に扱います。
なぜオンプレミスから AWS に移行するのか ─ 5 つの動機
AWS 移行の目的は「クラウド化」では不十分です。移行後に何が改善したら成功なのかを測れないからです。主な動機は次の 5 つに分けられます。
- ハードウェア更改やデータセンター契約の期限に対応する
- 調達にかかる時間を短くし、需要に応じて計算資源を変更する
- バックアップ、復旧、監視の仕組みを標準化する
- 拠点や在宅勤務から利用できる業務基盤を整える
- レガシーシステムを段階的にリプレイスできる土台を作る
このうち、期限対応だけを目的にすると、現行環境をそのまま移すリホストが有力です。一方、保守負担の削減や機能追加の速度向上が目的なら、OS を持ち続ける構成だけでは効果が限定されます。移行後にデータベースや実行基盤をマネージドサービスへ置き換える余地までロードマップに含めます。
メリットだけでなく、増える仕事も確認します。物理機器の保守は減っても、クラウドアカウント、権限、設定変更、利用量、ログは継続的に管理します。費用も固定的な設備費から利用量に連動する費用へ変わります。「運用が不要になる」のではなく、運用対象と必要なスキルが変わると捉えるのが正確です。
FIXIT更改期限が迫っているなら、全部そのまま移せば早いですよね？
Dodaiまず期限を守る移設と、その後の改善を分けます。一度に両方を狙うと切り替えが重くなります。
移行しない選択肢も比較します。設備に密接した低遅延処理、クラウドへ持ち出せないデータ、特殊な機器やライセンスへの依存がある場合は、オンプレミスを残す合理性があります。その場合も「何となく残す」のではなく、AWS とオンプレミスを接続するハイブリッドクラウドの期間、対象、終了条件を決めます。
AWS 移行の 4 段階 ─ 計画からクラウドネイティブ化まで
オンプレミスから AWS への移行手順は、4 段階に分けると投資判断と技術判断を混ぜずに進められます。すべてを最終形へ一度に移す必要はありません。
| 段階 | 主な作業 | 完了を判断する材料 | 次へ進む条件 |
|---|---|---|---|
| 1. 計画 | 資産・依存関係の棚卸し、目的、対象、方式、ウェーブ、責任分担を決める | 現行構成図、依存関係表、移行計画書、概算 | 対象外と切り戻し条件まで合意できた |
| 2. リフト&シフト | 検証環境を作り、サーバーやデータを大きく変えずに移す | リハーサル結果、性能・業務試験、復旧試験 | 業務の受け入れ基準を満たした |
| 3. 最適化 | 構成、サイズ、監視、バックアップ、権限、費用を見直す | 利用量、アラート、障害対応記録、請求内訳 | 安定運用の担当と手順が決まった |
| 4. クラウドネイティブ化 | コンテナ、サーバーレス、マネージド DB などへ段階的に再構築する | 変更頻度、運用工数、復旧結果、費用差 | 改修効果が再構築コストを上回る |
第 1 段階: 移行計画書を意思決定の台帳にする
棚卸しはサーバー一覧だけでは足りません。「受注登録は認証基盤、在庫 DB、帳票サーバー、外部倉庫 API を使う」のように、業務を起点に依存関係をたどります。利用部門、利用時間、データ量、通信先、ジョブ、証明書、ライセンス、障害時の影響も記録します。
AWS への移行計画書には、目的と数値化できる完了条件、対象と対象外、現行構成、依存関係、移行方式、移行ウェーブ、試験、役割分担、停止枠、切り替え手順、切り戻し条件、リスクと対策、費用を含めます。文書を納品物にするだけでなく、前提が変わったときに判断を更新する台帳として使います。
第 2 段階: リフト&シフトで移行経路を確保する
リフト&シフトは、OS やアプリケーションを大きく変えずに実行場所を移す方法です。更改期限への対応や、複雑なシステムを短期間で退避するときに有効です。ただし、現行の過剰なリソース、古い運用、単一障害点まで持ち込む可能性があります。
最初のウェーブには、依存関係が少なく、業務影響を限定できる検証環境や社内 Web サーバーを選びます。移行ツールによる複製が成功しても、名前解決、認証、時刻、ジョブ、監視、バックアップ、外部接続まで通るとは限りません。利用者の操作から後続処理までを一連で試験します。
第 3・第 4 段階: 実測してから最適化と再構築を選ぶ
移行直後は、性能、エラー、利用量、問い合わせを観測し、想定との差を修正します。その後に、不要な常時稼働、過剰な保存、広すぎる権限、手作業の構築を見直します。
クラウドネイティブ化は目的ではありません。常時稼働する Web アプリケーションや実行環境を制御したい処理は ECS / Fargate、イベントを起点に短く独立して動く処理はサーバーレスが候補です。判断材料は AWS ECS 入門 と AWS サーバーレス入門 に分けているので、移行後の実測値を得てから比較してください。
Windows Server・AD・DB・基幹システムの移行注意点
対象ごとに壊れやすい境界が違います。サーバーの起動確認だけで受け入れると、認証や日次処理で問題が発覚します。
| 対象 | 先に棚卸しする項目 | 移行時の主な注意点 | 受け入れ確認 |
|---|---|---|---|
| Windows Server | OS・ミドルウェア、サービスアカウント、共有、タスク、ライセンス | 名前解決、時刻同期、権限継承、サポート条件 | 利用者操作、共有アクセス、定期処理、復旧 |
| Linux Server | ディストリビューション、パッケージ、常駐プロセス、マウント、証明書 | 手作業設定、秘密情報、ログ、監視の抜け | 再起動後の自動復旧、ジョブ、外部接続 |
| Active Directory | ドメイン構成、DNS、サイト、信頼関係、管理経路 | オンプレミスとの接続断、時刻ずれ、認証依存 | ログオン、権限、名前解決、障害時の管理 |
| データベース | エンジン、拡張、文字コード、容量、更新量、接続元 | 互換性、同期遅延、更新競合、切り戻し後の差分 | 件数・金額・ハッシュ、性能、業務照合 |
| 基幹システム | 業務カレンダー、外部連携、締め処理、帳票、責任者 | 停止枠、処理順序、データ整合性、判断の遅れ | 受注から請求までの業務シナリオ |
Windows Server と Linux Server
Windows サーバーの AWS 移行では、OS だけでなくサービスアカウント、ファイル共有のアクセス制御、タスクスケジューラ、証明書、バックアップソフトを確認します。ライセンス条件は契約や製品によって変わるため、利用時点の契約条件を権利者やベンダーに確認します。
Linux サーバーでは、担当者が手で変更した設定が構成管理から漏れていないかを確認します。起動時の処理、cron、マウント、ローカルディスクへ置いた状態、IP アドレスを前提にした許可設定が典型的な確認点です。再構築できる設定は IaC や構成管理へ移し、再現性を受け入れ条件にします。
Active Directory とハイブリッド接続
Active Directory は認証の中心なので、ほかのサーバーと同じウェーブで不用意に動かしません。AWS 側とオンプレミス側を接続する期間の DNS、時刻同期、管理者の接続経路、接続断時に利用できる業務を決めます。
ハイブリッドクラウドを恒久化するなら、回線を「つながっている前提」にせず、切れたときの影響を試験します。監視担当、通信費、障害の切り分け、クラウドと社内ネットワークの変更責任も明文化します。
データベースと基幹システム
データベース移行は、データ量だけで難易度を判断できません。更新頻度、文字コード、ストアド処理、拡張機能、接続元、許容停止時間が方式を左右します。継続同期で停止時間を短くする場合も、同期遅延と更新競合、切り戻し後にどちらを正とするかを決めます。
基幹システムの AWS 移行で注意したいのは、技術チームの確認と業務部門の確認を分けないことです。受注、在庫引当、出荷、請求、会計連携のシナリオを用意し、誰が何を見て移行成功と判定するかを決めます。月末や年度末だけ動く処理は、通常日のリハーサルでは見落としやすいため、入力データと期待結果を保存します。
AWS 移行費用をシミュレーションする方法
費用は「AWS の月額」だけで比較しません。移行プロジェクトの一時費用、移行中の二重費用、移行後の継続費用、社内工数を同じ期間で並べます。個別サービスの料金はリージョン、利用量、契約、改定によって変わるため、見積時点の公式料金と料金計算ツールで確認します。
| 費用区分 | 数える項目 | 変動要因 |
|---|---|---|
| 調査・設計 | 棚卸し、依存関係調査、方式選定、計画書、セキュリティ設計 | 文書の有無、対象数、外部連携、規制 |
| 構築・移行 | AWS 基盤、ネットワーク、データ転送、変換、試験、リハーサル | データ量、互換性、ウェーブ数、停止可能時間 |
| 並行稼働 | オンプレミス設備、回線、AWS 環境、ライセンス | 並行期間、再試験、切り戻し準備 |
| 継続運用 | 計算、保存、転送、監視、バックアップ、サポート、運用担当 | 利用量、保持期間、可用性、通信経路 |
| 終了処理 | データ保全、契約解約、機器撤去、消去証跡 | 保管義務、設備契約、撤去対象 |
試算は次の順で行います。
- 現行費用を設備、保守、回線、ソフトウェア、データセンター、社内工数に分ける
- 通常時、繁忙時、障害時の利用量と必要性能を実測する
- 移行方式ごとに調査、構築、試験、並行稼働、撤去を積み上げる
- AWS 側は計算、保存、データ転送、ログ、バックアップ、ネットワークを分ける
- 通常月だけでなく、繁忙月と事業成長後のシナリオを作る
- 前提、確認日、含まない費用を見積書に残す
ファイルサーバーでは保存容量だけでなく、アクセス方法、転送量、バックアップ保持、検索、権限移行が費用を変えます。サーバー集約では台数が減っても、可用性や災害対策のために冗長化する資源が必要です。オンプレミスの減価償却済み設備と AWS の月額だけを比べるのではなく、次回更改までの総保有コストと、障害・調達にかかる時間も別項目で示します。
サービス上の費用目安を確認する場合も、対象システム、移行方式、停止条件、成果物をそろえて比較してください。この記事では新しい料金レンジを作らず、内訳を作る方法を重視します。
一般的な失敗パターンと回避策
ここで扱うのは当社の実案件ではなく、AWS 移行で一般に起こり得る失敗パターンです。原因を「技術力不足」の一言で片付けず、計画と判定の仕組みに変換します。
失敗 1: サーバー一覧だけでスケジュールを作る
台数順に移すと、後から認証、DB、外部接続への依存が見つかり、ウェーブを組み直すことがあります。回避策は、業務フローから依存関係をたどり、一緒に試験すべき単位でウェーブを作ることです。AWS 移行プロジェクトの期間は、台数ではなく依存関係とリハーサル回数から積み上げます。
失敗 2: ツールの複製完了を移行完了と考える
AWS 移行ツールは転送や複製を助けますが、業務が正しく完了したことまでは判定しません。監視、バックアップ、ジョブ、認証、帳票、外部連携を含む受け入れ試験を用意し、技術担当と業務担当の両方が確認します。
失敗 3: 切り戻し手順はあるが、判断条件がない
手順書があっても、誰がいつ中止を決めるかが曖昧だと、復旧に使える時間を失います。「データ同期の遅延が許容範囲を超えた」「主要業務シナリオが期限までに通らない」のような条件、判断者、決定期限を決めます。切り戻し後に発生した更新データの扱いも試験します。
失敗 4: リフト&シフト後の作業を予算化しない
移設だけで終えると、過剰なサイズ、手作業、広い権限、古い監視が残ります。移行直後の安定化期間と、その後の最適化バックログを最初から計画します。レガシーのリプレイスは別プロジェクトに分けても構いませんが、責任者と再評価日を置きます。
失敗 5: 運用引き継ぎが本番後に始まる
構築担当だけが設定を理解していると、最初の障害や権限変更で止まります。構成図、IaC、権限一覧、監視、バックアップと復旧、デプロイ、障害時の Runbook を成果物として定義し、情シスがリハーサル段階から操作します。
FIXITリハーサルで成功した手順なら、本番もそのまま進めてよいですか？
Dodai差分を確認します。データ量、担当者、開始時刻まで本番条件に近づけ、切り戻しも通します。
AWS 移行ベンダーを選ぶ 5 つの軸
AWS 移行ベンダーやマイグレーション会社を比較するとき、提案されたサービス数の多さだけでは実行力を判断できません。同じ現行情報と前提条件を渡し、次の 5 軸で比較します。
- 現状調査では、サーバー台帳だけでなく、業務、認証、データ、外部接続の依存関係をどう確認するか
- 方式の根拠として、リホスト、リプラットフォーム、再構築を対象ごとに選ぶ理由と、選ばなかった案の説明があるか
- 移行リスクと対策では、リハーサル、停止枠、受け入れ基準、切り戻し条件、データ整合性の確認方法が具体的か
- 費用と責任分界では、調査、追加試験、AWS 利用料、ライセンス、回線、運用、対象外作業の前提が分かれているか
- 引き継ぎでは、構成図、IaC、権限一覧、監視、復旧、デプロイ、Runbook を誰が管理できる形で渡すか
基幹系の AWS 移行実績を尋ねること自体は有効ですが、名称や規模だけでなく、どの制約に対して何を設計し、どう検証したかを確認します。守秘義務で詳細を出せない場合も、架空の成功談ではなく、匿名化できる設計判断や成果物のサンプルで説明できるかが判断材料になります。
見積もり前には、目的、希望時期、停止できない業務、現行構成、データ量、外部接続、社内担当、予算上の制約を共有します。要件が固まっていなくても、調査フェーズと実装フェーズを分ければ発注できます。AWS 構築の設計、移行、運用引き継ぎの相談は AWS 構築・移行支援 で受け付けています。
まとめ ─ 移行単位はサーバーではなく業務の依存関係
オンプレミスから AWS への移行は、計画、リフト&シフト、最適化、クラウドネイティブ化の 4 段階で考えると、期限対応と改善を分けて進められます。最初に決めるのは AWS サービスではなく、移行目的、対象、依存関係、停止可能時間、受け入れ基準、切り戻し条件です。
Windows Server、Linux Server、Active Directory、データベース、基幹システムは、それぞれ壊れやすい境界が違います。業務シナリオを起点に移行ウェーブを組み、実データに近い条件で切り替えと切り戻しをリハーサルしてください。費用は月額だけでなく、調査、並行稼働、試験、運用引き継ぎ、旧環境の撤去まで同じ表に載せます。
移行方式の整理から AWS 環境の設計、リハーサル、運用引き継ぎまで外部支援を検討する場合は、AWS 構築・移行支援 をご覧ください。現行構成や要件が固まる前でも、調査すべき項目と移行計画の作り方から整理できます。