オンプレからAWSへ — 移行前に決めるべき設計10項目

オンプレミス環境をAWSへ移行する際、多くの現場で「作業を始めてから設計を決める」という順序の逆転が起きています。しかし、移行の成否を左右する設計判断のほとんどは、プロジェクト開始から最初の2週間で固まっていなければなりません。本記事では、移行前に確定させておくべき10の設計項目を整理し、後から変更コストが跳ね上がる落とし穴を先に示しながら、判断の優先順序を解説します。

移行は「作業」の前に「10の決定」で9割決まる

設計の後回しが現場を止める

「とりあえずEC2を立てて進めよう」と作業を先行させると、後工程でネットワーク構成やアカウント分離の方針が変わり、すでに作ったリソースをすべて作り直す事態になります。構築を任されたある担当者が携わった中規模移行プロジェクト（サーバー30台規模）では、VPCのCIDR設計を曖昧なまま進めた結果、オンプレとのVPN接続設定の段階でアドレス重複が発覚し、2週間分の作業を最初からやり直すことになったといいます。設計判断の先送りがどれほど高くつくかを示す典型例です。

「後から変えると高くつく」設計項目を先に洗い出す

移行プロジェクトを構成する設計判断は無数にありますが、後から変えると影響範囲が爆発するものと、後から調整しやすいものに二分されます。前者の代表が「リージョン選定」「アカウント分離方針」「VPCのCIDRとネットワーク境界」「IAMの権限モデル」「ログの保管先と保持期間」です。これらは変更のたびに依存リソースへの連鎖変更が発生し、設計変更ではなく再構築に近い作業量になります。後述する10項目は、まさにこの「後から変えると高くつく」カテゴリを網羅しています。移行キックオフから1週間以内に決定を完了させることを目標にしてください。

決定1〜3：リージョン／アカウント分離／ネットワーク境界

決定1 リージョン選択 — 法令と遅延の二軸で決める

リージョン選択を「東京にしておけばいい」という直感で済ませると、後でコンプライアンス上の問題が浮上することがあります。判断軸は主に2つです。1つ目はデータ所在地の制約で、個人情報保護法対応が求められる場合、データが物理的にどの国のデータセンターに保管されるかを明示しなければなりません。国内案件であればap-northeast-1（東京）またはap-northeast-3（大阪）が原則ですが、将来のグローバル展開を見越すなら、マルチリージョン設計の種を最初に蒔いておく必要があります。2つ目はレイテンシ要件です。「単一リージョン＋マルチAZ」か「マルチリージョン」かの二択は、プロジェクト最初の判断です。マルチリージョン構成はデータ同期のコストと複雑性も倍増することを念頭に置いてください。

決定2 アカウント分離 — 環境境界をどこで引くか

AWSアカウントは「環境の最強の境界線」です。本番・ステージング・開発を同一アカウントに同居させると、IAMポリシーのミスで本番リソースへ誤操作が届くリスクが消えません。推奨パターンは「本番アカウント・非本番アカウント・管理アカウント（AWS Organizations利用）」の3アカウント最小構成で、10台以上の規模ではさらにセキュリティ監査用アカウント（ログ集約専用）を加えた4アカウント構成が標準的な選択肢になります。「1アカウントでタグ管理すればいい」という考え方は初期フェーズならアリですが、規模が膨らんだ段階での分離はリソース移行を伴うため極めて困難です。アカウント分離の設計は移行初期のうちに固めてください。

決定3 VPCのCIDRとネットワーク境界

VPCのCIDR設計は「一度決めたら簡単には変えられない」設定の筆頭です。既存オンプレのIPアドレス体系との重複を避けつつ、将来のサブネット追加やピアリング・Transit Gateway接続を見越した十分な広さを確保することが不可欠です。/16のVPCに/24サブネットを使うパターンが一般的ですが、Availability Zoneごとに分けたPublic／Private／Data（DB）層の3層構成にすると、3AZ×3層で9サブネット以上が必要になります。/24では将来の拡張余地が不足するケースがあるため、/20〜/18を確保しておくことで余裕が生まれます。オンプレとのVPN・Direct Connect接続を予定している場合、オンプレ側アドレスとの重複チェックは設計初日の必須作業です。

決定4〜6：認証・権限モデル／踏み台とアクセス経路／ログ設計

決定4 IAMの権限モデル — 最小権限の「実装判断」

