AWS AppConfig (Freeform Configuration)

If you have ever run your code on Lambda, EC2 or Containers (ECS, EKS) in AWS, there is a high chance it depended on configurations. Some configurations could be present remotely in SSM Parameter Store or Secrets Manager while others set as environment variables at the time of deployment. Or in the worst case, they were shipped with the code in a configuration file.

Imagine that you want to change these configurations because that's what happens in the realm of software. No software is perfect and final. The same goes for configurations. They need to change because your customer support team received an email from an angry customer complaining that his requests are being throttled or because your 3rd party integration requires you to fetch data from a different URL or maybe even because Pluto was declared a planet of our solar system once again. Happy planet, poor you! Reason? Your app is down and business is losing money with every passing minute.

Depending on where the configurations are stored, here is what you'll find yourself doing:

• Shipped with code
   Change the code, create PR, let the CI pass, let the CD do its thing and if the deployment is successful, your code is there but after ten eternities
• Set as environment variables in AWS Lambda
   Ask for break-glass / admin access to AWS Account to setup AWS CLI or login to AWS Management Console, manually change the environment variables and wait for new lambda containers to spin up. The issue might reappear if you forget to make the changes in IaC or CloudFormation Template before the next deployment happens overriding your manual changes.
• Stored in parameter store or secrets manager
   You change the configuration values but then look for ways to make the code read the updated values. You wish that you had written a bad code that wastes time fetching these configurations every time you need those. If you fetch these configurations only during initialization, you will be looking for ways to stop your existing running containers and spin up new ones so that the updated values are fetched

But all of this can be avoided. AWS AppConfig to the rescue. You can define those configurations using AppConfig's freeform configuration profile. The configurations can be sourced by different providers:

• AppConfig hosted configuration in the form of Text, JSON, or YAML
• S3 object
• System Manager document
• System Manager parameter
• Secrets Manager secret
• AWS CodePipeline tied to Github, BitBucket Pipelines, and AWS CodeCommit

The configurations can optionally be validated before deployment to ensure that there are no semantic or syntactic errors. The deployment happens at runtime without any build process or service interruptions. The deployment rate can be controlled across a set of targets to minimize the risk. Once the deployment is done, AppConfig can optionally monitor CloudWatch alarms to be able to revert the deployment in case the alarms are triggered.

The updated configurations reach the targets based on the configurable polling interval and the deployment strategy. The targets need to install the AppConfig extension/agent for that purpose. Not only it communicates with AppConfig in the background but it also caches the configurations locally and updates it when required.

After verifying that the updated configurations have solved the problem in just a few seconds or a couple of minutes at maximum, you can freely let the customers know, close your laptop, and celebrate the hours you saved by spending that time with your family or by giving Pluto a very warm welcome.