Safe Deployment of Application Configuration Settings With AWS AppConfig

A few years ago, we identified a need for an internal service to enable us to make configuration changes faster than traditional code deployments, but with the same operational scrutiny as code changes. So, we built a tool to address this need and now most teams across AWS, Amazon.com, Kindle and Alexa use this configuration deployment system to perform changes dynamically in seconds, rather than minutes. The ability to deploy only configuration changes, separate from code, means we do not have to restart the applications or services that use the configuration, and changes take effect immediately. This service is used thousands of times a day inside of Amazon and AWS.

A common question we receive from customers is how they can operate like us, and so we decided to take this internal tooling and externalize it for our customers to use. Today, we announced AWS AppConfig, a feature of AWS Systems Manager. AWS AppConfig enables customers to quickly rollout application configuration changes, independent of code, across any size application hosted on Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, and serverless applications and functions.

Configurations can be created and updated using the API or console, and you can have the changes validated prior to deployment using either a defined schema template or an AWS Lambda function. AWS AppConfig also includes automated safety controls to monitor the deployment of the configuration changes, and to rollback to the previous configuration if issues occur. Deployments of configuration updates are available immediately to your running application, which uses a simple API to periodically poll and retrieve the latest available configuration.

Managing Application Configuration Settings with AWS AppConfig
Using AWS AppConfig to create and manage configuration settings for applications is a simple process. First I create an Application, and then for that application I define one or more Environments, Configuration profiles, and Deployment strategies. An environment represents a logical deployment group, such as Beta or Production environments, or it might be subcomponents of an application, for example Web, Mobile, and Back-end components. I can configure Amazon CloudWatch alarms for each environment, which will be monitored by AWS AppConfig and trigger a rollback if the alarm fires during deployment. A configuration profile defines the source of the configuration data to deploy, together with optional Validators that will ensure your configuration data is correct prior to deployment. A deployment strategy defines how the deployment is to be performed.

To get started, I go to the AWS Systems Manager dashboard and select AppConfig from the navigation panel. Clicking Create configuration data takes me to a page where I specify a name for my application, together with an optional description, and I can also apply tags to the application if I wish.

Once I have created my application, I am taken to a page with Environments and Configuration Profiles tabs. Let’s start with creating an environment to target my production environment for the application. With the Environments tab selected, I click Create environment. On the resulting page, I give my environment a name, and then, under Monitors, select Enable rollback on Cloudwatch alarms. I then supply an IAM role that enables AWS AppConfig to monitor the selected alarms during deployments, and click Add. Details about the permissions needed for the role can be found here.

Next, I set up a configuration profile. Returning to the details view for my application, I select the Configuration Profiles tab, and click Create configuration profile. The first details needed are a name for the configuration and a service role that AWS AppConfig will assume to access the configuration. I can choose to create a new role, or choose an existing role.

Clicking Next, I then select the source of the configuration data that will be deployed. I can choose from a Systems Manager Document, or a parameter in Parameter Store. For this walk-through, I’m going to select a parameter that when set to true, will enable the functionality related to that feature for users of this sample application.

Next, I can optionally add one or more validators to the profile, so that AWS AppConfig can verify that when I attempt to deploy an updated setting, the value is correct and not going to cause an application failure. Here, I am going to use a JSON schema, so I am using a syntactic check. If I want to run code to perform validation, a semantic check, I would configure a Lambda function. Once I have entered the schema, I click Create configuration profile to complete the process.

One more task remains, to configure a Deployment strategy that will govern the rollout. I can do this from the AWS AppConfig dashboard by selecting the Deployment Strategies tab and clicking Create deployment strategy. Here I have configured a strategy that will cause AWS AppConfig to deploy to one-fifth (20%) of my instances hosting the application at a time. Monitoring will be performed during deployments and a ‘bake’ time which occurs when all deployments complete. During deployments and the bake time, if anything goes wrong, the alarms associated with the environment will trigger and a rollback will occur. You can read more about the options you can set for a strategy here. Clicking Create deployment strategy completes this step and makes the strategy available for selection during deployment.

With an environment and a configuration profile configured for my application, and a deployment strategy in place – I can add more of each – I am ready to start a deployment. Navigating to my configuration profile, I click Start deployment.

I select the environment I want to deploy to, the version of the parameter that contains the configuration change I want to deploy, the deployment strategy, and I can enter an optional description. The parameter version I selected is 2. Version 1 of the parameter had the value { “featureX”: false }. Version 2 of the parameter has the value { “featureX”: true }, enabling the functionality associated with that feature for my users, as soon as it is deployed.

Clicking Start deployment starts the validation and deployment process. I know that the value of version 2 of the parameter is valid, so deployment will proceed after validation. As soon as the deployment becomes available to a target, in its next poll for configuration, the target will receive the updated configuration and the new features associated with featureX will be safely enabled for my users!

In this post I presented a very simple experience based around a feature toggle, enabling me to be able to instantly turn on features that might require a timely rollout (for example a new product launch or announcement). AWS AppConfig can be used for many different use cases, here are a couple more examples to consider:

• A/B Testing: perform experiments on which versions of an application earns more revenue.
• User Membership: allow Premium Subscribers to access an application’s paid content.

Note that the targets receiving deployments from AWS AppConfig do not need to be configured with the Systems Manager Agent, or have an AWS Identity and Access Management (IAM) instance profile, which is required by other Systems Manager capabilities. This enables me to use AWS AppConfig with managed and unmanaged instances. You can read more about AWS AppConfig in the User Guide, and pricing information is available here. AWS AppConfig is available now to customers in all commercial AWS Regions.