AWS SAA · Domain 3
Design High-Performing Architectures
About 24% of the exam
Compute options
- EC2
- full control of the instance
- Auto Scaling group
- capacity follows the demand
- ECS on EC2
- containers, you manage the hosts
- Fargate
- containers with no hosts to patch
- EKS
- Kubernetes with a managed control plane
- Lambda
- event driven, short lived, serverless
- AWS Batch
- queued jobs across purchase options
- Elastic Beanstalk
- platform handles the plumbing
Match the runtime to the shape of the work: steady servers, bursty functions, or queued batch jobs
EC2 instance families
- General purpose
- balanced compute, memory and network
- Compute optimized
- high clock, transcoding and simulation
- Memory optimized
- large in-memory datasets and caches
- Storage optimized
- high local disk throughput
- Accelerated computing
- GPUs for training and inference
- Burstable
- credits for spiky small workloads
- Graviton
- better price for many workloads
- Placement group
- cluster, spread or partition
EBS volume types
- gp3
- baseline throughput, tuned independently
- gp2
- performance scales with size
- io2
- provisioned IOPS, highest durability
- io2 Block Express
- largest IOPS for critical databases
- st1
- large sequential throughput, cheap
- sc1
- cold, rarely accessed data
- Instance store
- fast, ephemeral, dies with instance
- Multi-Attach
- one volume, several instances
Storage services by shape
- Amazon S3
- object storage, effectively unlimited
- Amazon EBS
- block volume for one instance
- Amazon EFS
- shared file system for Linux
- FSx for Windows
- SMB shares with directory integration
- FSx for Lustre
- high throughput for compute clusters
- FSx for ONTAP
- efficiency features and snapshots
- Storage Gateway
- on-premises access to cloud storage
- Snowball
- bulk transfer the network cannot carry
S3 performance and classes
- Standard for frequent access
- Intelligent-Tiering moves objects automatically
- Standard-IA and One Zone-IA for cold
- Glacier tiers for archive retention
- Expedited retrieval returns within minutes
- Transfer Acceleration uses edge locations
- Multipart upload for large objects
- S3 Select filters before transfer
Database performance
Relational
- RDS Proxy pools database connections
- Read replicas offload read traffic
- Aurora reader endpoint balances readers
- Right-size the instance class first
NoSQL
- Partition key must spread evenly
- A hot key causes throttling
- Secondary indexes have their own capacity
- DAX caches reads in microseconds
Analytics
- Redshift for warehouse queries
- Spectrum queries data in S3
- Partition and compress the data
- Athena is serverless over S3
Caching and content delivery
CloudFront
- Caches static and dynamic content
- TTL settings control freshness
- Compression on eligible responses
- Request collapsing protects the origin
ElastiCache
- Redis for structures and replication
- Memcached for simple sharded caching
- Cache aside is the common pattern
- Multi-AZ with automatic failover
Edge compute
- CloudFront Functions for tiny rewrites
- Lambda at Edge for richer logic
- Global Accelerator for TCP and UDP
- Origin failover to a second origin
Network performance
- Enhanced networking with elastic fabric adapters
- Cluster placement group lowers latency
- Direct Connect gives predictable bandwidth
- Transit Gateway simplifies many connections
- Endpoints avoid the NAT gateway hop
- Same zone traffic avoids cross-zone charges
Scaling patterns
- Scale out before scaling up
- Stateless tiers scale without pain
- Target tracking on a user-facing metric
- Provisioned concurrency removes Lambda cold starts
- Queue depth makes a good signal
- Load test before the launch
Analytics and streaming
- Kinesis Data Streams orders within a shard
- Split shards to raise throughput
- Firehose delivers into S3 and Redshift
- Partition key drives shard distribution
- Batch small records to cut overhead
- Glue catalogs the data for Athena
Performance anti-patterns
- Scaling on the instance count itself
- Database connection opened per invocation
- Random access on throughput optimized disks
- One huge instance instead of many
- Chatty service calls across zones
- Cache never invalidated after writes
Service names to know
- Shared Linux file system
- Amazon EFS
- Parallel compute file system
- FSx for Lustre
- Microsecond DynamoDB reads
- DynamoDB Accelerator
- Managed connection pooling
- Amazon RDS Proxy
- Global anycast entry point
- AWS Global Accelerator
- Serverless SQL over S3
- Amazon Athena
- Managed Kafka
- Amazon MSK
Know the order
- Measure the bottleneck
- Right-size
- Cache
- Scale out
- Measure again
Measure before you resize, because the wrong metric turns a scaling policy into an expensive no-op
Reference strip: compute, storage, database, delivery, method
Compute
- Instance families by shape
- Spot for interruptible batch
- Fargate removes host patching
- Lambda for short bursts
Storage
- gp3, io2, st1 and sc1
- EFS shared, FSx specialized
- S3 classes by access pattern
- Instance store is ephemeral
Database
- Read replicas and proxies
- Even partition keys
- DAX and ElastiCache
- Redshift for warehouses
Delivery
- CloudFront at the edge
- Global Accelerator for TCP
- Compression and caching headers
- Origin failover configured
Method
- Measure the real bottleneck
- Load test before launch
- Compute Optimizer recommendations
- Review as traffic changes
Quick exam traps
- Trap: Provisioned IOPS volumes are the right answer for large sequential reads
- Trap: EFS gives one instance dedicated block performance
- Trap: Instance store data survives a stop and start
- Trap: Adding read replicas fixes a write throughput problem
- Trap: Intelligent-Tiering is always cheaper than choosing a class deliberately
- Trap: The number of running instances is a valid target tracking metric
- Trap: Enabling DAX also caches strongly consistent reads and writes
cybercertprep.com · original revision sheet written from the public body of knowledge