Use AWS Secrets Manager to Store Feature Flags
If you develop and maintain software that runs “on-prem” in the AWS environment, you might want to move new or modified code to production behind a switch or a feature flag. This can reduce the risk and assist in backing out your changes if necessary, or manage the issues that may occur from unintended consequences. Even when you’re sure you’ve got the problem nailed, you might just add a feature flag as insurance.
Maintenance and eliminating tech debt also present opportunities to use a feature flag. In some cases, refactoring or swapping out APIs that access external systems may require adding a feature flag to support “old way”, “new way” changes.
Often feature flags are added to the application’s configuration file, and are parsed and made available using a mechanism like Java’s Properties class. This works well enough, but is static. It might be better to have a more dynamic way to manage the feature flags, and more importantly, an easier way to update them on-the-fly.
The AWS Secrets Manager offers many capabilities to provide a full secrets management solution. From the AWS Secrets Manager product page, we learn it offers these capabilities:
The service enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.
As it turns out, Secrets Manager is a good feature flag system for some use cases.
In Secret Manager parlance, a “secret” is a group of items that are stored and retrieved together. In my case I set up one Secret that contained about a dozen items. The items are key-value pairs, the Secret Manager returns the entire group — the Secret — as a JSON document.
As far as AWS cost go, creating and using a Secret is not expensive. The Secret itself is $0.40 per month, and $0.05 for 10,000 accesses. This does not seem to be expensive, unless the secret is retrieved from the AWS Secrets Manager very often. In the sample code below, the constructor accesses AWS, and the getter routines for the specific key/value pairs access the cached data, so they are free.
The primary prerequisite is to have the developer and EC2 instance able to access the Secret; ensure they are in groups that have a role with appropriate access to Secret Manager.
Creating a Secret is easy, a few steps through the AWS Secret Manager UI. Go to the Secrets Manager main page, click “Store a new Secret”. Ensure you click “Other types of Secrets”, and disable Key rotation.
The AWS secrets manager walks you through the steps of creating a new secret and also provides sample code to add to your program to access the secrets.
Here is the sample code for one of my applications, verbatim, as generated by AWS:
In this AWS-provided code no credentials are hard coded, although the Secret name and region are.
I modified this code based on these ideas:
- No hard coded values
- Exceptions will be handled by the caller, there aren’t any decisions to be made in this code in case of exceptions. The developer can determine how elaborate the “fall back plan” should be. In my case, the caller prints the exception and then calls System.exit().
- Provide accessor routines for String, int, long, and boolean datatypes
- Keep the Secret stored in this class.
Here is my version which includes getters for various datatypes:
To summarize, in this post I’ve suggested using AWS Secret Manager as a cheap-and-easy feature flag system that you can use in development and production. The code above may have room for improvement, but work with it and you will see how easy it is to have an inexpensive, powerful, dynamic, feature-flag system.
