AWS Organizations: Centrally Manage Multiple AWS Accounts | Hacker News Reader

AWS Organizations: Centrally Manage Multiple AWS Accounts

aws.amazon.com

245 pointsmwarkentin53 comments

I'm always amazed at how quickly Amazon pushes out new, useful features. I don't know if it's on their radar, but I think one of the most important things they could incorporate is the concept of a "project" within their console / apis.

I'm not saying it's not possible to do similar things within the constructs already provided, but if I'm involved in 10 different projects (or managing them) maybe I want to be able to "toggle" between projects. This way (a) I can simply assign / unassign a person to/from a project without needing to worry about permissions at a different level. If I'm a lead programmer on a project I should simply have "project-level" permissions. (b) when I "toggle" to a project I immediately see project-related resources ONLY. No more need to scroll through 10's or maybe 100's of unrelated resources just to get to what I'm looking for.

Agreed - that would be much appreciated. Very similar to the "Region" dropdown where you get limited to everything in a specific geography.

I've started tagging resources and doing a filter/sort but it would be much nicer if I could just do it once during a session rather than filtering on each service's screen.

Most use separate accounts for these purposes. You can connect them for credentials, billing, etc., but there's still some friction.

I use one IAM User per project per engineer, all tied to a root account. Since my IAM roles are project specific, the console shows only the resources relevant to the project that the IAM User is allowed to see.

For quick switching between projects on the Console, I use a Chrome user session per project and have them loaded up. [Chrome session is the little icon on the top right corner of browser that has your name on it]

It will indeed will be a cool Console feature to handle multiple IAM User sessions with a drop down toggle like the Region switch.

This is excellent, I'm going to use this to separate production from test environments using separate accounts.

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't intend to. Or an errant process in a test environment could unexpectedly gobble up too many resources, resulting in production being throttled.

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't be sharing reserved instances anymore) and I wasn't sure how to handle things that need to be cross-environment, like Route53 (DNS). Looking forward to trying this out!

[1]: https://charity.wtf/2016/03/23/aws-networking-environments-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.

IAM was already built into AWS, so that's sort of their own fault for not utilizing that feature. Unless you mean this in a different way, but using a single login was not needed in the past. This is a little different. Sorry, but it's true.

I wholeheartedly agree. IAM has been readily available to provision individual users on the AWS accounts for quite some time now. Sharing access to the root account is a bad practice.

Ideally, the root account should have MFA enabled, all root access keys should be deleted, and individual users should have their own usernames provisioned via IAM with the principle of least privilege applied.

Except if you need to use AWS services such as AWIS which requires root account access keys...

