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

161–170 of 176 posts

Re: Have lots of AWS accounts

#161

Post by DangitBobby »

psanford wrote: post #159
DangitBobby wrote: post #149

Earlier quoted context omitted.

So the problem is the abstraction is so easy to use to get a project going that people just litter them everywhere... how is that a problem with the platform? At least they are actually in one searchable location. How do you find your production workloads if you have 1000 AWS accounts?

In AWS we divide things up into child accounts that roughly match our org tree. Each team or service gets dev, staging, and prod child accounts. Teams have access to their child accounts and its fairly obvious what they all do, or at least, who to talk to to find out. I think my main complaint with GCP is that it is often tied directly to an org's gsuite account. And doing things in gsuite (used to?) automatically cr…

We haven't seen that gsuite project problem, but we also don't do really color outside the lines with gsuite. Email, chat, docs, AD, etc.

Re: Have lots of AWS accounts

#162

Post by 0xbadcafebee »

DangitBobby wrote: post #148
0xbadcafebee wrote: post #6

Earlier quoted context omitted.

I really dislike the Google Cloud way of doing things, for example Projects, Folders and Orgs. There's a dozen different weird paradigms that you have to consider to securely and reliably manage a large number of different projects, accounts, tenants, business units, etc in Google Cloud; if you don't do things "The Google Cloud Way" you are screwed. AWS is much simpler and more straightforward. You don't have to thin…

AWS is decidely _not_ simpler here. You've got Stockholm syndrome. What's complicated about making two projects and picking between them? What's complicated about grouping projects under a single organization? What's complicated about grouping projects under a folder? What's complicated about adding someone to a project through IAM? The only way you can fuck that last part up is by granting overly broad permissions (…

I think it's the other way around :-)

In Google Cloud, you have to learn all these concepts and use them as Google intends. Oh, you should create a new Project. But to do that you need an Organization. But to do that you need an Identity Source. But you'll need to choose from x or y and have a domain. But... (all this before creating a billing account, or enabling an API, or... ?!)

In AWS, you just have an account. That's it. You can later add-on AWS Organizations if you need to manage a big organization.

AWS is simple and composeable, and GCP is advanced and opinionated. Pick your poison.

Re: Have lots of AWS accounts

#163

Post by moltar »

JoBrad wrote: post #137
pan69 wrote: post #87

Earlier quoted context omitted.

> You move between accounts with AWS SSO (now IAM Federation) - No more password per account The only thing I really hate about this is that it is tied/bound to your browser. If you switch browsers or use an incognito window you have to through the whole dance of setting up your account switching set up. Imagine you're in multiple orgs that are set up this way...

Firefox Containers is a great way to handle this. I usually only need to log into 3 or 4 accounts, max, at the same time. I have AWS Containers 1-4 setup for just that.

I do the same.

Pro tip time!

You can use this ext and accompanying cli tool to launch URLs in a container.

https://github.com/honsiorovskyi/open-url-in-container

Couple that with aws-vault login link generator.

Then pipe thru fzf.

Now you have a quick script to open an aws profile in a new container. Containers don’t even need to exist and can be created on the fly.

I just craft the name like “aws-$profile”.

Re: Have lots of AWS accounts

#164

Post by Aeolun »

scarface74 wrote: post #158
Aeolun wrote: post #127

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. Yeah. So you are saying it’s a great idea for 80% of all companies? > My favourite thing doing is spending 2 days opening support tickets in 10 different accounts to get a limit raised and then tracking the state of all the tickets and limit changes I agree this sucks balls t…

Then don’t do that. There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script. Let me take that back, you have to assume the role in each account using either the autogenerated Organization role or Control Tower role.

> There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script.

You assume I have access to all that. Then there’s the situations in which you request a limit higher than what they’ll automatically give you, and you end up running through 10 support requests :/

Re: Have lots of AWS accounts

#165

Post by solatic »

iLoveOncall wrote: post #23
malcolp wrote: post #21

I love this approach, although I'm yet to work anywhere that does this. I guess the million (thousand?) dollar questios now become where do you draw the boundary across accounts? Presumably there are many bad ways to slice accounts up. And what happens when accounts do need to communicate? I can imagine three major scenarios for cross account permissions: * Cross account iam policies (painful in my experience) * Addi…

