© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Matt Tavis, AWS Principal Solutions Architect

October 2015

ARC340

Multi-Tenant Application

Deployment Models

What to Expect from the Session

Key challenges of multi-tenant architectures

Common deployment models for multi-tenant

architectures

Common strategies for addressing challenges in each

model

What Not to Expect

Multi-account, multi-VPC strategies

Detailed IAM security strategies

Key Challenges in Multi-Tenant Architectures

Request routing and handling

Change management

Data security and isolation

Deployment patterns

Pattern 1: The Retro

Deploy an entire application stack per tenant

Isolation at the AWS resource level (e.g., EC2 instance,

ELB, RDS instance, …)

When to consider:

Black box applications – packaged software, legacy apps…

Snowflakes configurations – every install is different…

Low-effort but with cloud-scale

Challenges:

Cost efficiency, resource management (aka “urban sprawl”)

This is *not* modern cloud architecture

The Retro: Architecture Example

Auto

Scaling

Auto

Scaling

Auto

Scaling

Auto

Scaling

Auto

Scaling

Auto

Scaling

ELB

ELB

ELB

EC2

EC2

EC2

EC2

EC2

EC2

RDS

RDS

RDS

Pattern 2: The Bridge

Hybrid model to bridge from Retro to modern

Leverage “containerization” to drive greater efficiency

Drive request context throughout architecture

When to consider:

See the Retro – same reasons plus…

Transitioning to SOA/μServices – enabling re-factoring

Blending monolithic components into a modern architecture

Challenges:

Multiple change management approaches

Refactoring to a shared services model

Legacy Refactored Migrating

Service 2

The Bridge: Architecture Example

Auto

Scaling

Auto

Scaling

Data

Serv

ices L

ayer

Service 1

ELB

ELB

ELB

ELB

EC2

EC2

EC2

ECS

ECS

RDS

DynamoDB

S3

Pattern 3: The Pool

All resources are shared across all tenants

Any service can handle any request from any tenant

Pure services models embracing “share nothing”

architecture

When to consider:

Always – usually new app development

SOA/μServices and Service Ownership is embraced

Challenges:

Factoring out request context, state, and data locality

Evolving state through deployment

The Pool: Architectural Example

Auto

Scaling

Service 1

Service 2

Service 3

ELB

ECS

RDS

DynamoDB

DynamoDB

EC2

ECS

Elastic

Beanstalk

ELB

ELB

ELB

Pattern 4: The Serverless

Event-driven model for service interactions

No (or few) managed server instances

Leverages AWS managed scalable services

When to consider:

IoT, batch/event processing, mobile apps – new architectures

Async-oriented interaction models

Challenges:

Transient nature of processing and debugging

Monitoring state of fully transient system

The Serverless: Architectural Example

Amazon SWF

ELB

ELB

DynamoDB

Lambda

LambdaAmazon

Kinesis

API Gateway

Addressing Challenges in

Each Pattern

Request Routing and Processing Challenges

Routing the request or processing any request

Sufficient context at every layer to properly process

Scaling the environment consistent with volume

The Retro: Architecture Example

Auto

Scaling

Auto

Scaling

Auto

Scaling

Auto

Scaling

ELB

ELB

EC2

EC2

EC2

EC2

RDS

RDS

Legacy Refactored Migrating

Service 2

The Bridge: Architecture Example

Auto

Scaling

Auto

Scaling

Data

Serv

ices L

ayer

Service 1

ELB

ELB

ELB

ELB

EC2

EC2

EC2

ECS

ECS

RDS

DynamoDB

S3

Request Routing and Processing - Comparison

Unique endpoints

per tenant stack

Dedicated

resources

Dedicated data

stores

Dedicated

endpoints if

needed

Request context

flows through

Shared resources

where refactored

Try containers

Shared endpoints

for all

Complete context

flows through

Data stores

wrapped by

services

Complete context

in the event

(metadata)

Tenant IDs are 1st

class construct

Use Tenant IDs for

auth and auth

Retro Bridge Pool Serverless

Change Management

Rolling out new versions

Running multiple versions side by side

Handling massive fleet deployment

The Retro: Architecture Example

ELB

Auto

Scaling

Auto

Scaling

EC2 EC2

Auto

Scaling

Auto

Scaling

EC2 EC2

RDS

The Pool: Architectural Example

Auto

Scaling

Service 1

Service 2

Service 3

ELB

ECS

RDS

DynamoDB

DynamoDB

EC2

ECS

Elastic

Beanstalk

ELB

ELB

ELB

CodeDeploy

Change Management

Each stack stands

alone

vNext cutover or

true blue/green

Application repo &

infra code repo

Adopt ALM

solution for future

Treat each service

individually

Flexibility for

dedicated

endpoints

Rolling deploy for

shared services –

handle rollback

Data location

services for data

migrations

Treat each service

individuaily

Rolling deploy for

all services –

handle rollback

Data sources

always hidden

behind service

layer

Leverage API

Gateway deploy

Embed versioning

into API Gateway

call

Update Lambda

function directly or

“cutover” through

API Gateway

resource

mappings

Retro Bridge Pool Serverless

Data Security and Isolation

Ensuring rights and permissions at every tier

Protecting data from insecure access

Isolating data between tenants

The Retro: Architecture Example

Auto

Scaling

Auto

Scaling

Auto

Scaling

Auto

Scaling

ELB

ELB

EC2

EC2

EC2

EC2

RDS

RDS

KMS

Legacy Refactored Migrating

Service 2

The Bridge: Architecture Example

Auto

Scaling

Auto

Scaling

Data

Serv

ices L

ayer

Service 1

ELB

ELB

ELB

ELB

EC2

EC2

EC2

ECS

ECS

RDS

DynamoDB

S3

KMS

Data Security and Isolation

Unique resources

end to end

IAM roles for

resource access

Consider unique

encryption keys

per tenant with

KMS

Embed data

access

authorization in

shared layers

Leverage tenant

identity in context

for access and

encryption

Use unique

encryption keys

per tenant via

KMS

Embed data

access

authorization in

shared layers

Leverage tenant

identity in context

for access and

encryption

Use unique

encryption keys

per tenant via

KMS

Secure API

Gateway with IAM

Embed data

access

authorization into

Lambda functions

Leverage tenant

identity for access

and encryption

Use unique

encryption keys

per tenant via

KMS

Retro Bridge Pool Serverless

TL;DL – Too Long; Didn’t Listen

Legacy

Arch? Go Retro

Dive into

Pool

Event-

based

Model?

Bliss with

Serverless

Refactor

to Bridge

Fight inertia!Crack the code

Learn to share

Embrace the Cloud

Share and share alike

Learn to let go

Yes

No

No

Yes

Go SOA & μServices

Share nothing

Think async

Qui(e)t SSH

Leverage what you have

Measure what you do

Thank you!

Remember to complete

your evaluations!

Related Sessions

ARC201 - Microservices Architecture for Digital

Platforms with AWS Lambda, Amazon CloudFront and

Amazon DynamoDB

DVO401 - Deep Dive into Blue/Green Deployments on

AWS

ARC309 - From Monolithic to Microservices: Evolving

Architecture Patterns in the Cloud