Join us to get a better understanding around architecting scalable, reliable applications for the cloud. You'll learn about monitoring, alarming, automatic scaling, load balancing, replication, and more, direct from AWS Senior Evangelist Jeff Barr.

1. Best Practices in
Architecting for the
Cloud
Jeff Barr Senior Evangelist jbarr@amazon.com

2. Cloud Best Practices Whitepaper
Prescriptive guidance to Cloud Architects
http://bit.ly/aws-best-practices

3. Abstract
Resources
No Servers or Hard drives but Instances and Volumes.
Cloud resources are fungible.
On-Demand
Provisioning
Ask for what you need, exactly when you need it. Get rid
of it when you don’t need.
Scalability in
Minutes
Scale out or in depending on usage needs.
Pay On
Consumption
You stop paying for resources when you turn them off
Automation
Cloud gives you access to scriptable infrastructure.
Allows you to automate using APIs.
Cloud Computing Attributes
Why Architects love the cloud?

4. The “Living and Evolving” CloudThe “Living and Evolving” Cloud
AWS services and basic terminology
Infrastructure
building blocks
Platform building
blocks
Tools to access
services
Cross Service
features

5. The “Living and Evolving” CloudAWS Building Blocks
Inherently Fault-Tolerant
Services
Fault-Tolerant
with the right
architecture Amazon S3
 Amazon
DynamoDB
 Amazon
CloudFront
 Amazon SWF
 Amazon SQS
 Amazon SNS
 Amazon SES
 Amazon Route53
 Elastic Load
Balancing
 AWS IAM
 AWS Elastic
Beanstalk
 Amazon
ElastiCache
 Amazon EMR
 Amazon
CloudSearch
 Amazon
Redshift
 Amazon EC2
 Amazon EBS
 Amazon RDS
 Amazon VPC

6. Scalability
Characteristics of Truly Scalable Service
Build a Scalable Architecture on AWS
A scalable architecture is critical to take advantage of a scalable
infrastructure
Increasing resources results in a proportional increase in
performance
A scalable service is operationally efficient
A scalable service is resilient
A scalable service becomes more cost effective when it
grows

7. Cloud Architecture Lessons
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
using Amazon Web Services

8. 1. Design for Failure
"Everything fails, all the time"
Werner Vogels, CTO Amazon.com
and nothing will really fail
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.

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

10. 2. Build Loosely Coupled Systems
The looser they're coupled, the bigger they scale
Independent components
Design everything as a Black Box
De-couple for Hybrid models
Load-balance clusters
Controller A Controller B Controller C
Controller A Controller B Controller C
Q Q Q
Tight Coupling
Loose Coupling
using Queues
Use Amazon SQS as Buffers

11. 3. Implement Elasticity
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
Elasticity is fundamental property of the Cloud
Use Auto Scaling
Use Elastic Load Balancing on multiple layers
Use configurations in DynamoDB to bootstrap instance
Use Configuration Management tools like Chef & Puppet…

12. 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 (Chaos Monkey).
Stateless:
Extract stateful components and strive to make them stateless.
Packable into an AMI:
Package and deploy your application into an AMI so it can run on an Amazon
EC2 instance. Run multiple instances on multiple Amazon EC2 instances.
Decouple:
Isolate the components using Amazon SQS. Decouple code with deployment
and configuration.

13. Standardized Technology Stacks
Use a Chaos Monkey
Standardized Application Stacks

14. 4. Build Security in every layer
In the Cloud, Security is a Shared
Responsibility and it has to be
implemented in every layer
Design with Security in mind

15. SOC 1, 2, 3
ISO 27001/2 Certification
PCI DSS 2.0 Level 1-5
HIPAA/SOX Compliance
FedRAMP
FISMA & DIACAP
ITAR
Enforce IAM policies
Use MFA, VPC, Leverage S3
bucket policies, EC2 Security
groups, EFS in EC2 Etc..
Encrypt data in transit
Encrypt data at rest
Protect your AWS Credentials
Rotate your keys
Secure your application, OS,
Stack and AMIs
In the cloud, Security is a Shared Responsibility
Application
Security
Services Security
Infrastructure
Security
How we secure our
infrastructure
What security options
and features are available
to you?
How can you secure your
application and what is
your responsibility?

16. Availability Zone #2
RDS
Slave
Availability Zone #1
Cache Tier
Auto Scaling group : Web Tier
RDS
Master
Elastic Load
Balancer
Memcache
LB
Tomcat
Memcache
Distribution
Buckets
Amazon
CloudFront
Amazon S3
www.myphpwebsite.com
(dynamic data)
media.myphpwebsite.com
(static data)
Amazon Route 53
(DNS)
Amazon EC2
# Permit HTTP(S) access to Web
Layer from the Entire Internet
ec2auth Web -p 80,443 -s 0.0.0.0/0
# Permit Web Layer access to App
Layer
ec2auth App -p 8000 –o Web
# Permit App Layer access to DB
ec2auth DB -p 3209 –o App
# Permit admin access SSH to all
three layers
# First allow connection from
office to Web tier, and from there
to the other layers
ec2auth Web -p 22 -s <for example,
network block of your office>
ec2auth App -p 22 -o Web
ec2auth DB -p 22 -o Web
Web Server
App Server
Web Server
App Server

17. 5. Think Parallel
Experiment with different architectures in parallel
Multi-threading 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
Serial and Sequential is now history

18. Hadoop
Amazon
Elastic
MapReduce
Cluster
Compute
HPC
Spot
Instances
Expand/
Shrink
Elastic
Super
computer
Distributed
Processing
Framework
On-demand
Infrastructure
(Cloud) +
Automation
Each VM =
2 Xeon
“Nehalem”
Quad-core
10G Ethernet
2 GPGPUs
Cost savings
due to lower
“Spot price”
(Time-insensitive
tasks)
Expand or
Shrink a
running
cluster
Big Data
power
house
5. Think Parallel
This is where AWS really shines..

19. 6. Leverage many storage options
Amazon S3: large static objects
Amazon Cloudfront: content distribution
Amazon DynamoDB : 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
Amazon Redshift: Data warehouse service
Use Scalable Ingredients

20. 6. Leverage many storage options
Which storage option to use when?
Amazon S3 +
CloudFront
Amazon
EC2
Ephemeral
Store
Amazon EBS Amazon
DynamoDB
Amazon RDS Amazon
Redshift
al for Storing Large
write-once,
read-many
types of
objects, Static
Content
Distribution
Storing non-
persistent
transient
updates
Off-instance
persistent
storage for any
kind of data
Querying light-
weight attribute
data
(SimpleDB)
Highly scalable
applications
(DynamoDB)
Storing and
querying
structured
Relational and
referential
Data
Storing and
rapidly
querying
vast
amounts of
Relational
data
al examples Media files,
audio, video,
images,
Backups,
archives,
versioning
Config Data,
scratch files,
TempDB
Clusters, boot
data, Log or
data of
commercial
RDBMS like
Oracle, DB2
Querying,
Mapping,
tagging, click-
stream logs,
metadata,
shared-state
management,
indexing
Complex
transactional
systems,
inventory
management
and order
fulfillment
systems
Enterprise
data
warehouse,
DW cube
lookups
ommended
Querying,
Searching
Storing
Database
logs or
backups,
customer
data
Relational
(joins) query
Moderately
sized data
sets
Database, File Sensitive Content OLTP, DW cube Simple Simple

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

22. Photo: Grand Canyon Hopi Point SunSet
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

23. jbarr@amazon.com
Twitter: @jeffbarr
Thank you!

24. http://aws.amazon.com