AWS SAA-C03 design high-performing architectures syllabus
Design High-Performing Architectures is the widest domain on the exam. Five task statements cover storage, compute, databases, networking and data ingestion, and between them they carry 24 per cent of the scored content.
That makes it the thinnest domain per task. Each of the five areas carries less weight than the single tasks in Domain 2, so breadth matters here more than depth. The AWS SAA-C03 syllabus hub page covers the other three domains.
Pattern
| Element | Detail |
|---|---|
| Questions | 65 |
| Scored questions | 50 |
| Unscored questions | 15, not identified on the exam |
| Duration | 130 minutes |
| Question types | Multiple choice and multiple response |
| Scaled score | 100 to 1,000 |
| Passing score | 720 |
| Negative marking | None. An unanswered question is scored as incorrect |
This domain carries 24 per cent of the scored content. The current weightings are below, and they replace the 26, 24, 24 and 26 split that most study material still quotes.
| Domain | Weighting | Task statements |
|---|---|---|
| Design Secure Architectures | 30% | 3 |
| Design Resilient Architectures | 26% | 2 |
| Design High-Performing Architectures | 24% | 5 |
| Design Cost-Optimized Architectures | 20% | 4 |
Even if $9 invested today doubled in five years...
$9 spent on mocks today could change what you’re earning in five years.
AWS Solutions Architect Pro · one year of access.
Task statements
Task 3.1: Determine high-performing and scalable storage solutions
- Storage services and their use cases: Amazon S3, Amazon EFS and Amazon EBS
- Storage types and characteristics: object, file and block
- Hybrid storage solutions
- Matching storage configuration to performance demands, and to future scale
Task 3.2: Design high-performing and elastic compute solutions
- Compute services and their use cases: AWS Batch, Amazon EMR and AWS Fargate
- Scalability through Amazon EC2 Auto Scaling and AWS Auto Scaling
- Serverless patterns with AWS Lambda and AWS Fargate
- Container orchestration with Amazon ECS and Amazon EKS
- Decoupling workloads so components scale independently
- Metrics and conditions that trigger scaling actions
- Selecting instance types, and sizing resources such as Lambda memory
- Distributed computing across the global infrastructure and edge services
Task 3.3: Determine high-performing database solutions
- Database types and services: relational against non-relational, serverless, and in-memory
- Engine selection and the difference between homogeneous and heterogeneous migration
- Amazon Aurora, Amazon DynamoDB and Amazon RDS
- Caching with Amazon ElastiCache
- Read replicas, database connections and proxies
- Capacity planning with capacity units, instance types and Provisioned IOPS
- Read-intensive against write-intensive access patterns
Task 3.4: Determine high-performing and scalable network architectures
- Edge networking with Amazon CloudFront and AWS Global Accelerator
- Network architecture design: subnet tiers, routing and IP addressing
- Load balancing strategy selection
- Connection options: AWS VPN, AWS Direct Connect and AWS PrivateLink
- Network topologies for global, hybrid and multi-tier architectures
- Placement of resources, and configurations that scale
Task 3.5: Determine high-performing data ingestion and transformation solutions
- Data analytics and visualisation services, including Amazon Athena and AWS Lake Formation
- Data ingestion patterns and frequency
- Data transfer with AWS DataSync and AWS Storage Gateway
- Data transformation with AWS Glue
- Streaming data with Amazon Kinesis
- Building and securing data lakes, and designing streaming architectures
- Compute options for data processing such as Amazon EMR
- Transforming data between formats, for example CSV to Parquet
Services most used in this domain
- Amazon S3, Amazon EFS, Amazon EBS and Amazon FSx
- Amazon EC2, AWS Lambda, AWS Fargate, AWS Batch and Amazon EMR
- Amazon EC2 Auto Scaling and AWS Auto Scaling
- Amazon Aurora, Amazon DynamoDB, Amazon RDS and Amazon ElastiCache
- Amazon CloudFront, AWS Global Accelerator, Elastic Load Balancing and AWS PrivateLink
- Amazon Kinesis, AWS Glue, Amazon Athena, AWS Lake Formation and AWS DataSync
What is not in this domain
- No cost comparison between the options, which belongs to Domain 4
- No encryption or access control design, which belongs to Domain 1
- No machine learning model development. The machine learning services appear only as managed options
- No out-of-scope analytics services such as Amazon Managed Workflows for Apache Airflow
How to spend the time
Cover breadth rather than depth. Five task statements share 24 per cent, so no single area here repays the kind of attention that Domain 1 or Domain 2 does, and a gap in any of the five costs you questions.
Storage class selection is the most frequently examined single decision. Know what Amazon S3, Amazon EFS and Amazon EBS are each for, and the object, file and block distinction that drives the choice.
For databases, learn the decision tree rather than the feature lists. Relational or not, then managed or serverless, then whether caching or a read replica solves the stated bottleneck.
Task 3.5 is the one candidates skip, because data ingestion feels like a data engineering topic. Amazon Kinesis, AWS Glue, Amazon Athena and AWS DataSync are all named and all appear. Browse the available AWS Solutions Architect practice papers.
Common mistakes
- Studying three of the five task statements and leaving networking and data ingestion thin
- Choosing Amazon EFS where the scenario describes block storage for a single instance, which is Amazon EBS
- Reaching for a read replica when the bottleneck is repeated identical reads, which is a caching problem
- Confusing Amazon CloudFront, which caches content at the edge, with AWS Global Accelerator, which routes traffic over the AWS network
- Answering a performance question on cost grounds
- Treating Provisioned IOPS as a default rather than as a response to a stated performance requirement
Performance against cost on the same decisions
| Decision | Asked in Domain 3 | Asked in Domain 4 |
|---|---|---|
| Storage class | Which meets the throughput requirement | Which is cheapest for the access pattern |
| Instance choice | Which family and size performs | Spot, Reserved or Savings Plans |
| Database | Which engine and type is fastest | Which is cheapest to run and back up |
| Networking | Which topology scales | Which minimises data transfer charges |
| Weighting | 24 per cent | 20 per cent |
Frequently asked questions
How much of the exam is Design High-Performing Architectures?
24 per cent of the scored content, across five task statements.
Why does it have the most task statements but not the most marks?
The weighting is set per domain rather than per task, so five tasks share 24 per cent while Domain 2 has two tasks sharing 26 per cent.
What is the difference between Amazon EBS and Amazon EFS?
Amazon EBS is block storage attached to an instance. Amazon EFS is a shared file system. The object, file and block distinction is named in the syllabus.
When is caching the answer rather than a read replica?
When the bottleneck is repeated identical reads. A read replica scales read capacity, while Amazon ElastiCache removes the read entirely.
Is data ingestion really in scope?
Yes. Task 3.5 names Amazon Kinesis, AWS Glue, Amazon Athena, AWS Lake Formation, AWS DataSync and AWS Storage Gateway.
What is the difference between Amazon CloudFront and AWS Global Accelerator?
CloudFront caches content at edge locations. Global Accelerator routes traffic over the AWS backbone to the nearest healthy endpoint. Both are named as edge services.
Are machine learning services examined?
Only as managed options within an architecture. Model development is not in scope.
Is cost part of this domain?
No. The same decisions are asked on cost grounds in Domain 4.
How deep does capacity planning go?
The syllabus names capacity units, instance types and Provisioned IOPS, which is the level the questions sit at.
Which task statement is most often skipped?
Task 3.5 on data ingestion and transformation, because it reads as a data engineering topic rather than an architecture one.