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