A regulated fintech company runs 15 containerized microservices handling ledger writes and notifications. The team has no Kubernetes expertise, must avoid EC2 node patching, requires AWS-native service discovery between services, and needs isolated IAM permissions per microservice task. Which container orchestration approach meets these microservice isolation and operations requirements?
Select an answer to reveal the explanation.
Short Explanation
You've got no K8s crew and no appetite for patching, so you'll love how ECS on serverless handles the heavy lifting. It's like room service for containers — networking, discovery, and launch handled for you — secured by task IAM roles per service.
Full Explanation
Amazon ECS with AWS Fargate removes EC2 node patching and the Kubernetes control plane, which directly matches the lack of Kubernetes expertise and the no-node-management constraint, while Service Connect provides AWS-native service discovery and load balancing between microservices without you running your own proxy or mesh, and per-task IAM roles scope AWS permissions to each microservice for ledger isolation. Running on Amazon EKS with Fargate still satisfies serverless compute but fails the operations concept because it retains Kubernetes API, upgrade, manifest and controller complexity the team explicitly wants to avoid. Running on Amazon ECS with EC2 launch type preserves ECS simplicity but fails the serverless concept because self-managed EC2 requires patching, scaling and agent management. Running on Amazon EKS with managed node groups fails both constraints because it adds node-group operations plus a third-party Istio mesh when native Service Connect would suffice. Exam caveat: choose ECS plus Fargate when the stem stresses simplicity and no Kubernetes skills, and reserve EKS when Kubernetes APIs or portability are required. Practical check: verify Fargate platform version, Service Connect namespaces and task role trust policies in the task definitions.