Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Thanks for the valuable inputs Raphael, very helpful.
Separating access to dev/UAT & production based on seniority sounds a bit off-track to me as it'd leave junior colleagues with little understanding of prod architecture & issues + become a blocker if none of the seniors are available.
It can also lead to teams starting up resources in dev/UAT & miss on cleaning them up later, creating high bills in AWS/GCP.
What do you think is a good approach to solve this?
Hi Vinay, I do think this multi-account structure can be improved upon by adding tags on resources and giving devs write permissions for those tagged resources.
PRODUCTION
Junior Dev: Read only, write access only when applicable
Senior Dev: More access
DEV / QA
Junior Dev: Write access to resources with the appropriate tags
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Thanks for the valuable inputs Raphael, very helpful.
Separating access to dev/UAT & production based on seniority sounds a bit off-track to me as it'd leave junior colleagues with little understanding of prod architecture & issues + become a blocker if none of the seniors are available.
It can also lead to teams starting up resources in dev/UAT & miss on cleaning them up later, creating high bills in AWS/GCP.
What do you think is a good approach to solve this?
Hi Vinay, I do think this multi-account structure can be improved upon by adding tags on resources and giving devs write permissions for those tagged resources.
PRODUCTION
DEV / QA
Resource: docs.aws.amazon.com/IAM/latest/Use...
The suggestion of using tags & the shared documentation certainly helps, thank you Raphael!