5 Choosing Storage for Common Workloads

Start with the data model

Choose storage by starting with how the application accesses its data: as objects, blocks, or files. Then consider access frequency, latency and throughput requirements, sharing, durability, and total cost—not only the price per gigabyte.

A common design combines services when different parts of an application have different needs. For example, a database might use EBS, shared uploads might use EFS, and backups might use S3 with lifecycle policies that move older objects into archive storage.

Block storage for instance disks

Amazon EBS provides persistent block storage attached to EC2 instances. It is suited to low-latency workloads that need a conventional disk, such as boot volumes and transactional databases. The operating system can format a volume with a file system, or an application such as a database can use it directly. Most volume types are used by one instance at a time; specialized options support some multi-attach use cases.

Choose an EBS volume type and provision its capacity and, where applicable, performance. Capacity and performance choices both matter. Costs depend on provisioned storage and, depending on the volume type, provisioned IOPS or throughput.

File storage shared across clients

Amazon EFS provides file storage accessed through NFS and mounted in a file-system directory. Multiple supported clients can access the same file system, making EFS a fit for Linux-based workloads that need ordinary file and directory semantics. Common uses include shared application files, home directories, content shared across instances, and workloads requiring a common file system.

Throughput and latency depend on the storage class and throughput mode. Standard is suited to frequently accessed files needing lower latency. Less-frequently accessed files can use IA or Archive classes, which trade access characteristics for lower storage cost. EFS cost depends on the amount of data in each class and the throughput configuration.

Object storage for accessible data

Amazon S3 stores whole objects in buckets. Applications read and write objects through APIs, and objects can include metadata. S3 scales to large datasets and is accessed through network APIs; it is not a mounted disk or a conventional shared file system. It is suited to broadly accessible, read-heavy data and to objects such as images, backups, logs, data-lake data, media, static website assets, and application data.

Choose an S3 storage class based on how often objects are accessed and how quickly they must be available. Standard suits frequently accessed objects. Cost varies with storage class, request volume, retrieval, and data transfer. Cooler tiers can reduce storage cost but may add retrieval charges or delays.

Archive objects with retrieval trade-offs

S3 Glacier archival classes are object storage classes within S3, not a separate file system. Objects remain in S3, but some classes require restoration before ordinary access. Choose an archive class according to the required retrieval time: Glacier Instant Retrieval supports access in milliseconds, while colder archive options can take minutes to hours or longer. Glacier Flexible Retrieval and Deep Archive are for data that is not available for real-time access and must be restored.

These classes suit long-term backups, compliance records, and historical data that is rarely accessed. Storage is designed to be low-cost, but retrieval fees, restore requests, minimum storage durations, and early deletion charges can affect the total cost.

Match access and performance needs

Match the application's expected interface to the storage service:

• Choose EBS when software expects a disk, such as a database writing to a block device.

• Choose EFS when software expects files and directories, especially when multiple compute instances need access to the same files.

• Choose S3 when the application stores and retrieves objects such as images, backups, or log files rather than requiring a mounted disk.

• Choose an S3 Glacier storage class when the data is object-shaped and can tolerate an archive tier's access pattern.

Then match performance to the workload. For EBS, select a volume type based on the application's IOPS and throughput needs. For EFS, select a storage class and throughput mode that fit the access pattern. For S3, select a class based on access frequency and required availability time.

Compare total cost

Compare the full expected access pattern rather than storage rates alone:

• EBS: Estimate how much capacity and performance must be provisioned.

• EFS: Consider how much data is stored in each class and the throughput the workload needs.

• S3: Account for the storage class, request volume, retrieval, and data transfer.

• Archive classes: Consider retrieval frequency, restore delay, retrieval fees, and minimum storage duration.

A cold archive tier may have a lower storage rate but cost more overall if data is retrieved frequently. Keeping rarely accessed data in a high-access tier can also be unnecessarily expensive. Check current regional pricing and model expected usage before committing.

Apply the choices to workloads

Apply the data-model, access, and performance criteria to these common workloads:

• A relational database on one EC2 instance needs a persistent disk with consistent, low-latency access: Use EBS. The database needs block storage presented as a disk; select a volume type sized for its capacity and performance requirements.

• Several Linux web servers need to read and update the same set of user-uploaded files: Use EFS because the central requirement is shared file-system access across multiple instances.

• A media site stores images and serves them through application or web integrations: Use S3 because images are objects suited to scalable object storage; choose a class appropriate to access frequency.

• A company retains backups for years, expects very few restores, and can wait to retrieve them: Use S3 Glacier Deep Archive, or another suitable archive class if retrieval requirements differ. Slow retrieval is an acceptable trade-off in this scenario.

• An application stores frequently updated transaction records in a database and keeps periodic backup copies: Use EBS for the live database and S3 for backups. Backup copies can transition to an archive class as they age.

• A team needs a shared project directory, but most files are seldom opened: Use EFS with lifecycle management to IA or Archive if the workload and retrieval expectations fit. Archiving objects in S3 would not by itself provide the same mounted file-system interface.

• lifecycle policy