Over the past few years, DynamoDB has gotten more and more popular as a database. This is for a few reasons, such as the way it fits so well with serverless architectures using AWS Lambda or AWS AppSync or due to the growing community around how to model DynamoDB spurred by the talks from the incredible Rick Houlihan.

When I talk to people who are new to DynamoDB, I often hear the same initial grumblings:

DynamoDB is a solid, well-loved product, but that hasn't stopped the DynamoDB team from innovating. At last year's re:Invent, we saw two huge announcements. DynamoDB Transactions brought transactions to DynamoDB and made it easier to handle complex, multi-item operations in a single request. DynamoDB On-Demand Pricing let you forget about capacity planning and only pay for what you use.

But as AWS customers, we still want more. It's the reason Jeff Bezos loves us -- we are 'divinely discontent'. In this post, I lay out my two big #awswishlist items for DynamoDB.

AWS just announced the release of S3 Batch Operations. This is a hotly-anticpated release that was originally announced at re:Invent 2018. With S3 Batch, you can run tasks on existing S3 objects. This will make it much easier to run previously difficult tasks like retagging S3 objects, copying objects to another bucket, or processing large numbers of objects in bulk.

In this post, we'll do a deep dive into S3 Batch. You will learn when, why, and how to use S3 Batch. First, we'll do an overview of the key elements involved in an S3 Batch job. Then, we'll walkthrough an example by doing sentiment analysis on a group of existing objects with AWS Lambda and Amazon Comprehend.

AWS API Gateway is an awesome service to use as an HTTP frontend. You can use it for building serverless applications, for integrating with legacy applications, or for proxying HTTP requests directly to other AWS services.

But understanding the elements of API Gateway can be difficult. If you're like me, your understanding of API Gateway might be like the following:

In a previous post, we looked at how to use CloudFormation Macros to provide a simpler DSL around CloudFormation or to provide company-wide defaults around particular resources.

However, sometimes you need more than what CloudFormation currently offers. Perhaps CloudFormation doesn't have support for a resource that you need. Or maybe you want to use a third-party resource, like Auth0 or Algolia, in your application.

In this post, we'll learn about CloudFormation custom resources. Custom resources greatly expand what you can do with CloudFormation as you can run custom logic as part of your CloudFormation deployment.

In September 2018, AWS released CloudFormation Macros, a powerful addition to CloudFormation. Macros allow you to write your own mini-DSLs on top of CloudFormation, giving you the power to enforce organization-wide defaults or allow for more flexible syntax in your templates.

In this post, we'll cover the what, why, and how of CloudFormation macros. This post includes:

AWS CloudFormation is a powerful tool for provisioning resources in AWS. It allows you to describe your desired infrastructure in a configuration file, which can be checked into source control for easy review, automation, and tracking over time. You submit this configuration file to the CloudFormation service, which safely and reliably provisions your infrastructure.

One of the trickier aspects of CloudFormation is around its update mechanisms. Changing a property for an existing resource in your CloudFormation file can have drastic effects on your infrastructure, including replacing an existing piece of infrastructure by deleting the old one and creating a new one.

Amazon DynamoDB is a fully-managed NoSQL database that's exploding in popularity. It provides low-latency reads and writes via HTTP with low maintenance in a way that fits with high-scale applications.

At re:Invent 2017, AWS announced DynamoDB Global Tables. With Global Tables, you can write to a DynamoDB table in one region, and AWS will asynchronously replicate items to the other regions.

Serverless is all the rage. Ever since AWS Lambda was announced at re:Invent 2014, there's been an explosion in the serverless space. We've seen more FaaS offerings, more event sources, more managed services, and more pay-per-use pricing models.

Serverless has unlocked a whole new world for developers. But how do you get started? Because serverless is so new, it requires learning new patterns and skills.

In this post, I'll cover a few categories that I see as good entry-level projects with serverless. It's kind of like having your training wheels on -- you get used to the motions and how things work without making a big bet with your core business applications.

In my last post, I showed how to connect AWS API Gateway directly to SNS using a service integration.

A few people asked me about the performance implications of this architecture.