Amazon S3 Security: 7 Ways to Protect Your Cloud Storage
A misconfigured storage bucket can expose sensitive files to unintended users. Learn how S3 Block Public Access, bucket policies, encryption, versioning, logging, and least-privilege permissions help protect data stored in Amazon S3.
Amazon S3 Security: 7 Ways to Protect Your Cloud Storage
Amazon Simple Storage Service (Amazon S3) is widely used to store files, application assets, backups, documents, and data for analytics. Its flexibility makes it useful for everything from personal projects to enterprise applications.
However, storing data in the cloud also introduces an important responsibility: ensuring that only authorized people and applications can access it.
A bucket configured incorrectly can expose files that were never intended to be public. Even when permissions are configured correctly, weak access management or insufficient recovery options can create additional risks.
In this article, we will explore seven practical ways to improve Amazon S3 security and build safer cloud storage configurations.
What is Amazon S3?
Amazon S3 is an object storage service. It stores data as objects inside buckets, with each object containing data, metadata, and a key used to identify it.
For example, an application might store the following objects:
reports/annual-report.pdfimages/profile.pngbackups/database-backup.zipdocuments/invoice-001.pdf
A bucket provides a logical container for these objects. Access can be controlled through mechanisms such as IAM policies, bucket policies, and S3 Block Public Access settings.
The important point is that creating a bucket and uploading a file does not mean that the file should be publicly accessible.
Let's look at the security controls that help protect these resources.
1. Enable S3 Block Public Access
One of the most important S3 security measures is preventing unintended public access.
Amazon S3 provides Block Public Access settings that can be applied at the account and bucket levels. These settings help prevent public access granted through certain access control lists (ACLs) and bucket policies.
For private data, keeping all four Block Public Access settings enabled is generally a sensible starting point.
The four settings address different ways public access could be granted or configured:
- BlockPublicAcls: Blocks new public ACLs and certain changes to existing ACLs.
- IgnorePublicAcls: Causes public ACLs to be ignored when evaluating access.
- BlockPublicPolicy: Blocks attempts to add certain public bucket policies.
- RestrictPublicBuckets: Restricts access to buckets with public policies in specific circumstances.
For most private storage buckets, you should leave these settings enabled unless there is a reviewed, specific requirement for public access.
How to check the setting
- Open the AWS Management Console.
- Navigate to Amazon S3.
- Select the bucket you want to review.
- Open the Permissions tab.
- Find Block public access (bucket settings).
- Review the settings and confirm that public access is blocked when it is not required.
You should also review account-level settings, because they provide an additional layer of protection.
Important: A bucket being marked as private is not a substitute for reviewing all applicable access mechanisms.
2. Follow the principle of least privilege
Not every application needs full control over an S3 bucket.
Consider an application that only downloads profile images. It might need permission to read specific objects, but it does not need permission to delete files or change bucket permissions.
Granting broad permissions increases the possible impact of compromised credentials or application vulnerabilities.
For example, an IAM policy can restrict an application's access to objects in one bucket:
1
2
3
4
5
6
7
8
9
10
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-private-bucket/*"
}
]
}
This policy allows the specified action on objects in the named bucket. It does not independently grant permission to list the bucket, upload objects, delete objects, or change bucket policies.
Replace
my-private-bucket with your actual bucket name before using the policy.Remember that effective access also depends on other applicable policies and authorization controls. Test the complete configuration instead of assuming that one policy determines every access decision.
3. Enable encryption
Data should be protected not only from unauthorized access but also against exposure of its contents.
Amazon S3 supports encryption at rest. S3 automatically applies server-side encryption to new object uploads, using S3-managed encryption keys by default in standard configurations.
Depending on your requirements, you can use:
- SSE-S3: Server-side encryption with keys managed by Amazon S3.
- SSE-KMS: Server-side encryption using AWS Key Management Service (AWS KMS) keys.
- DSSE-KMS: Dual-layer server-side encryption using AWS KMS keys.
SSE-KMS can be useful when you need additional control over key management and auditing of relevant key usage.
Encryption at rest is not a replacement for access control. An unauthorized user who is permitted to retrieve and decrypt an object may still be able to read its contents.
For sensitive workloads, evaluate encryption requirements, key policies, permissions, and compliance obligations together.
4. Use versioning to protect against accidental deletion
Imagine an application overwrites an important report with incorrect data. Alternatively, someone might accidentally delete an object that is still needed.
S3 Versioning helps preserve multiple versions of an object in a bucket.
When versioning is enabled, overwriting an existing object generally creates a new version rather than permanently replacing the previous version. Deleting an object without specifying a version typically adds a delete marker, which can allow an earlier version to be recovered.
This can be useful for:
- Recovering accidentally overwritten files.
- Restoring deleted documents.
- Retaining previous versions of application assets.
- Improving recovery options after certain operational mistakes.
However, versioning does not prevent every form of data loss. Permanent deletion of specific versions remains possible for identities with the required permissions, and stored versions can increase storage costs.
For critical data, combine versioning with appropriate access restrictions, lifecycle rules, and backup or retention requirements.
5. Use bucket policies carefully
Bucket policies are resource-based policies written in JSON. They help define which principals can access a bucket and which actions they can perform.
For example, an organization might need to restrict access to a specific set of trusted identities or enforce particular conditions on requests.
When reviewing a bucket policy, ask:
- Does it grant access to an unexpected principal?
- Does it contain unnecessarily broad actions or resources?
- Does it expose sensitive data to anonymous users?
- Are the conditions appropriate for the intended use case?
- Could the policy conflict with other access controls?
Avoid copying a policy from another project without understanding its effect.
A policy that works for a public website may be completely inappropriate for a bucket containing customer documents or database backups.
AWS IAM Access Analyzer can help identify certain unintended external-access configurations, while policy validation tools can help identify policy issues before deployment.
6. Monitor activity and maintain an audit trail
Access controls reduce risk, but monitoring helps you understand what happens within your environment.
AWS CloudTrail records supported AWS API activity. Its event history can help investigate actions such as changes to bucket policies and other S3 configuration operations.
For example, if a bucket's permissions unexpectedly change, CloudTrail can help you investigate the identity associated with the API request and the time of the event.
Depending on your requirements, you can also use:
- S3 server access logging: Records detailed requests made to a bucket, with delivery and completeness considerations.
- AWS CloudTrail data events: Can record object-level operations, such as relevant object reads and writes, when configured for the appropriate resources.
- Amazon CloudWatch: Can support monitoring and alerting workflows when integrated with relevant log sources and metrics.
CloudTrail management events and S3 object-level data events are different. Do not assume that every object download or upload is recorded in CloudTrail by default; data-event logging must be configured as needed and may incur additional charges.
Monitoring is most effective when you decide in advance which activities are important and what response should follow an alert.
7. Review access and remove unused permissions
Security configurations can become outdated as applications evolve.
A role created for an old deployment might retain permissions long after they are needed. An access key may remain active even though the associated integration has been retired.
Make periodic reviews part of your operational routine.
A practical checklist includes:
- Review IAM users, roles, and policies that can access the bucket.
- Remove obsolete permissions and unused credentials.
- Check bucket policies and access point policies where applicable.
- Review Block Public Access settings.
- Verify encryption and recovery requirements.
- Investigate unexpected access or configuration changes.
- Confirm that logging and alerts cover the events important to your environment.
Where appropriate, IAM Access Analyzer and IAM Access Analyzer policy-generation capabilities can help inform permission reviews. Recommendations should still be validated against the application's actual requirements.
A practical S3 security exercise
If you are learning AWS, try a small exercise in a test account.
- Create a test S3 bucket without uploading sensitive information.
- Verify that Block Public Access is enabled.
- Upload a sample text file.
- Review the bucket's encryption and versioning settings.
- Create a narrowly scoped test identity or role with only the access it needs.
- Verify that the intended operation succeeds and an unauthorized operation is denied.
- Review the relevant CloudTrail events and identify which additional logging settings would be required to capture object-level activity.
Avoid making the bucket public just to test access. You can test authorization using an appropriate authenticated identity and controlled permissions.
When finished, remove unnecessary test resources and permissions.
Final thoughts
Amazon S3 provides flexible storage, but secure storage requires more than uploading files and relying on default configurations.
Start by blocking public access when it is unnecessary, limiting permissions, enabling suitable encryption, and configuring recovery and monitoring controls according to the importance of your data.
The right combination depends on your application's purpose. A public website may need some publicly readable assets, while a bucket containing customer information should generally remain private.
The goal is not simply to store data in AWS. It is to ensure that the right identities can access the right data, for the right reasons, with the ability to detect and recover from mistakes.
If you manage S3 buckets today, choose one and review its permissions, public access settings, encryption, versioning, and logging. A short security review can reveal improvements before they become incidents.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article