Expiration With DynamoDB TTL

In my last post I mentioned our trials expire after 14 days.

In the old system we used a Lambda function scheduled by a CloudWatch event to check for trials that had expired by comparing the current date with an expiry date stored on the EC2 instance as a tag.

We also had a mechanism to routinely remove previous trial requests from the DynamoDB table, again something scheduled daily with a CloudWatch event.

The DynamoDB TTL feature seemed a perfect use case for both these problems.

When a trial is provisioned an expiry time is calculated (using epoch seconds) and stored in the TTL attribute. This gist shows how we configure the “expiresAt” attribute for TTL in CloudFormation and figure 1 below shows how the DynamoDB console confirms the configuration has been applied.

Figure 1.

For the TTL attribute to work the value has to be stored as epoch seconds in an attribute of type Number and the streams feature needs to be enabled using the NEW_AND_OLD_IMAGES setting.

If you need to do some troubleshooting and examine the table having the TTL attribute stored as epoch seconds means it’s hard to determine the actual date and time without calculating it. Fortunately, AWS have thought about this and provided a really useful feature, hover your mouse over the value and a popup appears showing the ISO time as shown in figure 2 below.

Figure 2.

Shortly after the expiry time has passed DynamoDB will remove the item from the table which in turn will cause a REMOVE event to be sent to the stream. Items removed by a TTL can be differentiated from a DeleteItem API call by the existence of an userIdentity object in the event.

We then have a Lambda function processing the event stream converting INSERT events into a “TrialRequested” EventBridge event and REMOVE events triggered by TTL into a “TrialExpired” EventBridge event. Our use of EventBridge will be the focus of my next post!