Study guide
Roughly 24% of the exam tests whether you can choose the AWS service and configuration that best matches a workload's performance profile, whether that means raw compute throughput, storage IOPS, or reducing latency for users spread across the globe. This chapter reviews the compute, storage, database, and networking options that make an architecture fast rather than merely functional.
Choosing EC2 Instance Families and Placement Groups
EC2 instances are grouped into families optimized for different workload shapes. General purpose instances (like the M family) balance compute, memory, and networking for typical web applications. Compute optimized instances (the C family) favor workloads with a high ratio of CPU work to memory, such as batch processing or media transcoding. Memory optimized instances (the R and X families) suit workloads that hold large datasets in memory, such as in-memory databases or big data processing. Storage optimized instances (the I and D families) provide high, low-latency local disk throughput for workloads like NoSQL databases or data warehousing. A scenario describing a genomics research workload at a company like Baxter Life Sciences that needs to hold enormous datasets entirely in RAM for rapid analysis points to a memory optimized instance, while a scenario about a video encoding pipeline points to compute optimized. Beyond instance selection, a placement group controls how instances are physically arranged. A cluster placement group packs instances close together in a single AZ for the lowest possible network latency and highest throughput between them, ideal for tightly coupled high performance computing (HPC) workloads, but it increases the risk that a single hardware failure affects multiple instances at once. A spread placement group does the opposite, spreading a small number of critical instances across distinct underlying hardware to minimize correlated failure, suiting a handful of instances that must never fail together. A partition placement group divides instances into logical partitions on separate hardware, used by distributed systems like Hadoop or Cassandra that need awareness of partition boundaries to place replicas safely.
Storage Performance: EBS, S3, and Transfer Optimization
Amazon EBS offers several volume types tuned for different performance needs. General Purpose SSD (gp3) is the default recommendation for most workloads, providing a solid baseline of IOPS and throughput that can be provisioned independently of volume size, meaning you can pay for extra performance without buying extra capacity. Provisioned IOPS SSD (io2, including the io2 Block Express tier) targets the most demanding, latency-sensitive workloads such as large relational databases, offering very high IOPS, high durability, and support for volumes needing consistent sub-millisecond-class performance. Throughput Optimized HDD (st1) and Cold HDD (sc1) are magnetic volumes priced for throughput-heavy, sequential workloads like big data processing or infrequently accessed data, not for transactional databases. Exact numeric limits for each volume type are updated periodically, so always confirm current maximums on the AWS EBS documentation before an exam attempt or a real design. On the object storage side, S3 Transfer Acceleration speeds up uploads over long distances by routing traffic through Amazon CloudFront's globally distributed edge locations to reach the nearest one and then over AWS's optimized backbone network to the bucket, which benefits a photography marketplace like Denner Foto Co. whose contributors upload large files from around the world. Multipart upload splits a single large object into parts uploaded in parallel, then reassembles them, improving throughput and letting a failed part be retried without restarting the entire upload; AWS recommends it for objects above 100 MB. For frequently accessed static or dynamic content, Amazon CloudFront caches responses at edge locations near end users, cutting latency and reducing load on the origin server.
Caching and Database Performance: ElastiCache, DAX, and Read Scaling
Amazon ElastiCache provides a managed in-memory data store, available with the Valkey, Redis OSS, or Memcached engine, sitting in front of a database to serve frequently requested data far faster than a disk-backed query would. Valkey (an open-source fork of Redis that AWS now recommends for new deployments) and Redis OSS support data persistence, replication, and richer data structures like sorted sets, making them suitable for use cases such as leaderboards or session stores that need durability and complex queries. Memcached is simpler, purely a multi-threaded cache with no persistence, fitting workloads that just need to cache simple key-value pairs and can tolerate cache loss on restart. For DynamoDB specifically, DynamoDB Accelerator (DAX) is a dedicated in-memory cache purpose-built in front of DynamoDB tables, reducing read latency and offloading repeated reads without requiring application-level cache logic, though it only accelerates reads, not writes. DynamoDB's two capacity modes matter for performance planning too: on-demand mode automatically absorbs traffic spikes without pre-planned capacity, well suited to unpredictable workloads, while provisioned mode, ideally paired with auto scaling, suits steady, forecastable traffic at potentially lower cost. Good partition key design still matters in either mode, since a poorly chosen key that concentrates traffic on one partition value creates a hot partition regardless of capacity mode. For relational workloads, Amazon Aurora separates compute from a distributed, auto-scaling storage layer and supports up to fifteen low-latency Aurora Replicas for read scaling; because Aurora Replicas share the same distributed storage volume as the writer, their replica lag is typically far lower than the asynchronous replication lag of standard RDS read replicas. Aurora also offers a reader endpoint that automatically load-balances read traffic across all available replicas, simplifying application logic that just needs to send reads somewhere fast.
Containers, Serverless, and the Performance Trade-off
Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service) both run containerized applications, differing mainly in orchestration model: ECS uses AWS's own simpler orchestration API, while EKS runs upstream Kubernetes, appealing to teams already standardized on Kubernetes tooling or needing to run the same manifests across multiple clouds. Both can run their containers on AWS Fargate, a serverless compute engine that removes the need to provision or patch underlying EC2 instances, letting you specify only CPU and memory per task while AWS manages the compute fleet; the trade-off is somewhat less low-level control and typically a higher per-unit compute cost than self-managed EC2 capacity. AWS Lambda takes this further into serverless: code runs only in response to triggers, scales automatically and near-instantly to handle concurrent invocations, and you pay per invocation and duration rather than for idle capacity. Lambda's performance trade-off is the cold start, a brief added latency when a new execution environment must initialize, which matters for latency-sensitive synchronous APIs but is largely irrelevant for asynchronous or infrequent background processing. A scenario describing an image-thumbnail generator triggered occasionally by S3 uploads fits Lambda well; a scenario describing a long-running, steady-traffic web service with predictable load and a need for fine-grained infrastructure control points toward ECS or EKS on EC2 instead. AWS Global Accelerator improves performance for global user bases by routing traffic onto AWS's private backbone network through the nearest of a fixed set of anycast IP addresses, reducing the number of internet hops; it suits non-HTTP protocols and use cases needing static entry-point IP addresses, which differentiates it from CloudFront, which is purpose-built for HTTP/HTTPS content caching.
Key terms
- Compute optimized instance
- — An EC2 instance family favoring a high ratio of CPU performance to memory, suited to batch processing or media encoding.
- Cluster placement group
- — An EC2 placement strategy that packs instances close together in one AZ for the lowest network latency between them.
- gp3
- — General Purpose SSD EBS volume type providing baseline IOPS and throughput that can be provisioned independently of volume size.
- S3 Transfer Acceleration
- — An S3 feature that routes uploads through CloudFront edge locations onto AWS's backbone network to speed long-distance transfers.
- Multipart upload
- — Splitting a large S3 object into parts uploaded in parallel, improving throughput and allowing individual part retries.
- ElastiCache
- — A managed in-memory caching service, available with the Valkey, Redis OSS, or Memcached engine, that reduces read latency for frequently accessed data.
- DAX (DynamoDB Accelerator)
- — A dedicated in-memory cache for DynamoDB that reduces read latency without requiring application-level caching logic.
- Aurora Replica
- — A read-scaling replica in Amazon Aurora sharing the same underlying distributed storage as the primary, accessed via a load-balancing reader endpoint.
- Fargate
- — A serverless compute engine for ECS and EKS that runs containers without provisioning or managing underlying EC2 instances.
- Cold start
- — The brief added latency when a serverless execution environment, such as an AWS Lambda function, must initialize before running.
- Global Accelerator
- — A networking service that routes traffic onto AWS's private backbone via static anycast IPs to improve performance for global users.
- Hot partition
- — A DynamoDB performance problem where a poorly distributed partition key concentrates traffic on a single partition.
Exam tips
- Match instance family to workload shape: compute optimized for CPU-heavy batch jobs, memory optimized for in-memory datasets, storage optimized for high local disk I/O.
- For DynamoDB read latency problems, DAX is the purpose-built answer; for general database read scaling, Aurora Replicas or RDS read replicas apply instead.
- When a question stresses infrequent, event-driven, short-lived processing, favor Lambda; when it stresses steady long-running services needing infrastructure control, favor ECS/EKS on EC2.
- Distinguish CloudFront (HTTP/HTTPS content caching at the edge) from Global Accelerator (backbone routing via static IPs, works for non-HTTP protocols too).
- Always sanity-check any numeric IOPS, throughput, or replica-count limit mentioned in a practice question against current AWS documentation, since these figures are periodically increased.