Amazon CloudFront and Amazon Route 53 can help optimize web application performance and availability. CloudFront improves performance by caching static and reusable content at edge locations and optimizing delivery of dynamic content through features like keep-alive connections and latency-based routing. Route 53 provides fast, reliable DNS services and can health check origins to improve high availability. Together, CloudFront and Route 53 provide a global network that caches content close to users and routes traffic based on network conditions to optimize performance and design for failure.

1. Dynamic Content Acceleration:
Lightning-Fast Web Apps with
Amazon CloudFront and Amazon Route 53
Kalyanaraman Prasad
Parviz Deyhim
November 13, 2013
© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

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.
 Use Amazon CloudFront to customize your error pages.
 Amazon CloudFront will automatically serve stale
content when origin is unavailable.

5. Why Performance Matters?
• Performance translates to …
• Higher Page Views
• Better Customer Experience
• Higher Conversion Rates

6. Why Performance Matters?

7. Why Performance Matters?
Great amount of time and money spent improving
back-end infrastructure performance

8. Why Performance Matters?
80% of user’s perceived latency comes from frontend

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

10. Static or Re-Usable Content
Can be cached (High TTLs or Low TTLs)

11. Typical Architecture

12. Dynamic or Unique Content
Cannot be cached - BUT affects 100% of your viewers!

13. Why Not…?

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

15. How Can Amazon CloudFront Help?
 TCP/IP optimizations for the network path
 Keep-Alive Connections to reduce RTT
 SSL Termination close to viewers
 POST/PUT upload optimizations
 Latency Based Routing
 Low prices, same as static content delivery!

17. Unique or Reusable Contents?

18. STATIC or REUSABLE
A given content where the state of the content
does NOT change for a given period of time
t0
t1

19. DYNAMIC OR UNIQUE
A given content where the state of the content
changes as soon as it gets created
t0
t1

20. Example

21. Example
Index.jsp (dynamic)
Images (static)

22. .
sec

23. Page Load Time?
.
Sec

24. Improving Web Application Performance
Accelerating static contents
Accelerating dynamic contents

25. Brief Introduction to
Waterfall Graphs

26. Waterfall Graphs
• Most important tool for web-performance measurement
• Most browsers provide waterfall graph plug-ins

27. What Happens?
Typing the Address
Browser renders

28. Understanding Waterfall Graphs
TCP Connection
Content Download
DNS Lookup
Time to First Byte

29. Understanding Waterfall Graphs
Index.jsp

30. Optimizing
Static Content

31. Optimizing Static Content
Index.jsp
Images, JS and
CSS

32. Optimizing Static Content
Index.jsp
Optimize By
Caching With
Amazon
CloudFront

33. Caching
Origin
Edge
Location
User Request A

34. Caching
Origin
Get Image
Edge
Location
User Request A

35. Caching
Get Image
Origin
Get Image
Edge
Location
User Request A

36. Caching
Get Image
Origin
Image
Get Image
Edge
Location
User Request A

37. Caching
Get Image
Origin
Image
Get Image
Edge
Location
Image
User Request A

38. Caching
Origin
Edge
Location
Get Image
User Request B

39. Caching
Origin
Edge
Location
Image
Get Image
User Request B

40. Optimizing Static Content with Caching
Brings content closer to the users

41. Optimizing Static Content with Caching
Improves the experience and performance

42. Optimizing Static Content with Caching
Offloads your infrastructure

44. Before Caching = 1.46sec

45. After Caching = 770ms

46. Are We Done?

47. NOT SO FAST
GOAL:
.
sec

48. Cache As Much As You Can

49. How? I’m Caching
All My Images, CSS
and JS

50. Steps to Find Cachable Content
1. Collect web (W3C) logs from your web tier
2. Run a report on your logs (Amazon EMR,
Amazon RDS, or Amazon Redshift)
3. Identify top N URLs

51. Steps to Find Cachable Content
Example of query:
Select count(url) count, url
from logs_table
Group by url sort by count;

52. Site Content

53. STATIC or REUSABLE
A given content where the state of the content
does NOT change for a given period of time
t0
t1

54. Caching for Smaller Time Units
•
Goal: Find contents that can be cached for any
given period of time
•
•
Minutes
•
•
Hours
Seconds
CloudFront can cache content for any period of
time

55. Content with Query Strings
110 /factor/create_image?name=book1&size=10x10
Reusable?

56. Content with Query Strings
• CloudFront can cache content with query strings
• Every unique query string combination is a new
object in CloudFront’s cache

57. API Calls
100 /api/GetBooks?category=math
Reusable?

58. API Calls
80 /api/GetBooks?top=10
Reusable?

