AWS Certified Solutions Architect - Associate (SAA-C03) · High-Performing Networking and Data Pipelines
~11 min
Domain 3's five task statements all ask the same underlying question in different clothes: given a workload's numbers — IOPS, latency, RAM, requests per second, records per second — which AWS service removes the bottleneck those numbers describe? Storage answers with volume type or file system; compute answers with instance family or serverless option; databases answer with engine and capacity mode; networking answers with edge service and connection type; ingestion answers with streaming or batch service. The skill this domain tests isn't memorizing every service — it's reading a scenario's specific numbers and constraints and matching them to the one service built for that shape of problem.
Real architectures rarely solve a performance requirement with a single service. A product page that needs to survive a launch-day spike might combine a memory-optimized ElastiCache layer in front of Aurora, an Auto Scaling group of compute-optimized instances behind an Application Load Balancer, and CloudFront caching the static assets — four services from three different task statements, each solving one piece of the same requirement.
Work a composite scenario the way the exam will: a photo-sharing app needs to (1) store and serve millions of images cheaply and durably, (2) resize images on upload without running servers around the clock, (3) look up a user's photo feed by user ID at unpredictable, spiky scale, and (4) serve images to a global audience with low latency. Four requirements, four services, each chosen by naming the bottleneck: image storage is discrete objects with no need for a file system, so that's Amazon S3. Resizing on upload is short, event-driven, bursty work with no idle cost wanted, so that's AWS Lambda triggered by an S3 event. Looking up a feed by user ID at unpredictable scale is a key-based access pattern, so that's DynamoDB in on-demand mode. Serving images globally with low latency is cacheable HTTP content, so that's CloudFront in front of the S3 bucket.
Notice what's absent: no EC2 instance, no relational database, no Kinesis stream. The framework doesn't reach for a service because it's familiar — it reaches for the one service whose defining strength matches the requirement actually stated.
The dominant trait the requirement names — here, "cheapest" and "rarely-accessed" point toward a low-cost, infrequent-access storage tier rather than a performance-optimized one; naming that trait first narrows the choice before comparing specific services.