Amazon cloud storage: choosing S3, EBS, EFS, and FSx

Amazon cloud storage covers several services with different jobs. Amazon S3 stores objects for applications, backups, and archives. Amazon EBS provides block storage for EC2 virtual machines. Amazon EFS and Amazon FSx provide managed file systems. Choose by how your application reads and changes data, then compare costs, access controls, and recovery requirements.

If you want personal photo backup, start with Amazon Photos instead. AWS storage requires more technical configuration and separate billing. This guide focuses on AWS; our guide to free Amazon storage and photo benefits covers the consumer and introductory offers.

Which Amazon storage service fits your workload?

Start with the interface your software expects. An application written for an object API needs different storage from a database expecting an attached disk or a team application opening shared files. AWS's storage decision guide makes this distinction between object, block, and file storage.

Service	Storage model	Typical starting point	Decision to check
Amazon S3	Objects accessed through APIs	Application assets, backups, data lakes, archives	Storage class, request volume, retrieval and transfer costs
Amazon EBS	Block volumes attached to EC2	Virtual-machine disks and databases	Provisioned capacity, volume performance, snapshots
Amazon EFS	Shared NFS file storage	Linux applications needing shared files	Client compatibility, throughput, Regional or One Zone deployment
Amazon FSx	Managed file-system families	Windows file shares or workloads needing a particular file system	Windows File Server, Lustre, NetApp ONTAP, or OpenZFS

EBS for attached block storage

Amazon EBS gives an EC2 instance volumes that it can use like attached disks. Volume types have different performance and pricing characteristics, so there is no single IOPS limit that describes every EBS configuration. Include snapshots in your backup plan and estimate provisioned capacity, rather than only the space occupied by files.

EFS and FSx for file storage

Amazon EFS supports shared NFS access and grows as files are added. AWS does not support EFS with Windows-based EC2 instances. Regional and One Zone file systems also have different failure exposure; choose deliberately.

Amazon FSx offers Windows File Server, Lustre, NetApp ONTAP, and OpenZFS options. Their protocols, features, and operational requirements differ. For an existing application, list its file-locking behavior, permissions, metadata operations, and client requirements before selecting a replacement. Our guide to cloud file-system architecture explains why those details affect performance.

How Amazon S3 stores data

In a general purpose S3 bucket, an object contains data and associated metadata, and its key identifies it within the bucket. A key such as reports/2026/october.csv uses a prefix that the console displays like a folder. Plan the naming scheme before uploading a large collection: applications depend on those keys.

You can work with S3 through the AWS Management Console in a browser, the AWS CLI, or SDKs. Its object APIs can store images, videos, documents, and other files without provisioning a disk volume. That does not automatically provide desktop synchronization, document editing, or a complete application interface for your users.

AWS documents strong read-after-write consistency for object writes and deletes. A successful upload can be read immediately, but that says nothing about whether an application chose the right file or whether an independent backup exists.

Current upload limits

The old 5 TB object limit is outdated. AWS raised the maximum to 50 TB in December 2025. Upload methods have smaller limits of their own: a single PUT supports up to 5 GB, the console supports up to 160 GB per object, and multipart upload supports up to 50 TB. Check the current upload documentation and use a supported, current transfer client for large objects.

Test a representative file before moving the whole dataset. Compare checksums, confirm metadata, and download the uploaded copy. A completed progress bar is only one part of migration verification.

Choose an S3 storage class by access needs

Storage classes trade off access behavior, location redundancy, and charges. The following groups cover common decisions; consult AWS's storage-class documentation for each class's limits.

Class	When to consider it	Main trade-off
S3 Standard	Frequently accessed objects	General-purpose starting point
S3 Intelligent-Tiering	Uncertain or changing access patterns	Monitoring charges; optional archive tiers require restoration
S3 Standard-IA	Infrequent access that still needs immediate retrieval	Retrieval charges and minimum billing rules
S3 One Zone-IA	Infrequently read, reproducible data or additional copies	Single Availability Zone; not resilient to its loss
S3 Express One Zone	Latency-sensitive object workloads	Directory buckets and single-zone placement
S3 Glacier Instant Retrieval	Rarely read archives needing immediate access	Retrieval charges and minimum billing rules
S3 Glacier Flexible Retrieval	Archives that can wait for restoration	Retrieval speed depends on the selected option
S3 Glacier Deep Archive	Long-term archives with slower recovery needs	Plan for hours of restoration, potentially longer at scale

Durability describes protection against losing stored objects; availability describes access to the service. Neither guarantees that you can recover a file you deleted. In particular, do not treat a single-zone storage class as equivalent to copies across multiple zones.

