AWS AppConfig is a service designed to enable users to manage application configurations dynamically, securely, and with minimal risk. It allows for the deployment of configuration changes across applications hosted in various environments, including EC2 instances, containers, and serverless functions, without requiring a redeployment of the applications themselves. This capability is critical for ensuring high availability and operational stability in modern cloud environments.

How does AppConfig Work?

AWS AppConfig operates through several core components and follows a structured workflow to manage configurations:

1. Configuration Profiles:

   • These profiles define the configuration data that you want to deploy. The data can be stored in various formats such as JSON, YAML, or plain text, and can reside in AWS Systems Manager Parameter Store, AWS Secrets Manager, or Amazon S3.

   • Profiles are versioned to keep track of changes and ensure rollback capabilities if necessary.

2. Environments:

   • An environment in AWS AppConfig represents a logical deployment stage for configurations, such as development, testing, or production.

   • Environments can have validators attached to them, which are used to check the configuration data against specific criteria or constraints before deployment. Validators can be implemented using JSON schema or Lambda functions.

3. Deployment Strategies:

   • AWS AppConfig supports various deployment strategies to control how configurations are rolled out. These strategies include time-based canary, linear deployments, and immediate deployments.

   • Canary deployments start with a small percentage of the fleet receiving the new configuration and gradually increase the percentage after monitoring for issues.

   • Linear deployments incrementally increase the number of targets over a defined period, allowing gradual exposure.

   • Immediate deployments apply the configuration to all targets simultaneously.

4. Deployment:

   • Deployments are initiated by specifying the configuration profile, environment, and deployment strategy. AWS AppConfig then orchestrates the deployment process according to the specified strategy.

   • The service monitors the deployment in real-time, allowing for automatic rollback if issues are detected based on predefined alarms or metrics.

5. Safety and Validation:

   • AWS AppConfig integrates with Amazon CloudWatch to monitor metrics and alarms that can trigger rollbacks if anomalies are detected.

   • The system supports validators to ensure that configurations meet the necessary criteria before deployment. These validators help prevent deploying incorrect or potentially harmful configurations.

6. Integration with AWS Systems Manager:

   • AWS AppConfig is tightly integrated with AWS Systems Manager, enabling it to leverage Systems Manager capabilities such as Parameter Store and Run Command.

   • This integration allows configurations to be securely stored and accessed, ensuring that sensitive data is managed correctly and in compliance with organizational policies.

Technical Workflow

1. Creating and Storing Configuration Data:

   • Configuration data is created and stored in a secure repository like AWS Systems Manager Parameter Store, AWS Secrets Manager, or Amazon S3. This data can be structured in various formats depending on the application's needs.

2. Defining Configuration Profiles and Environments:

   • Users define configuration profiles that point to the configuration data. Each profile is associated with an environment, representing different stages of the deployment lifecycle.

3. Setting Up Validators:

   • Validators are configured to ensure that the configuration data is correct and adheres to the expected schema or logic. These can be simple JSON schema validators or custom logic implemented in AWS Lambda functions.

4. Choosing a Deployment Strategy:

   • A deployment strategy is selected based on how the organization wants to manage the rollout. For instance, a canary deployment might be chosen for critical changes to minimize risk.

5. Initiating Deployment:

   • The deployment process is initiated by specifying the configuration profile, environment, and deployment strategy. AWS AppConfig manages the rollout, applying the configuration changes according to the chosen strategy.

6. Monitoring and Rollback:

   • During deployment, AWS AppConfig continuously monitors the application’s health using Amazon CloudWatch. If any predefined alarms are triggered, indicating issues, AWS AppConfig can automatically rollback the changes to the previous stable configuration.

N.B: I have previously written extensively about AWS AppConfig and you can find it here. This lab is meant to provide a practical aspect to AppConfig and give you a hands-on experience of this service. I recommend you read it first before following through with this lab.

Working AppConfig generally requires three steps:

• Setting up AppConfig: This is where you configure the environment, application, configuration profiles and select your deployment strategies. This can be done through the console or using any IaC tool - Terraform, CloudFormation, CDK etc.

• Integrating your application: This is the second step where you actually integrate your application with AppConfig. This can either be done via APIs/SDKs or AWS Lambda extensions. When using APIs, your application will initially call the "StartConfigurationSession" API method which initializes the session and returns a token. Your app will then  use that token in making subsequent "GetLatestConfiguration" API calls which returns configurations to the app.  Now it is important to note that AppConfig uses a Pull-based method for updating configurations. That is to say that when configurations are updated in AppConfig, they are not automatically pushed to your app. Your application will actually have to periodically invoke the "GetLatestConfiguration" method in order to get updated configurations. 

  With Lambda extensions, this process is simplified. The extension maintains a local cache of the configuration data. If the data isn't in the cache, the extension calls AWS AppConfig to get the configuration data. Upon receiving the configuration from the service, the extension stores it in the local cache and passes it to the Lambda function. AWS AppConfig Agent Lambda extension periodically checks for updates to your configuration data in the background. To access its configuration data, your function calls the AWS AppConfig extension at an HTTP endpoint running on localhost:2772. 

