1

I'm a bit of a beginner but I'm working on creating an external API with AWS SAM (using API Gateway and Lambda), and I want a way to track & monitor usage.

Some options I was considering:

1. Store the requests in a database

Pro: It would allow me to store as much information as I want about the request
Con: I figured this might be too slow to handle a lot of fast requests

2. Keep count of how often a user makes requests with Redis – but I would also want more information about the requests they make

Pro: I could quickly count user requests
Con: This might limit the amount of information I could store about a user if my key-value pair is user-id: number-of-requests

3. Use a messaging queue

Pro: I could put request info into a message queue and let another Lambda function put it in a database without slowing down my API's response time Con: This might be overly complex? And I still might have the same issue as option 1 where I would have a bunch of small transactions at once.

Can you suggest an approach or critique any of the options above?

Thanks for your help!

A Poor
  • 113
  • 4
  • 1
    Is a basic access log possible? When a request comes into lambda write and entry to Cloudwatch Logs simpler and cheaper than DynamoDB, but bandwidth and storage does add up. – Tim May 03 '21 at 21:00

1 Answers1

2

API Gateway includes some request logging to Cloudwatch Logs, documentation is here. If you want to record more information I would personally collect it in lambda and push it out to an access log in a dedicated Cloudwatch Logs group. Just beware because the cost of bandwidth and storage to Cloudwatch Logs can add up for busy sites.

Otherwise regarding your options

  1. DynamoDB would be fast enough. A MySQL database would probably be fine for performance as well, probably adding less than a millisecond to processing time.
  2. Not really fully featured
  3. This would work fine, but I would only do it if #1 turned out to be too slow. It's not that complex to push a message to a queue then have another process consume it.
Tim
  • 31,888
  • 7
  • 52
  • 78