If you're accessing the root of your CloudFront distribution, you need to set a default root object:
To specify a default root object using the CloudFront console:
Sign in to the AWS Management Console and open the Amazon CloudFront console at https://console.aws....
You're making two requests for the same object, one from HTML, one from XHR. The second one fails, because Chrome uses the cached response from the first request, which has no Access-Control-Allow-Origin response header.
Chromium bug 409090 Cross-origin request from cache failing after regular request is cached describes this problem, and it's a "...
I've just had the same issue and while Kousha's answer does solve the problem for index.html in the root path, my problem was also with sub-directories as I used those combined with index.html to get "pretty urls" (example.com/something/ rather than "ugly" example.com/something.html)
Partially it's Amazon's fault as well, because when you set up CloudFront ...
I've hit a few pages in Google where you can set the Header in S3 for individual objects. That's really not a productive way to do it specially since in my case we are talking of several objects.
Well, "productive" or not, that is how it actually is designed to work.
CloudFront does not add Cache-Control: headers.
CloudFront passes-through (and also ...
First thing, you need to make sure that you whitelist origin header:
If you want CloudFront to respect cross-origin resource sharing settings, configure CloudFront to forward the Origin header to your origin.
Also see: http:...
Route53 alias records is an own concept separate from DNS protocol record types: e.g. A is an address record and CNAME is a canonical name record. CNAME is the one that acts like an alias pointing to the canonical name, while A has nothing to do with aliases. (See RFC 1035.)
An alias record is an internal Amazon specific pointer working on a higher level; ...
I had the same issue as @Cezz, though the solution would not work in my case.
As soon as static website hosting is enabled for the bucket, it means users can access the content either via the Cloudfront URL, or the S3 URL, which is not always desirable. For example, in my case, the Cloudfront distribution is SSL enabled, and users should not be able to ...
As of March 2014, Amazon CloudFront supports SNI, at no additional cost, see details here.
This will allow you to use your ssl certificate on CloudFront, without paying $600 monthly.
Please note that SNI is not supported by (extremely) old browsers (pre-IE7, pre-Chrome6, pre-FF 2), see details in link above.
This is a bit more complicated than the accepted answer indicates.
The CORS support when using Cloudfront + S3 is actually implemented in S3 and it works like this according to Amazon:
The request's Origin header must match an AllowedOrigin element.
The request method (for example, GET or PUT) or the Access-Control Request-Method header in case the of a ...
An update on this...
HTTP response headers can now be customized via Lambda@edge functions. Please see http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html for the documentation. To try this, create a new lambda function in the AWS console. Choose 'Edge Nodge.js 4.3' for the language and look for the cloudfront-modify-...
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to ...
Two Cloudfront Distributions
Since AWS allows for overlap between wildcard alternate CNAMEs in the same AWS account, you can switch between two cloudfront distributions in the following manner:
Use www.domain.com as Alternate CNAME for Prod distribution 1
Use *.domain.com as Alternate CNAME for Prod distribution 2
Point your CNAME DNS www.domain.com to ...
Presumably, if the service on the ELB only answers to www.example.com then that's the hostname you're going to be pointing to CloudFront -- so, your solution is straightforward: in the Cache Behavior settings, whitelist the Host header for forwarding to the origin.
In this configuration, CloudFront passes through the Host header sent by the browser, which ...
(Updated for future reference)
Let's say your CloudFront distribution is in account 123456789012 with logging configured to a bucket your-logging-bucket in a different account.
Create a S3 Bucket Policy that gives the CloudFront account 123456789012 permissions to do s3:GetBucketAcl and s3:PutBucketAcl on your-logging-bucket.
This is the required Bucket ...
The upside is that it's very flexible. A wildcard cert allows you to add alternate domains in the future. The "normal" downsides to a star cert in general is they can be expensive and they create the potential for a security vulnerability.
For your use case they are not expensive at all, AWS Certificate Manager is free:
Public SSL/TLS certificates ...
Yes using CloudFront is a legitimate way to enable https, and (as iBug pointed out in comments) can reduce your bandwidth egress costs a little. Another option is to use an application balancer, which integrates with AWS Certificate Manager (ACM) to enable https.
A lower cost method is to install a certificate directly on your EC2 instance using Lets Encrypt ...
[Note: This answer was correct up until March 2014]
No, this is not possible with CloudFront. The user will hit the mismatched certificate before CloudFront processes the request because of the natures of DNS and SSL. You might consider CloudFlare's SSL offering.
In my case I was using multiple origins with "Path Pattern" Behaviors along with an Origin Path in my S3 bucket:
/images/* -> My-S3-origin
Origin Path: /images
/images/my-image.jpg -> 403
What was happening was the entire CloudFront GET request gets sent to the ...
A bit late in the game here, but for anyone else looking for this.
I believe this can be done using lambda@edge. Similar to A/B tests.
You can implement a lambda function triggered when a user requests a url. Choose to serve the blue/green content from different origins or url prefix. A cookie ...
When using an S3 bucket with the web site hosting feature (which enables index documents) you don't want to use the REST endpoint of the bucket, which is what CloudFront will offer you in the console. You need to type in the web site endpoint, instead.
On the Create Distribution page, for Origin Settings, type the Amazon S3 static website hosting ...
It's true that Cloudfront does not charge for storage, but here is the point you are misinterpreting:
my files will be copied to many geographically distributed data centers.
Cloudfront has dozens of edge locations around the globe, but your content is not exactly copied to them.
Instead, when a browser tries to fetch one of your files/...
Create a second distribution.
CloudFront can select the origin server based on path pattern matching only -- not the hostname, or other request parameters.
This behavior likely results from the fact that by default CloudFront sets the Host: HTTP request header to the origin hostname, in this case elb.example.com. The application then presumably generates links based on that hostname.
If, instead, you configure CloudFront to whitelist that header for forwarding to the origin, the Host header sent by the browser ...
If you have this issue, check first when you configure the s3 bucket origin for the cloudfront, the autocomplete returns the s3 REST endpoint domain.amazonaws.com which return this ListBucketResult response.
You have to write down manually the website endpoint domain.s3-website-region.amazonaws.com
Important: If you have wrongly configured cloudfront with ...
The distribution only requires you to provision a hostname as the origin. As long as that hostname happens to be able to route traffic to your origin, CloudFront doesn't need to have an awareness of what specifically it is or how it works. (The exception is when the origin is S3.)
For that host, you'd use essentially what you're using now, but on the back ...
You can create a lambda function, setup API gateway, and then configure CloudFront to forward certain paths (e.g. /rest/*) to API gateway, and serve everything else from a S3 bucket.
Here is a complete walk through showing how to do this: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/
In Amazon Hosted Zone you have different set of name servers than at your registrar.
Domain Name: ADAMATAN.COM
Registrar: Gandi SAS
Name Server: NS-1193.AWSDNS-21.ORG
Name Server: NS-1889.AWSDNS-44.CO.UK
Name Server: NS-4.AWSDNS-00.COM
Name Server: NS-1193.AWSDNS-21.ORG
None of the name servers above answers to adamatan.com SOA & cdn.adamatan.com. ...
Given the choice between CloudFront and APi Gateway, CloudFront is the correct solution. API Gateway is not really suited for hosting an entire site, and there are complications related to large payloads and binary content.
Both can be used as reverse proxies but CloudFront is more straightforward for use cases beyond APIs and has unlimited cache storage.