Table of Contents
After mastering how to upload files to Amazon S3, Arjun was feeling confident — until one day, he accidentally made a bucket public.
“Wait… did I just expose everything to the internet?”
He quickly realized that understanding AWS S3 Security was just as important as storing the data itself.
Here’s everything Arjun learned about securing AWS S3 — step by step.
🧱 The Two Main Types of S3 Security
AWS S3 provides multiple layers of security. Arjun learned there are two major categories:
1️⃣ User-Based Security (IAM Policies)
- Controls who (IAM user or role) can access which AWS S3 buckets or objects
- Managed through IAM (Identity and Access Management)
- Used mostly for:
- Users inside your own AWS account
- EC2 instances accessing S3 via IAM roles
2️⃣ Resource-Based Security (Bucket Policies & ACLs)
- Controls what permissions the AWS S3 bucket or object gives to users
- Managed directly on the bucket or object
- Commonly used for:
- Public access
- Cross-account sharing
- Enforcing encryption
🛡️ IAM Policies – Controlling Access by Identity
Arjun had an IAM user who needed to read files from AWS S3. So he attached a policy like this:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket-name/*"
}
✅ Now the user could download objects from the specified bucket.
If the user was an EC2 instance, he’d use an IAM Role instead of attaching policies to an individual user.
📜 AWS S3 Bucket Policies – Controlling Access at the Bucket Level
Arjun learned that AWS S3 Bucket Policies are JSON documents attached to a bucket that define what external users or accounts can do.
Example: Making a Bucket Public
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
✅ This allows anyone on the internet to download files from this bucket.
📘 SAA Tip: Principal: "*" means public access. Use with extreme caution!
🌍 Cross-Account Access
What if an IAM user from another AWS account needs access?
Arjun added a Bucket Policy like this:
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:user/OtherAccountUser" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-shared-bucket/*"
}
✅ Now that user from another AWS account could access the bucket — securely.
📂 Object and Bucket ACLs (Access Control Lists)
Arjun saw ACLs listed in the console, but learned they are:
- An older, less-preferred way to manage access
- Available at both object-level and bucket-level
- Can be disabled, and usually are, in new S3 buckets
✅ Use Bucket Policies or IAM instead of ACLs for modern setups
🚫 Block Public Access — Extra Layer of Protection
To prevent accidental exposure, Arjun discovered AWS provides a “Block Public Access” setting:
- Blocks any public access, even if a policy says it’s allowed
- Can be set at:
- The bucket level
- The entire AWS account
📘 Best practice: Keep “Block Public Access” ON for all production buckets unless you’re intentionally hosting a public website.
🔐 Encryption — Protecting Data at Rest
Arjun also learned that he could enforce encryption for all uploaded files.
Using Bucket Policies, he could deny uploads unless the file is encrypted.
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::secure-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
}
✅ This ensures every object is encrypted using SSE-S3 (Server-Side Encryption with Amazon S3 managed keys).
🧠 When Does an IAM User Get Access?
Access is granted only when:
- ✅ The IAM policy allows it
- ✅ The AWS S3 bucket policy or ACL allows it
- ❌ There is no explicit deny
“It’s like passing through two doors. Both must say ‘yes’, and no one should slam them shut.”
📌 Summary – AWS S3 Security Best Practices
| Feature | Description |
| IAM Policies | Control access based on the user/role |
| Bucket Policies | Control access at the bucket level |
| Cross-Account Access | Use bucket policies to share with other AWS accounts |
| Object ACLs | Legacy method, avoid if possible |
| Block Public Access | Protect against accidental exposure |
| Encryption | Enforce encrypted uploads using bucket policies |
🎯 Arjun’s Final Takeaway
“Storing data is easy — but securing it is what makes you cloud-ready. With IAM, bucket policies, and encryption, I control who can access what, when, and how.”
Now Arjun builds apps with confidence, knowing his data — and his users’ trust — are safe.
🧠 Frequently Asked Questions (FAQ)
1. What is the best way to secure data in AWS S3?
The best way to secure your data in Amazon S3 is by combining IAM policies, bucket policies, and encryption. Use IAM to control who can access your resources, bucket policies to manage permissions at the bucket level, and encryption to protect data at rest.
2. What’s the difference between IAM policies and bucket policies?
IAM policies control access based on the user or role (identity-based), while bucket policies control access based on the resource itself (resource-based). Both must allow access for a user to successfully interact with an S3 bucket.
3. How do I prevent accidental public access to my S3 buckets?
Enable Block Public Access at both the account and bucket levels. This feature overrides any public permissions and ensures your data stays private unless intentionally shared.
4. Should I still use S3 ACLs?
In most cases, no. ACLs (Access Control Lists) are a legacy feature. Modern AWS best practices recommend using IAM and bucket policies instead, as they offer more precise and auditable control.
5. How can I enforce encryption for all S3 uploads?
In most cases, no. ACLs (Access Control Lists) are a legacy feature. Modern AWS best practices recommend using IAM and bucket policies instead, as they offer more precise and auditable control.
6. Should I still use S3 ACLs?
Yes. Use a bucket policy that specifies the external account’s AWS ARN as the principal. This allows secure cross-account access without making your bucket public.
