SAP-C02
Deep Dive
Once applications are migrated, modernization transforms legacy systems into cloud-native architectures. The SAP-C02 tests knowledge of patterns like Strangler Fig, progressive containerization, and the transition to serverless and event-driven designs.
Contents
Modernization isn't a single event — it's a continuum. Patterns let you modernize incrementally, reducing risk vs a "Big Bang rewrite".
Incremental
Modernize component by component. The legacy and new systems coexist during the transition. Lower risk, more time.
Strangler Fig, Branch by Abstraction
Parallel Run
The legacy and new systems run in parallel processing the same traffic. Verify results before a full cutover.
Shadow deployments, Traffic splitting
Expand-Contract
Add new functionality in parallel (expand), migrate consumers to the new system, remove the old one (contract). For schema or API changes.
API v1 → v2 migration with backward compatibility
The Strangler Fig Pattern migrates a monolith by extracting functionality one piece at a time into independent microservices, without rewriting everything from scratch. A proxy/API Gateway routes traffic to the monolith or the new microservice depending on the route.
Identify the functionality to extract
Select a bounded context with clear boundaries (e.g. the payments module). It must be independent of the rest of the monolith.
Deploy the new microservice in parallel
Build the microservice on ECS/Lambda/EKS. Initially with no production traffic.
Configure the proxy/API Gateway
API Gateway or ALB routes /api/payments/* to the new microservice, everything else goes to the monolith.
Migrate traffic gradually
Canary deployment: 10% → 50% → 100%. Immediate rollback if errors occur.
Remove the monolith code
Once the microservice handles 100% of the traffic, remove the functionality from the monolith.
Strangler Fig with API Gateway or an ALB
Proxy routing between the monolith and the new microservices is implemented with API Gateway or an ALB with path-based rules, diverting each feature to its microservice as it is extracted. AWS Refactor Spaces, which automated this, was part of Migration Hub, which no longer accepts new customers.
Containerization path
Lift & Shift into a container
Package the existing app in Docker with no changes. Same configuration, more portability. Rehost first, optimize later.
Containerize + managed DB
App on ECS Fargate + migrate the DB from EC2 to RDS. Replatform with containers.
Microservices in containers
Full refactor: each microservice in its own container with independent CI/CD.
AWS containerization tools
Serverless modernization replaces components running on permanent servers with event-driven services that scale to zero. Not everything can or should go serverless — apply it selectively.
| Legacy component | Serverless equivalent | Benefit |
|---|---|---|
| Cron jobs on EC2 (nightly scripts) | EventBridge Scheduler + Lambda | No idle instances for 23h |
| API on EC2 + ALB | API Gateway + Lambda | Scales to 0, pay per request |
| Message queue with workers on EC2 | SQS + Lambda | No permanent workers, automatic scaling |
| Batch processing on EC2 | AWS Batch or Step Functions + Lambda | No permanent cluster, pay per job |
| WebSockets with an EC2 server | API Gateway WebSocket + Lambda + DynamoDB | No permanent stateful server |
| Daily batch ETL in a Python script | Glue Streaming or Step Functions + Lambda | Serverless ETL, automatic scaling |
When serverless is NOT appropriate
Lambda has a 15-minute execution limit and 10 GB of memory. For long-running jobs (hours) or heavy compute → ECS/EKS or AWS Batch. For workloads with critical cold-start latency → EC2 instances with a warm pool or Provisioned Concurrency on Lambda.
From synchronous to asynchronous
Before (synchronous)
API calls 5 services in sequence. If one fails, the whole operation fails. Accumulated latency. Tight coupling.
After (asynchronous with SQS/SNS)
API publishes an event to SNS. 5 services consume from their own SQS queues. Fault isolation, independent retries, no coupling.
CQRS and Event Sourcing patterns
| Situation | Modernization strategy | Tool |
|---|---|---|
| Oracle DB on EC2 — high licensing cost | Migrate to Aurora PostgreSQL (Babelfish for SQL Server compatibility) | AWS SCT + DMS |
| On-premises MySQL/PostgreSQL | Migrate to Aurora (same engine, better performance and HA) | DMS with minimal downtime |
| MongoDB on EC2 | Migrate to Amazon DocumentDB | mongodump / mongorestore or DMS |
| DynamoDB table with a hot partition | Redesign the partition key, add a random suffix (write sharding) | Data design review |
| Relational database with slow analytical queries | Segregate: OLTP on RDS, OLAP on Redshift with DMS or Kinesis | Redshift + DMS / Firehose |
| On-premises DB with compliance requiring < 1ms latency | Retain (don't migrate) or AWS Local Zones + Outposts | AWS Outposts |
CodeCommit
Managed Git repository. Integrated with IAM for granular access control.
CodeBuild
Serverless build: compiles, runs tests, produces artifacts. Pay per build minute.
CodeDeploy
Automated deployment to EC2, ECS, Lambda and on-premises. Native Blue/Green and Canary deployment.
CodePipeline
CI/CD pipeline orchestrator. Integrates Source → Build → Test → Deploy automatically.
Blue/Green Deployment — zero downtime
Blue/Green creates an identical environment (green) with the new version while blue keeps serving traffic. Once green is validated, traffic switches instantly. On ECS with CodeDeploy: the ALB has two target groups, CodeDeploy switches the routing. Immediate rollback by switching routing back to blue.
Trap: "Modernizing always means moving to microservices"
Reality: Modernization can be as simple as moving a DB from EC2 to RDS (Replatform), or containerizing the monolith without splitting it. Microservices are one end of the spectrum — not always the right goal.
Trap: "Strangler Fig requires rewriting the entire application"
Reality: The opposite is true. Strangler Fig is an INCREMENTAL pattern — it extracts one piece of functionality at a time without touching the rest of the monolith. The monolith keeps running throughout the whole transition.
Trap: "Blue/Green deployment and Canary are the same thing"
Reality: They're different. Blue/Green switches 100% of traffic at once (after validating green). Canary gradually shifts a small percentage (5–10%) of traffic to the new version before making the full switch.
Did you get this topic?
Test what you just learned
A company has a Java monolith deployed on 4 EC2 instances behind an ALB. They want to modernize it gradually toward microservices without interrupting service. The notifications module is the first to be extracted. What is the correct approach?
Put what you learned to the test with original SAP-C02 exam questions.
Start SAP-C02 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.