What's changed: Deepened SAP-C02 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.3Modernizing on the Cloud
Understand post-migration modernization—containers (ECS/EKS/Fargate), serverless, decomposing into microservices, and incremental migration via the strangler fig pattern. Improve agility, scale, and cost-efficiency.
Modernization moves a monolith to containers/serverless and decomposes it into microservices—done incrementally, not all at once.
4.3.1Modernization patterns
- Containers: EKS (Kubernetes) / ECS (AWS-native); use Fargate for no server management.
- Serverless: Lambda for small event-driven functions; scales with zero infra management.
- Microservices: decompose the monolith by capability for independent deploy/scale.
- Strangler fig: run old/new behind a router and shift features gradually to new services, retiring the old last.
Common on SAP-C02: Kubernetes required = EKS, AWS-native containers = ECS, no-server-management containers = Fargate, event-driven functions = Lambda, safe incremental monolith migration = strangler fig pattern. Big-bang rewrites are risky; incremental migration is preferred.
Choose EKS for existing Kubernetes assets/portability, ECS for tighter AWS integration and simpler ops; pick Fargate as the launch type to avoid managing servers in either.
Modernization questions probe "the axes for choosing a runtime" and "how to migrate safely." ECS and EKS both orchestrate containers, but ECS is AWS-native with a low learning curve and tight IAM/ALB/CloudWatch integration, while EKS uses standard Kubernetes APIs for multi-cloud portability and ecosystem (Helm/Operators). Both offer launch types: EC2 (self-managed nodes for cost tuning or daemon needs) or Fargate (serverless, zero node management). Lambda suits event-driven, short, intermittent workloads and incurs no charge while idle—but has execution-time and package-size limits, so steady high-throughput or long-running work favors containers. Because big-bang rewrites are risky, dismantle a monolith with the strangler fig pattern: place an API Gateway or ALB as a "facade," carve out features one at a time into new services and re-point routing, then retire the old monolith last. Separating state (splitting databases) and loose coupling between services (SQS/SNS/EventBridge) are also key modernization ingredients.
| Requirement | Runtime | Why |
|---|---|---|
| Kubernetes standard/portability | EKS | K8s APIs, reuse assets/ecosystem |
| AWS-native, simpler ops | ECS | Tight IAM/ALB/CloudWatch integration |
| No server management | Fargate (launch type) | Serverless, zero node management |
| Event-driven/intermittent | Lambda | No idle charge, auto-scale |
Scenario: Incrementally break a bloated ordering monolith into microservices without downtime, starting with just the "inventory lookup" feature. → Put an ALB/API Gateway facade in front and route only the inventory-lookup path to a new ECS (Fargate) service. Keep the old monolith running; once validated, move the next feature, and so on (strangler fig). Loosely couple services via EventBridge, and retire the monolith last.
FAQ: When Lambda vs containers? For intermittent, event-driven, short (within minutes) work where you want no idle cost, use Lambda. For steady high load, long-running execution, or special runtimes/large dependencies, use ECS/EKS (with Fargate as needed). Mixing them—Lambda at the front, containers for heavy long-lived work—is common.
Exam trap: Choosing a big-bang full rewrite to "safely modernize a huge monolith" is wrong—high risk and hard to roll back. The answer is incremental migration via the strangler fig pattern. Also, choosing EKS when Kubernetes is not a requirement tends to over-complicate operations; ECS is the safer default there.
4.3.2Section summary
- Runtime = EKS/ECS/Fargate (containers), Lambda (serverless)
- Modernize = microservices + strangler fig incremental migration
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to run containers reusing existing Kubernetes manifests and ecosystem. What on AWS?
Q2. You want to run containers without ever managing, patching, or scaling EC2 servers. Which launch type?
Q3. You want to replace a huge monolith with microservices gradually and with low risk. Best approach?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.