Check restoration before choosing an archive

Glacier Instant Retrieval objects can be read directly. Flexible Retrieval and Deep Archive objects need a restore request first. AWS's retrieval guidance gives typical timings, including 3–5 hours for ordinary Standard retrieval from Flexible Retrieval and up to 12 hours from Deep Archive. Large datasets and very large objects can take longer. Test the amount you would need during an incident, including the time to transfer it afterward.

What Amazon cloud storage actually costs

A per-GB storage price is one part of the bill. Use the S3 pricing page for your region and class, then account for the workload around it:

• Stored data: current files, retained versions, replicas, and unfinished multipart uploads.
• Requests: uploads, downloads, listing, and lifecycle transitions.
• Retrieval: class-dependent charges for reading or restoring archived data.
• Data transfer: the actual route, destination, and applicable allowances.
• Additional services: monitoring, key management, replication, backup, or a content-delivery service.

For example, a collection downloaded frequently can have a different bill from an archive of the same size. Millions of small objects can also create a different cost pattern from a few large objects. Estimate both a normal month and a full recovery or export, so leaving the service is part of the comparison.

Do not describe uploads as universally free: a transfer-in allowance does not eliminate storage or request charges. Nor does a closer AWS region automatically guarantee a lower transfer price. Check the documented billing path, then measure latency separately.

Free Tier is an introductory offer

As checked on October 12, 2026, AWS advertises USD $100 in credits for eligible new customers and up to $100 more through qualifying activities. The Free plan lasts up to six months or until credits run out. Eligibility, services, and account terms matter; check the current Free Tier FAQ and the expiry shown in your account. Avoid relying on an old promise of a universal 12-month S3 allowance.

A first S3 setup in the AWS Management Console

Use a small, non-sensitive test dataset. Write down who owns the bucket, the expected monthly bill, and who will respond to access or recovery problems before moving production files.

1. Confirm your account and billing terms. Understand Free or Paid status, credit expiry, and the services you will use. Set a budget and assign someone to review alerts.
2. Choose a region and bucket type. For ordinary object storage, begin with a general purpose bucket. Check application location, residency requirements, and regional feature availability.
3. Choose a valid bucket name. Follow AWS's rules and avoid sensitive information in names. General purpose buckets can use the shared global namespace or an account regional namespace; their uniqueness rules differ.
4. Keep access private. Retain Block Public Access and disabled ACLs unless a documented requirement needs a different design. Grant only the actions and paths each application needs.
5. Confirm encryption and recovery settings. Check the encryption configuration, decide whether to enable versioning, and define a separate recovery process.
6. Upload and retrieve a sample. Test the actual application identity as well as an administrator. Check that an unauthorized identity cannot read it.
7. Review cost and cleanup. Inspect the test's usage before expanding it. Remove unneeded test objects and versions, and review lifecycle rules before enabling automatic deletion.

The current bucket naming rules explain account regional namespaces and the risks of releasing a shared global bucket name. Do not assume every bucket name is unique across every AWS partition worldwide.

Protect access, then verify what gets logged

Follow AWS's S3 security guidance: apply least privilege, use IAM roles with temporary credentials for supported application workloads, and require HTTPS. New S3 uploads are encrypted at rest by default. That is server-side encryption, not a claim that only the end user can decrypt the data.

When sharing a private object, a presigned URL can provide time-limited access. Treat the URL as sensitive while it is valid. Choose its scope and expiry carefully rather than making the whole bucket public to share one file.

Logging also needs configuration. CloudTrail does not log S3 data events by default, and enabling them adds charges. Decide which object operations must be recorded, configure the selectors, and test that the expected events appear. Check the logs using a test upload, read, and deletion performed by the relevant identities.

Make recovery a separate design decision

Versioning, replication, and backup solve different problems. S3 replication copies objects asynchronously; its optional Replication Time Control has specific timing commitments. Ordinary replication should not be described as a blanket 15-minute guarantee, and existing objects need their own replication plan.

S3 Object Lock protects specified object versions using retention settings or legal holds. It requires versioning and does not prevent another version from being created under the same key. Choose retention rules carefully and test them outside production before committing important records.

AWS Backup can centralize backup policies for supported resources. Confirm support for the exact service and feature you need, including cross-account or cross-region copies. Then run recovery tests that restore usable data with the credentials and tools your team would have during an outage.

Before moving production data

Choose the service that matches the application's interface, test representative files, and calculate ongoing storage plus recovery and exit costs. Keep a record of access permissions, retention rules, and the person responsible for reviewing them. Expand the migration only after the sample can be read, restored, and removed as intended.