By the time a workload reaches AWS, the interesting architectural decisions are only beginning. The SAP-C02 exam knows this, which is why an entire domain — Accelerate Workload Migration and Modernization, about 20% of the scored content — sits after the migration is theoretically done. This domain is where the exam stops asking “how do you move it?” and starts asking “how do you make it worth having moved?”
Most candidates prepare for the migration half of this story — the 7 Rs, the migration tooling, the portfolio assessment — and stop there. They can tell you the difference between rehost and replatform, then freeze when a scenario describes a monolithic .NET application on EC2 that the business wants to decompose into services without a risky big-bang rewrite. That scenario is testing modernization, and the answer is rarely “rewrite it.” This guide covers what modernization means on the SAP-C02, how to choose a container or serverless target, how the strangler fig pattern lets you refactor incrementally, and how to modernize the data tier — the part most rewrites get wrong.
If you haven’t yet mapped the whole blueprint, start with the AWS Solutions Architect Professional guide for 2026 and the SAP-C02 study plan. This guide builds directly on the SAP-C02 migration strategies guide: migration gets the workload to AWS, modernization is what you do with the “Refactor” and “Replatform” R’s once it’s there.
Where Modernization Sits in the SAP-C02 Blueprint
The exam draws a deliberate line between migration and modernization, and reading a scenario correctly depends on knowing which one it’s testing:
- Migration answers “how do we get this to AWS with acceptable risk and effort?” — the 7 Rs, AWS Application Migration Service (MGN), Database Migration Service (DMS), and cutover planning.
- Modernization answers “how do we change the architecture to reduce operational burden, cost, or time-to-market?” — containers, serverless, managed data services, and decoupling.
The two overlap at two of the 7 Rs. Replatform (“lift-tinker-and-shift”) makes a targeted change during the move — for example, migrating a self-managed MySQL box to Amazon RDS. Refactor / Re-architect changes the application’s structure — breaking a monolith into services, moving to event-driven communication, or going serverless. When a SAP-C02 scenario emphasises reducing operational overhead, improving elasticity, or decoupling teams so they can deploy independently, it is signalling refactor/re-architect, and the highest-scoring answer usually chooses the most managed option the constraints allow.
The Modernization Decision: Rehost, Replatform, or Refactor
Before choosing a target, decide how far to go. The exam rewards matching the degree of change to the business driver, not defaulting to the most modern option.
| Strategy | What changes | Effort / risk | Choose when the scenario stresses… |
|---|---|---|---|
| Rehost (lift-and-shift) | Nothing — same binaries on EC2 | Lowest | Speed, a hard datacenter-exit deadline, “no time to change code” |
| Replatform (lift-tinker-shift) | Swap a component for a managed service (RDS, ElastiCache, MQ) | Low–medium | Cutting undifferentiated ops with minimal code change |
| Refactor to containers | Repackage into ECS/EKS, keep app logic | Medium | Portability, denser bin-packing, faster deploys, gradual decomposition |
| Refactor to serverless | Re-architect into Lambda + managed services | Highest | Spiky/low traffic, “no servers to manage,” pay-per-use, event-driven |
A common exam trap is a distractor proposing a full serverless rewrite when the scenario stresses a tight deadline or a large, tightly-coupled codebase. The correct answer respects the constraint — often replatform now, refactor incrementally later.
Compute Modernization: Containers and Serverless
Once the scenario points to refactor, the next question is the compute target. AWS gives you a spectrum from “manage the orchestration yourself” to “there is no server.”
Replatform to Containers: ECS, EKS, Fargate, and App Runner
Containers are the pragmatic middle ground: you get portability and faster deployments without rewriting application logic. The SAP-C02 tests your ability to choose the right container platform for the constraints:
| Service | What it is | Best fit on the exam |
|---|---|---|
| ECS on Fargate | AWS-native orchestration, no nodes to manage | Default for teams that want containers with minimal ops and no Kubernetes requirement |
| ECS on EC2 | AWS-native orchestration on your instances | Need GPU/specialised instances, per-instance licensing, or maximum cost control at scale |
| EKS on Fargate | Managed Kubernetes, serverless pods | Team already invested in Kubernetes/portability, wants managed data plane |
| EKS on EC2 | Managed Kubernetes on your nodes | Kubernetes ecosystem (operators, service mesh) with node-level control |
| App Runner | Fully managed container web apps from source or image | Simplest path for a stateless web service/API; no load balancer or scaling config to own |
The decision cue: Fargate removes node management — reach for it whenever the scenario stresses reducing operational overhead and there’s no reason to own the instances. Choose EKS over ECS only when the scenario justifies Kubernetes (existing K8s skills, multi-cloud portability, a specific operator/mesh). If a distractor pushes EKS purely to sound sophisticated but the workload is a single stateless web API, App Runner or ECS/Fargate is the better-scoring answer. For the broader compute-selection framework, see the SAP-C02 compute selection guide.
To get a legacy application into a container without hand-writing Dockerfiles, AWS App2Container (A2C) analyses a running Java or .NET application and generates container images, ECS task definitions, or EKS manifests plus a CI/CD pipeline. When a scenario says “containerise an existing .NET/Java app with minimal manual effort,” A2C is the intended tool.
Refactor to Serverless
The far end of the spectrum removes servers entirely. A serverless refactor typically replaces long-running app servers with AWS Lambda functions, fronts them with Amazon API Gateway or an Application Load Balancer, coordinates multi-step logic with AWS Step Functions, and leans on managed data stores like DynamoDB. The wins the exam looks for: no capacity to manage, automatic scaling to zero, and pay-per-invocation economics that suit spiky or low-average traffic.
Serverless is the right answer when the scenario stresses unpredictable or low-volume traffic, event-driven processing, or eliminating idle cost. It is the wrong answer when it stresses steady high throughput (where always-on containers are cheaper), long-running jobs beyond Lambda’s timeout, or large tightly-coupled codebases that can’t be decomposed quickly. The SAP-C02 serverless architecture patterns guide goes deeper on the patterns themselves.
The Strangler Fig Pattern: Decomposing a Monolith Safely
The scenario that trips people up is the large monolith the business wants as microservices without a risky big-bang rewrite. The named answer is the strangler fig pattern — and the exam does use this vocabulary.
The idea, borrowed from a vine that grows around a tree and gradually replaces it, is to put a routing layer in front of the monolith and peel off functionality one capability at a time:
- Insert a facade. Place Amazon API Gateway or an Application Load Balancer in front of the existing application so every request flows through a layer you control.
- Extract one capability. Rebuild a single bounded piece — say, the “notifications” or “checkout” service — as a new Lambda or container behind that facade.
- Reroute incrementally. Point the facade’s route for that capability at the new service. Everything else still hits the monolith. Use weighted routing to shift a small percentage of traffic first, then ramp up as confidence grows.
- Repeat until the monolith is empty. Each iteration moves one more capability out. The monolith shrinks until it can be retired — “strangled” — with no single high-risk cutover.
The architectural benefit the exam rewards: risk is spread across many small, reversible steps instead of concentrated in one migration event. If a new service misbehaves, you reroute that one path back to the monolith. When a scenario asks for incremental decomposition with the ability to roll back per feature, strangler fig — implemented with API Gateway/ALB routing — is the intended answer, not a parallel rewrite-and-switch.
An important companion concept is the anti-corruption layer: a translation shim between the new services and the legacy system so the monolith’s data model doesn’t leak into your clean service boundaries. Expect it to appear as the “how do the new and old systems talk without coupling?” part of a scenario.
Decoupling and Event-Driven Modernization
Modernization is as much about how components communicate as where they run. Synchronous, tightly-coupled calls are the fragility the SAP-C02 wants you to remove. The tools:
- Amazon SQS — queues that decouple producers from consumers and absorb load spikes; the consumer processes at its own pace and failures don’t cascade.
- Amazon SNS — pub/sub fan-out so one event notifies many subscribers; pair with SQS (the “fan-out” pattern) for durable, parallel processing.
- Amazon EventBridge — an event bus with content-based routing and SaaS/AWS-service integrations; the modern default for event-driven choreography between services.
- Amazon Kinesis — ordered, replayable streaming for high-volume real-time data and analytics.
The modernization move the exam tests: converting a synchronous request that blocks on downstream work into an asynchronous, queued or event-driven flow. This improves resilience (a downstream outage no longer fails the caller), elasticity (each component scales independently), and team autonomy (services deploy on their own cadence). When a scenario complains that one slow component is failing the whole request path, decoupling with SQS/EventBridge is the modernization answer.
Database Modernization: Escaping the One-Size-Fits-All Store
The data tier is where lift-and-shift debt accumulates and where the most valuable modernization points hide. The SAP-C02 pushes the purpose-built database philosophy: stop forcing every workload into one relational engine and match each access pattern to the right store.
| From (legacy) | To (modernized) | Driver the scenario will stress |
|---|---|---|
| Self-managed MySQL/PostgreSQL on EC2 | Amazon RDS or Aurora | Offload backups, patching, HA; Aurora for higher throughput and storage auto-scaling |
| Relational store used as a key-value/session cache | Amazon DynamoDB | Single-digit-millisecond latency, serverless scale, unpredictable traffic |
| Relational + a hot read path | Amazon ElastiCache in front | Reduce read load and latency on a busy database |
| Documents shoehorned into relational tables | Amazon DocumentDB | Native JSON/document workloads |
| Highly connected data (graphs, recommendations) | Amazon Neptune | Relationship-heavy queries that are painful in SQL |
| Time-series metrics | Amazon Timestream | High-ingest time-series at scale |
The migration mechanics are worth knowing: AWS Database Migration Service (DMS) moves the data with minimal downtime, and the AWS Schema Conversion Tool (SCT) handles heterogeneous conversions (for example Oracle → Aurora PostgreSQL) by translating schema and code. When a scenario pairs “reduce database licensing cost” with “minimal downtime,” the intended answer is usually DMS + SCT to a managed open-source-compatible engine like Aurora.
For choosing among the relational options and the full purpose-built catalogue, see the SAP-C02 database selection guide; for the analytics side of data modernization — offloading reporting to Redshift, Athena, and a data lake — see the SAP-C02 data & analytics architecture guide.
Exam Scenarios: Reading the Modernization Cue
The domain is scenario-heavy. Practising the cue-to-answer mapping is worth more than memorising service lists:
- “A monolithic Java app on EC2; the business wants independent team deployments and the ability to roll back individual features.” → Strangler fig with API Gateway/ALB routing; extract capabilities into ECS/Fargate services incrementally. Not a big-bang rewrite.
- “A batch job runs a few times a day; the team wants to stop paying for idle EC2 and eliminate server management.” → Refactor to Lambda + Step Functions (or Fargate tasks if beyond Lambda limits). Serverless matches the spiky, low-average profile.
- “Self-managed Oracle is expensive to license and operate; downtime must be minimal.” → DMS + SCT to Aurora PostgreSQL. Managed, licence-cost-reducing, minimal-downtime.
- “One slow downstream service intermittently fails the entire checkout request.” → Decouple with SQS or EventBridge so the slow component processes asynchronously and its failures don’t cascade.
- “Containerise an existing .NET application with the least manual effort.” → AWS App2Container to generate images and deployment artifacts.
Modernization Anti-Patterns on the SAP-C02
The exam plants distractors that sound modern but violate a constraint. Watch for:
- Big-bang rewrites when the scenario demands incremental, low-risk change — strangler fig beats parallel-build-and-switch here.
- Serverless for steady high-throughput or long-running workloads — always-on containers are usually cheaper and simpler; Lambda’s timeout and pay-per-invocation work against you.
- EKS for a simple stateless web app with no Kubernetes justification — App Runner or ECS/Fargate scores higher.
- Forcing every store into one relational database instead of choosing purpose-built engines per access pattern.
- Modernizing compute while leaving a self-managed database on EC2 — the biggest operational-overhead reduction is often in the data tier, and the exam expects you to see it.
Practice With Full-Length Mock Exams
Domain 4 rewards judgement under time pressure — reading a dense scenario, spotting the migration-versus-modernization cue, and choosing the option that respects the constraints rather than the flashiest one. That judgement is built by working through the reasoning on realistic questions, especially the ones where two answers are technically valid and only one fits the stated driver. Sailor.sh’s AWS Certified Solutions Architect – Professional (SAP-C02) Mock Exam Bundle provides full-length mock exams at real exam length and timing, with detailed explanations covering why each distractor fails — which is exactly where the modernization cues in this guide become instinct. Pair it with the SAP-C02 study plan, the migration strategies guide, and a set of SAP-C02 practice questions with answers to rehearse the scenario format.
Frequently Asked Questions
What is the difference between migration and modernization on the SAP-C02?
Migration moves a workload to AWS with acceptable risk and effort — the 7 Rs, MGN, DMS, and cutover planning. Modernization changes the architecture afterward to reduce operational burden, cost, or time-to-market — containers, serverless, decoupling, and managed data services. Domain 4 tests both, and the two overlap at the “Replatform” and “Refactor” R’s.
When should I choose ECS over EKS on the exam?
Choose ECS (usually on Fargate) as the default when the team wants AWS-native container orchestration with minimal operational overhead and has no specific Kubernetes requirement. Choose EKS only when the scenario justifies Kubernetes — existing K8s skills, a required operator or service mesh, or multi-cloud portability. Reaching for EKS on a simple stateless web app is a common distractor; App Runner or ECS/Fargate scores higher there.
What is the strangler fig pattern and when does the exam expect it?
It’s a pattern for decomposing a monolith incrementally: put a routing facade (API Gateway or ALB) in front of the application, rebuild one capability at a time as a new service, reroute traffic to it, and repeat until the monolith is empty. The exam expects it whenever a scenario asks to break up a monolith without a risky big-bang rewrite and wants per-feature rollback.
How do I modernize a database with minimal downtime?
Use AWS Database Migration Service (DMS) to replicate data to the target with minimal downtime, and the AWS Schema Conversion Tool (SCT) for heterogeneous conversions like Oracle to Aurora PostgreSQL. The intended target is usually a managed, purpose-built, or open-source-compatible engine that cuts licensing and operational cost while matching the workload’s access pattern.
Is serverless always the “most modern” and therefore correct answer?
No. Serverless is the best answer for spiky or low-volume traffic, event-driven processing, and eliminating idle cost. For steady high throughput, long-running jobs, or large tightly-coupled codebases, always-on containers are usually cheaper and lower-risk. The SAP-C02 rewards matching the degree of change to the business driver, not defaulting to the newest paradigm.
What is AWS App2Container used for?
App2Container (A2C) analyses a running Java or .NET application and generates container images plus ECS task definitions or EKS manifests and a CI/CD pipeline. On the exam it’s the answer when a scenario asks to containerise an existing application with minimal manual effort.
Conclusion
Domain 4 is where the SAP-C02 separates architects who can move a workload from architects who can improve it. The through-line: read whether the scenario wants migration or modernization, match the degree of change to the business driver, and prefer the most managed option the constraints allow. Reach for Fargate to shed node management, App2Container to lift legacy apps into containers, the strangler fig pattern to decompose monoliths without a big-bang risk, decoupling to remove synchronous fragility, and purpose-built databases plus DMS/SCT to modernize the tier most rewrites neglect. Ground these choices in the wider blueprint with the SAP-C02 migration strategies guide and the AWS Solutions Architect Professional guide for 2026, then pressure-test your judgement against full-length mock exams.