If it is a test stage (in Api Gateway) I would like to be able to add the stage name explicitly to the url or remove from the api call. Both should hit the stage environment.
Setup a regional rest API Gateway
Configured GET method /test/v1/health (test is stage name)
Deployed API
I can access it using the URL https://.execute-api..amazonaws.com/test
I can make calls to https://api-id.execute-api.region.amazonaws.com/test/v1/health and it is all good
Setup a regional custom domain api.example.com
Added a Base Path Mappings /v1 to test environment. Basically I would like to call https://api.example.com/v1/health since I want to have multiple stages but I don't want to specify test environment in the url. This should be optional.
Created a Cloudfront distribution and setup the origin to be the regional custom domain such as d-api-id.execute-api.region.amazonaws.com (note the d since this is regional) and Origin Path blank.
Updated my external DNS CNAME to map api.example.com to the cloudfront address.
Try to call https://api.example.com/v1/health and I get an HTTP 403.
Not sure what is going wrong here. Any ideas how to fix this issue would be appreciated.
Related
I am working on creating a new request in AWS API Gateway. I am having issues with a 404 not found on the URL request.
The request (had to create fake one for the question):
GET https://hello.stackoverflow.com/services/misc/myroute/v1/swagger.json
I created a route in API Gateway ANY /services/misc/myroute/{proxy+}
I attached the route to a Load Balancer Listener integration
I set up the listener rule in the Load Balancer:
IF Path is /services/misc* Then Forward to Target
IF Requests otherwise not routed Then Forward to Default
Created logs for this system in the AWS API Gateway: Monitor -> Logging -> Set Log Destination
Set variables for the log format using the $context variables, Context Variables
Ex Log:
{ "requestId":"QWRHQKWFHWAFZ=",
"routeKey":"ANY /services/misc/myroute/{proxy+}",
"path":"/services/misc/myroute/v1/swagger.json",
"domain":"hello.stackoverflow.com",
"domain_prefix":"hello",
"httpMethod":"GET", "status":"404","protocol":"HTTP/1.1", "endpoint":-" }
One final check I have done to make sure its completing its "route" was see the requests in the monitoring and seeing the 4xx come from this ALB listener.
I can send the request via localhost and get a response with the json body
GET https://localhost:8080/v1/swagger.json --> Status 200 OK with body filled
In my quest to solve the issue, it has lead me to many older (2019) stack overflow questions that seem to be outdated with the AWS Console, same with the AWS documentation. See links below...
AWS API Gateway Method request path parameter not working
AWS API Gateway 404 page not found error when invoking endpoint url
AWS API Gateway Method request path parameter not working
With this being my first project in the AWS cloud space, I am not sure where else to turn. My guess would be the authentication headers from the API Gateway are being lost, but not sure where I can see this loss happening.
From my understanding of how the AWS Request Flow goes, I created this diagram:
I’m currently experimenting on Metaflow. I followed the documentation and was able to deploy an aws setup with the given cloud formation template.
My question is why is that I’m always getting a:
message: "Missing Authentication Token"
when I access METAFLOW_SERVICE_URL in the browser, even if I made sure that the APIBasicAuth was set to false during the creation of cloudformation?
Shouldn’t this setting make the metadata/metaflow service accessible without the authentication/api key?
How can I resolve this? Or is this expected? That is, I cannot really view the metadata/metaflow service url via browser?
Thanks in advance
This was resolved under this github issue.
You still need to set the x-api-key header if you are trying to access the service url via the browser. To get the api-key you can go to the aws console
Api Gateway -> Api Keys -> show api key
Alternatively you can use the metaflow client in the sagemaker notebook which should be automatically setup for you via the template.
Also worth mentioning that there are two sets of endpoints: The one provided by the api gateway (which you seem to be hitting) and the one provided by the service itself. The api gateway forwards the requests the the service endpoints but needs the x-api-key to be set in the header. You can probably try hitting the service endpoints directly since you disabled auth.
I'm trying to host a static site in S3 with ability to handle some dynamic content using Lambda/Api Gateway. Can't seem to be able to do that.
I want URLs to look like this:
example.com/index.html
example.com/images/*
example.com/css/*
example.com/api/* -> API Gateway
Also, when redirecting I'd like to keep the example.com as a root domain. I tried RoutingRules in S3, but redirects from the client. I need this to be transparent from the user, like proxying requests.
While Bob's answer is pretty neat for public websites and is simple but if you are looking for other alternates which can work for internal sites or don't want to use CDN, you can try following options.
Option 1 -
This is most common option people prefer. You just configure 2 different DNS hosts for static vs api.(Assuming you enable proper CORS for *.example.com)
example.com(S3) --> S3 static content
api.example.com(APIGateway) --> Lambda
Option 2 -
Example.com(APIGateway) --> /apigLambda -->Lambda
Example.com(APIGateway) --> /* --> S3 Bucket/S3 File.
API Gateway Configuration -
API Gateway S3 Backend Proxy -
Example API Urls -
https://xxx.execute-api.us-east-1.amazonaws.com/dev/apigLambda
https://xxx.execute-api.us-east-1.amazonaws.com/dev/myfilename.css
Reference -
https://docs.aws.amazon.com/apigateway/latest/developerguide/integrating-api-with-aws-services-s3.html
Note - In above reference Url, the bucket name is being accepted in Url Path but my example hides bucket name so users have no idea of S3 bucket name when they see API Gateway Url.
Option 3 -
As per your comment just use {proxy+} as resource for proxying S3 to support sub-folders calls but as you suggested, making just pass-through proxy doesn't give much options to transform HTTP response body which I believe still ok since you know your website content files.
You can configure this by putting a CloudFront distribution in front of both the API Gateway API and the S3 bucket for static content. This would also allow you to take advantage of CloudFront's edge caching.
I'm using API Gateway as a proxy to fan out requests to different services based on the requested url. For example, /api/${proxy+} is mapped to an EKS cluster with my REST api behind it. But everything that's not under /api is mapped to an S3 bucket with my static files. That's the /${proxy+} part as seen below. It's all working, except that when I request / it returns "Missing Authentication Token." Weird, because /${proxy} doesn't require API tokens or authentication of any kind.
My setup is shown below:
I have tried a variation where I added a method on "/" and return index.html specifically from that S3 bucket
I'm using the Serverless framework, and I want to be able to reference my API Gateway URL in my acceptance tests.
My test environment is regularly destroyed and then recreated, so hardcoding a URL into the tests is not possible.
I can see there are ways to reference API Gateway as an AWS environment variable, but this doesnt help me to locally get the URL for my tests.
I was hoping that the cloudformation output would be referenced in the .serverless package, and accessible via json, but this doesnt seem to be the case.
Any idea how I can reference the API Gateway URL in my acceptance test files?
NOTE: These tests need to be run on AWS, not using a local server to mimic API Gateway
The serverless-plugin-test-helper plugin can help here. It will generate a YAML file containing all of the outputs of your stack. This includes a couple of standard ones - the S3 bucket that was used (ServerlessDeploymentBucketName) and the base service endpoint (ServiceEndpoint).
If you are using Node and have your tests in the same directory as the stack being tested then there's also a module to read this file. Otherwise, it's just standard YAML and you can use whatever tools are convenient.
Consider adding an APIGateway custom domain for your API. You can then use a known DNS name for your acceptance tests.
You will need to add an ApiGateway base path mapping, apigateway domain name, and a route53 recordset to the resources section of your serverless.yml.