This session is recommended for people who are new to content distribution networks (CDNs) and have a need to decrease server load and speed up their website’s load time.
In this mid-level technical session you will be able to learn more about improving the performance of web sites and web applications using Amazon CloudFront and Amazon Router 53. Learn how to assess whether your web applications will benefit from caching and how to optimize the delivery of static and dynamic content to boost performance and improve your customers' experience in using your applications.
2. Fundamental Facts
Any web application must have…
• Tight Security
• High Availability
• High Performance
3. Why Does Availability Matter?
• If your application is not available, your revenue loss is
100%.
• Impact to customer loyalty and your brand image.
4. How AWS Helps?
ü Use Amazon Route 53 to health-check your origin
webservers, with automatic failover.
ü Use Amazon CloudFront to front your origins to reduce
load on your origins.
ü Amazon CloudFront will automatically serve stale
content when origin is unavailable.
ü Use Amazon CloudFront to customize your error pages.
8. How do we Improve Performance ?
A Typical Web Application Has …
• Static or Re-Usable Content
• High TTLs
• Low TTLs (Customized Content)
• Dynamic or Unique Content
• Zero TTL
11. Why Don’t Customers Use a CDN for Dynamic Content?
I don’t see the value - each request is unique and must go back
to the origin web server.
AND/OR
I see the value, but my current CDN charges premium rates for
dynamic content acceleration, with many additional fees.
AND/OR
Configuring a CDN for dynamic content acceleration requires
expensive professional services and is not self-service.
12. How Can Amazon CloudFront Help?
ü Caching Static content
ü Improving Dynamic – DNS, Keep-Alive Connections,
First Byte and Content Download
ü SSL Termination close to viewers
ü Latency Based Routing
ü Design for Failure
ü Low prices, same as static content delivery!
13. STATIC or REUSABLE
A given content where the state of the content
does NOT change for a given period of time
t0 t1
14. DYNAMIC OR UNIQUE
A given content where the state of the content
changes as soon as it gets created
t0 t1
38. Caching for Smaller Time Units
• Imagine your have a read heavy API GETS Hit 1000 RPS
• Offload your web-tier from handling 1000 RPS
• Offload your load balancer: ELB or any other LB
• Provision less capacity and reduce cost
1000 /api/GetBooks?top=10
44. Optimizing DNS Response Time
• Route 53 managed DNS offering
• Designed to be fast
• Low latency DNS resolution
• Global network of DNS servers
• Queries routed to the nearest DNS server
Route 53
47. How to Improve
TCP Connection and First Byte Time?
TCP Connection
Index.jsp
48. TCP/IP Hand Shake
• HTTP Runs on TCP/IP
• TCP has the concept of TCP
handshake
• Every HTTP Connection has to
complete TCP Handshake
• TCP/IP Hand Shake Penalizes Dynamic
49. Two Users without CloudFront
SYN
SYN-ACK
ACK
GET /index.jsp
ACK
SYN-ACK
GET /index.jsp
2nd User
Region
SYN
90ms
360ms
360ms
51. CloudFront Keep Alive
SYN
SYN-ACK
ACK
GET /index.jsp
ACK
SYN-ACK
GET /index.jsp
Region
SYN
30ms
SYN
SYN-ACK
ACK
GET /index.jsp
GET /index.jsp
60ms
2nd User
360ms
180ms
56. SSL Optimization with CloudFront
• CloudFront has the ability to support SSL traffic
• Use CloudFront cert or bring your own
• SSL traffic gets terminated at the closest
CloudFront location
57. CloudFront SSL Optimization Benefits
• Taking advantage of keep-alive connections
• SSL introduces additional TCP handshake packets
• Keep alive eliminates additional SSL TCP handshake
packets
• Offloading your infrastructure from terminating 1000s of
end-users SSL connections
58. How to Improve Content Download Time?
Content Download
Index.jsp
61. • CloudFront can optimize slow start
• Slow start impacts new connections not the
existing ones
• CloudFront uses existing connections so users
can skip slow start
Slow-Start Optimization with CloudFront
65. Performance Results
Test # Of Packets Response Time Per Request
Response Time For 200
Requests
Without
CloudFront
2605 170 ms 33.876 seconds
With
CloudFront
896 96 ms 19.24 seconds
70. Latency-based Routing (LBR)
• Run multiple stacks of your application in different EC2 regions around
the world
• Create LBR records for each location and tag the location with geo
information
• Route 53 will route end users to the endpoint that provides the lowest
latency
70
71. LBR Benefits
• Better performance than running in a single region
• Improved reliability relative to running in a single region
• Easier implementation than traditional DNS solutions
• Much lower prices than traditional DNS solutions
71
74. CloudFront and Route 53
• Use CloudFront for dynamic content optimization
• Host your origin at multiple AWS locations (or data
centers)
– US
– Europe
75. CloudFront and Route 53
• Create Origin DNS records in Route 53 for each location
• Route 53 measures the latency between CloudFront and
all configured origins
• Route 53 resolves origin’s hostname to the closest
location
• Reduce content download time
79. Design for Failure
Normal interaction:
1. Users connect to
CloudFront
2. CloudFront connects to
Origin
Region
CloudFront
80. Design for Failure
How does caching help, if
the origin is down and fails
to respond to CloudFront?
Region
CloudFront
81. Design for Failure: Serve Cached Content
Origin
Edge
Location
User Request A
82. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
User Request A
83. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get Image
User Request A
84. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get Image
Image
User Request A
85. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get Image
Image
Image
User Request A
86. Design for Failure: Serve Cached Content
Origin
Edge
Location
Image
User Request B
87. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get Image
User Request B
88. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get Image
User Request B
89. Design for Failure: Serve Cached Content
Origin
Edge
Location
Get Image
Get ImageImage
User Request B
90. Design for Failure: Caching
• Caching improves performance, but …….
• Can also improve availability
• If your infrastructure is experiencing failure,
CloudFront can serve cached content instead of
5xx,4xx and etc
91. Design for Failure
• Health-checking your origin with Amazon Route
53
Region
Route53
Health
Check
Health
Check
92. Design for Failure
• Failures can be detected by Route 53 health checks
Region
Route53
Health
Check
Health
Check
CloudFront
93. Design for Failure
• The traffic shifts to the healthy instances or load balancers
instead
Region
Route53
Health
Check
Health
Check
CloudFront
98. Summary
• Accelerate all your content with CloudFront
• Use CloudFront with Route 53 latency-based
routing to improve your performance
• Design for failure with CloudFront and Amazon
Route 53
103. Measuring CDN performance
• How do we know our CDN is effective?
– Significant engineering work
– Simple tools
• http://go.import.io/aws-test
– Academic research
• http://go.import.io/aws-measure [PDF]
104. CloudFront use cases
• Distributing large files
• Serving static WebApps
• Serving branded content
105. Distributing binaries
• Application installation binaries
– 50 to 100MB each
• CloudFront with S3 Origin
– 1 hour TTL (set on CDN)
• Extremely quick to set up (30 mins)
106. Serving static WebApps
• API / Client separation
Browser
Elastic Load Balancer Elastic Load Balancers
import.io
api.import.io
AutoScaling Group
(API servers)
AutoScaling Group
(nginx reverse proxies)
S3 Upstream
CloudFront Distribution
xyz.cloudfront.ne
t
version = ?
version = 𝑥
version = 𝑥
version = 𝑥
108. Serving static WebApps
• Quick to set up
• Change configuration when WebApp is built
• JavaScript requires CORS set on S3
– Cross Origin Resource Sharing: http://go.import.io/aws-cors
– Compatibility recently improved
– http://go.import.io/aws-s3cors
• 1 year (or more) TTL, set using S3 headers
– http://go.import.io/aws-expiration
110. Serving branded content
• cdn.import.io
– Alias record in Route53
– http://go.import.io/aws-alias
– Domain needs to be setup on both Route53 and CloudFront
• SSL with custom domain (https://cdn.import.io)
– SNI SSL certificate
– http://go.import.io/aws-sni
111. Route53 Failover
• Provides a website in case of disaster
• Important to inform users and reduce support calls
Route53
(import.io)
Elastic Load Balancer
AutoScaling Group
Health
checks
S3 static content
(import.io bucket)
112. POC: Latency-based Routing
• Trials of serving frontend content globally
Browser
Elastic Load Balancer
AutoScaling Group
Elastic Load Balancer
AutoScaling Group
Route53
No shared state
113. POC: Latency-based Routing
• Route53 and CloudFront
Browser
Elastic Load Balancer
AutoScaling Group
Elastic Load Balancer
AutoScaling Group
Route53
No shared state
CloudFront
114. POC: Dynamic content optimisation
• Trials of dynamic content behind CloudFront
Browser
Elastic Load Balancer
Elastic Load Balancers
import.io
api.import.io
AutoScaling Group
(API servers)
AutoScaling Group
(nginx reverse proxies)
S3 Upstream
CloudFront Distribution
xyz.cloudfront.ne
t
version = ?
version = 𝑥
version = 𝑥
version = 𝑥
CloudFront Distribution
115. Thank you
We use:
Java: Hazelcast, Guava, CometD, Spring, Jetty, OSGi
We do:
Devops, AWS, testing, agile
We have:
Cool office, diverse team, well funded
matthew.painter@import.io