Designing for the four domains
Domain 3: Designing high-performing architectures
Domain 3 (24%) is about choosing resources that meet performance needs and scale with demand. It has five task statements, one per layer.
3.1 High-performing and scalable storage
| Need | Choose |
|---|---|
| Unlimited, durable object storage, high request rates | S3 (spread prefixes; multipart; byte-range fetches) |
| Lowest-latency object storage in one AZ | S3 Express One Zone |
| Single-instance high IOPS database disk | EBS io2 Block Express |
| General-purpose disk, tunable performance | EBS gp3 |
| High sequential throughput | EBS st1, or instance store |
| Shared Linux files, scales automatically | EFS (Elastic throughput) |
| HPC/ML parallel file system | FSx for Lustre (linked to S3) |
| Windows shares | FSx for Windows File Server |
| Hybrid low-latency access to cloud data | Storage Gateway (cached modes) |
3.2 High-performing and elastic compute
| Need | Choose |
|---|---|
| Right resources per workload | Correct instance family (C compute, R memory, I storage, P/G accelerated); Graviton for price-performance |
| Elastic scaling | EC2 Auto Scaling, ECS/EKS service scaling, Lambda |
| Scale on the right signal | CPU, request count per target, queue backlog, custom business metrics |
| Decouple to scale components independently | SQS, SNS, EventBridge, Kinesis |
| Batch at scale | AWS Batch; big data → EMR |
| No servers | Fargate, Lambda (tune memory for CPU) |
| Low inter-node latency | Cluster placement groups, EFA |
| Edge/distributed processing | CloudFront Functions, Lambda@Edge, Local Zones, Wavelength, Outposts |
3.3 High-performing databases
| Need | Choose |
|---|---|
| Read-heavy relational | Read replicas, Aurora replicas + reader endpoint |
| Repeated reads, low latency | ElastiCache; DAX for DynamoDB |
| Write-heavy, massive scale, key-value | DynamoDB (good partition keys) |
| Many short-lived connections | RDS Proxy |
| High IOPS relational storage | Provisioned IOPS (io1/io2), Aurora |
| Global low-latency reads | Aurora Global Database, DynamoDB global tables |
| Variable load | Aurora Serverless v2, DynamoDB on-demand |
| Analytics without hurting OLTP | Read replica, zero-ETL to Redshift, export to S3 + Athena |
3.4 High-performing and scalable networks
| Need | Choose |
|---|---|
| Global content delivery | CloudFront |
| Global TCP/UDP acceleration, static IPs, fast failover | Global Accelerator |
| Route users to the nearest Region | Route 53 latency routing |
| L7 routing vs extreme L4 performance | ALB vs NLB |
| Many VPCs and hybrid connectivity at scale | Transit Gateway, Direct Connect |
| Private service access | VPC endpoints, PrivateLink |
| Room to grow | Plan non-overlapping, generously sized CIDRs; add secondary CIDRs |
| Place resources well | Same Region/AZ as data; Local Zones for metro latency |
3.5 High-performing data ingestion and transformation
| Need | Choose |
|---|---|
| Real-time streams, multiple consumers, replay | Kinesis Data Streams (or MSK) |
| Load streams into S3/Redshift/OpenSearch simply | Data Firehose |
| Real-time stream analytics | Managed Service for Apache Flink |
| Batch file transfer from on-premises | DataSync; Storage Gateway; Snow Family for huge offline |
| Transform/catalog (CSV → Parquet) | Glue |
| Query the lake | Athena; warehouse → Redshift; big data → EMR |
| Govern access to the lake | Lake Formation |
| Visualise | QuickSight |
Key idea
Performance questions reward matching the tool to the access pattern: caching for repeated reads, queues for bursts, the right instance family for the bottleneck, edge services for distance, columnar formats for analytics.
Exam patterns
- "Global users complain about slow page loads of static assets" → CloudFront.
- "Database CPU is high from read queries" → read replicas or ElastiCache.
- "Lambda function is slow and CPU-bound" → increase memory.
- "Analytics queries on S3 scan too much data and are slow" → Parquet + partitioning (Glue), then Athena.
Written by Bipin Singh
Work with meSenior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.