Design High-Performing Architectures
Pick the right primitive before you tune anything
High performance on AWS starts with selection, not tuning: match each part of the architecture to its workload before you touch a single knob. Five areas cover this whole domain (storage, compute, database, networking, and ingestion) and each has a primitive that fits a given access pattern naturally. The classic exam trap is reaching for tuning or a bigger instance when the real fix is a different primitive entirely (object instead of file, key-value instead of relational, an edge cache instead of a faster origin). Name the area and the access pattern first, and the right service usually follows; pick the wrong primitive and no amount of later tuning wins back the lost milliseconds.
The domain unfolds in five steps: storage, compute, database, networking, ingestion
Read this page as a map, then follow the five subtopics in order. High-performing storage picks the data shape, object (S3), file (EFS/FSx), or block (EBS), by how the data is accessed. High-performing compute matches the EC2 family to the bottleneck and chooses the operational model along the EC2 → containers → Fargate → Lambda spectrum. High-performing databases maps the access pattern to RDS/Aurora, DynamoDB, ElastiCache, or a warehouse, and is where the in-memory caches (ElastiCache, DAX) live. High-performing networks removes latency with CloudFront and Global Accelerator at the edge and picks the load balancer by L4 vs L7. High-performing data ingestion moves data in by latency tolerance, streaming (Kinesis, MSK) versus batch, then transforms it (Glue, Athena, EMR). Each subtopic carries the deep tables, the numbers, and the traps; this overview just shows how they fit together.
When in doubt, offload the read path and scale out, not up
Across all five areas the same instinct keeps winning: don't hit the origin or buy a bigger box when you can spread the load instead. Offload reads with caching and replicas (CloudFront at the edge, ElastiCache and DAX for hot keys, read replicas for read-heavy relational workloads) so most requests never reach the primary. Then scale out rather than up: add stateless capacity behind a load balancer with Auto Scaling, reach for serverless (Lambda, Fargate, DynamoDB on-demand) when the requirement says 'no servers to manage', and push expensive work into asynchronous pipelines to keep the synchronous request path fast.
The five performance areas, and where each is covered
| Area | Pick by | Example services | Drill into |
|---|---|---|---|
| Storage | Shape of the data: object vs file vs block | S3, EFS / FSx, EBS / instance store | High-Performing and Scalable Storage |
| Compute | The workload's bottleneck and how much ops you want | EC2 families, ECS / EKS, Fargate, Lambda | High-Performing and Elastic Compute |
| Database | Access pattern: relational, key-value, in-memory, warehouse | RDS / Aurora, DynamoDB (+ DAX), ElastiCache, Redshift | High-Performing Databases |
| Networking | Where the latency lives: distance vs L4/L7 routing | CloudFront, Global Accelerator, ALB / NLB | High-Performing and Scalable Networks |
| Ingestion | Latency tolerance: streaming vs batch | Kinesis / MSK, Firehose, Glue, Athena | High-Performing Data Ingestion and Transformation |