Domain 3: Design High-Performing Architectures

AWS Certified Solutions Architect – Associate (SAA-C03) — Domain 3: Design High-Performing Architectures

Exam Code: SAA-C03  |  Level: Associate
Domain Weight: 24%  |  Total Domains: 4  |  Passing Score: 720/1000

---

Table of Contents

1. High-Performing Storage Solutions
   • 1.1 Storage Selection Framework
   • 1.2 EBS Volume Types Deep Dive
   • 1.3 S3 Performance Optimization
   • 1.4 Hybrid Storage Solutions
2. High-Performing Compute Solutions
   • 2.1 EC2 Instance Family Selection
   • 2.2 EC2 Purchasing Options for Performance
   • 2.3 Scaling for Performance
   • 2.4 Serverless Performance Optimization
3. High-Performing Database Solutions
   • 3.1 Relational Database Performance
   • 3.2 DynamoDB Performance Deep Dive
   • 3.3 ElastiCache and MemoryDB
   • 3.4 Specialized Purpose-Built Databases
4. High-Performing Network Architectures
   • 4.1 CloudFront for Performance
   • 4.2 AWS Global Accelerator
   • 4.3 VPC Design for Performance
5. Data Ingestion and Analytics Pipelines
   • 5.1 Streaming Data Services
   • 5.2 Batch Data Processing
   • 5.3 Analytics and Visualization
6. Exam Tips & Quick Reference

---

1. High-Performing Storage Solutions

1.1 Storage Selection Framework

Every performance question starts with choosing the right storage type for the access pattern. Use this decision tree before choosing a service.

What is the data access pattern?
│
├── Object data (images, videos, backups, static website, logs)
│   └── Amazon S3
│
├── Block data (OS, databases, applications requiring raw disk)
│   ├── Single instance attachment   → Amazon EBS
│   └── Multi-instance (rare)        → EBS io1/io2 with Multi-Attach
│
├── File data (shared hierarchical, NFS/SMB)
│   ├── Linux, NFS                   → Amazon EFS
│   ├── Windows, SMB, AD             → FSx for Windows
│   ├── HPC or ML training           → FSx for Lustre
│   └── Multi-protocol (NFS + SMB)   → FSx for NetApp ONTAP
│
└── Archive (infrequent, long-term retention)
    ├── Need instant retrieval        → S3 Glacier Instant Retrieval
    ├── Minutes–hours OK              → S3 Glacier Flexible Retrieval
    └── 12+ hours OK                  → S3 Glacier Deep Archive

---

1.2 EBS Volume Types Deep Dive

Full EBS Volume Comparison

Key Concept: gp3 decouples IOPS from volume size — you can configure up to 16,000 IOPS on any size volume. gp2 forces you to provision a large volume to get high IOPS (3 IOPS/GB). For the same IOPS, gp3 is always cheaper. Migrate from gp2 to gp3 for an instant ~20% cost reduction.

Instance Store (Ephemeral)

Instance store is NVMe SSD directly attached to the host hardware — no network overhead. It provides the highest possible IOPS and throughput available in AWS. The critical constraint: data is permanently lost when the instance stops, terminates, or the host fails. It survives reboot only.

Use instance store for: buffer, scratch space, temporary processing, or as a caching layer where data can be recreated from a durable source.

EBS Multi-Attach

Attach a single io1 or io2 volume to up to 16 EC2 instances simultaneously within the same AZ. The application must manage concurrent write access using a cluster-aware file system. Use for Oracle RAC or high-availability shared storage clusters.

---

1.3 S3 Performance Optimization

S3 Throughput Limits and Scaling

S3 automatically partitions based on key prefixes. Each prefix supports 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second. Using multiple key prefixes creates multiple partitions and linearly scales throughput. S3 scales automatically — no manual sharding required.

Transfer Performance Methods

S3 Storage Class Selection

S3 Lifecycle Transitions — Minimum Age Rules

S3 Standard → Standard-IA:          minimum 30 days in Standard
Standard-IA → Glacier Instant:       minimum 90 days from object creation
Standard-IA → Glacier Flexible:      minimum 90 days from object creation
Any class   → Glacier Deep Archive:  minimum 180 days from object creation
Expiration:                          delete objects or incomplete multipart uploads after N days

