Hacker News Reader

Comment by Prefinem | Hacker News Reader

1. Use a framework for deploying your lambda functions. There are a few that will manage the API Gateway for you.

2. Don't put the Lambda inside a VPC if you want lower response times

3. Step Functions don't seem ready for prime time that I can tell. (This might have changed in the last couple of months)

4. Lambda Functions should be microservices. Small and lean.

5. There is a limit on resources for CloudFormation so at about 20-30 functions with API Gateway on the serverless framework, you will hit a limit and can't add anymore (other deployment tools which don't use CloudFormation shouldn't have an issue)

6. Want more CPU, add more RAM

View on HN

What makes you say Step Functions isn't ready for prime time? We've been using it (and SWF which it is based off) for about a year at decent scale and been generally very happy with it.

When I initially set the up, there was no way to edit or delete them. I haven't messed with them since, although, I did just check and there aren't any step functions in my account so it looks like they deleted the old ones.

It may be time to test them out again, I just go bit pretty bad with the last time I implemented them and lost about a weeks worth of work because of it being un-usable.

Don't put the Lambda inside a VPC if you want lower response times

Response time's are fine inside a VPC... People keep saying gateway is slow but it isn't from my experience...

API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well.

I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows.

Edit: this is by no means a deal breaker or anything. Just something that shocked me when I first noticed it.

(crap I just typed stuff out and pressed F5...)

I haven't tried with a NAT Gateway.

This is what I know.

If the response is small, the request duration is small.

Cloudfront > Gateway > Lambda > RDS (PostgreSQL)

Response:

1k | 20ms-60ms

10k | 50ms-90ms

100k | 150ms-200ms

350k | 200ms-450ms

That's a rough gauge of what I've experienced.

I think the throughput on the gateway is the bottleneck.

Just hit one of our test endpoints

Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms)

Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms)

Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms)

This is for a 20kb payload single request.

Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch

I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?

Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.

Just a follow up, after the issue last week with AWS Lambda in East-1 (thursday I believe) VPC is not longer causing any additional overhead.

I am not sure what happened, but I had to move a couple of functions inside the VPC and our response times have remained the same.

Are you paying for ssl round trips in your tests? We haven't seen such slow response times with lambda or the gateway.

I don't believe so. I am using Chrome network data and the SSL has already been downloaded / cached.

Reply on news.ycombinator.com