AWS re:Invent 2022 - Reimagining multi-account deployments for security and speed (NFX305)

Подписаться 116 тыс.

Просмотров 6 тыс.

50% 1

In this session, discover a new paradigm for multi-account architecture based on decoupling a workload’s identity and permissions from its underlying cloud infrastructure. Efforts to segment cloud environments are often stymied by complex migrations and excessive operational overhead, hindering organizations from capturing the desired security and scalability benefits. Join us to learn how Netflix is deploying applications in isolated AWS accounts without relocating their compute or network resources, and discover how they are increasing developer velocity along the way.
Learn more about AWS re:Invent at go.aws/3ikK4dD.
Subscribe:
More AWS videos bit.ly/2O3zS75
More AWS events videos bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.
AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers-including the fastest-growing startups, largest enterprises, and leading government agencies-are using AWS to lower costs, become more agile, and innovate faster.
#reInvent2022 #AWSreInvent2022 #AWSEvents

Наука

Опубликовано:

24 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 12

@EnterExile Год назад

Maybe I missed that, but how do you deal with non-ec2 services which might need connectivity?

@sharmaprateek84 Год назад

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.

@psanders_nflx Год назад

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.

@davidroberts478 Год назад

@@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?

@psanders_nflx Год назад

@@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.

@Gosu9765 Год назад

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.

@animatem Год назад

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.

@Gosu9765 Год назад

@@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 Год назад

@@Gosu9765 Let me know what you take away after watching it again. I am actually curious.

@Gosu9765 Год назад

@@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.

@psanders_nflx Год назад

@@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.