Prefer video? View this post on YouTube!

As a programmer, it is important to know the limits of any service that you're using. In some cases, the limits of a particular service may make it unsuitable for the task at hand, such as using Route53 as a database. In other cases, the limit may alter how you structure your solution, such as how the 15 minute limit on Lambda execution time requires you to break down large work into smaller chunks.

In this post, we'll talk about limits in DynamoDB. While the DynamoDB documentation has a long list of limits for the service, most of these are not going to drastically change how you use DynamoDB. For example, nested attributes can only go to 32 levels of depth, I've never found this to be a factor in building my applications.

I've spent a fair bit of time with API Gateway over the past few years. It's an awesome (if occasionally frustrating) service for building serverless web APIs using Lambda functions.

In previous blog posts, I took a close look at the internals of API Gateway and ran a performance test for different API setups. We've explored the intricacies of custom authorizers in API Gateway and how to connect API Gateway directly to other AWS services.

In this post, we're continuing the deep dive on API Gateway. Here, we'll be looking at API Gateway access logging. Access logging can save your bacon when debugging a gnarly API Gateway issue, but you need to understand some nuance before you can use it correctly. We'll dig into the details here so that you'll be logging like Paul Bunyan in no time.

If you're working with DynamoDB, you're likely to rely on Condition Expressions when manipulating items in your table. Condition Expressions can ensure you don't overwrite existing users, allow bank account balances to drop below \$0, or give Admin access to every user in your application.

Yet despite their usefulness, I see Condition Expressions misunderstood quite often. My hunch is that this is due to an underdeveloped mental model of how DynamoDB works and why it makes the choices it makes.

In this post, you'll learn all about DynamoDB's Condition Expressions. First, we'll start with some background on what Condition Expressions are. We'll see why they are helpful and the API operations to which they apply.

DynamoDB is sometimes considered just a simple key-value store, but nothing could be further from the truth. DynamoDB can handle complex access patterns, from highly-relational data models to time series data or even geospatial data.

In this post, we'll see how to model one-to-many relationships in DynamoDB. One-to-many relationships are at the core of nearly all applications. In DynamoDB, you have a few different options for representing one-to-many relationships.

This is part 2 of a two-part post on DynamoDB Transactions. Check out part 1 in this series for a look at how and when to use DynamoDB Transactions.

In this post, we're going to do some performance testing of DynamoDB Transactions as compared to other DynamoDB API calls. As a reminder from the last post, you can use DynamoDB Transactions to make multiple requests in a single call. Your entire request will succeed or fail together -- if a single write cannot be satisfied, all other writes will be rolled back as well.

Amazon's DynamoDB was released in 2012 and has been adding a drumbeat of new features ever since. It's hard to believe now, but the original version of DynamoDB didn't have DynamoDB Streams, parallel scans, or even secondary indexes.

One of the more exciting feature releases from DynamoDB in recent years has been the addition of DynamoDB Transactions at re:Invent 2018. With DynamoDB Transactions, you can write or read a batch of items from DynamoDB, and the entire request will succeed or fail together.

This feature release simplified a lot of workflows that involved complex versioning and multiple requests to accurately work across multiple items. In this post, we'll review how and why to use DynamoDB Transactions.

I've become a big proponent of DynamoDB over the past few years. DynamoDB provides many benefits that other databases don't, such as a flexible pricing model, a stateless connection model that works seamlessly with serverless compute, and consistent response time even as your database scales to enormous size.

Yet data modeling with DynamoDB is tricky for those used to the relational databases that have dominated for the past few decades. There are a number of quirks around data modeling with DynamoDB, but the biggest one is the recommendation from AWS to use a single table for all of your records.

In this post, we'll do a deep dive on the concepts behind single-table design.

In the past few weeks, I've seen a few podcasts talking about building developer communities. As I listened to them, I wanted to share my thoughts on building developer communities.

For background, I ran the Growth team at Serverless, Inc. for part of 2017 as the Serverless Framework was really taking off. I also spent all of 2018 & 2019 in a different role at Serverless but still heavily engaged in the community.

In this post, I'll cover how our team worked to engage and grow the community over time.

When building an application with AWS Lambda, you may need to host your Lambda function in a VPC. The most common reason for this is because your Lambda function will use other resources which aren't accessible from the public internet, such as a relational database or Redis instance.

Since the improvement of VPC cold starts in 2019, hosting a Lambda function inside a VPC is more feasible even for user-facing workflows. However, by default, your Lambda function in a VPC won't have access to the public internet. This is fine for many use cases, as you may have an HTTP endpoint that uses your database in the VPC and responds to the user without making any public internet calls.

But even a single endpoint like this can be a pain if you're using a service like Amazon CloudWatch Metrics to store metrics about your function's execution. Like other AWS services, the CloudWatch Metrics API is a public API that requires public internet access to publish metric data from your Lambda function.

In this post, we'll see three ways to use AWS services from your Lambda function in a VPC:

Over the past few years, I've helped people design their DynamoDB tables. For many, it's a struggle to unlearn the concepts of a relational database and learn the unique structure of a DynamoDB single table design. Primary keys, secondary indexes, and DynamoDB streams are all new, powerful concepts for people to learn.

Yet there's one feature that's consistently a red herring for new DynamoDB users -- filter expressions. I'm going to shout my advice here so all can hear: