大手製薬企業がオンプレミスで稼働する40本の.NET Framework 4.8 Webアプリケーション（Windows Server 2019上）をAWSのコンテナ基盤へ移行する計画を立てています。これらのアプリケーシ

Question

大手製薬企業がオンプレミスで稼働する40本の.NET Framework 4.8 Webアプリケーション（Windows Server 2019上）をAWSのコンテナ基盤へ移行する計画を立てています。これらのアプリケーションはWindows認証（NTLM/Kerberos）、COM+コンポーネント、Windowsレジストリを設定に使用しており、コードの大幅な書き換えは避けることが必須要件です。プラットフォームチームは以下を求めています：
①アプリケーション依存関係の自動検出とDockerイメージの自動生成
②AWS CloudFormationテンプレートの自動出力
③WindowsコンテナをサポートするAWSマネージドコンテナサービスへのデプロイ
④40本を効率的に管理できる運用負荷の最小化
この要件をすべて満たす最適なアプローチはどれですか？

Accepted Answer

正解: AWS App2ContainerをWindows Server 2019上でエージェントとして実行し、.NETアプリの依存関係を自動検出してDockerイメージとCloudFormation/ECSタスク定義テンプレートを生成する。生成したWindowsコンテナイメージをAmazon ECS（EC2起動タイプ、Windows Server Core AMI）にデプロイし、ALBとAuto Scalingグループで可用性とスケーラビリティを確保する。。AWS App2Containerは、稼働中のサーバー上でエージェントを実行し、Java/.NETアプリの依存関係を自動検出してDockerイメージとCloudFormation/ECSタスク定義テンプレートを自動生成する移行ツールです。Windows Server上の.NET Framework 4.8アプリをコードの書き換えなしにWindowsコンテナとしてパッケージ化でき、Amazon ECSのEC2起動タイプ（Windows Server Core AMI）はWindowsコンテナを完全サポートします。40本のアプリもECSクラスターで統一管理でき、全要件を満たす最適解です。

選択肢BのAWS FargateはWindowsコンテナをサポートしていますが、COM+コンポーネントやNTLM/KerberosなどWindows固有機能のコンテナ化にはECS EC2起動タイプ（Windows Server Core AMI）の方が互換性が高く、App2Containerが生成するCloudFormationテンプレートもEC2起動タイプ向けに最適化されています。Fargateでの実行には追加の設定変更が必要です。

選択肢CのAWS Application Migration Serviceはリフト＆シフトには有効ですが、その後の手動Dockerfile作成では依存関係の自動分析とCloudFormationテンプレート自動生成の要件を満たしません。40本のアプリに対して多大な手作業が発生します。

選択肢DのAWS Schema Conversion ToolはデータベーススキーマをターゲットDBに変換するツールであり、アプリケーションコードの変換機能は持ちません。COM+やNTLMなどのWindows固有コンポーネントをLinuxへ自動変換することは技術的に不可能であり、大幅なコード書き換えが必要となります。

Answer

AWS App2ContainerでWindows Server上の.NETアプリを自動分析・コンテナ化し、DockerイメージをAmazon ECRに格納する。コンテナ実行基盤にはAWS Fargate（FargateはWindowsコンテナをサポートしており、EC2インスタンス管理が不要）を選択して、40本のアプリの運用負荷を大幅に低減する。 — FargateはWindowsコンテナをサポートしていますが、COM+コンポーネントやNTLM/KerberosなどWindows固有機能はECS EC2起動タイプ（Windows Server Core AMI）の方が互換性が高く、App2Containerが生成するCloudFormationテンプレートもEC2タイプ向けに最適化されているため、Fargate選択では追加設定変更が必要です。

Answer

AWS Application Migration Service（MGN）で40本のアプリを稼働するWindowsサーバーをAmazon EC2（Windows Server 2019）にリフト＆シフトする。その後AWS Systems Manager Run Commandで各EC2にDockerをインストールし、開発チームが手動でDockerfileを作成・ECRにプッシュしてECS EC2で実行する。 — MGNによるEC2へのリフト＆シフト後に開発チームが手動でDockerfileを作成するアプローチは、依存関係の自動分析とCloudFormationテンプレート自動生成の要件を満たしません。40本のアプリに対して手作業が膨大となり、コンテナ化の効率化要件にも反します。

Answer

AWS Schema Conversion Tool（SCT）で.NET Framework 4.8コードをLinux互換の.NET 8に自動変換し、LinuxベースのDockerコンテナイメージを生成する。AWS Fargateのサーバーレスコンテナ環境にデプロイし、COM+やNTLMなどのWindows固有コンポーネントはSCTが自動的にLinux互換実装に変換することでコードの書き換えを最小化する。 — AWS SCTはデータベーススキーマの変換ツールであり、アプリケーションコード（.NET Framework）の変換機能を持ちません。COM+やNTLMはLinux上に存在せず、「SCTが自動的にLinux互換実装に変換」という説明は技術的に誤りで、大幅なコード書き換えが必要となります。

解説

解説