ヘルスケア企業が、オンプレミスで稼働するマイクロサービスアーキテクチャ（50のサービス、Kubernetes 1.24で管理、各サービスはDockerコンテナとして動作）をAWSへ移行することを決定しました。要件と制約：HIPAA準拠が必要でPHI（保護医療情報）を含むデータは暗号化と厳格なアクセス制御が必要、現在のKubernetesクラスターは自己管理でアップグレードに多大なオーバーヘッドがかかっている、サービスメッシュ（Istio）を使用してサービス間通信を管理している、CI/CDパイプラインはJenkinsで構築されGitHubと統合がある、一部のサービスはステートフル（PostgreSQL・Redisをコンテナとして実行）、移行後は運用オーバーヘッドを削減したい、開発チームのKubernetes習熟度は高い。最適な移行アーキテクチャとして適切なものを2つ選択してください。
正解A（EKS）：既存のKubernetesワークロードを最小変更で移行でき、高いKubernetes習熟度を持つチームに最適です。マネージドコントロールプレーンによりアップグレードオーバーヘッドを削減でき、HIPAA準拠のための暗号化・IAM統合も可能です。なお、AWS App MeshはEOLが2026年9月に予定されており新規採用は推奨されないため、サービスメッシュはEKS上でIstioを継続稼働させることが現実的です。 正解B（Aurora/ElastiCache）：ステートフルサービスのAWSマネージドサービスへの移行は運用オーバーヘッドを大幅に削減します。Aurora PostgreSQLとElastiCacheはHIPAAエリジブルサービスとして保存時・転送時暗号化・監査ログ・自動バックアップをネイティブに提供します。 選択肢C（App Runner）は誤りです。サービスメッシュや50サービス規模のマイクロサービスの複雑性に対応できず不適切です。 選択肢D（ECS/Fargate）は誤りです。KubernetesマニフェストをECS形式へ手動で再実装するコストが高く、既存のKubernetes習熟度を活かせないため移行リスクが増大します。 選択肢E（Outposts）は誤りです。オンプレミスの運用オーバーヘッドを維持するため「運用オーバーヘッド削減」の要件を満たしません。