Live data from Hacker News

Have lots of AWS accounts

src-bin.com

51–60 of 176 posts

Re: Have lots of AWS accounts

#51
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…

One example of why you might want one account per region:

You regionalize data (eg, US data in the US, EU data in the EU) and you want to be able to show (and enforce) separation for compliance or security reasons. You might even take that further, and have multiple accounts per region to create “cells” that correspond to segments of that region.

Disclosure: I worked on Amazons tax pipelines.

Re: Have lots of AWS accounts

#52
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 meet compliance requirements like GDPR, etc.

Re: Have lots of AWS accounts

#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 a central S3 for audit (Same region pricing works for diff accounts!)

- Each account is `project.env` like micro_service1.dev or company1_k8s+s3.prod

- That way, we have pricing per project built in where tag support ends (and it do have limits)

We came to this structure realization after we saw Azure Resource Groups and Google Projects. We also saw the 5 VPC soft limit AWS has per region and think it's kind of a clue from amazon: "pss.. this account soft/hard limits is sized for 1 project/deployment"

The only problems come from automating stuff, like Route53 records that can point automatically to load balancers in that account or as mentioned in the article, VPC2VPC, although we use serverless stuff like lambda and s3 and experience less of that.

But as time go on we realized, like the VPC example in the article, that those problems forced us to structure our stuff in a more SOLID way, which became a feature for us. Just like moving docker-compose to k8s is not creating app-mesh and ops problem, but REVEALING them. So the solution for the Route53 example is to have a separate subdomain zone in each account for automation and ADDING another account `main_route53.prod` with a root zone pointing to them.

Hope this helps for the curious.

Re: Have lots of AWS accounts

#54
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…

We keep dev/staging/prod in different accounts, and we host some special environments for customers which is in separate accounts as well.

The only reason you want to do these things is for security and liability purposes. They are not an advantage for organizing things, but rather they protect against accidental resource deletion and unauthorized / unintended access.

It’s cumbersome to manage many accounts, but that’s a feature, not a bug: it’s intended to be difficult to switch between accounts, so that you can’t accidentally fat finger the wrong button.

Re: Have lots of AWS accounts

#55
post #32

Every serious project I engage on has its own: * domain (obviously) * emails also for every provider I have a different email like (google@domain, twilio@domain, etc...) * credit cards (my bank makes it super easy to just create new ones) * phone no. (I just buy a burner phone) It's a bit of a PITA but the benefits outweigh the cons. I have a clear understanding of how much each of them costs me, for instance. Plus,…

Which bank is that?

in the US, at least Citi (that i know of) lets you create virtual card numbers.

Re: Have lots of AWS accounts

#57
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…

None of these concerns require multiple accounts. An account is a container for resources and resources do have tangible isolation between them if configured properly and properly delegated credentials should be issued to staff which are specific and limited in capability. Same with assumed roles. Same with VPC configurations.

If you didn't do that, you fucked up. Adding more accounts doesn't guarantee that you didn't fuck up.

And yes you need to open 10 tickets, even if you have enough spend to have a direct line to AWS internal staff with multiple enterprise accounts...

Re: Have lots of AWS accounts

#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."

I have create so many accounts that when I had to erase them I was stuck in this stupid limit.

Re: Have lots of AWS accounts

#59
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…

[deleted]

Re: Have lots of AWS accounts

#60
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…

We keep dev/staging/prod in different accounts, and we host some special environments for customers which is in separate accounts as well. The only reason you want to do these things is for security and liability purposes. They are not an advantage for organizing things, but rather they protect against accidental resource deletion and unauthorized / unintended access. It’s cumbersome to manage many accounts, but that…

They don't really though because in the several systems I've seen configured like that, the same staff have access to all accounts. Accidental deletion and unauthorized access should not be a possibility via policy rather than isolation, because if the former isn't done then the latter will not help. If the client demands it, sure, but charge them for the inconvenience.

The main risk is hitting resource limits which is why I would and do give development teams their own account to cause mayhem in.

Post reply on HN