I'm new to AWS and setting up a Cloudfront distribution. From what I understand Cloudfront is designed to be used as a CDN.
I have a single-page-app that requires to communicate with the api from the same domain under /api/graphql path pointing to a GQL server that is not hosted in AWS.
My question is is there a way to bypass the cloudfront cache for /api* and proxy to the server?
So far I tried to create a new custom origin in the same distribution setup a cache behavior for the /api* path to point to the custom origin, but it seems the viewer request headers are not sent to the origin server and things don't work properly.
You can add/attach a cache policy for /api*.
See here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/working-with-policies.html
This way, you can disable cache for Cloudfront and forward all headers to your origin.
Related
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.
are there any benefits to running a static website via S3/CloudFront vs running one via Express (via Fargate) sitting behind API Gateway? In terms of performance or any other considerations? The latter approach allowing api endpoints to also be hosted via Express/API Gateway on the same domain.
Scaling in case of Cloudfront/S3 is better.
Caching and serving from edge locations in Cloudfront S3.
Cloudfront gives you options to alter req and response, say you want to add CSP headers to all response going out from your domain or say you want to prevent open redirect from you domain URL, you can use origin request and origin response lambdas in cloudfront.
I'm new with AWS WAF and get stuck with setting up it for application that hosts on some dedicated server. I didn't find any information how to set up it without migration to aws servers, but I found that WAF integrated with CloudFront. But anyway I found only few information that explain how to integrate this CDN with my web application. So, the main question is:
Is it possible to use AWS WAF with application that hosted on some dedicated server? And if it possible - can you provide some guides and/or docs for setting up?
Yes, you can use WAF with a server outside AWS.
WAF works with CloudFront, and CloudFront does not require the origin server to be in the AWS ecosystem.
When you create a distribution, you specify where CloudFront sends requests for the files. CloudFront supports using several AWS resources as origins. For example, you can specify an Amazon S3 bucket or a MediaStore container, a MediaPackage channel, or a custom origin, such as an Amazon EC2 instance or your own HTTP web server. (emphasis added)
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html
Configuring CloudFront to work with your external server is no different than configuring it to work with a server in EC2. Your DNS entry (e.g. www.example.com) changes to point to CloudFront, and CloudFront connects to your server using a new name that you create (e.g. origin.example.com). CloudFront proxies requests through to your server, unless the edge location handling the a given request happens to have access to a copy of the same resource that it cached while handling a previous request for the same page -- that's how CloudFront gets your content, by caching it as it handles requests that are passing through. (You don't pre-load any content into CloudFront.) If CloudFront has a cached copy, your server sees nothing, and CloudFront returns the object to the browser from its cache. But CloudFront isn't strictly a CDN, even though they market it that way. It is a global network of reverse proxies and high-reliability/low-latency transport.
You'll want to take steps to ensure that the web server rejected requests that didn't come through CloudFront. See Using Custom Headers to Restrict Access to Your Content on a Custom Origin as well as the list of CloudFront IP Addresses which you could use on your web server's firewall.
Once you have your site working through CloudFront, all you do is activate WAF on the distribution. CloudFront is very tightly integrated with WAF so that is a very simple change, once you have your WAF rules set up.
I have setup my nopCommerce 4.10 (.net Core) in the Cloud Ec2 instance.
And also setup the CDN CloudFront for it using a Load-balancer.
The main purpose of going to cloud and cdn was to improve the page speed for the client(the client asked for this).
Page speed after this has not improved and is showing that the image header has "cache policy" is not effective.
For this I need to set cache-control in the header.
I checked the original image has this value but the load-balancer and cdn doesn't have this value for the images.
Please let me know how to set the cache-control in the header for CloudFront cdn.
Cache-control header should come from CloudFront Origin
(application that is behind Cloudfront).
Then cache-control header will be used by:
Cloudfront to cache objects in edge locations
User's browser, to cache objects directly in browser
In case of image, proper cache headers can be set in a place image is stored: S3 bucket, Apache config, etc..
Cloudfront does not strip cache headers, coming from origin. But your load balancer could. Open image via CloudFront Origin URL, to make sure headers are there.
Thanks for your response.
I think there was some issue with the load balancer configuration because of which this was happening to me.
After re-configuring the load balancer it has started to work.
You can now create a "Response headers policy"
Then, specify a custom header that is "Cache-Control" with the desired value.
Does AWS allow usage of Cloudfront for websites usage, eg:- caching web pages.
Website should be accessible within corporate VPN only. Is it a good idea to cache webpages on cloudfront when using Application restricted within one network?
As #daxlerod points out, it is possible to use the relatively new Web Application Firewall service with CloudFront, to restrict access to the content, for example, by IP address ranges.
And, of course, there's no requirement that the web site actually be hosted inside AWS in order to use CloudFront in front of it.
However, "will it work?" and "are all the implications of the required configuration acceptable from a security perspective?" are two different questions.
In order to use CloudFront on a site, the origin server (the web server where CloudFront fetches content that isn't in the cache at the edge node where the content is being requested) has to be accessible from the Internet, in order for CloudFront to connect to it, which means your private site has to be exposed, at some level, to the Internet.
The CloudFront IP address ranges are public information, so you could partially secure access to the origin server with the origin server's firewall, but this only prevents access from anywhere other than through CloudFront -- and that isn't enough, because if I knew the name of your "secured" server, I could create my own CloudFront distribution and access it through CloudFront, since the IP addresses would be in the same range.
The mechanism CloudFront provides for ensuring that requests came from and through an authorized CloudFront distribution is custom origin headers, which allows CloudFront to inject an unknown custom header and secret value into each request it sends to your origin server, to allow your server to authenticate the fact that the request not only came from CloudFront, but from your specific CloudFront distribution. Your origin server would reject requests not accompanied by this header, without explanation, of course.
See http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html#forward-custom-headers-restrict-access.
And, of course, you need https between the browser and CloudFront and https between CloudFront and the origin server. It is possible to configure CloudFront to use (or require) https on the front side or the back side separately, so you will want to ensure it's configured appropriately for both, if the security considerations addressed above make it a viable solution for your needs.
For information that is not highly sensitive, this seems like a sensible approach if caching or other features of CloudFront would be beneficial to your site.
Yes, you CloudFront is designed as a caching layer in front of a web site.
If you want to restrict access to CloudFront, you can use the Web Application Firewall service.
Put your website into public network > In CloudFront distribution attach WAF rules > In WAF rules whitelist range of your company's IP's and blacklist everything else