5 ms·

Holy moly, why 20 accounts?

abrookewood 6y ago
It's not that unusual to use separate AWS accounts as blast-barriers. I.e. they contain the damage that might occur due to a leak etc. I typically use 2 (prod & non-prod) for each major product/offering, plus a centralised one to manage policies, billing etc for all the sub accounts. They add up pretty quickly.
- jethro_tell 6y ago
  I use an account for $service-$stage-$region-<$function> then I run most services in every available region so: main-service_prod_us-east-1_dataStore main-service_prod_us-east-1 main-service_test_us-east-1_dataStore main-service_test_us-east-1 main-service_beta_us-east-1_dataStore main-service_beta_us-east-1 * regions Adds up pretty quickly.
LilBytes 6y ago
My employer has accounts in the hundreds... Similar to OP you're replying to, I use Firefox Containers to open separate accounts to open independent windows from my Identity Provider when I need to be in more than one account at a time.
dheera 6y ago
AWS credits? You can get a bunch of free credits for each account, and then build an abstraction around boto3 to make 20 accounts look like 1 account to you.
- jethro_tell 6y ago
  meh, compute cost almost always costs less than dev time. I use multiple accounts for separation of duties, cost, access, and blast radius. Most services I run blow through the free tier in minutes. I do have scripts that spin up accounts as needed and I just have a bucket for 'free Tier account access ending' emails.
jethro_tell 6y ago
Standard practice in larger scale. I run big fleets, 100s of hosts 1000s of containers in most AWS regions. Most of the control plane is automated, but when that breaks, or there are issues in the data plane, I might log into read logs, look at metrics, force scaling actions, or just general investigation tasks. I also use different accounts for permissions boundaries. Data shared between multiple teams might go in one account. The apps can access the data but maybe the interns can only access the app account while the SR. Eng(s) + current oncall have full read only access to the data for investigation. A second RW-Data oncall might have access to the DB account in each region. Ever data storage account also has a limited access cross account Data replication/backup account. + I help people out. 'Can you look at this? . . .' In the end, there are account specific errors that can be caused in your infra, IAM rolls, keys, throttling, malicious access that are easily prevented with least access in per account buckets. So I end up with multiple accounts in each region.

It's not that unusual to use separate AWS accounts as blast-barriers. I.e. they contain the damage that might occur due to a leak etc. I typically use 2 (prod & non-prod) for each major product/offering, plus a centralised one to manage policies, billing etc for all the sub accounts. They add up pretty quickly.

jethro_tell 6y ago
I use an account for $service-$stage-$region-<$function> then I run most services in every available region so: main-service_prod_us-east-1_dataStore main-service_prod_us-east-1 main-service_test_us-east-1_dataStore main-service_test_us-east-1 main-service_beta_us-east-1_dataStore main-service_beta_us-east-1 * regions Adds up pretty quickly.

LilBytes 6y ago

My employer has accounts in the hundreds... Similar to OP you're replying to, I use Firefox Containers to open separate accounts to open independent windows from my Identity Provider when I need to be in more than one account at a time.

dheera 6y ago

AWS credits? You can get a bunch of free credits for each account, and then build an abstraction around boto3 to make 20 accounts look like 1 account to you.

jethro_tell 6y ago
meh, compute cost almost always costs less than dev time. I use multiple accounts for separation of duties, cost, access, and blast radius. Most services I run blow through the free tier in minutes. I do have scripts that spin up accounts as needed and I just have a bucket for 'free Tier account access ending' emails.

jethro_tell 6y ago

Standard practice in larger scale. I run big fleets, 100s of hosts 1000s of containers in most AWS regions. Most of the control plane is automated, but when that breaks, or there are issues in the data plane, I might log into read logs, look at metrics, force scaling actions, or just general investigation tasks. I also use different accounts for permissions boundaries. Data shared between multiple teams might go in one account. The apps can access the data but maybe the interns can only access the app account while the SR. Eng(s) + current oncall have full read only access to the data for investigation. A second RW-Data oncall might have access to the DB account in each region. Ever data storage account also has a limited access cross account Data replication/backup account. + I help people out. 'Can you look at this? . . .' In the end, there are account specific errors that can be caused in your infra, IAM rolls, keys, throttling, malicious access that are easily prevented with least access in per account buckets. So I end up with multiple accounts in each region.