AWS Lambda Smart Feature Flags — Now with Time Based Conditions

Feature flags change service behavior in runtime without redeploying the service code. Feature flags can improve your CI/CD process by enabling capabilities otherwise not possible, thus making them an enabler of DevOps and a crucial part of continuous integration. However, that requires a flexible and easy-to-use feature flags implementation such as AWS Lambda Powertools feature flags utility and AWS AppConfig.

This blog covers the newly added time conditions to the AWS Lambda Powertools feature flags utility open-source I contributed that leverages AWS AppConfig. You will learn how to define time-based feature flags that will change the behavior of your service at different times, hours and weekdays.

This blog was originally published on my website “Ran The Builder”.

Re: cap

In my previous post, I presented the added value of using feature flags as part of your CI/CD process and showcased a feature flags rule-based open-source SDK I contributed to AWS Lambda Powertools that leverages AWS AppConfig.

This post assumes you are familiar with the AWS Lambda Powertools feature flags utility and can deploy JSON configuration to AWS AppConfig.

In case you are not, feel free to watch my Conf42 DesSecOps 2022 conference talk in the video below:

Time-Based Feature Flags Use Case

Prior to this feature, you could define rules with 12 possible conditions options.

You could enable features for users that are part of a specific tier, customer, region, and any string comparison or numeric comparison condition.

However, none of them included any time conditions.

I’ve been working with the AWS Lambda Powertools on this feature for some time to get it right and up to standards, and it finally got released in v2.7.0 and documented here.

There are three time-based conditions, and each has its use case:

1. Datetime range condition

2. Weekdays condition

3. Hour ranges condition

You can also mix and match them and use any other condition out of the previous 12 conditions to create even more complex rules and use cases.

Datetime Range Condition Use case

Let’s assume you want to enable a feature flag starting a precise date and turn it off automatically at a precise date; for example, you wish to enable a Christmas discount feature only during the Christmas days sale.

The following configuration provides this behavior:

> If you don’t specify the timezone, UTC is assumed. If you wish to specify a timezone, you can use any IANA time zone (as originally specified in PEP 615 ) as part of your rules definition. Powertools takes care of converting and calculate the correct timestamps for you.

The Lambda function handler code looks like this:

AWS Lambda Powertools feature flags will check the current Lambda function time against the START and END conditions you defined to evaluate the rule.

Week Days Condition Use Case

Let’s assume you want to enable a feature flag during specific weekdays; for example, you wish to provide a weekend discount for a recurring event. You can define specific days (not ranges) to enable the feature, in this case, during Saturday and Sunday only.

The following configuration provides this behavior:

The Lambda function handler code looks like this:

AWS Lambda Powertools feature flags will check the current Lambda function day against the START and END conditions you defined to evaluate the rule.

The same timezone IANA format applies here too.

Hour Ranges Condition Use Case

Let’s assume you want to enable a feature flag during specific hours every day, for example, you wish to enable a happy hour feature between 17:00 to 19:00 every day as a recurring event.

The following configuration provides this behavior:

Let’s assume you want to enable a feature flag during specific hours every day; for example, you wish to enable a happy hour feature between 17:00 to 19:00 every day as a recurring event. You can add another condition, for the weekend days. The rule will match only if both conditions are matched, i.e, only when on a Saturday or Sunday AND the hour is 17:00 to 19:00 New York time. The order of the conditions does not matter.

The following configuration provides this behavior:

And in both cases, the Lambda function handler code looks like this:

The same IANA timezone format applies here too.