Amazon Simple Storage Service (Amazon S3) is AWS object storage. It stores files and their metadata as objects inside buckets. Applications upload, retrieve, and manage those objects through the AWS console, APIs, SDKs, or CLI.

Amazon S3 is one service within AWS, the wider cloud platform. This guide focuses on general purpose buckets, which AWS recommends for most use cases and access patterns.

Introduction to Amazon S3

What Amazon S3 stores

An S3 object contains data and metadata. A bucket holds objects, and each object's key names it within that bucket. For example, reports/2026/summary.csv can be an object key. When Versioning is enabled, S3 also assigns a version ID to each stored version. In a general purpose bucket, the slashes are part of the key; the console displays prefixes like reports/2026/ as folders, but they are not separate directories.

Core components: buckets, objects, and keys

A general purpose bucket belongs to one AWS Region. You choose its name and Region when you create it, and neither can be changed later. AWS supports both a shared global namespace and an account regional namespace, where only your account can create names; see AWS's bucket namespace guide. Objects stay in their Region unless you explicitly transfer or replicate them.

Strong consistency and object operations

Amazon S3 provides strong read-after-write consistency: after a successful upload, a later read or list request sees the new object. After an overwrite, a later read sees the new data; after a delete, later reads reflect the deleted state, including a delete marker in a versioned bucket. This makes an extra wait or retry unnecessary just to see a completed write; it does not copy the object to another Region. See AWS's S3 overview and consistency model.

Amazon S3 is one AWS service

AWS provides compute, databases, networking, storage, and other cloud services. Amazon S3 is the object storage service in that larger platform; the names are related, but they do not mean the same thing.

What Amazon S3 is good for

S3 is a good fit when an application needs durable storage for whole objects and can address them by key. Common examples include user uploads, images and video, log files, backup copies, software artifacts, and datasets used by analytics services. S3 stores and serves the objects; it does not run your application or manage database records for you.

Is Amazon S3 a NoSQL database?

A general purpose bucket is object storage, not a relational or NoSQL database: its basic operations address objects by key rather than queryable records. Amazon S3 also offers S3 Tables, a separate bucket type for Apache Iceberg tables that compatible analytics engines can query. Choose the data model that fits the workload; do not treat ordinary object keys as a database index.

Choose a storage class for how data is used

A general purpose bucket can contain objects in different storage classes. If you do not choose a class when uploading an object, S3 uses S3 Standard. Start with the access frequency, required retrieval time, resilience, and retention period:

  • S3 Standard is the straightforward default for frequently accessed data, with direct millisecond access across multiple Availability Zones.
  • S3 Intelligent-Tiering moves eligible objects among access tiers as usage changes. It has per-object monitoring and automation charges; its optional Archive Access tiers require a restore before reading.
  • S3 Standard-IA keeps infrequently read objects immediately accessible across multiple Availability Zones. S3 One Zone-IA also provides immediate access but stores data in one Availability Zone, so use it only when the data can be recreated after a zone loss. Both have retrieval charges, a 30-day minimum storage duration, and a 128 KB minimum billable object size.
  • S3 Glacier Instant Retrieval is for rarely read archive data that still needs millisecond access; retrieval charges, a 90-day minimum storage duration, and a 128 KB minimum billable object size apply. S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive cost less to store, but require a restore before a normal read. Their minimum storage durations are 90 and 180 days, respectively.

Typical restore times differ by archive class. For objects under 250 MB, Flexible Retrieval's expedited option typically takes 1–5 minutes; standard takes 3–5 hours and bulk 5–12 hours. Deep Archive typically takes up to 12 hours with standard or 48 hours with bulk; it has no expedited option. Retrieval charges vary by class and tier, and a temporary restored copy is billed alongside the archive.

S3 Express One Zone is a high-performance, single-Availability-Zone storage class used with directory buckets. It is a specialized option for latency-sensitive workloads, not a class to select for a general purpose bucket. Review AWS's storage class comparison, directory bucket guidance, archive retrieval times, and guidance on restored copies and charges before choosing a class. For a deeper side-by-side comparison, read our guide to choosing an S3 storage class.

Understand the full cost

The storage rate is only part of an S3 bill. Depending on the class and workload, charges can include how much data you store and for how long, requests, retrievals, data transfer, lifecycle transitions, and optional features such as KMS keys or replication. A lower storage price can cost more overall when objects are read often, retained for less than a class's minimum period, or moved in many small transitions. Compare the current prices for your Region on AWS's Amazon S3 pricing page.

