3 ms·

> In isolation without impacting other engineers due to everyone having their own AWS account. This is super interesting. I'm almost certain they mean AWS keys

> In isolation without impacting other engineers due to everyone having their own AWS account. This is super interesting. I'm almost certain they mean AWS keys (with appropriate IAM permissions etc.,). Otherwise billing, developer onboarding/de-boarding and such quickly go out of control. Back in 2015 at my previous company I had setup two AWS accounts, one for test stack and one for production. That in itself was quite a bit of pain.

l33tman 5y ago
Don't know what they used but you can have linked accounts so the billing part is not a problem. With separat IAM users you can still hurt each other as you share the same space for all the services, unless you make some pretty advanced access control rules I guess.
OJFord 5y ago
I think that refers just to individual testing & feature development, not that different parts of prod get deployed to different accounts. There's (perhaps relatively recently) a 'sub-account' concept that perhaps with billing & {on,de}boarding? (Haven't used it.)
akos-kri 5y ago
Hey, author of the post here! To manage our AWS accounts we use: - AWS SSO hooked up to our Google Workspace: so no AWS access keys exist, everyone has only short-lived credentials (e.g. 24 hours) to access their AWS account. - AWS Organization with consolidated billing: all our bills roll up into one nice invoice! - AWS Control Tower: allows us to deploy guardrails and policies to keep all our AWS accounts secure. We also have a centralized Audit AWS account where all Cloudtrail logs are routed. - AWS Account Factory: to create new AWS accounts that are automatically enrolled and created as part of the right Org Unit. - AWS Cloudformation StackSets: allows us to deploy custom resources to everyone's AWS accounts. Right now we use this to deploy custom roles that can be assumed by developers. Hope that answers your question!
- vishnugupta 5y ago
  Thanks for sharing the context! Looks like AWS have thought about use cases similar to yours and developed features. Will explore it more!
arpinum 5y ago
Use Org-formation to manage AWS accounts as a set of Cloudformation templates. [1] https://aws.amazon.com/blogs/opensource/managing-aws-organizations-using-the-open-source-org-formation-tool-part-1/ https://aws.amazon.com/blogs/opensource/managing-aws-organiz...
rorymalcolm 5y ago
You can trivially resolve this with Organisations now, multi-account is incredibly common even within environments, it's a smart isolation boundary.
- tempnow987 5y ago
  Which I think google does a bit better with their project model, but messes up with crazy permissions that don't let you (easily) edit things and the error messaging can be poor.

l33tman 5y ago

Don't know what they used but you can have linked accounts so the billing part is not a problem. With separat IAM users you can still hurt each other as you share the same space for all the services, unless you make some pretty advanced access control rules I guess.

OJFord 5y ago

I think that refers just to individual testing & feature development, not that different parts of prod get deployed to different accounts. There's (perhaps relatively recently) a 'sub-account' concept that perhaps with billing & {on,de}boarding? (Haven't used it.)

akos-kri 5y ago

Hey, author of the post here! To manage our AWS accounts we use: - AWS SSO hooked up to our Google Workspace: so no AWS access keys exist, everyone has only short-lived credentials (e.g. 24 hours) to access their AWS account. - AWS Organization with consolidated billing: all our bills roll up into one nice invoice! - AWS Control Tower: allows us to deploy guardrails and policies to keep all our AWS accounts secure. We also have a centralized Audit AWS account where all Cloudtrail logs are routed. - AWS Account Factory: to create new AWS accounts that are automatically enrolled and created as part of the right Org Unit. - AWS Cloudformation StackSets: allows us to deploy custom resources to everyone's AWS accounts. Right now we use this to deploy custom roles that can be assumed by developers. Hope that answers your question!

vishnugupta 5y ago
Thanks for sharing the context! Looks like AWS have thought about use cases similar to yours and developed features. Will explore it more!

arpinum 5y ago

Use Org-formation to manage AWS accounts as a set of Cloudformation templates. [1] https://aws.amazon.com/blogs/opensource/managing-aws-organizations-using-the-open-source-org-formation-tool-part-1/ https://aws.amazon.com/blogs/opensource/managing-aws-organiz...

rorymalcolm 5y ago

You can trivially resolve this with Organisations now, multi-account is incredibly common even within environments, it's a smart isolation boundary.

tempnow987 5y ago
Which I think google does a bit better with their project model, but messes up with crazy permissions that don't let you (easily) edit things and the error messaging can be poor.