AWS Storage

AWS storage is not one product or one durability setting. It is a portfolio of storage models, protection tools, and data-movement services.

Start with the interface your workload expects. An application may read objects through an API, address blocks through a device, or share files through a file-system protocol. That first choice narrows the service list quickly.

Then test the choice against scope, latency, throughput, sharing, durability, recovery, security, and cost. A service can store the data correctly and still fail the workload through the wrong access model.

Three storage models

Object storage keeps data as objects in buckets. Each object has a key, content, and metadata. Amazon S3 is the main AWS object store. It fits backups, static assets, archives, data lakes, and application data designed for an object API.

An S3 bucket is not a mounted disk. Applications normally use S3 APIs, SDKs, or transfer tools. Rewriting part of an object is not the same operation as updating blocks in a file system.

Block storage exposes addressable blocks to a host. The host creates a partition or file system and decides how data is organized. Amazon EBS provides persistent block volumes for Amazon EC2. EC2 instance store provides temporary block storage tied to the instance and its host.

Block storage fits boot volumes, databases, and applications that expect a local disk. The attachment and failure scope matter. An EBS volume and its EC2 instance must be in the same Availability Zone.

File storage exposes directories, files, permissions, and a file-system protocol. Amazon EFS provides managed NFS file storage. Amazon FSx provides managed Lustre, NetApp ONTAP, OpenZFS, and Windows File Server options.

File storage fits shared application content, home directories, content management, analytics, and enterprise applications that cannot use an object API directly.

S3 is the object-storage baseline

Amazon S3 stores objects in buckets. General-purpose buckets have regional scope. Most S3 storage classes store objects across at least three Availability Zones. S3 One Zone-IA and S3 Express One Zone keep data within one Availability Zone.

S3 Standard is the default class for frequently accessed data. Infrequent Access classes trade lower storage cost for retrieval charges and minimum-duration rules. S3 Intelligent-Tiering moves objects between access tiers when patterns change. Glacier storage classes target archives and may require a restore before access.

Choose a storage class from measured access frequency, retrieval latency, object size, retention time, and failure requirements. A low price per gigabyte does not guarantee a low total bill. Requests, retrievals, monitoring, early deletion, and data transfer can matter.

S3 Versioning retains multiple versions of an object. It helps recover from accidental deletion or overwrite, but every retained version consumes storage. S3 Lifecycle rules can transition or expire current and noncurrent versions.

Versioning is not a complete backup strategy. Permissions that can destroy every version can still remove the recovery path. Define recovery objectives, isolate backup permissions, and test restores.

EBS is persistent block storage for EC2

An EBS volume behaves like an unformatted block device after attachment. The operating system creates and mounts a file system, or an application uses the device directly.

EBS volumes persist independently from an EC2 instance. They are replicated within one Availability Zone and attach to instances in that same Zone. Snapshots provide point-in-time copies stored through the regional EBS snapshot service.

Volume type is a workload decision:

General Purpose SSD volumes fit a broad range of boot and application workloads.
Provisioned IOPS SSD volumes fit latency-sensitive, IOPS-intensive workloads.
Throughput Optimized HDD volumes fit large sequential workloads.
Cold HDD volumes trade performance for lower cost on less frequently accessed sequential data.

Capacity, IOPS, throughput, queue depth, instance limits, and I/O size interact. Provisioning a faster volume cannot overcome an EC2 instance limit or an application that issues unsuitable I/O.

Use instance store only for replaceable data such as caches, buffers, and scratch space. Its data survives a reboot, but not a stop, hibernation, termination, host failure, or many recovery events.

EFS and FSx solve shared-file needs

Amazon EFS provides elastic NFS file storage. Multiple Linux clients can mount the same file system. Regional EFS file systems use mount targets across Availability Zones. One Zone file systems keep data and the mount target in one Zone.

EFS separates storage classes from throughput modes. Standard storage targets frequently accessed files. Infrequent Access and Archive target colder files. Elastic, Provisioned, and Bursting throughput modes provide different ways to allocate throughput.

EFS is a direct fit for shared Linux file access when you do not need a specific enterprise file-system implementation. It is not supported as a Windows file system.

Amazon FSx is the family to evaluate when the file-system implementation matters:

FSx for Windows File Server provides Windows-native file storage and SMB access.
FSx for Lustre targets high-performance parallel file workloads.
FSx for NetApp ONTAP provides ONTAP features and multiple storage protocols.
FSx for OpenZFS provides managed OpenZFS with NFS access.

Do not select a file service from the protocol alone. Check client operating systems, required file-system features, throughput, latency, availability mode, backup behavior, administration model, and migration constraints.

Protection is a separate design

Durable storage reduces the chance of data loss from infrastructure failure. It does not define the recovery point or recovery time your business needs.

AWS Backup centralizes policy-based backup for supported AWS resources. Backup plans define schedules, retention, and lifecycle behavior. Backup vaults hold recovery points. Cross-Region and cross-account copies can separate recovery data from the source failure boundary.

Native features still matter. S3 Versioning, EBS snapshots, EFS backups, FSx backups, replication, and application-consistent procedures solve different parts of protection. Avoid duplicate protection that adds cost without improving a stated recovery objective.

Test restoration. A successful backup job confirms that a recovery point was created. It does not prove that the application can be restored within its target time.

Moving data is not the same as storing it

AWS DataSync moves file or object data over a network. It supports transfers between on-premises systems, other clouds, and AWS services such as S3, EFS, and FSx. It also verifies data integrity during transfer.

AWS Storage Gateway connects on-premises applications to cloud-backed storage. File Gateway presents file shares backed by cloud storage. Volume Gateway presents iSCSI block volumes. Tape Gateway presents a virtual tape library to existing backup software.

EC2 instance store, EBS, S3, EFS, and FSx are storage destinations. DataSync and Storage Gateway solve movement or hybrid access. AWS Backup coordinates protection. Keep these roles separate in the architecture.

AWS Snowball Edge is no longer available to new customers. AWS directs new customers toward DataSync for online transfer, Data Transfer Terminal for eligible physical transfers, or partner solutions. Data Transfer Terminal is currently limited to AWS Enterprise customers.

A practical selection path

Identify the access model: object API, block device, or shared file system.
Define whether data is persistent, temporary, shared, or replaceable.
Set recovery point and recovery time objectives.
Set throughput, IOPS, latency, concurrency, and request-pattern requirements.
Choose the Region and Availability Zone failure scope.
Define encryption, identity, network, logging, and deletion controls.
Model storage, requests, retrieval, backup, and transfer costs.
Test failure, restore, and migration paths with representative data.

The durable mental model is interface, scope, protection, and movement. Pick the interface the application needs. Match the failure scope to the data. Design protection independently. Then choose how data enters, leaves, and recovers.