This document discusses scaling web applications on AWS. It provides the following key points: 1. Loose coupling of application components allows them to scale independently and improves fault tolerance. Data and services should reside outside components that need to scale. 2. Architecting for horizontal scaling across multiple servers or instances allows applications to scale more easily than vertical scaling on single, larger instances. 3. Session and application state should be stored in a separate, scalable service like DynamoDB to avoid bottlenecks. 4. AWS services like ELB, Auto Scaling, RDS, DynamoDB and S3 help applications scale dynamically based on load and eliminate the need to manage infrastructure.

1. Glenn Gore
Building Web Scale Applications with AWS
Sr. Manager, Solutions Architects, AWS

2. I am Barack Obama, Ask me anything
Reddit Needed to Scale for a special guest
• 2,987,307 pageviews on the day of the IAmA
• President Obama’s user page received 428,004
pageviews on the day of the IAMA
• Added 60 dedicated instance to handle the increased
load
• At peek transfering 48 MB/s to the internet

3. While You’re Scaling
• Architect for Failure
– Failures do happen
– Internet is unpredictable
– People are unpredictable
• Architect with Security
– Security must happen
– Security is multi-layered
– Security can be automated while
you scale

4. Why Is Scale Important?
Self
Hosting
Waste
Customer
Dissatisfaction
Actual demand
Predicted Demand
Rigid Elastic
Actual demand
AWS

5. Web Application Scaling

6. Loose coupling sets you free!
• The looser they're coupled, the bigger they scale
– Independent components
– Design everything as a black box
– Decouple interactions
– Load-balance clusters
Controller A Controller B Controller C
Controller A Controller B Controller C
Q Q Q
Tight Coupling
Use Amazon SQS as Buffers
Loose Coupling

7. Allows for Parallel Processing and Failure
• Fan out
• Use varied instance types
• Use varied billing models
• Protects against failure
• Different workloads can scale independently

8. Allows for Parallel Processing and Failure

9. Go wide, not high!
• Build for horizontal scale
– Decrease request contention
– Reduce capacity planning headaches
– Requires a stateless application architecture
– Allows for dynamic scalability
Route 53 ELB Auto Scale EC2 S3 DynamoDBRDSCloudWatch
Cloud
Formation SQS SNS

10. But usually some state has to reside somewhere
Cookies in browser
Memory-resident session manager
Session database
Framework-provided session handler

11. So this store of state needs to be…
Performant
Scalable
Reliable

12. Where should session state reside?
Trigger auto-
scaling policy
Session State
Service
Not Here
Here
State must reside OUTSIDE
the scope of the elements you
wish to scale

13. And what do I build it on?
The state service itself must
be well architected

14. Data Tier Scaling
The bane of the Architect’s existence

15. Vertical Scaling
“We’re gonna need a bigger box”
• Simplest approach
• Can now leverage PIOPs
• High I/O instances
• Easy to change instance sizes
• Will hit an endpoint eventually
hi1.4xlarge
m2.4xlarge
m1.small

16. Master/Slave Horizontal Scaling
• Reasonably simple to adapt to
• Can now leverage PIOPs
• Easy to change instances sizes
• Will hit an endpoint eventually

17. Sharded Horizontal Scaling
Hash Ring
A
BC
D
• More complex at the application layer
• ORM support can help
• No practical limit on scalability
• Operation complexity/sophistication
• Shard by function or key space
• RDBMS or NoSQL

18. Horizontal Scaling – Fully Managed
DynamoDB
• Provisioned throughput NoSQL database
• Fast, predictable performance
• Fully distributed, fault tolerant architecture
• Considerations for non-uniform data
Feature Details
Provisioned
throughput
Dial up or down provisioned read/write
capacity.
Predictable
performance
Average single digit millisecond latencies
from SSD-backed infrastructure.
Strong consistency Be sure you are reading the most up to
date values.
Fault tolerant Data replicated across Availability Zones.
Monitoring Integrated to CloudWatch.
Secure Integrates with AWS Identity and Access
Management (IAM).
Elastic
MapReduce
Integrates with Elastic MapReduce for
complex analytics on large datasets.

19. Petabyte-Scale Data Warehousing
Feature Details
Optimized for Data
Warehousing
Redshift uses a variety of innovations to obtain
very high query performance on datasets
ranging in size from hundreds of gigabytes to a
petabyte or more.
Scalable Easily scale the number of nodes in your data
warehouse up or down as your performance or
capacity needs change
Fault tolerant Data replicated across Availability Zones.
Monitoring Integrated to CloudWatch.
Secure Encrypt data in transit and at rest. Can also be
run in VPC to isolate your data warehouse
cluster.
S3 intergration Loads data in parallel to each node from S3.
Elastic MapReduce Integrates with ERM via Data Pipeline.

20. AWS Application Management Solutions
Elastic Beanstalk OpsWorks CloudFormation EC2
Convenience Control
Higher-level Services Do it yourself

22. Summary
• Awareness of the options is the first step to good design
• Scaling is the ability to move the bottlenecks around to the
least expensive part of the architecture
• Loose coupling is good
• AWS makes this easier – so your application is not a victim of
its own success

23. EROAD AWS Summit 2013
Web Scale Applications
30th May 2013
jarred.clayton@eroad.com - Engineering Manager

24. What’s EROAD
• World’s first autonomous GNSS/CN (Global Navigation Satellite Systems/Cellular Network)
tolling system for heavy vehicles in New Zealand in 2009
• Australasia’s fastest growing technology company (2746% growth 2010-2012)
• Cool tech and a great place to work
• Now growing globally in US and Australia on AWS
• Multi-region / Multi-AZ global infrastructure
• Multi-tenanted SaaS application

25. Why AWS
• Infrastructure Issues - Capital costs, datacenters (not core business), DR/Multisite costs,
growing rapidly (very hard to capacity plan)
• Requirement for Global infrastructure to rapidly enter new markets at low cost
• Aligned with security standards (ISO 27001 etc)
• Oregon State Government security Audit
• Ride the infrastructure innovation wave at commodity prices

26. AWS Building Blocks
• Automation
• Chef, Cloudformation & SuperStacker (EROAD tool – opensource potential)
• Build new environments in minutes (DR, UAT, developers)
• Fault tolerant, autonomous self-healing environment
• Multiple regions and availability zones
• Auto Scaling and ELB

27. Scaling Web-tier
• Tomcat with session state
• Utilize ELB for health and load-balancing
• Session state in separate HA store (Couchbase) across multi-AZ
• Use cloudwatch to auto-scale

28. Scaling Middle-tier
• Stateless – YAY!

29. Scaling Database tier
• The hardest. Take quick wins early.
• PIOPS
• Vertical partitions
• Autoscale high cost read-only GIS database operations
• Scale read-replica’s
• Separate OLTP location data from reporting data
• Plenty more to do
• Sharding, DynamoDB, MongoDB or CouchBase
• Continue scaling
• Utilize new tech – PostgreSQL RDS 

30. Thanks
• We have plenty more work as we continually grow
• Currently utilize reserved instances and want to take advantage spot instances, Redshift etc