59. Caching for Smaller Time Units
1000 /api/GetBooks?top=10
•
Imagine your have a read heavy API GETS Hit 100 or 1000
RPS
•
Offload your web-tier from handling 1000 RPS
•
Offload your load balancer: Elastic Load Balancing or any
other LB
•
Provision less capacity and reduce cost

60. Base Page (First HTML page)
220 /index.jsp
Reusable?

61. Optimizing Dynamic
Content

62. Dynamic Content
Index.jsp

63. Optimizing Dynamic Content
Index.jsp

64. Can Dynamic Content Be Optimized?
Dynamic content is not cachable
Content proxied by CDN to the
origin and back

65. Can Dynamic Content Be Optimized?
Poke
Origin
Ok
Poke
Edge
Location
Poke
Ok
Poke
User
Request
User
Request

66. Can Dynamic Content Be Optimized?
That adds latency?
How to optimize dynamic content?

67. How to Optimize Dynamic Content?
TCP Connection
DNS Lookup
Time to First Byte
Content Download

68. How to Optimize Dynamic Delivery?
Faster Response Time =
Route 53
Reduced DNS Time
+
Keep-Alive Connections
& SSL Termination
Reduced Connection Time
+
Reduced First Byte Time
Keep-Alive Connections
TCP/IP Optimization
Rute53
Route 53
+
Reduced Content Download Time

69. After Caching/Before CloudFront
Dynamic Acceleration = 770ms

70. How to Improve DNS Time?
Index.jsp
DNS Lookup

71. With Amazon Route 53
Route 53

72. Optimizing DNS Response Time
• Amazon 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

73. Without Amazon Route 53

74. With Amazon Route 53

75. How to Improve
TCP Connection and First Byte Time?
TCP Connection
Index.jsp

76. With CloudFront’s
Keep-Alive Connections

77. 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
Contents

78. Two Users without CloudFront
SYN
SYN-ACK
360ms
ACK
GET /index.jsp
2nd
User
SYN
SYN-ACK
360ms
ACK
GET /index.jsp
90ms

79. Without CloudFront
• Every user is new
connection
• More users = more
TCP connections

80. Without Keep-Alive Connections
• Puts load on your web servers:
Memory/CPU

81. Without Keep-Alive Connections
• Load on your web server increases the
time to first byte
Time to First Byte

82. Keep Alive Connections
SYN
SYN-ACK
ACK
2nd
Request
GET /index.jsp
GET /index.jsp

83. CloudFront Keep Alive
SYN
SYN
SYN-ACK
360ms
SYN-ACK
ACK
ACK
GET /index.jsp
2nd User
GET /index.jsp
SYN
SYN-ACK
GET /index.jsp
ACK
180ms
GET /index.jsp
30ms
60ms

84. CloudFront Keep Alive
• More users
Without CloudFront
With CloudFront
More TCP connections
2 connections
1 connection
• Offloads your web tier’s CPU/memory
• Improves response time
Without CloudFront
With CloudFront
720 ms
540 ms

85. Test
CPU Util. %
Without CloudFront
20%
With CloudFront
6%

86. How to Optimize
My SSL Connections?
TCP Connection
Index.jsp

87. With CloudFront’s
SSL Termination

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

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

90. SSL Optimization Patterns with CloudFront
Two optimization patterns:
1. Half bridge SSL termination
2. Full bridge SSL termination

91. Half Bridge SSL Termination
CloudFront
HTTP

92. Half Bridge SSL Termination Benefits
• Better performance by leveraging HTTP
connections to origin
CloudFront
HTTP

93. Full Bridge SSL Termination
HTTPs

94. How to Improve
Content Download Time?
Content Download
Index.jsp

95. With Amazon CloudFront
Slow-Start Optimization

96. TCP Slow Start
Packet1
Packet 1 ACK
Packet 2
Packet 3
Packet 3 ACK
Packet 4
Packet 5
Packet 6
Packet 7

97. Slow-Start Optimization with CloudFront
• CloudFront can optimize slow start
• Slow start impacts new connections not the
existing ones
• CloudFront uses existing connections so users
can skip slow start

98. Packet1
Packet 1 ACK
Packet 2
Packet1
Packet 2
Packet 3
Packet 4
Packet 3
Packet 3 ACK
Packet 4
Packet 5
Packet 6
Packet 7
Packet 4 ACK
Packet 5
Packet 6
Packet 7
Packet 8
Packet 9

99. Performance Test 1: Without CloudFront

100. Performance Test 2: With CloudFront

101. Performance Results
Test
# Of Packets
Response Time Per Request
Response Time For 200
Requests
Without
CloudFront
2605
170 ms
33.876 ms
With
CloudFront
896
96 ms
19.24 ms

102. How to Optimize PUT/POST?
TCP Connection
Index.jsp

103. With Amazon CloudFront
PUT/POST Verb Optimization

