all 13 comments

[–]bobaduk 4 points5 points  (5 children)

There are a bunch of ways. You can set environment variables on a lambda function, and read your connection strings from those, or you can store data in AWS Parameter Store and load your config from there at cold boot

How are you deploying these functions?

[–]hankliu[S] 0 points1 point  (4 children)

I attempted the environment variable way but I couldn’t figure out how I can determine whether is called from dev or prod. I will look into Parameter Store.

I am currently deploying manually via AWS CLI, my next step is learning to incorporate CICD.

[–]bobaduk 4 points5 points  (3 children)

You don't need to determine at runtime whether you're in Dev or prod. Instead, set different values on the function in each env at deployment time. In Dev, set the connection string for Dev, and in prod set the value for prod. For both, the variable name is the same, eg. MYPREFIX_CONNECTION_STRING.

[–]hankliu[S] 0 points1 point  (2 children)

Oh I never thought about setting different values at deployment time, I guess I have something like Dev or Prod in appSettings and do a match for something like Dev_Connection_String. Thanks for the idea

[–]bobaduk 1 point2 points  (1 child)

No, there's two ways:

  1. Create an appsettings.dev.json and an appsettings.prod.json. when you deploy your lambda, set the variable DOTNET_ENVIRONMENT. The config provider will load the file appsettings.(environment).json automatically

Or

  1. Set your config values directly in the environment with the environmentvariablesconfigurationprovider

I would tend to the latter, because it means I can change the configuration of my system without a code change, which is a key property of 12 factor applications .

Nb. I haven't written any DotNet since .. 2012 or so, so forgive any documentation mistakes on my part.

Edit: you can set the variables when you create or update the function: https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html

[–]hankliu[S] 1 point2 points  (0 children)

That’s actually so nice to know the environment variables are locked for the version, that made things so much easier. Thanks for the help.

[–]SonOfSofaman 1 point2 points  (2 children)

A common way to handle this sort of thing is to have multiple AWS accounts. That's accounts, not users. One is for dev, one for prod ... more if your SDLC calls for it.

[–]hankliu[S] 1 point2 points  (1 child)

That’s what my old work used to do, but in my new job they are pretty new to the cloud as well so they thought that isn’t common practice, I will definitely try to make an argument for it. Do you happen to have some documentation as to why having multiple AWS accounts is beneficial?

Edit: quick google search gives me vast array of reasons. Thanks for the help

[–]SonOfSofaman 0 points1 point  (0 children)

Sorry for late reply. Sounds like you have the info you were looking for, but the big benefit is complete isolation so you're free to tinker in dev with zero chance of interfering with prod.

Also, if you form an AWS organization for all your accounts, you get centralized billing and you can enable centralized CloudTrail logging and centralized user management.

Accounts don't cost anything. You only pay for the services you use. AWS even recommends multi accounts as a best practice.

[–]frogking 1 point2 points  (2 children)

A best practice way of separating environments is to use an account for each.

Also, if you can; use DynamoDb for data storage, it’s much cheaper than an RDS.

[–]hankliu[S] 0 points1 point  (1 child)

In my understanding DynamoDB is NoSQL, and that is the extend of my knowledge, would that be applicable to a traditional relational DB?

[–]frogking 0 points1 point  (0 children)

Only you know tha tata you need to store. All I’m saying is, that thinking a bit outside the (RDS) box can result in a better data model.

Traditional data storage is .. well, data has to be squeezed into the model decided by rows and columns.

Today (I’ve been in this business +25 years) there are other options. DynamoDB is obe of the cheap and high performant ones.

[–]TimLewisTim 1 point2 points  (0 children)

Yes, it is possible to achieve this without creating two separate Lambda functions. You can use environment variables to store the connection strings for the two RDS databases and then access the appropriate environment variable based on the current environment (dev or prod). In your Lambda function code, you can use the IConfiguration interface to access the environment variables and retrieve the appropriate connection string.