This is how AWS runs projects internally. Tons of dedicated, limited scope accounts.
Have lots of AWS accounts
131–140 of 176 posts
Re: Have lots of AWS accounts
#132Earlier quoted context omitted.
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 a…
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.
Re: Have lots of AWS accounts
#133I 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…
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).
Re: Have lots of AWS accounts
#134I 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…
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.
Re: Have lots of AWS accounts
#135Earlier quoted context omitted.
I run into "IT professionals" all the time who don't even realize you can run services without a VPC.
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”. (Lam…
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?
Re: Have lots of AWS accounts
#136Define “lots.” Because the default limit in AWS is 10 accounts per org. 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”?
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.
Re: Have lots of AWS accounts
#137My anecdote on how we do it: - We have AWS Org - Each account has no root IAM and cost/pricing goes through root AWS Org Account - You move between accounts with AWS SSO (now IAM Federation) - No more password per account - AWS SSO standardizes boundaries across account with IAM policies, like eu-centeral-1 only for dev IAM etc. - Inside Account more granular access with IAM Assume Roles - Each account Cloudtrail to…
> 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.
Re: Have lots of AWS accounts
#138Earlier quoted context omitted.
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.
Not true, the free tier is applied at the Organization level (i.e. the billing account), not to each individual account.
Re: Have lots of AWS accounts
#139I 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.
Re: Have lots of AWS accounts
#140In 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.