So it's basically just an IAM delegation - wouldn't call it "multi-account" deployment - more like Identity sandboxing that misses most of the reasons you do multi-account.
I don't think so. I had to watch parts of this 3 or 4 times. It would have helped if they showed a final architecture picture with where everything resided. BUT, I think the point here is that they can use shared services accounts for VPC and EC2 (compute) shared with other accounts that do not have VPC and EC2. The OIDC federation was the trick. In this way, for those services that are hard to keep setting up in multiple accounts they just use the shared accounts. Lambdas, dynamodb, etc, are allowed in the new accounts. The roles allow the EC2s to access anything in the new accounts. So, by doing this they simplify new accounts. No VPCs and No EC2s. Not sure about ALBs, but I think I get the idea. If the management gets worse the more you deploy some type of resource to new accounts, stop deploying it to new accounts and use a shared account and a shared role. Really, I wish they had another architecture diagram or two at the end.
@@animatem From what I understood they failed migration of services to dedicated accounts (very understandable considered the scope), so they just created a hybrid that still uses the old infra, but it's accessed by the identity managed in subaccounts. They gain the "multiaccount" configuration label that way, but it's still not the true isolation "multiaccount" is about when it comes to security, billing (nothing that enough of ABAC policies and tags can't fix tho). You got me curious - will watch again and get into details :D
@@animatem Indeed -I believe you got it correctly (it's so easy to miss - all that info is just crammed in that small part at 28:28 and the rest is barely mentioned at the end after 31:40 - all extremely vaguely at that). They basically failed to communicate what they did as still I'm not 100% sure. They still lack a lot of things that true multi-account gives you, but at least resources like DBs and buckets are somewhat isolated and the management is no doubt miles easier than with true multiaccount so indeed - interesting architecture. Can't agree more with you on that one diagram missing that would bring all the light onto what they said.
@@animatem Thanks for the feedback! We hope to share more details as we go along with the app migrations. I'll be sure to get some more architecture diagrams included with what we share in the future.
For resources within the dedicated app account, the developers are free (within the given guardrails, SCP etc) to provision any managed service and use it as such. There could be cases where you may want to access non-ec2 resources from other accounts - for that the standard procedure for cross account access apply, or you can also use AWS Resource Access Manager.
Yep, like @sharmaprateek84 said, these accounts are limited by SCP to only allow access to managed services that don't need VPC connectivity. Anything that needs to be "on the network" has to live in another account. For example, there could be a VPC-connected storage account where RDS instances are placed.
@@psanders_nflx Are you suggesting each service has a storage account for RDS (which is presumably platform-team managed?) or there is a central storage account for all service RDS instances?
@@davidroberts478 We're not prescriptive, but I would recommend the latter where data platform folks maintain a small set of accounts where they manage persistent datastores.
So it's basically just an IAM delegation - wouldn't call it "multi-account" deployment - more like Identity sandboxing that misses most of the reasons you do multi-account.
I don't think so. I had to watch parts of this 3 or 4 times. It would have helped if they showed a final architecture picture with where everything resided. BUT, I think the point here is that they can use shared services accounts for VPC and EC2 (compute) shared with other accounts that do not have VPC and EC2. The OIDC federation was the trick. In this way, for those services that are hard to keep setting up in multiple accounts they just use the shared accounts. Lambdas, dynamodb, etc, are allowed in the new accounts. The roles allow the EC2s to access anything in the new accounts. So, by doing this they simplify new accounts. No VPCs and No EC2s. Not sure about ALBs, but I think I get the idea. If the management gets worse the more you deploy some type of resource to new accounts, stop deploying it to new accounts and use a shared account and a shared role. Really, I wish they had another architecture diagram or two at the end.
@@animatem From what I understood they failed migration of services to dedicated accounts (very understandable considered the scope), so they just created a hybrid that still uses the old infra, but it's accessed by the identity managed in subaccounts. They gain the "multiaccount" configuration label that way, but it's still not the true isolation "multiaccount" is about when it comes to security, billing (nothing that enough of ABAC policies and tags can't fix tho). You got me curious - will watch again and get into details :D
@@Gosu9765 Let me know what you take away after watching it again. I am actually curious.
@@animatem Indeed -I believe you got it correctly (it's so easy to miss - all that info is just crammed in that small part at 28:28 and the rest is barely mentioned at the end after 31:40 - all extremely vaguely at that). They basically failed to communicate what they did as still I'm not 100% sure. They still lack a lot of things that true multi-account gives you, but at least resources like DBs and buckets are somewhat isolated and the management is no doubt miles easier than with true multiaccount so indeed - interesting architecture. Can't agree more with you on that one diagram missing that would bring all the light onto what they said.
@@animatem Thanks for the feedback! We hope to share more details as we go along with the app migrations. I'll be sure to get some more architecture diagrams included with what we share in the future.
Maybe I missed that, but how do you deal with non-ec2 services which might need connectivity?
For resources within the dedicated app account, the developers are free (within the given guardrails, SCP etc) to provision any managed service and use it as such. There could be cases where you may want to access non-ec2 resources from other accounts - for that the standard procedure for cross account access apply, or you can also use AWS Resource Access Manager.
Yep, like @sharmaprateek84 said, these accounts are limited by SCP to only allow access to managed services that don't need VPC connectivity. Anything that needs to be "on the network" has to live in another account. For example, there could be a VPC-connected storage account where RDS instances are placed.
@@psanders_nflx Are you suggesting each service has a storage account for RDS (which is presumably platform-team managed?) or there is a central storage account for all service RDS instances?
@@davidroberts478 We're not prescriptive, but I would recommend the latter where data platform folks maintain a small set of accounts where they manage persistent datastores.