This document discusses several best practices for architecting applications for the cloud. It begins by outlining three approaches for architecting applications in AWS: deploying existing apps with minimal changes, evolving apps to leverage more AWS services, and designing apps from the start to be cloud-native. It then discusses seven cloud architecture best practices: designing for failure, building security at every layer, leveraging different storage options, implementing elasticity, thinking parallel, loose coupling, and not fearing constraints. For each best practice, it provides examples and recommendations.

1. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWSOME DAY
Architecting for The Cloud - Best
Practices
Herman Mak
Solutions Architect – AWS

2. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Architecting Approaches for AWS
• Deploy existing apps in AWS with minimal re-design
• Good strategy if starting out on AWS, or if application can’t be re-
architected due to cost or resource constraints
• Primarily use core services such as EC2, EBS, VPC
Lift-and-shift
• Evolve architecture for existing app to leverage AWS services
• Gain cost and performance benefits from using AWS services such
as Auto Scaling Groups, RDS, SQS, and so on
Cloud-optimized
• Architect app to be cloud-native from the outset
• Leverage the full AWS portfolio
• Truly gain all the benefits of AWS (security, scalability, cost,
durability, low operational burden, etc)
Cloud-native
architecture

3. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Cloud Architecture Best Practices
1. Design for failure and nothing fails
2. Build security in every layer
3. Leverage different storage options
4. Implement elasticity
5. Think parallel
6. Loose coupling sets you free
7. Don’t fear constraints
8. Use Caching

4. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
1
Design for Failure
and Nothing Fails

5. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Werner Vogels
(CTO, Amazon.com)
“Everything fails,
all the time”

6. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: A Single User
Single Points of Failure:
• A single Elastic IP
• Gives a server a static Public IP
address
• A single Amazon Elastic Compute
Cloud (EC2) instance
• Full stack on single host
• Web application
• Database
• Management, etc…
EC2 Server
Elastic IP
address
User
AWS Cloud
Amazon Route 53
(DNS)

7. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: Difficulties Scaling to Many
Users
We could potentially get to a few
hundred to a few thousand users
depending on application
complexity and traffic, but…
There may be difficulty scaling to
many more users due to:
• All eggs in one basket
• No failover or redundancy
Users
EC2 Server
Elastic IP
address
AWS Cloud
Amazon Route 53
(DNS)

8. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: Solving “All Eggs in One
Basket”
Separate single EC2 Server into web
and database tiers:
• Web Server on EC2
• Database on EC2 or RDS
 Amazon Relational Database
Service (RDS) can take care of
management overhead such as
patching, backups, and failure
detection
Users
Web Server
Elastic IP
address
Database
AWS Cloud
Amazon Route 53
(DNS)

9. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Leverage multiple Availability Zones
for redundancy and high availability.
• Use an Elastic Load Balancer
(ELB) across AZs for availability
and failover
• If using RDS, use the Multi-AZ
feature for managed replication
and a standby instance
• If not, use failover and
replication features native to
your database engine
Database Master Database Standby
AZ 1 AZ 2
Design for Failure: Solving No
Failover/Redundancy
Users
Web Server Web Server
AWS Cloud
Amazon Route 53
(DNS)

10. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: Best Practices
Best Practices:
• Eliminate single points of failure
• Use multiple Availability Zones
• Use Elastic Load Balancing
• Do real-time monitoring with
CloudWatch
• Create a database standby across
Availability Zones
Database Master Database Standby
AZ 1 AZ 2
Users
Web Server Web Server
AWS Cloud
Amazon Route 53
(DNS)

11. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: Best Practices
Best Practices:
• Eliminate single points of failure
• Use multiple Availability Zones
• Use Elastic Load Balancing
• Do real-time monitoring with
CloudWatch
• Create a database standby across
Availability Zones
Database Master Database Standby
AZ 1 AZ 2
Users
Web Server Web Server
AWS Cloud
Amazon Route 53
(DNS)

12. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure: Best Practices
Best Practices:
• Eliminate single points of failure
• Use multiple Availability Zones
• Use Elastic Load Balancing
• Do real-time monitoring with
CloudWatch
• Create a database standby across
Availability Zones
Database Master Database Standby
AZ 1 AZ 2
Users
Web Server Web Server
AWS Cloud
Amazon Route 53
(DNS)

13. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
On-Premises
Colocation Facility – e.g., Equinix HK1
Private VIF
Public VIF
VLAN B
VLAN A
AWS Direct
Connect POP
Customer or
Partner Cage
Service Provider
Network
AWS Direct Connect
AWS Direct Connect helps increase bandwidth throughput, provide stable
connectivity for Hybrid Architectures

14. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Hong Kong Direct Connect POP Locations
iAdvantage Mega-iEquinix HK1

15. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Design for Failure
Avoid single points of failure
Assume everything fails and design backwards
• When, not if, an individual component fails, the application
does not fail
• Think of your servers as cattle, not pets
• Leverage Route 53 DNS Pilot-light or Warm-standby
strategies to implement Disaster Recovery
• Auto Scaling groups can be used to detect failures and self-
heal, thus protecting against AZ level outages

16. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
2
Build Security in
Every Layer

17. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
HTTP: 80
Corporate Network
EC2EC2 EC2

18. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
EC2EC2 EC2
Encrypt data in
transit and at rest HTTPS: 443
IPSEC VPN
Corporate Network
Key
Management
Service

19. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
EC2EC2 EC2
Enforce principle
of least privilege
with IAM
Key
Management
Service
HTTPS: 443
IPSEC VPN
Corporate Network
IAM

20. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
EC2EC2 EC2
Create firewall
rules with
Security Groups
and NACLs
HTTPS: 443
IPSEC VPN
Corporate Network
Key
Management
Service
IAM

21. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
EC2EC2 EC2
DDoS Protection
and Application
Firewall with
Shield and WAF
HTTPS: 443
IPSEC VPN
Corporate Network
Amazon
CloudFront
AWS Shield
AWS WAF
Key
Management
Service
IAM

22. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Build Security in Every Layer
More Tools for your Security Toolbox:
• Amazon Inspector
• Amazon Certificate Manager
• Amazon Macie
• Amazon GuardDuty
• AWS Config

23. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
3
Leverage Many
Storage Options

24. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Leverage Many Storage Options
One size does NOT fit all
• Amazon Elastic Block Storage (EBS) – persistent block
storage
• Amazon EC2 Instance Storage – ephemeral block storage
• Amazon RDS – managed relational database
• Amazon CloudFront – content distribution network
• Amazon S3 – object/blob store, good for large objects
• Amazon DynamoDB – non-relational data (key-value)
• Amazon ElastiCache – managed Redis or Memcached

25. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Leverage Many Storage Options
Current State:
• All load handled by one stack
• Elastic Load Balancer
(ELB)
• EC2 Web App cluster
• Relational Database
• No caching layer(s)
• All persistent data in database or
Web instances’ Elastic Block
Storage (EBS) volumes
DNS
(Route 53)
Web Instances
Relational
Database
Users

26. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Leverage Many Storage Options
Offload and cache requests for
static assets:
• Store large/static objects in
Simple Storage Service
(S3)
• Use a Content Delivery
Network (CDN) like
CloudFront to cache
responses using points of
presence all around the
world
Amazon S3
Amazon
CloudFront
DNS
(Route 53)
Web Instances
Relational
Database
Users

27. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Leverage Many Storage Options
Save user session data in a
database to avoid interrupting
the user experience if a web
host becomes unresponsive:
• Store session/state data in
DynamoDB, a managed
NoSQL key-value store
DynamoDB
Amazon S3
Amazon
CloudFront
DNS
(Route 53)
Web Instances
Relational
Database
Users

28. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
ElastiCache
Leverage Many Storage Options
DynamoDB
Amazon S3
Amazon
CloudFront
DNS
(Route 53)
Web Instances
Relational
Database
Users
Cache frequent queries to shift
the load off of your database:
• Put ElastiCache as a
caching layer between the
web hosts and the database

29. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
4
Implement Elasticity

30. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Provisioned capacity
Actual Traffic
November traffic to Amazon.com

31. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
November traffic to Amazon.com
76%
24%
Provisioned capacity
Actual Traffic

32. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
November traffic to Amazon.com
Provisioned capacity
Actual Traffic

33. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Implement Elasticity
How To Guide:
• Write Auto Scaling policies with your specific application access
patterns in mind
• Prepare your application to be flexible: don’t assume the health,
availability, or fixed location of components
• Architect resiliency to reboot and relaunch
• When an instance launches, it should ask “Who am I and
what is my role?”
• Leverage highly scalable, managed services such as S3 and
DynamoDB

34. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Load Test using testing tools available online

35. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Availability Zone 2
RDS DB
instancestandby
(multi-AZ)
RDS DB
instance
Availability Zone 1
Elastic Load
Balancing
Elastic Load
Balancing
Auto-Scaled
EC2
Instances
Auto-Scaled
EC2
Instances
AMI, Tools &
Scripts
AWS Region 2
AWS Region 1
AWS Region 3
AWS Region 4

36. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
5
Think Parallel

37. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Think Parallel
Scale Horizontally, Not Vertically
• Decouple compute from state/session data
• Use ELBs to distribute load
• Break up big data into pieces for distributed processing
• AWS Elastic Map Reduce (EMR) – managed Hadoop

38. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Example – Data Processing
Store Process Store
After 4 hours
Generic
database
Instance Generic
database

39. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Example – Data Processing
Store Process Store
Generic
database
Generic
database
Cluster
After 1 hour

40. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Hour 1 Hour 2 Hour 3 Hour 4
• One Server working for Four
hours costs the same as Four
servers working for One hour
• Combine with elasticity to
increase capacity when you
need it most
• The beauty of the cloud
shines when you combine
elasticity and parallelization
Think Parallel
Faster doesn’t need to mean more expensive!

41. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Think Parallel
Parallelize using native managed services
• Get the best performance out of S3 with parallelized
reads/writes
• Multi-part uploads (API) and byte-range GETs (HTTP)
• Take on high concurrency with Lambda
• Initial soft limit: 1000 concurrent requests per region

42. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
6
Loose Coupling
Sets You Free

43. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Loose Coupling Sets You Free: Queueing
Use Amazon Simple Queue Service (SQS) to pass
messages between loosely coupled components
Tight coupling
Loose coupling

44. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Nearly everything in AWS is
an API call. Leverage AWS
Native Services for…
• Queuing
• Transcoding
• Search
• Databases
• Email
• Monitoring
• Metrics
• Logging
• Compute
Amazon
CloudSearch
Amazon SQS
Amazon SNS
Amazon SES
AWS Lambda
Amazon
CloudWatch
Amazon RDS
AWS CloudTrail
Amazon
ElasticSearch
Loose Coupling Sets You Free: Don’t Reinvent the
Wheel
Amazon Elastic
Transcoder

45. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
S3 Bucket
Lambda
Push: Event
Notification
DynamoDB
Pull: DynamoDB
Stream
Amazon
Kinesis
Pull:
Kinesis Stream
SQS
messages
Get
Message
Instance
Put
Message
Instance
Amazon SNS
Topic
Publish
Notification
Queue Is
Subscribed to
Topic
Loose Coupling Sets You Free
Using SNS and SQS to asynchronously scale:
Using Lambda triggers to
decouple actions:

46. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Example – Voting System
Vote Store Report
Mobile
client
Client
Instance Generic
database
Office
After 24 hoursPush

47. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Example – Voting System
Vote Store Report
Mobile
client
Client
Instance Generic
database
Office
After 24 hoursPush

48. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Example – Voting System
Vote Store
Mobile
client
Client
Instance Generic
database
Queue
Report
Office
After 24 hoursPullPush

49. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
7
Don’t Fear
Constraints

50. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Don’t Fear Constraints
Rethink traditional architectural constraints
Need more RAM?
• Don’t: vertically scale
• Do: distribute load across machines or a shared cache
Need better IOPS for database?
• Don’t: rework schema/indexes or vertically scale
• Do: create read replicas, implement sharding, add a caching layer
Hardware failed or config got corrupted?
• Don’t: waste production time diagnosing the problem
• Do: “Rip and replace” – stop/terminate old instance and relaunch
Need a Cost Effective Disaster Recovery (DR) strategy?
• Don’t: double your infrastructure costs when you don’t need to
• Do: implement Pilot Light or Warm Standby DR stacks

51. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
8
Use Caching

52. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Availability Zone 2
RDS DB
instancestandby
(multi-AZ)
RDS DB
instance
Availability Zone 1
Elastic Load
Balancing
Elastic Load
Balancing
Auto-Scaled
EC2
Instances
Auto-Scaled
EC2
Instances

53. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Availability Zone 2
RDS DB
instancestandby
(multi-AZ)
RDS DB
instance
Availability Zone 1
Elastic Load
Balancing
Elastic Load
Balancing
Auto-Scaled
EC2
Instances
Auto-Scaled
EC2
Instances
Amazon
CloudFront
S3 Bucket

54. © 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Cloud Architecture Best Practices
1. Design for failure and nothing fails
2. Build security in every layer
3. Leverage different storage options
4. Implement elasticity
5. Think parallel
6. Loose coupling sets you free
7. Don’t fear constraints
8. Use Caching

55. Thank you!
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWSOME DAY
Architecting for The Cloud: Best Practices
https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf
Herman Mak
Solutions Architect – AWS