Architecture modernization is the heart of SAP-C02 Domain D4. It tests your ability to transform monolithic applications into serverless, container-based, and event-driven architectures, and to select purpose-built databases for each workload.
The starting point for modernization is not "What needs to change?" but "Which constraints of the current architecture are blocking business goals?" You must first identify whether scalability, operational burden, cost, or development velocity needs to be addressed before selecting the right modernization path.
Serverless — Lambda and API Gateway
Lambda executes code without server management. There are no charges when requests are not being processed, and it scales horizontally and automatically. However, the maximum execution time limit of 15 minutes means long-running tasks of 25 minutes or more require ECS Fargate or EC2.
Lambda concurrency management is important in the exam. Reserved Concurrency sets a maximum concurrency cap per function to prevent any single function from monopolizing the regional concurrency pool. This is an isolation-purpose setting that protects other functions. Provisioned Concurrency pre-initializes instances to eliminate cold starts — this is a performance-purpose setting. Choose Reserved for isolation and Provisioned for cold start elimination.
The standard fully serverless web architecture pattern is CloudFront + S3 (static hosting) + API Gateway + Lambda + DynamoDB. The moment EC2 or Fargate is included, it is no longer fully serverless.
API Gateway supports both REST APIs and WebSocket APIs. The WebSocket API automatically generates a connectionId and handles hundreds of thousands of concurrent connections. When server-to-client active push is needed, the API sends messages immediately to a specific connectionId. A DynamoDB table stores user-to-connectionId mappings for push targeting.
Containers — ECS vs EKS, Fargate vs EC2 Launch Type
ECS (Elastic Container Service) is the AWS-native container orchestrator. It is operationally simpler and deeply integrated with AWS services. EKS (Elastic Kubernetes Service) provides Kubernetes as a fully managed service. Choose EKS when you need advanced Kubernetes ecosystem features or are migrating existing Kubernetes workloads.
The Fargate launch type runs containers without managing cluster infrastructure. No EC2 instances need to be provisioned or patched. Pricing is based on vCPU and memory usage time, which often results in cost savings over underutilized EC2 instances. Even the Fargate launch type is not fully serverless (a container layer still exists). Only Lambda is fully serverless.
The selection criterion between Lambda and Fargate is execution time. Lambda has a 15-minute cap and is optimal for intermittent, event-driven processing. Fargate has no time limit and is used for always-on services and long-running tasks.
!ECS versus EKS
Purpose-Built Databases — DynamoDB, Aurora Serverless, ElastiCache
A core principle of modernization is choosing the right database for each workload. Trying to solve everything with a single relational database creates bottlenecks.
DynamoDB is a fully serverless NoSQL database with single-digit millisecond responses, automatic scaling, and full management. On-demand mode automatically handles traffic without provisioning capacity in advance. It suits unstructured data, bursty traffic, IoT device data, session stores, and real-time event processing.
The DynamoDB Streams + Lambda + SNS pattern is the standard for real-time event processing. DynamoDB Streams captures item-level changes (INSERT/MODIFY/REMOVE) for up to 24 hours. Lambda automatically polls Streams via event source mapping and sends SNS notifications when changes arrive.
Aurora Serverless v2 is a relational database optimized for variable workloads, automatically adjusting capacity based on traffic. For fixed, always-on workloads, Reserved Instances are more cost-effective.
ElastiCache caches repeated query results in memory to reduce load on RDS or Aurora. Redis supports complex data structures, persistence, and cluster mode. Memcached is optimized for simple key-value caching. DAX is DynamoDB-specific and cannot be applied to Aurora.
Decoupling — SQS, SNS, EventBridge
Loose Coupling is a core principle of modern architecture. SQS, SNS, and EventBridge each provide different decoupling patterns.
SQS Standard queues offer maximum throughput but do not guarantee message order and deliver at least once. SQS FIFO queues guarantee order using message group IDs and provide exactly-once processing, but are capped at 300 TPS (3,000 TPS in batch mode).
Dead Letter Queues (DLQ) isolate messages that repeatedly fail processing in a separate queue. Without a DLQ, failing messages continuously retry and can block the entire pipeline.
SNS is used for immediate parallel fan-out patterns — delivering a single message simultaneously to multiple subscribers (SQS, Lambda, HTTP, Email). To resolve API rate-limiting problems, use SQS instead of SNS. SNS delivers immediately in parallel, which worsens rate-limiting.
EventBridge defines rules based on events from AWS services and SaaS applications to trigger targets such as Lambda, SQS, and Step Functions. Its event bus model completely decouples event producers from consumers.
Step Functions — Serverless Workflow Orchestration
Implementing complex multi-step workflows as Lambda function chains makes error handling and state management difficult. Step Functions visually defines workflows and automates execution, retries, and error handling for each step.
Standard Workflow is used for long-running workflows (up to 1 year) that require audit trails. It guarantees exactly-once execution and preserves execution history for 90 days. Express Workflow is used for high-throughput workflows under 5 minutes. Event-based pricing makes it cost-effective for high-frequency invocations.
When Lambda's 15-minute execution limit is a problem, use Step Functions + ECS Fargate Tasks. The Map state orchestrates parallel processing, and Retry/Catch implements built-in error retries and exception handling.
Strangler Fig Pattern and Monolith Decomposition
Migrating a monolithic application to microservices all at once is risky. The Strangler Fig pattern implements new features as microservices while gradually replacing the monolith.
The standard pattern for monolith decoupling is S3 static hosting (frontend) + API Gateway (REST API) + SQS + Lambda (async processing). The SQS queue decouples the producer (API) from the consumer (Lambda), ensuring message durability during traffic spikes. Fault isolation is also achieved — order processing delays do not impact frontend or API response times.
Exam Key Points
"Fully serverless web architecture" -- CloudFront + S3 + API Gateway + Lambda + DynamoDB (excluded if EC2/Fargate present)
"Isolate Lambda functions, prevent regional pool monopolization" -- Reserved Concurrency
"Eliminate Lambda cold starts" -- Provisioned Concurrency
"Long-running tasks exceeding Lambda's 15-minute limit" -- ECS Fargate
"Real-time server-to-client active push" -- API Gateway WebSocket API + @connections API
"Unstructured data, bursty traffic, session store" -- DynamoDB On-demand
"Real-time events on DynamoDB item changes" -- DynamoDB Streams + Lambda
"DAX is DynamoDB-specific" -- cannot be applied to Aurora/RDS (use ElastiCache for Aurora)
"Guaranteed message order, exactly-once processing" -- SQS FIFO (Standard does not guarantee order)
"Resolve API rate-limiting, write buffering" -- SQS (SNS worsens rate-limiting)
"Multi-step workflow, long-running, audit trail" -- Step Functions Standard Workflow
"High-throughput workflow under 5 minutes" -- Step Functions Express Workflow
"Gradual monolith decomposition" -- Strangler Fig pattern