Technical Study Report: SAA-C03 Domain 3 — Designing High-Performing Architectures
1. Domain Overview: The Performance Pillar
In the AWS ecosystem, performance is not an inherent property of the cloud; it is a function of intentional design and precise configuration. For the SAA-C03 examination, Domain 3 focuses on the Architect's ability to select and tune services to meet specific latency, throughput, and IOPS requirements.
The core objectives of this domain are distilled into five critical task statements:
- Task 1: Storage — Determine high-performing and scalable storage solutions (Object, Block, File).
- Task 2: Compute — Design high-performing and elastic compute solutions (Instances, Containers, Serverless).
- Task 3: Database — Determine high-performing database solutions (SQL, NoSQL, Caching).
- Task 4: Network — Determine high-performing and/or scalable network architectures (Global acceleration, Hybrid connectivity).
- Task 5: Data Ingestion — Determine high-performing data ingestion and transformation solutions (Streaming, Batch, Physical transport).
2. High-Performing Compute Solutions
2.1 EC2 Instance Selection Framework
Architects must select instance families based on the primary resource bottleneck. When designing for high performance, the trade-off usually centers on cost-per-unit of the constrained resource.
| Family | Optimization | Ideal High-Performance Use Case |
|---|---|---|
| C Family | Compute (CPU) | High-performance web servers, video encoding, batch processing. |
| R Family | RAM (Memory) | In-memory analytics (SAP HANA), large Redis datasets, high-performance DBs. |
| I Family | I/O (Storage) | Massive local NVMe throughput for data warehouses and NoSQL workloads. |
| M Family | Mainstream (General) | Balanced ratio for application servers with steady-state workloads. |
| P/G Family | Pictures (Graphics) | Machine learning inference, 3D rendering, and GPU-intensive tasks. |
Technical Note: The CloudWatch Memory Trap In high-performance compute design, memory utilization is a critical scaling metric. However, Memory Utilization is NOT a default CloudWatch metric for EC2. For performance-based scaling triggered by RAM, a custom agent (CloudWatch Agent) must be installed on the instance to push metrics. This is a common "exam trap" where CPU-based scaling fails to address a memory bottleneck.
2.2 Optimizing Lambda Performance
Lambda performance is governed by the Memory x Duration pricing model. Increasing memory linearly increases allocated vCPU, which can significantly reduce latency for compute-heavy tasks.
- Reserved Concurrency: Sets a guaranteed maximum for a function. The primary performance use case is throttling to protect downstream resources (like RDS) from being overwhelmed by traffic spikes.
- Provisioned Concurrency: Pre-initializes execution environments to ensure they are "warm." This is the required mechanism to eliminate cold starts for customer-facing APIs requiring consistent sub-second latency.
2.3 Container Orchestration Performance
- ECS on EC2: Superior when the workload requires fine-grained control over the instance type, such as GPU-intensive ML or specific kernel tuning. It allows for higher container density and cost optimization for steady-state, high-utilization fleets.
- ECS on Fargate: The "least operational overhead" choice. It is superior for spiky, unpredictable workloads because it scales on a per-task basis without the latency associated with provisioning underlying EC2 cluster capacity.
Architectural Insight: ECS Role Distinction To ensure both performance and security, distinguish between the Task Role (permissions for the application code, e.g., S3/SQS access) and the Task Execution Role (permissions for the ECS agent to pull images from ECR and send logs to CloudWatch).
3. High-Performing Storage Solutions
3.1 Block Storage (EBS) Performance Tiers
When configuring EBS, Architects must distinguish between IOPS-limited and throughput-limited workloads.
| Volume Type | Primary Metric | Max Performance Values |
|---|---|---|
| gp3 | IOPS & Throughput | 16,000 IOPS / 1,000 MiB/s (Baseline 3,000 IOPS / 125 MiB/s included). |
| io2 | IOPS (Provisioned) | 256,000 IOPS (io2 Block Express) with 99.999% durability. |
| st1 | Throughput (HDD) | 500 MiB/s (Ideal for MapReduce, Log processing). |
| sc1 | Throughput (HDD) | 250 MiB/s (Cold storage for infrequently accessed big data). |
3.2 Instance Store vs. Provisioned EBS
Callout Box: The Performance Ceiling Gap For workloads demanding the highest possible local performance (e.g., NoSQL databases or scratch space), Instance Store provides 100,000+ IOPS and sub-millisecond latency. Because it is physically attached to the host, it is the most cost-effective choice for temporary/discarded data. io2 EBS is only the correct choice when these high performance levels must be paired with persistence (data must survive an instance stop or termination).
3.3 Scalable File Systems (EFS & FSx)
- EFS Bursting Mode: Throughput scales with the amount of data stored.
- EFS Provisioned Mode: Used when a scenario requires the highest predictable throughput regardless of the total data volume stored.
- EFS Elastic Mode: Automatically scales for spiky, unpredictable workloads.
FSx Flavor Comparison:
| Service | Protocol | Performance "Tell" |
|---|---|---|
| FSx for Windows | SMB | Native AD integration for Windows-based shared storage. |
| FSx for Lustre | Lustre | Sub-millisecond latency; integrates with S3 for HPC/ML. |
| FSx for NetApp ONTAP | NFS/SMB/iSCSI | Multi-protocol access with automatic volume tiering. |
| FSx for OpenZFS | NFS | High IOPS/low latency for Linux/ZFS migrations. |
3.4 S3 Performance Optimization
- Multi-part Uploads: Recommended for files > 100 MB and mandatory for files > 5 GB. This parallelizes the transfer to maximize bandwidth.
- S3 Transfer Acceleration: Leverages CloudFront edge locations and the AWS backbone to bypass internet congestion.
- CloudFront Caching: The most effective method for accelerating read performance for globally distributed static assets.
Archival Retrieval Time Comparison:
| Class | Retrieval Time | Performance Profile |
|---|---|---|
| Glacier Instant Retrieval | Milliseconds | Same latency as S3 Standard; no restore request needed. |
| Glacier Flexible Retrieval | 1 min to 12 hours | Requires a restore step; Expedited (1-5m) available. |
| Glacier Deep Archive | 12 to 48 hours | Lowest cost; longest restoration window. |
4. High-Performing Database Solutions
4.1 Relational Performance: RDS vs. Aurora
Aurora utilizes a shared cluster volume replicated 6 ways across 3 AZs. This architecture eliminates the storage-level bottlenecks of standard RDS. Aurora Replicas serve a dual role: they scale read performance (up to 15 replicas) and act as instant failover targets without data loss.
Technical Note: RDS Encryption Workflow In Domain 3, if an instance was created unencrypted, the only way to enable encryption is: Snapshot → Copy (and select encryption) → Restore new instance. This workflow is mandatory for retroactively securing performance-critical data.
4.2 NoSQL at Scale: DynamoDB & DAX
DynamoDB provides consistent single-digit millisecond latency. When a "hot-key" pattern (thousands of reads on one item) causes performance degradation, DynamoDB Accelerator (DAX) reduces latency to microseconds using an in-memory cache.
4.3 Caching and Connection Pooling
| Strategy | Trade-off | Result |
|---|---|---|
| Lazy Loading | Potential data staleness | Efficient memory usage; cache populated on demand. |
| Write-Through | Increased write latency | Cache is never stale; immediate read performance. |
For high-performing serverless architectures, use RDS Proxy. It pools database connections to prevent the CPU/RAM overhead of thousands of Lambda functions repeatedly opening and closing connections.
5. High-Performing and Scalable Networking
5.1 Load Balancer Triage
| Type | OSI Layer | Performance Strength |
|---|---|---|
| ALB | Layer 7 | Intelligence: Path/Host-based routing for microservices. |
| NLB | Layer 4 | Speed: Static IPs and ability to handle millions of requests/sec. |
| GLB | Layer 3 | Transparency: Scalable inspection of raw IP traffic. |
5.2 Global Traffic Acceleration
- CloudFront: Optimized for HTTP/HTTPS caching at the edge.
- Global Accelerator: Uses Anycast IP routing to optimize the path for TCP/UDP traffic over the AWS global backbone.
- Route 53 Policies: Use Latency-based routing to minimize distance to the user or Geoproximity to shift traffic based on geographic bias.
5.3 Hybrid Performance and Resiliency
- Site-to-Site VPN: Fast to provision but subject to internet jitter.
- Direct Connect (DX): Provides consistent bandwidth. To avoid a single point of failure, use a Site-to-Site VPN as a lower-cost backup to the primary DX link.
6. High-Performing Data Ingestion & Transformation
- Kinesis Data Streams: Real-time, manual scaling via shards; allows multiple consumers and data replay.
- Kinesis Data Firehose: Serverless delivery to S3/Redshift/OpenSearch. Best for the least operational effort when format conversion (JSON to Parquet) is required.
- AWS Glue vs. EMR: Use AWS Glue for serverless ETL and automated schema discovery. Use Amazon EMR when the dataset is petabyte-scale and requires fine-grained cluster tuning (e.g., custom Spark/Hadoop configurations).
- Snow Family: The primary solution for bandwidth-constrained environments where physical transport of TB/PB-scale data is faster than network transfer.
7. Summary Performance Decision Matrix
| Requirement Scenario | Recommended Service/Feature | Performance "Why" |
|---|---|---|
| Eliminate Lambda cold starts | Provisioned Concurrency | Pre-warms environments for instant execution. |
| Microsecond DB reads | DAX | In-memory cache for DynamoDB "hot-keys." |
| Millisecond S3 archival access | Glacier Instant Retrieval | Millisecond access without the restore-wait penalty. |
| Non-HTTP global acceleration | Global Accelerator | Uses Anycast IP routing over AWS global backbone. |
| Shared storage / least overhead | EFS | Serverless file system; auto-scales throughput. |
| Highest possible EC2 IOPS | Instance Store | 100,000+ IOPS via local NVMe (Ephemeral). |
| Sub-millisecond latency for HPC | FSx for Lustre | Optimized for high-throughput, low-latency compute. |
| Fixed IP for a Load Balancer | NLB | Only LB providing a static IP per Availability Zone. |
| Lambda to RDS connection volume | RDS Proxy | Connection pooling prevents database exhaustion. |