大手保険会社が、IBM z/OSメインフレーム（処理能力15,000 MIPS（Millions of Instructions Per Second：メインフレームの処理能力単位）、月額コスト：約5,000万円）上で稼働するミッションクリティカルなアプリケーション群をAWSへ移行する計画を立てています。 【現在のメインフレーム環境】 ・COBOLアプリケーション：バッチ処理500本（JCL：Job Control Languageで制御） ・オンライントランザクション処理：CICS（Customer Information Control System）100本 ・データストア：VSAMファイル（Virtual Storage Access Method：メインフレーム固有のファイル形式）群、DB2データベース（3TB） ・コードベース：1970年代から累積した約800万行のCOBOL ・依存関係：既存の保険業務ロジックが複雑に絡み合い、完全な書き直しは10年以上かかると試算 【要件と制約】 ・完全なコードの書き直しは予算・期間的に不可能（3年以内に段階的移行） ・JCLバッチジョブのスケジュールとCICSトランザクション処理を維持する ・移行後もCOBOLプログラムをそのまま実行できる環境が必要 ・AWSのマネージドサービスを活用してインフラ管理コストを削減する 最も適切なAWSサービスと移行アプローチはどれですか？
AWS Mainframe Modernizationは、メインフレームワークロードをAWSへ移行するためのマネージドサービスです。「リプラットフォーム」パターンでは、Micro Focus Enterprise Server（COBOLをそのまま実行）またはBlu Age（COBOLをJava/PostgreSQLに自動変換）エンジンを選択できます。JCL・CICS・VSAMをネイティブサポートしており、800万行のCOBOLコードを書き直しなしにAWSのマネージド環境へ移行できます。インフラ管理はAWSが担うためコスト削減も実現できます。 選択肢B の EC2へのリフトアンドシフトはIaaS（Infrastructure as a Service）であり、マネージドサービスの恩恵を受けられずインフラ管理コストが削減されません。500本のJCLをシェルスクリプトに手動変換する作業は膨大で非現実的です。 選択肢C の LambdaはステートレスなFaaS（Function as a Service：関数単位でコードを実行するクラウド実行モデル）で最大実行時間が15分のため、数時間かかるメインフレームバッチジョブには根本的に不適切です。また、COBOLカスタムランタイムはCICS環境を再現できません。 選択肢D の AWS BatchはCOBOLネイティブサポートがなく、JCLをBatch Job Definitionに変換する標準ツールも存在しません。VSAMのアクセスパターン（順次・索引・直接アクセス）はDynamoDBに直接マッピングできず、大規模な書き直しが必要です。