4.4 - Modernizing workloads (strangler-fig, serverless, blue/green)
AWS Solutions Architect Professional objective 4.4 covers modernizing workloads after or during migration. You avoid a big-bang rewrite with the strangler-fig pattern, peeling features into new microservices behind a routing facade such as API Gateway or an ALB while the monolith serves untouched paths until it is retired. Unpredictable relational traffic modernizes to Aurora Serverless v2 that scales capacity finely and automatically, an ECS v1-to-v2 cutover uses a blue/green deployment with CodeDeploy shifting traffic between target groups with instant rollback, and a read-heavy catalog offloads hot reads to ElastiCache in front of Aurora. A fragile cron ETL becomes an observable Step Functions state machine with per-step retries, a DMS cutover keeps a rollback path with reverse CDC so writes can flow back, and a large SQL Server migration optimizes licensing with AWS License Manager tracking core consumption and BYOL on Dedicated Hosts with host affinity. Expect scenarios about incremental decomposition, auto-scaling databases, or a safe version cutover, and ask which modernization pattern fits.
Decompose a monolith with no big-bang = strangler-fig behind an API Gateway/ALB facade. Auto-scaling relational engine for spiky traffic = Aurora Serverless v2. Version cutover with instant rollback = blue/green with CodeDeploy.
Practice questions
1. After a lift-and-shift, a monolith on a large EC2 instance is idle most of the day but spikes unpredictably. The team wants to modernize toward pay-per-use with minimal servers to manage. Which target fits an event-driven, spiky function?
- A larger EC2 instance with a longer Reserved Instance term
- A fixed-size ECS on EC2 cluster running 24/7
- An on-premises server kept as a fallback
- Refactor the spiky component to AWS Lambda (correct answer)
Lambda runs code only when invoked and scales automatically, so an idle-then-spiky, event-driven component pays per use with no servers to manage. Bigger EC2 or fixed ECS keep paying while idle, and on-premises is the opposite of modernization.
2. A team must containerize legacy .NET and Java applications on EC2 without access to the original source code or build scripts, then deploy to ECS. Which AWS service is purpose-built for this?
- AWS Application Migration Service (MGN) lifting the servers as they are
- AWS App2Container (A2C) (correct answer)
- Manually authoring Dockerfiles and rebuilding each application from source
- AWS Elastic Beanstalk deploying the packaged application artifacts
App2Container inspects a running .NET or Java app, packages it and its dependencies into a container image, and generates ECS/EKS deployment artifacts without needing the source. MGN rehosts whole VMs (no containerization), hand-writing Dockerfiles needs the source, and Beanstalk expects a prepared artifact rather than analyzing a running legacy process.
3. A large monolith must be modernized incrementally: new features become microservices while the monolith keeps serving untouched paths, and traffic is redirected route by route until the monolith is retired. Which pattern describes this approach?
- A big-bang rewrite that simultaneously replaces the whole monolith in a single high-risk cutover event
- A rehost of the monolith to EC2 followed by vertical scaling of the instance
- The strangler-fig pattern fronted by a routing proxy such as API Gateway or an ALB (correct answer)
- A lift-and-shift to containers with all modules kept in one image for now
The strangler-fig pattern places a routing facade (API Gateway or ALB) in front of the monolith and gradually redirects individual routes to new microservices, shrinking the monolith safely until it can be decommissioned. A big-bang rewrite is high risk, rehosting/lift-and-shift do not decompose anything, and keeping all modules in one image is still a monolith.
4. Two new microservices currently share one relational database, creating tight coupling. The architect wants each service to own its data. Which TWO actions decouple the shared database? (Choose TWO.)
- Keep the single shared schema but add more read replicas for both services
- Split the schema so each service owns its own database and tables (correct answer)
- Give both services the same database admin credentials for simplicity
- Have services exchange data through events or APIs instead of cross-service table joins (correct answer)
- Point both services at the very same primary database using row-level locks to serialize every single write
Database-per-service ownership plus asynchronous events or APIs for cross-service data removes the shared coupling and lets each service evolve independently. More replicas, shared admin credentials, or row locks all keep the single shared database and preserve the coupling you are trying to eliminate.
5. A commercial Oracle database must be replatformed to an open-source-compatible managed engine on AWS with minimal downtime. Which combination of tools best fits the conversion and the ongoing migration?
- Schema Conversion Tool (SCT) to Aurora PostgreSQL, then DMS with change data capture (correct answer)
- A single mysqldump export restored into Amazon RDS for MySQL overnight
- AWS Backup copying the existing Oracle database snapshots directly into an Aurora MySQL cluster overnight
- DataSync replicating the raw database files into an Aurora cluster volume
SCT converts the Oracle schema and code objects to Aurora PostgreSQL, and DMS with CDC replicates ongoing changes so cutover downtime is minimal. A one-shot dump forces a long outage and no Oracle-to-open-source conversion, AWS Backup snapshots are engine-specific and cannot cross into Aurora, and DataSync moves files, not live database changes.
6. During modernization, an order service must notify inventory, shipping, and analytics services when an order is placed, without knowing who consumes the event or coupling to them. Which service best implements this fan-out by event pattern?
- A direct synchronous REST call from the order service to each downstream service
- A shared database table that each downstream service polls every few seconds
- An AWS Step Functions state machine invoked once per order to call everyone
- Amazon EventBridge routing order events to multiple targets via rules (correct answer)
EventBridge lets the producer publish an event once while rules deliver it to many decoupled targets, so consumers can be added or removed with no change to the order service. Synchronous REST couples the producer to every consumer, database polling is inefficient and coupled, and Step Functions orchestrates a known workflow rather than open-ended event fan-out.