-
aws-lambda-handler-cookbook
This repository provides a working, deployable, open source-based, serverless service template with an AWS Lambda function and AWS CDK Python code with all the best practices and a complete CI/CD pipeline.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
In this post, I’ll guide you through deploying AWS AppConfig configurations using the AWS Cloud Development Kit (CDK) and the new AppConfig L2 constructs (higher abstraction). We will deploy a JSON configuration for feature flags’ usage for serverless and non-serverless applications alike with Python CDK code. This blog post was originally published on my website, “Ran The Builder.” Quick AppConfig Introduction AWS AppConfig is a self-managed service that stores plain TEXT/YAML/JSON configuration to be consumed by multiple clients. Let’s look at AppConfig’s advantages: FedRAMP High certified Fully Serverless Out-of-the-box support for schema validations that run before a configuration update. Out-of-the-box integration with AWS CloudWatch alarms triggers an automatic configuration revert if a configuration update fails your AWS Lambda functions. Read more about it here. You can define configuration deployment strategies. Deployment strategies define how and when to change a configuration. Read more about it here. It provides a single API that fetches configuration. If you’ve read my previous AppConfig posts, you know that I use AWS Lambda Powertools feature flags utility to fetch and evaluate AppConfig configurations. Our Goal We aim to deploy a JSON freeform configuration that we can use with the AWS Lambda Powertools feature flags utility. The construct I present here will deploy a JSON configuration to AppConfig as a freeform configuration with a zero wait time deployment strategy. For production accounts, you should use a canary deployment profile and configure JSON validations and a CloudWatch alarm to trigger an automatic rollback in case of service errors during configuration deployment. If you want to learn about best practices for feature flags and how to use, build, and test feature flags, check out my two posts about them: AWS Lambda Cookbook — Part 6 — Configuration & Feature Flags Best Practices Manage Your AWS Lambda Feature Flags Like a Boss Let’s go ahead and write some code. Python Dependencies To consume the new L2 construct, which contains better abstractions, add the following statements to your poetry file: Be aware that we are using an alpha construct, which might break or contain bugs. Use it at your discretion. However, after testing it, I can confirm it works as expected at the time of writing, and it’s already part of the AWS Lambda Handler Cookbook project. Configuration Construct Let’s go over my new construct, which uses L2 higher abstractions constructs, thus reducing the overall effort to define AppConfig configurations: Our construct requires several input parameters: id_ (str): The scoped construct ID. It must be unique. Environment (str): AppConfig environment name to create. service_name (str): AppConfig application name to create. configuration_name (str): AppConfig configuration name to create. configuration_str (str): AppConfig configuration content to create In lines 33–40, we create the AppConfig application; in line 40, we set the removal policy to destroy. You will have a similar approach applied to all resources. In lines 41–48, we define the AWS AppConfig environment. In lines 51–61, we define the AppConfig deployment strategy. I chose an immediate deployment (zero minutes for bake and deployment times), but you should use the canary deployment options or define your own for production workloads. Read the docs here. In lines 63–75, we define the configuration to deploy and connect all the resources. Notice how I chose line 69, the freeform type. You must use freeform for usage with the Powertools feature flags utility. In line 68, we provide the configuration string we got as a construct input parameter. Line 75 is a workaround until the removal policy is set and exposed correctly (see the link to the CDK issue). Bottom line: The new L2 constructs are a welcome edition as they reduce the total amount of code and the overall complexity, but I suggest that you create your own construct that wraps these L2 constructs into one or use the example I provided here. For other information and connecting advanced features such as JSON validators, extensions, and CloudWatch alarm, refer to the official documentation below: https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_appconfig_alpha.html