Amazon CloudFront Flash Talks: Best Practices on Configuring, Securing, Customizing, and Monitoring Your Distribution - CTD301 - re:Invent 2017

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:INVENT
Amazon CloudFront Flash Talks:
Best Practices on Configuring, Securing, Customizing, and
Monitoring Your Distribution
C T D 3 0 1
Chaitanya Solapurkar
Software Development Engineer
Amazon CloudFront
Komei Nakamoto
Amazon CloudFront
Alexander Korobeynikov
Amazon CloudFront
N o v e m b e r 2 8 , 2 0 1 7

Overview
• How Amazon CloudFront delivers content
• Cache configurations and examples
• Customizing delivery with Lambda@Edge
• Performance metrics with real-user monitoring (RUM)

How CloudFront Delivers Content
CloudFront
Edge
Locations
Regional
Edge
Cache
Origins
Amazon
EC2
ELB
Amazon
S3 Custom
Server
ISP Nameserver
1.2.3.4Viewers

Cache Configurations and Examples

Why Performance Matters
• More page views
• Better customer experience
• Higher conversion rates
• SEO impact as site speed is also considered
Cache performance
• Object’s presence in Edge cache
• Nature of connections—for viewer and origin

Static, long-lived
*.css, *.js, *.jpg, *.png
Software downloads, Media
fragments, Video On-Demand
manifests
• Use a high TTL value as content
seldom changes
• Use versioning to update a new
version of the content
Static, short-lived
Landing pages - index.jsp
News, Weather
Live streaming manifests
• Low TTL as content is
periodically updated
• CloudFront lowers origin load
by only revalidating object on
expiration
Dynamic content
Always updated
uncacheable
• Resources that are updated
frequently
• Content that is unique based on
request
• Very low or zero TTL
Objects
+  = 12199213980087345254
Cache key
Request
Configuration

• Cache-control header per object can control its validity
• High TTL  Cache-Control: max-age=31536000; s-
maxage=86400
• Low TTL  Cache-Control: public; max-age=60
• To set a different TTL or to override origin  use Min, Max,
and default TTL values at Cache Behavior
• Have fewer variants for better cacheability:
• Query strings
• Cookies
• Selected request headers
Static Content
CloudFront
Edge Locations
Regional
Edge
Cache
User Agents

• Use a zero TTL value so that the fresh object is
present in cache
• Cache-Control: no-cache; max-age=0; No-
store; private
• Cache-Control: public; max-age=0;
• Zero TTL objects can be cached at Edge
• Second request triggers revalidation—which
can be lightweight if object has not changed
• For content to never be cached:
• Cache-Control: private, no-store
• In Cache Behavior, pick ‘All’ for ‘Cache based
on Selected Headers’
Dynamic Content
CloudFront
Edge Locations
Regional
Edge
Cache
Origins
Amazon EC2 Amazon ELB
Amazon S3
Custom Server

