I have two private S3 buckets, in different regions, served via CloudFront with a custom domain name.
What I would like to do is have different S3 buckets in each region to be served and have CloudFront serve those buckets (via Edge) via my custom domain name.
However, I think my understanding of Origins and Origin Groups is lacking...
Given I can only have two origins in a group, how can CloudFront be configured to reference more than 2 buckets as origins?
Related
I have a external domain which I want to use for a static website on aws.
I found a couple of examples using S3 + CloudFront + Route 53
But is it possible to keep the name server of my domain and work with the external nameserver? (No Route 53?)
Yes, it is possible, Route53 isn't mandatory to use CloudFront and S3. You can have CNAME configured in your DNS provider. However, there is a RFC limitation on CNAME restriction for naked/apex domain(as you cannot have a CNAME record and another DNS record of a different type) so Route53 provides an alternate record called alias record, as long as your DNS provider provides this feature, you're good to go. e.g: CloudFlare provides CNAME flattening
https://support.cloudflare.com/hc/en-us/articles/200169056-Understand-and-configure-CNAME-Flattening
Amazon Route53 alias:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
Is it possible to restrict an Amazon S3 website endpoint to CloudFront only? I see this is possible for S3 rest endpoints but was wondering if there were any new workarounds to do this for S3 website endpoints.
For website endpoint you can use bucket policy to allow only CloudFront IP address, not restrictive as OAI but still a way.
http://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips
For S3 as an origin, CLOUDFRONT_REGIONAL_EDGE_IP_LIST IP address are not used unless you're using lambda#edge or AWS has enabled it intentionally so you can allow only CLOUDFRONT_GLOBAL_IP_LIST.
I have a subdomain for my website named api.example.com and I want to have the following achieved:
have 1 CloudFront distribution for an S3 static website mapped to api.example.com
have the API Gateway custom domain name mapped to the same subdomain api.example.com
The steps I did to achieve this setup are:
Create an API Gateway custom domain api.example.com and set the base mappings for the APIs I want to expose as v1 (version 1 for now)
In Route 53 I created a CNAME record api.example.com pointing to the Edge optimized Target domain name of the API Gateway from Step 1
Note: at this point I get, as expected, the 200 response from https://api.example.com/v1
I created an S3 bucket and set it up for Static website hosting. All files uploaded successfully and working.
I created a new Cloudfront distribution with the origin in the S3 bucket. At this point, for this Cloudfront distribution, I can not set the CNAME record as api.example.com because it is already used by the first Custom Domain Name set in the API Gateway and AWS gives an CNAMEAlreadyExistsException - so I leave this field empty. Accessing the CloudFront distribution for the S3 bucket works as expected.
Under the CloudFront distribution generated for the S3 bucket I add another origin (the API Gateway custom domain name) and create the Bevahior rule to route the v1/* calls to API Gateway custom domain name.
At this point, things are not falling into place anymore:
- when accessing https://api.example.com I get the {"message": "Fobidden" } from the API Gateway distribution. However the URL https://api.example.com/v1 still returns the expected result.
Question: Is there anything which I missed to set so it will work for the URL https://api.example.com to return the content of the S3 static website?
Note: also, the fact that I have an empty CNAME field on the S3 bucket cloudfront distribution while I have a CNAME defined in Route53 using the same cloudfront distribution prompts me an warning message saying that this situation may expose me to a vulnerability.
For your usecase mentioned, you only need one Cloudfront distribution (which is mapped to api.example.com) where it should be able to forward the traffic to S3 and API Gateway (both added as origins to the same distribution) using different behavior configurations. You can configure the behaviors in a way that /v1/* traffic is routed to the API Gateway and other traffic to S3.
When setting up the origins and behaviors, there are few configurations you need to follow.
Make sure both S3 and API Gateway behaviors redirects HTTP to HTTPS.
When adding API Gateway origin set only to forward HTTPS traffic.
In API Gateway behavior, whitelist the headers for accept-* ones , authorization, origin, referrer and makesure you do not whitelist 'Host' header.
In both origins, don't add any paths.
For the API Gateway behavior configure the TTLs to 0 and allow all the methods (GET, POST & etc.)
Let’s assume that I have a S3 hosted website. Aside from that I have an EC2 that would be to receive http requests from that website. Is there a way that I can set up a security group so that that EC2 can only receive http requests from that website? I know that if the website was hosted on another EC2 I could this vos the IP address or a load balancer, I’m just not sure how to go about it in the S3 website case.
When you launch a website on S3 you will have all Static front-end Contents being served (Just like having a pure HTML/CSS/Javascript website with no Webserver on your local Machine). Means all the calls, XHRs or embedded resource pointing to your EC2 instance are requests which are generated by visitors Browsers with Network Source of their IP with the Origin of "S3 or If you place a CloudFront on S3 it will be CloudFront as Origin in HTTP Headers) communicating with the Destination Target of EC2 (Where you have your WebServer serving on port 80or443). There is no SG that could be applied on the Bucket. However, S3 Buckets can be configured with a Policy to white-list certain IPs address to access Bucket Content and subsequently the Static Web content hosted on it. You can Also enforce CORS policy and have conditions to check Referees and Origins.
Putting aside the Bucket Level Policy, IP White listing, CORS and Condition Restrictions If you serve your Web S3 Bucket from a CloudFront Distribution you can apply GEOIP restriction Rules at the CloudFront level as well.
Just in case if say like you have an API server on EC2 which is going to be called by your CloudFront Domain you can Apply some access control at both CloudFront and EC2 Web level to enforce tightened CORS policies. I.e. Other Websites on the Internet can not Hijack your API service or do CSRF attacks(again as a Browser Level Protection Only).
I have hosted my static website in S3 bucket using angular5 and mapped to a custom domain using Route53. I want to have SSL/TLS(HTTPS) for my site, so I used ACM to generate the certificate and mapped it to my site using CloudFront. The ACM status is issued and it says it's in use. but my website is not HTTPS enabled.
Everything is hosted in us-east-1, I am accessing my site from East-Asia. Is this an issue?
Am I missing something?
The ACM certificate for CloudFront should have been generated in the N.Virginia region. Then you should be able to assign it to your CloudFront distribution.
In your CloudFront distribution Origin, you should set the "Origin Protocol Policy" parameter to "HTTPS Only" if you want to use HTTPS between CloudFront and your S3 bucket.
In your CloudFront distribution Cache Behavior, you should set the "Viewer Protocol Policy" parameter to "Redirect HTTP to HTTPS" so that every HTTP communication between the clients and your CloudFront distribution is redirected to use HTTPS.
Then you would have to change your DNS record to point to the CloudFront distribution CNAME.
Additionally you could configure your CloudFront distribution and your S3 bucket to restrict access directly from the clients to the S3 buckets, so that every request goes through your ClouddFront distribution.
Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content
Typically, if you're using an Amazon S3 bucket as the origin for a
CloudFront distribution, you grant everyone permission to read the
objects in your bucket. This allows anyone to access your objects
either through CloudFront or using the Amazon S3 URL. CloudFront
doesn't expose Amazon S3 URLs, but your users might have those URLs if
your application serves any objects directly from Amazon S3 or if
anyone gives out direct links to specific objects in Amazon S3