Have lots of AWS accounts

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.<p>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&#x27;t know what you are doing to start with. And some of the stuff doesn&#x27;t even make sense, particularly the point about EKS upgrades (I run three different versions of EKS in the same account).<p>There are many negative effects of multiple accounts including billing aggregation is very difficult, having to dig through several accounts worth of Cloudwatch logs, unexpected egress traffic costs and the overall complexity is much higher. If you have to switch to an org account and set up SSO you then have an administrative cost which is immense.<p>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...

One of the things I love most about google cloud is that &quot;projects&quot; are easy to create and easy to link to other projects.<p>Roles and service accounts can even reference across projects, though I&#x27;m not sure I&#x27;d recommend doing that.<p>No more faffing about with special accounts, passwords and difficult to configure shared VPCs, it all becomes so easy.<p>Even managing the different accounts is difficult without browser extensions such as this one: <a href="https:&#x2F;&#x2F;chrome.google.com&#x2F;webstore&#x2F;detail&#x2F;aws-extend-switch-roles&#x2F;jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en" rel="nofollow">https:&#x2F;&#x2F;chrome.google.com&#x2F;webstore&#x2F;detail&#x2F;aws-extend-switch-...</a>

My anecdote on how we do it:<p>- We have AWS Org<p>- Each account has no root IAM and cost&#x2F;pricing goes through root AWS Org Account<p>- You move between accounts with AWS SSO (now IAM Federation) - No more password per account<p>- AWS SSO standardizes boundaries across account with IAM policies, like eu-centeral-1 only for dev IAM etc.<p>- Inside Account more granular access with IAM Assume Roles<p>- Each account Cloudtrail to a central S3 for audit (Same region pricing works for diff accounts!)<p>- Each account is `project.env` like micro_service1.dev or company1_k8s+s3.prod<p>- That way, we have pricing per project built in where tag support ends (and it do have limits)<p>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&#x27;s kind of a clue from amazon: &quot;pss.. this account soft&#x2F;hard limits is sized for 1 project&#x2F;deployment&quot;<p>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.<p>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.<p>Hope this helps for the curious.

&gt; My favorite way to create a network between all my services hosted in different AWS accounts is to share a VPC from a network account into all my service accounts and use security groups to authorize service-to-service communication. There’s no per-byte tax, zonal architectures are easy to reason about, and security groups work just like you expect.<p>That&#x27;s gold advice. I wish AWS RAM supported more services (like AWS EKS).<p>A small complain: working with AWS SSO is a bit tedious. My current solution is to share my ~&#x2F;aws&#x2F;config with everyone so we all have the same profile names and scripts can work for everyone.

A related problem is multi-cloud orgs trying to copy this advice into other clouds. For example, at $dayjob, the cloud guy is trying to replicate the AWS account structure into Azure, where it&#x27;s largely unnecessary. In Azure the equivalent of an account is a subscription, but then there&#x27;s a second hierarchy level in the form of resource groups. Combined with tagging, this makes it very easy to do internal charge-backs or RBAC.<p>They&#x27;ve even added a feature to redistribute the costs of shared resources: <a href="https:&#x2F;&#x2F;azure.microsoft.com&#x2F;blog&#x2F;simplify-financial-reporting-with-cost-allocation-now-in-preview&#x2F;" rel="nofollow">https:&#x2F;&#x2F;azure.microsoft.com&#x2F;blog&#x2F;simplify-financial-reportin...</a><p>Splitting things across accounts or subscriptions is complex and results in all sorts of strange limitations. For example, some resources can&#x27;t be connected to each other across subscription boundaries, so you have to duplicate them.<p>Another example is Kubernetes (EKS or AKS). The typical thing to do is to create a single cluster with multiple node pools, all in the same account or subscription. Then this is split using namespaces. All of this will be in one account, and can&#x27;t be &quot;associated&quot; with other accounts or subscriptions. The second a shared platform like this is introduced, the fine-grained account model breaks down.

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 project, use cloud identity&#x2F;IAM and keep the head of hair you had in your 20s! You&#x27;ve been warned...

Every serious project I engage on has its own:<p>* domain (obviously)<p>* emails<p>also for every provider I have a different email like (google@domain, twilio@domain, etc...)<p>* credit cards (my bank makes it super easy to just create new ones)<p>* phone no. (I just buy a burner phone)<p>It&#x27;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, the ban hammer will not be able to destroy all my income in one blow.

