Amazon Simple Storage Service (Amazon S3) is AWS object storage. You create a bucket in an AWS Region, then store data in that bucket as objects. An object includes its data and metadata, and applications can work with it through the AWS Management Console, AWS CLI, SDKs, or S3 APIs. Common uses include application files, backups, media, and data for analytics.

To get started, learn how buckets and object keys work, create a private bucket for a test file, and understand the permissions and charges before storing production data.

How Amazon S3 is organized

Most S3 use starts with a general purpose bucket, the standard bucket type for a wide range of storage needs. A bucket belongs to one AWS account and one Region. Its name and Region cannot be changed after creation, so choose both with the application, data location requirements, and users in mind. AWS describes the general purpose bucket model in its Amazon S3 overview.

Bucket names and Regions

In the shared global namespace, a general purpose bucket name must be unique across AWS accounts within its AWS partition. AWS also offers an account regional namespace, a reserved part of the global namespace where only your account can create general purpose buckets. Bucket names can appear in object URLs, so do not put confidential information in them. A bucket's Region determines which AWS Region stores its objects; pick one that fits your application's location, data residency needs, and related AWS services. See AWS's bucket naming rules and namespaces.

Create a bucket for a first test

You can use the S3 console to create a bucket and upload a small test file. For a first bucket:

  1. Open Amazon S3 in the AWS Management Console and choose the Region where the bucket should reside.
  2. Choose a valid, available bucket name. For a shared-namespace general purpose bucket, names are unique within the AWS partition, not just within your account or Region.
  3. Keep Block Public Access enabled and leave the default encryption and Object Ownership settings in place.
  4. Create the bucket and upload a non-sensitive test file.

To verify access, use the object’s Open action in the S3 console or retrieve it with an authenticated AWS CLI command. Signing in to the console does not make the object’s ordinary URL public. New general purpose buckets are private by default. Keep S3 Block Public Access enabled unless you have a specific, reviewed reason to expose content publicly; see AWS’s Block Public Access guidance. For normal application access, grant only the required S3 actions to an IAM role or other intended principal. Do not make a bucket public just to make a test object easy to open in a browser.

Remove test objects when finished so they do not continue to incur storage charges. If versioning is enabled, previous versions can still incur charges after an object is deleted. To delete the bucket, empty it first, including all object versions and delete markers. For a bucket in the shared global namespace, delete it only if no client will keep using its name; another AWS account can reuse the name after deletion. If you need to keep the name, empty the bucket and leave it in your account. See AWS’s bucket emptying guidance and bucket deletion guidance.

Objects, keys, and folders

An S3 object is a sequence of bytes plus metadata such as content type and last-modified time. Its key is its name within a bucket. Together, the bucket and key identify the object; if versioning is enabled, a version ID distinguishes saved versions of the same key.

General purpose buckets have a flat object structure. A key such as reports/2026/summary.csv is one name; the slashes create a prefix that the console displays like folders. Prefixes help organize objects and can be used when granting scoped access, but they are not separate directories or buckets. See AWS's guide to object keys and prefixes.

S3 provides strong read-after-write consistency for object PUT and DELETE operations in every Region. After a successful upload, a later read sees the new object; a read that races with an overwrite returns the old or new object, not a partial object. See the S3 consistency model.

Keep the bucket private and control access

S3's security defaults give a new bucket a safe starting point:

  • Block Public Access: new buckets block public access by default. Keep the settings enabled for private application data. AWS explains how Block Public Access works across account and bucket settings.
  • Object Ownership: new general purpose buckets use Bucket owner enforced by default, which disables ACLs. Manage access with IAM and bucket policies unless a specific integration requires ACLs. See S3 Object Ownership.
  • Encryption at rest: S3 automatically encrypts new object uploads with server-side encryption using S3-managed keys (SSE-S3) at no extra cost. You can choose server-side encryption with AWS Key Management Service keys (SSE-KMS) when you need more control over the encryption key, but it adds KMS permissions and can add request charges. Encryption protects stored data; it does not decide who may read it. See AWS's default encryption guidance.
  • Access in transit: use HTTPS for requests to S3. AWS recommends requiring TLS for requests; see its S3 security best practices. For applications running on AWS, use an IAM role with only the S3 permissions the application needs instead of storing long-term access keys in code.

Access control can involve identity policies, bucket policies, organization rules, and (for SSE-KMS objects) KMS key permissions. For examples of scoped permissions and how those policies work together, see our guide to Amazon S3 access management.

Choose a storage class and understand the bill

Storage class is selected per object. If you do not choose one when uploading, S3 uses S3 Standard. Start there for frequently accessed data or while you are learning the access pattern. A lower storage rate can come with retrieval charges, minimum storage durations, minimum billable object sizes, or a restore delay.

Class or groupCommon fitCheck before choosing
S3 StandardFrequently accessed data or a new workloadGood starting point while you measure usage.
S3 Intelligent-TieringAccess patterns that are unknown or changeMonitoring charges apply to eligible objects; optional archive tiers need a restore.
S3 Standard-IA / One Zone-IAInfrequently read data that still needs immediate accessRetrieval fees, a 30-day minimum, and a 128 KB minimum billable object size apply. One Zone-IA stores data in one Availability Zone, so use it only if that failure boundary fits.
S3 Glacier Instant RetrievalRarely read archive data that must be available immediatelyRetrieval fees, a 90-day minimum, and a 128 KB minimum billable object size apply.
S3 Glacier Flexible Retrieval / Deep ArchiveArchive data that can wait for restorationRestore time, retrieval charges, per-object metadata charges, and 90-day or 180-day minimums affect the total cost.

This is a first-pass guide, not a price comparison. Compare the current options and constraints in our guide to choosing an S3 storage class and AWS's storage class documentation.

Your AWS bill for an S3 workload can include storage, requests such as uploads and downloads, data retrieval, data transfer, replication, and AWS KMS requests. Rates vary by Region and storage class. Check the Amazon S3 pricing page for the Region you plan to use before moving a large dataset. When enabled, versioning can help recover earlier object versions after overwrites or deletes, but those versions continue to use storage until you remove them.

A practical next step

Start with one private bucket and a few representative test objects. Confirm that the intended AWS identity can upload and read them, check the Region and security settings, and watch how the objects are accessed before adding lifecycle rules or selecting a colder storage class. If the data is important, decide separately how you will recover from accidental deletion or a broader outage; durability alone does not define your backup and recovery plan.