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 sense, particularly the point about EKS upgrades (I run three different versions of EKS in the same account).
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.
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...
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.
I'm not even sure at what point account boundaries really have merit anymore past organization. Most things that are subject to account boundaries have really poorly crafted IAM roles or policies somewhere. You just have a single logical boundary in between the two talking things.
The way that GCP organizes various different projects is actually really nice. I haven't seen what this looks like at scale though.
> 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 many of the hairy weeds and the permissions you end up might end up being much simpler to create and then also to maintain down the road, since everything is isolated by default and then you allowlist only the things you need.
I don't see why you would frame this as "you fucked up" in your design.
Even if it only protects you from fuck ups, isn't that part of good design? People WILL make mistakes, limiting the blast radius of a fuck up is important.
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
It does, but account creation is kind of slow, and the whole control tower / SSO / etc. stuff is fairly janky. Clearly Amazon have been trying to make the account a more common level of isolation for some time and it's improving, but it's still not fantastic. Support also still has a minimum monthly pricing and isn't cross-account.
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.
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.
The places I've worked just control that with SSO and groups in their auth system. Much easier to make a group in your auth software than try to create multiple permission boundaries in the same AWS account. It also makes cost allocation much easier (you don't need complicated tagging policies everywhere)
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.
I worked with one of those tag based accounts a few years ago. Incredibly frustrating because it was locked down to the point you couldn't see the IAM policies and figure out what tags or metadata you were missing.
You’re absolutely right, I’ve fucked up plenty. That’s why I believe so strongly in making the right thing the easy thing. I think I’m doomed if it’s critical for tags to be perfect because they always drift, doomed if IAM policies must be least-privilege because sometimes that’s impossible, and doomed if I can’t adapt what I built yesterday to what my business needs today.
PS good job partitioning your EKS clusters, even within one account. That’ll save you some sleep one day, I’m sure.
> Every other reason here is because you fucked up.
No. Just No.
This is a guardrail against fucking up. And everybody needs more of those.
The only thing missing that would make this the best thing ever, is AWS having a limit on how much cost an account can generate. But they love making money of people's mistakes, so you can never prevent the infinite downside.
Having things “in a VPC” doesn’t help unless you are just using AWS as a glorified Colo. Once you start using AWS native services - many of which aren’t in a VPC, VPC isolation doesn’t help.
Each AWS account also has its own service limits and quotas. One out of control Lambda in the dev “environment” can impact production.
And you don’t have to open support tickets manually. There are APIs to request service limits and you can monitor the progress programmatically.
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”. (Lambdas are never “run in” a customer VPC)
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?
There's definitely a place for these counterarguments, but I have had Amazon's own consultants tell me that quota issues are exactly the reason they think you should architect to span many Amazon accounts if you're big. There are some quotas they simply can't raise as high as you want them on a per-account basis.
The main counter to this is account limits. For example we had our staging and live environments in one account. We load tested on staging (which has its own VPC) expecting it not to affect production. But because we hit account limits in the process of load testing, production Lambdas stopped responding as we exceeded the account limits.
We now have a Control Tower setup to ensure that anything we do to staging can never take down production, even if it's an account limit breach.
> 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?
> 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
> 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?
Are you suggesting having 2+ copies of your infra so that you can withstand losing one of them? I've never heard anybody propose this approach before.
> If you want to build a _reliable_ infrastructure, the only rule is to avoid singe point of failure. Account is one of those.
I'm not sure which sense of the word "reliable" you're using here. Usually durability / continuity of business conversations focus on having backups in other accounts (on same or different IaaS providers).
Availability conversations are usually centered around multi-region within a single IaaS provider, and that can be in a single account. Sure, you could build it to use multiple accounts, and you might pat yourself on the back if it ever actually saves you, but how long would it take to build that and what else could you have done with that time?
> I've never heard anybody propose this approach before.
Some people do, some people just talk. Noone proposed don't mean noone did.
> Usually durability / continuity of business conversations focus on having backups in other accounts
That's quite poor quality of conversations then. Continuity of business is much wider than having backups.
> how long would it take to build that and what else could you have done with that time?
Lesser than you may have expect. What could you have done with your time is certainly a good question, the best asked when your infra is down because cloud provider blocked your account. As I mentioned in original comment, if you ignore probability of that, then you are just not experienced enough.
> 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...
Counter intuitively, a single or small N of accounts makes this more likely. With many, have fun, take the safety bars off, it is contained.
You need multiple accounts, and that has always been the best practice: [1] and [2].
Where are you keeping your Cloudtrail logs? On a Bucket on the same account!!?
That is the first thing that will be wiped out, in case of a security compromise of the role, or user, that set it up.
You can also, and should, use AWS Organizations for consolidated billing [3].
Even without AWS Organizations, with a single account, particularly at an Enterprise level, you are just a step away from loosing everything. And the reason why you might loose everything, has nothing to do, with the best practice of only using the root user, (with MFA) only for the very few required tasks that force you to use the root user. [4]
One possible scenario, is if for example, the persons that have acess to the root user credentials, ( and there always be some...) are going rouge, blackmailed, or getting compromised in another way. All gone, including your remote backups in other regions...
S3 Object Lock [5] will mitigate the risks of a compromised root user but don't use only one account. Have more than one, even for your personal projects.
If there's one thing that is true in this world, it's that you can't rely on people not fucking up.
All you can do is try making fuckups difficult by figuring out how to implement systems where doing the right thing is the path of least resistance. You won't stop fuckups, but a system where people will do the right thing 90% of the time instead of 50% is so much better.
> 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...
Oh. So, you fucked up too? Because all that should be automated.
One other motivation would be a fully functional backup so your product keeps running when they arbitrarily disable your first account (bonus if it's on a whole other provider).
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.
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.
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...
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 think about anything to segregate infrastructure, networks, applications, users, data, etc. Just put it in a different account. If someone needs access, you need to explicitly add extra connections/grant that access. You can't just accidentally create one user that implicitly has access to hundreds of accounts.
Honestly the entire security model of Google Cloud is frightening. It's like they wanted to make it easy to expose everything.
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 (which they warn you when you've done right there in the console).
You can safely ignore the existence of Organizations and folders completely if you are so inclined. At least there's a sensible way to set default policies for your organization baked into the platform. Even so, literally 3 hours, tops, and you know everything about these abstractions you could ever care about. I cannot emphasize enough how much easier GCP is to learn and use than AWS.
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.
You can still work like that. You just don't have to bother changing your project id, and switch accounts to jump to other projects. I do this for some things I work on where there are account level controls and the accounts cant be shared across projects.
They recently rebranded it to the super-catchy "AWS IAM Identity Center (successor to AWS SSO)". Gotta love Seattle-based tech marketing people, presumably trained at Microsoft. :)
I guess it will soon be the default user management system, and 'proper' IAM will be the low-level one. I see this as a reaction towards GCP's IMHO superior UX/system design in this aspect. I don't think they can entirely catch up because of early and bad architectural decisions regarding projects/accounts.
I was originally skeptical when we implemented it because for safety reasons I wanted it to be painfully obvious when I was switching contexts.
It's definitely grown on me, but I frequently emphasize to my teammates that I'd much rather they specify their AWS_PROFILE for each command they run, instead of exporting it into their environment. Especially using Windows and setx seems like an open invitation for disaster.
The killer feature of AWS is that they've broken almost nothing since first launching over 15 years ago. Their commitment to keeping old stuff working is truly amazing.
No other cloud hosting service comes close, because no other cloud service has had 15 years to prove themselves in the same way!
I don't know. I've found it to be pretty difficult to answer the question "which of these 1000 gcp projects are running a production workload and which are random one offs created by a dev messing around or by a google sheet script?"
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 create GCP projects behind the scenes. So you could easily get thousands of projects that the users themselves didn't even know that they had created.
If I were starting from scratch with GCP I'd use a third party IdP and not let users access it via their gsuite accounts. I suspect that would avoid most of the issues I've run into.
One reason to have your roles and service accounts reference cross-project is to give your CI builder access to your artifacts project; Have your prod and dev environments use containers from a third account that serves only as an archive of your build artifacts.
- 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.
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.”
> 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.
> 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.
That's gold advice. I wish AWS RAM supported more services (like AWS EKS).
A small complain: working with AWS SSO is a bit tedious. My current solution is to share my ~/aws/config with everyone so we all have the same profile names and scripts can work for everyone.
Depending on your SSO provider, you can list all the roles using saml2aws[0] and then parse the output so you can generate the relavant config. It is a bit tedious, but it works.
Synchronizing ~/aws/config gets harder and harder as your team grows because there are both more people who need to receive changes and more people making changes.
I think the human-readable names for AWS accounts need to be part of the account, not part of the laptop. Substrate [1] does this so that you can type commands like `substrate assume-role -domain example -environment production -quality beta` [2] to get where you're going.
I have thought a great deal about whether I also want EKS clusters to officially support nodes in multiple AWS accounts. On the one hand, having the option to create that additional low-level isolation would be lovely, even and maybe even especially if I didn't always take it. On the other hand, isolating two things from each other but then tying them to the same Kubernetes cluster upgrade schedule feels wrong.
In the end, I decided that if I care about isolating two things enough to put them in separate AWS accounts, I'm willing to spend the $75 per month that it takes to have separate EKS clusters, too. (This opinion perhaps obviously doesn't fit will with hobby/side project budgets.)
> My current solution is to share my ~/aws/config with everyone so we all have the same profile names and scripts can work for everyone.
If you're on Mac/Linux you could have everyone use direnv. Add a .envrc file in each git repo (or your script's subdirectory) with `export AWS_PROFILE=profilename`. Now everyone is working with the same profile names without having to pass around config files.
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's largely unnecessary. In Azure the equivalent of an account is a subscription, but then there'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.
Splitting things across accounts or subscriptions is complex and results in all sorts of strange limitations. For example, some resources can't be connected to each other across subscription boundaries, so you have to duplicate them.
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't be "associated" 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/IAM and keep the head of hair you had in your 20s! You've been warned...
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.
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).
Curious / product research: Are your 38 accounts all in the same organization? Do you have any human IAM users left or is it all IdP, all the time? Do you use Terraform or anything like it?
Also, yes, a pox on the single-player AWS Console. I’ve at least found a way to logout from one account and login to another in the same motion but it’s still a poor experience.
Yeah all accounts are in the same OU. We do have human IAM users but those are "legacy". Nowadays Okta has been the preferred method of accessing AWS console and CLI. We do use terraform but that is also fragmented since each team has the freedom to innovate in their own way. People use CDK, SAM, CloudFormation, Terraform etc. This fracturing of IaC techniques has been a natural consequence of having too many silos aka. accounts and has made it hard to enforce consistency. I think having 2 or 3 accounts is probably ok for a small to medium size org. We are 96 humans so far.
Interesting. Thanks for the detailed response. Another, positive way to look at one aspect of your architecture is that the AWS account boundary prevents most cases of dueling configuration management, with two tools changing the same resource back and forth forever.
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, the ban hammer will not be able to destroy all my income in one blow.
I've never used Google Voice so I cannot say about that. Where I'm at you can buy a cheap phone for like $20 and it comes with a prepaid SIM that never expires. I have about 10 of those on a drawer on my desk LOL, it goes well with the hacker vibe B). Funny thing is I don't have them labeled, so when I need it I have to turn on all of them to see which one gets an SMS.
For email, my domain provider handles email for me as well, I have a Google Workspace account and first thing I do when I set up an email is to link it there so I have a single Inbox for everything. (Although my real Inbox is the Spam folder, where a lot of genuine emails land now).
I'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't want to manage accounts.
And that's just the management complexity -- cross-account network adds a ton of complexity to other stuff, including VPC management, transit gateways, and sometimes DNS.
Compared to having fewer accounts, the difference in complexity is enormous.
"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.
Somewhere I worked used to just run awsnuke and move them to a "deleteme" OU. I guess that's an option if you're okay with a bunch of empty accounts (they have a few hundred in there)
Having multiple accounts reduces the potential blast radius tremendously.
Anyone who hasn't accidentally deleted "stuff" in the wrong account is someone who hasn't been doing production work for long.
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.
It also makes tooling more awkward.
But, it also allows you to completely automate deployment of consistent environments, providing a IT/CI/Testing nirvana for not that much work.
GCP organization structure is such a breath of fresh air after dealing with AWS. AWS Orgs and all the complexity with VPC and DNS management at a scale of hundreds of accounts is just a complete pain in the arse. GCP makes it far easier with Shared VPC and org/folder/project structure.
Lots of AWS accounts doesn't scale. Accounts are heavy items in terms of governance, manageability and cost. On your way to 100 accounts you'll be rearchitecting security and networking and will find yourself in a strange limbo of architecture models. Once over 100 you'll be drowning in the tech debt of a complex environment with increasing friction.
Accounts can be made lightweight by using shared VPC/subnets but then you'll be in the realm of niche user, hampered by AWS's poor support for RAM service support with poor documentation if you plan on using anything off the highway of bread and butter services.
IMO a balance needs to be struck with sensible boundaries built on business units or ownership. Shared VPC'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's difficult to silo access to specific resources with AWS IAM.
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:
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 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's missing any discussion of downsides to having a lot of accounts.
Some of these include:
* 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.
* Using the web console or cli is more complicated. In the cli you'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.
* Several products charge per AWS account. Using a lot of accounts can make those products very expensive.
* 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.
I say this as someone with experience with working with several accounts, and who thinks that we should have more accounts.
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.
> * 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.
One workaround I usually implement for this is to always have to assume a role. Meaning that, basically, your base permissions only allow you to assume roles. To actually do the job, you need a separate one, in whichever account.
This way, it's also easier to standardize roles across accounts. A action requires R role.
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.
In my experience, no business is able to shuffle its people 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.
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't predict the weather.
> AWS accounts are the most complete form of isolation on offer.
Because it's a pretty brutal namespace. While I usually wind up with separate accounts for multiple reasons, I strongly prefer to get rbac/iam properly implemented in a single account wherever possible.
> I strongly prefer to get rbac/iam properly implemented in a single account wherever possible.
This can really help manage complexity but it the more this account grows the riskier it becomes if a bad actor breaks into the account (ranging from fraudsters/hackers to disgruntled employees).
Using accounts as the security boundary is easier to reason about up front but it's rather ham fisted. If you're centrally automating large swaths of infrastructure across many accounts you'll wind up paying for that in the long run.
When a shop smaller, or dealing with multi-tenancy situations, multiple accounts is an easy trade off to make. The account boundary has its place, but it's not for everything.
Some of these scaling pains with hard boundaries have gotten better with awssso and iam features over the years but you still run into them on occasion.
As far as whatever you mean by "breaking into an account". I said originally, "rbac/iam properly implemented". If you fuck that up, it doesn't matter whether or not you have one or multiple accounts.
Having a single account does mean that you have to give anyone the keys to the kingdom or that you don't separate your concerns.
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)
* 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've seen but maybe too limited)
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 accounts to manage), and so did my team, so we stuck with one account per stage per service.
That said, cross account permissions is really not an issue, it's very easy and straightforward to setup. You also should not need it in 90% of the cases if your application is properly split with the right ownership for each microservice.
For my current team we manage probably more than a thousand AWS accounts, and permissions are never an issue. Neither is anything else actually. We aggregate metrics in a single account for the stuff that needs to be aggregated, we have small CLI scripts that automate tedious steps like requesting limit increases, etc.
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.
> 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.
There are global quotas per account that can sneak up on you if you have too many services running in the same account albeit in different regions. DynamoDB total read and write capacity comes to mind.
I'm not sure what you are referring to (pricing or service quotas?, I will assume the latter), but I think it depends on the service. For some setting the service quota will be per region and for others it will be global.
One I know that is for sure regional is the limit reserved concurrent executions of Lambda functions.
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.
Author here: I have settled on account per service per environment with a couple of exceptions.
Sometimes I run multiple services in one account if they’re so tightly coupled as to be useless as a group if any one is down. (This has practically come up when two services are codesigned to multiplex TCP connections to support tens of millions of clients.)
Sometimes I run a single stateless production service in two accounts and route 10% of traffic to the canary account and 90% to the other one.
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!
> Quota increases can be requested but the default limit tells us what AWS thinks normal usage should be for most use cases.
This is certainly not true for a lot of AWS quotas. If you hit an ec2 quota for an instance type, that isn't AWS telling you that you are using too much compute. Its there as a speedbump to make sure you have some idea that you know what you are doing and to make sure AWS can actually service your requests.
AWS will happily let you have hundreds of child accounts. In fact, if you are talking to them about your architecture they will even encourage it (assuming that it is actually appropriate for the scale of your organization).
I think this just tells us author is using a method counterintuitive to what AWS would recommend, so while you may try it out that it probably isn't best practice and so when you screw up then you will just be left pointing to some blog as to why you chose the direction you did.
Sorry to ask but...what is an "account" 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 "account".
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.
"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."
Got to be my favorite way to describe two nines ever!
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.
> The fact that it’s the internal service used to provision AWS accounts means that AWS engineers building AWS are insulated from the way that the rest of the world manages AWS accounts–or should I say, ways. They don’t have to deal in the same way with AWS Organizations or Landing Zones or Control Tower or AWS SSO (an absolute hidden gem of a service, by the way). And that’s the crux of my beef with the service.
Apparently, /u/quinnypig dislikes this account-manager-thing specifically because AWS has been hoarding it to themselves.
His point is valid: When is AWS going to advertise account per region per service as an official default policy and bring AWS Orgs up to par with it? They think it's the right way, why not for the customer?
AWS Organizations (https://aws.amazon.com/organizations/) is supposed to solve this for you. If all your accounts are in the same Organization then you get one bill instead of six.
I'm not honestly sure how AWS Organizations interacts with the AWS free tier.
Rest assured, though, having lots of AWS accounts (and using AWS Organizations, their service designed to _help_ you use lots of AWS accounts) is _not_ against the terms of service.
Each account within the organization gets the limits of the free tier, just as a single account would. I think the reasoning is that if you're going to go through the hassle of setting up orgs then you're probably an enterprise user slated to take the long haul anyway.
Multi Account is a normal pattern for AWS. They even have tools to handle that better like AWS Control Tower. Someone from AWS we talked to even mentioned it as a perk (to get the free tier on every account).
That person was misinformed or maybe the context was outside the scope of business needs. If you use link accounts within an AWS Organization, one of them becomes the payer account with consolidated billing. There's a shared free tier across all accounts. If you actually spin them up as completely separate accounts and don't link within an org, you do get extra free tiers, but most corporations would rather not have the headache that comes with that.
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
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 sense, particularly the point about EKS upgrades (I run three different versions of EKS in the same account).
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.
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...