A company runs ML workflows on an on-premises Kubernetes cluster. Each ML service is packaged as a standalone Docker image. They need to lift and shift to an Amazon EKS cluster with the least operational overhead. Which solution meets this requirement?

The correct solution leverages the existing Docker images and the lift-and-shift strategy. Pushing the Docker images to Amazon ECR allows them to be stored securely and accessed by Amazon EKS. Configuring a deployment pipeline (e.g., using AWS CodePipeline or Jenkins) to deploy these images to the EKS cluster minimizes operational overhead because it directly translates the on-premises Kubernetes deployment model to AWS. Redesigning services for Kubeflow introduces significant development and operational overhead, as it requires refactoring existing applications to fit the Kubeflow MLOps framework. Moving training data to Amazon Redshift and retraining models with Amazon Redshift ML, or using Amazon SageMaker notebooks for retraining, are both substantial architectural changes that go beyond a simple lift-and-shift, requiring data migration, model retraining, and potential code rewrites, thus increasing operational overhead.