We currently want to start hosting all our assets through AWS S3 and we also want to server everything over https. I understand I can use the Amazon Certificate Manager (ACM) with Cloudfront to server assets over https. The problem is that we are in the medical industry and we are legally prohibited to host anything outside the EU. With S3 I can choose a location (Frankfurt for us), but with Cloudfront I just get this option:
So I thought that I could maybe use Letsencrypt to generate my own certs. But I think I then still need to use ACM which only works with Cloudfront, which means I still can't use it.
Does anybody know if I can somehow setup S3 with https but without cloudfront?
Unfortunately you can't use an SSL certificate with your custom domain with S3. You can use the S3 domain with the Amazon SSL certificate like: https://my-example-bucket.s3-website-us-east-1.amazonaws.com.
If you want to use a custom domain with SSL, and you can't use CloudFront, then you will need to look into placing some other proxy in front of S3 like your own Nginx server or something.
In AWS API Gateway, you can create a proxy resource /{proxy+} that maps to s3-website.
Be sure to map not to s3 alone, but s3-website, so you get PATH/TO/DIR/index.html returned for PATH/TO/DIR, and possibly other things working as desired.
API Gateway is served over HTTPS, optionally under your own domain.
This is not very good option though, because you have to manually add all allowed HTTP return codes, and there's a limit of 10MB payload in a request, as this service is aimed at REST APIs.
Below is a useful resource schedule. Both S3 and CloudFront are available in the EU. You can certainly present S3 via CloudFront.
I understand the requirements to host within a territorial boundary. The req'ts for that you will achieve with S3 in the EU region. CloudFront is not a hosting service it is a CDN (Content Delivery network) using high performance leased lines and manageable endpoint caching. The issue you are looking at is the price options, not the hosting location. If you want to serve content in the EU you would want 'Price Class 100' or 'Price Class All'.
When using CloudFront you can control both which IP ranges that can access your material, and the encryption of both front-end and back-end traffic. Check out some of the design patterns
There are some excellent white papers and design patterns for setting up secure CloudFront. I think you will find that you can do what you want and stay well within the legal requirements.
http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region
https://aws.amazon.com/compliance/eu-data-protection/
Also check out AWS doco 'using-https-cloudfront-to-s3-origin' & 'custom-ssl-domains'
P.S. Ensure that you set the bucket permissions to only be available via the CloudFront channel.
RL
CloudFront has a feature for white/blacklisting countries. I would try using any of the 3 CDN options you listed along with a whitelist of EU countries. I'm not sure what the easiest way to verify that other countries (e.g. US) are denied though.
Related
I'm moving my domain names from CloudFlare's DNS to AWS Route53 and in some cases I'm using CloudFlare's redirects for project that are dead so that their domains go to a page in another domain, so https://projectx.com goes to https://example.com/projectx-is-no-more.
I want to replicate this in AWS and what I found so far is this:
Set up an S3 bucket with the redirect to the desired URL, https://example.com/projectx-is-no-more
Set up CloudFront for the domain, projectx.com
Generate the TLS cert for projectx.com and add it to CloudFront so it can serve both https and http.
Set up Route53 to resolve the domain name to CloudFront.
I set it up, it's working, I'm even using CDK so I'm not doing it manually. But I'm wondering if there's a way of setting up these redirects that requires less moving pieces. It sounds like such a redirect would be a common enough problem that maybe Route53 or CloudFront would have a shortcut. Are there any?
Update: using only S3 doesn't work because S3 cannot serve https://projectx.com. S3 has no method by which it can respond to HTTPS request for arbitrary domains, there's no way of adding a TLS certificate (and keys) for another domain.
I checked for information and see only three possible solutions:
Set up CloudFront + S3 *
Set up Application Load Balancer
Set up API Gateway + Lambda (mock integration may be used instead of Lambda, that should reduce service cost)
Use GitHub pages with custom domain
※ S3 support only HTTP traffic so we need to add CloudFront for HTTPS:
Amazon S3 does not support HTTPS access to the website. If you want to use HTTPS, you can use Amazon CloudFront to serve a static website hosted on Amazon S3.
In my opinion the ②nd way is super easy to set up but running 24/7 ALB is little bit expensive. In other way Lambda and API Gateway price depending on requests count. CloudFront seems to be cheaper than ALB too.
So the better solution is depending on how many requests you have
The ④th solution is depends on GitHub platform (wider than AWS only scope), but it is absolutely free and support custom domain and Let's Encrypt certificates out of the box.
You just need to create repository with static index.html file that will do redirects
You can do it without including CloudFront.
What you need to do is create S3 bucket projectx.com. In Properties go to Static website hosting. Enable static website hosting and choose Redirect as a hosting type (add the redirection URL).
You will still need to set up Route53, but you will now add alias to this projectx.com bucket, instead of going to CloudFront
My S3(front-end codes), and EC2(back-end codes) are BOTH linked to 'example.com'
What I like to do here is to direct users to view the pages, stored in S3, unless they input 'example.com/api/'on their browser.
In other words, 'example.com/api/' for the server access, and the other routes for the react app access.
which service should I use in AWS? CloudFront, Route53, Load Balance. I am so confused. thank you.
TLDR; Create a single CloudFront distribution for your domain with separate cache behaviors for each of the paths you need to support. You can easily add additional applications, control caching, or write edge functions (using Lambda#Edge or CloudFront Functions) for any further customization you might need.
Details: CloudFront allows you to configure multiple origins (e.g. S3, EC2, API Gateway, ELB, custom URLs, and so forth) and then create cache behaviors (routes) that direct traffic to the appropriate origin.
In your case, you would create a cache behavior of /api/* to point to your EC2 origin, and the default cache behavior (think of this as your fallback route) would point to your S3 origin for all requests that do not begin with /api/
You can create a subdomain say api.example.com using Route53, here is a document for that https://aws.amazon.com/premiumsupport/knowledge-center/create-subdomain-route-53/
And for routing traffic for the newly created subdomain go through this document https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-routing-traffic-for-subdomains.html
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've got a static S3 website. When I log in, I can see that the endpoint is http://www.example.com.s3-website.eu-west-2.amazonaws.com, but I've seen answers claiming that the site should be accessible via HTTPS at https://www.example.com.s3-website.eu-west-2.amazonaws.com. This doesn't work though.
Did AWS used to support HTTPS for static sites and have now stopped it, or do I need to enable it somehow?
The website hosting section on S3 now has this note at the bottom of the page:
The Amazon S3 website endpoints do not support HTTPS. For information about using HTTPS with an Amazon S3 bucket, see How do I use CloudFront to serve HTTPS requests for my Amazon S3 bucket? and Requiring HTTPS for Communication Between CloudFront and Your Amazon S3 Origin.
Seems the only option now is to use CloudFront. Quite disappointing when you just want a quick and dirty HTTPS website and would happily use https://examplebucket.s3-website-us-west-2.amazonaws.com/ as the URL, which would work fine with a wildcard SSL certificate.
So the answer is no, it's not possible to use HTTPS for S3 static websites directly like I'm trying to do. From the docs:
Note the following about using HTTPS when the origin is an Amazon S3
bucket:
* If your Amazon S3 bucket is configured as a website endpoint, you can't
configure CloudFront to use HTTPS to communicate with your
origin because Amazon S3 doesn't support HTTPS connections in that
configuration.
You cannot use periods in the bucket name. If you do use periods, Amazon's wildcard certificate won't work.
Quoting the BucketRestrictions documentation:
When you use virtual hosted–style buckets with Secure Sockets Layer (SSL), the SSL wildcard certificate only matches buckets that don't contain periods. To work around this, use HTTP or write your own certificate verification logic. We recommend that you do not use periods (".") in bucket names when using virtual hosted–style buckets.
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