Configuration management

Maintain an accurate and complete record of all your cloud workloads, their relationships, and configuration changes over time.

To ensure that you have reliable and scalable systems, it is important to manage application configurations, particularly as complexity increases.

Start

Most software teams already organize their application source code by separating out executable code from application configuration data. When writing application code, a software engineer will determine what values in the application may change over time and separate those values out into a distinct configuration file. As the application development continues, an engineer may simply update a variable in configuration data without the need to recompile the code.

However, separating configuration data from code does not go far enough. While this separation does help teams to move faster, the next step is to separate the deployment of configuration data from the deployment of code. An example of this includes using AWS Systems Manager Parameter Store for managing application logging configuration data, including the file paths on the Amazon EC2 instance where the AWS Systems Manager Agent (SSM Agent) should read log data from the Amazon CloudWatch log group, and the Amazon S3 bucket to which a copy of those logs should be sent. Most significantly, you can also include a parameter to store the current verbosity level that the application should use to write to the logs. In this way, your application can typically run with an ERROR level of logging, keeping the volumes of data generated (and associated storage and processing overheads) low. Yet, in response to certain error conditions, or using a manual update of the parameter, you can set a more verbose level, helping support any subsequent investigations.

The first step beyond this initial separation of configuration from code is to change the application to continually poll configuration data at runtime. The application reads config data and adjusts accordingly, without a restart. If there is a change to the configuration data, the application will read that change and adjust its behavior in near real-time. An example of this includes putting parameters such as throttling limits into configuration data. Once a DevOps engineer wants to adjust throttling limits to react to the current conditions of the application, they can simply update only the configuration data variable. The app will read that new data, and, without restarting, adjust throttling limits.

Advance

While it’s important to manage configurations of applications, the OS and other software on the instances also need to be managed to ensure the successful running of the workload. AWS Systems Manager State Manager provides a mechanism to do this immediately or to a schedule, with support for a variety of playbook formats, including Ansible playbooks, Chef recipes, or Managed Object Format (MOF) files. The tasks you can carry out in this way vary, but examples include updating the AWS paravirtual (PV) drivers on Microsoft Windows EC2 instances, forcing changes to logging configurations, installing packages, and updating dependencies.

As you begin to manage your application, infrastructure as code (IaC) and configuration management becomes even more important. Building secure, reliable, and efficient images for your EC2 instances is an important task. EC2 Image Builder provides a scalable means of creating your golden images. Once you’ve created your new Amazon Machine Image (AMI), your various application environments also need to be instructed to make use of it. As you create your first AWS CloudFormation template to describe you application environment, you might initially hardcode definitions for EC2 instances or Auto Scaling groups. Later, you might improve things by moving such configurations to a parameter that still needs to be manually updated. Finally, you might consider using AWS Systems Manager Automation actions to automate the distribution of golden images across teams.

Excel

Using AWS AppConfig, you can make updates to configuration data in a validated and controlled way. AWS AppConfig lets you configure, validate, and deploy your application configuration data. You can choose among multiple sources of configuration data, including AWS Systems Manager Parameter Store, Amazon S3, or within AppConfig itself. Using AWS AppConfig validators, configuration data can be syntactically or semantically validated prior to deployment (thus, avoiding typos that could cause outages). Additionally, configuration data can be rolled out gradually or immediately, allowing teams to limit the blast radius of changes. And finally, if bad configuration changes are pushed out, tripping a CloudWatch alarm, AWS AppConfig can automatically roll back the latest configuration and restore the previous version.

There are three questions you should ask yourself when considering how to manage your application’s dynamic configuration:

An approach known as continuous configuration provides the means of adjustment of software behavior that allows teams to move faster and safer. Instead of changing software with new release through a CI/CD pipeline, changes are made only to configuration data, which can happen immediately and can be scoped to limit its impact. AWS AppConfig has a capability called feature flags that provides one kind of continuous configuration. Engineers will develop a new feature, but hide it behind a feature flag so that end users cannot yet access it. Engineers can update the value of the flag to allow access to the new feature for a limited set of users. Over time, the flag can be adjusted to allow for more users to access the feature. Teams can measure operational impact as more users access the new functionality. This technique helps limit blast radius for operational or reputational impact, and if the new feature results in negative consequences, the feature can be immediately rolled back with a simple configuration change.