I set a large environment variable (2KB), then I opened deploy preview, and it failed with the error
Invalid AWS Lambda parameters. Reserved keys used in this request.
When I removed the environment variable and retried the preview, it deployed successfully.
I’m pretty sure I just hit the 4KB limit on all env vars, but could the error message be changed to make that clear? Is there any way to find out exactly how long your env vars are before you deploy and get an error message?
I haven’t used Functions myself, but I think it has nothing to do with the EV size. The message seems to say that you used a reserved key, so my guess is that you set an EV which you’re not supposed/allowed to override.
Not in this case. I’ve run into that error too. 
I wanted to use S3 but it’s illegal to use the AWS env variables. You have to call them MY_APP_AWS… instead of the default names.
In this case, the same env var was in use in another Netlify site, so it wasn’t an illegal name per se.
In that case, the error message is definitely misleading.
Hey @carlmjohnson,
That’s a great idea. Can you please share the deploy log where you saw that? I’ll also work on a reproduction case and then get a request filed. Many thanks for the suggestion.
5:11:22 PM: 3 new files to upload
5:11:22 PM: 2 new functions to upload
5:11:24 PM: Invalid AWS Lambda parameters. Reserved keys used in this request
5:11:24 PM: Invalid AWS Lambda parameters. Reserved keys used in this request
5:12:47 PM: Failed to upload file: identity-signup
5:13:19 PM: Failed to upload file: almanack-api
5:13:19 PM: Failing build: Failed to deploy site
5:13:19 PM: Finished processing build request in 6m15.363468051s
Awesome, thank you. Turns out there’s an existing issue filed internally on these misleading log lines- I’ve added the details in this thread so we can update you if/when there’s movement on it.
By any chance, did you get the error resolved? I have the same error: Invalid AWS Lambda parameters. Reserved keys used in this request..
we still have this issue open, but i have added your voice to the chorus. We’ll definitely update here if there are changes.
I spent a total of 6 hours debugging that error before i realize that one my cloud function file was empty… once this file deleted everything worked fine again…
this error was misleading me… i suppose it should be updated…!!
Hey there, @romain1304 
Thanks for following up on this thread, I will add your feedback to the open issue.
Same here.
I’ve had an empty function file for quite a while now, and just today it started failing my deploy.
Thanks to romain, I knew what to look for and removed the empty file. Without his post, I probably would have spent 6 hours tearing my hair out as well 
Hopefully anyone who Googles the error will find this thread and know what to do. No more empty function files!
that is great to hear! this is the community helping each other in a way that we love 
There has been some suggestions in this thread around the ability to specify what environment variables are used in functions. We have a lot of environment variables we use in our frontend applications at build time and only a couple needed for the functions, we have run into the 4kb issue quite a few times and shortening the environment variable names is not something we can do sensibly anymore. Many of them are also sensitive so they cannot be set in the netlify.toml file.
Is there any update on improving the environment variable flow in functions?
hi there @alexjfno1 - totally hear you on this. I am asking to see if we can get some up to date news on this.
Hi @alexjfno1,
Unfortunately, there’s no update yet. The limit is imposed by AWS and not by Netlify as mentioned in their docs: Using AWS Lambda environment variables - AWS Lambda (Configuring environment variables section).
I totally understand the limit imposed by AWS and know that you can’t get around that. What I’m more interested in is the ability to control what environment variables get sent where. The ability to select what env variables are injected into the function would be great, instead of sending every variable defined in the UI.
That is an interesting feature request. Like you know, there’s no way to do that as of now.
The only workaround is the one in the thread you linked above. As to if/when the feature would be available in the future, we do not have a timeframe.