Tenant Isolation for Large Scale Platforms in AWS

Photo by Martin Reisch on Unsplash

Why is Tenant Isolation Important?

Building your software ecosystem with tenant isolation baked into the architecture ensures that your business won’t suffer from a cascading compliance or security issue. It can also give your organization flexibility in terms of customizing your solution or services for specific market segments or product tiers.

Where to Start

First and most importantly, establish your requirements for tenant isolation by clarifying the needs of your customers, customer segments and market. Understand the compliance and security profiles & personas of your customers and how many need varying levels of isolation. As well as accurately capture how your customers require their data represented in unique or custom ways.

Developing an Isolation Strategy

For large-scale platforms it’s common to employ a hybrid of multiple isolation models, since it’s unlikely that a one-size-fits-all approach will work for the entirety of a large ecosystem of technologies. In fact, isolation strategies should likely be based on a per service basis.

Drivers for creating your isolation strategy can include: customer security concerns, industry compliance requirements, software customization expectations, legacy systems, product tiering, noisy neighbor considerations, and specific customer requests for data separation / partitioning.

Available AWS Options for Isolation

There are two overarching isolation models in AWS: Silo & Pool.

The Silo Model essentially says each tenant has their own technical stack and you should use course grained controls like separate VPCs and databases to create isolation.

The Pool Model says each tenant lives in a shared environment and you should use fine grained controls like IAM policies & authorization to segment access.

In the Silo Model:

- Isolation via separate VPC’s is common
- Isolation via separate AWS accounts is also effective
- Subnet-based isolation is also an option

In the Pool Model:

- Isolation using run-time policies are common via IAM
- Authorization/Authentication is a strong layer of protection
- API-enforced access is also quite common

Tactical-Level Approaches

At a tactical level, much of your isolation strategy will depend on the technologies and services currently deployed in your infrastructure.

  • Database storage isolation can involve implementing separate databases per tenant (Silo Model) or implementing one database for all tenants with a data model that uses a Tenant ID as a key (Pool Model). The approach here will depend on many factors include the database technologies you’re using. For example, Aurora has Row Level Security and DynamoDB can utilize IAM policies.

Key Challenges

Finding the right mix of isolation models and approaches will become complicated the larger and more diverse your technical infrastructure is.

The challenge is building a well thought out roadmap that over time achieves the levels of isolation your business demands without putting in jeopardy the cost structure, stability, and manageability of your systems.

The process starts by identifying your customers and business requirements, and then carefully establishing the approach on a service-by-service basis.

Other Considerations

  1. Don’t assume code alone will ensure isolation. Mistakes can be made in code.

Technology leader scaling software, teams & business. Amateur mechanic. Book junkie. Enthusiastic garage gym owner. Connect with me on Twitter @bscalable

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store