Creating a configuration profile for non-native data sources - Amazon AppConfig
Migrating to Amazon AppConfig from legacy and home-grown configuration services
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Creating a configuration profile for non-native data sources

Amazon AppConfig supports deploying configuration data from most any data store. Natively, Amazon AppConfig supports deploying configuration data stored in the following services:

  • The Amazon AppConfig hosted configuration store

  • Amazon S3

  • Amazon Secrets Manager

  • Amazon Systems Manager Parameter Store

  • Systems Manager Document Store

  • Amazon CodePipeline

If your configuration data is stored in a location not natively supported by Amazon AppConfig, you can create an Amazon AppConfig extension to retrieve your data from its source. For example, by using an Amazon AppConfig extension, you can retrieve configuration data stored in Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB (DynamoDB), GitHub, GitLab, or a local repo, to name a few. By implementing an extension, you can take advantage of Amazon AppConfig security and DevOps enhancements for your applications and computing environment. You can also use this method as you migrate configuration data from legacy systems into Amazon AppConfig.

Creating a configuration profile for data sources not natively supported in Amazon AppConfig involves the following processes or actions:

  1. Create an Amazon Lambda function that fetches data from your data source. As long as a Lambda function can access the data source, your Amazon AppConfig extension will be able to retrieve the data.

  2. Create a custom Amazon AppConfig extension that invokes your Lambda function. For more information, see Walkthrough: Creating custom Amazon AppConfig extensions.

  3. Create an Amazon AppConfig free-form configuration profile. Specifically, create a configuration profile that uses the Amazon AppConfig hosted configuration definition. The configuration profile functions as a temporary data store after your Lambda function retrieves your configuration from your source. Your application will retrieve the configuration data from the Amazon AppConfig hosted configuration store. For more information, see Creating a free form configuration profile in Amazon AppConfig.

  4. Create an extension association that triggers using the PRE_CREATE_HOSTED_CONFIGURATION_VERSION action point. For more information, see Step 4: Create an extension association for a custom Amazon AppConfig extension.

Once configured, when your application requests a new version of the configuration data, the Lambda fetches your configuration data and pulls it into the configuration profile. Amazon AppConfig then saves the configuration profile and your third-party data.

When you're ready, you can deploy the configuration profile to your applications, just like any other type of configuration data.

Note

You can choose to insert third-party data in line with existing configuration data, or have the entire contents of the configuration data contain only the third-party data. If you want to have the data in line with other existing data, that logic should be part of the Lambda function that imports the data from the third-party source.

Migrating to Amazon AppConfig from legacy and home-grown configuration services

If you've started using Amazon AppConfig and still have legacy configuration data or feature flags in another system, you can use the process described earlier in this topic to migrate off of your legacy system and onto Amazon AppConfig. You can build an extension that pulls data out of your legacy system and deploys it through Amazon AppConfig. Using Amazon AppConfig in this way provides you with all of the safety guardrail controls and benefits while still using your legacy data stores.