Traicing is currently not supported for API Gateway based on this documentation
However, when the trace is "started" by some component in front of that e.g. LB those traces/headers are not visible in the log either.
API GW is ESP v2. I found following startup options available
Is there a way how to pass those startup options to API gateway for example in terraform?
CORS and other configuration would be the same.
The only way I could think of was OpenAPI extension where I don't see such option.
Propagating trace context to stackdriver logs I consider as bare minimum for the purpose of supportability.
Thanks for the help
Related
I am newbie to AWS and looking to resolve the API Gateway issue. We had a frontend web application where if users perform any activity by clicking a Personal Details link then request will hit the AWS API Gateway "A" and trigger lambda-A. We created AWS code pipeline and deployed application using Cloud Formation Stack which creates new API Gateway-B and Lambda-B. After the deployment it was intended that when ever user hits the Personal Details it should hit API Gateway-B and triggering the Lambda-B instead it was hitting old AWS API Gateway "A" and triggering lambda-A. Any help will be highly appreciated.
Regards,
Raghu
You need to update the base path mapping of your backend domain to API Gateway B.
Or you have to edit the backend url in frontend code to new api gateway url
Custom domains with API Gateway
You need to change Lambda function in API Gateway. Please check this article which have screenshots.
https://aws.amazon.com/blogs/compute/using-api-gateway-stage-variables-to-manage-lambda-functions/
https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html
Also I want to recommend you to use Serverless for your project.
This was due to the User request from Website navigating to data power (third party vendor for security). In data power it was configured to old API Gateway, so we changed it to new API Gateway.
AWS comes with a service called Application Load Balancer and it could be a trigger to a lambda function. The way to call such a lambda function is by sending an HTTP/HTTPS request to ALB.
Now my question is how this is any different from using the API Gateway? And when should one use ALB over API Gateway (or the way around)?
One of the biggest reasons we use API gateway in front of our lambda functions instead of using an ALB is the native IAM (Identity and Access Management) integration that API GW has. We don't have to do any of the identity work ourselves, it's all delegated to IAM, and in addition to that, API GW has built-in request validation including validation of query string parameters and headers. In a nutshell, there are so many out of the box integrations what come with API GW, you wind up having to do a lot more work if you go the route of using an ALB.
It seems that the request/response limit is lower when using ALB, and WebSockets are not supported:
The maximum size of the request body that you can send to a Lambda
function is 1 MB. For related size limits, see HTTP Header Limits.
The maximum size of the response JSON that the Lambda function can
send is 1 MB.
WebSockets are not supported. Upgrade requests are rejected with an
HTTP 400 code.
See: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html
Payload limit with API Gateway is discussed here: Request payload limit with AWS API Gateway
Also the article already mentioned by #matesio provides information about additional things to consider when choosing between ALB and API Gateway.
Notable tweet referenced in the mentioned article:
If you are building an API and want to leverage AuthN/Z, request
validation, rate limiting, SDK generation, direct AWS service backend,
use #APIGateway. If you want to add Lambda to an existing web app
behind ALB you can now just add it to the needed route.
(From: Dougal Ballantyne, the Head of Product for Amazon API Gateway)
API gateways usually are richer in functionality than Load balancers. In addition to load balancing, API gateways often capable to do the following:
Content based based routing (some calls to v1 and some calls to v2 and so on, based on certain criteria)
IAM related functionality (eg: access validation )
Security (eg: SSL offloading, DDOS attack prevention, security credentials translation - eg: translating particular type of token to another, etc)
Payload translation (eg: XML to Json, etc)
Additionally, API gateways may be available in appliance form - and appliances are usually of low-latency, far more secure, etc.
I am not aware of specific features of AWS API gateway, but the above ones are general features of any API gateway. Nevertheless, when you have an option to use either LB or API gateway to offer a service on internet, API gateway is usually a better option, unless there are specific reasons to choose otherwise.
I have a custom gRPC backend deployed behind an Endpoints Service Proxy (ESP) connected to Google Cloud Endpoints.
When sending a request with the X-Cloud-Trace-Context header set, I can see the spans recorded by ESP show up in my Stackdriver Trace dashboard.
However, my service is also sending requests to Google Cloud KMS as part of handling that request. I'd like Google Cloud to create trace spans for those sub-requests automatically for me as well; however, attaching the X-Cloud-Trace-Context header that ESP forwarded to me to the sub-requests sent to Cloud KMS does not cause any spans for those sub-requests to show up in Stackdriver Trace. The service account used to connect to Cloud KMS does have the "Stackdriver Trace Agent" role enabled.
Is it possible to tell Google Cloud services (such as Cloud KMS) to automatically generate trace spans for the current request's trace context, or do I need to manually generate traces for these requests in my backend code?
Cloud Trace doesn't currently generate service-side traces for requests to most GCP services, although we're aware of it as a valuable feature. To track how much of your latency is being consumed by KMS (or other services) you can create a client-side trace record using OpenCensus (Github) or similar.
Cloud KMS (as of this writing) doesn't support gRPC, but we are working on it.
I would like to put an AWS WAF in front of a web site served by CloudFront. I will need to update this WAF via automated calls though its API.
Where is this API documented?
I quickly found the Making HTTPS Requests to AWS WAF or Shield Advanced page, which states that
Many AWS WAF and Shield Advanced API actions require you to include
JSON-formatted data in the body of the request.
This is followed by a random example of how to insert an IP match condition rule.
I cannot believe that this is the only "documentation" available (making the REST interface hardly usable).
Here is the api documentation for WAF http://docs.aws.amazon.com/waf/latest/APIReference/API_Operations_AWS_WAF.html
and this if you are using Python https://boto3.amazonaws.com/v1/documentation/api/latest/index.html
I am fairly new to AWS Lambda but sure can see the benefits of it and stumbled upon the superb framework Serverless to help me built solutions on Lambda.
I started out building solutions using AWS API Gateway but really need "internal" VPC API's and not public Internet facing API's like API GW creates.
I found that Servless indeed can expose a HTTP endpoint but I can't figure out how this is done and how the URL is created.
When I deploy the Lambda from Serverless it gives me the URL, e.g.:
https://uxezd6ry8z.execute-api.eu-west-1.amazonaws.com/dev/ping
I would like to be able to find (or create) this same http listener for already existing Lambdas so my question is how is the URL created and where is teh actual HTTP listener deployed?
You might be looking for the invoke url,
1. go to https://console.aws.amazon.com/apigateway
2. select api link (which you have deployed on aws lambda).
3. select stages in left side panel and
see the invoke url.
Adding a http listener can be done by going to your lambda function, selecting the 'triggers' tab and 'add trigger', finally selecting API Gateway - but as others mentioned this does create a public facing url.
Duh, I was in the wrong AWS logon previously so the API GW was not showing any matching Serverless API and that was why I couldn't understand how they did it...
Once I logged into the AWS account that hosts the Serverless structure I can see the API GW GET API's for the Serverless HTTP listener.