Rehostで一旦EC2上に移行した既存アプリケーションを、より運用効率の高いコンテナ基盤へ移行する（Replatform）ことは、モダナイゼーションの代表的な中間ステップです。本記事ではその実践手法を解説します。

SAA レベル：基礎概念

コンテナ化のメリット（おさらい）

環境差異（「自分の環境では動く」問題）を解消し、開発〜本番まで一貫した実行環境を保証
ECS/EKS/Fargateとの組み合わせで、2-1で解説したスケーラブルな運用が可能になる

SAA 試験のポイント

コンテナ化は、必ずしもアプリケーションコードの大規模な書き換えを必要としません。既存のEC2上で動いているアプリケーションを、そのままコンテナイメージ化することも可能である、という点がSAAで問われることがあります。

SAP レベル：高度な設計シナリオ

AWS App2Containerによる自動化

SAP 試験のポイント

AWS App2Container (A2C) は、既存のEC2インスタンスやオンプレミスサーバー上で稼働している.NETやJavaアプリケーションを分析し、依存関係を含めて自動的にコンテナイメージ化するツールです。手動でDockerfileを一から作成する手間を省き、ECS/EKS用のデプロイ設定（タスク定義、CloudFormationテンプレート等）まで自動生成します。SAPレベルでは、大量の既存アプリケーションを効率的にコンテナ化する際の自動化手段として、A2Cの活用が問われます。

コンテナ化の段階的アプローチ

SAP 試験のポイント

コンテナ化とマイクロサービス化は独立した取り組みです。SAPレベルでは、まずモノリシックなアプリケーションをそのままの粒度でコンテナ化し（Replatform）、コンテナ運用の経験を積んでから、必要に応じてマイクロサービスへの分割（Refactor）に着手するという、リスクを分離した段階的アプローチが問われます。一度に両方を行うと、問題発生時の切り分けが困難になります。

段階	内容	リスク
Step 1	モノリスをそのままコンテナ化（ECS/EKSで運用）	低い（アプリロジックは変更なし）
Step 2	必要に応じてマイクロサービスへ段階的に分割	中〜高（アーキテクチャ変更を伴う）

設計上の落とし穴

「コンテナ化するなら、同時にKubernetes（EKS）へ移行し、マイクロサービス化も進めるべき」という一足飛びの判断は、SAPレベルでは過度にリスクの高いアプローチとされることがあります。チームのコンテナ運用経験やKubernetesのスキル成熟度に応じて、まずはECS（学習コストが低い）から始め、必要に応じてEKSへ移行するという段階的な技術選定も、現実的な判断として問われます。

ステートフルなレガシーアプリケーションの考慮

コンテナは本来ステートレスな実行を前提とするため、ローカルファイルシステムに依存したレガシーアプリケーションをそのままコンテナ化する場合、EFSをマウントして永続化データを外部化するといった追加の設計が必要になることがある

まとめ

SAA: コンテナ化が既存アプリの大幅な書き換えなしに実現できる場合があることを理解する。
SAP: App2Containerによる自動化、コンテナ化とマイクロサービス化を分離した段階的アプローチ、チーム習熟度に応じた技術選定ができる。

次は **サーバーレス化（Lambda移行パターン）**を見ていきましょう。