Live data from Hacker News

Have lots of AWS accounts

src-bin.com

91–100 of 176 posts

Re: Have lots of AWS accounts

#91

Earlier quoted context omitted.

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.

Actually, as of Friday, that’s no longer true. \o/

https://aws.amazon.com/about-aws/whats-new/2022/09/aws-updat...>

Re: Have lots of AWS accounts

#92
post #35

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,…

For phone, what are your thoughts on something like Google Voice instead? For emails, how do you handle email? Outlook/Google Workspace? Something else?

A lot of services block VoIP numbers (including Google Voice), especially if two factor or some sort of verification is involved.

Re: Have lots of AWS accounts

#93
post #66

Multiple AWS accounts is definitely a best practice in larger engineering orgs. We implemented a CloudFormation StackSet to ingest them into our billing tool and lay them out appropriately. This proved to be a very slick solution from AWS so it made me believe that they want their larger customers to use multiple accounts too. If you are smaller I would not recommend it. Many things become a little more difficult, as…

AWS recommends a multi account strategy to help achieve their Well Architected framework. https://docs.aws.amazon.com/whitepapers/latest/organizing-yo...

Re: Have lots of AWS accounts

#94

Earlier quoted context omitted.

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.

This papercut has, as of last week, finally been fixed: https://aws.amazon.com/about-aws/whats-new/2022/09/aws-updat...

Re: Have lots of AWS accounts

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

I'd say application boundaries at a high-level. Your various environments should be completely isolated. For instance, you can split web services at the load balancer level.

Application boundaries tend to mirror org structure so that allows you to scope down team access.

To get a better idea of your architecture, you can create a dependency diagram and look for clusters of things.

As for connectivity, you could go over the internet, use VPC peering, use Transit Gateways, PrivateLinks, or follow a hub/spoke network architecture with a "network account"

If you're using managed services, you can also use things like SNS and SQS to create shareable communication channels for other accounts to use.

Re: Have lots of AWS accounts

#96
post #81

Multiple AWS accounts makes life a living nightmare. We have 38 AWS accounts and it is incredibly difficult to maintain each one of them. IAM and even worse cross account IAM is horrible to author and maintain! Keeping track of resource limits and billing sucks. When using SSO, which we do, you cannot have more than one account open in the same browser at the same time. Use GCP instead, segregate your infra by projec…

You don't need to sso in each and every account, you can just have a user in the main org (or at any point in the org tree that is most appropriate) and assume the role within the account you want to manage.

The browser will only remember the last 5 roles you’ve assumed, so it’s still a pain.

Re: Have lots of AWS accounts

#97
post #71
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.

Totally agree. Defense in depth, security in layers. You're not protecting against just the most elite hackers, you're protecting against mistakes. Mistakes and change are inevitable, they should be in the design.

Re: Have lots of AWS accounts

#98
post #80

Earlier quoted context omitted.

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

AWS recently added the organizations:CloseAccount API (albeit with some caveats discussed elsewhere in this comment tree).

Re: Have lots of AWS accounts

#99

Earlier quoted context omitted.

You don't need to sso in each and every account, you can just have a user in the main org (or at any point in the org tree that is most appropriate) and assume the role within the account you want to manage.

The browser will only remember the last 5 roles you’ve assumed, so it’s still a pain.

That UX is atrocious.

Substrate [1] instead presents you with a list of all your accounts with a link to assume your role in that account in the AWS Console (and parallel tools for assuming that role in a terminal, too).

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

Re: Have lots of AWS accounts

#100

Only if you're gonna use AWS Orgs/AWS Control Tower to help manage everything otherwise it gets wild. Internally, Amazonians also use AWS accounts per "app" basically.

In fact per app per region that the AWS service exists in. My AWS service exists in 24 regions so that is 24 “prod” accounts, 8 “gamma” and 6 “beta” and 1 “alpha” account. Some newer teams go even further. If the app is made out of different micro services, then each micro service gets its own account per region. Typically a medium sized AWS service will have like 30 micro services behind it (not really micro; these tend to hold lots of code and APIs) so that would be 24 regions * 30 micro-service accounts. Tooling is important without which you cannot manage so many accounts.
Post reply on HN