Durability and availability measure different things. AWS designs S3 Standard for 99.999999999% annual object durability and 99.99% availability. Durability describes the likelihood that data remains intact; availability describes how often it can be accessed. Neither protects against an authorized or accidental delete, so use recovery controls that match the data's importance. See AWS's S3 durability and availability details.

Keep access private and encryption clear

New general purpose buckets have S3 Block Public Access enabled by default. For private application data, keep its settings enabled at the account and bucket levels. Block Public Access helps prevent public policies or ACLs from exposing data; it does not grant access to your application.

New buckets also default to Bucket owner enforced Object Ownership, which disables ACLs. Use IAM roles and bucket policies to grant only the actions and object keys each workload needs. For policy examples and how S3 evaluates access, see our Amazon S3 access management guide. AWS documents Block Public Access and Object Ownership and ACL defaults.

Encrypt data at rest and in transit

By default, S3 encrypts new object uploads at rest with S3-managed keys (SSE-S3) at no additional charge. Choose SSE-KMS when you need customer-managed key controls and account for its permissions and charges. Use HTTPS/TLS for data sent to S3. Encryption protects data; it does not make a bucket private or grant a principal permission to read it. See AWS's default encryption FAQ.

Start with a private bucket and one object

Create a general purpose bucket

  1. Choose the AWS account and Region where the data should live. For most workloads, create a general purpose bucket.
  2. Keep Bucket owner enforced and all Block Public Access settings enabled.
  3. Leave default SSE-S3 encryption in place unless your requirements call for another key-management setup.
  4. Use an IAM role or user with only the bucket permissions the task needs; do not make the bucket public to test access.

Upload and verify an object

Before using the CLI, confirm that its active credentials belong to the intended account. Replace the placeholders below with a bucket you own, its Region, and a local file you mean to upload:

aws sts get-caller-identity

aws s3 cp ./report.csv s3://YOUR_BUCKET_NAME/reports/report.csv \
  --region YOUR_REGION

aws s3 ls s3://YOUR_BUCKET_NAME/reports/ --region YOUR_REGION

The successful upload is followed by a list request to confirm the object is visible. For a full console and CLI walkthrough, see how to create and verify an S3 bucket.

Protect changes and manage the object lifecycle

Read objects by key

Applications retrieve objects with the S3 API or an SDK; the CLI's aws s3 cp command is useful for basic uploads and downloads. A bucket does not expose its objects as a local filesystem, and a key prefix is not a query over object contents.

Use Versioning and replication with deletes in mind

Versioning is disabled by default. When enabled on a general purpose bucket, it keeps previous object versions after an overwrite. A simple delete adds a delete marker, which hides the current object while earlier versions remain stored and billable. To permanently remove data, delete its versions as well. Versioning can help recover from mistakes, but it does not prevent someone with permission from deleting versions.

S3 Replication requires Versioning on both buckets and asynchronously copies eligible objects to a destination bucket in the same or a different Region. Delete handling depends on the replication rule, so check it before relying on the destination to recover from mistakes. See AWS's S3 Versioning guide and S3 data protection guidance.

Use lifecycle rules carefully

S3 Lifecycle rules can transition eligible objects to another storage class or expire them by age and filters. A new rule can affect existing objects as well as future uploads, so check its scope before applying it to a bucket. For an object whose current version is not already a delete marker, expiration in a versioning-enabled bucket creates a delete marker and retains that version as noncurrent. Add noncurrent-version expiration only when permanent cleanup is intended. Verify retention requirements and class charges before enabling an expiration rule. AWS explains how S3 Lifecycle works and how expiration depends on versioning.

Connect S3 to application services

React to object events with Lambda

An application can use S3 event notifications to invoke a Lambda function when a configured object event occurs. Notifications are delivered at least once, so duplicates are possible, and they can arrive out of order. Make handlers idempotent; for create/delete events that update state for one key, compare the S3 event sequencer when order matters. If a function writes to the triggering bucket, use a separate bucket or filter its trigger to an input prefix to prevent a loop. For example, a function can create a thumbnail after an image upload.

Use S3 with compute and content delivery

Applications on EC2 and other AWS compute services can read or write S3 objects using an attached IAM role. CloudFront can cache content stored in S3 for delivery to users; for private content, use CloudFront origin access control instead of opening the bucket to the public. Analytics services can also read datasets from S3 while S3 remains the storage layer.

Putting the pieces together

Think of S3 as objects addressed by keys inside Region-specific buckets. Choose storage classes by access and recovery needs, keep public access blocked, use least-privilege IAM policies, and understand how versioning and lifecycle rules affect deletes and charges. Then verify the current AWS documentation and Regional pricing against your workload before expanding a test into production data.