AWS Exam Review

Design High-Performing Architectures

Review SAA-C03 Domain 3 by connecting storage, compute, databases, networking, data ingestion, caching, scaling, edge services, and performance traps.

intermediate5 min readUpdated 2026-06-04CloudCertificationCapacityDataNetworkingTradeoffs
PerformanceScalabilityStorage PerformanceCompute ElasticityDatabase PerformanceNetwork PerformanceData IngestionCaching

After this, you will understand

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

Plain version

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 readingWhat 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.

Reading in progress

This page is saved in your local study history so you can continue later.

Next: High-Performing Architecture Trap Drills

Study path

Read these in order

Start with the mechanics, then move into the patterns that explain why the system is shaped this way.

  1. 1Design Cost-Optimized ArchitecturesAWS Review
  2. 2Athena vs Redshift vs OpenSearchaws-services

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:

  1. S3 vs EBS vs EFS vs Instance Store
  2. Lambda vs ECS/Fargate vs EC2
  3. Amazon EC2 Auto Scaling
  4. DynamoDB vs RDS vs Aurora
  5. ElastiCache vs DynamoDB DAX
  6. CloudFront vs Global Accelerator
  7. Transit Gateway vs VPC Peering vs PrivateLink
  8. Kinesis vs SQS vs EventBridge
  9. Athena vs Redshift vs OpenSearch
  10. Analytics Data Lake On S3

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:

What to study next

These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.