This deck discusses general best practices of architecting applications in the cloud. It was used in May 2011 Architecture Center webinars. For more information, read the whitepaper available at http://bit.ly/aws-best-practices
3. Cloud Best Practices Whitepaper
Prescriptive guidance to Cloud Architects
http://bit.ly/aws-best-practices
4. Cloud Computing Attributes
Why Architects love the cloud?
Abstract No Servers or Hard drives but Instances and Volumes.
Resources Cloud resources are fungible.
On-Demand Ask for what you need, exactly when you need it. Get rid
Provisioning of it when you don’t need.
Scalability in
minutes
Scale out or in depending on usage needs.
Pay per
consumption
You stop paying for resources when you turn them off
Cloud gives you access to scriptable infrastructure.
Automation
Allows you to automate using APIs.
5. The “Living and Evolving”
The “Living and Evolving” Cloud Cloud
AWS services and basic terminology
Tools to access
services
Cross Service
features
Platform building
blocks
Infrastructure
building blocks
6. Cloud Architecture Lessons
using Amazon Web Services
1. Design for failure and nothing fails
2. Loose coupling sets you free
3. Implement “Elasticity”
4. Build Security in every layer
5. Think Parallel
6. Leverage different storage options
7. 1. Design for Failure
and nothing will really fail
"Everything fails, all the time"
Werner Vogels, CTO Amazon.com
Avoid single points of failure
Assume everything fails, and design backwards
Goal: Applications should continue to function even if the underlying physical
hardware fails or is removed or replaced.
8. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
9. www.example.com
(dynamic traffic) media.example.com
(static load)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Dynamic Data
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
10. www.example.com
(dynamic traffic) media.example.com
(static load)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Amazon SNS Web Server
(notifications) Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Amazon SimpleDB
(Catalog and Config data) Auto Scaling Group
Dynamic Data
Amazon EC2
Amazon CloudWatch Instance
(Monitoring)
EBS
Snapshots
Availability Zone #1
11. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
Use Amazon Elastic Block Store (EBS) Snapshots
12. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
13. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Availability Zone #1
14. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
15. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
16. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
17. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
Use Amazon Elastic Block Store (EBS) Snapshots
Auto-scaling for Auto-Recovery
18. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Amazon Machine Buckets
Static Data
Image App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
19. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Logs
Amazon Machine Buckets
Static Data
Image Amazon S3
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
20. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server
Logs
Static Data Buckets
App Server Amazon S3
Amazon EC2
Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
21. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server Web Server
Logs
Static Data Buckets
App Server App Server Amazon S3
Amazon EC2 Amazon EC2
Instance Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1
22. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
Use Amazon Elastic Block Store (EBS) Snapshots
Auto-scaling for Auto-Recovery
Multi-AZ Data Replication and Recovery
23. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server Web Server
Logs
Static Data Buckets
App Server App Server Amazon S3
Amazon EC2 Amazon EC2
Instance Instance
Auto Scaling Group
Amazon EC2
Instance
EBS
Snapshots
Availability Zone #1 Amazon EC2
Instance
EBS
Availability Zone #2
24. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront
Web Server Web Server
Logs
Static Data Buckets
App Server App Server Amazon S3
Amazon EC2 Amazon EC2
Instance Instance
Auto Scaling Group
Snapshots
Availability Zone #1 Amazon EC2
Instance
EBS
Availability Zone #2
25. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
Use Amazon Elastic Block Store (EBS) Snapshots
Auto-scaling for Auto-Recovery
Multi-AZ Data Replication and Recovery
On-demand application provisioning in a different AZ
26. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Distribution
Amazon
CloudFront
Logs Buckets
Web Server Web Server Static
Data
App Server App Server Amazon S3
Amazon EC2 Amazon EC2
Instance Instance
Auto Scaling Group
Amazon EC2 Amazon EC2
Instance Instance
Synchronous
EBS Replication EBS
Snapshots
Availability Zone #1 Availability Zone #2
27. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Distribution
Amazon
CloudFront
Logs Buckets
Static
Data
Amazon S3
Auto Scaling Group
Amazon EC2 Amazon EC2
Instance Instance
Synchronous
EBS Replication EBS
Snapshots
Availability Zone #1 Availability Zone #2
28. www.example.com
(dynamic data) media.example.com
(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Distribution
Amazon
CloudFront
Logs Buckets
Web Server Web Server Static
Data
App Server App Server Amazon S3
Amazon EC2 Amazon EC2
Instance Instance
Auto Scaling Group
Amazon EC2 Amazon EC2
Instance Instance
Synchronous
EBS Replication EBS
Snapshots
Availability Zone #1 Availability Zone #2
29. Design for Failure with AWS
Tools to make your life easier
Use Fault-tolerant Services as Ingredients of your App
Use Amazon Elastic Block Store (EBS) Snapshots
Auto-scaling for Auto-Recovery
Multi-AZ Data Replication and Recovery
On-demand application provisioning in a different AZ
Multi-AZ Application Deployment and Data replication
30. www.example.com
(dynamic data)
Amazon Route 53 media.example.com
(DNS) (static data)
Elastic Load Balancer LB
Auto Scaling group : Web Tier Auto Scaling group : Web Tier
WebAuto Scaling group : Server
Server Web Web Tier Web Server Web Server
Web Server Web Server App Server Distribution
AppWeb Server AppWeb Server
Server Server App Server
AppWeb Server App Server
Server
App Server App Server
App Server Amazon
Amazon EC2 CloudFront
Amazon EC2
Memcache Memcache Memcache Memcache
Tomcat Tomcat
Memcache Memcache
Tomcat
Cache Tier Cache Tier
Cache Tier
DB Multi-AZ
Buckets
Amazon RDS Slave
Master Read
DB
Replica
Slave
Master
Availability Zone #1 Availability Zone #2 Amazon S3
Availability Zone #3
31. www.example.com
(dynamic data)
Amazon Route 53 media.example.com
(DNS) (static data)
Elastic Load Balancer LB
Auto Scaling group : Web Tier
Auto Scaling group : Web Tier Web Server Web Server
App Server App Server Distribution
Web Server Web Server
App Server App Server
Amazon
CloudFront
Amazon EC2
Memcache Memcache
Tomcat
Memcache Memcache
Tomcat
Cache Tier
Cache Tier
Multi-AZ
Buckets
Slave
DB
Slave
Master
Availability Zone #2 Amazon S3
Availability Zone #3
32. www.example.com
(dynamic data)
Amazon Route 53 media.example.com
(DNS) (static data)
Elastic Load Balancer LB
Auto Scaling group : Web Tier
Auto Scaling group : Web Tier Web Server Web Server
Web Server Web Server Distribution
Web Server Web Server App Server App Server
Web Server Web Server App Server App Server
App Server App Server
App Server App Server Amazon
CloudFront
Amazon EC2
Memcache Memcache
Tomcat
Memcache Memcache
Tomcat
Cache Tier
Cache Tier
Multi-AZ
Buckets
Slave
DB
Slave
Master
Availability Zone #2 Amazon S3
Availability Zone #3
33. 2. Build Loosely Coupled Systems
The looser they're coupled, the bigger they scale
Independent components
Design everything as a Black Box
De-coupling for Hybrid models
Load-balance clusters
Use Amazon SQS as Buffers
Tight Coupling Controller A Controller B Controller C
Q Q Q
Loose Coupling
using Queues Controller A Controller B Controller C
34. 3. Implement Elasticity
Elasticity is fundamental property of the Cloud
Don’t assume health or fixed location of components
Use designs that are resilient to reboot and re -launch
Bootstrap your instances: Instances on boot will ask a
question “Who am I & what is my role?”
Enable dynamic configuration
Use Auto-scaling (Free)
Use Elastic Load Balancing on multiple layers
Use configurations in SimpleDB to bootstrap instance
Use Configuration Management tools like Chef, Puppet, Pallet..
35. 3. Implement Elasticity
Towards elastic architectures
Resilient to reboot and re-launch:
Design the system such that in the event of a failure, it is resilient enough to
automatically re-launch and restart. Forcefully fail and test.
Stateless:
Extract stateful components out and make them stateless
Packable into an AMI:
Package and deploy your application into an AMI so it can run on an Amazon
EC2 instance. Try to run multiple instances of the application on one EC2
instance, if needed. Run multiple instances on multiple Amazon EC2
instances.
Decouple:
Isolate the components using Amazon SQS. Decouple code with deployment
and configuration.
36. 3. Implement Elasticity
Standardized Technology Stacks
Standardized Application Stacks
Apache
Web Server Apache IIS Apache
Mongrel
App Server Tomcat ASP.NET Mongrel
Rails
MVC Struts ASP.NET MVC Rails
Your Code Your Code Your Code Your Code
logger
Libraries Log4J Log4Net logger
RubyGems
Packages Spring Spring.NET RubyGems
memcached
DB Caching Hibernate nHibernate memcached
Ruby Runtime
Framework JEE .NET Ruby Runtime
Centos
OS Linux Windows Centos
Java Stack .NET Stack RoR stack
37. 3. Implement Elasticity
3 Approachesdesigning your AMIs
3 approaches to to design MDE
Easier to Setup
Inventory of fully baked AMIs
(Frozen Pizza Model)
“Golden AMIs” with fetch on boot
(Take N’ Bake Papa Murphy Model)
AMIs with JeOS and “Chef” Agent
(Made to Order Pizza Model)
More Control
Easier to maintain
38. 3. Implement Elasticity
3 ApproachesPizza design MDE
1. Frozen to Model
Apache
Apache
Tomcat Tomcat
Struts Struts
IIS IIS
Your Code Your Code IIS
ASP.NET MVC
IIS
IIS
IIS
ASP.NET MVC
IIS
Your Code ASP.NET MVC
Your Code
IIS
Log4Net Log4Net
Your Code
ASP.NET MVC
Log4J Spring.NET
Log4Net
Spring.NET
Log4J
Your Code
nHibernate nHibernate
Spring.NET
Log4Net
.NET .NET
nHibernate
Spring.NET
Windows Windows
Spring
.NET
nHibernate
Windows
.NET
Spring Windows
Hibernate
Hibernate Amazon EC2
JEE
JEE Linux
Linux
.NET Stack Java AMI
39. “GoldenImplement on boot
3. AMIs” with fetch Elasticity
3 Approaches to design MDE
2. Take N Bake Pizza Model
Apache Your
Code Fetch on boot time
Source Control
Tomcat
Struts Struts
Log4J
Spring
Your Code IIS
Amazon S3 IIS IIS
IIS IIS
IIS
IIS
Log4J .NET
Windo .NET
ws
IIS
.NET
Windo .NET Windo
Apache ws ws
Windo
Spring ws
Tomcat
Hibernate Hibernate
JEE
Amazon EC2
JEE
Linux
Linux
Java Stack Java AMI
40. 3. Implement Elasticity
3 Approaches toPizza Model MDE
3. Made to Order design
Apache Your
Code Cookbooks
Tomcat Source Control
Recipes
Struts
Apache Chef Server
Your Code Struts
Tomcat
Log4J
Hibernat
Log4J e Spring
CHEF
Agent
Spring Amazon S3
Windows
Hibernate
CHEF Agent
JEE
Linux
Amazon EC2
Linux
Java Stack AMI (JeOS)
41. 3. Implement Elasticity
3 Approachesdesigning your AMIs
3 approaches to to design MDE
Easier to Setup
Inventory of fully baked AMIs
(Frozen/Ready made)
“Golden AMIs” with fetch on boot
(Take N’ Bake)
AMIs with JeOS and “Chef” Agent
(Made to Order)
More Control
Easier to maintain
42. 4. Build Security in every layer
Design with Security in mind
In the Cloud, Security is a Shared
Responsibility and it has to be
implemented in every layer
43. In the cloud, Security is a Shared Responsibility
Encrypt data in transit
SAS 70 Type II Audit
Encrypt data at rest
ISO 27001/2 Certification
Protect your AWS Credentials
PCI DSS 2.0 Level 1-5
Rotate your keys
HIPAA/SOX Compliance
Infrastructure Application Secure your application, OS,
FISMA A&A Low
Security Security Stack and AMIs
How we secure our How can you secure your
infrastructure application and what is
your responsibility?
Services Security
Enforce IAM policies
What security options
Use MFA, VPC, Leverage S3
and features are available
bucket policies, EC2 Security
to you?
groups, EFS in EC2 Etc..
44. www.example.com
(dynamic data)
Amazon Route 53
media.example.com
(DNS)
(static data)
Elastic Load LB
# Permit HTTP(S) access to Web Balancer
Layer from the Entire Internet
ec2auth Web -p 80,443 -s 0.0.0.0/0
Distribution Amazon
Web Server CloudFront
Web Server
App Server App Server
Auto Scaling group : Web Tier
# Permit Web Layer access to App
Amazon EC2
Layer
ec2auth App -p 8000 –o Web
Memcache Memcache
Tomcat
# Permit App Layer access to DB
ec2auth DB -p 3209 –o App Cache Tier
# Permit admin access SSH to all Amazon S3
RDS Buckets
three layers
Master
# First allow connection from
office to Web tier, and from there
to the other layers Availability Zone #1
ec2auth Web -p 22 -s <for example,
network block of your office> RDS
ec2auth App -p 22 -o Web Slave
Availability Zone #2
ec2auth DB -p 22 -o Web
45. 5. Think Parallel
Serial and Sequential is now history
Experiment different architectures in parallel
Multi-treading and Concurrent requests to cloud services
Run parallel MapReduce Jobs on Amazon Elastic MapReduce
Use Elastic Load Balancing to distribute load across multiple servers
Decompose a Job into its simplest form
46. 6. Leverage many storage options
Use Scalable Ingredients
Amazon S3: large static objects
Amazon Cloudfront: content distribution
Amazon SimpleDB: simple data indexing/querying
Amazon EC2 local disc drive : transient data
Amazon EBS: persistent storage for any RDBMS + Snapshots on S3
Amazon RDS: RDBMS service - Automated and Managed MySQL
47. 6. Leverage many storage options
Which storage option to use when?
Amazon S3 + Amazon EC2 Amazon EBS Amazon Amazon RDS
CF Ephemeral SimpleDB
Store
Ideal for Storing Large Storing non- Off-instance Querying light- Storing and
write-once, persistent persistent weight attribute querying
read-many transient storage for any data structured
types of updates kind of data, Relational and
objects, Static referential
Content Data
Distribution
Ideal examples Media files, Config Data, Clusters, boot Querying, Complex
audio, video, scratch files, data, Log or Mapping, transactional
images, TempDB data of tagging, click- systems,
Backups, commercial stream logs, inventory
archives, RDBMS like metadata, management
versioning Oracle, DB2 shared-state and order
management, fulfillment
indexing systems
Not Querying, Storing Relational (joins)
recommended Searching Database logs query
for or backups,
customer data
Not Database, File Sensitive data Content OLTP, DW cube Simple
recommended Systems Distribution rollups lookups
examples
48. Cloud Architecture Lessons
Best Practices
1. Design for failure and nothing fails
2. Loose coupling sets you free
3. Implement Elasticity
4. Build Security in every layer
5. Think Parallel
6. Leverage many storage options
49. Additional Info..
AWS Architecture Center - http://aws.amazon.com/architecture
AWS Premium Support - http://aws.amazon.com/premiumsupport
AWS Blog – http://aws.amazon.com/blog
Photo: Grand Canyon Hopi Point SunSet