AWS認定資格 WEB問題集＆徹底解説DevOpsエンジニア プロフェッショナル（DOP）
AWSサービスの一つであるAWS App2Containerはどんな内容なのでしょうか？また、AWS認定資格のDevOpsエンジニア-プロフェッショナル(DOP)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか？
ここでは、そんなあなたの疑問に回答していきたいと思います
1. サービス概要
AWS App2Container（A2C）は、オンプレミスのデータセンターや仮想マシンで稼働中のJava / ASP.NETアプリケーションを解析し、ソースコードなしでコンテナイメージ化して、Amazon ECS・Amazon EKS・AWS App Runnerへデプロイするための成果物を生成するコマンドラインツールです。 7Rの移行戦略でいえば、アプリケーションのコードには手を入れずに実行基盤だけをコンテナへ載せ替える「リプラットフォーム」を支援します。
現状（2026年10月時点）: App2Containerは2025年11月7日以降、新規顧客の受付を終了しています。既存の利用者はこれまでどおり使えますが、これから新たに利用を始めることはできません。 同じ告知でPorting Assistant for .NET、AWS Toolkit for .NET Refactoring、AWS Microservice Extractor for .NETも新規受付を終了しており、AWSは後継として、エージェント型AIで.NETやメインフレーム、VMware環境などのモダナイゼーションを進めるAWS Transformを案内しています。
一方、DOP-C02の試験ガイドは対象サービスにApp2Containerを掲載し続けているため、試験対策としては「稼働中の既存アプリを解析してコンテナ化し、ECS/EKSへのデプロイとCI/CDパイプラインまで一括で用意するツール」という役割を押さえておく必要があります。実務の新規案件ではAWS Transformを検討するのが基本です。
2. 主な特徴と機能
2.1 ソースコード不要のコンテナ化
A2Cは稼働中のプロセスを調べ、実行時の依存関係（連携するプロセスや待ち受けポートなど）を洗い出したうえで、アプリケーションの成果物を抜き出してDockerfileとコンテナイメージを作ります。 ソースコードが手元に無い市販パッケージや、開発チームが既に解散した古い業務アプリでもコンテナ化の起点にできる点が特徴です。
2.2 対応するアプリケーション
- Java（Linux）: Ubuntu / CentOS / RHEL / Amazon Linux上のJavaプロセス。Tomcat、TomEE、JBoss（スタンドアロンモード）は依存関係を絞り込む「アプリケーションモード」に対応。クラスター/HA構成のフレームワークは対象外。
- ASP.NET（Windows）: IIS上のASP.NETアプリ（IISでホストするWCFを含む）やWindowsサービス。コンテナ化の処理はコンテナ対応のWindows Server（2016/2019/2022）で行う。
- ASP.NET（Linux）: .NET Core 3.1〜.NET 8のランタイムを検出し、対応するベースイメージでコンテナ化する。
- 対象外: データベース層はコンテナ化しない。アプリのコンテナからは既存のDBサーバー（または移行先のRDS等）へ接続させる。
2.3 アプリケーションモードとプロセスモード
対応フレームワークを検出できた場合は、必要なファイルと依存関係だけを含めた小さなイメージを作ります（アプリケーションモード）。 対応フレームワークが見つからない場合や他の依存プロセスがある場合は、サーバー上のシステム以外のファイルをすべて取り込む保守的な方式（プロセスモード）になり、イメージが大きくなります。
2.4 デプロイ成果物の生成
コンテナイメージはAmazon ECRへ登録され、デプロイ先に応じてECSのタスク定義、EKSやApp Runner向けのCloudFormationテンプレートなど、ネットワーク・コンピューティング・セキュリティ設定を含む成果物が生成されます。
生成物をレビューしてから自分でデプロイすることも、--deployオプションでそのままCloudFormationスタックを作成することもできます。
2.5 CI/CDパイプラインの雛形
任意で、AWS CodePipelineと関連サービス（CodeBuildなど）を使ったCI/CDパイプラインの成果物も生成できます。 「コンテナ化」と「その後の継続的なビルド・デプロイの自動化」を同じツールで一度に用意できる点が、DOPの設問で正解の決め手になりやすい部分です。
2.6 ワーカーマシン
アプリケーションサーバーに直接インストールして実行するほか、別の「ワーカーマシン」からリモートで棚卸し・解析・抽出を行うこともできます。 本番サーバーに余計な負荷やツールを置きたくない場合や、コンテナを実行できない古いOS（Windows Server 2008/2012 R2など）のアプリを扱う場合に使います。
3. アーキテクチャおよび技術要素
A2Cの処理は「初期化 → 解析 → 変換 → デプロイ」の4フェーズで進みます。
- 初期化:
initでワークスペース、AWSプロファイル、成果物を置くS3バケットなどを設定する。ワーカーマシンを使う場合はremote configureで接続先サーバーを登録する。 - 解析:
inventoryで稼働中のアプリを一覧化してIDを振り、analyzeで依存関係を調べてanalysis.jsonを作る。このファイルは編集してコンテナ設定を調整できる。 - 変換: 必要に応じて
extractでアプリのアーカイブを作り、containerizeでDockerfileとイメージを生成し、デプロイ設定のdeployment.jsonを作る。 - デプロイ:
generate app-deploymentでECS/EKS/App Runner向けの成果物を作り、ECRへイメージを登録する。generate pipelineでCodePipelineのパイプライン成果物を作る。
生成されるのは標準的なCloudFormationテンプレートやタスク定義なので、移行後はA2Cに依存せず、CloudFormationやAWS CDKなどの通常のIaC運用へ引き継げます。
4. セキュリティと認証・認可
- AWS認証情報:
init時に指定したAWSプロファイルの権限で、ECR、ECS/EKS、CloudFormation、S3、CodePipelineなどを操作する。作業用ロールにはこれらに必要な権限だけを付与する。 - 実行権限: Linuxでは解析のために管理者権限（sudo）が必要。ワーカーマシンを使う場合は、アプリケーションサーバー側でリモートアクセスを事前に許可しておく。
- 機密情報の扱い: 抽出したアプリ成果物には設定ファイルが含まれる。接続文字列やパスワードはイメージに焼き込まず、Secrets ManagerやSystems Manager Parameter Storeから注入する形に直す。
- 実行時の権限: デプロイ後はECSのタスクロール/タスク実行ロール、EKSのPod Identityなどで最小権限を設計する。
5. 料金形態
App2Container自体は追加料金なしで提供されています。課金されるのは、コンテナ化したアプリを動かすために使うAWSサービスの利用料です。
- コンテナ実行基盤: ECS（EC2またはFargate）、EKS（クラスター料金＋ノード）、App Runnerの利用料。
- 周辺サービス: ECRのイメージ保存、S3の成果物保存、CodePipeline/CodeBuildの実行、ロードバランサーやNATゲートウェイなど。
- 後継サービス: AWS Transformを使う場合は、そちらの料金体系に従う。
6. よくあるアーキテクチャ・設計パターン
- Tomcat上のJava業務アプリのリプラットフォーム: オンプレのLinuxサーバーでA2Cを実行し、イメージをECRへ登録、ECS on Fargateで稼働させ、生成したCodePipelineで以後の更新を自動化する。
- IIS上の.NET FrameworkアプリのWindowsコンテナ化: コード改修をせずにWindowsコンテナとしてECSまたはEKSへ移し、ハードウェア保守やOS更改の負担を減らす。
- 多数サーバーの一括棚卸し: ワーカーマシンから複数のアプリケーションサーバーを順に解析し、コンテナ化の候補を洗い出す。
- 新規案件での選択: 新規受付終了のため、これから始める.NETやメインフレーム等のモダナイゼーションではAWS Transformを検討する。サーバーをそのままEC2へ移すだけならAWS Application Migration Service（リホスト）を使う。
7. 設定・デプロイ手順（ハンズオン例）
既存利用者がLinux上のTomcatアプリをECSへ移す場合の流れです。
- アプリケーションサーバー（またはワーカーマシン）にA2CとDockerを用意し、AWSプロファイルを設定する。
- ワークスペースを初期化する:
sudo app2container init - 稼働中のアプリを棚卸しする:
sudo app2container inventory（出力されたアプリIDを控える） - 依存関係を解析する:
sudo app2container analyze --application-id java-tomcat-xxxx。生成されたanalysis.jsonを確認し、必要ならポートや環境変数を修正する。 - コンテナ化する:
sudo app2container containerize --application-id java-tomcat-xxxx - デプロイ成果物を作り、ECSへ展開する:
sudo app2container generate app-deployment --application-id java-tomcat-xxxx --deploy - CI/CDを用意する:
sudo app2container generate pipeline --application-id java-tomcat-xxxx --deploy - 動作を確認し、生成されたテンプレートをリポジトリで管理する。
8. 試験で問われやすいポイント
8.1 サービス選択
- Q: 稼働中のJava/.NETアプリを、ソースコードを改修せずにコンテナ化してECSやEKSへ移したい。使うツールは？
A: AWS App2Container。実行中のアプリを解析してDockerfile・イメージ・デプロイ成果物を生成する。 - Q: 既存アプリのコンテナ化に加えて、更新を自動化するCI/CDパイプラインも一緒に用意したい場合は？
A: A2Cのgenerate pipelineでCodePipelineを使うパイプラインの成果物を生成する。 - Q: AWS Application Migration Service（MGN）との違いは？
A: MGNはサーバーをそのままEC2へ移すリホスト、A2Cはアプリをコンテナへ載せ替えるリプラットフォーム。 - Q: AWS Copilot CLIとの違いは？
A: Copilotは既にコンテナ化（Dockerfile化）されたアプリをECSへ展開するツールで、稼働中アプリの解析はしない。なおCopilot CLIは2026年6月12日にサポートを終了している。
8.2 対応範囲と制約
- Q: Javaでアプリケーションモード（最小イメージ）に対応するフレームワークは？
A: Tomcat、TomEE、JBoss（スタンドアロンモード）。それ以外はプロセスモードになり、クラスター/HA構成は非対応。 - Q: データベースもまとめてコンテナ化される？
A: されない。DB層は既存サーバーやRDSなどに残し、コンテナから接続させる。 - Q: Windowsアプリのコンテナ化を実行できるOSは？
A: コンテナ対応のWindows Server 2016/2019/2022。古いOS上のアプリはワーカーマシンを使って処理する。
8.3 成果物とワークフロー
- Q: 解析結果を調整するために編集するファイルは？
A:analyzeが生成するanalysis.json。 - Q: 生成物を確認せずに一気にデプロイするには？
A:generate app-deploymentとgenerate pipelineに--deployを付ける。
8.4 提供状況
- Q: App2Containerは今から新規に使い始められる？
A: できない。2025年11月7日に新規顧客の受付を終了しており、既存顧客のみ継続利用できる。後継として案内されているのはAWS Transform。 - Q: 試験の選択肢にApp2Containerが出たら誤りと考えてよい？
A: いいえ。DOP-C02の試験ガイドは対象サービスに掲載し続けており、「稼働中アプリのコンテナ化＋ECS/EKSデプロイ＋パイプライン生成」を求める設問では正解になりうる。