Shared pools of resources? Microservices in containers? Isolated application stacks? You have many architectural models and AWS services to consider when you deploy applications on AWS. This session focuses on several common models and helps you choose the right path or paths to fit your application needs. Architects and operations managers should consider this session to help them choose the optimal path for their application deployment needs for their current and future architectures. This session covers services such as Amazon Elastic Compute Cloud (Amazon EC2), EC2 Container Services, AWS Lambda, and AWS CodeDeploy.

1. © 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

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

3. Key Challenges in Multi-Tenant Architectures
 Request routing and handling
 Change management
 Data security and isolation
 Deployment patterns

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

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

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

7. Legacy Refactored Migrating
Service 2
The Bridge: Architecture Example
Auto
Scaling
Auto
Scaling
DataServicesLayer
Service 1
ELB
ELB
ELB
ELB
EC2
EC2
EC2
ECS
ECS
RDS
DynamoDB
S3

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

9. The Pool: Architectural Example
Auto
Scaling
Service 1
Service 2
Service 3
ELB
ECS
RDS
DynamoDB
DynamoDB
EC2
ECS
Elastic
Beanstalk
ELB
ELB
ELB

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

11. The Serverless: Architectural Example
Amazon SWF
ELB
ELB
DynamoDB
Lambda
LambdaAmazon
Kinesis
API Gateway

12. Addressing Challenges in
Each Pattern

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

14. The Retro: Architecture Example
Auto
Scaling
Auto
Scaling
Auto
Scaling
Auto
Scaling
ELB
ELB
EC2
EC2
EC2
EC2
RDS
RDS

15. Legacy Refactored Migrating
Service 2
The Bridge: Architecture Example
Auto
Scaling
Auto
Scaling
DataServicesLayer
Service 1
ELB
ELB
ELB
ELB
EC2
EC2
EC2
ECS
ECS
RDS
DynamoDB
S3

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

17. Change Management
 Rolling out new versions
 Running multiple versions side by side
 Handling massive fleet deployment

18. The Retro: Architecture Example
ELB
Auto
Scaling
Auto
Scaling
EC2 EC2
Auto
Scaling
Auto
Scaling
EC2 EC2
RDS

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

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

21. Data Security and Isolation
 Ensuring rights and permissions at every tier
 Protecting data from insecure access
 Isolating data between tenants

22. The Retro: Architecture Example
Auto
Scaling
Auto
Scaling
Auto
Scaling
Auto
Scaling
ELB
ELB
EC2
EC2
EC2
EC2
RDS
RDS
KMS

23. Legacy Refactored Migrating
Service 2
The Bridge: Architecture Example
Auto
Scaling
Auto
Scaling
DataServicesLayer
Service 1
ELB
ELB
ELB
ELB
EC2
EC2
EC2
ECS
ECS
RDS
DynamoDB
S3
KMS

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

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

26. Thank you!

27. Remember to complete
your evaluations!

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