- Newest
- Most votes
- Most comments
I published the solution with examples to this public repo: https://github.com/zaphodbeeblebrox3rd/working_with_aws
It essentially involves the use of dedicated S3 buckets for each project. Access to the buckets is controlled by IAM policies assigned to the IAM role for each project team.
A set of EventBridge rules with Lambda functions allows the Transcribe jobs to be tagged so that they can be broken down per-project in Cost Explorer.
Unfortunately, Translate does not yet include resource tags in its API. I provided the instructions and code to use that feature if/when it becomes available.
I like Eric's answer. My "answer" is more like thinking outside the box and may not be helpful.
Background
AWS is going to be changing sign-on to make it better. I wonder if this ties to Identity Center. Should you look at Identity center as a possible good long term solution unless you are already using SSO with your account at which point you already know this.
Why Identity Center
- it allows you to make multiple "organizations" that are managed by your Identity center admin.
- you could even use it to merge multiple accounts which I suspect is well beyond what you want/need to do.
- SSO has some cool advantages.
- Identity center is not a simple migration. So unless Identity Center is something you can see for other benefits then skip this crazy idea.
Just a quick update to this. I had some objections on the basis of researcher privacy being somewhat violated by user visibility into the Batch Transcribe and Translate jobs, and needed to remove that in favor of just simple access to S3 and no other access. Also, I ran into some onboarding problems getting new SSO-linked IAM roles for each project so I have users logging in with the same IAM role now. Buckets are being created with appropriate bucket policies dynamically by a lambda function. I can only guess that it will work for any organization that uses Okta for SSO, but it has only been tested in my organization.
In addition to other changes, I balled up everything into one CF stack that can be deployed from Ansible to facilitate version control and rollout across dev, testing, and prod instances. https://github.com/zaphodbeeblebrox3rd/working_with_aws/tree/main/ansible_with_aws/site-playbooks/files
Relevant content
- asked 2 years ago
AWS OFFICIALUpdated 3 years ago
100% agreed. I'm using it for an Org that uses Organizations and SSO, but this allows my department to be a little less dependent on centralized IT and Finance to constantly churn out new accounts. The strategy will work either way regardless of whether Organizations and/or SSO is implemented .