7. AWS building blocks
Inherently highly scalable, available and
fault-tolerant services
Highly scalable, available
with the right architecture
a Amazon CloudFront
a Amazon Route 53
a Amazon S3
a Amazon DynamoDB
a Elastic Load
Balancing
a AWS Lambda
a Amazon EFS
a Amazon SQS
a Amazon SNS
a Amazon SES
a AWS Step Functions
a …
a Amazon
EC2
a Amazon
EBS
a Amazon
RDS
a Amazon
VPC
12. Lightsail: the easiest way to get started on AWS
• Choose from five plans that include bundled
compute, storage, and networking
• Benefit from a low, predictable price
• Spin up a fully configured server in seconds
• Manage from the intuitive Lightsail console
• Scale with access to AWS services
• Automate with Lightsail API & CLI
13. “We’re gonna need a bigger box”
• Simplest approach
• Can now leverage PIOPS
• High I/O instances
• High memory instances
• High CPU instances
• High storage instances
• Easy to change instance sizes
• Will hit an endpoint eventually
c4.8xlarge
m4.2xlarge
t2.micro
18. Amazon Aurora
• MySQL or Postgres compatible
• Automatic storage scaling (up to 64 TB)
• Up to 15 read-replicas
• Continuous (incremental) backups to
Amazon S3
• 6-way replication across 3 zones
19. Users > 100
Amazon EC2
instance
Elastic IP
User
Amazon
Route 53
Amazon RDS
DB instance
21. Why start with SQL?
• Established and well-worn technology.
• Lots of existing code, communities, books, and tools.
• You aren’t going to break SQL DBs in your first millions
of users. No, really, you won’t.*
• Clear patterns to scalability.
*Unless you are doing something SUPER peculiar with the data or you have MASSIVE amounts of it.
…but even then SQL will have a place in your stack.
23. > 5 TB in year one?
Incredibly data intensive workload?
OK!
You might need NoSQL.
24. Why else might you need NoSQL?
• TB of data
• Super low-latency applications
• Nonrelational, schema-less* data
• Rapid ingest of data (thousands of records/sec)
• Metadata-driven datasets
*Need!= “It’s easier to do dev without schemas”
28. Users > 100
User
Amazon
Route 53
Web
Instance
Amazon RDS DB
Instance
Active (Multi-AZ)
Web
Instance
Amazon RDS DB Instance
Standby (Multi-AZ)
Load
balancer
34. Users > 10000s – 100000s
Amazon RDS DB
Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Amazon RDS DB
Instance Standby
(Multi-AZ)
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53 User
? ? ?
35. Amazon Simple Storage Service (S3)
• Object-based storage
• Highly durable
• Great for static assets
• “Infinitely scalable”
• Objects up to 5 TB
• Encryption
36. Amazon CloudFront
• Cache content for faster delivery
• Dynamic and static content
• Streaming video
• Custom SSL certificates
• Low TTLs (as short as 0 seconds)
• Optimized for AWS
ResponseTime
ServerLoad
Response
Time
Server
Load
Response
Time
Server
Load
No CDN CDN for Static
Content
CDN for Static &
Dynamic Content
37. Shift some load around
Amazon RDS DB Instance
Active (Multi-AZ)
Availability Zone
Load balancer
Amazon S3
Amazon
CloudFront
Amazon
Route 53User
Web Instances
Availability Zone
Web Instances
Amazon RDS DB Instance
Standby (Multi-AZ)
38. Caching….
Amazon RDS DB Instance
Active (Multi-AZ)
Availability Zone
Load balancer
Amazon S3
Amazon
CloudFront
Amazon Route 53
User
Web Instances
Amazon
ElastiCache
39. Amazon ElastiCache
• Managed Memcached or Redis
• Scale from one to many nodes
• Self-healing (replaces dead instance)
• Single digit ms speeds (usually)
• Local to a single AZ for Memcache
• Multi-AZ possible with Redis
41. Shift some load around
Amazon RDS DB Instance
Active (Multi-AZ)
Availability Zone
Load balancer
Amazon S3
Amazon
CloudFront
Amazon Route 53
User
Web Instances
Amazon
ElastiCache
Amazon
DynamoDB
42. Amazon DynamoDB
• Managed NoSQL database
• Provisioned throughput
• Fast, predictable performance
• Fully distributed, fault tolerant
• JSON support
• Items up to 400 KB
• Time-to-live (TTL)
• Streams and Triggers
• AWS Application Auto Scaling!!
43. Amazon DynamoDB
• Managed NoSQL database
• Provisioned throughput
• Fast, predictable performance
• Fully distributed, fault tolerant
• JSON support
• Items up to 400 KB
• Time-to-live (TTL)
• Streams and Triggers
• AWS Application Auto Scaling!!
AWS Database
Migration Service!!
44. Now that our web tier is
much more lightweight,
we can revisit the beginning
of our talk…
55. Users > 500,000s
Amazon RDS DB
Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Amazon RDS DB
Instance Standby
(Multi-AZ)
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53User
Amazon S3
Amazon
CloudFront
Amazon
DynamoDBAmazon
ElastiCache
Amazon
ElastiCache
57. AWS Code Services
Source Build Test Production
Third Party
Tooling
Software Release Steps:
AWS CodeCommit AWS CodeBuild AWS CodeDeploy
AWS CodePipeline
58. Users > 500,000+
• Monitoring, metrics, and logging
• If you can’t build it internally,
outsource it! (third-party SaaS)
• What are customers saying?
• Try to squeeze as much performance
out of each service/component
63. • Identify performance bottlenecks and errors
• Pinpoint issues to specific service(s) in your application
• Identify impact of issues on users of the application
• Visualize the service call graph of your application
AWS X-Ray
67. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
68. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
69. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
70. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
71. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
72. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
73. OUR PORTFOLIO
Creativity is the key to success in the future, and primary education is where teachers can bring creativity in children
at that level keep growing lorem ipsum dolor sit amet.
74. Reaching a million and above is going to require some bit
of all the previous things:
• Multi-AZ
• Elastic Load Balancing between tiers
• Auto Scaling
• Microservices
• Serving content smartly (Amazon S3/CloudFront)
• Caching off DB
• Moving state off tiers that auto scale
Users >1 million+
75. Amazon RDS DB
Instance
Active (Multi-AZ)
Availability Zone
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
User
Amazon S3
Amazon
DynamoDB
Amazon SQS
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance Amazon SES
AWS Lambda
Amazon
Route 53
Amazon
CloudFront
Load balancer
Users >1 million+
76. Amazon RDS DB
Instance
Active (Multi-AZ)
Availability Zone
Amazon RDS DB
Instance Read
Replica
Amazon RDS DB
Instance Read
Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
User
Amazon S3
Amazon
DynamoDB
Amazon SQS
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance Amazon SES
AWS Lambda
Amazon
Route 53
Amazon
CloudFront
Load balancer
Amazon
DynamoDB
Amazon API
Gateway
Users >1 million+
78. Database Issues?
How can you solve it?
• Moving some functionality to other types of DBs (NoSQL, Graph)
• Federation—splitting into multiple DBs based on function
• Sharding—splitting one dataset up across multiple hosts
Users >5 million - 10 million
79. Database federation
• Split up databases by function/purpose
• Harder to do cross-function queries
• Essentially delays sharding/NoSQL
• Won’t help with single huge functions/tables
Clientes DB
Unicornios DB
Products DB
80. • More complex at the application layer
• No practical limit on scalability
• Operation complexity/sophistication
• Shard by function or key space
• RDBMS or NoSQL
User ShardID
002345 A
002346 B
002347 C
002348 B
002349 A
CBA
Sharded horizontal scaling
82. • More fine-tuning of your application
• More SOA/ MS of features/functionality
• Going from Multi-AZ to multi-region
• Possibly start to build custom solutions
• Deep analysis of your entire stack
• Amazon EC2 Container Service
• AWS Lambda
User >10 million
84. • Multi-AZ your infrastructure.
• Make use of self-scaling services—ALB, Amazon S3, AWS
Lambda, Amazon SNS, Amazon SQS, AWS Step Functions,
etc.
• Build in redundancy at every level.
• Start with SQL. Seriously.
• Cache data both inside and outside your infrastructure.
• Use automation tools in your infrastructure.
A quick review
85. • Make sure you have good metrics/monitoring/logging
• Split tiers into individual services (Microservices)
• Use Auto Scaling once you’re ready for it
• Don’t reinvent the wheel
• Move to NoSQL if and when it makes sense
A quick review continued