"With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. "
I.e. wrap your code as if it were a lambda function, and pass it to us. It will work when we call it just as well as when you do in the original environment.
Sounds like a better name would be "Amazon Macro", though. This is because the "lambda" (user's application) likely refers to features of the hosting environment and is influenced by them; it is not referentially transparent to place code on a server, even if the grunt work of setting up the surroundings is done by a "macro".
"Lambda" is a hot buzzword though, as some notable Blub languages have been scrambling to integrate them, whereas "macro" has a stained reputation.
There are several connections between Lambda and functional programming.
1. The snippets of code you run in Lambda are called "cloud functions".
2. Lambda applications are generally event driven and stateless, which is a very functional idiom.
As other folks mentioned, however, you can use Lambda with non functional languages (like Java). So even though a Lambda application is inherently functional (small stateless functions communicating via events), you don't have to write in a functional style if you don't want to.
That's the case for most uses of "lambda" in programming languages too. It just means something like "anonymous function". I believe Lisp was the first language to introduce lambda as a keyword, and that's how it uses it: (lambda (x) ...) creates an anonymous function, but the body of the function doesn't have to be written in a functional style. In fact the modern concept of "functional style" didn't exist at the time.