• Deploying your configuration: This is the final step where by you deploy your configuration updates to AppConfig.This is as easy as selecting your config updates, choosing your deployment strategy and executing the deployment.

Step 1: Setting Up AppConfig

On the AppConfig Console, click on "Create application"

Give Your application a name and click on create. You can associate extensions with your application. Extensions that you associate with your application will be triggered when configuration updates occur. They include EventBridge, SQS and SNS. We will be skipping that now.

Now that our application has been created, let'sgo on to create an environment.

Click on the "Environments" tab and click on "Create Environment"

We can associate monitors with our environments. Monitors require an IAM role and a CloudWatch alarm. If the alarm gets trigered during the deployment, the monitor notifies AppConfig and the deployment subsequently gets rolled back. We will implement this at a later time. You can also see that there is an options for extensions. Extensions can either be added at an application level or at the environment level.

Click on "Create Environment".

Let us now go back to the application that we just created and click on the "Confiuration profile and feature flags" tab.

Notice that I chose the freeform configuration option. Freeform configuration allows you more flexibility that the feature flag option.

Associate a name with your configuration profile and click on next.

AppConfig offers a variety of options for hosting your configuration data. We will be hosting our data in AppConfig itself.

Paste the following into the content box below:

{ 
  "clientList": ["user1", "user2", "user3"]
}

You can add validators to ensure that your configuration updates stick to a specific schema. This helps to ensure that we don't accidentally input wrong configuration vaules. Validators can either be JSON schema or a custom validator using a lambda function.

Our validator is JSON and consists of the following code:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "description": "My Config",
  "type": "object",
  "properties": {
    "clientList": {
      "type": "array"
    }
  },
  "minProperties": 1,
  "required": [
    "clientList"
  ]
}

Click on Next > Save and deploy later. 

It should look like this after you're done.

You can create several versions of your configuration profile.

Our application should now look like this:

Click on the Test-env environment and click on Start deployment

For simplicity sake, I am choosing the AllAtOnce deployment strategy. This is not a good strategy for production workloads.

Read more about AppConfig deployment strategies here.

Click on "Start deployment"

Step 2: Integrating Your Application

We will be using lambda extensions for this excercise.

Go to the lambda console and Create a function.

Once the function is created, click on layers and add the AppConfig extension.

Now let us update our lambda execution policy with the permissions necessary to invoke AppConfig.

Click on Configuration > Permissions > "Role name"

On the new page that opens up, click on "Add Permissions" > "Create inline policy"

Paste the following into the JSON box:

{
        "Version": "2012-10-17",
        "Statement": [
                {
                        "Sid": "VisualEditor0",
                        "Effect": "Allow",
                        "Action": "appconfig:GetConfiguration",
                        "Resource": [
                                "arn:aws:appconfig:*:ACCOUNTID:application/*/environment/*",
                                "arn:aws:appconfig:*:ACCOUNTID:application/*/configurationprofile/*"
                        ]
                },
                {
                        "Sid": "VisualEditor1",
                        "Effect": "Allow",
                        "Action": [
                                "appconfig:ListConfigurationProfiles",
                                "appconfig:GetConfiguration"
                        ],
                        "Resource": "arn:aws:appconfig:*:ACCOUNTID:application/*"
                },
                {
                        "Sid": "VisualEditor2",
                        "Effect": "Allow",
                        "Action": [
                                "appconfig:GetLatestConfiguration",
                                "appconfig:StartConfigurationSession"
                        ],
                        "Resource": "arn:aws:appconfig:*:ACCOUNTID:application/*/environment/*/configuration/*"
                }
        ]
}

Be sure to replace "ACCOUNTID" with your AWS account ID.

Now in the code section of your lambda function, paste the following python code:

import urllib.request
                

def lambda_handler(event, context):
    url = f'http://localhost:2772/applications/PracticalCloud/environments/Test-env/configurations/ClientAllowList'
    config = urllib.request.urlopen(url).read()
    return config

From the code, you can notice that we are making a url request to the http endpoint on localhost:2772

Deploy the code and test.

As you can see from the execution results, my lambda function is able to retrieve my configuration data from AppConfig.

By now, you should possess solid understanding of how to manage and access configuration settings in your application using AppConfig. You've gained experience with creating key-value pairs, storing them securely in AppConfig and retrieving them within your lambda code.

Happy Clouding !!!