> Would love to hear the author's view. Instead you can hear AWS's view, which is to have one account per stage per region per service. I can't find a source but I work for Amazon and this is what was recommended to us by ProServe (the contracting branch of AWS) when we talked with them. I think it's idiotic though (because regions are 100% separated within an account, and it would easily triple the number of account…

> I think it's idiotic though (because regions are 100% separated within an account, and it would easily triple the number of accounts to manage), and so did my team, so we stuck with one account per stage per service.

The benefit to one-region-per-account is for any tool that needs to do broad scanning of an account. Running something like awsnuke is much faster if you know that resources were only ever created in one region, and you know you know this because you have an SCP restricting the account to that one region.

If you have an application that is intentionally multi-region though, sure, feel free to violate that principle if it simplifies management for the application team; just still ensure you have the SCP in place to restrict to only those regions which are needed.

Re: Have lots of AWS accounts

#166

Post by scumola »

I've used AWS for 12+ years. In the old days, we had one jumbo account that we separated by tags for projects and billing. It was a pain.

Then about 5 years ago, AWS suggested that we use the multi-account strategy. I changed jobs and decided to go with Control Tower, AWS Orgs and the multi-account strategy. I spent more time writing automation to supplement and write terraform and python code to build supporting infrastructure to tie accounts together, enable the proper services and networking in all accounts. The automation for build a new account grew and grew and became a behemoth. There's no API for Control Tower and the process of setting up a new account with MFA enabled and all of the bells and whistles enabled is such a pain in the ass that I consider the AWS multi-account strategy not worth it AT ALL anymore I don't care how much it reduces the "blast zone" it's a monumentally stupid idea.

You should try to put all of your eggs into one basket and manage access to your resources inside of IAM instead. Use tags smartly and you'll thank me in the long run.

Re: Have lots of AWS accounts

#167

Post by scarface74 »

Aeolun wrote: post #164
scarface74 wrote: post #158

Earlier quoted context omitted.

Then don’t do that. There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script. Let me take that back, you have to assume the role in each account using either the autogenerated Organization role or Control Tower role.

> There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script. You assume I have access to all that. Then there’s the situations in which you request a limit higher than what they’ll automatically give you, and you end up running through 10 support requests :/

Surely you aren’t administering your AWS accounts clicking around in the console all day? You are responsible for opening tickets for accounts but don’t have permissions to use the CLI within CloudShell?

Re: Have lots of AWS accounts

#168

Post by coredog64 »

Aeolun wrote: post #164
scarface74 wrote: post #158

Earlier quoted context omitted.

Then don’t do that. There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script. Let me take that back, you have to assume the role in each account using either the autogenerated Organization role or Control Tower role.

> There are APIs to both list all of the accounts in the organization and request service limits. It’s a three line bash script. You assume I have access to all that. Then there’s the situations in which you request a limit higher than what they’ll automatically give you, and you end up running through 10 support requests :/

If you don’t feel like writing the three lines, ask your TAM.

Re: Have lots of AWS accounts

#169

Post by coredog64 »

icedchai wrote: post #135
scarface74 wrote: post #116

Earlier quoted context omitted.

Besides, every time you try to create a “least privileged role” to run infrastructure as code, that role has so many privileges it’s easy for mistakes to cause mistakes in your production “environment” that you meant to only affect your dev “environment”. And I know I’m probably preaching to the choir. But one of the misconceptions I have to constantly fight is “we run our Lambdas in a VPC for security reasons”. (Lam…

Yes, I tried arguing with someone that it was actually more secure to run your Lambda without associating it with a VPC. If it doesn't need access to the VPC resources, it shouldn't be "run in" one. What can be more secure than having absolutely no access?

cfn_nag has this as a default security rule. So there’s one place to lay blame.

Re: Have lots of AWS accounts

#170

Post by coredog64 »

scumola wrote: post #166

I've used AWS for 12+ years. In the old days, we had one jumbo account that we separated by tags for projects and billing. It was a pain. Then about 5 years ago, AWS suggested that we use the multi-account strategy. I changed jobs and decided to go with Control Tower, AWS Orgs and the multi-account strategy. I spent more time writing automation to supplement and write terraform and python code to build supporting inf…

Control Tower now has a limited API and it’s reasonable to expect additional capability in the future.

Until then, there’s things like Account Factory for Terraform. Or, if you’re really burned out on Control Tower, you can check out OrgFormation.

Post reply on HN