Amplify-cli: How am I supposed to use Amplify Environment variables in my Lambda @functions?

Created on 21 May 2020 · 15Comments · Source: aws-amplify/amplify-cli

Which Category is your question related to?
Environment variables, Amplify and Lambda

This is a pretty straightforward feature and question. It has been mentioned in many issues here

Or elsewhere:

And the terrible documentation does not help, only the first part of it (setting the variables) makes sense.

Here is from where I started, what I went through and what didn't work. Let me know if I have missed something.

_Where I started_
I wanted to remove the api id from dynamoDB generated tables for @model, in order to have a table name e.g. "project-dev" instead of "Project-6ezfre56g4erg-dev". It would have been much easier, to reference it, especially since I have multiple api using the same table.

As I understood it, Amplify is opinionated and it abstracts the implementation details, we then cannot have both custom data sources and an API generated through the @model directive.

I still tried to update the cloudFormation template of my nested stack to remove the apiId from the table name (GetAttGraphQLAPIApiId) everywhere it was mentionned, but the update rollback:

"TableName": {
                    "Fn::If": [
                        "HasEnvironmentParameter",
                        {
                            "Fn::Join": [
                                "-",
                                [
                                    "Project",
                                    {
                                        "Ref": "GetAttGraphQLAPIApiId"
                                    },
                                    {
                                        "Ref": "env"
                                    }
                                ]
                            ]
                        },

Again, this is a managed approach, so I guess I should comply with it. However, when you offer a managed approach, it should consider that the AppSync data sources are exposed, can be changed, and that it has no consequence on the API. This is very inconsistent with the managed approach and misleading to say the least.

_So I needed environment variables_ to store my table names. I found the documentation, switched to the managed hosting of the frontend apps to have the possibility to add environment variables (no idea why it is mandatory) and defined my env variables at the amplify app level as mentioned here.

I expected these global, app level, env variables to be global env variables. However, as far as I know, they are not. In my lambda workers, I cannot find them at the process.env level. Why are they not inherited? Am I missing something?

I really don't want to manually add to my 50+ lambda workers local env variables, at the lambda level.

I also tried to update the cloudFormation template of the lambda with the same approach than the snippet above but GetAttGraphQLAPIApiId is not available. Since I can't have custom table names, I am back to square one.

Since it seems that Amplify env variables are exposed at build step, I tried to assign them to the backend at the build level in the amplify.yml file. No luck there either, it fails to build if I assign a variable.

I really like Amplify but this issue has made me lose a lot of time and was a real disappointment. I still think I could have missed something so I took the time to write all this. Please consider the effort and let me know how I should proceed to have my env variables available in my lambda workers, or change my tables names to custom names while keeping the @model directive benefits.

amplify-console functions pending-close-response-required question

Source

Billybobbonnet

👍8

Most helpful comment

Any chance this will be picked up in a upcoming release? Becoming a real headache to deal with

anandsathe67 on 13 Jul 2020

👍10

All 15 comments

@Billybobbonnet Apologize for the confusion out here. Did you try out the amplify update function flow to add the table names generated by the GraphQL transformer (i.e data sources) as environment variables to the function? We provide that flow and it's documented out here -https://docs.amplify.aws/cli/function#function-templates
Unfortunately at this time, the lambda functions generated by the CLI do not inherit the env variables defined in the Amplify Console. The env variables defined in the Amplify console is just used in your build configs and are build time environment variables.

kaustavghosh06 on 26 May 2020

@kaustavghosh06 Thank you for your answer. I'll look into the doc you mentioned.

Billybobbonnet on 28 May 2020

Unfortunately at this time, the lambda functions generated by the CLI do not inherit the env variables defined in the Amplify Console. The env variables defined in the Amplify console is just used in your build configs and are build time environment variables.

@kaustavghosh06 - is there a feature request issue for this functionality? And is there a workaround - some better way of centrally managing e.g. a cryptographic secret and automatically getting it into lambdas as an environment variable without putting it into a file that will be in version control?

Edit: Looks like that would be #2227

djsmedes on 1 Jun 2020

Any chance this will be picked up in a upcoming release? Becoming a real headache to deal with

anandsathe67 on 13 Jul 2020

👍10

@anandsathe67 we're working on this now, unsure of a date but will try to come back soon with something close.

dabit3 on 26 Jul 2020

👍5

What we do is equivilent to doing this:

aws lambda update-function-configuration --function-name someFunction --environment "Variables={SOMEVAR=foo}"

Actually what we have is a local JSON that looks like this:

[{
    functionName: ['variableName', 'variableName2']
}]

Then use the aws SDK in a node.js script which yanks the values from SSM and sets them using a similar command to above in deployments, for local dev we just use node.exec to set process.ENV to the right values.