I'm using cloudfront to redirect a web app to a S3 bucket for some media content. As we trying to add HTTPS to our test environment, we wanted to add the https://app.foo.com origin to our cloudfront distribution. We've tried two different ways:
On the Create Origin tab, creating the second origin with the https
By editing the first working origin (in http) and adding a second origin header beneath the first one (in the origin settings tab).
None of these solutions seems to works, the app with http origin can access the bucket content. But the redirection with https does not work. I must precise that our authorizations on the bucket are ok, we can access the bucket content with the CloundFront link, and the CORS rules accept both http and https for the app. It looks like the https origin is not processed by ClondFront.
Thanks in advance
You need to understand what CloudFront is. It isn't "redirecting" users to an S3 bucket like you state in your question. It is loading, and caching the contents of the S3 bucket, and serving it to the user on request. An origin isn't a location for CloudFront to redirect users to. An Origin is a location for CloudFront to load resources from. In the context of http vs. https connections and CloudFront, you have the following decisions to make:
Will CloudFront communicate with the origin via http or https. This decision will not affect your users ability to load http or https resources in any way.
Will CloudFront serve both http and https content to your users, or will it redirect all http requests to https. This decision is not impacted by the origin configuration in any way.
The user's web browser is making an HTTP connection to a CloudFront server, and receiving the response from CloudFront. The user's web browser is never making a connection directly to S3.
You can't have two origins that only differ by http/https protocol. Both of those origins would be at the same path, and contain the same content. CloudFront only wants one of those origins, which it will connect to as needed to populate its cache.
Related
I have a origin in Cloudfront: mybucket.s3.amazonaws.com/path
And a behavior that use this origin to serve *.jpg.
I also have a default Behavior serving a static web site from another origin (another bucket).
Both behaviours is set to HTTP and HTTPS.
SSL works fine for the website.
However, when i try to browse a image directly only http works.
http://www.example.com/image.jpg does work
But the same URL with https just render the website (as if the behaviour was not triggered).
Do I need to configure something on the S3 side?
Having trouble setting a cookie (subdomain to parent) in a CloudFront configuration:
S3 bucket serving a static site with a CloudFront distribution. CNAME: example.com
API Gateway API with a custom domain: api.example.com
S3 bucket with a CloudFront distribution with CNAME: files.example.com
The web application on example.com contacts a lambda proxy GET method on api.example.com. This function, among other things, returns headers with values generated by AWS.CloudFront.Signer.getSignedCookies()
{
'Set-Cookie': `CloudFront-Expires=...; Domain=.example.com`,
'SEt-Cookie': `CloudFront-Signature=...; Domain=.example.com`,
'SET-Cookie': `CloudFront-Key-Pair-Id=...; Domain=.example.com`
}
These are being sent to the client with the response, but for some reason are not sent in GET requests to the S3 bucket on files.example.com.
I am not certain if the issue is with the cookies being set or being sent: By looking at the application tab in chrome dev tools it seems that the cookies aren't there. However, in the network tab the cookies are indeed being sent alongside requests to api.example.com (but not with requests to files.example.com).
As far as I can tell the configuration should work in terms of Domain cookie policy (the subdomain is attempting to set a cookie with a parent domain, under which is a different subdomain of the parent, that should receive the cookies). Any other immediate suspects for this sort of behaviour?
You want to use the cookie domain .example.com instead of example.com. The leading . allows subdomains to access the cookie as well.
You also need to ensure that the cookies are being forwarded to the origin in your CloudFront behavior.
I have my website like this "https://hr.mywebsite.com", I am able to go to my website when i type the whole url(https://hr.mywebsite.com).
But I want to go to my website without typing "https://".
That is if i type "hr.mywebsite.com" it should open my website. My website is hosted on AWS CloudFront.
You need to set an HTTP to HTTPS redirect on your CloudFront distribution. CloudFront has a setting for this.
To configure CloudFront to require HTTPS between viewers and CloudFront
Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/.
In the top pane of the CloudFront console, choose the ID for the distribution that you want to update.
On the Behaviors tab, choose the cache behavior that you want to update, and then choose Edit.
Specify one of the following values for Viewer Protocol Policy:
Redirect HTTP to HTTPS
Viewers can use both protocols. HTTP GET and HEAD requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.
Important
CloudFront doesn't redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).
When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the object that are returned by your origin.
From http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html
I have an Amazon CloudFront setup that points to an S3 bucket as a CDN. I also have an alternate domain name (not on Route53) that points to this CloudFront.
I kept having trouble getting scripts to pull through the CDN when using the alternate domain name - but if I use the native one from the CloudFront control panel, it works.
Is there something special I need to do other than just set the domain name CNAME to point to the amazon CloudFront address for CORS to work?
An important part of correctly caching web requests is to ensure that a response to be served from the cache is "correct," in the sense if whether it will match the response generated by the origin, for the same request.
This isn't as simple as it sounds, since responses can vary based on the content if certain request headers.
CloudFront adopts a conservative and safe approach, by stripping most request headers as it forwards requests to the origin server -- if the server can't see the header, it can't use the header to vary its response.
In the case of CORS, it's critical for the origin server to see the Origin:, Access-Control-Request-Headers:, and Access-Control-Request-Method: headers so it can respond accordingly.
But forwarding unnecessary headers to the origin server causes inefficient caching, since the cached response will only be served against identical future requests, identical including the forwarded headers.
So the three CORS request headers must be "whitelisted" in the CloudFront cache behavior, so that they will be forwarded to the origin server (in this case, S3).
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors
I have a domain formulagrid.com.
I am using AWS S3 to host it as a static website. My problem was that I wanted to redirect the www subdomain to the bare domain like so:
https://www.formulagrid.com -> https://formulagrid.com
http://www.formulagrid.com -> https://formulagrid.com
Amazon provides URL redirecting from S3 bucket to S3 bucket if both are setup for static website hosting.
So what I had to do was set up two buckets:
formulagrid.com - actual website
www.formulagrid.com - exists solely to redirect to the actual website
This works perfectly fine if you're operating only over HTTP, but S3 has absolutely no support for HTTPS.
The way that one can use HTTPS to connect to an S3 static website is by setting up a CloudFront distribution in front of an S3 bucket. CloudFront, however, while it does provide HTTPS, mainly exists to function as a CDN.
Initially, I had a single CloudFront distribution setup in front of the S3 bucket holding the actual site. Everything seemed operational: the site was distributed over the CDN, it had HTTPS, and HTTP redirected to HTTPS.
There was one exception.
https://www.formulagrid.com was a completely broken page
After trying to find the source of the error for a while, I realized it's because it wasn't going through the CDN, and trying to access S3 over HTTPS doesn't work.
Finally, what I ended up having to do was provision another distribution to sit in front of the www S3 bucket so it was accessible over HTTPS. This is where my concerns come in because, like I mentioned earlier, CloudFront's main purpose is to be a CDN.
It doesn't make any sense to me to have a CDN sit in front of a url that just redirects to another. Also it brings up the question of whether I would be double charged for every request that hits the www subdomain because it'd hit the other CloudFront distribution after being redirected.
This is frustrating because I'm trying to do a "serverless" architecture using Lambda, and having to provision an EC2 instance just to do url rewriting isn't something I want to do unless it's my last resort.
The solution would be trivial if Amazon offered any form of URL rewriting or if CloudFront itself did redirecting, but neither of these exist as far as I know (let me know if they do).
I'm new to AWS so I'm hoping someone with more experience can point me in the right direction.
You're thinking too narrowly -- there's nothing wrong with this setup.
The solution would be trivial if Amazon offered any form of URL rewriting
They do -- the empty bucket.
S3 has absolutely no support for HTTPS.
Not for web site hosted buckets, no... but CloudFront does.
CloudFront is not just a CDN. It's also an SSL offloader, Host: header rewriter, path prepender, geolocator, georestrictor, secure content gateway, http to https redirector, error page customizer, root page substituter, web application firewall, origin header injector, dynamic content gzipper, path-based multi-origin http request router, viewer platform identifier, DDoS mitigator, zone apex alias target... so don't get too hung up on "CDN" or on the fact that you're stacking one service in front of another -- CloudFront was designed, in large part, to complement S3. They each specialize in certain facets of storage and delivery.
So, you did it right... most of it, anyway... Create a bucket, configure it for web site hosting, set it to redirect all requests to another site (the non-www) and put a CloudFront distribution in front of it -- using the web site endpoint URL for with bucket in CloudFront, not the one from the drop-down list -- configured with high TTLs so that CloudFront will send a minimal number of requests to S3 then put your (free!) SSL certificate from Amazon Certificate Manager. HTTPS alternate domain routing: solved. No servers, no troubleshooting, and cheap. The only charges are the usage -- there is no background recurring charge as there would be with servers.
Extra credit: configure the redirecting CloudFront distribution for the cheapest rate tier. Redirects from more expensive locations will either be routed to a cheaper edge location or -- at CloudFront's option -- may be served out of a higher cost location but billed at the lower rate.
Note that most of the time, CloudFront should serve the redirects from S3 from it's cache... and when you configure a bucket to redirect all requests to another hostname, the redirect is a 301 permanent redirect -- which browsers are supposed to cache, themselves.