AWS Lambda functions are run inside of an Amazon Linux environment (presumably a container of some sort). Sequential calls to the same Lambda function could hit the same or different instantiations of the environment.
If you hit the same copy (I don’t want to say “instance”) of the Lambda function, then stuff you left in the environment from a previous run might still be available.
This could be useful (think caching) or hurtful (if your code incorrectly expects a fresh start every run).
Here’s an example using lambdash, a hack I wrote that sends shell commands to a Lambda function to be run in the AWS Lambda environment, with stdout/stderr being sent back through S3 and displayed locally.
$ lambdash 'echo a $(date) >> /tmp/run.log; cat /tmp/run.log' a Tue Dec 9 13:54:50 PST 2014 $ lambdash 'echo b $(date) >> /tmp/run.log; cat /tmp/run.log' a Tue Dec 9 13:54:50 PST 2014 b Tue Dec 9 13:55:00 PST 2014 $ lambdash 'echo c $(date) >> /tmp/run.log; cat /tmp/run.log' a Tue Dec 9 13:54:50 PST 2014 b Tue Dec 9 13:55:00 PST 2014 c Tue Dec 9 13:55:20 PST 2014
As you can see in this example, the file in /tmp contains content from previous runs.
These tests are being run in AWS Lambda Preview, and should not be depended on for long term or production plans. Amazon could change how AWS Lambda works at any time for any reason, especially when the behaviors are not documented as part of the interface. For example, Amazon could decide to clear out writable file system areas like /tmp after each run.
If you want to have a dependable storage that can be shared among multiple copies of an AWS Lambda function, consider using standard AWS services like DynamoDB, RDS, ElastiCache, S3, etc.