Block Public Access by Default
S3 buckets should generally remain private unless there is a specific requirement for public access.
Enable:
- Block public bucket policies
- Restrict public bucket policies
For applications that need public content, consider using Amazon CloudFront with S3 instead of directly exposing the bucket.
Use IAM for Access Control
Avoid sharing AWS access keys or granting broad permissions such as:
Instead, follow the principle of least privilege.
For example, an application that only needs to upload objects could receive permissions such as:
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
}
This limits the application's access to the required operation and location.
Enable Versioning
S3 versioning helps protect against accidental deletion or overwriting of objects.
For example:
report.pdf
↓
Version 1
↓
Version 2
↓
Version 3
If someone accidentally deletes or overwrites an important object, an earlier version can potentially be recovered.
Versioning is particularly useful for:
Use Encryption
Sensitive data stored in S3 should be encrypted.
Depending on the requirement, you can use:
For workloads requiring centralised key management and detailed access control, AWS KMS can be used with S3.
Example:
Application
|
v
S3
|
v
KMS
|
v
Encrypted Object
Configure Lifecycle Policies
Not every object needs to remain in the same storage class forever.
For example:
Day 0 → S3 Standard
Day 30 → S3 Standard-IA
Day 90 → S3 Glacier
Day 365 → Delete
Lifecycle policies can automatically transition objects between storage classes or delete objects that are no longer required.
This can significantly reduce storage costs for data with predictable access patterns.
Use Appropriate Storage Classes
S3 provides different storage classes for different workloads.
Examples include:
Storage Class | Typical Use |
|---|
S3 Standard | Frequently accessed data |
S3 Standard-IA | Infrequently accessed data |
S3 One Zone-IA | Infrequent access where one AZ is acceptable |
S3 Glacier Instant Retrieval | Archive data requiring rapid retrieval |
S3 Glacier Flexible Retrieval | Long-term archive |
S3 Glacier Deep Archive | Very long-term, rarely accessed data |
Choosing the right storage class is an important part of S3 cost optimisation.
Enable Logging and Monitoring
S3 activity should be monitored, especially for production and sensitive buckets.
Useful AWS services include:
For example, CloudTrail can help identify who performed an operation and when it occurred.
User / Application
|
v
S3
|
v
CloudTrail
|
v
Monitoring / Auditing
Protect Critical Data Against Accidental Deletion
For important backup or compliance data, consider additional protection mechanisms such as:
- MFA Delete where applicable
Object Lock can be particularly useful when data must be protected from modification or deletion for a defined retention period.
Think About S3 Like a Production System
A production-ready S3 design should consider more than just storage.
Think about:
Security → Access → Encryption → Availability → Recovery → Monitoring → Cost
A simple architecture might look like this:
CloudFront
|
v
Application ------> S3
|
+------------+------------+
| | |
Versioning Encryption Lifecycle
| | |
v v v
Recovery KMS Cost Control
Final Thoughts
Amazon S3 is simple to start with, but production-grade S3 requires thoughtful design.
By combining least-privilege IAM, block public access, encryption, versioning, lifecycle policies, monitoring, and appropriate storage classes, you can build S3 architectures that are more secure, resilient, and cost-efficient.
The key principle is simple:
Don't just store data in S3 — design how that data should be protected, accessed, retained, and recovered.
Loading article