I'm using SAM with AutoPublishAlias safe lambda deployments. However, in the Pretraffic hook, I'd like to run some initial validation tests by invoking the latest [unvalidated] lambda version through an AWS API Gateway endpoint that's different from the endpoint that points to stable lambda version.
In my case, it's quite challenging to call the lambda function directly by by-passing APIGateway in the pre-traffic hook because the lambda function includes whitelisting and other logic that requires values set by API Gateway proxy integration. Ideally, I'd like to have 2 API gateway endpoints that always point to the live & latest versions of the lambda function as follows:
/api/resource -> lambdaFunction:live
/api/latest_resource -> lambdaFunction:$LATEST
This way, the pre-traffic hook can always use /api/latest_resource while customers use /api/resource. So far, I've not been able to figure out a way to configure this in SAM AWS::Serverless::Function or AWS::Severless::Api. Does anyone have an example or idea of how to do this?
Related
My company has been using AWS Lambda for many years to run our Spring Boot REST API. We are migrating to GCP and they want me to deploy our code to GCF the same way we were with AWS Lambda, but I am not sure that GCF works that way.
According to Google Cloud Functions are only good for Single Endpoints and can only work as a web server using the functions framework.
Spring has a document that uses the GcfJarLauncher, but that is still in alpha and I can only get it to work for a single endpoint. Any additional functions I put into the code are ignored and every endpoint triggers the same function.
There were some posts here on SO that talked about using Functional Beans to map to multiple functions, but I couldn't fully get it working and my boss isn't interested in that.
I've also read of people putting the endpoint in the request payload and then mapping to the proper function, but we are not interested in doing that either.
TLDR/Conclusion:
Is it even possible to deploy our app to GCF or do we need to use Cloud Run (as Google suggests in my first link)?
I've implemented two lambda's (let's call A and B) behind api gateway. Assume A is called from "outside" and B is being called from outside and also from A.
I've also implemented lambda Authorizer (token-based; cognito) as auth layer. Everything is working as expected.
Is there a way to bypass authorizer process for B, for calls coming from A only?
Tnx
There are multiple possibilities I have explored myself in the past for the exact same issue.
Change the calls to lambda:Invoke
Assuming you're generating some client code for your micro-services, you can create two versions of these clients:
external to call your service via HTTP API
internal to use lambda:Invoke operation straight to your micro-service.
Create a mirrored VPC-private API
This is probably feasible if you're deploying your infrastructure using CDK (or a similar alternative). Essentially, you keep your existing API where it is, and you create another internal version of it that does not have the authorizer. (Note that you may still want some sort of authorization process happening depending on the nature of your project.)
From this point on, you can pass the endpoint of your internal HTTP API to the Lambdas as environment variables and have them call that.
You can find more info about this, here. As a perk you should probably get lower latencies when talking to API Gateway as traffic through the VPC endpoints will only flow through AWS network, instead of going out on the internet and back in.
Move your workloads to ECS
This is perhaps a major change to your project, but one worth mentioning.
You can create true micro-services using ECS. You can run these services in private subnets of your VPC. In order not to have to deal with IP addresses yourself, you can explore multiple options:
have a VPC-internal Route53 Hosted Zone (more on this here). See more on ECS Service Discovery here
create Network Load Balancers in the private subnets of your VPCs and pass their endpoints to your services.
I understand you can use the AWS API Gateway to allow developers to create applications that interact with AWS backend services (e.g. DynamoDB).
The basic flow is:
Create the resource (e.g. DynamoDB table)
Create a Lambda function
Create an HTTP API
Create Routes
Create an integration
Attach integration to routes
But what are the options for the API? What kind of operations can be done on DynamoDB (or whatever resource you’re working with)?
Usually when a REST API is available through a Gateway there is a set of endpoints, so the developers know what they can build with the API. Like Swagger Documentation.
It would be great to know all the things that can be done via API to DynamoDB, S3, Cloudwatch, etc. is there a master list somewhere?
Or is the idea that you can do anything inside the Lambda function that is supported by the aws-sdk?
In that case, is there a list of available options for the aws-sdk?
Am I thinking about this the right way?
Recently I use Serverless framework do create/deploy AWS lambda function / API gateway. It's a very cool way to deploy Lambda/API but I don't know how to apply it to existing AWS lambdas / APIs.
Is there any way to do it without drop the existing one then re-creating using serverless because i have dozens of existing lambda functions and apis.
https://www.serverless.com/framework/docs/providers/aws/events/apigateway/#share-api-gateway-and-api-resources
As your application grows, you will likely need to break it out into multiple, smaller services. By default, each Serverless project generates a new API Gateway. However, you can share the same API Gateway between multiple projects by referencing its REST API ID and Root Resource ID in serverless.yml as follows:
service: service-name
provider:
name: aws
apiGateway:
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
restApiRootResourceId: xxxxxxxxxx # Root resource, represent as / path
websocketApiId: xxxxxxxxxx # Websocket API resource ID. Default is generated by the framework
description: Some Description # optional - description of deployment history
functions: ...
No. You can reuse the lambda functions by pointing to the specific ARN's of those functions within Serverless.yml, but there is currently no way to "replace" the API Gateway component without manual intervention and re-creation using Serverless.
The upside is, it should be relatively straightforward and easy to do unless you use features in AWS API Gateway currently not supported by the Serverless framework.
I have a simple question: is there a way/program/method to create unit tests to test the API Url generated on AWS AppSync to verify the validity of created GraphQL schemas, queries, mutations, etc?
There is an open-source AppSync Serverless plugin which has offline emulator support. You may find it useful: https://github.com/sid88in/serverless-appsync-plugin#offline-support
Another good recommendation is to have two separate AppSync APIs. One API is hosting you production traffic. The other is to test changes before they go to production. This is significantly easier if you use Cloudformation (highly recommended) to manage your infrastructure.
If you want to validate your API is working periodically (every minute or so), you could create a canary like the following:
Create a Lambda function which runs on a schedule. This lambda function will make various GraphQL requests. It can emit success/failure metrics to CloudWatch.
Setup a CloudWatch alarm so you can be notified if your success/failure metric is out of the ordinary.
For the canary use-case see:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html
There is also amplify amplify-appsync-simulator package that is supposed to help with testing appsync, but there is no documentation on how you should use it. It is used by serverless-appsync-simulator Michael wrote and Amplify itself.