---

1.4 Hybrid Storage Solutions

AWS Storage Gateway — Gateway Type Selection

Exam Tip: "All data must remain on-premises, with cloud backup" → Volume Gateway Stored mode. "Large dataset in cloud, local cache for frequently accessed data" → Volume Gateway Cached mode. Confusing these two is one of the most common Domain 3 mistakes.

AWS DataSync vs. Storage Gateway

Key Concept: Use DataSync for migration — moving large data sets to AWS once (or periodically). Use Storage Gateway for ongoing hybrid access — on-premises applications that continuously read and write to cloud storage.

AWS Transfer Family

Provides managed SFTP, FTPS, FTP, and AS2 endpoints that front Amazon S3 or EFS. Migrate existing FTP-based workflows to S3 without changing client software. Supports custom authentication via Lambda, Secrets Manager, or Active Directory.

---

2. High-Performing Compute Solutions

2.1 EC2 Instance Family Selection

Match the instance family to the workload bottleneck — CPU, memory, network, or storage.

Matching Symptoms to Instance Family

• Application uses > 80% RAM, CPU normal → Memory Optimized (R-series)
• Application uses > 80% CPU, RAM normal → Compute Optimized (C-series)
• ML training workload → GPU (P-series or G-series)
• General web application → M-series (steady) or T-series (variable/bursty)

Burstable Performance (T-Series)

T3, T3a, and T4g instances earn CPU credits when running below baseline and spend them when bursting. In Standard mode, the instance is throttled when credits are exhausted. In Unlimited mode, it bursts beyond credits and accrues additional charges. Unlimited mode prevents throttling for production workloads with occasional spikes.

---

2.2 EC2 Purchasing Options for Performance

Savings Plans vs. Reserved Instances

Key Concept: Choose Compute Savings Plans when you have mixed workloads (EC2 + Lambda + Fargate), plan to migrate regions, or need the flexibility to change instance families. The slight discount reduction is worth the flexibility for most organizations.

Spot Instances for Performance at Low Cost

Spot Instances offer up to 90% discount but can be interrupted with a 2-minute warning. Key strategies:

• Capacity-optimized allocation — AWS selects the Spot pool with the most available capacity; minimizes interruptions.
• Spot Fleet with multiple instance types — diversify across pools; if one type is unavailable, another is used.
• Interruption handling — subscribe to EC2 Spot Instance Interruption Notice via EventBridge → Lambda to gracefully drain connections and checkpoint work.

---

2.3 Scaling for Performance

Auto Scaling Custom Metrics for SQS Workloads

Custom CloudWatch Metric:
  ApproximateNumberOfMessagesVisible / NumberOfRunningInstances

Target Tracking Target Value = desired backlog per instance (e.g., 100 messages)

Effect: ASG scales workers proportionally to queue depth

EC2 Fleet and Spot Fleet

EC2 Fleet launches a mix of instance types and purchase options (On-Demand + Spot + Reserved) with a single API request, simplifying capacity provisioning for heterogeneous workloads.

---

2.4 Serverless Performance Optimization

Lambda Memory and CPU Relationship

Lambda CPU power scales proportionally with memory allocation. Doubling memory effectively doubles CPU. Sometimes allocating more memory makes a function faster and cheaper because it reduces duration enough to offset the higher per-millisecond rate. Use the AWS Lambda Power Tuning open-source tool to find the optimal memory/cost balance.

Lambda Performance Tools

Exam Tip: Provisioned Concurrency is the answer for eliminating cold starts. SnapStart is specifically for Java runtimes and is cheaper than Provisioned Concurrency for some use cases. Both reduce latency; the exam differentiates by runtime and cost sensitivity.

---

3. High-Performing Database Solutions

3.1 Relational Database Performance

RDS Read Replicas for Read Scaling

Route read queries to the reader endpoint to offload the primary instance. Up to 5 read replicas per RDS instance (up to 15 for Aurora). Read replicas use asynchronous replication — there may be a small lag. Replicas can be in different Regions (Cross-Region Read Replicas).

