Enable API Gateway IPv6 on AWS? - amazon-web-services

I'm using Lambda and API Gateway for building the APIs. And, I read that AWS CloudFront has IPv6 support. I want to use custom domain and I created certificates with ACM as required by the API Gateway.
But, when I test if the AAAA records are found for the CloudFront URL using http://ready.chair6.net, the AAAA records are not found.
Many blog posts assume CloudFront distribution settings are accessible. But, when we create the CloudFront distribution with API Gateway, you can't change settings of the distribution - not from the console.
How do I enable IPv6 for API Gateway?

As a workaround, you can create your own CloudFront distribution, enable IPv6 there, and then point it to API Gateway -- which you will want to deploy using a Regional Endpoint (which avoids having API Gateway creating its own CloudFront distribution) instead of an Edge-Optimized Endpoint (which creates a "hidden" CloudFront distribution controlled by API Gateway).

Related

Restrict access to API Gateway to traffic coming from static website in S3

I have a static website hosted in a public S3 bucket with a little bit of javascript code in it. Basically what this bit of code does is sending a POST request to an API Gateway to retrieve some data from the backend. The URL of the API Gateway is hardcoded into the website.
I'm concerned about the security implications of this. In theory anyone could look into it, get the URL and run a DDoS attack or something leading to a lot of costs for me. Is there a way to restrict access of to the API Gateway to only the requests coming from the website in the Bucket? I know there are ways to restrict access to API Gateways with IAM or Cognito but that's not what I'm looking for.
Yes the issue is valid, but there is a solution, what I would suggest:
Create a CloudFront distribution
Create 2 origin, on for the S3 and one for the API Gateway
configure an additional header in the API Gateway origin (which will be send between the CloudFront distribution and the API Gateway (no external will be able to see it)
Set up a AWS WAF, and configure a RULE to reject all traffic which does not have the appropriate "header" that you have configured in the CloudFront Distribution API Gateway origin.
Associate WAF with the API Gateway
Something like this:

How can I use aws to secure a domain with https for a non aws origin?

I did a search in the aws docs and couldn't find anything that could help me to setup a cloudfront distribution for a non aws origin server to secure my domain with https. I'm using route 53 to manage my dns for the domain, I'd like to setup https for the domain but it is not hosted with aws. How can I use aws to create a secure domain with https?
Update: I've created the cloudfront distribution and set the alternative cnames to the domain (example.com and www.example.com). In Route 53 I updated the A record for the domain - example.com - to be an alias and pointed it to the cloudfront distribution, but when I try to access the site I get page not working error. The domain does now have he secure padlock, but I can't access the site. Here is the error that I get when I access the site:
The simplest way is to use a CloudFront distribution in front of your non AWS endpoint. This endpoint would be configured as a custom origin endpoint.
You would need to generate or upload a certificate to ACM to attach to the resource. This must be done before you can use the distribution on your own domain, if you don't have it when you create the distribution you will need to edit it later.
The AWS documentation includes documentation for Creating a Distribution. If you follow this and reference your endpoint as the custom origin you will be able to create the host.
You will need to ensure you configure the Origins Origin Protocol Policy option to be HTTP Only if your host does not have a HTTPS certificate.
Be aware that as the CloudFront distribution communicates with your endpoint over the internet, any traffic between CloudFront and your endpoint will still not be encrypted.

Route53 point to other url (e.g. API Gateway endpoint)

I have:
Route53 Hosted Zone with DNS example.com.
API Gateway wiht DNS z8n73n8d123.execute-api.eu-west-1.amazonaws.com.
Now if I want to point, lets say, api.example.com or example.com/api (does not matter) to an API Gateway there are at least few ways to do it:
Use an Alias A record in Route53. But before that i need to add BasePathMapping and DomainName attributes to an API Gateway, create a Certificate (which MUST be in us-east-1). Creating certificate in us-east-1 is a deal breaker for me so I can not use it.
Redirect using S3 bucket. But this looks like a shameful workaround introduced by AWS itself. Also additional charges would apply by triggering S3 every time a redirect should take place. So it is again a deal breaker for me.
Use CNAME record???
???
Are there any other viable solutions how to point some-sub-domain.example.com or example.com/whatever to an api gateway?
CloudFront's home region (where its control plane APIs are hosted) is us-east-1, and CloudFront provides the "edge-optimized" feature of API Gateway. This is why -- in "edge-optimized" configuration -- the cert goes in us-east-1, because that's where CloudFront is integrated with Amazon Certificate Manager (ACM).
But if you choose a "regional" API deployment then the certificate goes in ACM in the same region as the API Gateway deployment itself.
See Set Up a Custom Domain Name for a Regional REST API or WebSocket API in API Gateway in the Amazon API Gateway Developer Guide.

Disable http redirection to https

I'm developing little service using lambda functions which returns "Fact of the day" in your CLI using curl.
First, I developed business logic, deployed and created lambda using Serverless.
Second, I bought domain using aws route 53, Provisioned certificate and routed domain using `Custom Domain Name on API gateway.
At the moment if you would visit https://domain.io service works as intented but if you would try call curl domain.io it outputs:
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
My goal is to get service running without SSL (or redirect), by calling curl domain.io.
Is it possible to avoid redirection? Or can you create API custom domain name without certificate?
Currently I call curl -F domain.io it will follow redirect, but it's not solution I'm looking for.
Thank you!
Remove the custom domain configuration from API Gateway.
Wait a few minutes for API Gateway to release the custom domain in the AWS Edge Network (there isn't a way to determine when this is complete, but you'll get an error on one of the subsequent steps until it is. 20 minutes should be sufficient).
Create a CloudFront distribution, using the generic ...execute-api...amazonaws.com domain name assigned to your API stage.
For Origin Protocol Policy, select HTTPS Only.
Set the Origin Path to your stage prefix (e.g. /prod or /v1) -- whatever you set up as the stage prefix.
Set the Viewer Protocol Policy to HTTP and HTTPS.
Set the Minimum TTL and Default TTL to 0.
Set the Alternate Domain Name for the distribution to your custom domain.
If you want SSL to optionally work on your custom domain, associate an ACM certificate with the CloudFront distribution.
Change your DNS entry to point to the *.cloudfront.net hostname assigned to your distribution.
Wait for the CloudFront distribution state to change from In Progress to Deployed.
Test.
This seems like a lot of effort to enable HTTP against API Gateway, but it is necessary, because API Gateway was specifically designed not to support HTTP -- it only works with HTTPS, because that's a best-practice for APIs, generally.
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.
https://aws.amazon.com/api-gateway/faqs/
CloudFront is commonly known as a CDN, but it is in fact something of a Swiss Army knife of custom HTTP request manipulation, and this is a case of that.
Once you verify your behavior, you can optionally increase the Default TTL in CloudFront, which will cause it to cache responses for up to that value in seconds, reducing your costs by sending fewer actual requests to API Gateway and replaying cached responses to the callers.
This setup differs from what you have, now, because you are in control of the CloudFront distribution, instead of API Gateway... so you can customize it in ways that API Gateway doesn't allow when it is in control.

What is the difference between a Custom Domain Name at the API Gateway and a CloudFront Instance with a Custom Domain?

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.