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.
Related
Recently I had a contracted company do some work and part of that was to create an API Gateway. When I create one I add a stage with usage plan so I can add an API key. They did not. So now when I attempt to hit it with Postman it is always reporting "forbidden".
Is a stage required for the API Gateway to be usable by Postman?
Found the answer in the docs at AWS here: Publishing REST APIs for customers to invoke
It states:
Simply creating and developing an API Gateway API doesn't automatically make it callable by your users. To make it callable, you must deploy your API to a stage.
So YES, a stage is required for the API Gateway to be usable by Postman.
I have a Django Project deployed in AWS EC2 and have created all the REST APIs with DRF. Everything is working great. When I point public.ip.of.ec2:8000/myapi, I get the correct response and these APIs are used in Android application.
Now, day by day the API hits will be increased. So in order to maintain API requests I want to integrate my APIs with APIGateway. After a lot of reading and searching I still could not find any definitive tutorial or steps as of how to integrate APIGateway with EC2.
I've followed this but still could not integrate APIGateway with AWS Service i.e., EC2.
Please suggest a way to do this.
I have a Django Project deployed in AWS EC2 and have created all the
REST APIs with DRF. Everything is working great. When I point
public.ip.of.ec2:8000/myapi, I get the correct response
Integration type you are looking for is HTTP integration
Now, day by day the API hits will be increased. So in order to
maintain API requests I want to integrate my APIs with APIGateway
Although you can configure API caching, throttling, logging and monitoring, AWS API Gateway won't scale your backend integration. You will need to configure autoscaling on backend service as well.
I have a task to replace current CA layer 7 with new API gateway.
New API gateway should be able to handle
1. Rate limiting
2. Authentication
3. Version handling etc.,
After researching i found we could use AWS api gateway or Kong api gateway or AWS ALB with Cognito for authentication support.
This is so overwhelming to understand the basic differences, could you please give some insight on basic concept in simple words and some pointers or link that i should refer to start with.
API Gateway keep track of every deploy you make in the Deployment History tab. There you will find all versions of your API and you can change to any of them whenever you want.
You can also create your api gateway from a Swagger file.
For every method that you create for a resource you need to configure the Method Request, the Integration Request, the Integration Response and the Method Response.
The Integration Request is where everything happens. You will set there how you are going to handle your requests, if you are going to integrate with any aws service like firehose or if you are going for a lambda integration or with an existing HTTP endpoint.
Mapping Templates uses Apache Velocity Template Language (VTL). http://velocity.apache.org/engine/1.7/vtl-reference.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html
Getting started with REST apis:
https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started.html
API GATEWAY INTEGRATION TYPES:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-integration-types.html
How to import a rest api:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html
Limits and known issues:
https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html
Deploying:
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-deploy-api.html
Publish:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-publish-your-apis.html
AWS API Gateways supports lambda authoriser for authentication which is integrated with any identity provider - Azure AD, Cognito pool etc. It supports both Client Credentials (service to service) authentication and Authentication code(user based authentication) but AWS ALB don't support client credentials authentication flow.
AWS API Gateway also provides caching, request & response mapping, customise handling for each response type, request validation, throttling where AWS ALB is yet to be improved for all these feature.
Kong api gateway also provide similar feature as AWS API Gateway with added features
If all the backend services are deployed in AWS and you don't need
complex API gateway then go for AWS API Gateway. It is pay per use service and you don't need to pay for extra support for API gateway assuming your services are already deployed in AWS.
If you need api gateway solution with complex requirement and extra features then Kong API gateway can be considered. But you will need to either pay for Kong API gateway support or need extra effort in coding when used open source.
AWS ALB can be used only for specific scenarios and it is getting matured day by day.
As my project is going to be deployed on AWS, we started thinking about AWS API Gateway as a way to have one main entry point for all of our microservices(frankly speaking, we also would like to use by some other reasons like security). I was playing with API Gateway REST API and I had feeling that it it a bit incovinient if we have to register there every REST service we have.
I found very good option of using AWS API Gateway and lambda function as a proxy. It is described here:
https://medium.com/wolox-driving-innovation/https-medium-com-wolox-driving-innovation-building-microservices-api-aws-e9a455cc3456
https://aws.amazon.com/blogs/compute/using-api-gateway-with-vpc-endpoints-via-aws-lambda
I would like to know your opinion about this approach. May be you could also share some other approaches that can simplify API Gateway configuration for REST API?
There are few considerations when you proxy your existing services through API Gateway.
If your backend is not publicly then you need to setup a VPC and a site to site VPN connection from the VPC to your backend Network and use Lambda's to proxy your services.
If you need do any data transformations or aggregations, you need to use Lambda's(Inside VPC is optional unless VPN connection is needed).
If you have complex integrations behind the API gateway for your services, you can look into having ESB or Messaging Middleware running in your on-premise or AWS then proxy to API Gateway.
You can move data model schema validations to API Gateway.
You can move service authentication to API Gateway by writing a Custom Authorizer Lambda.
If you happen to move your User pool and identity service to AWS, you can migrate to AWS Cognito Manage Service and use AWS Cognito Authorizer in API Gateway to authenticate.
For usecases when you adopt dumb pipes (as described on martinfowler.com) AWS API Gateway is a reasonable option.
For AWS API Gateway I'd suggest to describe/design your API first with RAML or OpenAPI/Swagger and then import into AWS using AWS API Importer.
As soon as you plan to move logic in there, such as dynamic routing, detailed monitoring, alerting, etc, I'd suggest considering other approaches, such as:
Apigee
Mulesoft
WSO2
You can also host them on an EC2 within your VPC or opt-in for the hosted version. (which does have a significant pricetag in some cases)
For describing APIs you can use RAML (for Mulesoft) or OpenAPI (ex-Swagger, for Apigee and WSO2). You can also convert between them using APIMATIC which enables you to migrate your specification across various API Gateways (even AWS).
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.