RDS Proxy

RDS Proxy sits between your application and RDS, managing a persistent connection pool. Critical for Lambda functions (which open many short-lived connections) and applications with bursty connection patterns. Also improves failover time by maintaining connections during Multi-AZ failover.

Performance Insights vs. Enhanced Monitoring

Key Concept: Performance Insights reveals why a database is slow (which queries, which wait events). Enhanced Monitoring shows the OS resource consumption. Use Performance Insights first for query-level bottlenecks.

Aurora Architecture for Performance

Cluster Endpoints:
├── Writer Endpoint    → always routes to current primary (handles failover automatically)
├── Reader Endpoint    → load-balances reads across all Aurora Replicas
└── Custom Endpoints   → point to a specific subset of instances (workload isolation)

Aurora Parallel Query pushes processing to storage-layer nodes, reducing data movement and accelerating analytics queries on transactional data without a separate data warehouse.

---

3.2 DynamoDB Performance Deep Dive

Capacity Modes

Capacity Unit Math

• 1 RCU = 1 strongly consistent read per second for items ≤ 4 KB (or 2 eventually consistent reads)
• 1 WCU = 1 write per second for items ≤ 1 KB
• Items larger than the threshold consume proportionally more units

Read Consistency Models

Global Secondary Index vs. Local Secondary Index

---

3.3 ElastiCache and MemoryDB

ElastiCache Redis Cluster Modes

• Cluster Mode Disabled (Replication Group) — one shard, up to 5 read replicas, up to 500 GB dataset. Simplest configuration.
• Cluster Mode Enabled — up to 500 nodes across multiple shards; supports up to 340 TB dataset; horizontal write scaling via sharding.

Production Redis Patterns

• Session store — stateless app servers store user sessions in Redis; instances are interchangeable
• Leaderboard — sorted sets for real-time ranking without complex queries
• Rate limiting — INCR counter per user key with a TTL; atomic and fast
• Query result caching — cache-aside pattern; reduces RDS load by 90%+ for read-heavy workloads
• Pub/Sub — lightweight real-time messaging for chat or notifications

Amazon MemoryDB for Redis

MemoryDB is Redis-compatible but designed as a primary database, not just a cache. Data is persisted in a Multi-AZ transaction log, providing microsecond reads and single-digit millisecond writes with full durability. Use MemoryDB when Redis data is the source of truth (not a cache in front of another database).

---

3.4 Specialized Purpose-Built Databases

Choose the right database engine before optimizing — the wrong engine is never "performant enough."

Amazon Redshift Performance Features

Key Concept: Redshift is for OLAP (analytics, aggregations, historical reports). Do not use Redshift for OLTP (transactional, row-level operations). For mixed workloads, use RDS/Aurora for OLTP and Redshift + Spectrum for analytics on historical data.

---

4. High-Performing Network Architectures

4.1 CloudFront for Performance

CloudFront caches content at 400+ edge locations globally, dramatically reducing origin load and user latency.

Cache Behavior Configuration

CloudFront Functions vs. Lambda@Edge

Exam Tip: Use CloudFront Functions for simple, high-volume operations that run at every edge location (URL redirects, header manipulation). Use Lambda@Edge when you need more compute power, longer duration, or need to make calls to origin/external services.

Origin Groups for Failover

Configure an Origin Group with a primary origin and a failover origin. If the primary returns 5xx errors or is unavailable, CloudFront automatically retries the request against the failover origin — providing automatic CDN-level failover.

---

4.2 AWS Global Accelerator

Global Accelerator uses two static anycast IP addresses to route traffic through the AWS global network backbone rather than the public internet. This reduces latency by entering the AWS backbone at the nearest edge location.

CloudFront vs. Global Accelerator

Exam Tip: If the question mentions static IPs or IP allow-listing, the answer is Global Accelerator. If it mentions caching or CDN, the answer is CloudFront. Both improve global performance; they solve different problems.

---

4.3 VPC Design for Performance

Placement Groups

Enhanced Networking Options