Here‘s a very detailed step-by-step tutorial on how to realize resource-separation without giving up single sign-on with AWS:<p><a href="https:&#x2F;&#x2F;manuel.kiessling.net&#x2F;2020&#x2F;12&#x2F;29&#x2F;single-sign-on-and-resource-separation-on-aws&#x2F;" rel="nofollow">https:&#x2F;&#x2F;manuel.kiessling.net&#x2F;2020&#x2F;12&#x2F;29&#x2F;single-sign-on-and-r...</a><p>Only one of several ways to achieve that, but one that works really well for me.

I&#x27;ve seen this tried. It required a considerable investment in tooling and people to run it, because the dev teams just want to run their apps and don&#x27;t want to manage accounts.<p>And that&#x27;s just the management complexity -- cross-account network adds a ton of complexity to other stuff, including VPC management, transit gateways, and sometimes DNS.<p>Compared to having fewer accounts, the difference in complexity is enormous.

There is a practical problem: AWS has a very restrictive policy for deleting sub-accounts.<p>From: <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;organizations&#x2F;latest&#x2F;APIReference&#x2F;API_CloseAccount.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;organizations&#x2F;latest&#x2F;APIReferenc...</a><p>&quot;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&#x27;t exceed the 10% account closure limit.&quot;<p>I have create so many accounts that when I had to erase them I was stuck in this stupid limit.

Having multiple accounts reduces the potential blast radius tremendously.<p>Anyone who hasn&#x27;t accidentally deleted &quot;stuff&quot; in the wrong account is someone who hasn&#x27;t been doing production work for long.<p>One big downside is that it makes sharing resources between accounts more difficult...which I suppose might also be an upside, since that dependency needs to be explicit in the various permissions.<p>It also makes tooling more awkward.<p>But, it also allows you to completely automate deployment of consistent environments, providing a IT&#x2F;CI&#x2F;Testing nirvana for not that much work.

AWS gets many things more right, but I think GCP wins on how they handle Projects and Managed Instance Groups for auto-scaling.

Lots of AWS accounts doesn&#x27;t scale. Accounts are heavy items in terms of governance, manageability and cost. On your way to 100 accounts you&#x27;ll be rearchitecting security and networking and will find yourself in a strange limbo of architecture models. Once over 100 you&#x27;ll be drowning in the tech debt of a complex environment with increasing friction.<p>Accounts can be made lightweight by using shared VPC&#x2F;subnets but then you&#x27;ll be in the realm of niche user, hampered by AWS&#x27;s poor support for RAM service support with poor documentation if you plan on using anything off the highway of bread and butter services.<p>IMO a balance needs to be struck with sensible boundaries built on business units or ownership. Shared VPC&#x27;s are inherently unstable and should be avoided where possible. Build a good delegated IAM model and hammer people to use it properly.

I have indeed found that it&#x27;s difficult to silo access to specific resources with AWS IAM.<p>I use these custom policies a lot, which give write access to a specific S3 Bucket [0], and give sending capabilities for a specific SES Identity [1] respectively:<p>[0]<a href="https:&#x2F;&#x2F;koptional.notion.site&#x2F;IAM-Policy-for-select-S3-Access-on-a-single-bucket-1d368c7eb45446b1bd653d1a0425042c" rel="nofollow">https:&#x2F;&#x2F;koptional.notion.site&#x2F;IAM-Policy-for-select-S3-Acces...</a><p>[1] <a href="https:&#x2F;&#x2F;koptional.notion.site&#x2F;IAM-Policy-for-email-sending-on-behalf-of-single-SES-identity-414f02acd0e4496eb994e171a74f3fdf" rel="nofollow">https:&#x2F;&#x2F;koptional.notion.site&#x2F;IAM-Policy-for-email-sending-o...</a>

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.<p>If you are smaller I would not recommend it. Many things become a little more difficult, as others have pointed out. Oftentimes a devops or platform engineering org will paper over these things.