「とりあえず管理者権限を渡す」という初期設定が、後のセキュリティ強化のネックになるパターンは現場で頻繁に見られます。移行前に決めるべきは次の4点です。ヒューマンユーザーのアクセスはSSOで一元化するかIAMユーザーを使うか。サービス間の権限はIAMロールで制御し、長期的な認証情報（アクセスキー）を発行しない方針を貫けるか。権限境界（Permission Boundary）を使うか。権限変更の申請・レビュープロセスをどう運用するか。特に「長期認証情報を使わない」方針は初期に徹底しておかないと、後からアクセスキーが散在した状態になり、棚卸しと削除だけで数日を費やすことになります。

決定5 踏み台とアクセス経路 — SSMか踏み台サーバーか

EC2へのログイン経路はセキュリティとオペレーション効率の両方に直結します。Session Manager（SSM）経由のアクセスは、踏み台サーバーが不要でSSHポートをセキュリティグループに開放しなくてよい点が強みです。セッションログはCloudTrailとS3に自動記録され、監査証跡の確保も容易になります。一方、踏み台サーバー（Bastion Host）は既存のSSH運用フローをそのまま踏襲できるため、移行直後の運用習熟度が低い段階で選ばれやすいです。ただし、踏み台サーバー自体のパッチ管理・可用性確保・ログ収集が追加の運用負荷になります。選択基準は「チームがSSM操作を習得できるか」と「監査要件でセッションログをどのレベルで取るか」の2点です。

決定6 ログ設計 — 「どこに・何を・何日分」を先に決める

AWSのログは設計なしに有効化すると「全部オン→コスト爆発」か「取っていると思ったログが実は取れていなかった」の二択になります。最低限確定させるべきは3点です。CloudTrailはAPIコール全記録を対象にマルチリージョン有効化・S3集約・90日以上の保持が基本です。VPC Flow Logsはネットワークレベルの通信記録であり、インシデント調査に不可欠ですが大量ログが発生するため、S3格納とAthenaクエリを前提に設計します。アプリケーションログはCloudWatch Logsへの転送かS3直接出力かを選択し、保持期間は法令・社内規程から逆算してコストとのバランスを取ります。「インシデントが起きてから気づくログの不在」は移行後半の最大リスクの一つです。

決定7〜8：バックアップと復旧目標（RPO/RTO）の現実解

決定7 バックアップ設計 — 「取れている」と「使える」は別物

バックアップ設計で見落とされがちなのは、「バックアップを取ること」と「それが復旧手順として機能すること」の違いです。EBSスナップショットを毎日取っていても、リストア手順が未整備で実際の復旧に4時間かかるならRTOは4時間です。これが許容できるかを先に決めておく必要があります。設計ポイントは次の2つです。AWS Backupの集中管理を使うかサービスごとの個別設定かは、管理対象サービス数が5を超えるかどうかが一つの目安になります。また、リストアのテスト頻度を計画に組み込まなければ「取っただけで使えないバックアップ」になります。移行完了後の最初の3か月は月1回以上のリストアテストを実施することを推奨します。

決定8 RPO/RTOの現実解 — 「理想」ではなく「受け入れられる現実」で設定する

RPO（目標復旧時点）とRTO（目標復旧時間）は、ビジネス側の「全部ゼロにしてほしい」要求と、技術的・コスト的な現実のギャップを調整する作業です。ある製造業向けシステムの移行案件では、「RPO＝ゼロ、RTO＝即時」を実現するためにActive-Active構成と同期レプリケーションが必要になり、インフラコストが単純構成の3倍以上になることが判明しました。最終的にRPO＝1時間、RTO＝4時間という現実解に落ち着いたといいます。以下のマトリクスを設計判断の出発点として活用してください。

RPO/RTO水準	実現手段	追加コスト・複雑度
RPO＝0 / RTO＝数分	マルチAZレプリケーション＋自動フェイルオーバー	高（レプリカ費用＋設計工数）
RPO＝1時間 / RTO＝1〜4時間	定期スナップショット＋リストア手順整備	中（スナップショット費用のみ）
RPO＝24時間 / RTO＝8時間以上	日次バックアップ＋手動リストア	低（追加コストはほぼなし）

決定9〜10：コスト境界とスケール方針

決定9 コスト境界 — 「意図しないコスト増」を設計で防ぐ

クラウド移行後のコスト管理で多い失敗は「気づいたら想定の2倍になっていた」という事後的な発見です。コスト管理は監視ではなく設計の時点で境界を引く問題です。決めるべきポイントは3つあります。コスト配分タグ設計は後から遡及適用できないため、どのタグキーでどの粒度でコストを分けるかを最初に決め、全リソースへの一貫付与規約を設けます。AWS Budgetsはアカウントまたはサービス単位で予算上限を設定し、80%・100%到達時のアラートを移行初日から動かします。また、データ転送費用（Egress）とNATゲートウェイ費用はオンプレ感覚では見落としやすいクラウド固有のコスト構造です。大量データを外部転送する用途ではEgress費用が月額コストの20〜30%を占めるケースもあります。

