I'm curious whether is possible to load a web page via AWS lambda functions.
I mean, I would like to open a webpage like www.something.com/home which makes a request to the AWS lambda function which will open/get resources from www.i-would-like-to-hide-this-url.com/home, but the URL should remain www.something.com/home.
So can I use AWS as a proxy for the case above?
Yes you can do it with CloudFront using custom Origin. It will work as a reverse proxy for your customers.
A custom origin is an HTTP server, for example, a web server. The HTTP server can be an Amazon Elastic Compute Cloud (Amazon EC2) instance or an HTTP server that you manage privately. An Amazon S3 origin configured as a website endpoint is also considered a custom origin.
When you use a custom origin that is your own HTTP server, you specify the DNS name of the server, along with the HTTP and HTTPS ports and the protocol that you want CloudFront to use when fetching objects from your origin.
Using Amazon EC2 or Other Custom Origins
Or you can do it with ELB and a reverse proxy on EC2. But in this case you will be responsible for this reverse proxy.
Maybe it is even possible to do it with lambda if you code the "reverse proxy" solution, but I guess it is not exaclty recommended.
Typically you host the static assets (html/js/css/img) in S3, you front Lambda with API Gateway, and your web page makes HTTP/Rest requests to API Gateway which forwards them to your Lambda. Lambda itself does not typically serve the static assets. If you need SSL then you add CloudFront. Example here.
Related
I have a ec2 server and it's using CloudFront because it needs to use https with cerificate signed by AWS. And then there is some API inside this ec2 server that i need to use post method with form-data. but the server somehow can't get the form-data. Is there some cache policy that i have to set? or CloudFront is purposedly forcing me to do everything with the API gateway thing?
Your setup that uses Cloudfront to terminate TLS and forward HTTP requests to EC2 is fine.
You can try turning on forwarding all Query strings and see if it works for you
I've been wasting about 12 hours going in circles in what seems like this:
I am trying to just make a simple static landing page in lambda and hook the root of a domain to it.
The landing page works, but api gateway didn't because AWS doesn't seem to set permissions properly by default ("internal server error" with API gateway and lambda on AWS) but now the gateway link works.
So the next steps were the following:
add a custom domain name in the api gateway
add the api mapping in the custom domain name
in route 53, create a wildcard certificate with *.domain.com and domain.com
create an A record that points to the api gateway with domain.com
create a CNAME record that points to the A record
and I get an error 403 with absolutely nothing in the log. I log both 'default' and '$default' stages in the api gateway.
I read https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-403-error-lambda-authorizer/ which is all about looking at what's in the logs...
and I find the doc is both everywhere and nowhere because it's built as chunks of 'do this' and 'do that' without ever painting a whole picture of how each piece is connected to the other, or any graph with the hierarchy of services, etc. Reminds me of code that works only when you follow the example documented and breaks otherwise.
I'm sure I'm doing something wrong, but given the lack of logs and lack of cohesive documentation, I have no idea about the problem.
Not to mention that http doesn't even connect, just https.
Can anyone outline the steps needed to achieve this? essentially: [http|https]://(www).domain.com -> one lambda function
You cannot use API Gateway for an HTTP request; it only supports HTTPS.
From the Amazon API Gateway FAQs (emphasis mine):
Q: Can I create HTTPS endpoints?
Yes, all of the APIs created with Amazon API Gateway expose HTTPS endpoints only. Amazon API Gateway does not support unencrypted (HTTP) endpoints. By default, Amazon API Gateway assigns an internal domain to the API that automatically uses the Amazon API Gateway certificate. When configuring your APIs to run under a custom domain name, you can provide your own certificate for the domain.
You can use CloudFront to automatically redirect HTTP to HTTPS. How do I set up API Gateway with my own CloudFront distribution? provides a pretty simple walkthrough of connecting an API Gateway to CloudFront (you can skip the API Gateway portion and use the one you created). The important thing you'll need to do that is not in that document is to select Redirect HTTP to HTTPS.
If you truly need HTTP traffic you're probably going to need to go with an ALB.
In our project we have been hosting a NuxtJS site on Amazon's ECS using docker repositories. We are now looking into using CloudFront mainly because we want to distribute content worldwide and also use it's compression mechanism.
Has anyone worked with a similar scenario before? Is is possible to host dynamic content on an ECS container and serve it through CloudFront?
I have worked on a similar scenario; running Nuxt in a lambda behind CloudFront. For that scenario you need to connect your nuxt lambda with API Gateway, then add the API Gateway as an Origin in CloudFront. If you want all requests on domain.com/app to hit Nuxt, you then set a CloudFront behaviour to forward all requests to /app/* to the API Gateway Origin you just added.
So unsure whether you need to front your EC2 with API Gateway, or if you can directly add EC2 as a CloudFront Origin, but look for info on using EC2 as a cloudfront origin and you should be fine.
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'm currently extensively using the API Gateway as a source for CloudFront. My CloudFront serves other things as well, such as plain files from S3.
I've recently been looking into improving the current setup, and noticed the "Custom Domain Names" option in API Gateway.
From what I've understood, using it creates an unconfigurable CloudFront instance. I've not been able to find much information beyond that.
Are there any advantages to using API Gateway's Custom Domain Names over using a self-managed CloudFront instance?
When you use AWS CloudFront you can configure different Origins such as S3, API Gateway & etc to the distribution which allows to serve different services through same domain. e.g you can serve mydomain.com points to index.html in S3 and mydomain.com/api/* points to API Gateway. This allows for the frontend JavaScripts to access the API without the need for Cross Origin Request support at API Gateway which avoids sending Options preflight(If you have headers like Cookie, Authorization & etc.) request by the browser.
On the other hand you can configure Custom Domain Names to API Gateway. This allows to define a Custom Domain as well as a Custom SSL Certificate using AWS Certificate Manager. The main difference is, if you have a frontend application, you need to define two domains(or different subdomains) for the frontend served from S3 and API. When accessing the API from different domain it will require to have CORS configured at the API Gateway and can affect performance based on the latency.