Objective
I have the following I wish to host under a single subdomain https://sub.example.com:
An external Wix site, which should be accessible at the root subdomain https://sub.example.com
An API accessible through AWS API Gateway, which should be accessible at https://sub.example.com/api
A flat static site in a restricted AWS S3 bucket, which should be accessible at https://sub.example.com/docs/
Attempted solution
I'm having trouble combining all this in AWS Cloudfront and Route 53. So far, I've tried setting up a Cloudfront distribution with the following default origins and behaviours:
Origin: https://username.wix.com/website (root domain as Origin domain and /website as Origin Path). Behaviour: Path as Default (*)
Origin: API Gateway Invoke URL (stage is Origin Path). Behaviour: Path as /api*.
Origin: S3 bucket domain. Behaviour: Path as /docs*.
In Route 53 I have the sub.example.com A and AAAA records pointing at the Cloudfront distribution domain.
Problems
I'm running into a few issues here:
Redirection of the Wix site is imperfect. Cloudfront hides the Wix domain at the root, but then redirects to the Wix domain for any subdirectories (e.g. https://sub.example.com/about. Also, when specifying index.html as Default root object (this is needed for the S3 static site), the Wix site 404s.
API calls work perfectly fine at https://sub.example.com/api/, but for some reason, the S3 static site is inaccessible (Access Denied) at https://sub.example.com/docs/, even when the Default root object is set as index.html.
Regarding Problem 1, I acknowledge that Cloudfront is not really meant for proxying external sites, but I'm not really sure how to otherwise keep this site at the root subdomain, especially since a Default (*) behaviour is mandatory.
Regarding Problem 2, I'm left a bit flummoxed. I tested all policies and OAIs using a separate distribution to the S3 bucket and confirmed that this is all correct. The Behaviour precedence is also correctly set (0: /docs*, 1: /api*, 2: *).
Regarding both these problems, I wonder if there may be some Route 53 wizardry that can partly solve them. Perhaps solutions can be found in Cloudfront Functions or Lambda#Edge. However, I'm not very experienced at these.
Any advice would be very welcome.
Related
Get into quite strange trouble. Have an Cloudfront distribution with two origins: S3 and ELB.
I've set behaviors for Default () and the Custom (/test-request).
On ELB side there is a rule to forward request from my domain to certain backend. Domain also added as an alias for cloudfront distribution.
But anytime I try to reach https://my.domain/test-request I've got... nothing. Looks like all request go to S3 content and never reach the backend I need.
I've already play with options on behavior side, read a lot of tutorials, but still no luck.
I'm not searching for clear answers, but at least I need direction of my research.
I'm assuming your Cloudfront distribution configuration is
/test-request to your ELB as first priority
Default (*) to your S3 as the catch-all
my.domain is mapped to your Cloudfront's CNAME correctly
When you try to access my.domain/test-request, Cloudfront will match your cache behavior and forwards to your ELB, together with the path /test-request.
Please note that it does NOT strip the /test-request path from your original request.
Your ELB then forwards the original request to your application server, using the path /test-request.
Therefore, it's likely that your application does not expose any resource or API under the path /test-request, and the request fails as a result.
Also, since you are in this topic, please note that by default, Cloudfront does not forward query parameters or browser cookie to your custom origin which is ELB in your case. If you want to capture them, you need to configure the cache behavior properly.
Refs:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesPathPattern
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesQueryString
I am trying to deploy my static website to S3 configuring CloudFront in front of it. But I am not able to configure Route53 to integrate with CloudFront. Below is what I have done so far.
I create an S3 bucket enabling static hosting and allowing public access. Then I deployed/ uploaded the files. I can access my website through the S3 website static URL, http://www.waiyanhein.com.s3-website-eu-west-1.amazonaws.com/.
I have my own domain called, waiyanhein.com.
I am trying to configure the CloudFront in front of my static website. So I created a CloudFront distribution. For the Origin Domain Name, I chose the S3 Bucket's static website URL. Then I chose "Compress Objects Automatically" as YES. In the "Alternate Domain Names (CNAMEs)" text field, I entered, "waiyanhein.com". Then I created the CloudFront distribution. Now my CloudFront distribution is up and running.
Then I tried to configure Route53 pointing to the CloudFront distribution. I tried creating a record choosing "Alias to CloudFront distribution" option. But I can't find my CloudFront distribution in the resources as you can see in the screenshot below.
What's wrong with my configuration?
I have sort of found out something in the CloudFront distribution too. When I edit the CloudFront distribution, the Alternative domains field is empty for some reasons. Then I entered the domains and clicked save. Then I got the following error.
com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: To add an alternate domain name (CNAME) to a CloudFront distribution, you must attach a trusted certificate that validates your authorization to use the domain name. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: 2d1bacd5-794c-46e5-beec-70b24fab83a6; Proxy: null)
If it does not appear automatically in the dropdown then AWS would be filtering this as it believes that the exact domain you intend to use is not usable for any CloudFront distributions in the account.
Please check the following are correct:
The exact record is covered by the alternative name(s) attached to the CloudFront distribution.
The CloudFront distribution is finished rolling out.
From the interface for the Alias value you should be able to paste the CloudFront domain name with a trailing . although in this new interface certain actions do not currently appear to work. If this is the case for you revert back to the original interface by clicking on the Switch to old console link on the left hand side of the screen and attempt from here.
Additional Comments
The screenshot indicates that an alternative domain that is being specified does not have a matching ACM certificate in us-east-1 which is attached to your CloudFront distribution.
If you do not have one generate a new one, then attach it to your CloudFront distribution when you add the alternative domain name.
I have tried several tutorials on how to set up https via CloudFront, but nothing is working. I am hosting from an S3 bucket and the app works fine via the http protocol, but I need it to be https.
Does anyone have a very thorough tutorial on how to make this work?
Some tutorials explain how to go about setting up a certificate, some explain how to use CloudFront to handle its distribution and I even found a CloudFront tutorial that explains how not using a link from the CloudFront setup forces the wrong region to be created for a certificate, so I even tried that.
I have not found anything that explains exactly what needs to be done for this very common setup, so I am hoping that someone here has some helpful resources.
I think the main issue I had when setting up a CloudFront distribution for an S3 static webhosting bucket was in the Orign Domain Name.
When you create a new distribution, under Origin Settings, the Origin Domain Name field works as a drop-down menu and lists your buckets. Except that picking a bucket from that list doesn't work for static webhosting. You need to specifically put the endpoint for the bucket there, for example:
mywebhostingbucket.com.s3-website-sa-east-1.amazonaws.com
And for custom domains, you must set up the CNAMEs under Distribution Settings, Alternate Domain Names (CNAMEs), and then make sure you have your custom SSL certificate in the us-east-1 region.
Then you can configure the alias record set for the CloudFront distribution.
Here is a complete answer for setting up a site with https.
I had everything in this document completed:
https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
And it worked to get the site live via http, but in order to add https, I needed to do the following:
I had requested a certificate for whatever.com, and tried several suggestions after that. But there were a couple of things missing.
To route traffic for the domain (whatever.com) to CloudFront distribution, you will need to clear the current value of the A record and fill in distribution domain name.
Several documents that I viewed said to point the whatever.com S3 bucket to the www.whatever.com S3 bucket, and use the second one to drive the site. Since CloudFront can serve multiple domain name, you may set CNAME of distribution with both, but you will need to set A record for both to distribution AND request an ACM certificate with both domain names (with and without the www). Also, I did ask this, so if you already have a certificate, you can't edit it to do this, which means you'll need to request a new one that has both whatever.com and www.whatever.com
After all of this, I still got "Access Denied" when I went to my site, so to fix this issue, I had to create a new origin in CloudFront with 'Origin Domain Name' set to the full address of the S3 bucket (without the http), and then set the Default (*) Behavior to the S3-Website-.....whatever.com bucket.
After all of this, my site was accessible via http AND https. I hope this helps anyone who experienced this challenge.
I'm having difficulty mapping a path-based route defined in CloudFront to custom domain. Any ideas what I need to change?
Background:
I've got a Vue app that I host on AWS in this way. This all works fine.
I build and push files to an s3 bucket (www.example.com).
CloudFront distribution that has an origin set up with that bucket (www.example.com.s3-website-us-west-1.amazonaws.com).
A CNAME record from www to the Cloudfront domain name (d111111abcdef8.cloudfront.net)
Now I want content from a separate domain on a separate server to show up as a path on the domain rather than a subdomain like it is now. I have a blog at blog.example.com that I would like to see as www.example.com/blog.
I went through these steps:
Add new custom origin to the Cloudfront distribution (blog.example.com)
Add a new behavior to Cloudfront distribution with path pattern="blog" and Origin set to the one above ("Custom-blog.example.com")
Set the new behavior as priority 0 and the default (*) to priority 1
https://d111111abcdef8.cloudfront.net/blog does a redirect to https://blog.example.com
but https://www.example.com/blog does not
Any ideas?
Here the config images:
Origin:
Behavior:
Set "Origin Protocol Policy" to "HTTPS Only". Otherwise, Cloudfront is talking plain HTTP with the origin, which may produces unwanted redirects.
After that, invalidate the desired path fragments, since redirects can be cached as well.
I have a single page application which is hosted on s3 and have cloudfront pointing to it. The app is multi-tenant, so the "tenants" need to be able to point their domain to a subdirectory.
Example: sometenant.com should point to app.domain.com/sometenant
Is this possible? Fairly hard to test with deployment/propagation/etc...
Also wondering if I could keep pushstate working, if it's possible that is...
This can be done, but not with a single CloudFront distribution -- a single CloudFront distribution can accept and handle requests for multiple subdomains, but unless the origin web server behind CloudFront can vary the response based on the hostname (and this won't work with S3 as the origin server), the basic assumption is that all of the domains pointing to a distribution result in the same behavior.
You'll need a CloudFront distribution for each domain. Not a problem, because the default limit of 200 distributions per account can be increased on request... and distributions are easily created in automation... and you don't pay a fee for each distribution -- just the bandwidth and requests, which will essentially the same.
Each CloudFront distribution can then be configured with a default root object -- this is the page fetched from the back-end when the root / page is requested. Set this to sometenant and, for this distribution, the root page will be requested from the bucket as GET /sometenant. Any other page/object request (images, css, etc.) is forwarded straight through to the bucket.
Each tenant site needs its domain added as an alternate name for its distribution, then you configure the tenant's site to point to the distribution's assigned dxxxexample.cloudfront.net endpoint, in DNS.