決定10 スケール方針 — 「上げるか・増やすか・下げるか」を型で決める

スケーリング戦略を決めずに構築すると、後でアーキテクチャの根本的な見直しが必要になります。垂直スケール（スケールアップ）はEC2インスタンスタイプの変更で実現しますが再起動が伴います。水平スケール（スケールアウト）はAuto ScalingとロードバランサーをあらかじめAMI設計に織り込む必要があります。どちらを主軸にするかは、アプリケーションのステートフル性（セッション情報をどこに持つか）によって先に決まります。また、使用頻度の低い開発・検証環境は「夜間停止・週末停止」のスケジュールを構築時点でAuto Scaling Scheduled Actionとして型にしておくと、運用フェーズに入ってから月額費用を30〜40%削減できることがあります。後から個別対応するより格段に楽です。

10項目を「決めた／未決」で可視化するチェックリスト

1. リージョン選定：データ所在地要件とレイテンシ要件を確認し、単一リージョンかマルチリージョンかを決定した
2. アカウント分離：本番・非本番・管理アカウントの分離方針を決定し、AWS Organizationsの利用有無を確定した
3. VPC CIDR設計：オンプレとのアドレス重複チェック済み。将来のサブネット拡張を見越した十分な範囲を確保した
4. IAM権限モデル：SSO or IAMユーザー・長期認証情報を使わない方針・Permission Boundaryの利用有無を決定した
5. アクセス経路：SSM Session Manager or 踏み台サーバーの選択を完了し、フォールバック手段を定義した
6. ログ設計：CloudTrail・VPC Flow Logs・アプリログの保管先・保持期間・閲覧手段を決定した
7. バックアップ設計：バックアップ対象・頻度・リストア手順・テスト計画を確定した
8. RPO/RTO：ビジネス側と技術側で「受け入れられる」数値に合意した
9. コスト境界：コスト配分タグ設計・Budgetsアラート・Egress費用の把握を完了した
10. スケール方針：垂直/水平スケールの主軸・環境停止スケジュールを設計に織り込んだ

決めきれない項目をどう小さく検証するか

「未決」を抱えたまま進む判断の分類

10項目すべてを初週で決めきれるプロジェクトはまれです。決めきれない理由には大きく2種類あります。1つ目は「情報が足りない」ケースで、オンプレ側のIPアドレス体系の全容が把握できていない、業務側のRPO/RTO要件が未確認、といった状況です。この場合は「誰が・いつまでに・何を調査して決める」というアクションに落とし込むことで、作業を前に進められます。2つ目は「選択肢の優劣が不明」ケースで、「SSMにするか踏み台にするか、実際に触ってみないとわからない」「マルチリージョンが本当に必要かどうかコストを試算しないと判断できない」という状況です。これは小さなPoCで検証を先に行う判断が有効です。

小さく検証するPoCの設計

決定を検証するPoCは「1〜2日で結論が出る最小構成」を目指します。SSMアクセスの検証なら「テスト用VPC＋EC2 1台＋最小IAMロール」で、接続の可否・ログ出力の確認・チームの習熟度の3点を測れます。リージョン間レプリケーションのコスト検証なら、サンプルデータ量で試算ツールを走らせることで実費に近い数字が得られます。ここで重要なのは「PoCの目的を判断基準に落とし込む」ことです。「触ってみました」で終わらず、「○○の条件が満たされればAを選ぶ、満たされなければBを選ぶ」という判断フォーマットを先に定義してから検証を始めることで、PoCが意思決定に直結します。

判断の依存関係と移行スケジュールの関係

10項目の中で依存関係が強いのは「アカウント分離→VPC設計→サブネット設計」と「IAM権限モデル→アクセス経路→ログ設計」の2系統です。前者はネットワーク構築の土台になるため最初に決定が必要で、後者はセキュリティ設計の軸であり、リソース作成前に方針を固めておかないと後から上書き作業が発生します。バックアップ・RPO/RTO・コスト境界・スケール方針は構築フェーズの途中でも調整しやすいですが、先送りしてよい理由にはなりません。これらも移行キックオフから2週間以内に確定させることで、構築と並行して運用設計を進められます。オンプレからAWSへの移行で「後から設計し直す」作業は、初期設計の3〜5倍の工数になると現場ではよく語られます。10項目の決定を前倒しにすることが、移行プロジェクト全体の品質と速度を左右する最大の判断です。