Using feature flags and other runtime configuration types is a fast-evolving technology segment. Adjusting your software behavior with a minor configuration update instead of deploying code lets teams move faster and more safely. Furthermore, releasing a feature using a feature flag allows engineering teams to turn on features to a limited set of users and then measure the impact. The capability can instantly turn off and roll back if something goes wrong, significantly limiting the change’s impact. At Amazon, we call the practice of using feature flags and runtime configuration, Continuous Configuration.
AWS AppConfig started in 2017 as an internal tool for Amazon. It quickly became a top-used service for internal teams that wanted a safe and measured way to manage their feature flags and operational flags. In 2019, AWS launched AppConfig for external customers. This offering had all of the learned lessons and best practices for utilizing runtime configuration and feature flags built into the product. Now we’re announcing AppConfig Extensions, which allows customers to extend the power of dynamic configuration and feature flags in new and innovative ways. After reading this post, you’ll understand what AppConfig Extensions are, what problems they solve, and what extension types you can build.
Since the internal launch of AppConfig in 2017, and the external launch in 2019, we’ve added many features that customers have requested. These include integrations with Lambda, AWS CodePipeline, and Amazon CloudWatch, as well as releasing an opinionated format for feature flags in 2021. We’ve innovated on behalf of our customers, and we continually receive many requests for new functionality. One observation we’ve had on these requests is that there are aspects to them that make them impractical to build in a generic way. Another observation was seeing how some customers have built solutions on top of our service in ways that were specific to their own workflows. However, instead of having the AppConfig team build all new features as requested, we decided to empower others to build on top of AppConfig. We knew that allowing other engineers, both internal and external, to utilize a framework to extend AppConfig would be a force multiplier, plus give the freedom to support integrations into customer-specific systems and processes.
AppConfig Extensions are add-ons to AppConfig that enhance the power and safety of the main AppConfig service. Managing configuration typically follows a lifecycle similar to developing code: create/update, validate/test, deploy, and monitor. The AppConfig Extension framework exposes hooks, called action points, at each of these lifecycle milestones. When an action point is triggered, whatever actions (e.g. calling a Lambda function) are defined in the set of AppConfig Extensions applicable at that lifecycle step will be invoked.
The framework allows for easier integration of other services (AWS and otherwise) to help customers improve their velocity and safety. Over the coming months and years, we expect the number of extensions to grow significantly, providing bespoke solutions created by AWS and our customers.
To provide a sense of the functionality that AppConfig Extensions can provide, we’ll illustrate some examples corresponding to the lifecycle steps mentioned above, starting with the first phase: the creation of configuration data. Let’s say, for example, that you wanted to add a timestamp inside your hosted configuration data’s JSON each time it gets updated. With an extension, you could hook into the PRE_CREATE_HOSTED_CONFIGURATION_VERSION action point and write a simple AWS Lambda to insert the timestamp. You may next decide that you want to export a copy of each version of your hosted configuration data into a source repository like Github, regardless of its data format. You could create another extension that also hooks into the PRE_CREATE_HOSTED_CONFIGURATION_VERSION action point to export the hosted data into your repo every time the data changes. While both extensions could be associated to a particular Configuration Profile, you could instead associate this extension to an Application which will cause it to automatically apply to all hosted Configuration Profiles in your Application, even those created at a later date. Continuing down the lifecycle steps, you might need to merge data from another source, such as a legacy configuration database, into your configuration data before it deploys. Your extension would contain an action that triggers at PRE_START_DEPLOYMENT and calls a Lambda to retrieve the data and merge it into the to-be-deployed version of configuration data. As a final example, you could trigger test automation to run after you’ve deployed new configuration data by hooking into the ON_DEPLOYMENT_COMPLETE action point that publishes a message to an SNS topic.
As noted above, an extension can hook into AppConfig Extension action points. Currently, AppConfig exposes the following action points:
| Action point | Description |
| PRE_CREATE_HOSTED_CONFIGURATION_VERSION | occurs when an AppConfig hosted configuration is created or updated, but just before it’s saved |
| PRE_START_DEPLOYMENT | occurs just before a deployment starts |
| ON_DEPLOYMENT_START | occurs when an AppConfig deployment starts |
| ON_DEPLOYMENT_STEP | occurs during a deployment, and increments depending on the deployment strategy step percentage |
| ON_DEPLOYMENT_BAKING | occurs after the deployment completes, but bake time (if specified) starts |
| ON_DEPLOYMENT_COMPLETE | occurs after the deployment and bake time is complete |
| ON_DEPLOYMENT_ROLLED_BACK | occurs if a deployment roll back initiates |
In addition to the AppConfig extensions you create, we have a handful of extensions that are already available for you to use. The AppConfig Notification Extensions allow customers to be notified for the ON_DEPLOYMENT_START, ON_DEPLOYMENT_COMPLETE, and ON_DEPLOYMENT_ROLLEDBACK action points. Customers can have these notifications sent to Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), or Amazon Simple Queue Service (Amazon SQS). We also have an AppConfig Feature Flags Helper extension, which plays a role in our Feature Flags feature and is automatically associated to Feature Flag Configuration Profiles, as well as a Jira Integration extension that creates and manages Jira Issues associated to your feature flags.
This initial launch of AppConfig Extensions lays the foundation for the platforming of configuration data and feature flags. However, this is just the start. In the future, we expect to release many AWS-owned extensions and some third-party extensions. Moreover, we’re looking forward to talking to customers about the extensions they have authored, and continuing to innovate with our customers in how they’re utilizing feature flags and runtime configuration.
Get started with AWS AppConfig Extensions.
By Steve Rice and Jonathan (JT) Thompson
