Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig
Key Takeaways
- Amazon ECS is the AWS-native orchestrator; Amazon EKS is managed Kubernetes; AWS Fargate is the serverless compute engine you can use with ECS or EKS so you do not manage container hosts; Amazon ECR is the registry, not an orchestrator.
- Do not force Kubernetes on a team with no operators, Helm estate, or portability requirement—ECS on Fargate is the usual Professional answer for a first container landing.
- The strangler-fig pattern puts a facade (API Gateway or Application Load Balancer path rules) in front of a monolith and peels routes to new container or Lambda services until the monolith can be retired.
- AWS App2Container remains a documented replatform-to-containers pattern for ASP.NET and Java without source-code rewrites, but AWS closed it to new customers after 7 November 2025; existing enrolled customers can still use it, and AWS now points new .NET modernization at AWS Transform and at Migration Hub Orchestrator’s replatform-to-ECS template.
- App2Container’s published EKS path launches on EC2, not EKS on Fargate; Java on A2C defaults to ECS on Fargate, not to a Kubernetes control plane.
Containers as a landing, not as a religion
SAP-C02 Task 4.3 includes selecting the appropriate container hosting platform. Task 4.4 repeats containers as a modernization opportunity. Independent OpenExamPrep teaching in this section keeps those skills distinct from Domain 2 greenfield container design: here the application already exists. You are choosing whether a rehosted guest becomes a container this wave, whether a monolith is strangled behind a facade, and whether the orchestrator is Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS).
Amazon Elastic Container Registry (Amazon ECR) stores images. It is not a scheduler. Stems that “put the app in ECR” without ECS, EKS, App Runner, Elastic Beanstalk, or Lambda have not chosen a runtime.
AWS Fargate is a technology you use with ECS or EKS to run containers without managing Amazon EC2 container instances. You package the application, declare CPU and memory, attach networking and AWS Identity and Access Management (IAM) task roles, and launch. AWS documents that each Fargate task has its own isolation boundary and does not share kernel, CPU, memory, or elastic network interface with another task. Fargate is not a third orchestrator sitting beside ECS and EKS.
When ECS is enough
Amazon ECS is a fully managed orchestrator that speaks AWS APIs: task definitions, services, capacity providers, and first-class integration with Elastic Load Balancing, IAM, CloudWatch, and Secrets Manager. Choose ECS when Meridian’s platform team wants containers without operating a Kubernetes control plane, when AWS-native IAM and VPC design already match the landing zone, and when the application is a conventional web or worker service rather than a fleet of custom resource definitions.
Launch types still matter:
| Launch choice | Who patches the host | Typical modernization tell |
|---|---|---|
| ECS on Fargate | AWS | First container landing; no GPU/host-namespace needs; pay for task CPU/memory |
| ECS on EC2 | You (or managed node automation) | Daemon patterns, custom AMIs, GPU, or density packing that Fargate task shapes cannot express |
| EKS on Fargate | AWS for data-plane pods that Fargate supports | Kubernetes API required and you still do not want node groups for those pods |
| EKS on EC2 (including managed node groups or Karpenter-style provisioning) | Shared: AWS for the control plane, you for nodes unless you add more automation | Helm, operators, DaemonSets on nodes, or an existing Kubernetes estate |
Fargate is the default people-cost win after a rehost: you stop patching a container host OS. It is the wrong answer when the stem needs privileged host access, a DaemonSet on every node, or hardware Fargate does not offer for that workload. Then ECS on EC2 or EKS on EC2 is the honest landing.
When not to force Kubernetes
Amazon EKS runs Kubernetes. Teams choose it for the Kubernetes ecosystem (Helm, operators, custom resource definitions), consistent manifests across hybrid or multi-cloud, Amazon EKS Anywhere or Amazon EKS Distro stories, and existing Kubernetes skills. The AWS container decision guidance is blunt in spirit: EKS provides Kubernetes flexibility; ECS is the simpler AWS-native path.
Do not force Kubernetes when:
- The platform team has no Kubernetes operators and no desire to staff them.
- The application is one or two services that ECS on Fargate plus an Application Load Balancer already serve.
- The only argument is “containers mean Kubernetes.”
- App2Container (or an Orchestrator replatform-to-ECS template) already emitted ECS artifacts and nobody asked for Helm.
Forcing EKS in those stems adds a control plane, node IAM, Kubernetes upgrades, and a second mental model next to the landing zone’s ECS-based internal platforms. Professional items reward the smaller operating model that still meets the requirement.
Choose EKS when the stem already has Kubernetes in production, needs a Kubernetes-only capability, or must keep manifests portable to another Kubernetes cluster. Then EKS is not fashion; it is continuity.
Strangler fig for the clinic-portal monolith
Meridian’s patient portal is a decade-old monolith: registration, scheduling, billing, and a PDF generator in one deployment unit. Product wants billing APIs weekly. Operations will not freeze the portal for a six-month rewrite. That is not a weekend rehost-or-bust item. It is strangler fig.
The strangler-fig pattern (the name Martin Fowler popularized, and the pattern AWS microservices guidance uses) places a facade in front of the existing system and incrementally routes slices of behavior to new services until the old system is “strangled” and can be retired. On AWS the facade is usually:
- Amazon API Gateway HTTP or REST APIs with path-based integrations (monolith VPC link versus new ECS or Lambda integrations).
- An Application Load Balancer with host or path rules (
/billing*to a new target group, everything else to the monolith target group). - Sometimes Amazon Route 53 weighted records when you are shifting a whole hostname rather than a path.
A Professional sequence for Meridian:
- Rehost or replatform the monolith as-is so the lease exit is not blocked by a rewrite (Task 4.3 landing on EC2 or ECS).
- Put the facade in front before you extract code.
- Extract billing as a container on ECS on Fargate (or a Lambda if the work is event-sized) talking to its own data store or to the existing database through a carefully bounded schema.
- Route only
/billingto the new service. Keep/registerand/scheduleon the monolith. - Repeat for the next bounded context. Retire the monolith when it no longer serves production routes.
Exam traps: rewriting the monolith in Kubernetes in one cutover; pointing Route 53 at the new service for all paths on night one; extracting billing but leaving both services writing the same rows without a data-ownership plan; calling a rolling AMI replacement “strangler fig.”
App2Container as a pattern—if current for that customer
AWS App2Container (A2C) is a command-line tool that inventories running ASP.NET (Windows) and Java (Linux) applications, analyzes runtime dependencies, and produces Open Container Initiative images without requiring source code. It can emit Dockerfiles, push images to Amazon ECR, and generate AWS CloudFormation for Amazon ECS, Amazon EKS, or AWS App Runner, optionally with an AWS CodePipeline path. AWS Prescriptive Guidance still lists App2Container as a replatform example for moving virtual machines into containers without code changes.
Current AWS documentation (App2Container user guide) states that Porting Assistant for .NET, App2Container, AWS Toolkit for .NET Refactoring, and AWS Microservice Extractor for .NET are no longer open to new customers. Sign-up had to occur prior to 7 November 2025. AWS directs new .NET modernization to AWS Transform. For a console-based replatform, AWS documents the Replatform applications to Amazon ECS template in AWS Migration Hub Orchestrator. On a September 2026 exam stem, treat A2C as a valid pattern for an already-enrolled customer or when the stem still names the tool. Do not invent a requirement that every new AWS account in 2026 must install A2C.
If A2C is in play, respect its published launch limits rather than assuming “containers on EKS Fargate.” AWS documents:
- ECS on Fargate as the default for Java, and for .NET applications that meet Fargate prerequisites; both Linux and Windows containers are supported on Fargate in A2C’s ECS integration.
- ECS on EC2 for .NET applications that do not meet those Fargate criteria; AWS states Java is not currently supported for that EC2 deploy target in A2C.
- EKS artifacts that launch application containers on EC2. AWS states App2Container does not currently support Fargate as a launch type for Amazon EKS.
Only one of createEcsArtifacts or createEksArtifacts should be true. Default destination is ECS. Flipping to EKS is a conscious Kubernetes decision, not a free upgrade.
Meridian’s Java clinic-search service on Linux VMs, owned by a team that has never run kube-apiserver, should land as containers in ECR + ECS on Fargate (via A2C if they already have it, or via the Orchestrator ECS replatform template / a standard Dockerfile pipeline if they do not). Standing up EKS “so we are future-proof” is how you fail a Task 4.4 container-selection item.
Putting the pieces together
ECR holds versions. ECS or EKS schedules them. Fargate removes the host if the task shape fits. Strangler fig removes the monolith one route at a time. App2Container or its current AWS-published successors remove the “we need source code to containerize” excuse for supported .NET and Java estates. None of that is a substitute for identity, networking, and data ownership in the landing zone.
Meridian’s platform team can operate Amazon ECS, IAM task roles, and Application Load Balancers. Nobody on the team has run a Kubernetes control plane, Helm, or operators. A Java clinic-search service must move from Linux virtual machines into containers this quarter with no application rewrite. Which hosting platform should the architect select?
Meridian’s patient portal is a monolith that still handles registration, scheduling, and billing. Product needs independent billing releases without a six-month freeze of the whole portal. The monolith will keep serving the other routes for months. Which design matches the strangler-fig pattern?
An existing Meridian customer enrolled in AWS App2Container before AWS closed new sign-ups. They want to containerize a Linux Java application without source-code changes and run it without managing container hosts. They do not operate Kubernetes. Which statement should guide the target artifacts?