Design High-Performing Architectures
High-Performance Storage and Hybrid Transfer
CoreSelect scalable storage configuration and hybrid access/transfer from protocol, throughput, IOPS, and growth.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Storage performance questions are solved by honoring protocol and attachment first, then matching latency, throughput, IOPS, concurrency, sharing, and growth. Hybrid designs add a separate decision: ongoing low-latency access versus moving datasets between locations.
Must Know
- S3 is massively scalable object storage; optimize object/request patterns and use parallelism where appropriate rather than treating it like an attached disk.
- EBS is AZ-scoped block storage for EC2. SSD families fit latency-sensitive transactional I/O; HDD families fit large sequential throughput when their workload constraints are met.
- EFS supplies shared elastic Linux file access across AZs; choose its performance and throughput behavior from concurrency and workload shape.
- FSx provides managed file systems with workload-specific protocols and characteristics, including Windows, Lustre, NetApp ONTAP, and OpenZFS families.
- Storage Gateway presents on-premises file, volume, or tape interfaces backed by AWS storage and fits recurring hybrid access with local caching.
- DataSync accelerates and automates online data movement between supported storage locations; it is a transfer service, not a persistent storage interface.
- Start with protocol and failure boundary, then data size/growth, access concurrency, latency, IOPS/throughput, and management priority.
Compare and Distinguish
- S3 vs EBS vs EFS vs FSx: object API, attached block, shared Linux file, and workload-specific file protocol are hard deciding constraints.
- EBS SSD vs HDD: SSD wins for random, latency-sensitive IOPS; HDD wins for eligible large sequential throughput workloads. Do not choose by capacity alone.
- EFS vs FSx: EFS wins for elastic shared Linux NFS; FSx wins when a specific filesystem protocol, feature set, or performance profile is required.
- DataSync vs Storage Gateway: DataSync wins for scheduled or one-time online movement; Storage Gateway wins for an ongoing on-premises storage interface backed by AWS.
- DataSync vs Transfer Family vs Snow Family: choose AWS-managed storage transfer, client-facing SFTP/FTPS/FTP/AS2 endpoint, or offline transfer when the network is impractical.
Scenario examples
- Scenario: A fleet of Linux instances concurrently reads shared content and capacity will grow unpredictably. Think: EFS satisfies shared file semantics and elastic growth.
- Scenario: A database on EC2 needs low-latency random block I/O. Think: choose an EBS SSD family and size performance to demand.
- Scenario: HPC processing needs a high-performance Lustre filesystem linked to S3 data. Think: the workload-specific filesystem points to FSx for Lustre.
- Scenario: A branch office needs local file access while data is backed by AWS. Think: Storage Gateway fits ongoing hybrid access; DataSync fits periodic movement.
Exam traps
- EBS is not a Regional shared filesystem merely because snapshots are durable.
- S3 throughput does not turn it into a POSIX block device.
- Provisioning more IOPS cannot fix the wrong protocol or a network bottleneck.
- DataSync does not provide an on-premises file share after transfer completes.
- Storage Gateway caching does not remove the need to size network connectivity and protect source data.
Key takeaways
- Protocol and sharing semantics eliminate incompatible storage before performance tuning begins.
- Separate latency-sensitive IOPS from sequential throughput.
- Use DataSync to move data and Storage Gateway to present ongoing hybrid storage access.
- Choose a storage model that can grow without coupling capacity to one compute host.
How it works
- EBS exposes block devices to attached EC2 instances and stores data independently from the instance lifecycle.
- EFS and FSx expose managed file protocols to multiple clients according to their filesystem behavior.
- Storage Gateway caches or buffers locally while connecting an on-premises interface to AWS-backed storage.
- DataSync agents or service endpoints transfer and verify data between supported locations.
When to use it
- Use S3 for scalable objects, EBS for attached block, EFS for shared Linux file, and FSx for specific filesystem needs.
- Use DataSync for online transfers and Storage Gateway for recurring hybrid access.
- Use Snow Family when data volume and available network make online movement impractical.
Security and governance implications
- Encrypt data and transport, restrict mount/endpoint access, and protect transfer roles.
- Place storage and clients to meet both failure-boundary and latency requirements.
- Monitor capacity/performance signals and verify backups independently of performance scaling.
Operational and diagnostic signals
- For slow storage, separate client, network, protocol, IOPS, throughput, latency, and hot-object or hot-directory effects.
- For failed hybrid transfers, inspect source permissions, agent/network health, destination permissions, and encryption context.
- For mount failures, verify protocol, DNS, routing, security groups, and file-system policy.
More detail
- Performance includes client concurrency, request size, access distribution, network path, and storage configuration; a single throughput number is rarely the whole design.
- Storage growth can require independent capacity scaling, lifecycle, and monitoring even when the service is elastic.
- Hybrid performance is bounded by on-premises infrastructure and the network path as well as the AWS destination.
Ready for the quiz?
- Which requirement distinguishes EBS from EFS?
- When does an EBS HDD family beat SSD?
- What clue favors FSx over EFS?
- Why is DataSync not a Storage Gateway replacement?
- Which dimensions must be measured beyond capacity?
Related objectives
- D3.1.K1
- D3.1.K2
- D3.1.K3
- D3.1.S1
- D3.1.S2