twagner

Quick clarification: No need to go through API Gateway if you don't actually need the https endpoint - all AWS SDKs can hit Lambda's REST APIs directly, which also reduces p50 latency.

Yes. First step was https://aws.amazon.com/blogs/aws/new-amazon-linux-container-.... Layering Lambda's image on top of that to assist people building and testing is definitely on our roadmap.

Yep, I hear about the lack of Python3 all the time, and I know our Python users are waiting for it. On the roadmap, and partially complete, but competing with some other language work at the moment.

@hobofan, take a look at our recent API Gateway features and see if the greedy paths and pass-through settings provide what you're looking for (they're also supported by CloudFormation). We tried to simplify the "configure every route" problem, but always looking for additional suggestions to make API config easier.

@jomamaxx (& others): Reducing latency (and latency variability) is a critical goal for our team. We've improved p99 variability in API Gateway-related latency over the last few months, and will be addressing some of the Lambda-related latency that occurs when we refresh containers in the coming months. Additional latency optimizations coming at all levels of the stack, including networking.

A clarification on the discussions about "managed hosting": Lambda is not classic web hosting; in fact, we block Lambda functions from calling socket.listen. In the Lambda model (whatever you prefer to call the broader category), the cloud service sees every request in order to perform scaling and load balancing on the function's behalf.

Happy to chat offline with anyone who has additional questions or feedback: DM me on twitter @timallenwagner

Suboptimal ;-). This is a common request, and we're looking at options for a config feature that's independent of the code payload. Tweet or email me detailed suggestions/asks for it: @timallenwagner or timwagne at amazon.com.

This is great feedback encoderer. We're going to keep iterating fast to make deployment, packaging, and global (cross-region) updates even easier for AWS Lambda.

Appreciate the feedback/suggestions! We'll take a look at expanding the disk space, probably as part of the "power level" adjustment that already affects memory, CPU power, etc.

AWS Lambda function schedules are driven off the same fault-tolerant, highly available service that powers SWF. (So...yes, they're reliable :)

Totally agree. It's our most requested feature on the Lambda team and a priority to enable.

AWS Lambda supports nodejs and jvm-based languages (Java, Scala, Clojure, etc.) directly, and lets you run Python, shell scripts, and arbitrary executables as well. We started with nodejs because it worked nicely for expressing our initial launch scenario, event handlers.

Thanks (and love the suggestion of R, though we probably want a repl as well for that).

1. Working on it :). I'd appreciate feedback on the scope of an mvp feature here: e.g., daily/hourly/5 minute-ly periodicity? Scheduled day/time in the future for a one-off? Or is anything short of full cron not enough?

2. Yep. Initially, you'll have to include the Clojure runtime as a library in your ZIP file, so it will look to Lambda like a Java function. Then assuming there's interest, we'll promote it to a first-class experience in the console and API as a language of its own at a later date.

Tldr: Only if your events are extremely infrequent. With an inter-event arrival rate of seconds to few minutes, your jvm processes get frozen and thawed out the vast majority of the time to avoid the initialization/load overhead that would otherwise result.

See https://aws.amazon.com/blogs/compute/container-reuse-in-lamb... for a more complete description.

@RossM: We will definitely be supporting additional languages. Happy to take input on the order... @vegasje: VPC tunneling is a frequent customer ask and is on the roadmap.