Have lots of AWS accounts
src-bin.com
src-bin.com
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...
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.
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...
- for each account number
- aws service-quotas request-service-quota-increase<https://aws.amazon.com/about-aws/whats-new/2022/09/aws-updat...>
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.
The main risk is hitting resource limits which is why I would and do give development teams their own account to cause mayhem in.
Infrastructure as code.
Easier for you, easier for the black hatters.
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.
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.
Azure also has higher-level subscriptions
PS good job partitioning your EKS clusters, even within one account. That’ll save you some sleep one day, I’m sure.
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.
The way that GCP organizes various different projects is actually really nice. I haven't seen what this looks like at scale though.
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'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?
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.
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)
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.
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 though.
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.
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 :/
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.
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.
Just imagine you woke up and your AWS account is blocked and all your infra is shut off. What's your plan? Blame "poor design" or policy?
If you want to build a _reliable_ infrastructure, the only rule is to avoid singe point of failure. Account is one of those.
No worries, it will come with experience.
> 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?
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.
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.
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.
[1] - "Benefits of using multiple AWS accounts" - https://docs.aws.amazon.com/whitepapers/latest/organizing-yo...
[2] - "Organizing Your AWS Environment Using Multiple Accounts" - https://docs.aws.amazon.com/whitepapers/latest/organizing-yo...
[3] - "Consolidated billing for AWS Organizations" - https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2...
[4] - "Tasks that require root user credentials" - https://docs.aws.amazon.com/accounts/latest/reference/root-u...
[5] - "Protecting data with Amazon S3 Object Lock" - https://aws.amazon.com/pt/blogs/storage/protecting-data-with...
Ok...
> 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.
Roles and service accounts can even reference across projects, though I'm not sure I'd recommend doing that.
No more faffing about with special accounts, passwords and difficult to configure shared VPCs, it all becomes so easy.
Even managing the different accounts is difficult without browser extensions such as this one: https://chrome.google.com/webstore/detail/aws-extend-switch-...
Maybe the next blog post?
No other cloud hosting service comes close, because no other cloud service has had 15 years to prove themselves in the same way!
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.
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.
I'm a huge fan and recommend it.
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.
Also a fan, so far.
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.
It’s not worse than your filesystem, in theory, but speaking for myself: my filesystem is a mess, so…
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.
- 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.
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...
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”.
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.
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.)
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.
[1] <https://src-bin.com/substrate/> [2] <https://src-bin.com/substrate/manual/moving-between-aws-acco...>
I would love to see a browser extension for SSO account tabs if AWS can't solve it natively.
1 - You need to do that with each account / role pair
2 - It gives profiles very long names by default (<role>-<account_number>)
3 - It does not set $AWS_PROFILE, so you need to pass `<...> --profile <...>` manually
So the code is actually there already, they just need to make the experience better.
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.
They've even added a feature to redistribute the costs of shared resources: https://azure.microsoft.com/blog/simplify-financial-reportin...
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.
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.
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).
http://willthames.github.io/2018/02/28/managing-multiple-aws...
You're welcome :)
* 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, the ban hammer will not be able to destroy all my income in one blow.
They give you an app where you can create virtual credit cards. Quite neat, I literally waited for something like that for decades.
Coincidentally, I just set up a Mercury account last week and I think they have a similar feature but haven't explored it yet.
For emails, how do you handle email? Outlook/Google Workspace? Something else?
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).
https://manuel.kiessling.net/2020/12/29/single-sign-on-and-r...
Only one of several ways to achieve that, but one that works really well for me.
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.
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.
At any rate, this is a good reason to use accounts for architectural divisions, not teams, and certainly not individual engineers.
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.
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 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:
[0]https://koptional.notion.site/IAM-Policy-for-select-S3-Acces...
[1] https://koptional.notion.site/IAM-Policy-for-email-sending-o...
- https://s3-credentials.readthedocs.io/
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.
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.
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.
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.
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.
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.
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.
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).
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 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)
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 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.
This is exactly correct.
> I think it's idiotic though (because regions are 100% separated within an account
But still bound to the same service limits, no?
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.
Service limits for global services like Organizations appear to only be manageable from us-east-1.
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.
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.
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.
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.
Quota increases can be requested but the default limit tells us what AWS thinks normal usage should be for most use cases.
https://docs.aws.amazon.com/organizations/latest/userguide/o...
Perhaps the author meant “more than one”?
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).
Could someone come with some analogy please?
Got to be my favorite way to describe two nines ever!
Internally, Amazonians also use AWS accounts per "app" basically.
> 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?
...Which is probably fine because that's pretty much how it always goes.
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?
Better, though, that one bill is broken down by account so you can see where the money’s going.
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.
Does anyone here do this?