AWS storage comes in three access models: object storage reached over an HTTP API (Amazon S3), block volumes attached to a single instance (Amazon EBS), and file systems mounted by many clients at once (Amazon EFS and the Amazon FSx family). This page describes each model, the storage classes and volume types within it, how to protect and cost-optimize the data, and how to choose between them. Figures are as of 2026 and quoted for US East (N. Virginia) where prices appear; check the service pricing pages before relying on them.

Storage models at a glance

flowchart TD
    Start([Where should this data live?]) --> Q1{Accessed through an API<br/>rather than a mounted path?}
    Q1 -->|Yes| Q1a{Tabular analytics<br/>or vector search?}
    Q1a -->|Iceberg tables| TB[(S3 Tables)]
    Q1a -->|Embeddings| VB[(S3 Vectors)]
    Q1a -->|General objects| S3[(S3 general<br/>purpose bucket)]
    Q1 -->|No, needs a file system| Q2{Shared by<br/>multiple clients?}
    Q2 -->|No, one instance| EBS[(EBS volume)]
    Q2 -->|Yes| Q3{Protocol or<br/>workload?}
    Q3 -->|Linux NFS, elastic| EFS[(EFS)]
    Q3 -->|Windows SMB / AD| FSxW[(FSx for<br/>Windows File Server)]
    Q3 -->|HPC / ML training| FSxL[(FSx for Lustre)]
    Q3 -->|NetApp features,<br/>multiprotocol| FSxN[(FSx for NetApp ONTAP)]

Amazon S3

S3 stores objects (data plus metadata) under keys in buckets. There is no directory hierarchy; the / in logs/2026/09/app.log is just part of the key, which the console presents as folders. S3 is designed for 99.999999999% (eleven nines) durability by storing data redundantly across at least three Availability Zones for most storage classes.

Core behavior

Conditional writes let S3 act as a coordination point: several writers can race to create a lock or manifest object and exactly one succeeds, without a separate database.

Bucket types

Table and vector buckets use their own IAM namespaces (s3tables, s3vectors) and always have Block Public Access enabled.

Storage classes

Pick a class by how often data is read and how quickly it must be available.

Points that change the arithmetic:

• The IA and Glacier Instant Retrieval classes bill a minimum 128 KB per object and charge per-GB retrieval; small or frequently read objects can cost more there than in Standard.
• Intelligent-Tiering moves each object between Frequent, Infrequent (after 30 days without access) and Archive Instant (after 90 days) tiers with no retrieval fees. Objects under 128 KB are not monitored and stay in the Frequent tier. It is the safe default when access patterns are unknown.
• Glacier Flexible Retrieval and Deep Archive objects must be restored (RestoreObject) before they can be read, and each archived object carries about 40 KB of billable metadata, so archive large objects or bundles, not millions of tiny files.
• One Zone-IA and Express One Zone keep data in a single AZ and do not survive the loss of that AZ. Use them only for data you can re-create or that is replicated elsewhere.
• Reduced Redundancy Storage is deprecated in practice; AWS recommends against it and Standard is cheaper.

Lifecycle rules

Lifecycle configuration transitions or expires objects automatically. A common pattern for logs, plus two rules every versioned bucket should have:

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    },
    {
      "ID": "expire-old-versions",
      "Filter": {},
      "Status": "Enabled",
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30, "NewerNoncurrentVersions": 3 }
    },
    {
      "ID": "abort-incomplete-mpu",
      "Filter": {},
      "Status": "Enabled",
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket --lifecycle-configuration file://lifecycle.json

flowchart LR
    Put([PUT]) --> Std["Standard<br/>day 0-30"]
    Std -->|day 30| IA["Standard-IA<br/>day 30-90"]
    IA -->|day 90| GFR["Glacier Flexible<br/>Retrieval"]
    GFR -->|day 365| Del([Expired])

Transitions only move data “down” the waterfall toward colder classes, and objects smaller than 128 KB are by default not transitioned, because the per-object overhead would exceed the savings. Use S3 Storage Lens and Storage Class Analysis to find prefixes worth tiering.

Data protection

Access control and encryption

Since 2023 a new bucket is private by default. Keep it that way:

# Account-wide guardrail: no bucket in this account can become public
aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Use SSE-KMS with an S3 Bucket Key instead of the SSE-S3 default
aws s3api put-bucket-encryption --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:111122223333:key/EXAMPLE-KEY-ID"
      },
      "BucketKeyEnabled": true
    }]
  }'

Grant access with IAM and bucket policies, not ACLs. For many consumers of one bucket, S3 Access Points give each application its own policy and optional VPC-only restriction. VPC gateway endpoints for S3 are free and keep traffic from private subnets off NAT gateways, which otherwise charge per GB processed. See Security & Identity for policy evaluation and KMS.

Serving static websites

The S3 website endpoint (aws s3 website) serves only HTTP and requires a publicly readable bucket. The current pattern keeps the bucket private and serves it through CloudFront with Origin Access Control (OAC), which adds HTTPS, custom domains via ACM, caching, and WAF:

flowchart LR
    User([Browser]) -->|HTTPS| CF[CloudFront distribution<br/>ACM certificate, WAF]
    CF -->|SigV4-signed via OAC| B[(Private S3 bucket<br/>Block Public Access on)]

# Build output is uploaded with sync; --delete removes files no longer in the build
aws s3 sync ./dist s3://my-site-bucket --delete
aws cloudfront create-invalidation --distribution-id E123EXAMPLE --paths "/index.html"

