Hey 👋🏽
There's no other field where it's so common to have "a small side-project" like in the software industry.
Even though it's possible to build things as quickly as ever before due to cloud providers, tools, platforms, and AI, many indie founders (and also large enterprises) tend to fall into the same trap: they tend to build features that users do not actually need or want.
The more time you invest in a task, the more you may come to appreciate it. Even if you attempt to disregard it, your mind will inevitably recall the sunk costs associated with the time (and maybe money) spent.
User feedback and validation are missing. However, feature flags and A/B testing can solve this problem.
As you might already know: CloudWatch Evidently was exactly built for this. Sadly, AWS deprecated this great feature back in October with a sundown in late 2025.
But don't worry: there's a comparable feature available for years. And it's part of AWS AppConfig!
And that's what this issue will be about.
Let's dive in! 🪄
Introduction to AWS AppConfig
AWS AppConfig, a feature of AWS Systems Manager, enables you to adjust application behavior in production environments quickly and securely without full code deployments. 🏗️
It also supports Feature flags, which allow for the gradual release of new software increments, so you can test and validate features before you roll them out to the whole user base or even before you fully build them. This also allows you to adopt trunk-based development, avoiding large and complex merges and allowing pre-release code to be safely rolled out to production.
As the feature flags are remotely controlled through AppConfig, you can enable and disable them post-deployment without rolling back the code.
Feature Flags as the Main Building Block
At the core of AppConfig are feature flags. These flags are mostly used to control the visibility of a feature in an application
This is done by hiding the new feature behind an if-else statement that can be activated at any point after it is already deployed. This if-else query can also be targeted to a specific user segment, device type, or any other context you define.
With this approach, you can gradually increase the percentage of users that receive the new feature.
Why Feature Flags Really Enable Trunk-Based Development
Before we start with our AppConfig deep dive, let’s look at some software development history. This will help us get a clear picture of why feature flags are so important.
There are different approaches to iterate and deploy software. These include feature branch and trunk-based development.
Each of them is a distinct approach to managing code integration and deployment. How do they differ?
- Long-Living Branch Development: Isolates feature development in separate branches, reducing incomplete features’ impact on the main codebase. This can lead to significant merge conflicts and a slower feedback loop.
- Trunk-Based Development: Developers commit small, frequent changes directly to the main branch, using short-lived feature branches that merge back quickly. Reduces merge conflicts but requires a disciplined team to maintain the fast pace.
These are the two most common approaches to software development that every experienced developer is familiar with.
But there’s a third approach that is gaining popularity in recent years:
Feature Flag Development: Enhances trunk-based development by allowing incomplete features to be merged into the main branch, controlled via feature flags. Parts of a feature can be implemented but remain hidden from users reducing the risk of deploying unfinished features. However, it adds complexity in managing the flags.
When we look at the three approaches, feature flag-based development is the most flexible and agile.
Benefits of Using AppConfig
Using a feature-flag-based, iterative approach in software development isn’t just a nice gimmick or trend. It’s a game-changer.
Let’s have a look at some of the benefits that come with feature flags
- 🛡️ Reduced Production Deployment Risks: Feature flags minimize the risk of deploying new releases by allowing incomplete features to remain hidden, preventing issues from impacting users and avoiding deployment delays.
- 🎯 Granular Rollout of New Features: Features can be enabled or disabled without redeploying the application, allowing for controlled rollouts to specific user percentages via remote services.
- 🌑 Minimized Impact: “Dark Launches” allow testing new features on a small user segment, evaluating performance in real-world conditions without affecting all users.
- ⏪ Rollbacks without Code Deployments: Gradual rollouts enable quick adjustments based on metrics, allowing for instant reversion to previous states without needing a full deployment rollback.
Overall, feature flags enhance agility and reduce bug risks compared to long-living feature branches.
How AppConfig Works
What do we need to set up so that we can actually use AWS AppConfig inside of our application?
- Identifying Our Configuration Values And Feature Flags - This is an ongoing process because your application will change over time, and configuration values and flags will come and go.
- Creating an Application Namespace - AppConfig uses the concept of namespaces, which are simply organizational structures, like folders.
- Creating Environments - An AppConfig configuration is always linked to an environment, such as
production or preview. This also refers to a logical grouping of targets, like your backend, web frontend, or mobile app. It can also be more detailed, down to sub-components. - Creating a Configuration Profile - A configuration profile holds your configuration data and a profile type. AppConfig offers two profile types: freeform and feature flags. Configuration profiles can also include validators to prevent developers and other stakeholders from providing invalid values.
- Deploying our Configurations - To apply your configuration, you need to create a deployment. A deployment links to an application, profile, configuration version, and environment. The deployment also requires selecting a deployment strategy, which includes the rules for how the configuration will be rolled out to the environment.
- Retrieving the Configuration Within Our Application - When your configuration changes take effect, you need to fetch it from within your application.
- (Optionally) Attaching CloudWatch Alarms to Our Environment - With AppConfig, we can automatically monitor the deployment process of our configurations using CloudWatch by attaching one or more alarms. If an alarm is triggered during deployment, the configuration will automatically roll back. This is a great feature and is easy to set up; we just need to add the ARNs of the alarms and a dedicated role that can describe the alarms.
The AWS AppConfig Agent Lambda Extension
Before we really jump into the hands-on part, let’s discuss one further point that is important when using AppConfig with AWS Lambda.
With Lambda, we have an almost unlimited number of execution environments because AWS manages when new instances start and stop. At first glance, this means we need to make many calls to the AppConfig service, and of course, we are billed for each call.
Fortunately, there’s the AWS AppConfig Agent Lambda Extension, which we can use right away to help us easily reduce the number of calls we make.
This layer will internally cache our configurations fetched from AppConfig and will automatically keep the cache updated without any action needed from us. This means it doesn’t matter how often we fetch the configuration in our code, as these calls don’t actually result in calls to AppConfig.
Bonus: Environments Can Be Attached to CloudWatch Alarms for Automated Rollbacks
Yes, you read that right. You can easily set up automated rollbacks using CloudWatch Alarms. This is done by attaching a CloudWatch Role (needs to have the cloudwatch:DescribeAlarm action allowed) ARN and one or several CloudWatch Alarm ARNs to the environment.
If one Alarm is triggered, AppConfig will immediately stop the rollout and roll back to the previous configuration.
Summary
After working with AppConfig for a while, we don't really know why AWS didn't just add the Analytics part of Evidently to CloudWatch as an extension for AppConfig.
AppConfig has so many similar features and it works almost identically (even though some things are not quite as fancy as in Evidently), but having two services that do want to do the same thing doesn't sound right.
TL;DR: AppConfig is great and you should use it! 😊
Don't forget to read the full post which also includes every step on how to set up AppConfig with a simpel feature flag - code included! 🤖
