Automate AWS S3 IAM Setup
Budget: $30 – $250 AUD
I’m preparing AWS for more than 100 business units and need a repeatable way to spin up one S3 bucket per unit, each locked to its own users while an Admin group retains full oversight. Our bucket naming convention is already set, so your templating can reference it directly without inventing new patterns.
Here’s what I need built and delivered:
• Infrastructure-as-Code script runnable inside AWS CloudShell (Bash + AWS CLI or CloudFormation).
• Creation of the buckets themselves plus an Admin IAM group with full access to every bucket.
• For each unit, a new IAM group, a role (if it simplifies least-privilege access), and a user placeholder that inherits permissions only to that unit’s bucket.
• Clear, inline comments and a separate short document explaining why each policy statement, condition, or permission boundary was chosen—especially around the use of aws:PrincipalArn vs aws:username, resource-level permissions, and the decision to attach policies to groups rather than users.
Acceptance criteria
1. Running the script in a clean account from CloudShell completes without manual tweaks.
2. Admin group can read/write across all buckets; a sample business-unit user can only list, get and put objects in its own bucket, and is denied elsewhere.
3. Explanation document is concise yet covers policy-scope choices, use of least privilege, and how the design scales past 100 units with minimal policy bloat.
Documentation and script execution is important
Here’s what I need built and delivered:
• Infrastructure-as-Code script runnable inside AWS CloudShell (Bash + AWS CLI or CloudFormation).
• Creation of the buckets themselves plus an Admin IAM group with full access to every bucket.
• For each unit, a new IAM group, a role (if it simplifies least-privilege access), and a user placeholder that inherits permissions only to that unit’s bucket.
• Clear, inline comments and a separate short document explaining why each policy statement, condition, or permission boundary was chosen—especially around the use of aws:PrincipalArn vs aws:username, resource-level permissions, and the decision to attach policies to groups rather than users.
Acceptance criteria
1. Running the script in a clean account from CloudShell completes without manual tweaks.
2. Admin group can read/write across all buckets; a sample business-unit user can only list, get and put objects in its own bucket, and is denied elsewhere.
3. Explanation document is concise yet covers policy-scope choices, use of least privilege, and how the design scales past 100 units with minimal policy bloat.
Documentation and script execution is important
Related categories:
Linux
Cloud Computing
Amazon Web Services
Ubuntu
Scripting
Security
Cloud Development
DevOps
Automation
Bash