Design High-Performing Architectures
Core concepts
Performance questions reward picking the right tool for the bottleneck and knowing the scaling lever each service offers.
Compute: match instance families to workload (compute, memory, storage, accelerated), consider Graviton for price-performance, and use placement groups - cluster for low-latency HPC (single AZ), spread for small numbers of critical instances, partition for distributed systems like HDFS and Kafka. Enhanced networking and EFA matter for tightly coupled workloads.
Storage: gp3 decouples IOPS from capacity (unlike gp2), io2 Block Express for high-IOPS databases, st1 for throughput-heavy sequential access, instance store for scratch. S3 performance scales with request parallelism: multipart upload for large objects, byte-range fetches, and prefix distribution; Transfer Acceleration for distant uploaders.
Databases: Aurora reader endpoints and read replicas for read-heavy traffic, ElastiCache/DAX for hot-read caching, and DynamoDB partition-key design to avoid hot partitions. Adaptive capacity helps but does not fix a low-cardinality key.
Decoupling and edge: CloudFront for cacheable content at the edge, Global Accelerator for TCP/UDP latency over the AWS backbone, ALB for HTTP path/host routing, NLB for extreme throughput, static IPs, or non-HTTP protocols.
Traps
- Choosing a bigger instance when the real fix is caching, indexing, or partitioning.
- Assuming DynamoDB provisioned throughput auto-scales instantly under a hot key.
- Using a Network Load Balancer for path-based routing (that is ALB).
Worked example
A DynamoDB table throttles under load even with high provisioned capacity; the key is a timestamp. Reads for "today" all hit one partition. Fix the key design (add a high-cardinality suffix or a write-sharding component) rather than adding capacity.