Review

Design High-Performing Architectures

A focused review of AWS Solutions Architect Associate exam (SAA-C03) Domain 3 by connecting storage, compute, databases, networking, data ingestion, caching, scaling, edge services, and performance traps.

5 min readUpdated June 2026

After this, you will understand

Performance questions become clear when learners classify the bottleneck instead of choosing the fastest-sounding AWS service.

Article guideprerequisites, mental models, and concepts

intermediateCloudCertificationCapacity

Three useful mental models

In plain terms

This domain asks whether you can choose storage, compute, database, network, and ingestion designs that meet performance and scaling requirements.

Decision pressure

Learners scale the wrong layer, use a warehouse for search, use a queue for every performance issue, or choose bigger instances instead of matching the access pattern.

Exam-ready model

Find the bottleneck first: storage API, compute capacity, database access pattern, network path, ingestion rate, or cacheable read pattern.

Think before reading

What is the first question to ask in a high-performance AWS architecture scenario?

Ask which layer is actually constrained: storage, compute, database, network, data ingestion, or repeated reads that could be cached.

Connected learning

These lessons add useful context to the current core lesson.

Concepts Covered

SAA-C03 high-performing architecture domain
Scalable storage
Elastic compute
Database performance
Network performance
Data ingestion
Data transformation
Caching
Edge acceleration
Service fit traps

1. Domain Mental Model

High performance is not "make everything bigger."

The core question is:

which component is under pressure, and which AWS design matches that pressure?

A storage problem may be object, block, file, or ephemeral local disk. A compute problem may be bursty event-driven work, containerized services, or instance-level control. A database problem may be read scaling, write scaling, connection pressure, caching, or wrong data model. A network problem may be edge proximity, static IP entry, private connectivity, routing topology, or hybrid bandwidth. A data problem may be ingestion frequency, file format, streaming, cataloging, or transformation.

The exam rewards access-pattern thinking.

2. Official Task Map

AWS groups this domain into five task areas:

storage solutions that are high-performing or scalable
high-performing and elastic compute
high-performing database solutions
scalable network architectures
data ingestion and transformation

The official weighting is 24 percent of scored content.

Arcflow maps that to:

storage semantics and throughput
compute elasticity and fit
database type, capacity, and caching
edge, load balancing, and network topology
analytics ingestion and transformation pipelines

Performance is about matching the shape of demand.

3. What AWS Is Testing

AWS is testing whether you can select purpose-built services and configurations.

For storage, expect S3, EBS, EFS, FSx, instance store, Storage Gateway, DataSync, and file formats for analytics.

For compute, expect EC2 instance families, Auto Scaling, Lambda memory and concurrency, ECS, Fargate, containers, queues, and decoupling.

For databases, expect RDS, Aurora, DynamoDB, ElastiCache, DAX, read replicas, provisioned IOPS, serverless database patterns, and connection proxies.

For networks, expect CloudFront, Global Accelerator, ALB, NLB, VPN, Direct Connect, PrivateLink, Transit Gateway, subnet placement, and hybrid topology.

For ingestion, expect Kinesis, SQS, EventBridge, Glue, Athena, Redshift, OpenSearch, DataSync, Storage Gateway, and data lake design.

4. Service And Concept Clusters

Start with storage:

Then compute:

Then databases and caching:

Then network and ingestion:

5. Architecture Reasoning Patterns

Classify the access pattern before choosing a service.

For storage:

objects -> S3
block device -> EBS
shared NFS files -> EFS
Windows or high-performance file systems -> FSx
temporary local scratch -> instance store

For compute, ask whether the workload is request-driven, event-driven, containerized, batch-oriented, always-on, latency-sensitive, or needs host control.

For databases, ask whether the access pattern is relational, key-value, document-style, analytical warehouse, full-text search, or in-memory cache.

For network performance, ask whether the goal is caching content, accelerating dynamic traffic, providing static global IPs, private service exposure, hybrid bandwidth, or hub-and-spoke routing.

For data ingestion, ask whether the flow is batch file transfer, stream processing, event routing, queue buffering, ETL transformation, or ad hoc SQL over S3.

6. High-Yield Comparisons

S3 vs EBS vs EFS vs instance store: object, block, shared file, or temporary local disk.

Lambda vs ECS/Fargate vs EC2: managed event compute, managed containers, or instance-level control.

DynamoDB vs RDS vs Aurora: key-value scale, relational managed database, or cloud-optimized relational engine.

ElastiCache vs DAX: general-purpose in-memory caching versus DynamoDB-specific cache.

CloudFront vs Global Accelerator: cache and web edge controls versus static IPs and accelerated routing.

Kinesis vs SQS vs EventBridge: streaming data, work queue, or event bus.

Athena vs Redshift vs OpenSearch: serverless SQL over S3, warehouse BI analytics, or indexed search and logs.

Direct Connect vs VPN: dedicated private connectivity versus encrypted internet-based connectivity.

7. Scenario Triggers

"Ad hoc SQL over S3 logs" points to Athena.

"Full-text search or log exploration" points to OpenSearch.

"Business intelligence warehouse" points to Redshift.

"Low-latency repeated database reads" points to ElastiCache or DAX depending on database.

"High read traffic on relational database" points to read replicas or caching.

"High write scale with predictable key-value access" often points to DynamoDB.

"Static assets for global users" points to CloudFront.

"Static global IP addresses" points to Global Accelerator.

"Shared file storage for multiple Linux EC2 instances" points to EFS.

"Database volume on EC2" points to EBS.

8. Common Traps

Do not choose the service with the biggest-sounding scale if the access pattern does not fit.

Do not use S3 as a low-latency block device.

Do not use EBS as the general answer for shared files across many instances.

Do not use Redshift for occasional S3 log queries when Athena fits.

Do not use Athena for low-latency application search.

Do not assume read replicas solve write bottlenecks.

Do not add cache without understanding invalidation and stale data.

Do not choose Global Accelerator for object caching.

Do not ignore file format and partitioning in analytics performance.

9. Study Path

Study in this order:

Then practice turning scenario wording into bottleneck type.

Review Design Resilient Architectures, Design Cost-Optimized Architectures, Serverless API With Lambda And DynamoDB, and Analytics Data Lake On S3.

Official AWS references:

Finished reading?

Your reading history is saved in this browser so you can continue later.

Recommended Next

High-Performing Architecture Trap DrillsAWS Exam Review5 min read

This reviews the architecture judgment built through foundations and scenarios.

Optional exploration

These links add context, but they do not replace the recommended next lesson.