Dealing with Environment Variables in bref + AWS CDK

[h-kenji1]

Hey, guys!

I'm building a Laravel Serverless API using Bref and AWS CDK. One of the main challenges I'm facing is how to properly handle environment variables, specifically the credentials for RDS Aurora.

Setup:
In my AWS CDK project, I am deploying a Lambda function, an RDS Aurora instance, and some additional resources. The Aurora credentials are automatically stored in AWS Systems Manager when deploying.

The Problem:
I need to set the Aurora credentials inside the Lambda environment variables (or inside the .env file in source code). However, since the Lambda function and the Aurora instance are deployed together, there seems to be no way to automatically set these credentials during deployment.

The only workaround I’ve found so far is:

1. Deploy the entire stack with the environment variables left empty.
2. After the deployment, manually access the Systems Manager through the AWS Console.
3. Retrieve the Aurora credentials.
4. Set the credentials in the .env file inside the Lambda source code.
5. Redeploy the stack so the Lambda function updates with the new environment variables.

In other words, I have to deploy two times on the first deploy...
I think there's a better way to handle this, specially because I'm gonna have to deal with 3 different stages(dev, test, production).

I've been thinking about those two solutions, but I'm not sure if it's appropriated:
・Should I create the Credentials on Systems Manager manually through the Console in advance?
-> If possible, I wanna handle the whole project only through CDK.
・Should I create a Credentials Stack at first and then refer to it using ARN something similar on Lambda and RDS?
->It seems like the credentials value are revealed on cloud formation templates and it's not recommended.

Does anyone have any idea on how should I improve the process?
Really appreciate any advices!

[mnapoli]

I don't know 100% if there isn't a solution to your problem, but just to share my approach: this is why I usually separate long-lived resources in different stacks. Also the first deploy of secrets is always super annoying to deal with, because you end up needed a second deploy to have everything up to date. So you could create the secrets manually.

Sorry I don't have a magic answer, in my experience it's usually about finding a reasonable workaround that works.

[h-kenji1]

Hey, there! Thanks for sharing your approach!
After careful consideration, I think we're gonna implement everything using CDK and then perform a second deployment to update the secrets.

Currently, I’m redeploying the entire Lambda function whenever there’s a change in the source code, which takes several minutes. Is there a more efficient way to upload the code without redeploying the entire function or even the stack?

By the way, when you mention "long-lived resources," are you referring to stateful resources like RDS or DynamoDB tables?

[mnapoli]

By the way, when you mention "long-lived resources," are you referring to stateful resources like RDS or DynamoDB tables?

yes exactly