I have a cloudfront web distribution setup for an API Gateway proxy. The API is IAM enabled mock call. I also created a customer name which has the same domain name as the cname I used to create cloudfront distribution. I set cloudfront up to pass Authorization and Host only for headers. And set Query String forwarding and Forward Cookie to None.
When I hit the cloud front using Postman, I kept on getting Miss from cloudfront from the response. I also disabled Postman's send no-cache header and I also tried manually adding a Cache-Control: max-age=3600.
But None of these works.
Anyone knows why?
I just solved a similar issue by noticing that the API Gateway domain name for my RestAPI was always returning an X-Cache header with "Miss from cloudfront"; but after realizing I had used the execute api domain, my second request to my *.cloudfront.net domain resulted in a Cloudfront cache hit.
Related
I have the following AWS architecture:
Dns Name -> Cloud front
Cloud front -> API gateway
API gateway -> Lambda function
Problem can not identify Dns Name inside Lambda function
The only thing that I can get from request headers is dns name of API gateway
Are there any Cloud front configuration that allows to pass user entered dns name through all the layers till backend code?
in headers I receive host field but it contains dns of api gateway and not cloud front or public dns name
"Host": [
"9b8vc8vvhl.execute-api.us-east-1.amazonaws.com"
],
Here's what is passed in browser
UPDATE:
Implementation attempt from comment
gives
503 ERROR
The request could not be satisfied.
The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: n03zM0u93vrvdcwQi-hgyhONbv3b10x3ETq-A4Ru7-fC-RUlskjJxQ==
The reason why you get 9b8vc8vvhl.execute-api.us-east-1.amazonaws.com as Host in your lambda function is because, by default, CloudFront rewrites the Host in the origin request.
From HTTP request headers and CloudFront behavior documentation:
Header
Behavior if you don't configure CloudFront to cache based on header values
Host
CloudFront sets the value to the domain name of the origin that is associated with the requested object.
Host in the request header that your browser sends to CloudFront: yuriy-test-cars2.pp.ca (CloudFront uses this value to route your request to the distribution owned by you)
Host in the request header of the origin request that CloudFront sends to API Gateway: 9b8vc8vvhl.execute-api.us-east-1.amazonaws.com (This is the origin domain that you configured in your distribution. CloudFront sets it as the value of the Host header in the origin request. This is consistent with what the documentation says.)
Issue
You can't simply passthrough the Host header to the origin in CloudFront since the API Gateway service uses this value to route your request to the API that you created.
Solution
Create a CloudFront Function to make a copy of the Host header.
function handler(event) {
var request = event.request;
request.headers['cf-host'] = request.headers.host;
return request;
}
Here, I save the value to a custom header named Cf-Host.
Associate this function to the viewer request event.
Create an Origin request policy and include the Cf-Host header in the policy. This makes sure that the Cf-Host header is included in the origin request.
You will be able to access the Cf-Host header in your lambda function. The value of the Cf-Host header is the alternative dns name that you are looking for.
Don't know if my solutions is suitable for you, but I have a similar architecture, except the step Cloud Front > API Gateway.
My DNS is a direct CNAME to API Gateway DNS which result in the original header once the request is logged:
My APIGateway also has a "Custom domain name" ties to it, this way AWS create the proper ssl certificate for the my public domain.
Also the API Gateway endpoint could be edge-optimized (https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) to be server phisiclaly near the user.
If you don't need any caching feature, maybe you could give a try.
I have a REST API serving behind API Gateway.
I have a Route53-hosted zone: myAWSHostedDomain.myCompanyDomain.com
I have also created a certificate in ACM: myApp.myAWSHostedDomain.myCompanyDomain.com
The certificate has an additional domain:
myApp.myCompanyDomain.com
The cert has been issued without any problem, both domains were validated.
In the company non-AWS-hosted zone myCompanyDomain.com, I have a CNAME pointing myApp to myApp.myAWSHostedDomain.myCompanyDomain.com. It resolves OK.
I have configured a Custom Domain for that API Gateway using that certificate. The name that shows is myApp.myAWSHostedDomain.myCompanyDomain.com. Which is fine because it's the main domain for that cert.
The problem I have is that all the requests made to myApp.myCompanyDomain.com fail with a 403 Forbidden error, while those same requests on the myApp.myAWSHostedDomain.myCompanyDomain.com work just fine. The app code has nothing to do with it, a request for a favicon.ico behaves the same way.
The API Gateway endpoint is configured as a Regional one.
Could it be that API Gateway's custom domain only takes the main domain from the certificate and doesn't work with the additional ones? Is there a way to fix this?
So, the problem is that the request fails with a 403 forbidden error, because API Gateway is unable to set the correct Host header, which is required for the request to succeed.
If I do:
curl https://myApp.myCompanyDomain.com/favicon.ico -H "Host:myApp.myAWSHostedDomain.myCompanyDomain.com"
Then, it works.
Hence, the options here are the following:
Create a DNS record in Route53 for myApp.myCompanyDomain.com.
While calling the API, add a Host header to the request, with the value set as the value for the DNS record.
Create a new API Gateway where the main custom domain corresponds with the one in the API Gateway: myApp.myCompanyDomain.com work instead of myApp.myAWSHostedDomain.myCompanyDomain.com work.
I just want to serve my s3 files on cdn.mydomain.com
So I create cloudfront distribution which is working fine on https://dxxxxxxxx.cloudfront.net/test.jpg - I get the image.
And now I want to associate my domain at cdn.domain.com with cloudfront in route53.
So I create A record type A-IPv4 address. with name cdn.domain.com alias target I manully put dxxxxxxxx.cloudfront.net.
But when I open the url:
http://cdn.mydomain.com/test.jpg
I get the error:
403 ERROR
The request could not be satisfied.
Bad request. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
What did I miss with my configuration?
I meet this issue some time before. The request blocked by CloudFront.
Please check this list:
CDN domain added in Cloudfront Alternate Domain Names. Once you add CDN domain to Cloudfront, you can select CloudFront endpoint without typing
WAF (if any) does not block your request
Check Http and Https
I'm using AWS API Gateway with a custom domain. When I try to access https://www.mydomain.com it works perfectly, but when i try http://www.mydomain.com it can't connect.
Is there a way to redirect the http -> https with the custom domain in API Gateway? If not, is there a way to get the http:// links to work just like the https:// links?
API Gateway doesn't directly support http without TLS, presumably as a security feature, as well as for some practical considerations.
There is not a particularly good way to do this for APIs in general, because redirection of a POST request from HTTP to HTTPS is actually a little bit pointless -- the data is has already been sent insecurely by the time the redirect is generated, unless the client has asked the server to inspect the request headers before the body is sent, with Expect: 100-continue.
You can create a CloudFront distribution, and configure it to redirect GET and HEAD requests from HTTP to HTTPS... but if you send a POST request to such a distribution, CloudFront doesn't redirect -- it just throws an error, since (as noted) such a redirection would be more harmful than helpful.
However... if GET is your application, then it's pretty straightforward: first, deploy your API with a Regional (not Edge-Optimized) API endpoint with a system-assigned hostname, not a custom domain.
Then, create a CloudFront distribution that uses this regional API endpoint as its origin server, and configure the CloudFront distribution's behavior to redirect HTTP to HTTPS. Associate your custom domain name with the CloudFront distribution, rather than with API Gateway directly.
I'm working on a project with serverless architecture.
I've found that though AWS said API Gateway can protect your resources from DDoS attack.
But if there is a bad user which keep sending spam to your service,
API gateway can't provide an appropriate way to handle this kind of issues.
So I start to figure out what I can do:
AWS WAF is an obviously solution.
I've found this post on stackoverflow: API gateway with aws waf
Then in order to setup WAF,
I put a Cloud Front distribution in front of the API Gateway.
I realized this might be a workaround solution, but is it?
Here's the issue I found:
I have a cloud front distribution, its domain name is cdn.net
I set the origin path to my api gateway: https://sampleagigw.amazon.com, and set path to its stage dev.
When I call GET http://cdn.net/posts, it will return a result which I expect.
Then if you put the http://cdn.net/posts on browser, it surprised you more than your expect, it also expose the API gateway's url on the url bar of browser: https://sampleagigw.amazon.com/dev/posts
It means all of the work with WAF and Cloud front is meaningless.
Is there anything I misunderstood?
Check the "Viewer Protocol Policy" on your additional CloudFront distribution (cdn.net) and ensure that it is set to either "Redirect HTTP to HTTPS" or "HTTPS Only". Alterntively, you can edit your origin and set "Origin Protocol Policy" to "HTTPS Only".
If you have "Viewer Protocol Policy" set to "HTTP and HTTPS" and "Origin Protocol Policy" set to "Match Viewer", then I can see how you would get this result. You enter http://cdn.net/posts on browser, then the cdn.net distribution attempts to connect to http://sampleagigw.amazon.com (no https/tls/ssl). This goes to the CloudFront distribution created by API Gateway which is set to "Redirect HTTP to HTTPS". Since it got an HTTP request, it returns a 302 redirect to http://sampleagigw.amazon.com. This is returned by the cdn.net distribution to the browser. The browser then follows the 302 redirect, leaving the http://sampleagigw.amazon.com URL in the browser's URL bar.