5 ms·

Sorry if this comes across weird or snotty it’s not supposed to. But I’m coming at this from a GCP lens and got half way through the article about how the reco

by mdhb 3y ago

Sorry if this comes across weird or snotty it’s not supposed to. But I’m coming at this from a GCP lens and got half way through the article about how the recommended unit of isolation in the AWS environment is entirely different AWS accounts and I’m kind of hung up on that. Is that really a thing people tend to do often? Doesn’t it get super unwieldy? How does billing work? What about identity? I have so many questions. EDIT: Despite the fact that the root resource in both GCP and AWS is an organization, when I heard “account” I mistook that to be AWS terminology for an organization.

dragonwriter 3y ago
> But I’m coming at this from a GCP lens and got half way through the article about how the recommended unit of isolation in the AWS environment is entirely different AWS accounts and I’m kind of hung up on that. Is that really a thing people tend to do often? Doesn’t it get super unwieldy? There are AWS systems above the account level for managing it (Organizations), so its not quite as bad as it might naively seem, but, yes, its more unwieldy than GCP’s projects.
- mdhb 3y ago
  Oh thank god, that’s much better than I naively thought. Thanks for the heads up.
stock_toaster 3y ago
You can have sub-accounts that roll up billing to a main account. Still messy, but probably cleaner (security policy wise) and possibly safer (fewer production impacting accidental config changes?) than having a single giant account with _lots_ of things mixed together.
- mdaniel 3y ago
  As the resident pedant, one cannot have "sub-accounts" in AWS. One can 100% have Accounts that are a member of an AWS Organization, which itself has a Management Account that does as you describe as the "main account", but there is no parent-child relationship between Accounts, only OUs and Accounts or OUs and other OUs (which the Organization, itself, counts as an OU)
  - stock_toaster 3y ago
    Thanks for the corrections. :)
cube2222 3y ago
It's extremely common and recommended. Billing works by having a billing aws account that all other accounts are in a sense "children" of.
lgreiv 3y ago
You should be able to organize accounts hierarchically using AWS Organizations, which allows to have cost centers and centralized billing (and some imposed policies over all accounts).
swozey 3y ago
The way this works with AWS is similar to you making a GCP project. At the top level you have an organization account, which is where billing occurs. From this org account you create accounts for the following (typically): 1. Security - AKA the account your USERS are in 2. Ops - The account your monitoring, etc are in From here where a lot of people seem to deviate (I've been interviewing level 2-3 SREs for the last 3 weeks and have heard all about different AWS structures that I don't like) is how to break up your applications into their own accounts for a low blast radius. What I DO, and is well known as being the best practice, is to create an AWS account for each environment of each application. App1-sandbox App1-staging App1-production Then your terraform is also structure by application/environment/service. Each environment and application has it's own state in s3 and dynamodb. And so on. Is this unwieldly? I have 40-50 AWS accounts and no it's not unwieldly at all IMO. Cross account IAM and trust relationships are set up very early on and they don't need to be modified much if any at all until you create another AWS account. Creating a new AWS account is kind of annoying, though. I need to automate that process better. https://aws.amazon.com/organizations/getting-started/best-practices/ https://aws.amazon.com/organizations/getting-started/best-pr...
- mdhb 3y ago
  Cool, that was a genuinely fascinating window into AWS for me. Thank you for sharing
  - swozey 3y ago
    FWIW I loathe AWS IAM and miss GCPs organization.
    - mdhb 3y ago
      I’m quite into learning a lot of cloud native security stuff and I have to say my first impression was that it seemed so much harder to think about creating a secure environment using AWS IAM. I couldn’t tell if it was just a case of familiarity or not.
      - 3y ago
erik_seaberg 3y ago
Some AWS services have per-account (not per-resource) size and rate limits. Keeping resources in separate AWS accounts gets them out of each others’ blast radii. AWS IAM doesn’t do capability inheritance; if I can write a policy at all I could grant any privilege to any resource in that policy, even privileges I don’t personally have. It’s easier for each groups of admins to have a separate AWS account than to put everyone in security boundaries that try to wall them off.
deleted 3y ago
[deleted]
linuxdude314 3y ago
This doesn’t have anything to do with AWS, this has to do with terraform not allowing you to dynamically instantiate providers. The same thing happens with the Kubernetes provider when you try to use it with multiple GKE clusters.

