AWS Organizations: Centrally Manage Multiple AWS Accounts

I&#x27;m always amazed at how quickly Amazon pushes out new, useful features. I don&#x27;t know if it&#x27;s on their radar, but I think one of the most important things they could incorporate is the concept of a &quot;project&quot; within their console &#x2F; apis.<p>I&#x27;m not saying it&#x27;s not possible to do similar things within the constructs already provided, but if I&#x27;m involved in 10 different projects (or managing them) maybe I want to be able to &quot;toggle&quot; between projects. This way (a) I can simply assign &#x2F; unassign a person to&#x2F;from a project without needing to worry about permissions at a different level. If I&#x27;m a lead programmer on a project I should simply have &quot;project-level&quot; permissions. (b) when I &quot;toggle&quot; to a project I immediately see project-related resources ONLY. No more need to scroll through 10&#x27;s or maybe 100&#x27;s of unrelated resources just to get to what I&#x27;m looking for.

This is excellent, I&#x27;m going to use this to separate production from test environments using separate accounts.<p>Using VPCs, security groups, IAMs, tags, etc. is great, but those are all constructs you have to take care to implement correctly yourself within your deploy scripts. One slip-up and you could accidentally expose environments to each other, or worse make a mistake that deletes or reconfigures resources in an environment you didn&#x27;t intend to. Or an errant process in a test environment could unexpectedly gobble up too many resources, resulting in production being throttled.<p>So separate accounts is the safest isolation approach, but historically there have been drawbacks (this blog post discusses some[1]), like billing is more expensive (due how AWS charges for usage and you won&#x27;t be sharing reserved instances anymore) and I wasn&#x27;t sure how to handle things that need to be cross-environment, like Route53 (DNS). Looking forward to trying this out!<p>[1]: <a href="https:&#x2F;&#x2F;charity.wtf&#x2F;2016&#x2F;03&#x2F;23&#x2F;aws-networking-environments-and-you&#x2F;" rel="nofollow">https:&#x2F;&#x2F;charity.wtf&#x2F;2016&#x2F;03&#x2F;23&#x2F;aws-networking-environments-a...</a>

I have seen numerous companies get burned because they were sharing a single login on AWS. This is a welcome improvement toward practically managing such an important resource for many teams.

Happy to have this as the existing workarounds were less than ideal... (e.g. <a href="https:&#x2F;&#x2F;segment.com&#x2F;blog&#x2F;rebuilding-our-infrastructure&#x2F;#separate-aws-accounts" rel="nofollow">https:&#x2F;&#x2F;segment.com&#x2F;blog&#x2F;rebuilding-our-infrastructure&#x2F;#sepa...</a>)

Nice feature and I know larger companies would love it, but I personally would like to have better grouping ability of assets within the <i>one</i> AWS account. For instance, we have a bunch of servers for one web app, two or three for other apps, a few apps with single servers etc.<p>Not just EC2 here, I am talking about RDS, Elastic Beanstalk, Route 53, CloudFront, DynamoDB, the works. Would be nice if we could define &#x27;stacks&#x27; for each web app and have the on one neat console to work with.<p>(I know there is the concept of &#x27;Resource Groups&#x27;, but that relies on tagging assets, and I don&#x27;t believe tagging extends across all the AWS assets at this stage? I would love for someone to correct me on my assumptions.)

This will be incredibly useful for an agency like scenario. Wish I had access to this 2 years ago!

A (lonely?) example of AWS playing catchup to GCP.

Can an OU easily be transferred to another Organization down the road? For example, if I put a client&#x27;s data in their own S3&#x2F;OU within our AWS account, then they want to assume ownership of that later, can the OU be transferred to their account without much hassle?

There&#x27;s really only a small set of use cases that should actually benefit from this. The vast majority of organizations simply need to use IAM users, which many don&#x27;t.

This is big. So many people were asking for this.

I hope this means that if you want to change your &quot;root&quot; account, this will basically allow that and the new organization account will take over all those responsibilities for the sub accounts.

This is also big as a lot of account limits are on a per account basis.

Can anyone tell me the difference between this and Azure&#x27;s RBAC? Just reading this, they seem to be the same or very similar.

Would it also allow you to delete subaccounts? We&#x27;ve been giving developer accounts to employees, but when they leave the company we have to ask them for the root credentials so we can deactivate that account...

FINALLY! =)<p><a href="https:&#x2F;&#x2F;24.media.tumblr.com&#x2F;426ebe2f8bf2499cac61a0710fb0c43d&#x2F;tumblr_n3jwddkzyk1smcbm7o1_250.gif" rel="nofollow">https:&#x2F;&#x2F;24.media.tumblr.com&#x2F;426ebe2f8bf2499cac61a0710fb0c43d...</a><p>(Don&#x27;t even care about all the downvotes I&#x27;ll get for posting Gif on HN as if it were Reddit).

As usual: better stay away from Amazon!

thank the maker!!