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
Related
I'm using the API Gateway v2 and Cloud Front on my system, and serverless framework (with compose) to manage everything.
How to expose both services in the same domain (to avoid preflight requests and a few other internal requirements) where each is accessible with a custom path?
Example:
https://foo.bar/app -> points to the Cloud Front application
https://foo.bar/api -> points to the API Gateway
https://foo.bar -> redirects to the Cloud Front in /app initially but later it will have its own SPA landing page.
Anything I can do? The only way we were able to configure this was by creating an edge lambda to handle requests and decide whether the CF or the API would be used but this solution seems to waste resources unnecessarily...
Thanks.
You could use the behavior and origin feature of cloudfront.
Have multiple origins for example S3 bucket and another api gateway.
Then based on behavior you can route to specific origin.
Like Default(*) behavior will point to S3.
/api/* behavior will point to api gateway.
https://kuchbhilearning.blogspot.com/2022/10/add-cloudfront-behavior-and-origin.html code.
Much detail explanation
https://kuchbhilearning.blogspot.com/2022/10/api-gateway-and-cloud-front-in-same.html
I’m trying to pick up API gateway.
What are the different use cases for alb vs API gateway? I’ll be honest to say that I am not completely familiar with the concept of an API. I know we can invoke it backend, and the analogy that it’s a restaurant menu. However, beyond that, I am not clear what the difference is. Is it that applications using ALB has a user interface, but not API gateway? I tried reading through documentation on the features, but got even more lost. As such, I am hoping someone can share the use cases for both services so that I can visualise what it’s used for and the reason for the features. Thanks!
API GW is focused on API and has some additional options - e.g. API definition via swagger, execution of a lambda function, converting the call to an event bridge event, support of authenticators (iam, cognito), multiple deployment stages etc.
The load balancer listens on a port and that's about it.
Q: In what cases would you require these API GW features as opposed to just using an ALB?
A: One obvious benefit is a serverless or "low code". Let's say you want an API which processes asynchronous requests.
It is possible to create an API endpoint which queues all incoming requests to a SQS queue with just one AWS CLI command with no programming (provided the resources do exist):
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services.html
Each API endpoint can be served by a different AWS resource including EC2/ALB.
ALB is well suited for things like traditional monolithic applications (LAMP, Java application servers etc.)
I have a private S3 bucket with lots of small files. I'd like to expose the contents of the bucket (only read-only access) using AWS API Gateway as a proxy. Both S3 bucket and AWS API Gateway belong to the same AWS account and are in the same VPC and Availability Zone.
AWS API Gateway comes in two types: HTTP API, REST API. The configuration options of REST API are more advanced, additionally, REST API supports much more AWS services integrations than the HTTP API. In fact, the use case I described above is fully covered in one of the documentation tabs of REST API. However, REST API has one huge disadvantage - it's about 70% more expensive than the HTTP API, the price comes with more configuration options but as for now, I need only one - integration with the S3 service that's why I believe this type of service is not well suited for my use case. I started searching if HTTP API can be integrated with S3, and so far I haven't found any way to achieve it.
I tried creating/editing service-linked roles associated with the HTTP API Gateway instance, but those roles can't be edited (only read-only access). As for now, I don't have any idea where I should search next, or if my goal is even achievable using HTTP API.
I am a fan of AWSs HTTP APIs.
I work daily with an API that serves a very similar purpose. The way I have done it is by using AWS Lambda functions integrated with the APIs paths.
What works for me is this:
Define your API paths, and integrate them with AWS Lambda functions.
Have your integrated Lambda function return a signed URL for any objects you want to provide access to through API calls.
There are several different ways to pass the name of the object(s) you want to the Lambda function servicing the API call.
This is the short answer. I plan to give a longer answer at a later time. But this has worked for me.
I have a React app which calls API gateway, which in turn triggers my Lambda functions. Now for saving cost purpose due to the potentially let’s say, tens of millions of requests to the API gateway, I did some research and are looking at to potentially use ALB to invoke my Lambdas rather than API GW. My API GW is simply a Lambda-Proxy integration.
My question is with API GW I can add API keys and custom authorizers etc, but for ALB, how do I add a bit of authentication at the ALB layer, say only allow the invocation of my Lambda functions only from the client that I trust? Note my client is a static React app with no server behind it! I don’t need anything too fancy but just want to reject requests other than my trusted request origins. Inside Lambda to cover browser I will just add CORS to response header. But at ALB level, how do I achieve what I required?
Looking forward to getting some shed of lights here!
Thanks
Is it an option using AWS Cognito or CloudFront? We did that with an Enterprise application which uses OIDC (OAuth 2.0). It does implement just Authentication for now.
Give a look in these links:
https://aws.amazon.com/de/blogs/aws/built-in-authentication-in-alb/
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
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.