Determine High-Performing Storage Solutions for SAA-C03
Choose the right S3, EBS, EFS, FSx, replication, and access-pattern design for SAA-C03 storage-performance scenarios.
High-performing storage questions on SAA-C03 are rarely asking “which storage service exists?” They are asking whether the access pattern is block, file, or object, whether latency matters more than throughput, and whether the workload needs one writer, many readers, or shared concurrent access.
What AWS is explicitly testing
The current exam guide points to storage services and characteristics, caching, data access patterns, durability, and performance features such as Provisioned IOPS and file-versus-block behavior.
Storage chooser
| Requirement | Strongest first fit | Why |
|---|---|---|
| Boot or database volume with low-latency block access | EBS | Block storage attached to EC2 |
| Shared Linux file system across many instances | EFS | Managed elastic file storage |
| Object storage at massive scale | S3 | Best fit for object access patterns |
| Specialized managed file system family | FSx | Stronger fit for Windows, Lustre, NetApp, or OpenZFS style workloads |
Performance levers by storage type
| Service | Main performance lever | What SAA-C03 is really testing |
|---|---|---|
| EBS | Volume type, IOPS, and throughput | Whether block performance matches the instance workload |
| EFS | Shared file access pattern and throughput mode | Whether the workload needs concurrent shared access more than block latency |
| S3 | Request pattern, object design, transfer path, and caching | Whether object storage is the right model at all |
| FSx | Filesystem family matched to workload needs | Whether a specialized managed filesystem fits better than generic file storage |
The question behind the service names
The real decision is whether the workload is bottlenecked by:
- storage type
- IOPS or throughput
- the need for shared access
- read locality or caching
- data transfer path into and out of the storage layer
If the prompt describes shared writable access from multiple instances, EBS usually becomes weak immediately. If it describes object retrieval, EFS is usually wrong even if it “stores files.”
Performance patterns to remember
- use EBS when the workload needs attached block storage and consistent instance-level performance
- use EFS when many instances need concurrent shared file access
- use S3 when the workload is object-oriented and benefits from decoupled storage, lifecycle, and event integrations
- use caching when the issue is repeated read pressure rather than raw storage choice alone
Example: tune a gp3 volume for the workload
This is the kind of storage shape SAA-C03 expects you to interpret correctly:
1Resources:
2 AppDataVolume:
3 Type: AWS::EC2::Volume
4 Properties:
5 AvailabilityZone: us-east-1a
6 Size: 500
7 VolumeType: gp3
8 Iops: 12000
9 Throughput: 500
10 Encrypted: true
What to notice:
- the architecture is still using block storage, not a shared filesystem
- gp3 lets you reason about size, IOPS, and throughput separately
- the exam often wants you to choose the right performance profile before you redesign the whole application tier
Failure patterns worth recognizing
| Symptom | Strongest first check | Why |
|---|---|---|
| The database instance is fine but storage latency is poor | EBS volume type, IOPS, or throughput | The bottleneck may be the attached volume, not the instance family |
| Many instances need the same writable filesystem | EBS versus shared file requirement | Shared access usually points away from single-instance block storage |
| Static assets are slow for global users | S3 plus edge path, not only the origin bucket | The issue may be request path and caching, not the bucket’s existence |
| Compute keeps scaling but reads still lag | Cache and storage access pattern | More compute does not fix a bad storage or read-design choice |
Common traps
- choosing EBS where many instances need the same filesystem simultaneously
- choosing EFS when the application is really object-centric
- confusing durability with low-latency performance
- scaling compute before checking whether the storage layer is the real bottleneck
Quiz
Continue with 3.2 Compute Solutions to connect storage choices to scaling and runtime design.