104. PUT/POST Optimization with CloudFront
• CloudFront supports verbs: PUT, POST,
DELETE, OPTIONS, and PATCH
• Data won’t get cached
• CloudFront proxies data to origin

105. PUT/POST Optimization with CloudFront
• Dynamic content optimizations apply
– Keep-alive connections
– TCP slow-start optimization
– Close proximity connection termination

106. PUT/POST Optimization with CloudFront
• Optimizing form POSTs
• Optimizing AJAX POST requests
• Optimizing content upload
– Uploading to Amazon S3

107. PUT/POST Optimization Test
CloudFront

108. PUT/POST Optimization Test
Uploading 10 MB data from an instance in US
East region to US West region
Avg. result: 5sec

109. PUT/POST Optimization Test
CloudFront
Uploading 10MB data from an instance in US
East region to the closest CloudFront location
Avg. result: 3.5sec

110. How to Improve
Content Download Time Even More?
Content Download
Index.jsp

111. With Amazon Route 53
Latency-based Routing
Route 53

112. Latency-based Routing (LBR)
• Run multiple stacks of your application in different Amazon
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
112

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

114. LBR For End-Users
114

115. LBR For End-Users
115

116. CloudFront and Route 53
• Use CloudFront for dynamic content optimization
• Host your origin at multiple AWS locations (or data
centers)
– US
– Europe

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

118. LBR For End-Users
118

119. LBR For End-Users
119

120. Lower Latency with CloudFront and
Route 53

121. Lower Latency with CloudFront and
Route 53

122. Lower Latency with CloudFront and
Route 53

123. Lower Latency with CloudFront and
Route 53

124. Lower Latency with CloudFront and
Route 53

125. Lower Latency with CloudFront and
Route 53

126. Lower Latency with CloudFront and
Route 53

136. After CloudFront Dynamic Content
Optimization = 555 ms

137. Example: somecompany.com
.
sec

138. Design for Failure with
CloudFront and Route 53
Route 53

139. Design for Failure
Normal interaction:
CloudFront
1. Users connect to
CloudFront
1. CloudFront
connects to Origin

140. Design for Failure
• What happens if the origin fails to respond back
to CloudFront?
CloudFront

141. Design for Failure
• With Amazon Route 53, you can health-check
your origin

142. Design for Failure
• Failures can be detected by Route 53 health
checks
CloudFront

143. Design for Failure
• The traffic shifts to the healthy instances or load
balancers instead
CloudFront

144. Can mix health check and
latency-based routing
Can apply the same logic to
multiregion deployments

145. Users get connected to the
closest region if both
regions are healthy

146. Route 53 detects failures
via health checks

147. Users get connected to the
healthy regions if the
closest region is not
passing the health check

148. Design for Failure: Caching
• Caching improves performance
• Can also improve availability
• If your infrastructure is experiencing failure,
CloudFront can serve cached content instead of
5xx,4xx and etc
148

149. Design for Failure: Caching
• Going back to “cache as much as you can”
• More caching = better availability
149

150. Design for Failure: Serve Cached Content
Origin
Edge
Location
User Request A

151. Design for Failure: Serve Cached Content
Origin
Get Image
Edge
Location
User Request A

152. Design for Failure: Serve Cached Content
Get Image
Origin
Get Image
Edge
Location
User Request A

153. Design for Failure: Serve Cached Content
Get Image
Origin
Image
Get Image
Edge
Location
User Request A

154. Design for Failure: Serve Cached Content
Get Image
Origin
Image
Get Image
Edge
Location
Image
User Request A

155. Design for Failure: Serve Cached Content
Origin
Edge
Location
Image
User Request B

156. Design for Failure: Serve Cached Content
Get Image
Origin
Edge
Location
Get Image
User Request B

157. Design for Failure: Serve Cached Content
Get Image
Origin
Edge
Location
Get Image
User Request B

158. Design for Failure: Serve Cached Content
Get Image
Origin
Edge
Location
Image
Get Image
User Request B

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

160. Customer Stories

161. Customer Story: Low TTLs

162. Customer Story: Query Strings

163. Customer Story: Cookies

164. Customer Story: POST/PUT
“We are excited to use CloudFront's new
POST, PUT, PATCH, and DELETE
capabilities to accelerate our RESTful
APIs on Amazon EC2. With these new
HTTP methods we can now take
advantage of CloudFront’s global footprint
and optimized connections back to our
origin servers in AWS. Routing our
customers’ API requests via a CloudFront
edge location near them will help improve
their experience by minimizing packet loss
and upload latency. This will help provide

165. Customer Story: Custom SSL

166. Customer Story: Health Checks &
Failover
“Amazon Route 53’s DNS Failover
feature provides high availability
across our multiple AWS regions and
gives us the ability to offload our
origins.”

167. Please give us your feedback on this
presentation
ARC309
As a thank you, we will select prize
winners daily for completed surveys!