Introduction

Write-only access in Amazon S3 usually means a principal can upload objects but cannot list the bucket or read existing objects. This is useful when an application needs to deposit data safely without being able to inspect what is already stored.

What write-only really means in S3

The core permission for uploading an object is s3:PutObject. Read access is typically s3:GetObject, and bucket listing is s3:ListBucket.

A write-only policy therefore grants s3:PutObject on a bucket path while omitting read and list permissions.

That sounds simple, but the effective permissions come from the union of all applicable IAM policies, bucket policies, and sometimes service control policies. If another policy already grants read access, your write-only intent is broken.

A minimal IAM policy example

This policy allows uploads into a single bucket prefix but does not allow reading or listing.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "s3:PutObject",
7      "Resource": "arn:aws:s3:::example-upload-bucket/incoming/*"
8    }
9  ]
10}

Because the resource is an object ARN and the only allowed action is s3:PutObject, the principal can upload to incoming/ but cannot list the bucket contents or download objects.

A bucket policy version

You can also enforce the same rule from the bucket side.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "AllowPartnerUploadsOnly",
6      "Effect": "Allow",
7      "Principal": {
8        "AWS": "arn:aws:iam::123456789012:role/partner-uploader"
9      },
10      "Action": "s3:PutObject",
11      "Resource": "arn:aws:s3:::example-upload-bucket/incoming/*"
12    }
13  ]
14}

This is often useful when the bucket owner wants centralized control over exactly who may upload.

Add security conditions, not just permissions

In practice, write-only uploads often need extra conditions. For example, you may want to require server-side encryption.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "s3:PutObject",
7      "Resource": "arn:aws:s3:::example-upload-bucket/incoming/*",
8      "Condition": {
9        "StringEquals": {
10          "s3:x-amz-server-side-encryption": "AES256"
11        }
12      }
13    }
14  ]
15}

Conditions can also restrict uploads to a prefix, require a specific KMS key, or limit access to requests coming from a trusted VPC endpoint.

Test the policy with the right commands

A good validation flow is to test one allowed action and two denied actions.

aws s3 cp report.csv s3://example-upload-bucket/incoming/report.csv
aws s3 ls s3://example-upload-bucket/
aws s3 cp s3://example-upload-bucket/incoming/report.csv ./report.csv

The upload should succeed. The list and download commands should fail if the write-only policy is actually effective.

Special cases to think about

Some upload workflows need multipart uploads for large files. Those flows may require additional permissions beyond plain s3:PutObject, depending on the client and upload method.

Another subtle point is overwrite behavior. If a principal can upload to a key that already exists, it can overwrite that object without needing read permission. If overwrites are dangerous, combine write-only permissions with key naming rules or application-generated unique object names.

Common Pitfalls

A common mistake is granting s3:PutObject and assuming the user cannot read anything, while another attached policy still grants s3:GetObject or s3:ListBucket.

Another issue is forgetting that bucket listing is controlled at the bucket ARN level, not the object ARN level. Denying or omitting s3:ListBucket requires thinking about the bucket resource separately.

It is also easy to ignore operational needs such as encryption requirements, prefix restrictions, and multipart upload support. A policy can be technically write-only and still unusable in production.

Summary

• Write-only S3 access usually means allowing s3:PutObject but not s3:GetObject or s3:ListBucket.
• Effective permissions come from every applicable policy, not just the one you are editing.
• Restrict uploads to a prefix whenever possible.
• Add conditions for encryption and network boundaries when needed.
• Test with real upload, list, and download commands to confirm the policy behaves as intended.