Design Resilient Architectures
Storage and Data Architecture Foundations
ImportantUse object, file, and block characteristics and purpose-built data services in loosely coupled systems.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Storage protocol and sharing semantics are hard requirements. Selecting the right model prevents an architecture from forcing object storage to behave like a disk, a single-instance volume to become a shared file system, or a relational database to absorb an incompatible access pattern.
Must Know
- S3 stores objects in buckets and scales independently of compute; applications use object operations rather than mounting it as ordinary block storage.
- EBS is persistent block storage commonly attached to EC2 in one Availability Zone; it fits boot volumes and low-latency block workloads.
- EFS provides elastic shared file access for Linux workloads across Availability Zones in a Region.
- FSx provides managed workload-specific file systems when protocol or filesystem compatibility such as Windows, Lustre, NetApp ONTAP, or OpenZFS is decisive.
- RDS/Aurora fit relational transactions and joins; DynamoDB fits key-value/document access at large scale with known access patterns.
- Separate durable state from stateless compute and choose the data store from model, access pattern, sharing, latency, consistency, growth, and failure boundary.
Compare and Distinguish
- S3 vs EBS vs EFS vs FSx: choose object API, instance-attached block, shared Linux file, or workload-specific managed file protocols.
- EBS vs instance store: EBS is separately persistent block storage; instance store is temporary host-attached storage for replaceable data.
- EFS vs FSx: EFS wins for elastic shared Linux NFS; FSx wins when a specific filesystem's protocol or performance behavior is required.
- RDS/Aurora vs DynamoDB: relational schema, transactions, and joins favor relational; predictable key access and horizontal serverless scale favor DynamoDB.
Scenario examples
- Scenario: Many Linux web servers need the same uploaded files. Think: shared file semantics across AZs point to EFS.
- Scenario: An EC2 database needs a low-latency persistent block device. Think: EBS, with performance chosen from workload I/O.
- Scenario: Durable static assets are consumed through APIs and a CDN. Think: S3 object storage decouples assets from compute.
- Scenario: A Windows workload requires native SMB features. Think: choose the relevant FSx family rather than forcing EFS.
Exam traps
- S3 is not an ordinary POSIX block device.
- An EBS volume is not a Regional multi-AZ shared filesystem.
- EFS is not the default choice for Windows SMB semantics.
- A database read replica does not replace choosing the correct storage/data model.
Key takeaways
- Let protocol and access model eliminate incompatible stores first.
- Object, block, and file solve different sharing and attachment needs.
- Purpose-built databases reduce mismatch when access patterns are clear.
- External state enables replaceable compute and independent scaling.
How it works
- Object clients address keys in buckets; block clients read/write device blocks; file clients use filesystem paths and protocols.
- Managed data services replicate and protect data according to service-specific topology, while applications still choose backups and recovery.
- Stateless compute retrieves durable state from shared storage, databases, or caches and can therefore be replaced.
When to use it
- Use S3 for durable objects, EBS for EC2 block devices, EFS for shared Linux files, and FSx for specific file-system compatibility.
- Use relational databases for relational constraints/transactions and DynamoDB for key-oriented serverless scale.
- Use instance-local temporary storage only when data can be recreated.
Security and governance implications
- Encrypt storage and control access at both identity and resource/network layers where supported.
- Keep backup and replication aligned to data criticality.
- Avoid putting secrets or sensitive state on ephemeral or broadly shared storage without controls.
Operational and diagnostic signals
- If a workload cannot mount storage, verify the access protocol before changing network rules.
- If scaling compute causes inconsistent state, check for local files or sessions.
- If performance is poor, separate throughput, IOPS, latency, request pattern, and network path.
More detail
- Durability, availability, and performance are separate properties; confirm each for the selected storage topology.
- Data gravity and coupling increase when compute owns local state. Prefer independent durable services where the workload permits.
- Growth requirements include both capacity and access throughput, not merely current data size.
Ready for the quiz?
- Why is S3 not a drop-in EBS replacement?
- When does EFS beat EBS?
- Which requirement points to FSx?
- What data shape favors DynamoDB over RDS?
Related objectives
- D2.1.K13