When to use Lambda env variable and App Config ?

I would say you can use all three.

App Config > Environment > Resource Files

App Config can be changed without re-deploying

Java already takes care of overriding resource files with environment variables if I am correct. For App Config I am not sure if Java supports that out of the box

Changing environment variables and configuration file requires redeploying your function. For this reason I would use environment variables for things that are different between different deployment, for instance, DB connection string. You will have a different connection string in prod and test so you will use an env var to point to the right one.

For things that can change I would use App Config or SSM Parameter store or Secrets manager. I would use environment variables to store the name of the config for the same reason above.

The following documentation does a great deep dive into the different options of getting parameters: https://aws.amazon.com/blogs/compute/choosing-the-right-solution-for-aws-lambda-external-parameters/

But, using the examples you shared of environment variables:

• Environment variables are good for parameter values that don’t need to be updated regularly
• Can be accessed within the code so do not take downstream calls to retrieve
• The downside is that the variables are set during the functions creation and/or update
• The other downside is that values can’t be accessed in a central location by multiple functions/services.

For java resource files, I’m only vaguely familiar with their usage as it applies to Lambda (mainly since I’m more familiar with the usage of our AWS based options which cover many of the use cases I’ve encountered), so I wouldn’t be able to speak on that much. I don’t want to make many assumptions on Java resource files with Lambda, but those may be a bit less dynamic from my understanding since you have to change it in the file -> then re-deploy it to the Lambda function.

With environment variables, you just need the change in the Lambda function configuration and that can be done in the console if you want a quick change outside of your infrastructure as code or bypass your CI/CD pipelines deployment quickly if an issue arises with the parameter at use. A bit outside of the question but thought I’d mention that to be as complete as I could when I think about it a bit more (hopefully that helps). A recommendation I could make is go with an AWS service first if it’s able to accomplish the task you need…but if a Java resource file does it better or an AWS service can’t accomplish what a Java resource file can for your use case, then use the Java resource file. It’s going to be specific to your use case and one size doesn’t fit all, so we have some variety we offer on different use cases that different services are developed for taking care of.

As far as AppConfig, I recommend checking out that first link I sent since it has some good advantages with certain scenarios. For example they have something called Feature Flags, https://aws.amazon.com/blogs/mt/introducing-aws-appconfig-feature-flags-in-preview/ and https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/, that are pretty unique; I’ll pose a small example of its usage.

Imagine you have a store online and want to test a new feature without having the feature pushed through your entire CI/CD pipeline on the go-live date. You can have the feature lying in wait before the go-live date already implemented and deployed, but simply “not-turned-on”/displayed to an end-user so to speak. Then, you can use AppConfig to turn on (toggle) the feature without the time it takes to deploy through the entire CI/CD pipeline. Now, if the feature doesn’t go so well in the production environment, no need to wait for a rollback of the system through the CI/CD pipeline…just use AppConfig to undo the change quickly. The links I shared on AppConfig pose real world examples that are very detailed.

I think it really depends on your use case, but there are also other options to consider that the first link I shared covers, and the bottom of that first link shares a summary of each which I’ll post here:

• For general-purpose low-cost parameters, use AWS Systems Manager Parameter Store.

• For single function, small parameters, use Lambda environment variables.

• For secret values that require automatic rotation, use AWS Secrets Manager.

• When you need a managed cache, use the AWS AppConfig Lambda extension or Lambda Powertools for Python/Java.

• For items larger than 400 KB, use Amazon S3.

• When access frequency is high, and low latency is required, use Amazon DynamoDB.