I'm creating a serverless website using AWS Lambda, but I'm a bit concerned about potential abuse. How do I protect myself against a user who queries my endpoint a million times?
The API Gateway supports throttling. The defaults are reasonable, but you can alter them however you like. The throttle settings in the console are under the Stages tab of you APIs. There's more info here: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
Related
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?
I am currently managing a website via Django.
The website's url will request an api which is stored in AWS Lambda Function.
Normally, a python based Lambda function with no VPC setting coldout wouldn't worry us.
But I have 2 concerns about my website performance.
The server function communicates with several 3rd party features like AWS S3, Firestore, Firebase Authentication, and DynamoDB. So every Lambda function needs to build up the required settings.
Every page of the website checks the Firebase authentication which persistance is local. Could process delay be critical to a coldstarted container, causing 30s timeout?
If some user occasionaly experience the API Gateway timeout, could the cause of this be AWS Lambda coldstart?
No, the cold start will never be that high. For all cases, cold start should be less than 1 second (even for lambdas bound to VPC).
I want my lambda function to access the database aurora serverless mysql. After some research, I found that we need to keep the lambda under the same VPC as aurora serverless. But keeping lambda in VPC leads to increase the cold start and also in order to access the internet we need to use NAT gateway which leads to additional cost. Since our application is small we cannot afford additional cost. Is there any other way we can access the aurora serverless database without keeping the lambda function in vpc?
maybe for the small application you can reduce the security level and run you serverless Aurora in the default VPC with the default security group. I mean to make the public access to the database with the login/password security gate only. Yes, it is less secure but your billing will be small.
I do not see another way.
Aurora Serverless has a feature called Data API. This allows you to access the database over http from outside the VPC or from anywhere on the Internet.
So, your database can be in a private VPC and your Lambda can be outside the VPC.
However, at the time of writing this, Data API has a high latency. Simple requests can take up to 200 ms to complete.
We are currently deploying to AppSync using the serverless-appsync plugin and the serverless-framework (naturally).
Our API is 100% public and unauthenticated. All queries and mutations are basically public, since we have at this point no need for users (via a Cognito pool for example).
We have added a first layer of security using api keys but this is undoubtedly not much, as the api key is included as-is in the frontend sources. We would like to add extra roadblocks to make it harder for malicious users to abuse that frontend API.
A few things come to mind:
rate limiting (not currently supported by AppSync but I've read it's apparently in the works). I do not want to do this using a custom made solution in a Lambda for example.
making sure only traffic from the website is allowed to use our API, in addition to our own devs... I could probably do this with pipeline resolvers but I am not too keen with doing that in that obscure and unwieldy VTL language.
cors, ...
I'm considering switching to Apollo Server since this solution seems more open and configurable...
I would recommend using AppSync's IAM auth option and then use Amazon Cognito Identity Pools to vend temporary AWS credentials to your client applications. Identity pools (as opposed to user pools) vend temporary AWS credentials that assume the access of a role of your choosing. When configuring the identity pool, you can define a role with full access to the AppSync API or you may selectively provide access. From the client applications, you use the temporary credentials to sign the requests to AppSync using SigV4 and AppSync will only allow requests with a valid signature to be executed. The temporary credentials also provide an extra layer of security as even if they are compromised, each credential will only provide access up to the max allowed time.
I'll also add that you can use multiple auth modes at once with an AppSync API. This allows you to protect all fields as mentioned above and then selectively mark specific other fields such that they are authorized via some other mechanism like user pools or OIDC.
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.