Request and Response Behavior for Amazon S3 Origins
How CloudFront Processes and Forwards Requests to Your Amazon S3 Origin Server
For information about how CloudFront processes viewer requests and forwards the requests to your Amazon S3 origin, see the applicable topic:
- Caching Duration and Minimum TTL
- Client IP Addresses
- Conditional GETs
- Cross-Origin Resource Sharing (CORS)
- GET Requests that Include a Body
- HTTP Methods
- HTTP Request Headers that CloudFront Removes or Updates
- Maximum Length of a Request and Maximum Length of a URL
- OCSP Stapling
- Query Strings
- Request Timeout
- Simultaneous Requests for the Same Object (Traffic Spikes)
Caching Duration and Minimum TTL
For web distributions, to control how long your objects stay in a CloudFront cache before CloudFront forwards another request to your origin, you can:
Configure your origin to add a
Expiresheader field to each object.
Specify a value for Minimum TTL in CloudFront cache behaviors.
Use the default value of 24 hours.
For more information, see Specifying How Long Objects Stay in a CloudFront Edge Cache (Expiration).
Client IP Addresses
If a viewer sends a request to CloudFront and does not include an
X-Forwarded-For request header, CloudFront gets the
IP address of the viewer from the TCP connection, adds an
X-Forwarded-For header that includes the IP address,
and forwards the request to the origin. For example, if CloudFront gets the IP address
192.0.2.2 from the TCP connection,
it forwards the following header to the origin:
If a viewer sends a request to CloudFront and includes an
X-Forwarded-For request header, CloudFront gets the IP address
of the viewer from the TCP connection, appends it to the end of the
X-Forwarded-For header, and forwards the request
to the origin. For example, if the viewer request includes
X-Forwarded-For: 192.0.2.4,192.0.2.3 and CloudFront gets the
192.0.2.2 from the TCP connection, it forwards the following header to the origin:
X-Forwarded-For header contains IPv4 addresses (such as 192.0.2.44) and IPv6 addresses
(such as 2001:0db8:85a3:0000:0000:8a2e:0370:7334), as applicable.
When CloudFront receives a request for an object that has expired from an edge cache, it forwards the request to the
Amazon S3 origin either to get the latest version of the object or to get confirmation from Amazon S3 that the CloudFront edge cache
already has the latest version. When Amazon S3 originally sent the object to CloudFront, it included an
ETag value and a
LastModified value in the response. In the new request that CloudFront forwards to Amazon S3, CloudFront adds one or both
of the following:
If-None-Matchheader that contains the
ETagvalue for the expired version of the object.
If-Modified-Sinceheader that contains the
LastModifiedvalue for the expired version of the object.
Amazon S3 uses this information to determine whether the object has been updated and, therefore, whether to return the entire object to CloudFront or to return only an HTTP 304 status code (not modified).
Amazon S3 doesn't process cookies. If you configure a cache behavior to forward cookies to an Amazon S3 origin, CloudFront forwards the cookies, but Amazon S3 ignores them.
Cross-Origin Resource Sharing (CORS)
If you want CloudFront to respect Amazon S3 cross-origin resource sharing settings, configure CloudFront to forward selected headers to Amazon S3. For more information, see Configuring CloudFront to Cache Objects Based on Request Headers.
GET Requests that Include a Body
If a viewer
GET request includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.
If you configure CloudFront to process all of the HTTP methods that it supports, CloudFront accepts the following requests from viewers and forwards them to your Amazon S3 origin:
CloudFront always caches responses to
HEAD requests. You can also configure CloudFront
to cache responses to
OPTIONS requests. CloudFront does not cache responses to requests that use the other methods.
If you use an Amazon S3 bucket as the origin for your distribution and if you use CloudFront origin access identities,
aren't supported in some Amazon S3 regions and
PUT requests in those regions require an additional header. For more information, see
Using an Origin Access Identity in Amazon S3 Regions that
Support Only Signature Version 4 Authentication.
If you want to use multi-part uploads to add objects to an Amazon S3 bucket, you must add a CloudFront origin access identity to your distribution and grant the origin access identity the applicable permissions. For more information, see Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content.
If you configure CloudFront to accept and forward to Amazon S3 all of the HTTP methods that CloudFront supports,
you must create a CloudFront origin access identity to restrict access to your Amazon S3 content and grant the
origin access identity the applicable permissions. For example, if you configure CloudFront to accept and forward these methods
because you want to use
PUT, you must configure Amazon S3 bucket policies or ACLs to handle
requests appropriately so viewers can't delete resources that you don't want them to. For more information, see
Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content.
For information about the operations supported by Amazon S3, see the Amazon S3 documentation.
HTTP Request Headers that CloudFront Removes or Updates
CloudFront removes or updates the following header fields before forwarding requests to your Amazon S3 origin:
Accept-Encoding– If the value contains
gzip, CloudFront forwards
Accept-Encoding: gzipto your Amazon S3 origin. If the value does not contain
gzip, CloudFront removes the
Accept-Encodingheader field before forwarding the request to your origin.
HEADrequests: CloudFront removes the
Authorizationheader field before forwarding the request to your origin.
OPTIONSrequests: CloudFront removes the
Authorizationheader field before forwarding the request to your origin if you configure CloudFront to cache responses to
CloudFront forwards the
Authorizationheader field to your origin if you do not configure CloudFront to cache responses to OPTIONS requests.
PUTrequests: CloudFront does not remove the header field before forwarding the request to your origin.
Connection– CloudFront replaces this header with
Connection: Keep-Alivebefore forwarding the request to your Amazon S3 origin.
Cookie– If you configure CloudFront to forward cookies, it will forward the
Cookieheader field to your Amazon S3 origin. If you don't, CloudFront removes the
Cookieheader field. For more information, see Configuring CloudFront to Cache Objects Based on Cookies.
Host– CloudFront sets the value to the name of the Amazon S3 bucket that is associated with the requested object.
User-Agent– CloudFront replaces the value of this header field with
Maximum Length of a Request and Maximum Length of a URL
The maximum length of a request, including the path, the query string (if any), and headers, is 20480 bytes.
CloudFront constructs a URL from the request. The maximum length of this URL is 8192 bytes.
If a request or a URL exceeds these limits, CloudFront returns HTTP status code 413, Request Header Fields Too Large, to the viewer, and then terminates the TCP connection to the viewer.
When a viewer submits an HTTPS request for an object, either CloudFront or the viewer needs to confirm with the certificate authority (CA) that the SSL certificate for the domain has not been revoked. OCSP stapling speeds up certificate validation by allowing CloudFront to validate the certificate and to cache the response from the CA, so the client doesn't need to validate the certificate directly with the CA.
The performance improvement of OCSP stapling is more pronounced when CloudFront receives a lot of HTTPS requests for objects in the same domain. Each server in a CloudFront edge location must submit a separate validation request. When CloudFront receives a lot of HTTPS requests for the same domain, every server in the edge location soon has a response from the CA that it can "staple" to a packet in the SSL handshake; when the viewer is satisfied that the certificate is valid, CloudFront can serve the requested object. If your distribution doesn't get much traffic in a CloudFront edge location, new requests are more likely to be directed to a server that hasn't validated the certificate with the CA yet. In that case, the viewer separately performs the validation step and the CloudFront server serves the object. That CloudFront server also submits a validation request to the CA, so the next time it receives a request that includes the same domain name, it has a validation response from the CA.
CloudFront forwards HTTP or HTTPS requests to the origin server based on the protocol of the viewer request, either HTTP or HTTPS.
If your Amazon S3 bucket is configured as a website endpoint, you cannot configure CloudFront to use HTTPS to communicate with your origin because Amazon S3 doesn't support HTTPS connections in that configuration.
For web distributions, you can configure whether CloudFront forwards query string parameters to your Amazon S3 origin. For RTMP distributions, CloudFront does not forward query string parameters. For more information, see Configuring CloudFront to Cache Based on Query String Parameters.
The request timeout for CloudFront depends on the HTTP method:
HEADrequests – If Amazon S3 doesn't respond within 30 seconds or stops responding for 30 seconds, CloudFront drops the connection and makes two additional attempts to contact the origin. If the origin doesn't reply during the third attempt, CloudFront doesn't try again until it receives another request for content on the same origin.
PUTrequests – If Amazon S3 doesn't respond within 30 seconds, CloudFront drops the connection and doesn't try again to contact the origin. The client can resubmit the request if necessary.
The request timeout cannot be changed.
Simultaneous Requests for the Same Object (Traffic Spikes)
When a CloudFront edge location receives a request for an object and either the object isn't currently in the cache or the object has expired, CloudFront immediately sends the request to your Amazon S3 origin. If there's a traffic spike—if additional requests for the same object arrive at the edge location before Amazon S3 responds to the first request—CloudFront pauses briefly before forwarding additional requests for the object to your origin. Typically, the response to the first request will arrive at the CloudFront edge location before the response to subsequent requests. This brief pause helps to reduce unnecessary load on Amazon S3. If additional requests are not identical because, for example, you configured CloudFront to cache based on request headers or query strings, CloudFront forwards all of the unique requests to your origin.
When the response from the origin includes a
Cache-Control: no-cache header, CloudFront typically forwards the next request
for the same object to the origin to determine whether the object has been updated. However, when there's a traffic spike and CloudFront pauses
after forwarding the first request to your origin, multiple viewer requests might arrive before CloudFront receives a response from the origin.
When CloudFront receives a response that contains a
Cache-Control: no-cache header, it sends the object in the response
to the viewer that made the original request and to all of the viewers that requested the object during the pause. After the response arrives
from the origin, CloudFront forwards the next viewer request for the same object to the origin. In CloudFront access logs, the first request is identified
Miss in the
x-edge-result-type column, and all subsequent requests that CloudFront received during the pause
are identified as a
Hit. For more information about access log file format, see
Web Distribution Log File Format.
How CloudFront Processes Responses from Your Amazon S3 Origin Server
If an object is not in the edge cache, and if a viewer terminates a session (for example, closes a browser) after CloudFront gets the object from your origin but before it can deliver the requested object, CloudFront does not cache the object in the edge location.
HTTP Response Headers that CloudFront Removes or Updates
CloudFront removes or updates the following header fields before forwarding the response from your Amazon S3 origin to the viewer:
Set-Cookie– If you configure CloudFront to forward cookies, it will forward the
Set-Cookieheader field to clients. For more information, see Configuring CloudFront to Cache Objects Based on Cookies.
Transfer-Encoding– If your Amazon S3 origin returns this header field, CloudFront sets the value to
chunkedbefore returning the response to the viewer.
Via– CloudFront sets the value to:
before returning the response to the viewer. For example:
Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)
Maximum File Size
The maximum size of a response body that CloudFront will return to the viewer is 20 GB. This includes
chunked transfer responses that don't specify the
Content-Length header value.
You can configure an Amazon S3 bucket to redirect all requests to another host name; this can be another Amazon S3 bucket or an HTTP server. If you configure a bucket to redirect all requests and if the bucket is the origin for a CloudFront distribution, we recommend that you configure the bucket to redirect all requests to a CloudFront distribution using either the domain name for the distribution (for example, d111111abcdef8.cloudfront.net) or an alternate domain name (a CNAME) that is associated with a distribution (for example, example.com). Otherwise, viewer requests bypass CloudFront, and the objects are served directly from the new origin.
If you redirect requests to an alternate domain name, you must also update the DNS service for your domain by adding a CNAME record. For more information, see Using Alternate Domain Names (CNAMEs).
Here's what happens when you configure a bucket to redirect all requests:
A viewer (for example, a browser) requests an object from CloudFront.
CloudFront forwards the request to the Amazon S3 bucket that is the origin for your distribution.
Amazon S3 returns an HTTP status code 301 (Moved Permanently) as well as the new location.
CloudFront caches the redirect status code and the new location, and returns the values to the viewer. CloudFront does not follow the redirect to get the object from the new location.
The viewer sends another request for the object, but this time the viewer specifies the new location that it got from CloudFront:
If the Amazon S3 bucket is redirecting all requests to a CloudFront distribution, using either the domain name for the distribution or an alternate domain name, CloudFront requests the object from the Amazon S3 bucket or the HTTP server in the new location. When the new location returns the object, CloudFront returns it to the viewer and caches it in an edge location.
If the Amazon S3 bucket is redirecting requests to another location, the second request bypasses CloudFront. The Amazon S3 bucket or the HTTP server in the new location returns the object directly to the viewer, so the object is never cached in a CloudFront edge cache.