このシリーズについて
本シリーズ「AWS移行のサービス選定」は、オンプレミス環境を AWS に移行する際に 「どのサービスを選ぶべきか」 の意思決定を設計観点で解説する。 各レイヤー（コンピュート・DB・ストレージ・ネットワーク・非同期・監視）ごとに判断フローを整理し、「なぜそのサービスか」を理解できる構成にしている。
なぜ戦略を先に決めるのか
移行プロジェクトでよくある失敗パターンが、「とりあえず EC2 に移す」 という判断だ。 確かに EC2 は最も移行コストが低いが、それがゴールになってしまうと「クラウドに移したのにコストが下がらない」「運用負荷が変わらない」という結果になりやすい。
逆に最初からすべてをサーバーレス・コンテナ化しようとすると、移行コストが膨大になり、スケジュールが崩壊する。
戦略（どう移行するか）を先に決めることで、後続のサービス選定の方向性が一気に定まる。 移行戦略の代表的な分類が「6R」だ。
移行戦略の分類：6R とは
AWS が提唱する 6R は、ワークロードをどのように移行・処理するかを6つのパターンに分類したものだ。
| 戦略 | 別名 | 概要 | 難易度 | メリット |
|---|---|---|---|---|
| Rehost | リフト＆シフト | アプリを変更せず EC2 等に移す | 低 | 移行速度が最速。コスト削減はリソース最適化フェーズで後追い |
| Replatform | リフト・ティンカー・シフト | 最低限の改修でマネージドサービスに乗り換え（DBをRDSに移すなど） | 中 | コード改修を最小化しつつ運用負荷を削減 |
| Refactor | Re-architect | クラウドネイティブなアーキテクチャに作り直す（コンテナ・サーバーレス等） | 高 | スケーラビリティ・コスト効率を最大化。中長期で最もメリット大 |
| Repurchase | Drop and Shop | SaaS へ切り替える（CRM を Salesforce に替える等） | 中 | 自前運用から脱却。ライセンスコスト見直しも同時に |
| Retire | — | 使われていないシステムを廃止する | 低 | コスト削減。移行対象を絞り込む |
| Retain | Re-visit | 今は移行しない（規制・依存関係等の理由で） | — | ハイブリッド構成でリスク分散。将来のフェーズへ先送り |
判断フロー
以下のフローに沿って、ワークロードごとに戦略を選択する。
✅ 実務のコツ：ワークロード単位で判断する
プロジェクト全体で一つの戦略を選ぶのではなく、ワークロード（サービス・機能）ごとに戦略を決めるのが現実的だ。例えば「フロントエンドは Refactor（CloudFront + S3）、バッチは Replatform（RDS移行）、レガシー基幹は Rehost（EC2）」という混在構成は珍しくない。
Rehost（リフト＆シフト）
最も移行コストが低い戦略。既存のアプリをそのまま EC2 に移す。
向いているケース：
- 移行期限が迫っている（データセンター契約終了など）
- レガシーアプリでコードを触れない
- まずオンプレの固定費を解消したい
Rehost 後にやること：
移行後に リソース最適化（適切なインスタンスタイプ選定、Reserved Instance 購入）や 部分的な Replatform（RDS 移行など）を段階的に進めることで、コスト削減効果を積み上げていく。Rehost はゴールではなく、移行の入口と捉えるのが正しい。
⚠️ Rehost の落とし穴：オンプレ慣習の持ち込み
オンプレでは「万が一に備えてリソースを多めに確保」が当たり前だったが、AWS では過剰なスペックはそのままコストになる。Rehost 後は AWS Compute Optimizer や Cost Explorer で定期的に見直しが必要だ。
Replatform（最低限の最適化）
アプリのコアロジックを変えずに、一部のコンポーネントをマネージドサービスに置き換える戦略。
代表的なパターン：
- オンプレ MySQL → Amazon RDS（アプリのDB接続先を変更するだけ）
- 物理サーバー上のアプリ → EC2 から ECS/Fargate へ（コンテナ化）
- オンプレ Redis → ElastiCache（接続設定の変更のみ）
コードの大幅改修なしに OS パッチ・DB バージョン管理・バックアップなどの運用負荷を AWS に委ねられる点がメリットだ。
Refactor（クラウドネイティブ化）
アーキテクチャを根本から再設計する。最もコストと期間がかかるが、長期的なコスト効率・スケーラビリティ・開発速度で最大のメリットを得られる。
代表的なパターン：
- モノリシックアプリ → マイクロサービス（ECS/EKS）
- バッチ処理 → Lambda + EventBridge（サーバーレス）
- オンプレ AP サーバー → コンテナ（Fargate）+ ALB
💡 Refactor を選ぶ判断基準
「スケールが読めない」「需要の波が激しい」「開発チームの CI/CD を整備したい」といったケースで Refactor の投資対効果が高くなる。一方、安定した需要・変更頻度が低いシステムは Replatform で十分なことも多い。
その他の R（Retire / Retain / Repurchase）
移行対象のシステム棚卸しで意外と見落とされるのが Retire（廃止） だ。 多くの組織では「使われているかもしれない」という懸念から廃止に踏み切れないシステムが多数ある。 利用状況を実際に確認し、廃止できるものを先に整理するだけで移行スコープを大幅に絞れる。
Retain（保留） は「今は移行しない」という明示的な判断だ。 規制対応中・依存システムの改修待ち・コスト的に移行メリットが薄いシステムなどが対象になる。 放置と区別するためにも、「いつ再判断するか」を記録しておくことが重要だ。
実務での使い方
移行プロジェクトのキックオフ段階で、以下のようなワークロード棚卸しシートを作ることを勧める。
| システム名 | 用途 | 利用状況 | 変更可否 | 戦略 | 備考 |
|---|---|---|---|---|---|
| 受注管理（Web） | 業務中核 | 高頻度 | 可（中規模改修） | Replatform | DB を RDS へ |
| 夜間バッチ | 日次集計 | 毎日 | 可（大幅改修 OK） | Refactor | Lambda + Step Functions |
| 旧社内ポータル | お知らせ閲覧 | ほぼゼロ | — | Retire | 新ポータルへ統合済み |
| メインフレーム連携 | 会計系 | 高頻度 | 不可（規制対応中） | Retain | 2027年度再評価 |
✅ 次の章では…
PART 02 ではコンピュートレイヤーの判断フローを解説する。EC2・ECS/Fargate・Lambda のどれを選ぶかを、ワークロードの性質から判断する方法を整理する。