I agree with a lot of this, but it&#x27;s missing any discussion of downsides to having a lot of accounts.<p>Some of these include:<p>* Granting permissions to resources in other accounts is complicated. Even where there is first class support, such as for s3 and kms, it involves multiple steps, and familiarity with confusing terminology.<p>* Using the web console or cli is more complicated. In the cli you&#x27;ll have to manage a bunch of profiles, and probably figure out a way to distribute that aws config to your team. And in the web console, switching between accounts is a huge pain unless you use a third party browser plugin to automate assuming a role (which normally requires knowing the account id). And even then, you need to give that plugin a mapping between names and account ids.<p>* Several products charge per AWS account. Using a lot of accounts can make those products very expensive.<p>* Having to assume a role in another account can complicate code, especially if you may or may not have to assume a role depending on the circumstances.<p>I say this as someone with experience with working with several accounts, and who thinks that we should have more accounts.<p>Even with these downsides, once you reach a certain size or complexity, the benefits outweigh the detriments. But the detriments are still there. I wish AWS did more to make working with a lot of accounts easier.

I&#x27;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.<p>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&#x27;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 <i>such</i> a pain in the ass that I consider the AWS multi-account strategy not worth it AT ALL anymore I don&#x27;t care how much it reduces the &quot;blast zone&quot; it&#x27;s a monumentally stupid idea.<p>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&#x27;ll thank me in the long run.

In my experience, no business is able to shuffle its <i>people</i> around efficiently enough for this choice to make a difference. I can see situations where it would help, and I can see situations where it would absolutely hurt to have multiple accounts.<p>Either way, people politics are going to get in the way more than any decision you make here. You can plan a pretty picnic but you can&#x27;t predict the weather.

&gt; AWS accounts are the most complete form of isolation on offer.<p>Because it&#x27;s a pretty brutal namespace. While I usually wind up with separate accounts for multiple reasons, I strongly prefer to get rbac&#x2F;iam properly implemented in a single account wherever possible.

I love this approach, although I&#x27;m yet to work anywhere that does this.<p>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?<p>I can imagine three major scenarios for cross account permissions:<p>* Cross account iam policies (painful in my experience) * Adding trust policies to enable cross account assuming roles (better but limited) * Limiting cross account policies to specific easy to configure services. E.g. S3 (best option, I&#x27;ve seen but maybe too limited)<p>Would love to hear the author&#x27;s view.

At the company I work they just built their „Landing Zone“ as AWS calls it with all the on-prem connectivity, shared VPCs, Product Catalogs, IAM restrictions to the moon and so on and every team gets their own account linked to that one. It‘s an enormous amount of work to get all of that to work nicely together but when it works it‘s very nice and allows for a great way to partition responsibilities. For smaller deployments I think you will be in a mess pretty fast when you start doing cross-account things without enough planning ahead. But per-project accounts? Sure!

I would argue that the optimal number of AWS Accounts is Zero.

Define “lots.” Because the default limit in AWS is 10 accounts per org.<p>Quota increases can be requested but the default limit tells us what AWS thinks normal usage should be for most use cases.<p><a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;organizations&#x2F;latest&#x2F;userguide&#x2F;orgs_reference_limits.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;organizations&#x2F;latest&#x2F;userguide&#x2F;o...</a><p>Perhaps the author meant “more than one”?

Sorry to ask but...what is an &quot;account&quot; in AWS? From what I read in the comments and the article, it seems to be everything but what I naively consider to be an &quot;account&quot;.<p>Could someone come with some analogy please?

Has anyone here used Control Tower? [0] If so, I&#x27;m curious to hear your experience and whether it&#x27;s worth it.<p>[0] <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;controltower&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;controltower&#x2F;</a>

I&#x27;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.

&quot;Imagine you’re trying to create the kind of isolation necessary to deliver the security, reliability, and compliance that business customers demand in one AWS account.&quot;<p>Got to be my favorite way to describe two nines ever!

Only if you&#x27;re gonna use AWS Orgs&#x2F;AWS Control Tower to help manage everything otherwise it gets wild.<p>Internally, Amazonians also use AWS accounts per &quot;app&quot; basically.

This is one of those cases where the wrong thing gets optimized because of something stupid.<p>...Which is probably fine because that&#x27;s pretty much how it always goes.

This is fascinating.<p>One thing that worries me: billing. If I have six different AWS accounts will I have to update six different places any time my credit card expires?

I am fairly certain this article could either be read as totally serious or complete satire. It works both ways.

This is how AWS runs projects internally. Tons of dedicated, limited scope accounts.

Isn’t that against terms since it activates a free tier credit?

I thought this was an article about having separate compartmented Amazon accounts. So one for shopping, another for Amazon Associates, another for AWS, another for Prime Video and Alexa, etc<p>Does anyone here do this?