Tutorial: AWS API Gateway to Lambda to DynamoDB

You may also like...

19 Responses

  1. Sushil says:

    Awesome tutorial

  2. 3dramble says:

    Hi Jon, excellent article, I was wondering if you have such a clear article as to how to retrieve the list of values from this example via APi -> Lambda?

  3. Orr says:

    My name is Orr Weinstein, and I am a senior Product Manager on the AWS Lambda team.

    Just wanted to update everyone that today, three API GW features were launched that both simplify Lambda integration, and also make it much more powerful (depending on your needs).

    API GW What’s new post: https://aws.amazon.com/about-aws/whats-new/2016/09/amazon-api-gateway-introduces-3-new-features-to-simplify-api-configuration/

    Lambda What’s new post: https://aws.amazon.com/about-aws/whats-new/2016/09/aws-lambda-simplifies-amazon-api-gateway-integration/

    Jeff Barr’s blog post: https://aws.amazon.com/blogs/aws/api-gateway-update-new-features-simplify-api-development/


  4. Dave says:


    I think great changes since you made example function. Can you rewrite it again with the new screenshot of AWS. Specifically, you will see that the DynamoDB and Lambda has change already.

    I’m a new guy here and my function says “errorMessage”: “ERROR: Dynamo failed: ResourceNotFoundException: Requested resource not found”. Frustrated person here, sorry.


  5. DC says:

    when you Create an API in the API Gateway, it now automatically creates the ROOT Endpoint, also known as RESOURCE-
    Creating it twice may not allow the tutorial to work correctly, It may be now that Step #2 is Create Method.
    Once I made this adjustment I no longer got the curl error

    Step #1 ā€“ Create a new API.
    Step #2 ā€“ Create Method

  6. question says:

    how could I tie your great example of writing to a dynamodb via lambda to alexa?

    • Jon says:

      That is an interesting use case. I don’t have an alexa, but that might be a fun reason to have one. Regardless you might look at something like https://www.npmjs.com/package/alexa-app since it specifically states “Easy connection into AWS Lambda”.

      In their example code they have a line: response.say(“You asked for the number “+number);

      There’s nothing to say you couldn’t change that line to be something like: myCustomWriteToDynamoFunction(number); response.say(“I wrote the number “+number+” to the database”);

      I could see that being useful for like a todolist or similar. You could even reverse it and have it look for items in Dynamo.

      • question says:

        Thank you for the reply and direction. This helps a great deal. I’ll keep you posted.

  7. Dirk says:

    Thanks for this guide! However, there is an inconsistency in the text, screenshot and the code, which costed me half an hour to find the problem.

    The text sais:
    “Range Name = datetime (Type number)”

    While the screenshot and gist code use “timedate”.

    I suggest to change the text to:
    “Range Name = timedate (Type number)”

    • Jon says:

      You are entirely correct Dirk. I’m very sorry to have wasted your time with my typo’s. I’ve corrected the text of the blog to match the screenshot (And, as you said, the code).

  8. tophtucker says:

    Thanks for the tutorial. Everything works for me up until curl. I just get: {“message”:”Missing Authentication Token”}

    My API Gateway Authorization type is “None” and “API Key Required” is false.

    Any ideas?

    • Jon says:

      I ran into that issue as well the first time I was playing with it. Couple of possible options: #1 – Verify that you deployed your API changes. #2 – Make sure you’re hitting the URL _exactly_ correctly. ex: no trailing slash. #3 – Make sure you setup the API resource to the proper type (in this example, POST) and that you’re curl’ing the same.

      Unfortunately “missing auth token” is also the message you get when you 404 on API Gateway. So if you know you turned authorizations off then the problem is typically a URL or a wrong resource type.

      Hope that helps!

  9. Ollie Rattue says:

    Jon, thanks for taking the time to write up this ultra clear tutorial. Appreciate your efforts here, experimenting and documenting a bleeding edge technology. Have a great day.

  10. Michael Binette says:

    In step 5 it shows that it took 612.05 ms to run. Then in step 7 the API call took 2309 ms. If you run these steps multiple times in a row, does the latency get better? If every API call took 2309 ms for a single DynamoDB putItem call then I can’t see how this could be used for anything besides a fire and forget situation.

    I wanted to test the waters of using Lambda, API Gateway, and DynamoDB for a true serverless backend but no app can overcome that amount of latency.

    • Jon says:

      That’s a fair point, I hadn’t noticed the timing in those screenshots. I tried the Step 10 curl on the command line (and added a `time` beforehand). I ran it 10 times and got the following “real” times: 0m0.589s 0m0.533s 0m0.370s 0m0.585s 0m0.361s 0m0.588s 0m0.602s 0m0.395s 0m0.564s 0m0.582s — So as you can see the average is somewhere in the 0.4second range. Keep in mind this is for the full curl session over HTTPS. I suspect most of the time is probably negotiating the conversation, and additions of large amounts of data or processing in Lambda wouldn’t add much time.

      Also keep in mind my DynamoDB in this case is set to 5 read unit and 2 write unit capacity. The API Gateway also offers caching options, which I opt’d not to enable. I’d suspect that there are some additional tricks to getting API Gateway/Lambda/Dynamo to be even more performant, but I honestly don’t know them.

    • Ollie Rattue says:

      The high latency is caused by not assigning the lambda function enough memory – see https://forums.aws.amazon.com/thread.jspa?threadID=211709&tstart=25 for further details.

      • Jon says:

        Spot on Ollie. I change what the Lambda function was allocated and ran the in-lambda test.

        With 128mb allocated: Duration: 650.53 ms Billed Duration: 700 ms
        With 1024mb allocated: Duration: 76.47 ms Billed Duration: 100 ms

        So the times dropped drastically, awesome!

      • akdjr says:

        Another factor is whether or not lambda chooses to reuse the container. When your function is first run, it provisions an ec2 container to execute in. On subsequent invocations, if lambda reuses that container, the execution time will be much lower as it doesn’t have to go through the container creation process.

        One of things on Amazon’s roadmap is improving their container reuse strategies, so that will be interesting to see. It also means that using lambda with something like RDS or a MongoDB instance has the added duration cost of the connection process (which is a tad unfortunate).

Leave your thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: