A design review receives four requirements: a database needs fast block-level access; Linux application servers must share the same file tree; a Windows workload depends on SMB semantics; and customer photographs must survive server replacement with minimal operating effort. Selecting one storage product for all four because it is familiar creates avoidable performance and availability risk. The primary architectural skill is recognizing which data interface and failure semantics the application actually needs.
The AWS SAA-C03 high-performance and cost-optimization domains include object, block, and file storage; hybrid choices; durability; access patterns; and lifecycle policies. The existing S3 storage-class and lifecycle specialist explains when objects move between S3 classes. This treatment starts one level earlier: should the workload use S3 at all, or does it need EBS, EFS, or an Amazon FSx file system instead?
Separate object, block, and file interfaces
Object storage treats data as named objects accessed through service APIs. File storage presents directories, filenames, and shared file semantics through a filesystem protocol. Block storage presents volumes to an operating system, which manages the filesystem and often requires a tight relationship with the compute host. Those are not interchangeable address formats. An application’s assumption that it can rename a file atomically or perform block-device writes cannot be satisfied merely by copying it to an object bucket.
Ask whether the consumer is a web API, Linux process, Windows server, database engine, analytics system, or backup product. Then capture required throughput, IOPS, latency, concurrency, sharing, retention, and failure recovery. These requirements choose the storage model; cost and operational complexity refine the choice after the interface is established.
Use EBS for the attached block-device problem
Amazon EBS volumes provide block storage designed for supported EC2 workloads and instance attachment patterns. A relational database or single-host application may require a normal filesystem and predictable storage performance. Choose an EBS volume type and provisioned performance according to measured throughput and IOPS; a larger gigabyte allocation is not automatically proof that the application has enough I/O capacity.
EBS volume availability is tied to an Availability Zone, so an application that depends on one volume must include backup, snapshot, or other suitable recovery mechanisms. Snapshots can support recovery and new-volume creation, but do not assume that attaching one EBS volume to arbitrary hosts across Zones creates a shared clustered filesystem. For database data, consistency and transaction recovery need to be understood separately from storage durability.
Use EFS when Linux application nodes need shared files
Amazon EFS is a managed elastic NFS file system designed for supported Linux workloads and shared access patterns. Multiple eligible clients can work with one filesystem rather than maintain separately synchronized copies on each EC2 instance. This can simplify shared content, build artifacts, or certain application data. It does not convert every application into a safe multi-writer program: file locking, permissions, latency sensitivity, and application behavior still matter.
Select an EFS storage class, throughput mode, mount configuration, and regional or One Zone option based on resilience and cost requirements. For high availability, verify that compute nodes can reach the appropriate mount targets and that security groups and NFS permissions match intended access. A filesystem may exist and be healthy while a new application node cannot mount it because the source security group or DNS path is wrong.
Choose FSx for protocol-specific or specialized filesystems
Amazon FSx provides managed options for particular file-system workloads, including Windows File Server, Lustre, OpenZFS, and NetApp ONTAP variants. These products address different needs: SMB and Windows integration, performance-intensive file processing, NFS-compatible workflows, or storage-management capabilities. The correct choice follows application protocol and operational requirements, not the word ‘FSx’ alone.
A Windows business application that expects Active Directory integration and SMB shares may be a better candidate for FSx for Windows File Server than EFS. A parallel-processing workload may justify FSx for Lustre and a distinct relationship with S3. Verify the selected FSx deployment mode, redundancy, backups, throughput and scaling constraints before promising it will behave like an existing on-premises file server in every respect.
Choose S3 for durable object data and decoupled consumers
S3 is a strong fit for images, documents, logs, backups, large analytical datasets, and other object-based workflows. Its service API and storage classes allow applications to scale beyond one attached host without operating a shared filesystem. S3 is not a drop-in POSIX filesystem; access patterns requiring frequent small synchronous in-place writes may need redesign rather than simply a different mount command.
Object security is also a separate decision. A bucket policy and public-access analysis can help distinguish who is authorized to retrieve an object. Versioning, replication, Object Lock where appropriate, and lifecycle rules deal with durability, retention and restoration. The most secure object store is not useful if the application cannot retrieve the right object version when an incident occurs.
Compare performance using the application’s real shape
Measure an application’s operation mix. A database with random reads and writes may need a low-latency block volume. A media processing job may benefit from a high-throughput shared filesystem for parallel workers before final output lands in S3. A content-serving application can store durable originals as objects and use CloudFront to cache frequently requested derivatives. These can coexist in one architecture without requiring one storage service to win every comparison.
Distinguish throughput from IOPS. A workload writing a few huge files can have high throughput with relatively few operations; a database doing tiny random reads can have high IOPS and low aggregate megabytes per second. Examine file sizes, directory counts, request parallelism, read/write ratios, and network dependency before attributing a slow application to insufficient EC2 CPU.
Make availability and recovery explicit
Storage must survive the failure events that matter to the business. Ask whether a single instance failure, Availability Zone outage, accidental deletion, ransomware event, or regional disaster is in scope. EBS snapshots, file-system backups, S3 versioning, cross-Region copies, and managed replication have different restore properties. None should be described as a universal backup substitute.
Use actual recovery time and data-loss tolerances. A single-AZ scratch filesystem for reproducible temporary work can be acceptable at lower cost, while a regulated customer document repository requires durable retention and a tested restore procedure. The existing backup and cross-Region recovery specialist explains broader resilience requirements. Storage selection must supply the building blocks that allow that recovery plan to work.
Account for storage bills beyond capacity
Review provisioned IOPS or throughput charges, request costs, lifecycle transition fees, retrieval delays and fees, backup retention, data transfer, and storage class minimum-duration rules where applicable. A cold S3 storage class may look cheap per gigabyte but perform poorly for frequently restored records. An oversized provisioned filesystem can waste money even when the application uses only a small fraction of its capacity.
Simulate the cost of a realistic month with both normal access and one recovery event. Include the operational cost of managing filesystems and patching clients where relevant. A cheaper monthly invoice is not cost-optimized if it introduces an outage the business cannot tolerate or a recovery workflow that depends on someone manually finding an undocumented snapshot.
Test the chosen interface with a failure exercise
Build a minimal proof for each workload, not a one-size-fits-all storage benchmark. Restore an EBS-backed instance from a clean snapshot, remount a shared EFS filesystem from another Availability Zone, validate one representative SMB operation for the chosen FSx option, and retrieve an older S3 object version. Record latency, permissions, failure detection, and the human or automated steps required.
A defensible SAA-C03 answer names why the workload needs a file, block, or object interface; how the AWS service meets the actual performance shape; which failure domains it protects; and what the monthly and recovery costs might be. Choosing among EBS, EFS, FSx, and S3 is not a brand-name quiz. It is a decision about application semantics, measurable workload behavior, and operational responsibility.