# Creating feature flags and free form configuration data in AWS AppConfig
Creating
The topics in this section help you complete the following tasks in AWS AppConfig. These tasks create important artifacts for deploying configuration data.
**1. [Create an application namespace](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-namespace.html)**
To create an application namespace, you create an AWS AppConfig artifact called an application. An application is simply an organizational construct like a folder.
**2. [Create environments](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-environment.html)**
For each AWS AppConfig application, you define one or more environments. An environment is a logical deployment group of AWS AppConfig targets, such as applications in a `Beta` or `Production` environment. You can also define environments for application subcomponents, such as `AWS Lambda functions`, `Containers`, `Web`, `Mobile`, and `Back-end`.
You can configure Amazon CloudWatch alarms for each environment to automatically rollback problematic configuration changes. The system monitors alarms during a configuration deployment. If an alarm is triggered, the system rolls back the configuration.
**3. [Create a configuration profile](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-profile.html)**
*Configuration data* is a collection of settings that influence the behavior of your application. A *configuration profile* includes, among other things, a URI that enables AWS AppConfig to locate your configuration data in its stored location and a configure type. AWS AppConfig supports the following types of configuration profiles:
+ **Feature flags**: You can use feature flags to enable or disable features within your applications or to configure different characteristics of your application features using flag attributes. AWS AppConfig stores feature flag configurations in the AWS AppConfig hosted configuration store in a feature flag format that contains data and metadata about your flags and the flag attributes. The URI for feature flag configurations is simply `hosted`.
+ **Freeform configurations**: A freeform configuration can store data in any of the following AWS services and Systems Manager tools:
+ AWS AppConfig hosted configuration store
+ Amazon Simple Storage Service
+ AWS CodePipeline
+ AWS Secrets Manager
+ AWS Systems Manager (SSM) Parameter Store
+ SSM Document Store
If possible, we recommend hosting your configuration data in the AWS AppConfig hosted configuration store as it offers the most features and enhancements.
**4. (Optional, but recommended) [Create multi-variant feature flags](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-multi-variant-feature-flags.html)**
AWS AppConfig offers basic feature flags, which (if enabled) return a specific set of configuration data per request. To better support user segmentation and traffic splitting use cases, AWS AppConfig also offers multi-variant feature flags, which enable you to define a set of possible flag values to return for a request. You can also configure different statuses (enabled or disabled) for multi-variant flags. When requesting a flag configured with variants, your application provides context that AWS AppConfig evaluates against a set of user-defined rules. Depending on the context specified in the request and the rules defined for the variant, AWS AppConfig returns different flag values to the application.
**Topics**
+ [
# Understanding the configuration profile IAM role
](appconfig-creating-configuration-and-profile-iam-role.md)
+ [
# Creating a namespace for your application in AWS AppConfig
](appconfig-creating-namespace.md)
+ [
# Creating environments for your application in AWS AppConfig
](appconfig-creating-environment.md)
+ [
# Creating a configuration profile in AWS AppConfig
](appconfig-creating-configuration-profile.md)
# Understanding the configuration profile IAM role
You can create the IAM role that provides access to the configuration data by using AWS AppConfig. Or you can create the IAM role yourself. If you create the role by using AWS AppConfig, the system creates the role and specifies one of the following permissions policies, depending on which type of configuration source you choose.
**Configuration source is a Secrets Manager secret**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name-a1b2c3"
]
}
]
}
```
------
**Configuration source is a Parameter Store parameter**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:parameter/parameter_name"
]
}
]
}
```
------
**Configuration source is an SSM document**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/document_name"
]
}
]
}
```
------
If you create the role by using AWS AppConfig, the system also creates the following trust relationship for the role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appconfig.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# Creating a namespace for your application in AWS AppConfig
Creating a namespace
The procedures in this section help you create an AWS AppConfig artifact called an application. An application is simply an organizational construct like a folder that identifies the namespace of your application. This organizational construct has a relationship with some unit of executable code. For example, you could create an application called MyMobileApp to organize and manage configuration data for a mobile application installed by your users. You must create these artifacts before you can use AWS AppConfig to deploy and retrieve feature flags or free form configuration data.
The following procedure gives you the option to associate an extension with a feature flag configuration profile. An *extension* augments your ability to inject logic or behavior at different points during the AWS AppConfig workflow of creating or deploying a configuration. For more information, see [Understanding AWS AppConfig extensions](working-with-appconfig-extensions-about.md).
**Note**
You can use AWS CloudFormation to create AWS AppConfig artifacts, including applications, environments, configuration profiles, deployments, deployment strategies, and hosted configuration versions. For more information, see [AWS AppConfig resource type reference](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppConfig.html) in the *AWS CloudFormation User Guide*.
**Topics**
+ [
## Creating an AWS AppConfig application (console)
](#appconfig-creating-application-console)
+ [
## Creating an AWS AppConfig application (command line)
](#appconfig-creating-application-commandline)
## Creating an AWS AppConfig application (console)
Use the following procedure to create an AWS AppConfig application by using the AWS Systems Manager console.
**To create an application**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose **Create application**.
1. For **Name**, enter a name for the application.
1. For **Description**, enter information about the application.
1. (Optional) In the **Extensions** section, choose an extension from the list. For more information, see [Understanding AWS AppConfig extensions](working-with-appconfig-extensions-about.md).
1. (Optional) In the **Tags** section, enter a key and an optional value. You can specify a maximum of 50 tags for a resource.
1. Choose **Create application**.
AWS AppConfig creates the application and then displays the **Environments** tab. Proceed to [Creating environments for your application in AWS AppConfig](appconfig-creating-environment.md).
## Creating an AWS AppConfig application (command line)
The following procedure describes how to use the AWS CLI (on Linux or Windows) or AWS Tools for PowerShell to create an AWS AppConfig application.
**To create an application step by step**
1. Open the AWS CLI.
1. Run the following command to create an application.
------
#### [ Linux ]
```
aws appconfig create-application \
--name A_name_for_the_application \
--description A_description_of_the_application \
--tags User_defined_key_value_pair_metadata_for_the_application
```
------
#### [ Windows ]
```
aws appconfig create-application ^
--name A_name_for_the_application ^
--description A_description_of_the_application ^
--tags User_defined_key_value_pair_metadata_for_the_application
```
------
#### [ PowerShell ]
```
New-APPCApplication `
-Name Name_for_the_application `
-Description Description_of_the_application `
-Tag Hashtable_type_user_defined_key_value_pair_metadata_for_the_application
```
------
The system returns information like the following.
------
#### [ Linux ]
```
{
"Id": "Application ID",
"Name": "Application name",
"Description": "Description of the application"
}
```
------
#### [ Windows ]
```
{
"Id": "Application ID",
"Name": "Application name",
"Description": "Description of the application"
}
```
------
#### [ PowerShell ]
```
ContentLength : Runtime of the command
Description : Description of the application
HttpStatusCode : HTTP Status of the runtime
Id : Application ID
Name : Application name
ResponseMetadata : Runtime Metadata
```
------
# Creating environments for your application in AWS AppConfig
Creating environments
For each AWS AppConfig application, you define one or more environments. An environment is a logical deployment group of AppConfig targets, such as applications in a `Beta` or `Production` environment, AWS Lambda functions, or containers. You can also define environments for application subcomponents, such as the `Web`, `Mobile`, and `Back-end`. You can configure Amazon CloudWatch alarms for each environment. The system monitors alarms during a configuration deployment. If an alarm is triggered, the system rolls back the configuration.
**Before You Begin**
If you want to enable AWS AppConfig to roll back a configuration in response to a CloudWatch alarm, then you must configure an AWS Identity and Access Management (IAM) role with permissions to enable AWS AppConfig to respond to CloudWatch alarms. You choose this role in the following procedure. For more information, see [Configure permissions for automatic rollback](setting-up-appconfig.md#getting-started-with-appconfig-cloudwatch-alarms-permissions).
**Topics**
+ [
## Creating an AWS AppConfig environment (console)
](#appconfig-creating-environment-console)
+ [
## Creating an AWS AppConfig environment (command line)
](#appconfig-creating-environment-commandline)
## Creating an AWS AppConfig environment (console)
Use the following procedure to create an AWS AppConfig environment by using the AWS Systems Manager console.
**To create an environment**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose the name of an application to open the details page.
1. Choose the **Environments** tab, and then choose **Create environment**.
1. For **Name**, enter a name for the environment.
1. For **Description**, enter information about the environment.
1. (Optional) In the **Monitors** section, choose the **IAM role** field, and then choose an IAM role with permission to call `cloudwatch:DescribeAlarms` on the metrics you want to monitor for alarms.
1. In the **CloudWatch alarms** list, enter the Amazon Resource Names (ARNs) one or more metrics to monitor. AWS AppConfig rolls back your configuration deployment if one of these metrics goes into an `ALARM` state. For information about recommended metrics, see [Monitoring deployments for automatic rollback](monitoring-deployments.md)
1. (Optional) In the **Associate extensions** section, choose an extension from the list. For more information, see [Understanding AWS AppConfig extensions](working-with-appconfig-extensions-about.md).
1. (Optional) In the **Tags** section, enter a key and an optional value. You can specify a maximum of 50 tags for a resource.
1. Choose **Create environment**.
AWS AppConfig creates the environment and then displays the **Environment details** page. Proceed to [Creating a configuration profile in AWS AppConfig](appconfig-creating-configuration-profile.md).
## Creating an AWS AppConfig environment (command line)
The following procedure describes how to use the AWS CLI (on Linux or Windows) or AWS Tools for PowerShell to create an AWS AppConfig environment.
**To create an environment step by step**
1. Open the AWS CLI.
1. Run the following command to create an environment.
------
#### [ Linux ]
```
aws appconfig create-environment \
--application-id The_application_ID \
--name A_name_for_the_environment \
--description A_description_of_the_environment \
--monitors "AlarmArn=ARN_of_the_Amazon_CloudWatch_alarm,AlarmArnRole=ARN_of_the_IAM role_for_AWS AppConfig_to_monitor_AlarmArn" \
--tags User_defined_key_value_pair_metadata_of_the_environment
```
------
#### [ Windows ]
```
aws appconfig create-environment ^
--application-id The_application_ID ^
--name A_name_for_the_environment ^
--description A_description_of_the_environment ^
--monitors "AlarmArn=ARN_of_the_Amazon_CloudWatch_alarm,AlarmArnRole=ARN_of_the_IAM role_for_AWS AppConfig_to_monitor_AlarmArn" ^
--tags User_defined_key_value_pair_metadata_of_the_environment
```
------
#### [ PowerShell ]
```
New-APPCEnvironment `
-Name Name_for_the_environment `
-ApplicationId The_application_ID
-Description Description_of_the_environment `
-Monitors @{"AlarmArn=ARN_of_the_Amazon_CloudWatch_alarm,AlarmArnRole=ARN_of_the_IAM role_for_AWS AppConfig_to_monitor_AlarmArn"} `
-Tag Hashtable_type_user_defined_key_value_pair_metadata_of_the_environment
```
------
The system returns information like the following.
------
#### [ Linux ]
```
{
"ApplicationId": "The application ID",
"Id": "The_environment ID",
"Name": "Name of the environment",
"State": "The state of the environment",
"Description": "Description of the environment",
"Monitors": [
{
"AlarmArn": "ARN of the Amazon CloudWatch alarm",
"AlarmRoleArn": "ARN of the IAM role for AppConfig to monitor AlarmArn"
}
]
}
```
------
#### [ Windows ]
```
{
"ApplicationId": "The application ID",
"Id": "The environment ID",
"Name": "Name of the environment",
"State": "The state of the environment"
"Description": "Description of the environment",
"Monitors": [
{
"AlarmArn": "ARN of the Amazon CloudWatch alarm",
"AlarmRoleArn": "ARN of the IAM role for AppConfig to monitor AlarmArn"
}
]
}
```
------
#### [ PowerShell ]
```
ApplicationId : The application ID
ContentLength : Runtime of the command
Description : Description of the environment
HttpStatusCode : HTTP Status of the runtime
Id : The environment ID
Monitors : {ARN of the Amazon CloudWatch alarm, ARN of the IAM role for AppConfig to monitor AlarmArn}
Name : Name of the environment
Response Metadata : Runtime Metadata
State : State of the environment
```
------
Proceed to [Creating a configuration profile in AWS AppConfig](appconfig-creating-configuration-profile.md).
# Creating a configuration profile in AWS AppConfig
*Configuration data* is a collection of settings that influence the behavior of your application. A *configuration profile* includes, among other things, a URI that enables AWS AppConfig to locate your configuration data in its stored location and a configure type. AWS AppConfig supports the following types of configuration profiles:
+ **Feature flags**: You can use feature flags to enable or disable features within your applications or to configure different characteristics of your application features using flag attributes. AWS AppConfig stores feature flag configurations in the AWS AppConfig hosted configuration store in a feature flag format that contains data and metadata about your flags and the flag attributes. The URI for feature flag configurations is simply `hosted`.
+ **Freeform configurations**: A freeform configuration can store data in any of the following AWS services and Systems Manager tools:
+ AWS AppConfig hosted configuration store
+ Amazon Simple Storage Service
+ AWS CodePipeline
+ AWS Secrets Manager
+ AWS Systems Manager (SSM) Parameter Store
+ SSM Document Store
**Note**
If possible, we recommend hosting your configuration data in the AWS AppConfig hosted configuration store as it offers the most features and enhancements.
Here are some configuration data samples to help you better understand different types of configuration data and how they can be used in either a feature flag or free from configuration profile.
**Feature flag configuration data**
The following feature flag configuration data enables or disables mobile payments and default payments on a per-region basis.
------
#### [ JSON ]
```
{
"allow_mobile_payments": {
"enabled": false
},
"default_payments_per_region": {
"enabled": true
}
}
```
------
#### [ YAML ]
```
---
allow_mobile_payments:
enabled: false
default_payments_per_region:
enabled: true
```
------
**Operational configuration data**
The following freeform configuration data enforces limits on how an application processes requests.
------
#### [ JSON ]
```
{
"throttle-limits": {
"enabled": "true",
"throttles": [
{
"simultaneous_connections": 12
},
{
"tps_maximum": 5000
}
],
"limit-background-tasks": [
true
]
}
}
```
------
#### [ YAML ]
```
---
throttle-limits:
enabled: 'true'
throttles:
- simultaneous_connections: 12
- tps_maximum: 5000
limit-background-tasks:
- true
```
------
**Access control list configuration data**
The following access control list freeform configuration data specifies which users or groups can access an application.
------
#### [ JSON ]
```
{
"allow-list": {
"enabled": "true",
"cohorts": [
{
"internal_employees": true
},
{
"beta_group": false
},
{
"recent_new_customers": false
},
{
"user_name": "Jane_Doe"
},
{
"user_name": "John_Doe"
}
]
}
}
```
------
#### [ YAML ]
```
---
allow-list:
enabled: 'true'
cohorts:
- internal_employees: true
- beta_group: false
- recent_new_customers: false
- user_name: Jane_Doe
- user_name: Ashok_Kumar
```
------
**Topics**
+ [
# Creating a feature flag configuration profile in AWS AppConfig
](appconfig-creating-configuration-and-profile-feature-flags.md)
+ [
# Creating a free form configuration profile in AWS AppConfig
](appconfig-free-form-configurations-creating.md)
+ [
# Creating a configuration profile for non-native data sources
](appconfig-creating-configuration-profile-other-data-sources.md)
# Creating a feature flag configuration profile in AWS AppConfig
Creating a feature flag configuration profile
You can use feature flags to enable or disable features within your applications or to configure different characteristics of your application features using flag attributes. AWS AppConfig stores feature flag configurations in the AWS AppConfig hosted configuration store in a feature flag format that contains data and metadata about your flags and the flag attributes.
**Note**
When you create a feature flag configuration profile, you can create a basic feature flag as part of the configuration profile workflow. AWS AppConfig also supports multi-variant feature flags. *Multi-variant feature flags* enable you to define a set of possible flag values to return for a request. When requesting a flag configured with variants, your application provides context that AWS AppConfig evaluates against a set of user-defined rules. Depending on the context specified in the request and the rules defined for the variant, AWS AppConfig returns different flag values to the application.
To create multi-variant feature flags, create a configuration profile first, and then edit any flags within the configuration profile to add variants. For more information, see [Creating multi-variant feature flags](appconfig-creating-multi-variant-feature-flags.md).
**Topics**
+ [
## Understanding feature flag attributes
](#appconfig-creating-configuration-profile-feature-flag-attributes)
+ [
# Creating a feature flag configuration profile (console)
](appconfig-creating-feature-flag-configuration-create-console.md)
+ [
# Creating a feature flag configuration profile (command line)
](appconfig-creating-feature-flag-configuration-commandline.md)
+ [
# Creating multi-variant feature flags
](appconfig-creating-multi-variant-feature-flags.md)
+ [
# Understanding the type reference for AWS.AppConfig.FeatureFlags
](appconfig-type-reference-feature-flags.md)
+ [
# Saving a previous feature flag version to a new version
](appconfig-creating-configuration-profile-feature-flags-editing-version.md)
## Understanding feature flag attributes
When you create a feature flag configuration profile—or create a new flag within an existing configuration profile—you can specify attributes and corresponding constraints for the flag. An attribute is a field that you associate with your feature flag to express properties related to your feature flag. Attributes are delivered to your application with your flag key and the `enable` or `disable` value of the flag.
Constraints ensure that any unexpected attribute values are not deployed to your application. The following image shows an example.
![\[Example of flag attributes for an AWS AppConfig feature flag\]](http://docs.aws.amazon.com/appconfig/latest/userguide/images/appconfig-flag-attributes.png)
**Note**
Note the following information about flag attributes.
For attribute names, the word "enabled" is reserved. You can't create a feature flag attribute called "enabled". There are no other reserved words.
The attributes of a feature flag are only included in the `GetLatestConfiguration` response if that flag is enabled.
Flag attribute keys for a given flag must be unique.
AWS AppConfig supports the following types of flag attributes and their corresponding constraints.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)
# Creating a feature flag configuration profile (console)
Use the following procedure to create an AWS AppConfig feature flag configuration profile by using the AWS AppConfig console. At the time you create the configuration profile, you can also create a basic feature flag.
**To create a configuration profile**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose an application you created in [Creating a namespace for your application in AWS AppConfig](appconfig-creating-namespace.md).
1. On the **Configuration profiles and feature flags** tab, choose **Create configuration**.
1. In the **Configuration options** section, choose **Feature flag**.
1. In the **Configuration profile** section, for **Configuration profile name**, enter a name.
1. (Optional) Expand **Description** and enter a description.
1. (Optional) Expand **Additional options** and complete the following, as necessary.
1. In the **Encryption** list, choose an AWS Key Management Service (AWS KMS) key from the list. This customer managed key enables you to encrypt new configuration data versions in the AWS AppConfig hosted configuration store. For more information about this key, see **AWS AppConfig supports customer manager keys** in [Security in AWS AppConfig](appconfig-security.md).
1. In the **Tags** section, choose **Add new tag**, and then specify a key and optional value.
1. Choose **Next**.
1. In the **Feature flag definition** section, for **Flag name**, enter a name.
1. For **Flag key** enter a flag identifier to distinguish flags within the same configuration profile. Flags within the same configuration profile can't have the same key. After the flag is created, you can edit the flag name, but not the flag key.
1. (Optional) Expand **Description** and enter information about this flag.
1. Select **This is a short-term flag** and optionally choose a date for when the flag should be disabled or deleted. AWS AppConfig does *not* disable the flag on the deprecation date.
1. (Optional) In the **Feature flag attributes** section, choose **Define attribute**. Attributes enable you to provide additional values within your flag. For more information about attributes and constraints, see [Understanding feature flag attributes](appconfig-creating-configuration-and-profile-feature-flags.md#appconfig-creating-configuration-profile-feature-flag-attributes).
1. For **Key**, specify a flag key and choose its type from the **Type** list. For information about the supported options for the **Value** and **Constraints** fields, see the previously referenced section about attributes.
1. Select **Required value** to specify whether an attribute value is required.
1. Choose **Define attribute** to add additional attributes.
1. In the **Feature flag value** section, choose **Enabled** to enable the flag. Use this same toggle to disable a flag when it reaches a specified deprecation date, if applicable.
1. Choose **Next**.
1. On the **Review and save** page, verify the details of the flag and then **Save and continue to deploy**.
Proceed to [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md).
# Creating a feature flag configuration profile (command line)
The following procedure describes how to use the AWS Command Line Interface (on Linux or Windows) or Tools for Windows PowerShell to create an AWS AppConfig feature flag configuration profile. At the time you create the configuration profile, you can also create a basic feature flag.
**To create a feature flag configuration**
1. Open the AWS CLI.
1. Create a feature flag configuration profile specifying its **Type** as `AWS.AppConfig.FeatureFlags`. The configuration profile must use `hosted` for the location URI.
------
#### [ Linux ]
```
aws appconfig create-configuration-profile \
--application-id APPLICATION_ID \
--name CONFIGURATION_PROFILE_NAME \
--location-uri hosted \
--type AWS.AppConfig.FeatureFlags
```
------
#### [ Windows ]
```
aws appconfig create-configuration-profile ^
--application-id APPLICATION_ID ^
--name CONFIGURATION_PROFILE_NAME ^
--location-uri hosted ^
--type AWS.AppConfig.FeatureFlags
```
------
#### [ PowerShell ]
```
New-APPCConfigurationProfile `
-Name CONFIGURATION_PROFILE_NAME `
-ApplicationId APPLICATION_ID `
-LocationUri hosted `
-Type AWS.AppConfig.FeatureFlags
```
------
1. Create your feature flag configuration data. Your data must be in a JSON format and conform to the `AWS.AppConfig.FeatureFlags` JSON schema. For more information about the schema, see [Understanding the type reference for AWS.AppConfig.FeatureFlags](appconfig-type-reference-feature-flags.md).
1. Use the `CreateHostedConfigurationVersion` API to save your feature flag configuration data to AWS AppConfig.
------
#### [ Linux ]
```
aws appconfig create-hosted-configuration-version \
--application-id APPLICATION_ID \
--configuration-profile-id CONFIGURATION_PROFILE_ID \
--content-type "application/json" \
--content file://path/to/feature_flag_configuration_data.json \
--cli-binary-format raw-in-base64-out
```
------
#### [ Windows ]
```
aws appconfig create-hosted-configuration-version ^
--application-id APPLICATION_ID ^
--configuration-profile-id CONFIGURATION_PROFILE_ID ^
--content-type "application/json" ^
--content file://path/to/feature_flag_configuration_data.json ^
--cli-binary-format raw-in-base64-out
```
------
#### [ PowerShell ]
```
New-APPCHostedConfigurationVersion `
-ApplicationId APPLICATION_ID `
-ConfigurationProfileId CONFIGURATION_PROFILE_ID `
-ContentType "application/json" `
-Content file://path/to/feature_flag_configuration_data.json
```
------
The command loads the content specified for the `Content` parameter from disk. The content must be similar to the following example.
```
{
"flags": {
"ui_refresh": {
"name": "UI Refresh"
}
},
"values": {
"ui_refresh": {
"enabled": false,
"attributeValues": {
"dark_mode_support": true
}
}
},
"version": "1"
}
```
The system returns information like the following.
------
#### [ Linux ]
```
{
"ApplicationId" : "ui_refresh",
"ConfigurationProfileId" : "UI Refresh",
"VersionNumber" : "1",
"ContentType" : "application/json"
}
```
------
#### [ Windows ]
```
{
"ApplicationId" : "ui_refresh",
"ConfigurationProfileId" : "UI Refresh",
"VersionNumber" : "1",
"ContentType" : "application/json"
}
```
------
#### [ PowerShell ]
```
ApplicationId : ui_refresh
ConfigurationProfileId : UI Refresh
VersionNumber : 1
ContentType : application/json
```
------
The `service_returned_content_file` contains your configuration data that includes some AWS AppConfig generated metadata.
**Note**
When you create the hosted configuration version, AWS AppConfig verifies that your data conforms to the `AWS.AppConfig.FeatureFlags` JSON schema. AWS AppConfig additionally validates that each feature flag attribute in your data satisfies the constraints you defined for those attributes.
# Creating multi-variant feature flags
Feature flag variants enable you to define a set of possible flag values to return for a request. You can also configure different statuses (enabled or disabled) for multi-variant flags. When requesting a flag configured with variants, your application provides context that AWS AppConfig evaluates against a set of user-defined rules. Depending on the context specified in the request and the rules defined for the variant, AWS AppConfig returns different flag values to the application.
The following screenshot shows an example of a feature flag with three user-defined variants and the default variant.
![\[An example screenshot of a feature flag with variants.\]](http://docs.aws.amazon.com/appconfig/latest/userguide/images/flag-variant-example.png)
**Topics**
+ [
# Understanding multi-variant feature flag concepts and common use cases
](appconfig-creating-multi-variant-feature-flags-concepts.md)
+ [
# Understanding multi-variant feature flag rules
](appconfig-creating-multi-variant-feature-flags-rules.md)
+ [
# Creating a multi-variant feature flag
](appconfig-creating-multi-variant-feature-flags-procedures.md)
# Understanding multi-variant feature flag concepts and common use cases
To help you better understand feature flag variants, this section explains flag variant concepts and common use cases.
**Concepts**
+ **Feature flag**: An AWS AppConfig configuration type used to control the behavior of a feature in an application. A flag has a status (enabled or disabled) and an optional set of attributes containing arbitrary string, numeric, boolean, or array values.
+ **Feature flag variant**: A specific combination of status and attribute values belonging to a feature flag. A feature flag may have multiple variants.
+ **Variant rule**: A user-defined expression used to select a feature flag variant. Each variant has its own rule that AWS AppConfig evaluates to determine whether to return it or not.
+ **Default variant**: A special variant that is returned when no other variant is selected. All multi-variant feature flags have a default variant.
Note, the default variant must be last in your ordering of variants, and it can't have rules associated with it. If it's not defined last, AWS AppConfig returns a `BadRequestException` when you try to create the multi-variant flag.
+ **Context**: User-defined keys and values passed to AWS AppConfig at configuration retrieval time. Context values are used during rule evaluation to select the feature flag variant to return.
**Note**
AWS AppConfig agent evaluates variant rules and determines which rule applies to the request based on the provided context. For more information about retrieving multi-varient feature flags, see [Retrieving basic and multi-variant feature flags](appconfig-integration-retrieving-feature-flags.md).
**Common use cases**
This section describes two common use cases for feature flag variants.
*User segmentation*
User segmentation is the process of dividing users based on certain attributes. As an example, you could use flag variants to expose a feature to some users but not others based on their user ID, geographic location, device type, or purchase frequency.
Using the example of purchase frequency, suppose your commerce application supports a feature to increase customer loyalty. You can use flag variants to configure different incentive types to be shown to a user based on when they last purchased something. A new user might be offered a small discount to encourage them to become a customer, whereas a repeat customer might be given a larger discount if they purchase something from a new category.
*Traffic splitting*
Traffic splitting is the process of selecting a random, but consistent, flag variant based on a context value you define. For example, you may want to perform an experiment where a small percentage of your users (identified by their user ID) sees a particular variant. Or, you may want to execute a gradual feature rollout where a feature is first exposed to 5% of your users, then 15%, then 40%, then 100%, while maintaining a consistent user experience throughout the rollout.
Using the experimentation example, you could use flag variants to test a new button style for the primary action on your application homepage to see if it drives more clicks. For your experiment, you could create a flag variant with a traffic splitting rule that selects 5% of users to see the new style, while the default variant indicates the users that should continue to see the existing style. If the experiment is successful, you can increase the percentage value, or even turn that variant into the default.
# Understanding multi-variant feature flag rules
When you create a feature flag variant, you specify a rule for it. Rules are expressions that take context values as input and produce a boolean result as output. For example, you could define a rule to select a flag variant for beta users, identified by their account ID, testing a user interface refresh. For this scenario, you do the following:
1. Create a new feature flag configuration profile called *UI Refresh*.
1. Create a new feature flag called *ui\$1refresh*.
1. Edit the feature flag after you create it to add variants.
1. Create and enable a new variant called *BetaUsers*.
1. Define a rule for *BetaUsers* that selects the variant if the account ID from the request context is in a list of account IDs approved to view the new beta experience.
1. Confirm that the default variant’s status is set to **Disabled**.
**Note**
Variants are evaluated as an ordered list based on the order they are defined in the console. The variant at the top of the list is evaluated first. If no rules match the supplied context, AWS AppConfig returns the Default variant.
When AWS AppConfig processes the feature flag request, it compares the supplied context, which includes the AccountID (for this example) to the BetaUsers variant first. If the context matches the rule for BetaUsers, AWS AppConfig returns the configuration data for the beta experience. If the context doesn’t include an account ID or if the account ID ends in anything other than 123, AWS AppConfig returns configuration data for the Default rule, which means the user views the current experience in production.
**Note**
For information about retrieving multi-variant feature flags, see [Retrieving basic and multi-variant feature flags](appconfig-integration-retrieving-feature-flags.md).
# Defining rules for multi-variant feature flags
A variant rule is an expression comprised of one or more operands and an operator. An operand is a specific value used during the evaluation of a rule. Operand values can be either static, such as a literal number or string, or variable, such as the value found in a context or the result of another expression. An operator, such as "greater than", is a test or action applied to its operands that produces a value. A variant rule expression must produce either a "true" or "false" to be valid.
**Operands**
****
| Type | Description | Example |
| --- | --- | --- |
| String | A sequence of UTF-8 characters, enclosed in double-quotes. | "apple", "Ḽơᶉëᶆ ȋṕšᶙṁ"
|
| Integer | A 64-bit integer value. | -7, 42
|
| Float | A 64-bit IEEE-754 floating-point value. | 3.14, 1.234e-5
|
| Timestamp | A specific moment in time as described by the [W3C note on date and time formats](https://www.w3.org/TR/NOTE-datetime). | 2012-03-04T05:06:07-08:00, 2024-01
|
| Boolean | A true or false value. | true, false
|
| Context value | A parameterized value in the form of \$1*key* that is retrieved from the context during rule evaluation. | $country, $userId
|
**Comparison operators**
****
| Operator | Description | Example |
| --- | --- | --- |
| eq | Determines whether a context value is equal to a given value. | (eq $state "Virginia")
|
| gt | Determines whether a context value is greater than a given value. | (gt $age 65)
|
| gte | Determines whether a context value is greater than or equal to a given value. | (gte $age 65)
|
| lt | Determines whether a context value is less than a given value. | (lt $age 65)
|
| lte | Determines whether a context value is less than or equal to a given value. | (lte $age 65)
|
**Logical operators**
****
| Operator | Description | Example |
| --- | --- | --- |
| and | Determines if both operands are true. | (and
(eq $state "Virginia")
(gt $age 65)
)
|
| or | Determines if at least one of the operands is true. | (or
(eq $state "Virginia")
(gt $age 65)
)
|
| not | Reverses the value of an expression. | (not (eq $state "Virginia"))
|
**Custom operators**
****
| Operator | Description | Example |
| --- | --- | --- |
| begins\$1with | Determines whether a context value begins with a given prefix. | (begins_with $state "A")
|
| ends\$1with | Determines whether a context value ends with a given prefix. | (ends_with $email "amazon.com")
|
| contains | Determines whether a context value contains a given substring. | (contains $promoCode "WIN")
|
| in | Determines whether a context value is contained within a list of constants. | (in $userId ["123", "456"])
|
| matches | Determines whether a context value matches a given regex pattern. | (matches in::$greeting pattern::"h.*y")
|
| exists | Determines whether any value was provided for a context key. | (exists key::"country")
|
| split | Evaluates to `true` for a given percentage of traffic based on a consistent hash of the provided context value(s). For a detailed explanation of how `split` works, see the next section in this topic, [Understanding the split operator](appconfig-creating-multi-variant-feature-flags-rules.md#appconfig-creating-multi-variant-feature-flags-rules-operators-split). Note that `seed` is an optional property. If you don't specify `seed`, the hash is *locally* consistent, meaning traffic will be split consistently for that flag, but other flags receiving the same context value may split traffic differently. If `seed` is provided, each unique value is guaranteed to split traffic consistently across feature flags, configuration profiles, and AWS accounts. | (split pct::10 by::$userId seed::"abc")
|
## Understanding the split operator
The following section describes how the `split` operator behaves when used in different scenarios. As a reminder, `split` evaluates to `true` for a given percentage of traffic based on a consistent hash of the provided context value. To understand this better, consider the following baseline scenario that uses split with two variants:
```
A: (split by::$uniqueId pct::20)
C:
```
As expected, providing a random set of `uniqueId` values produces a distribution that's approximately:
```
A: 20%
C: 80%
```
If you add a third variant, but use the same split percentage like so:
```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C:
```
You end up with the following distribution:
```
A: 20%
B: 0%
C: 80%
```
This potentially unexpected distribution happens because each variant rule is evaluated in order and the first match determines the returned variant. When rule A is evaluated, 20% of `uniqueId` values match it, so the first variant is returned. Next, rule B is evaluated. However, all of the `uniqueId` values that would have matched the second split statement were already matched by variant rule A, so no values match B. The default variant is returned instead.
Now consider a third example.
```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C:
```
As with the previous example, the first 20% of `uniqueId` values match rule A. For variant rule B, 25% of all `uniqueId` values would match, but most of those previously matched rule A. That leaves 5% of the total for variant B, with the remainder receiving variant C. The distribution would look like the following:
```
A: 20%
B: 5%
C: 75%
```
**Using the `seed` property**
You can use the `seed` property to ensure traffic is split consistently for a given context value irrespective of where the split operator is used. If you don't specify `seed`, the hash is *locally* consistent, meaning traffic will be split consistently for that flag, but other flags receiving the same context value may split traffic differently. If `seed` is provided, each unique value is guaranteed to split traffic consistently across feature flags, configuration profiles, and AWS accounts.
Typically, customers use the same `seed` value across variants within a flag when splitting traffic on the same context property. However, it may occasionally make sense to use a different seed value. Here is an example that uses different seeds for rules A and B:
```
A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C:
```
As before, 20% of the matching `uniqueId` values match rule A. That means 80% of values fall through and are tested against variant rule B. Because the seed is different, there is no correlation between the values that matched A and the values that match B. There are, however, only 80% as many `uniqueId` values to split with 25% of that number matching rule B and 75% not. That works out to the following distribution:
```
A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%)
C: 60%
```
# Creating a multi-variant feature flag
Use the procedures in this section to create variants of a feature flag.
**Before you begin**
Note the following important information.
+ You can create variants of existing feature flags by editing them. You can't create variants of a new feature flag *when you create a new configuration profile*. You must complete the workflow of creating the new configuration profile first. After you create the configuration profile, you can add variants to any flag within the configuration profile. For information about how to create a new configuration profile, see [Creating a feature flag configuration profile in AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md).
+ To retrieve feature flag variant data for Amazon EC2, Amazon ECS, and Amazon EKS compute platforms, you must use AWS AppConfig Agent version 2.0.4416 or later.
+ For performance reasons, AWS CLI and SDK calls to AWS AppConfig don't retrieve variant data. For more information about AWS AppConfig Agent, see [How to use AWS AppConfig Agent to retrieve configuration data](appconfig-agent-how-to-use.md).
+ When you create a feature flag variant, you specify a rule for it. Rules are expressions that take request context as input and produce a boolean result as output. Before you create variants, review the supported operands and operators for flag variant rules. You can create rules before you create variants. For more information, see [Understanding multi-variant feature flag rules](appconfig-creating-multi-variant-feature-flags-rules.md).
**Topics**
+ [
## Creating a multi-variant feature flag (console)
](#appconfig-creating-multi-variant-feature-flags-procedures-console)
+ [
## Creating a multi-variant feature flag (command line)
](#appconfig-creating-multi-variant-feature-flags-procedures-commandline)
## Creating a multi-variant feature flag (console)
The following procedure describes how to create a multi-variant feature flag for an existing configuration profile by using the AWS AppConfig console. You can also edit existing feature flags to create variants.
**To create a multi-variant feature flag**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose an application.
1. On the **Configuration profiles and feature flags** tab, choose an existing feature flag configuration profile.
1. In the **Flags** section, choose **Add new flag**.
1. In the **Feature flag definition** section, for **Flag name**, enter a name.
1. For **Flag key** enter a flag identifier to distinguish flags within the same configuration profile. Flags within the same configuration profile can't have the same key. After the flag is created, you can edit the flag name, but not the flag key.
1. (Optional) In the **Description** field, enter information about this flag.
1. In the **Variants** section, choose **Multi-variant flag**.
1. (Optional) In the **Feature flag attributes** section, choose **Define attribute**. Attributes enable you to provide additional values within your flag. For more information about attributes and constraints, see [Understanding feature flag attributes](appconfig-creating-configuration-and-profile-feature-flags.md#appconfig-creating-configuration-profile-feature-flag-attributes).
1. For **Key**, specify a flag key and choose its type from the **Type** list. For information about the supported options for the **Value** and **Constraints** fields, see the previously referenced section about attributes.
1. Select **Required value** to specify whether an attribute value is required.
1. Choose **Define attribute** to add additional attributes.
1. Choose **Apply** to save attribute changes.
1. In the **Feature flag variants** section, choose **Create variant**.
1. For **Variant name**, enter a name.
1. Use the **Enabled value** toggle to enable the variant.
1. In the **Rule** text box, enter a rule.
1. Use the **Create variant** > **Create variant above** or **Create variant below** options to create additional variants for this flag.
1. In the **Default variant** section, use the **Enabled value** toggle to enable the default variant. Optionally, provide values for attributes defined in step 10.
1. Choose **Apply**.
1. Verify the details of the flag and its variants and choose **Create flag**.
For information about deploying your new feature flag with variants, see [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md).
## Creating a multi-variant feature flag (command line)
The following procedure describes how to use the AWS Command Line Interface (on Linux or Windows) or Tools for Windows PowerShell to create a multi-variant feature flag for an existing configuration profile. You can also edit existing feature flags to create variants.
**Before you begin**
Complete the following tasks before you create a multi-variant feature flag by using the AWS CLI.
+ Create a feature flag configuration profile. For more information, see [Creating a feature flag configuration profile in AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md).
+ Update to the latest version of the AWS CLI. For more information, see [Install or update to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) in the *AWS Command Line Interface User Guide*.
**To create a multi-variant feature flag**
1. Create a configuration file on your local machine that specifies the details of the multi-variant flag you want to create. Save the file with a `.json` file extension. The file must adhere to the [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON schema. The schema contents of your configuration file will be similar to the following.
```
{
"flags": {
"FLAG_NAME": {
"attributes": {
"ATTRIBUTE_NAME": {
"constraints": {
"type": "CONSTRAINT_TYPE"
}
}
},
"description": "FLAG_DESCRIPTION",
"name": "VARIANT_NAME"
}
},
"values": {
"VARIANT_VALUE_NAME": {
"_variants": [
{
"attributeValues": {
"ATTRIBUTE_NAME": BOOLEAN
},
"enabled": BOOLEAN,
"name": "VARIANT_NAME",
"rule": "VARIANT_RULE"
},
{
"attributeValues": {
"ATTRIBUTE_NAME": BOOLEAN
},
"enabled": BOOLEAN,
"name": "VARIANT_NAME",
"rule": "VARIANT_RULE"
},
{
"attributeValues": {
"ATTRIBUTE_NAME": BOOLEAN
},
"enabled": BOOLEAN,
"name": "VARIANT_NAME",
"rule": "VARIANT_RULE"
},
{
"attributeValues": {
"ATTRIBUTE_NAME": BOOLEAN
},
"enabled": BOOLEAN,
"name": "VARIANT_NAME",
"rule": "VARIANT_RULE"
}
]
}
},
"version": "VERSION_NUMBER"
}
```
Here is an example with three variants and the default variant.
```
{
"flags": {
"ui_refresh": {
"attributes": {
"dark_mode_support": {
"constraints": {
"type": "boolean"
}
}
},
"description": "A release flag used to release a new UI",
"name": "UI Refresh"
}
},
"values": {
"ui_refresh": {
"_variants": [
{
"attributeValues": {
"dark_mode_support": true
},
"enabled": true,
"name": "QA",
"rule": "(ends_with $email \"qa-testers.mycompany.com\")"
},
{
"attributeValues": {
"dark_mode_support": true
},
"enabled": true,
"name": "Beta Testers",
"rule": "(exists key::\"opted_in_to_beta\")"
},
{
"attributeValues": {
"dark_mode_support": false
},
"enabled": true,
"name": "Sample Population",
"rule": "(split pct::10 by::$email)"
},
{
"attributeValues": {
"dark_mode_support": false
},
"enabled": false,
"name": "Default Variant"
}
]
}
},
"version": "1"
}
```
1. Use the `CreateHostedConfigurationVersion` API to save your feature flag configuration data to AWS AppConfig.
------
#### [ Linux ]
```
aws appconfig create-hosted-configuration-version \
--application-id APPLICATION_ID \
--configuration-profile-id CONFIGURATION_PROFILE_ID \
--content-type "application/json" \
--content file://path/to/feature_flag_configuration_data.json \
--cli-binary-format raw-in-base64-out \
outfile
```
------
#### [ Windows ]
```
aws appconfig create-hosted-configuration-version ^
--application-id APPLICATION_ID ^
--configuration-profile-id CONFIGURATION_PROFILE_ID ^
--content-type "application/json" ^
--content file://path/to/feature_flag_configuration_data.json ^
--cli-binary-format raw-in-base64-out ^
outfile
```
------
#### [ PowerShell ]
```
New-APPCHostedConfigurationVersion `
-ApplicationId APPLICATION_ID `
-ConfigurationProfileId CONFIGURATION_PROFILE_ID `
-ContentType "application/json" `
-Content file://path/to/feature_flag_configuration_data.json `
-Raw
```
------
The `service_returned_content_file` contains your configuration data that includes some AWS AppConfig generated metadata.
**Note**
When you create the hosted configuration version, AWS AppConfig verifies that your data conforms to the [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON schema. AWS AppConfig additionally validates that each feature flag attribute in your data satisfies the constraints you defined for those attributes.
# Understanding the type reference for AWS.AppConfig.FeatureFlags
Use the `AWS.AppConfig.FeatureFlags` JSON schema as a reference to create your feature flag configuration data.
```
{
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions": {
"flagSetDefinition": {
"type": "object",
"properties": {
"version": {
"$ref": "#/definitions/flagSchemaVersions"
},
"flags": {
"$ref": "#/definitions/flagDefinitions"
},
"values": {
"$ref": "#/definitions/flagValues"
}
},
"required": ["version"],
"additionalProperties": false
},
"flagDefinitions": {
"type": "object",
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/flagDefinition"
}
},
"additionalProperties": false
},
"flagDefinition": {
"type": "object",
"properties": {
"name": {
"$ref": "#/definitions/customerDefinedName"
},
"description": {
"$ref": "#/definitions/customerDefinedDescription"
},
"_createdAt": {
"type": "string"
},
"_updatedAt": {
"type": "string"
},
"_deprecation": {
"type": "object",
"properties": {
"status": {
"type": "string",
"enum": ["planned"]
},
"date": {
"type": "string",
"format": "date"
}
},
"additionalProperties": false
},
"attributes": {
"$ref": "#/definitions/attributeDefinitions"
}
},
"additionalProperties": false
},
"attributeDefinitions": {
"type": "object",
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/attributeDefinition"
}
},
"maxProperties": 25,
"additionalProperties": false
},
"attributeDefinition": {
"type": "object",
"properties": {
"description": {
"$ref": "#/definitions/customerDefinedDescription"
},
"constraints": {
"oneOf": [
{ "$ref": "#/definitions/numberConstraints" },
{ "$ref": "#/definitions/stringConstraints" },
{ "$ref": "#/definitions/arrayConstraints" },
{ "$ref": "#/definitions/boolConstraints" }
]
}
},
"additionalProperties": false
},
"flagValues": {
"type": "object",
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/flagValue"
}
},
"additionalProperties": false
},
"flagValue": {
"type": "object",
"properties": {
"enabled": {
"type": "boolean"
},
"_createdAt": {
"type": "string"
},
"_updatedAt": {
"type": "string"
},
"_variants": {
"type": "array",
"maxLength": 32,
"items": {
"$ref": "#/definitions/variant"
}
}
},
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/attributeValue",
"maxProperties": 25
}
},
"additionalProperties": false
},
"attributeValue": {
"oneOf": [
{ "type": "string", "maxLength": 1024 },
{ "type": "number" },
{ "type": "boolean" },
{
"type": "array",
"oneOf": [
{
"items": {
"type": "string",
"maxLength": 1024
}
},
{
"items": {
"type": "number"
}
}
]
}
],
"additionalProperties": false
},
"stringConstraints": {
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": ["string"]
},
"required": {
"type": "boolean"
},
"pattern": {
"type": "string",
"maxLength": 1024
},
"enum": {
"type": "array",
"maxLength": 100,
"items": {
"oneOf": [
{
"type": "string",
"maxLength": 1024
},
{
"type": "integer"
}
]
}
}
},
"required": ["type"],
"not": {
"required": ["pattern", "enum"]
},
"additionalProperties": false
},
"numberConstraints": {
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": ["number"]
},
"required": {
"type": "boolean"
},
"minimum": {
"type": "integer"
},
"maximum": {
"type": "integer"
}
},
"required": ["type"],
"additionalProperties": false
},
"arrayConstraints": {
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": ["array"]
},
"required": {
"type": "boolean"
},
"elements": {
"$ref": "#/definitions/elementConstraints"
}
},
"required": ["type"],
"additionalProperties": false
},
"boolConstraints": {
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": ["boolean"]
},
"required": {
"type": "boolean"
}
},
"required": ["type"],
"additionalProperties": false
},
"elementConstraints": {
"oneOf": [
{ "$ref": "#/definitions/numberConstraints" },
{ "$ref": "#/definitions/stringConstraints" }
]
},
"variant": {
"type": "object",
"properties": {
"enabled": {
"type": "boolean"
},
"name": {
"$ref": "#/definitions/customerDefinedName"
},
"rule": {
"type": "string",
"maxLength": 16384
},
"attributeValues": {
"type": "object",
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/attributeValue"
}
},
"maxProperties": 25,
"additionalProperties": false
}
},
"required": ["name", "enabled"],
"additionalProperties": false
},
"customerDefinedName": {
"type": "string",
"pattern": "^[^\\n]{1,64}$"
},
"customerDefinedDescription": {
"type": "string",
"maxLength": 1024
},
"flagSchemaVersions": {
"type": "string",
"enum": ["1"]
}
},
"type": "object",
"$ref": "#/definitions/flagSetDefinition",
"additionalProperties": false
}
```
**Important**
To retrieve feature flag configuration data, your application must call the `GetLatestConfiguration` API. You can't retrieve feature flag configuration data by calling `GetConfiguration`, which is deprecated. For more information, see [GetLatestConfiguration](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_GetLatestConfiguration.html) in the *AWS AppConfig API Reference*.
When your application calls [GetLatestConfiguration](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_GetLatestConfiguration.html) and receives a newly deployed configuration, the information that defines your feature flags and attributes is removed. The simplified JSON contains a map of keys that match each of the flag keys you specified. The simplified JSON also contains mapped values of `true` or `false` for the `enabled` attribute. If a flag sets `enabled` to `true`, any attributes of the flag will be present as well. The following JSON schema describes the format of the JSON output.
```
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/attributeValuesMap"
}
},
"additionalProperties": false,
"definitions": {
"attributeValuesMap": {
"type": "object",
"properties": {
"enabled": {
"type": "boolean"
}
},
"required": ["enabled"],
"patternProperties": {
"^[a-z][a-zA-Z\\d_-]{0,63}$": {
"$ref": "#/definitions/attributeValue"
}
},
"maxProperties": 25,
"additionalProperties": false
},
"attributeValue": {
"oneOf": [
{ "type": "string","maxLength": 1024 },
{ "type": "number" },
{ "type": "boolean" },
{
"type": "array",
"oneOf": [
{
"items": {
"oneOf": [
{
"type": "string",
"maxLength": 1024
}
]
}
},
{
"items": {
"oneOf": [
{
"type": "number"
}
]
}
}
]
}
],
"additionalProperties": false
}
}
}
```
# Saving a previous feature flag version to a new version
When you update a feature flag, AWS AppConfig automatically saves your changes to a new version. If you want to use a previous feature flag version, you must copy it to a draft version and then save it. You can't edit and save changes to a previous flag version without saving it to a new version.
**To edit a previous feature flag version and save it to a new version**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose the application with the feature flag you want to edit and save to a new version.
1. On the **Configuration profiles and feature flags** tab, choose the configuration profile with the feature flag you want to edit and save to a new version.
1. On the **Feature flags** tab, use the **Version** list to choose the version you want to edit and save to a new version.
1. Choose **Copy to draft version**.
1. In the **Version label** field, enter a new label (optional, but recommended).
1. In the **Version description** field, enter a new description (optional, but recommended).
1. Choose **Save version**.
1. Choose **Start deployment** to deploy the new version.
# Creating a free form configuration profile in AWS AppConfig
Creating a free form configuration profile
*Configuration data* is a collection of settings that influence the behavior of your application. A *configuration profile* includes, among other things, a URI that enables AWS AppConfig to locate your configuration data in its stored location and a configure type. With freeform configuration profiles, you can store your data in the AWS AppConfig hosted configuration store or any of the following AWS services and Systems Manager tools:
****
| Location | Supported file types |
| --- | --- |
| AWS AppConfig hosted configuration store | YAML, JSON, and text if added using the AWS Management Console. Any file type if added using the AWS AppConfig [CreateHostedConfigurationVersion](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API action. |
| [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) | Any |
| [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) | Pipeline (as defined by the service) |
| [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) | Secret (as defined by the service) |
| [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) | Standard and secure string parameters (as defined by Parameter Store) |
| [AWS Systems Manager document store (SSM documents)](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) | YAML, JSON, text |
A configuration profile can also include optional validators to ensure your configuration data is syntactically and semantically correct. AWS AppConfig performs a check using the validators when you start a deployment. If any errors are detected, the deployment stops before making any changes to the targets of the configuration.
**Note**
If possible, we recommend hosting your configuration data in the AWS AppConfig hosted configuration store as it offers the most features and enhancements.
For freeform configurations stored in the AWS AppConfig hosted configuration store or SSM documents, you can create the freeform configuration by using the Systems Manager console at the time you create a configuration profile. The process is described later in this topic.
For freeform configurations stored in Parameter Store, Secrets Manager, or Amazon S3, you must create the parameter, secret, or object first and store it in the relevant configuration store. After you store the configuration data, use the procedure in this topic to create the configuration profile.
**Topics**
+ [
# Understanding validators
](appconfig-creating-configuration-and-profile-validators.md)
+ [
# Understanding configuration store quotas and limitations
](appconfig-creating-configuration-and-profile-quotas.md)
+ [
# Understanding the AWS AppConfig hosted configuration store
](appconfig-creating-configuration-and-profile-about-hosted-store.md)
+ [
# Understanding configurations stored in Amazon S3
](appconfig-creating-configuration-and-profile-S3-source.md)
+ [
# Creating an AWS AppConfig freeform configuration profile (console)
](appconfig-creating-free-form-configuration-and-profile-create-console.md)
+ [
# Creating an AWS AppConfig freeform configuration profile (command line)
](appconfig-creating-free-form-configuration-and-profile-create-commandline.md)
# Understanding validators
When you create a configuration profile, you have the option to specify up to two validators. A validator ensures that your configuration data is syntactically and semantically correct. If you plan to use a validator, you must create it before you create the configuration profile. AWS AppConfig supports the following types of validators:
+ **AWS Lambda functions**: Supported for feature flags and free form configurations.
+ **JSON Schema**: Supported for free form configurations. (AWS AppConfig automatically validates feature flags against a JSON Schema.)
**Topics**
+ [
## AWS Lambda function validators
](#appconfig-creating-configuration-and-profile-validators-lambda)
+ [
## JSON Schema validators
](#appconfig-creating-configuration-and-profile-validators-json-schema)
## AWS Lambda function validators
Lambda function validators must be configured with the following event schema. AWS AppConfig uses this schema to invoke the Lambda function. The content is a base64-encoded string, and the URI is a string.
```
{
"applicationId": "The application ID of the configuration profile being validated",
"configurationProfileId": "The ID of the configuration profile being validated",
"configurationVersion": "The version of the configuration profile being validated",
"content": "Base64EncodedByteString",
"uri": "The configuration uri"
}
```
AWS AppConfig verifies that the Lambda `X-Amz-Function-Error` header is set in the response. Lambda sets this header if the function throws an exception. For more information about `X-Amz-Function-Error`, see [Error Handling and Automatic Retries in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/retries-on-errors.html) in the *AWS Lambda Developer Guide*.
Here is a simple example of a Lambda response code for a successful validation.
```
import json
def handler(event, context):
#Add your validation logic here
print("We passed!")
```
Here is a simple example of a Lambda response code for an unsuccessful validation.
```
def handler(event, context):
#Add your validation logic here
raise Exception("Failure!")
```
Here is another example that validates only if the configuration parameter is a prime number.
```
function isPrime(value) {
if (value < 2) {
return false;
}
for (i = 2; i < value; i++) {
if (value % i === 0) {
return false;
}
}
return true;
}
exports.handler = async function(event, context) {
console.log('EVENT: ' + JSON.stringify(event, null, 2));
const input = parseInt(Buffer.from(event.content, 'base64').toString('ascii'));
const prime = isPrime(input);
console.log('RESULT: ' + input + (prime ? ' is' : ' is not') + ' prime');
if (!prime) {
throw input + "is not prime";
}
}
```
AWS AppConfig calls your validation Lambda when calling the `StartDeployment` and `ValidateConfigurationActivity` API operations. You must provide `appconfig.amazonaws.com` permissions to invoke your Lambda. For more information, see [Granting Function Access to AWS Services](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke). AWS AppConfig limits the validation Lambda run time to 15 seconds, including start-up latency.
## JSON Schema validators
If you create a configuration in an SSM document, then you must specify or create a JSON Schema for that configuration. A JSON Schema defines the allowable properties for each application configuration setting. The JSON Schema functions like a set of rules to ensure that new or updated configuration settings conform to the best practices required by your application. Here is an example.
```
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "$id$",
"description": "BasicFeatureToggle-1",
"type": "object",
"additionalProperties": false,
"patternProperties": {
"[^\\s]+$": {
"type": "boolean"
}
},
"minProperties": 1
}
```
When you create a configuration from an SSM document, the system automatically verifies that the configuration conforms to the schema requirements. If it doesn't, AWS AppConfig returns a validation error.
**Important**
Note the following important information about JSON Schema validators:
Configuration data stored in SSM documents must validate against an associated JSON Schema before you can add the configuration to the system. SSM parameters do not require a validation method, but we recommend that you create a validation check for new or updated SSM parameter configurations by using AWS Lambda.
A configuration in an SSM document uses the `ApplicationConfiguration` document type. The corresponding JSON Schema, uses the `ApplicationConfigurationSchema` document type.
AWS AppConfig supports JSON Schema version 4.X for inline schema. If your application configuration requires a different version of JSON Schema, then you must create a Lambda validator.
# Understanding configuration store quotas and limitations
Configuration stores supported by AWS AppConfig have the following quotas and limitations.
****
| | AWS AppConfig hosted configuration store | Amazon S3 | Systems Manager Parameter Store | AWS Secrets Manager | Systems Manager Document store | AWS CodePipeline |
| --- | --- | --- | --- | --- | --- | --- |
| **Configuration size limit** | 2 MB default, 4 MB maximum | 2 MB Enforced by AWS AppConfig, not S3 | 4 KB (free tier) / 8 KB (advanced parameters) | 64 KB | 64 KB | 2 MBEnforced by AWS AppConfig, not CodePipeline |
| **Resource storage limit** | 1 GB | Unlimited | 10,000 parameters (free tier) / 100,000 parameters (advanced parameters) | 500,000 | 500 documents | Limited by the number of configuration profiles per application (100 profiles per application) |
| **Server-side encryption** | Yes | [SSE-S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html), [SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) | Yes | Yes | No | Yes |
| **CloudFormation support** | Yes | Not for creating or updating data | Yes | Yes | No | Yes |
| **Pricing** | Free | See [Amazon S3 pricing](https://aws.amazon.com//s3/pricing/) | See [AWS Systems Manager pricing](https://aws.amazon.com//systems-manager/pricing/) | See [AWS Secrets Manager pricing](https://aws.amazon.com//secrets-manager/pricing/) | Free | See [AWS CodePipeline pricing](https://aws.amazon.com//codepipeline/pricing/) |
# Understanding the AWS AppConfig hosted configuration store
AWS AppConfig includes an internal or hosted configuration store. Configurations must be 2 MB or smaller. The AWS AppConfig hosted configuration store provides the following benefits over other configuration store options.
+ You don't need to set up and configure other services such as Amazon Simple Storage Service (Amazon S3) or Parameter Store.
+ You don't need to configure AWS Identity and Access Management (IAM) permissions to use the configuration store.
+ You can store configurations in YAML, JSON, or as text documents.
+ There is no cost to use the store.
+ You can create a configuration and add it to the store when you create a configuration profile.
# Understanding configurations stored in Amazon S3
You can store configurations in an Amazon Simple Storage Service (Amazon S3) bucket. When you create the configuration profile, you specify the URI to a single S3 object in a bucket. You also specify the Amazon Resource Name (ARN) of an AWS Identity and Access Management (IAM) role that gives AWS AppConfig permission to get the object. Before you create a configuration profile for an Amazon S3 object, be aware of the following restrictions.
****
| Restriction | Details |
| --- | --- |
| Size | Configurations stored as S3 objects can be a maximum of 1 MB in size. |
| Object encryption | A configuration profile can target SSE-S3 and SSE-KMS encrypted objects. |
| Storage classes | AWS AppConfig supports the following S3 storage classes: `STANDARD`, `INTELLIGENT_TIERING`, `REDUCED_REDUNDANCY`, `STANDARD_IA`, and `ONEZONE_IA`. The following classes are not supported: All S3 Glacier classes (`GLACIER` and `DEEP_ARCHIVE`). |
| Versioning | AWS AppConfig requires that the S3 object use versioning. |
## Configuring permissions for a configuration stored as an Amazon S3 object
When you create a configuration profile for a configuration stored as an S3 object, you must specify an ARN for an IAM role that gives AWS AppConfig permission to get the object. The role must include the following permissions.
Permissions to access the S3 object
+ s3:GetObject
+ s3:GetObjectVersion
Permissions to list S3 buckets
s3:ListAllMyBuckets
Permissions to access the S3 bucket where the object is stored
+ s3:GetBucketLocation
+ s3:GetBucketVersioning
+ s3:ListBucket
+ s3:ListBucketVersions
Complete the following procedure to create a role that enables AWS AppConfig to get a configuration stored in an S3 object.
**Creating the IAM Policy for Accessing an S3 Object**
Use the following procedure to create an IAM policy that enables AWS AppConfig to get a configuration stored in an S3 object.
**To create an IAM policy for accessing an S3 object**
1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**, and then choose **Create policy**.
1. On the **Create policy** page, choose the **JSON** tab.
1. Update the following sample policy with information about your S3 bucket and configuration object. Then paste the policy into the text field on the **JSON** tab. Replace the *placeholder values* with your own information.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/my-configurations/my-configuration.json"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetBucketVersioning",
"s3:ListBucketVersions",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
1. Choose **Review policy**.
1. On the **Review policy** page, type a name in the **Name** box, and then type a description.
1. Choose **Create policy**. The system returns you to the **Roles** page.
**Creating the IAM Role for Accessing an S3 Object**
Use the following procedure to create an IAM role that enables AWS AppConfig to get a configuration stored in an S3 object.
**To create an IAM role for accessing an Amazon S3 object**
1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Roles**, and then choose **Create role**.
1. On the **Select type of trusted entity** section, choose **AWS service**.
1. In the **Choose a use case** section, under **Common use cases**, choose **EC2**, and then choose **Next: Permissions**.
1. On the **Attach permissions policy** page, in the search box, enter the name of the policy you created in the previous procedure.
1. Choose the policy and then choose **Next: Tags**.
1. On the **Add tags (optional)** page, enter a key and an optional value, and then choose **Next: Review**.
1. On the **Review** page, type a name in the **Role name** field, and then type a description.
1. Choose **Create role**. The system returns you to the **Roles** page.
1. On the **Roles** page, choose the role you just created to open the **Summary** page. Note the **Role Name** and **Role ARN**. You will specify the role ARN when you create the configuration profile later in this topic.
**Creating a Trust Relationship**
Use the following procedure to configure the role you just created to trust AWS AppConfig.
**To add a trust relationship**
1. In the **Summary** page for the role you just created, choose the **Trust Relationships** tab, and then choose **Edit Trust Relationship**.
1. Delete `"ec2.amazonaws.com"` and add `"appconfig.amazonaws.com"`, as shown in the following example.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appconfig.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Choose **Update Trust Policy**.
# Creating an AWS AppConfig freeform configuration profile (console)
Use the following procedure to create an AWS AppConfig freeform configuration profile and (optionally) a freeform-configuration by using the AWS Systems Manager console.
**To create a freeform configuration profile**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/).
1. In the navigation pane, choose **Applications**, and then choose an application you created in [Creating a namespace for your application in AWS AppConfig](appconfig-creating-namespace.md).
1. Choose the **Configuration profiles and feature flags** tab, and then choose **Create configuration**.
1. In the **Configuration options** section, choose **Freeform configuration**.
1. For **Configuration profile name**, enter a name for the configuration profile.
1. (Optional) Expand **Description** and enter a description.
1. (Optional) Expand **Additional options** and complete the following, as necessary.
1. In the **Associate extensions** section, choose an extension from the list.
1. In the **Tags** section, choose **Add new tag**, and then specify a key and optional value.
1. Choose **Next**.
1. On the **Specify configuration data** page, in the **Configuration definition** section, choose an option.
1. Complete the fields for the option you selected, as described in the following table.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-free-form-configuration-and-profile-create-console.html)
1. In the **Service role** section, choose **New service role** to have AWS AppConfig create the IAM role that provides access to the configuration data. AWS AppConfig automatically populates the **Role name** field based on the name you entered earlier. Or, choose **Existing service role**. Choose the role by using the **Role ARN** list.
1. Optionally, on the **Add validators** page, choose either **JSON Schema** or **AWS Lambda**. If you choose **JSON Schema**, enter the JSON Schema in the field. If you choose **AWS Lambda**, choose the function Amazon Resource Name (ARN) and the version from the list.
**Important**
Configuration data stored in SSM documents must validate against an associated JSON Schema before you can add the configuration to the system. SSM parameters do not require a validation method, but we recommend that you create a validation check for new or updated SSM parameter configurations by using AWS Lambda.
1. Choose **Next**.
1. On the **Review and save** page, choose **Save and continue to deploy**.
**Important**
If you created a configuration profile for AWS CodePipeline, then you must create a pipeline in CodePipeline that specifies AWS AppConfig as the *deploy provider*. You don't need to perform [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md). However, you must configure a client to receive application configuration updates as described in [Retrieving configuration data without AWS AppConfig Agent](about-data-plane.md). For information about creating a pipeline that specifies AWS AppConfig as the deploy provider, see [Tutorial: Create a Pipeline that Uses AWS AppConfig as a Deployment Provider](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-AppConfig.html) in the *AWS CodePipeline User Guide*.
Proceed to [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md).
# Creating an AWS AppConfig freeform configuration profile (command line)
The following procedure describes how to use the AWS CLI (on Linux or Windows) or AWS Tools for PowerShell to create an AWS AppConfig freeform configuration profile. If you prefer, you can use AWS CloudShell to run the commands listed below. For more information, see [What is AWS CloudShell?](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html) in the *AWS CloudShell User Guide*.
**Note**
For freeform configurations hosted in the AWS AppConfig hosted configuration store, you specify `hosted` for the location URI.
**To create a configuration profile by using the AWS CLI**
1. Open the AWS CLI.
1. Run the following command to create a freeform configuration profile.
------
#### [ Linux ]
```
aws appconfig create-configuration-profile \
--application-id APPLICATION_ID \
--name NAME \
--description CONFIGURATION_PROFILE_DESCRIPTION \
--location-uri CONFIGURATION_URI or hosted \
--retrieval-role-arn IAM_ROLE_ARN \
--tags TAGS \
--validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA"
```
------
#### [ Windows ]
```
aws appconfig create-configuration-profile ^
--application-id APPLICATION_ID ^
--name NAME ^
--description CONFIGURATION_PROFILE_DESCRIPTION ^
--location-uri CONFIGURATION_URI or hosted ^
--retrieval-role-arn IAM_ROLE_ARN ^
--tags TAGS ^
--validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA"
```
------
#### [ PowerShell ]
```
New-APPCConfigurationProfile `
-Name NAME `
-ApplicationId APPLICATION_ID `
-Description CONFIGURATION_PROFILE_DESCRIPTION `
-LocationUri CONFIGURATION_URI or hosted `
-RetrievalRoleArn IAM_ROLE_ARN `
-Tag TAGS `
-Validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA"
```
------
**Important**
Note the following important information.
If you created a configuration profile for AWS CodePipeline, then you must create a pipeline in CodePipeline that specifies AWS AppConfig as the *deploy provider*. You don't need to perform [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md). However, you must configure a client to receive application configuration updates as described in [Retrieving configuration data without AWS AppConfig Agent](about-data-plane.md). For information about creating a pipeline that specifies AWS AppConfig as the deploy provider, see [Tutorial: Create a Pipeline that Uses AWS AppConfig as a Deployment Provider](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-AppConfig.html) in the *AWS CodePipeline User Guide*.
If you created a configuration in the AWS AppConfig hosted configuration store, you can create new versions of the configuration by using the [CreateHostedConfigurationVersion](https://docs.aws.amazon.com//appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API operations. To view AWS CLI details and sample commands for this API operation, see [create-hosted-configuration-version](https://docs.aws.amazon.com/cli/latest/reference/appconfig/create-hosted-configuration-version.html) in the *AWS CLI Command Reference*.
Proceed to [Deploying feature flags and configuration data in AWS AppConfig](deploying-feature-flags.md).
# Creating a configuration profile for non-native data sources
AWS AppConfig supports deploying configuration data from most any data store. Natively, AWS AppConfig supports deploying configuration data stored in the following services:
+ The AWS AppConfig hosted configuration store
+ Amazon S3
+ AWS Secrets Manager
+ AWS Systems Manager Parameter Store
+ Systems Manager Document Store
+ AWS CodePipeline
If your configuration data is stored in a location not natively supported by AWS AppConfig, you can create an [AWS AppConfig extension](https://docs.aws.amazon.com/appconfig/latest/userguide/working-with-appconfig-extensions.html) to retrieve your data from its source. For example, by using an AWS 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 AWS 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 AWS AppConfig.
Creating a configuration profile for data sources not natively supported in AWS AppConfig involves the following processes or actions:
1. Create an [AWS Lambda function](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) that fetches data from your data source. As long as a Lambda function can access the data source, your AWS AppConfig extension will be able to retrieve the data.
1. Create a custom AWS AppConfig extension that invokes your Lambda function. For more information, see [Walkthrough: Creating custom AWS AppConfig extensions](working-with-appconfig-extensions-creating-custom.md).
1. Create an AWS AppConfig free-form configuration profile. Specifically, create a configuration profile that uses the **AWS 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 AWS AppConfig hosted configuration store. For more information, see [Creating a free form configuration profile in AWS AppConfig](appconfig-free-form-configurations-creating.md).
1. 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 AWS AppConfig extension](working-with-appconfig-extensions-creating-custom-association.md).
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. AWS 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 AWS AppConfig from legacy and home-grown configuration services
If you've started using AWS 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 AWS AppConfig. You can build an extension that pulls data out of your legacy system and deploys it through AWS AppConfig. Using AWS AppConfig in this way provides you with all of the safety guardrail controls and benefits while still using your legacy data stores.