Cache-Control Header (Examples)
Static Assets
*.css, *.js, images, software
downloads
Cache-Control:
public;
max-age=31536000
Login Landing Pages
index.html
Cache-Control:
no-cache=Set-Cookie;
max-age=30
Live Streaming Manifests
/*.m3u8
Cache-Control:
public;
max-age=2
Media Fragments
/*.ts
Cache-Control:
public;
max-age=31536000
Dynamic Content
Cache-Control:
no-cache;
max-age=0;
No-store;
private
User Agents
Edge
Cache

Errors
What happens if the Origin is unreachable? What happens if resource is not available?
• Cache errors at Edge locations to manage Origin load!
• CloudFront supports setting Error Caching Minimum TTL for:
• 400, 403, 404, 405, 414, 500, 501, 502, 503, 504
• Can also set a Custom Error Page and change the Response Code
• Set a low Error Caching Minimum TTL for revalidating sooner with your Origin
• CloudFront will deliver stale content if Origin is unreachable and object is in cache

Viewer 
CloudFront
• Use Keep-alive
• TLS handshake
• Enable gzip compression
• HTTP/2
• Multiplexed—uses
one connection for
parallelism
• Header compression
Connection Flow
TCP
TLS
Viewer Connection

Origin Connection Flow
TCP
TLS Session resume
Origin Connection
CloudFront  Origin
• Support keep-alive
• TLS handshake
• Support session tickets
• Enable gzip compression
• Tune Origin timeouts
• Read timeout
• Keep-alive timeout

Cache Configuration—Key Takeaways
• Configure TTLs for objects based on whether they’re long-lived, short-lived, or dynamic
• Set Error Caching Minimum TTL for managing Origin load and viewer experience
• Reuse viewer connections
• Use compression—both for viewers and from Origin
• Enable HTTP/2
• Support keep-alive for your Origin connections and configure Origin timeouts

Customizing Content Delivery with
Lambda@Edge

You PROGRAM Amazon CloudFront with Lambda@Edge
Amazon CloudFront and Lambda@Edge
AWS
Lambda
Lambda
Amazon
CloudFront Edge
+ = @

Lambda@Edge Events (Cache-Hit)
Viewers
Viewer
Request
Viewer
Response
Amazon
CloudFront Cache
Hit

Lambda@Edge Events (Cache-Miss)
Viewers
Viewer
Request
Viewer
Response
Amazon
CloudFront Cache Origin
Origin
Request
Origin
Response
Miss

• Triggered for every viewer request
• Cache key can be modified
• Response is not cached
Common use cases:
• Cache key optimization
• Authentication and access control
• Per-viewer content customization
• Triggered only for cache misses
• Cache key cannot be modified
• Response can be cached
Common use cases:
• Wider class content customization
• Better integration with your origin
• Content generation
Viewer events Origin events

Security
Response
Headers

Use Case: Security Headers
Event trigger: Origin Response
HSTS (tell your viewers to stick to HTTPS):
• Strict-Transport-Security
CORS (allow other domains to access your data relaxing the same-origin policy):
• Access-Control-Allow-Origin and other CORS headers
CSP (block content loaded from other sources, reduce the risk of XSS):
• Content-Security-Policy
HPKP (pin your public key in the client, prevent MITM attacks with forged certificates):
• Public-Key-Pins
More:
• X-Frame-Options (prevent clickjacking)
• X-Content-Type-Options (prevent MIME sniffing)
• X-XSS-Protection

exports.handler = (event, context, callback) => {
const response = event.Records[0].cf.response;
// Enforce HTTPS with the HSTS header
response.headers['strict-transport-security'] = [{
key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains’
}];
// Disallow embedded frames
response.headers['x-frame-options'] = [{
key: 'X-Frame-Options', value: 'DENY’
}];
// Remove CORS headers
delete response.headers[’access-control-allow-origin'];
delete response.headers[’access-control-max-age'];
...
callback(null, response);
}
Use Case: Security Headers
Event trigger: Origin Response

Content Customization
GET /objectX objectX
optimized
for Client A
objectX
optimized
for Client B
GET /objectX
Client A
Client B

Use Case: Content Customization (1)
Event trigger: Origin Request
The classification condition can be a part of the cache key, for example:
• CloudFront-Is-[Desktop|Mobile]-Viewer
• CloudFront-Viewer-Country
• any other header, cookie, or query string
Amazon S3
bucket
(or any origin)
GET /desktop/objectX
Origin
Request
GET /mobile/objectX
GET /objectX
GET /objectX
Amazon
CloudFront cache

Premium
viewer
Free
viewer
Amazon S3
bucket
(or any origin)
Amazon
CloudFront Cache
Use Case: Content Customization (2)
Event trigger: Viewer Request
The classification condition is based on unique properties of the viewer:
• Authentication/authorization condition
• User-Agent lookup
• Client IP address lookup
GET /free/objectX
GET /premium/objectX
Viewer
Request
GET /objectX
GET /objectX
Auth API

Origin Selection
• Minimize latency by going to the closest origin
• Keep data sovereignty by selecting the origin depending on the client ID
• Choose the origin that serves the content for the given device type
• Perform origin deployments, AB-testing, and migrations with session stickiness
• And much more!
Origin
Request
Amazon
CloudFront Cache
Origin A
Origin B
Viewer
OR

const request = event.Records[0].cf.request;
// select a region based on request properties, for example:
// a) CloudFront-Viewer-Country header (US, GB, DE, etc.)
// b) closest AWS region (available in process.env.AWS_REGION)
// c) any custom logic based on request properties (URI, query string, etc.)
const region = ...
const originDomainName =`my-origin-in-${region}.com`;
// set region specific domain name like:
request.origin.custom.domainName = originDomainName;
request.headers[’host’] = [{ key: ’Host’, value: originDomainName }];
callback(null, request);
}
Use Case: Origin Selection

Response and Content Generation
• Respond with HTTP redirects
• Dynamic content generation
• Content aggregation
• Customized content generation
• Choose whether to pass the request further (case A) or to generate a response (case B)
Origin
Request
Amazon
CloudFront cache
Viewer
Viewer
Request
Amazon
CloudFront cache
Viewer
Case A
Case B

performCustomAuth(request, (error, authResult) => {
if (error) {
console.log(‘Auth failed: ‘ + JSON.stringify(error));
const response = {
status: '302',
statusDescription: 'Found',
headers: { location: [{ key: 'Location', value: `/login?redirect_to=${request.uri}` }] }
};
callback(null, response);
} else {
console.log(‘Auth succeeded: ’ + JSON.stringify(authResult));
callback(null, request);
}
});
}
Use Case: Response Generation (1)
Event trigger: Viewer Request

async.parallel({
// Get the HTML template of the page. For example, from the CloudFront cache, using an URL like this one:
// https://d123.cloudfront.net/static/template.html
template: callback => { getHtmlTemplate(request, callback); },
// Get data from DynamoDB (preferably from the closest AWS region)
data: callback => { getDataFromDynamoDB(request, callback); }
},
(error, results) => {
if (error) { /* handle error here */ }
callback(null, {
status: ’200',
statusDescription: ’OK',
headers: { 'content-type': [{ key: 'Content-Type', value: 'text/html' }] },
body: buildHtml(request, results.template, results.data)
});
});
}
Use Case: Response Generation (2)

