AWS re:Invent 2019: SaaS tenant isolation patterns (ARC372-P)

This presentation was recorded prior to re:Invent. Tenant isolation is one of the most fundamental aspects of SaaS architecture. Every SaaS provider must consider how to ensure that their tenant resources are isolated and secure. The challenge is that each resource type (compute, storage, etc.) requires different isolation approaches. In this session, we build a clear roadmap for navigating the landscape of isolation options, highlighting the strategies for achieving isolation spanning the different multi-tenancy models and AWS services. Our goal is to create a comprehensive view of the considerations that impact your approach to introducing isolation into your SaaS solution.
Sign up at partners.awscloud.com/SaaS.html to stay up-to-date on the latest SaaS news, resources, and events from AWS.

[@ajwright5512]

One of the most important talks I've watched.

[@asifadamsha8863]

Learned lot about SaaS isolation, thank you very much !

[@victoriaperalta8590]

Great video Tod, thank you sooo much !!

[@RafaelCorreaGomes]

Excellent content, thank you!

[@PaganAbroad]

Was there a more recent update? I know the concepts dont change much but the tools etc to implement them usually do e.g. a 3P SaaS islotation checker version of Prowler?

[@jonasgrnbek7113]

There are much talk about silo partitioning models and how that abstracting tenant isolation away from the developers is important. But how to do that in a pool model, it seems inherently more difficult and I feel like that might be why it is left out, since you most likely will have to rely on developer implementations for tenant isolation

[@pankpunk1]

Great content; thanks for this

[@olajide9022]

Amazing content. Straight to the point.

[@rob3c]

Nice overview! Unfortunately, there was still no mention of data persistence dangers in memory and on disk between successive Lambda invocations for the same function version/environment. That kind of potential leak seems problematic for multi-tenant Lambda use (and ECS for that matter), regardless of policy constraints. At least it's mentioned (buried?) at the bottom of page 9 in the "Security Overview of AWS Lambda" whitepaper, even if the video presenters all avoid the subject (not only this one).

[@thomasgremm6127]

That is the attack vector, that I also thought of; I guess, we 2 Jedi's are not only ones..

[@croveapp]

came down to comment the same

[@marinradjenovicmarin]

Thanks Tod great video! However it is still not clear to me from security perspective why is ECS so different from Lambda. You mentioned, that you can't prevent code from ECS task executing other resources. If you define role per task, does that actually prevent running anything else than what is defined in Task IAM Role?

[@mfjonesxyz]

I'd also like to know more about this drawback of ECS

[@smecher69]

no *u*