• ENA (Elastic Network Adapter) — standard on current-gen instances; up to 100 Gbps network throughput
• EFA (Elastic Fabric Adapter) — adds OS-bypass networking (RDMA) for HPC; enables MPI communication at near-hardware latency; use for ML training clusters and CFD/weather simulation

---

5. Data Ingestion and Analytics Pipelines

5.1 Streaming Data Services

Kinesis Data Streams (KDS)

KDS enables real-time streaming with custom consumers and configurable retention (up to 365 days for replay).

Amazon Data Firehose (formerly Kinesis Data Firehose)

Fully managed delivery stream to S3, Redshift, OpenSearch, Splunk, and HTTP endpoints. No consumers to manage — Firehose handles buffering, transformation (optional via Lambda), and delivery automatically.

Kinesis vs. SQS

Amazon MSK (Managed Streaming for Apache Kafka)

Fully managed Kafka cluster. Use when the team already has Kafka expertise, when Kafka Connect or Kafka Streams is needed, or when migrating existing Kafka workloads to AWS. More operationally complex than Kinesis but fully API-compatible with Apache Kafka.

---

5.2 Batch Data Processing

AWS Batch

Managed batch computing on EC2 or Fargate for large-scale parallel jobs. Three key components:

• Job Definition — Docker image, resource requirements (vCPU, memory), command, retry strategy
• Job Queue — holds submitted jobs; assigned a priority; linked to a compute environment
• Compute Environment — EC2 or Fargate; managed (AWS handles scaling/provisioning) or unmanaged

Amazon EMR

Managed cluster for big data frameworks: Hadoop, Spark, HBase, Flink, and Presto. Deployment options:

• EMR on EC2 — traditional cluster; cost-effective with Spot instances for transient workloads
• EMR on EKS — run EMR jobs on an existing Kubernetes cluster
• EMR Serverless — no cluster management; auto-scales; pay per job

AWS Glue

Serverless ETL service and central data catalog.

---

5.3 Analytics and Visualization

Amazon Athena

Serverless, interactive SQL query engine for data in S3. Pay per query (per TB of data scanned). No infrastructure to provision.

Performance and cost optimization for Athena:

• Partition data by date, region, or account → queries scan only relevant partitions
• Use columnar formats (Parquet, ORC) → 30–90% less data scanned vs. CSV
• Compress data → fewer bytes to scan = lower cost and faster queries
• Federated query — query RDS, DynamoDB, and Redshift from Athena using Lambda data source connectors

AWS Lake Formation

Simplifies building, securing, and managing data lakes on S3.

Amazon QuickSight

Business intelligence and dashboarding. The SPICE (Super-fast Parallel In-memory Calculation Engine) in-memory analytics engine returns sub-second query results. Embedded analytics capability allows dashboards to be integrated into third-party applications. Pay-per-session pricing eliminates heavy BI licensing costs.

---

Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• DataSync vs. Storage Gateway: DataSync is for migration and batch transfer. Storage Gateway is for ongoing hybrid access. The exam tests this distinction frequently.
• CloudFront vs. Global Accelerator: CloudFront caches; Global Accelerator does not. Static IPs = Global Accelerator. Caching/CDN = CloudFront.
• gp2 vs. gp3: Always prefer gp3 for new volumes. gp2 ties IOPS to volume size; gp3 lets you configure them independently at lower cost.
• Kinesis vs. SQS: Kinesis allows multiple independent consumers to read the same stream; SQS delivers each message to one consumer. If multiple teams need the same events, use Kinesis (or SNS → multiple SQS queues).
• DAX write limitation: DAX is a write-through cache — it speeds up reads but does not help write-heavy workloads. The exam sometimes presents a write-heavy scenario and DAX as a distractor.
• Aurora Serverless v2 minimum: v2 scales down to 0.5 ACU minimum (not zero). v1 scales to zero but has a cold start. If the question requires true zero-cost-when-idle, v1 or regular serverless patterns (Lambda + DynamoDB) are needed.

---

Key Terms — Domain 3

---

End of Domain 3. Continue to Domain 4: Design Cost-Optimized Architectures →