Lambda@Edge—Key Takeaways
• Lambda@Edge makes CloudFront a programmable CDN
• Think of trade-offs when selecting a Lambda@Edge event type
• Go “originless”

Performance Metrics with Real-User
Monitoring (RUM)

Real-User Monitoring
• Synthetic monitoring as opposed to real-user monitoring (RUM)
• When to use one over the other
• What to monitor

What is Synthetic Monitoring?
• Consistent signal of service health
• Baseline performance before launch
• Deep-dive diagnostic capability
Synthetic monitoring
configuration
Synthetic
monitoring
portal
Web application
Simulated users

Synthetic Monitoring Use Case
• Consistent signal of service health
• Baseline performance before launch
• Deep-dive diagnostic capability
configuration
synthetic
monitoring
portal
New web application
Simulated users

Where Synthetic Monitoring Goes Wrong
• Network path to your application
might not be representative
• Client-specific cases
configuration
synthetic
monitoring
portal
Web application
Simulated users
Real
user

What is RUM?
Real users
Script injected in
web page HTTP
response
RUM
provider
portal
• Script injected in web page
• Script beacons data back from the user’s browser session to the RUM provider
• RUM provider portal aggregates the data for analysis

RUM Use Case
Real users
Script injected in
web page HTTP
response
RUM
provider
portal
• Measures all aspects of your real users’ experiences
• What should my next optimization be?
• What is the cause of a loss of availability?

What to Measure?
Connection definitions:
• Queueing – time spent waiting to begin processing
• Stalled/Blocking – total time spent in queue or proxying
• DNS lookup – time taken to receive DNS response with A or AAAA
• Initial connection – inclusive of TCP handshake and negotiating SSL

What to Measure?
Request definitions:
• Request sent – HTTP request sent time
• TTFB – time to first byte
• Content download – time to last byte

What to Measure?
Insights from this example:
• Initial connection time makes up 60% of the object download
• TTFB makes up ~30% of object download
• Small objects are heavily impacted by high RTTs

Optimizations for Small Objects
• Reuse connection:
• Keep-alive
• HTTP/2
• Origin as close to your end users as possible (multi-region)

What to Measure?
Insights from this example:
• Connection is reused to save initial connection time
• Content download makes up ~90% of object download
• Streaming objects are heavily impacted by throughput

Optimizations for Streaming Objects
• Look at content download time
• Bit rate (quality)
• Buffer fill time (rebuffer)
• Optimizations
• Congestion window
• Server throughput

Monitoring Service—Key Takeaways
• Use both Synthetic Monitor and RUM
• Measure 90th percentile values
• Availability: test your critical resources
• Index pages
• Video manifests
• Critical resources required for page load
• Performance: capture total load time
• Evaluate your user base
• Know your data
• Use Amazon CloudFront!

Summary
• Configure your distribution based on your use case
• Lambda@Edge as programmable CDN
• Use real-user monitor

Thank you!

Amazon CloudFront Flash Talks: Best Practices on Configuring, Securing, Customizing, and Monitoring Your Distribution - CTD301 - re:Invent 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Amazon CloudFront Flash Talks: Best Practices on Configuring, Securing, Customizing, and Monitoring Your Distribution - CTD301 - re:Invent 2017

Similar to Amazon CloudFront Flash Talks: Best Practices on Configuring, Securing, Customizing, and Monitoring Your Distribution - CTD301 - re:Invent 2017 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Amazon CloudFront Flash Talks: Best Practices on Configuring, Securing, Customizing, and Monitoring Your Distribution - CTD301 - re:Invent 2017