Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Have lots of AWS accounts

src-bin.com

Post reply on HN
Print view View original

71–80 of 176 posts

Re: Have lots of AWS accounts

#71

Post by ragona »

gw99 wrote: post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

> poor IAM policy and role modeling

This is a bad take. Making good IAM Roles and Policies is incredibly complicated if you have a complicated account. You WILL get it wrong. This becomes much more tractable if you have reasonable account boundaries between workloads.

If you insist on a single massive account you're fighting against the way that AWS designs the system, and you're gonna have a bad time.

Re: Have lots of AWS accounts

#72

Post by cameronh90 »

gw99 wrote: post #65
cactus2093 wrote: post #62

Earlier quoted context omitted.

> You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. I would flip it around and say that historically AWS has had extremely inconsistent architecture and IAM policy design that can make it very hard, sometimes impossible, to do it the "right way". The nice thing about using separate accounts is you don't have to get into as man…

Historically yes. Your job is to evolve this configuration as security controls improve. It's not a fire and forget process, it's continuous improvement.

Or you can just use multiple accounts, which makes things a whole bunch easier.

Frankly, AWS is just missing a level of abstraction here. Azure has resource groups, Gcloud has projects. An AWS account now is just used instead of those concepts, despite it being heavyweight and awkward to do so.

Re: Have lots of AWS accounts

#73

Post by woojae »

I've seen really stupid things done whenever there are multiple accounts. Very few developers know how to assume a role properly. This leads to assume-role permissions that are too permissive to make things work.

Re: Have lots of AWS accounts

#74

Post by rcrowley »

forgomonika wrote: post #52
gw99 wrote: post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

Is billing aggregation a problem and do you need to open up 10 different support tickets if all the accounts are part of an AWS Organization? As for keeping the number of accounts down, I've seen that blow up significantly if you have someone break into an account or have a disgruntled employee that can get into a single account and wreak massive damage. Or if your software runs in multiple regions and you need to me…

Actually upgrading your Support plan is one of the very, very few things you still need to break into the root of each account to do. However, if you’re big enough you just sign an EDP contract that forces all your accounts onto Enterprise Support anyway.

Re: Have lots of AWS accounts

#75

Post by rcrowley »

zimbatm wrote: post #67
yonixw wrote: post #53

My anecdote on how we do it: - We have AWS Org - Each account has no root IAM and cost/pricing goes through root AWS Org Account - You move between accounts with AWS SSO (now IAM Federation) - No more password per account - AWS SSO standardizes boundaries across account with IAM policies, like eu-centeral-1 only for dev IAM etc. - Inside Account more granular access with IAM Assume Roles - Each account Cloudtrail to…

AWS Control Tower is great to set all of this up. It's basically a layer on top of AWS SSO, AWS Org, Cloudtrail, AWS Config. With some sane default security policies.

Control Tower is cool if the problem is “I need lots of AWS accounts.” Substrate [1] is cool if the problem is “I need to accomplish something and I’m cool with using lots of AWS accounts to do it.”

[1] https://src-bin.com/substrate/>

Re: Have lots of AWS accounts

#76

Post by rcrowley »

felipelalli wrote: post #58

There is a practical problem: AWS has a very restrictive policy for deleting sub-accounts. From: https://docs.aws.amazon.com/organizations/latest/APIReferenc... "You can only close 10% of active member accounts within a rolling 30 day period. This quota is not bound by a calendar month, but starts when you close an account. Within 30 days of that initial account closure, you can't exceed the 10% account closure limit…

This is a bummer, yes. I haven’t looked but I wonder if that 10% is a soft limit.

At any rate, this is a good reason to use accounts for architectural divisions, not teams, and certainly not individual engineers.

Re: Have lots of AWS accounts

#77

Post by Hikikomori »

gw99 wrote: post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

Disagree. Shared accounts may work for a smaller org, but not for larger ones.

If you need multiple accounts for isolation or data protection you can accomplish the same thing with scoped IAM policies, so you can only touch things with the correct tag or name in path, this is hard to maintain and confusing for developers.

When you are large enough there's no avoiding multiple accounts as you run into API limits and hard quotas. The added benefit of having an account per system is that you can have simple IAM policies, essentially : compared to scoped described above.

Networking is simple with shared VPCs, even with hundreds or thousands of accounts. Unclear how this affects egress at all. Don't know about billing but we have an Org with enterprise support, guess that helps. The awslogs cli tool makes it easy to extract logs via cli, just login to each account in its own terminal window or use profiles.

Re: Have lots of AWS accounts

#78

Post by arinlen »

gw99 wrote: post #38

I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task. Every other reason here is because you fucked up. You have poor architecture, poor tagging, poor VPC design, poor IAM policy and role modelling or don't know what you are doing to start with. And some of the stuff doesn't even make…

> I disagree with this perspective. You should have multiple accounts but only if your organisation requires it for isolation or data protection reasons and only enough to perform the task.

I'm not sure where you got your take from. The blog post you're commenting explicitly makes the case for multiple AWS accounts with isolation in mind. In fact, the blog post barely mentions anything beyond isolation. How can you claim you agree and disagree at the same time?

Re: Have lots of AWS accounts

#80

Post by nijave »

cameronh90 wrote: post #72
gw99 wrote: post #65

Earlier quoted context omitted.

Historically yes. Your job is to evolve this configuration as security controls improve. It's not a fire and forget process, it's continuous improvement.

Or you can just use multiple accounts, which makes things a whole bunch easier. Frankly, AWS is just missing a level of abstraction here. Azure has resource groups, Gcloud has projects. An AWS account now is just used instead of those concepts, despite it being heavyweight and awkward to do so.

There's plenty of tools to automate the creation and management of new accounts. The biggest hurdle afaik is there's no automated way to delete an account

Azure also has higher-level subscriptions

Post reply on HN