I've created couple of AWS Lambda functions which are invoked via API Gateway Proxy request. Note that I am using Serverless framework for deployment. Also, I am using AWS SAM for testing lambda functions locally.
Once I've deployed my lambda function, its API endpoint looks something like this: https://38sp8vme5j.execute-api.us-east-1.amazonaws.com/{STAGE}/{PATH}
I would like to know if there is a way to change 38sp8vme5j.execute-api this part of my API endpoint.
Thanks in advance
In the API Gateway area, you have a option in the left menu called Custom Domain Names where you can set a specific domain you already have and set an alias to the specific Lambda function you want to run.
The Route 53 service is not necessary, you only need to register the domain in the certificates area ACM to have it available in this custom domain names option in API Gateway
You may not be able to change the portion 38sp8vme5j.execute-api of your full domain name but you can surely add a new Alias DNS records in Route53 to use a different domain that you own.
There is an alternative and easier way to give custom domain names in the API gateway itself using the "Custom Domain Names" option as shown here.
Just fill in the details and provide an ACM certificate for HTTPs.
Related
I would like to specify a dynamic subdomain in an Integration Request in API Gateway, but the UI is telling me that the URL is malformed. I can add this parameter to the path of the URL with no problems (although I still get the warning "the endpoint you have entered contains parameters that are not defined in the resource path"). Is this mapping to subdomain possible using API Gateway, or do I need a lambda to accomplish this? Thanks
I couldn't get this to work, so I assume it's not supported. I ended up making a different Gateway for each subdomain (I only have a few) and using a lambda to switch between them. You could also use a lambda without a a Gateway if you have many different subdomains.
I want to add a custom domain to the API Gateway using serverless framework but without "serverless-domain-manager" or any other plugin. I am looking for a more native way, maybe extending a resource in "serverless.yml"
All articles suggest that plugin, but it isn't the best for multi environment pipelines
https://www.serverless.com/blog/serverless-api-gateway-domain/
Doing it manually is not that complicated, here is the full explanation
Add a custom domain to all envs
Issue a certificate for the domain in the same region of serverless project, in my case us-east-2
Go to API Gateway > Custom domain names > Create, use Regional endpoint type if using HTTP APIs
In the created domain there is API Gateway domain name, you'll need to point a CNAME record to it
Finally go to API mappings and create the mappings, in my case main and prod with stage $default
API Gateway with a custom domain is configured to use TLS 1.2, and it supports some weak cipher. These weak ciphers are removed in TLS 1.3 which is only supported in CloudFront distributions at the moment.
Some security tools like AppScan raised these issues for me during the security testing of these APIs.
You can check the details here.
https://security.stackexchange.com/questions/254667/are-weak-cipher-suites-for-tls1-2-a-valid-concern
If security is concerned, I would suggest using a cloud front distribution in front of the API gateway.
https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cloudfront-distribution/
I have a custom domain set up in AWS API Gateway. My intention is to use "API mappings" to send traffic for different API versions to their respective API Gateways, e.g.:
GET https://example.com/v1/foo is sent to an API gateway "APIv1" ($default stage) via an API mapping on the custom domain with path="v1".
GET https://example.com/v2/foo is sent to an API gateway "APIv2" ($default stage) via an API mapping on the custom domain with path="v2" (not shown)
The HTTP APIs themselves are configured with a single route /{proxy+} and an integration that sends requests to a private ALB:
This setup works fine as far as routing traffic goes, but the problem is that when the request makes it to the actual application, the routes the application receives are like /v1/foo instead of just /foo, which is what the app is expecting.
I've played around with different route matching and parameter mapping (of which I can find almost no examples for my use case) to no avail.
I could change my app code to match the routes that AWS is sending, but the entire point of this was to handle versioning using my AWS stack and not app code. Do I have another option?
If you create a resource called /foo and the proxy resource inside it, when you set integration you can define which path to pass and the {proxy} will have just the part after /foo, ignoring the v1 entirely.
See an example below.
In this case it is ignoring everything before v1 and it is also rewriting the integration to /api/{proxy}.
It will receive a request as GET https://example.com/abc/xyz/v1/foo and will forward to backend as GET https://example.com/api/foo.
Update
It can't be done via VPC Link, but we can use public ALB almost like private, like the explanation below.
It explain about CloudFront, but the same is valid for API Gateway.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
It's totally possible. You just need to use parameters mapping for this. Using the AWS UI it would be:
I am creating a multi tenant silo mode architecture to support a SAAS application. Following this link.
I am able to register new tenants and create their respective stack like this:
So far so good, the next step is to create each tenant its own domain, for example: tenant1.admin.foo.com, to access the same CloudFront distribution (the web front end must be the same for all). I can make this by creating a record in Route53 *.admin.foo.com that has access to CloudFront
THE PROBLEM:
I need to route every request to their respective tenant stack, for example: tenant1.api.foo.com/whatever should route to the api gateway created for tenant1.
At first I thought of creating an origin in CloudFront that routes to the api gateway, the problem with this is that CloudFront origins are limited to 25.
I was thinking in creating a record in Route53 to point to their respective api gateway, but the problem is that I will have to use custom domain in the api gateway, because they are limited to 120, and I expect to have more tenants than 120.
How can I make this routing?
Here is an illustration of a use case:
PS: Any advice is welcome.
You can setup a distribution with a wildcard (*.api.foo.com) set for the Alternate Domain Name (CNAMEs). If you attach a Lambda#Edge to the Origin Request (Under Cache Behavior settings), you can dynamically modify the host header to point to the appropriate API Gateway host (xxxxxx.execute-api.us-east-1.amazonaws.com).
AWS Blog where they did this, with S3 buckets for the origin.
It should translate fairly closely to APIGateway hostnames instead:
https://aws.amazon.com/blogs/networking-and-content-delivery/dynamically-route-viewer-requests-to-any-origin-using-lambdaedge/
I am integrating a web-relay into AWS-service which makes call-outs to a predefined path (
/some-fixed-path and it can not be configured) and I want to intercept it using a lambda on dedicated sub-domain, to keep this separated from the rest of our service, so I want the call-out to be http://subdomain.example.com/some-fixed-path.
I have a domain (lets call it example.com) registered and I have a hosted-zone defined. How can i create a record-set in the hosted-zone and use it in the API-gateway definition? (The url must not contain the stage...)
In the API-gateway definition, there is a "Custom domain name" option, but I can't figure out how to point to a record from my hosted-zone.
You should simply be able to follow the instructions for using a custom domain and then adding an alias record in your hosted zone to the CloudFront distribution provided by the API Gateway console.
You'll want to configure your custom domain with the base path pointing to your deployed stage. At that point you can than create your resource at some-fixed-path.
Note: API Gateway currently requires all APIs to be HTTPS, so if your call out can't be changed to support HTTPS, API Gateway will not work for this use case.
AWS has a detailed guide about how to do that exactly.
A few more things to pay attention to are:
Make sure you remember to re-deploy when you make any change to the API.
When you set up Base Path Mapping, make sure double check the API resource path and method. (For example, if you create the API gateway through lambda template, the API resource will be created under /{API name} instead of /).
A lot of people see Missing Authentication Token when they use API gateway for the first time due to those reasons.