Compute and Storage Performance
Right-sizing EC2, placement groups and enhanced networking, and squeezing performance from EBS, S3, EFS, and FSx.
The previous topics were about seeing a problem and reacting to it. This one is about the problems that never trip an alarm: an instance that is twice the size it needs to be, a volume that runs out of burst credits at 3am, a transfer that uses a fifth of the bandwidth you are paying for. Nothing is broken in any of these cases, which is why they survive for months, and why the exam devotes a whole task to finding them.
What This Topic Covers
- Compute Optimizer findings, finding reasons, and performance risk, and the metric CloudWatch cannot collect without an agent
- The CPU credit model behind burstable T instances, and the difference between standard and unlimited mode
- Single-flow versus aggregate network bandwidth, network I/O credits, and the ENA allowance counters that reveal throttling CloudWatch averages away
- Cluster, partition, and spread placement groups, with the limits and capacity errors that come with each
- EBS volume types and their provisioning models, the connection between I/O size and throughput, and the gp2 burst credit arithmetic
- Telling a throttled volume apart from a throttled instance, and modifying a live volume with Elastic Volumes
- S3 request rates per prefix, 503 Slow Down responses, byte-range fetches, multipart uploads, and choosing between Transfer Acceleration, DataSync, and Snow devices
- EFS performance modes, throughput modes, and lifecycle policies, plus the 4 FSx file systems and Mountpoint for Amazon S3
Why It Matters
Task 1.3 of the SOA-C03 exam guide asks you to optimize compute resources with performance metrics and tags, analyze EBS metrics and pick the right volume type, implement S3 transfer strategies, evaluate shared storage options, and tune EC2 instances along with their storage and networking. Those questions are rarely about definitions. They give you a symptom and a set of numbers and ask which limit you are hitting.
The pattern repeats across almost everything here: AWS gives you a baseline you can sustain forever plus a credit bucket for going above it, and the incident happens when the bucket empties. Learn to spot that shape once, in CPUCreditBalance, BurstBalance, EBSByteBalance%, network I/O credits, and EFS BurstCreditBalance, and a large slice of this domain becomes the same question wearing different service names.