Future TopperFuture Topper
…

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

ElementDetail
Questions65
Scored questions50
Unscored questions15, not identified on the exam
Duration130 minutes
Question typesMultiple choice and multiple response
Scaled score100 to 1,000
Passing score720
Negative markingNone. 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.

DomainWeightingTask statements
Design Secure Architectures30%3
Design Resilient Architectures26%2
Design High-Performing Architectures24%5
Design Cost-Optimized Architectures20%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.

Take a free mock

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

DecisionAsked in Domain 3Asked in Domain 4
Storage classWhich meets the throughput requirementWhich is cheapest for the access pattern
Instance choiceWhich family and size performsSpot, Reserved or Savings Plans
DatabaseWhich engine and type is fastestWhich is cheapest to run and back up
NetworkingWhich topology scalesWhich minimises data transfer charges
Weighting24 per cent20 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.