DEV Community

Ran Isenberg for AWS Community Builders

Posted on • Edited on • Originally published at ranthebuilder.cloud

AWS Lambda Smart Feature Flags — Now with Time Based Conditions

Time 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.

[https://www.ranthebuilder.cloud/](https://www.ranthebuilder.cloud/)

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:

{
"christmas_discount": {
"default": false,
"rules": {
"enable discount during christmas": {
"when_match": true,
"conditions": [
{
"action": "SCHEDULE_BETWEEN_DATETIME_RANGE",
"key": "CURRENT_DATETIME",
"value": {
"START": "2022-12-25T12:00:00",
"END": "2022-12-31T23:59:59",
"TIMEZONE": "America/New_York"
}
}]}}}}
view raw datetime.json hosted with ❤ by GitHub
> 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:

from aws_lambda_powertools.utilities.feature_flags import AppConfigStore, FeatureFlags
app_config = AppConfigStore(environment="dev", application="product-catalogue", name="features")
feature_flags = FeatureFlags(store=app_config)
def lambda_handler(event, context):
# Get customer's tier from incoming request
xmas_discount = feature_flags.evaluate(name="christmas_discount", default=False)
if xmas_discount:
# Enable discount on christmas:
view raw datetime.py hosted with ❤ by GitHub

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:

{
"weekend_discount": {
"default": false,
"rules": {
"saturday or sunday time for discount": {
"when_match": true,
"conditions": [
{
"action": "SCHEDULE_BETWEEN_DAYS_OF_WEEK",
"key": "CURRENT_DAY_OF_WEEK",
"value": {
"DAYS": [
"SATURDAY",
"SUNDAY"
],
"TIMEZONE": "America/New_York"
}
}
]
}
}
}
}
view raw time_based.json hosted with ❤ by GitHub

The Lambda function handler code looks like this:
from aws_lambda_powertools.utilities.feature_flags import AppConfigStore, FeatureFlags
app_config = AppConfigStore(environment="dev", application="product-catalogue", name="features")
feature_flags = FeatureFlags(store=app_config)
def lambda_handler(event, context):
weekend_discount = feature_flags.evaluate(name="weekend_discount", default=False, context=ctx)
if weekend_discount:
# Enable special discount on weekends
view raw time_based.py hosted with ❤ by GitHub

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:

{
"happy_hour": {
"default": false,
"rules": {
"is happy hour": {
"when_match": true,
"conditions": [
{
"action": "SCHEDULE_BETWEEN_TIME_RANGE",
"key": "CURRENT_TIME",
"value": {
"START": "17:00",
"END": "19:00",
"TIMEZONE": "America/New_York"
}}]}}}}

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:

{
"happy_hour": {
"default": false,
"rules": {
"happy hour on weekend and between 17 to 19": {
"when_match": true,
"conditions": [
{
"action": "SCHEDULE_BETWEEN_DAYS_OF_WEEK",
"key": "CURRENT_DAY_OF_WEEK",
"value": {
"DAYS": [
"SATURDAY",
"SUNDAY"
],
"TIMEZONE": "America/New_York"
}
},
{
"action": "SCHEDULE_BETWEEN_TIME_RANGE",
"key": "CURRENT_TIME",
"value": {
"START": "17:00",
"END": "19:00",
"TIMEZONE": "America/New_York"
}
}
]
}
}
}
}
view raw happy_ex.json hosted with ❤ by GitHub

And in both cases, the Lambda function handler code looks like this:
from aws_lambda_powertools.utilities.feature_flags import AppConfigStore, FeatureFlags
app_config = AppConfigStore(environment="dev", application="product-catalogue", name="features")
feature_flags = FeatureFlags(store=app_config)
def lambda_handler(event, context):
is_happy_hour = feature_flags.evaluate(name="happy_hour", default=False)
if is_happy_hour:
# Apply special discount
pass
view raw current_time.py hosted with ❤ by GitHub

The same IANA timezone format applies here too.

Heroku

Simplify your DevOps and maximize your time.

Since 2007, Heroku has been the go-to platform for developers as it monitors uptime, performance, and infrastructure concerns, allowing you to focus on writing code.

Learn More

Top comments (0)

Best Practices for Running  Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK cover image

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

This post discusses the process of migrating a growing WordPress eShop business to AWS using AWS CDK for an easily scalable, high availability architecture. The detailed structure encompasses several pillars: Compute, Storage, Database, Cache, CDN, DNS, Security, and Backup.

Read full post

👋 Kindness is contagious

Immerse yourself in a wealth of knowledge with this piece, supported by the inclusive DEV Community—every developer, no matter where they are in their journey, is invited to contribute to our collective wisdom.

A simple “thank you” goes a long way—express your gratitude below in the comments!

Gathering insights enriches our journey on DEV and fortifies our community ties. Did you find this article valuable? Taking a moment to thank the author can have a significant impact.

Okay