Happy to have this as the existing workarounds were less than ideal... (e.g. https://segment.com/blog/rebuilding-our-infrastructure/#sepa...)

Nice feature and I know larger companies would love it, but I personally would like to have better grouping ability of assets within the one 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.

Not just EC2 here, I am talking about RDS, Elastic Beanstalk, Route 53, CloudFront, DynamoDB, the works. Would be nice if we could define 'stacks' for each web app and have the on one neat console to work with.

(I know there is the concept of 'Resource Groups', but that relies on tagging assets, and I don't believe tagging extends across all the AWS assets at this stage? I would love for someone to correct me on my assumptions.)

This would, i think, largely be delivered by the AWS Organisation structure this post is talking about.

Create an account per stack, switch role from your user account into the stack account to do any management.

Ah. Thinking outside the box. That is a neat way to approach it - rather than staying small, we go bigger and utilise the new multi account feature to accomplish. I'll look into this a bit more. If we can maintain the same billing details across accounts, then it could be an easy way of doing what we want. Added bonus I guess is that if one of our web apps gets acquired, it is extremely easy to detach it from our account and move it on.

It looks like part of the setup is to define the consolidated billing account for the whole organisation, then each new account goes onto the bill central.

The existing consolidated billing works pretty well, it's just the initial per-account setup of billing and roles that's been a headache before

Blast radius reduction. Especially when different agencies build systems for the same company.

I think CloudFormation [https://aws.amazon.com/cloudformation/] might be what you're looking for, they even use the term "stack".

At first blush it might seem to have a high learning curve given the verbosity of the syntax to define a stack, but with the launch YAML support, the syntax has become more succinct. Once you use it, you'll wonder how you ever lived without it.

The product page doesn't do it justice, but in short, CloudFormation allows you to:

- Describe the AWS resources you need in a single file (YAML or JSON), this would be your "stack".

- View all the resources provisioned based on your code in a single UI grouped under the "stack" in the CloudFormation console.

- Manage changes to your resources as different versions of the code file, meaning if you update a resource's properties in code, it'll know and update the already provisioned resource.

- You can delete an entire "stack" and be certain that all associated resources are also destroyed.

- When I used it, the coverage of types of resources you can code for was wide and they're continuously adding more.

I recommend trying it out by setting up a simple S3 hosted website using this template http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...

If you're trying to remain cloud-agnostic, then I suggest you also checkout HashiCorp's Terraform [https://www.terraform.io/]. Think of Terraform as a scripting language that compiles into AWS CloudFormation or any other cloud provider.

Thanks for the heads up on CloudFormation. I've just poked around and realise the our Elastic Beanstalk instances all create a stack in there automatically. Seems pretty useful, and I will investigate a little more to see if we can integrate other AWS assets like S3 buckets, RDS servers etc. into each stack for better management.

Save yourself the pain of CloudFormation and check out Terraform.

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

I am in a agency like scenario where all the clients have their own AWS infrastructures (sometimes multiple) and I have to juggle between those all the time. What I really would want is an account picker for myself: the default console login page is terrible and it's barely manageable with LastPass. Switching between incognito windows only goes so far too.

Maybe the new containers feature in Firefox Nightly can be useful for you :)

Hey, that sounds pretty great! Thanks!

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

Context: https://cloud.google.com/resource-manager/docs/creating-mana...

Don't forget S3-IA after we released Nearline. Also all those sudden price drops (particularly [1] the day after [2], and just last week the Glacier one [3] after Coldline [4]).

Everyone wins (or at least consumers of Cloud services) from this competition. So I'm glad to hear it!

Disclosure: I work on Google Cloud.

[1] https://aws.amazon.com/blogs/aws/aws-price-reduction-42-ec2-...

[2] https://cloudplatform.googleblog.com/2014/03/google-cloud-pl...

[3] https://aws.amazon.com/blogs/aws/category/amazon-glacier/

[4] https://cloudplatform.googleblog.com/2016/10/introducing-Col...

Disclosure: I work on Google Cloud.

> Disclosure: I work on Google Cloud.

I think our big clue was when you said "after we released Nearline". ;)

I know you're just joking, but I have honestly considered moving the Disclosure line to the top. Besides, maybe folks in Search and Ads can take pride in Cloud, too ;).

I appreciated the disclosure...I admit I just didn't even know what Nearline is!

My first thought was the mainframe tape robot: https://www.youtube.com/watch?v=RU8wASddKig.

People in Search and Ads consider the Cloud more of a pocket change sized hobby ;-)

Not lonely. GCP is doing several good things. (disclosure: I worked at AWS for 6 years; I think I know the space a bit).

This seems like a small tweak on IAM and consolidated billing which AWS had first, didn't they?

Can an OU easily be transferred to another Organization down the road? For example, if I put a client's data in their own S3/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'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't.

Really large organizations will appreciate this, IAM is not sufficient. Many account limits impact larger orgs, and having to ensure each accounts policies are set right is a trust exercise. It's much nicer to have policy trickle down from the org account (most have the consolidated billing master acct already).

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

I hope this means that if you want to change your "root" 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.

Yeah, I was considering building something that would require more than 50 (100?) S3 buckets. The thought of trying to do it by managing a bunch of independent accounts didn't appeal. I was also wary of infringing some policy by doing that.

For what it's worth, it turns out that GCP doesn't have per account bucket limits.

Isn't the limit on the number of S3 buckets simply a "send us an email and we'll change it" limit?

This was AFAIK one the few hard limits, however this changed in 2015 https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3... where you could request to get more buckets

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

apples and oranges actually. Azure RBAC is great in that you can keep it within the same account. Orgs and accounts means you can never really share resources, nor move them between. Think about what happens if you have a VPC in account A, and a VPC in account B. I want them to talk over internal network inside the VPC. Now I have to setup VPC peering between accounts. Azure RBAC model could let me share one VNET, and simply permission the app resource groups.

I don't know too much about Azure RBAC, but I would suggest a better parallel in the AWS world is IAM, which has a notion of roles to map users to permissions...

Azure RBAC is about controlling access to resources inside an Azure subscription. Subscriptions in Azure can be broken out into Resource Groups which are commonly used for units of deployment. RBAC would restrict a login to a specific set of resource groups and actions (i.e. modify, don't delete).

Azure has a similar account structure for enterprise customers. They get an root level enrollment and then have the flexibility to divide into "departments" and "accounts." Subscriptions live under accounts. Administrators and viewers can be assigned at any level and cost reporting is built into the enterprise portal. Policies cascade from higher levels down into accounts and subscriptions. Policies as JSON files that can control things like restricting regions, services, etc.

Disclaimer: I work for Microsoft and Azure is my focus.

Would it also allow you to delete subaccounts? We'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...

Why are you giving away root credentials when IAM users and policies are available?

It's for the personal AWS accounts of the employees that leave (the sub accounts in consolidated billing). Not the root credentials for our main account.

FINALLY! =)

https://24.media.tumblr.com/426ebe2f8bf2499cac61a0710fb0c43d...

(Don't even care about all the downvotes I'll get for posting Gif on HN as if it were Reddit).

Did she glue her fingers together?

As usual: better stay away from Amazon!

thank the maker!!

Reply on news.ycombinator.com