The bucket policy allows s3:GetObject only to the cloudfront.amazonaws.com service principal with an aws:SourceArn condition naming the distribution. The older Origin Access Identity (OAI) mechanism is legacy; use OAC for new distributions.

Performance

• Use multipart upload for objects over roughly 100 MB and parallelize parts; the AWS CLI and SDK transfer managers (built on the AWS Common Runtime) do this automatically.
• Use byte-range GETs to read large objects in parallel.
• Transfer Acceleration routes long-distance uploads through CloudFront edge locations.
• For request-heavy analytics, ML training data loaders, and checkpointing, Express One Zone in the same AZ as compute reduces both latency and request cost. Mountpoint for Amazon S3 exposes a bucket as a read-heavy local file system for such workloads (it is not fully POSIX-compliant; for example, existing files cannot be modified in place).

Amazon EBS

EBS provides network-attached block volumes for EC2. A volume lives in one Availability Zone, attaches to an instance in that AZ, and persists independently of the instance. Instance store (local NVMe on some instance types) is faster but ephemeral: its data is lost when the instance stops or terminates.

Volume types

gp3 decouples performance from size: you provision IOPS (up to 500 per GiB) and throughput (up to 0.25 MiB/s per provisioned IOPS) independently, and it is about 20% cheaper per GB than gp2. The top limits need a 160 GiB volume for 80,000 IOPS and 8,000 IOPS for 2,000 MiB/s. Every existing io2 volume became io2 Block Express as of April 2025. The highest io2 figures require a Nitro-based instance, and every instance type also has its own EBS bandwidth and IOPS cap, which is often the real bottleneck.

Changing volumes

Elastic Volumes lets you increase size, change type, or adjust IOPS and throughput while the volume is in use:

aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3 --size 200 --iops 6000 --throughput 250
aws ec2 describe-volumes-modifications --volume-ids vol-0abc123   # wait for "optimizing" or "completed"

Two constraints catch people out: after a modification you must wait six hours before modifying the same volume again, and growing a volume does not grow the file system. Extend the partition and file system inside the guest:

sudo growpart /dev/nvme0n1 1        # if the file system sits on a partition
sudo xfs_growfs -d /                # XFS
sudo resize2fs /dev/nvme0n1p1       # ext4

Volumes cannot be shrunk; to reduce size, copy the data to a new, smaller volume.

Snapshots and encryption

Snapshots are incremental, block-level backups stored in S3 (managed by AWS, not visible in your buckets). Only changed blocks are stored after the first snapshot, yet each snapshot can restore a complete volume.

Volumes restored from a snapshot load blocks lazily from S3 on first read; without Fast Snapshot Restore, a database on a freshly restored volume can be slow until the data is read once (or pre-warmed with fio or dd).

Turn on EBS encryption by default in every Region you use so every new volume and snapshot copy is encrypted with KMS; encryption has no measurable performance cost on Nitro instances.

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 create-snapshot --volume-id vol-0abc123 --description "pre-upgrade" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=purpose,Value=pre-upgrade}]'

Amazon EFS

EFS is a managed NFSv4.1 file system that grows and shrinks automatically. Thousands of EC2 instances, ECS tasks, EKS pods, Lambda functions and on-premises hosts (over VPN or Direct Connect) can mount it concurrently.

Regional file systems with Elastic throughput reach roughly 1 ms read and 2.7 ms write latency, up to tens of GiB/s aggregate read throughput, and 1,500 MiB/s per client when mounted with a recent amazon-efs-utils (2.0 or later) or the EFS CSI driver; other clients are limited to 500 MiB/s. Because every operation crosses the network, EFS is slow for workloads dominated by small-file metadata operations (such as npm install or large Git checkouts) compared with a local EBS volume.

# Mount with the EFS mount helper: TLS in transit and IAM authorization
sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/efs

# /etc/fstab entry
# fs-0123456789abcdef0:/ /mnt/efs efs _netdev,tls,iam 0 0

Access points give each application a fixed POSIX user and root directory within a shared file system, which is how containers and Lambda functions should mount EFS.

Amazon FSx

FSx runs full-featured third-party file systems as a managed service when EFS’s NFS semantics are not the right fit.

Moving and bridging data

Use case reference

Common pitfalls

• Public buckets. Keep account-level Block Public Access on and serve public content through CloudFront. Treat any request to disable Block Public Access as a design smell.
• Unbounded versioning costs. Every overwrite keeps the old version. Pair versioning with NoncurrentVersionExpiration.
• Incomplete multipart uploads. Abandoned parts are billed indefinitely and invisible in normal listings; add an AbortIncompleteMultipartUpload rule.
• Lifecycle transitions of tiny objects. Transition and minimum-size charges can exceed the savings for objects under 128 KB.
• One Zone classes for irreplaceable data. An AZ loss destroys it.
• Root volumes deleted with the instance. Root volumes default to DeleteOnTermination=true; other volumes default to false. Know which you have, and snapshot before terminating.
• Staying on gp2. gp3 is cheaper and faster for almost every volume; migrate in place with modify-volume.
• Instance limits hiding behind volume limits. A 64,000 IOPS volume on an instance capped at 20,000 EBS IOPS delivers 20,000.
• NAT gateway charges for S3 traffic. Add a free S3 gateway endpoint to VPCs with private subnets.

See also

• AWS Hub - overview of all AWS documentation
• Compute Services - EC2 instance storage, Lambda with S3 and EFS
• Databases - managed alternatives to databases on EBS
• Security & Identity - bucket policies, KMS, and data perimeters
• Cost Optimization - storage cost analysis
• Infrastructure as Code - defining storage resources as code