SAA-C03 · LESSON 3
Design High-Performing Architectures24% · 5 topics
Learn to design high-performing, scalable storage, compute, databases, networks, and data ingestion and transformation.
3.1Determine high-performing and scalable storage
3.1 Determine high-performing and/or scalable storage solutions.
Concept
EBS volume types are General Purpose SSD (gp3: IOPS and throughput can be set separately from size), Provisioned IOPS SSD (io2: high IOPS and durability), Throughput Optimized HDD (st1: large sequential reads and writes) and Cold HDD (sc1). For shared files use EFS (Linux) or FSx (Windows, Lustre for HPC). S3 offers high request performance per prefix and can be sped up with multipart upload and Transfer Acceleration.
How it works / steps
- Check the access pattern (random or sequential, IOPS or throughput)
- Choose gp3 for general use and io2 for high-IOPS databases
- Use EFS for sharing across multiple instances and FSx for Lustre for HPC
- Use multipart for large uploads to S3 and Transfer Acceleration from distant locations
- Instance store is fast but use it only for temporary data
Workplace example
Use st1 for heavy sequential log writes, io2 for a transactional DB, and FSx for Lustre linked to S3 for fast sharing of ML training data.
Common confusions and exam tips
- gp2 IOPS scale with size; gp3 can be set independently
- Instance store data is lost on stop or termination
- EFS can be mounted from multiple AZs at once; EBS is basically in one AZ
Mini quiz
Q1. A gp2 EBS volume has enough capacity but not enough IOPS. Which is the most appropriate way to increase performance while keeping costs down?
- Change the volume to gp3 and set the required IOPS separately from capacity
- Keep using gp2 with more capacity than needed just to get IOPS
- Change the volume to sc1 to lower cost
- Stop using EBS and put all data on instance store
Show answer and explanation
Answer: A Change the volume to gp3 and set the required IOPS separately from capacity
With gp2, IOPS is proportional to size. gp3 lets you set IOPS and throughput separately from size and often costs less. Elastic Volumes lets you change it while running.
Q2. An app on EC2 is slow. CloudWatch shows CPU utilization is low, but EBS volume reads and writes are pinned at the limit. What should you do next?
- Increase the Auto Scaling maximum
- Delete the CloudWatch alarms
- Review the EBS volume type and IOPS/throughput settings and change them as needed
- Change to a larger instance type to add CPU and see what happens
Show answer and explanation
Answer: C Review the EBS volume type and IOPS/throughput settings and change them as needed
The bottleneck is storage I/O, so adding CPU will not help. Review volume performance (gp3 IOPS settings or a change to io2) and the instance's EBS bandwidth.
Reference links
3.2Design high-performing and elastic compute solutions
3.2 Design high-performing and elastic compute solutions.
Concept
For performance, choose an instance family that fits the workload (C: compute, R: memory, I: storage, G/P: GPU, Graviton for high price-performance) and scale elastically with Auto Scaling. Scaling policies include target tracking (keep CPU at 50% and so on), step, scheduled and predictive scaling. Use a cluster placement group for low-latency HPC.
How it works / steps
- Check the bottleneck (CPU, memory, I/O, network) in CloudWatch
- Choose a suitable instance family (also refer to Compute Optimizer recommendations)
- Use target tracking scaling as the base and add schedules for predictable peaks
- Use a warm pool if launching takes a long time
- Consider Lambda for short event-driven processing and Fargate for containers
Workplace example
For an internal system with an access spike at 9:00 every morning, add instances on a schedule at 8:45, and keep CPU at 60% with target tracking during the day.
Common confusions and exam tips
- Cluster placement groups give low latency within one AZ; spread placement groups isolate failures
- Watch Lambda concurrency limits and cold starts (mitigated with provisioned concurrency)
- Vertical scaling (larger instances) often requires a stop
Mini quiz
Q1. To speed up batch processing, you want to split it into many small jobs and run them in parallel. Which approach keeps infrastructure management to a minimum?
- Keep an EMR cluster always running and submit jobs
- Run jobs in parallel with AWS Batch or a Step Functions distributed map
- Create an EC2 Auto Scaling group and distribute jobs with scripts
- Write all jobs as parallel threads inside one Lambda function
Show answer and explanation
Answer: B Run jobs in parallel with AWS Batch or a Step Functions distributed map
Managed batch execution and distributed processing services provision compute automatically according to the degree of parallelism. [Other options] Auto Scaling plus scripts is heavy to manage. An always-on EMR adds management and cost. One function hits time and memory limits.
Q2. A Lambda function takes a long time to run and has spare memory. Which is the most appropriate way to make it faster?
- Recreate the function in another Region
- Shorten the timeout to cut processing early and leave the rest for next time
- Limit concurrency to 1
- Increase the function's memory (CPU increases proportionally)
Show answer and explanation
Answer: D Increase the function's memory (CPU increases proportionally)
Lambda allocates CPU in proportion to the memory setting. CPU-bound processing gets faster with more memory, and shorter duration can even lower cost.
Reference links
3.3Determine high-performing database solutions
3.3 Determine high-performing database solutions.
Concept
Scale reads with RDS and Aurora read replicas (up to 15 for Aurora), cache frequent reads with ElastiCache (Redis, Memcached), and get microsecond DynamoDB reads with DAX. Use RDS Proxy for connection surges and Aurora Serverless v2 for unpredictable load; for large-scale key-value workloads, DynamoDB partition key design determines performance.
How it works / steps
- Check the read/write ratio and latency requirements
- For read-heavy workloads, use read replicas or a cache
- Pool large numbers of connections from Lambda with RDS Proxy
- For DynamoDB, choose a partition key that avoids skewed access and add DAX if needed
- For low-latency global reads, use Aurora Global Database or DynamoDB global tables
Workplace example
Reads of product detail pages account for 90% of DB load, so cache the results in ElastiCache and write inventory updates to the primary.
Common confusions and exam tips
- Read replicas are asynchronous, so there is a slight lag
- DAX is a cache dedicated to DynamoDB (separate from ElastiCache)
- RDS Proxy manages connections; it does not make queries themselves faster
Mini quiz
Q1. Read load on RDS for PostgreSQL is high and responses are slow. Writes are few. Which is the most appropriate way to improve performance with minimal app changes?
- Add read replicas and direct read-only queries to them
- Stop the DB instance once and reduce its allocated storage
- Send read queries to the Multi-AZ standby
- Shorten the database backup retention period
Show answer and explanation
Answer: A Add read replicas and direct read-only queries to them
Read replicas spread reads. The standby in a Multi-AZ instance deployment cannot serve reads.
Q2. A relational DB has a large gap between quiet periods and sudden peaks, and you want to automate capacity adjustment. Which is most appropriate?
- Use Aurora replica Auto Scaling to change the replica count
- Use Aurora Serverless v2 to scale capacity automatically with load
- Enable RDS storage autoscaling
- Add RDS Proxy to pool connections and reduce load
Show answer and explanation
Answer: B Use Aurora Serverless v2 to scale capacity automatically with load
Aurora Serverless v2 adjusts capacity (ACUs) automatically and in fine increments according to load. [Other options] Replica scaling helps reads only, not write capacity. Storage autoscaling does not adjust compute. RDS Proxy manages connections and does not change capacity.
Reference links
3.4Determine high-performing and scalable network architectures
3.4 Determine high-performing and/or scalable network architectures.
Concept
CloudFront speeds up delivery of static and dynamic content with edge caching, while Global Accelerator speeds up TCP/UDP traffic with fixed anycast IPs and the AWS network. Connect many VPCs with Transit Gateway (a hub), a few with VPC peering, and use Direct Connect for high-volume, stable connections to on-premises. For load balancers, use ALB for HTTP and NLB for ultra-low latency, fixed IPs and TCP/UDP.
How it works / steps
- Check where users are and the type of traffic (HTTP, TCP, UDP)
- Cache web content with CloudFront
- Use Global Accelerator for global apps that are non-HTTP or need fixed IPs
- Consolidate connections among many VPCs and on-premises on Transit Gateway
- Choose a load balancer from ALB and NLB
Workplace example
Use Global Accelerator for game servers that players worldwide connect to over UDP, and connect 100 VPCs with Transit Gateway.
Common confusions and exam tips
- VPC peering does not route transitively (A-B and B-C do not mean A-C)
- CloudFront caches; Global Accelerator does not
- Path-based routing is ALB; fixed IPs are NLB
Mini quiz
Q1. Requests to one S3 prefix are extremely numerous and approaching the performance limit. Which design improvement is most appropriate?
- Move the bucket to S3 Express One Zone and keep the same prefix
- Put CloudFront in front and cache write requests too
- Enable S3 Transfer Acceleration
- Spread object keys across multiple prefixes and send requests in parallel
Show answer and explanation
Answer: D Spread object keys across multiple prefixes and send requests in parallel
S3 can handle high request rates per prefix. Splitting prefixes and parallelizing raises overall throughput. [Other options] Transfer Acceleration speeds long-distance transfers and does not change prefix limits. Express One Zone uses directory buckets and needs redesign. CloudFront does not cache writes.
Q2. You want to transfer large amounts of data daily between the head office and the Tokyo Region with stable bandwidth, unaffected by internet congestion. Which is most appropriate?
- S3 Transfer Acceleration
- Amazon CloudFront
- AWS Direct Connect
- AWS Site-to-Site VPN (over the internet)
Show answer and explanation
Answer: C AWS Direct Connect
Direct Connect is a dedicated line with more stable bandwidth and latency than the internet. VPN goes over the internet and fluctuates more.
Reference links
3.5Determine high-performing data ingestion and transformation solutions
3.5 Determine high-performing data ingestion and transformation solutions.
Concept
For streaming ingestion use Kinesis Data Streams (real-time custom processing, scaled by shards) or Amazon Data Firehose (near-real-time delivery to S3, Redshift or OpenSearch with transformation and no operations), or Amazon MSK for Kafka. For batch transformation use AWS Glue (serverless ETL and Data Catalog), EMR for large-scale processing, Athena to analyze S3 data, and Lake Formation for data lake permissions. Use DataSync or Snowball for transfer.
How it works / steps
- Check data volume, velocity and latency requirements (real-time, minutes or daily)
- Use Kinesis Data Streams for millisecond-to-second custom processing and Firehose for delivery to S3
- Build the catalog with Glue and convert to a columnar format such as Parquet
- Query S3 with Athena and reduce data read with partitions
- Use DataSync for continuous transfer from on-premises
Workplace example
IoT sensor data is delivered to S3 as Parquet every minute with Firehose and analyzed with Athena using the Glue catalog.
Common confusions and exam tips
- Firehose buffers, so it is not suited to millisecond real-time processing
- Columnar formats (Parquet, ORC) and compression lower Athena cost and time
- Kinesis Data Streams capacity is set by the number of shards (on-demand mode is also available)
Mini quiz
Q1. Kinesis Data Streams processing cannot keep up, and ingestion is being throttled. Which measure is most appropriate?
- Shorten the data retention period
- Reduce the number of producers and stop sending
- Delete the stream and have all producers write directly to S3
- Increase the number of shards (or use on-demand mode)
Show answer and explanation
Answer: D Increase the number of shards (or use on-demand mode)
In provisioned mode, the number of shards determines throughput. Add shards, or use on-demand mode to adjust capacity automatically.
Q2. You are comparing analytics building blocks. Which statement about Amazon Athena is incorrect?
- Data cannot be queried without loading it into dedicated storage
- It is billed by the amount of data scanned by queries
- It can query data in S3 with standard SQL
- No server management is required
Show answer and explanation
Answer: A Data cannot be queried without loading it into dedicated storage
Athena queries data in S3 directly. Columnar formats (such as Parquet), compression and partitioning reduce the amount scanned.
Reference links
Lessons are written by this site based on public information and do not guarantee exam content. Product specifications change, so check the latest information at the reference links.
Notes (unofficial, original questions, no pass guarantee)
- The questions on this site are original practice questions written by this site based on publicly available skills outlines and exam guides. They are not actual exam questions.
- Amazon Web Services, AWS and related marks are trademarks of Amazon.com, Inc. or its affiliates. This site is not affiliated with or endorsed by AWS.
- This content is a study aid and does not guarantee a pass. Exam content, format and prerequisites may change without notice; always check the latest information on the official page before taking the exam.
- Your accuracy on the mock exam cannot be converted to the official (scaled) score and does not predict a pass or fail.
- Progress is saved only in this browser (localStorage) unless you sign in with Google to sync it. You can delete it from the Cookie & storage settings page (Japanese).