by mdhb 3y ago

dragonwriter 3y ago

> But I’m coming at this from a GCP lens and got half way through the article about how the recommended unit of isolation in the AWS environment is entirely different AWS accounts and I’m kind of hung up on that. Is that really a thing people tend to do often? Doesn’t it get super unwieldy? There are AWS systems above the account level for managing it (Organizations), so its not quite as bad as it might naively seem, but, yes, its more unwieldy than GCP’s projects.

mdhb 3y ago
Oh thank god, that’s much better than I naively thought. Thanks for the heads up.

stock_toaster 3y ago

You can have sub-accounts that roll up billing to a main account. Still messy, but probably cleaner (security policy wise) and possibly safer (fewer production impacting accidental config changes?) than having a single giant account with _lots_ of things mixed together.

mdaniel 3y ago
As the resident pedant, one cannot have "sub-accounts" in AWS. One can 100% have Accounts that are a member of an AWS Organization, which itself has a Management Account that does as you describe as the "main account", but there is no parent-child relationship between Accounts, only OUs and Accounts or OUs and other OUs (which the Organization, itself, counts as an OU)
- stock_toaster 3y ago
  Thanks for the corrections. :)

cube2222 3y ago

It's extremely common and recommended. Billing works by having a billing aws account that all other accounts are in a sense "children" of.

lgreiv 3y ago

You should be able to organize accounts hierarchically using AWS Organizations, which allows to have cost centers and centralized billing (and some imposed policies over all accounts).

swozey 3y ago

The way this works with AWS is similar to you making a GCP project. At the top level you have an organization account, which is where billing occurs. From this org account you create accounts for the following (typically): 1. Security - AKA the account your USERS are in 2. Ops - The account your monitoring, etc are in From here where a lot of people seem to deviate (I've been interviewing level 2-3 SREs for the last 3 weeks and have heard all about different AWS structures that I don't like) is how to break up your applications into their own accounts for a low blast radius. What I DO, and is well known as being the best practice, is to create an AWS account for each environment of each application. App1-sandbox App1-staging App1-production Then your terraform is also structure by application/environment/service. Each environment and application has it's own state in s3 and dynamodb. And so on. Is this unwieldly? I have 40-50 AWS accounts and no it's not unwieldly at all IMO. Cross account IAM and trust relationships are set up very early on and they don't need to be modified much if any at all until you create another AWS account. Creating a new AWS account is kind of annoying, though. I need to automate that process better. https://aws.amazon.com/organizations/getting-started/best-practices/ https://aws.amazon.com/organizations/getting-started/best-pr...

mdhb 3y ago
Cool, that was a genuinely fascinating window into AWS for me. Thank you for sharing
- swozey 3y ago
  FWIW I loathe AWS IAM and miss GCPs organization.
  - mdhb 3y ago
    I’m quite into learning a lot of cloud native security stuff and I have to say my first impression was that it seemed so much harder to think about creating a secure environment using AWS IAM. I couldn’t tell if it was just a case of familiarity or not.
    - 3y ago

erik_seaberg 3y ago

Some AWS services have per-account (not per-resource) size and rate limits. Keeping resources in separate AWS accounts gets them out of each others’ blast radii. AWS IAM doesn’t do capability inheritance; if I can write a policy at all I could grant any privilege to any resource in that policy, even privileges I don’t personally have. It’s easier for each groups of admins to have a separate AWS account than to put everyone in security boundaries that try to wall them off.

deleted 3y ago

[deleted]

linuxdude314 3y ago

This doesn’t have anything to do with AWS, this has to do with terraform not allowing you to dynamically instantiate providers. The same thing happens with the Kubernetes provider when you try to use it with multiple GKE clusters.