Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improved VPC Networking for AWS Lambda

aws.amazon.com

Post reply on HN
Print view View original

31–40 of 100 posts

Re: Improved VPC Networking for AWS Lambda

#31

Post by AmericanChopper »

paulddraper wrote: post #8

Iconoclast view ahead (change my mind please): AWS does tons of stuff around VPCs....I feel like they really want me to use them (or their customers really want to use them), but I just don't see why. I just run RDS on the internet. I don't have to muck with the complexity or cost of NATs or peering or Lambda slow start or any other weird networking issues. I know it's "public", but that seems irrelevant in the era o…

I don’t think AWS want you to use VPC at all. The Golden Path for serverless on AWS has always been “networkless”. If your use case fits into their stateless HTTP stack (API Gateway + Lambda + Dynamo + SQS...) then you’re gonna have a really easy time. The reason VPC is required is because not every use case is going to fit into that stack, and the fact that VPC functionality seems to be always just a little bit not good enough (in comparison) doesn’t make me think they’re pushing people towards it.

Re: Improved VPC Networking for AWS Lambda

#33

Post by slovenlyrobot »

This has been a /major/ sore point for Lambda use, amazing they fixed it, and always great to see they've documented the intense engineering requirements involved to make it happen.

AWS is a beautiful mix of business and technology, it's very rare to see such a large engineering-driven organization managing to balance customer friendliness. I'm an unashamed fanboy

Re: Improved VPC Networking for AWS Lambda

#34

Post by watermelon0 »

StreamBright wrote: post #30
paulddraper wrote: post #19

Earlier quoted context omitted.

My theory is that a bunch of entrenched network engineers just really like subnets and IPv4 and NAT and don't realize how mostly unnecessary it is in an era of cloud infrastructure and IPv6. My grandchildren are still going to be NAT'ing.

I think it is easy to have dev, qa and prod VPCs. Without VPC these separate infrastructure groups might be harder to split out. I usually reference security groups instead of subnets in security groups, avoiding referencing IP ranges (v4 or v6) entirely.

You can also use multiple AWS accounts to separate those environments, which also eases user management (usually you have different people with access to each environment, with some overlap).

This also means that developers can have close to admin privileges, since the worst they can do, is to disrupt work of another developer, without affecting either QA or production.

Re: Improved VPC Networking for AWS Lambda

#35

Post by aledalgrande »

k__ wrote: post #18
anherome21003 wrote: post #4

I dont understand why people use AWS Lambda. Here in France, people use PHP with docker and it works just fine. Another scam from amazon?

You can use PHP on AWS Lambda if you wish. If you use Lambda instead of Docker, you don't have to mess with container orchestration.

Actually now you can deploy your docker layers directly to lambda, so you are developing on exactly the same environment.

https://github.com/awslabs/aws-lambda-container-image-conver...

Re: Improved VPC Networking for AWS Lambda

#36

Post by scarface74 »

StreamBright wrote: post #27
ajoy wrote: post #22

This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.

Which can be mitigated by invoking your own Lambda functions once every minute or 5 minutes. Usually does not blow the budget.

Which is a horrible idea....

How many lambdas do you keep warm? 5, 10, 20? Every new connection is a new lambda instance. You're still just delaying the inevitable.

Just use Fargate if you want to stay serverless and don't want the cold start times -- well at least before today.

Re: Improved VPC Networking for AWS Lambda

#37

Post by scarface74 »

StreamBright wrote: post #30
paulddraper wrote: post #19

Earlier quoted context omitted.

My theory is that a bunch of entrenched network engineers just really like subnets and IPv4 and NAT and don't realize how mostly unnecessary it is in an era of cloud infrastructure and IPv6. My grandchildren are still going to be NAT'ing.

I think it is easy to have dev, qa and prod VPCs. Without VPC these separate infrastructure groups might be harder to split out. I usually reference security groups instead of subnets in security groups, avoiding referencing IP ranges (v4 or v6) entirely.

Which is really an old school way of doing it. Having multiple VPC's doesn't get around account limits, resources with the same name (sns topics, queues, stacks, etc.)

Just use separate accounts in an Organization.

You can give your developers almost complete unrestricted access to your dev account.

Re: Improved VPC Networking for AWS Lambda

#38

Post by zten »

AmericanChopper wrote: post #31
paulddraper wrote: post #8

Iconoclast view ahead (change my mind please): AWS does tons of stuff around VPCs....I feel like they really want me to use them (or their customers really want to use them), but I just don't see why. I just run RDS on the internet. I don't have to muck with the complexity or cost of NATs or peering or Lambda slow start or any other weird networking issues. I know it's "public", but that seems irrelevant in the era o…

I don’t think AWS want you to use VPC at all. The Golden Path for serverless on AWS has always been “networkless”. If your use case fits into their stateless HTTP stack (API Gateway + Lambda + Dynamo + SQS...) then you’re gonna have a really easy time. The reason VPC is required is because not every use case is going to fit into that stack, and the fact that VPC functionality seems to be always just a little bit not…

They definitely do if you're trying to use things based on EC2 instances. The newest types of instances have been VPC-only for years now.

Re: Improved VPC Networking for AWS Lambda

#39

Post by AmericanChopper »

zten wrote: post #38
AmericanChopper wrote: post #31

Earlier quoted context omitted.

I don’t think AWS want you to use VPC at all. The Golden Path for serverless on AWS has always been “networkless”. If your use case fits into their stateless HTTP stack (API Gateway + Lambda + Dynamo + SQS...) then you’re gonna have a really easy time. The reason VPC is required is because not every use case is going to fit into that stack, and the fact that VPC functionality seems to be always just a little bit not…

They definitely do if you're trying to use things based on EC2 instances. The newest types of instances have been VPC-only for years now.

But if you’re using EC2, then you’ve already wandered far off the serverless path.

Re: Improved VPC Networking for AWS Lambda

#40

Post by jabart »

paulddraper wrote: post #6
gazzini wrote: post #3

This is huge for Lambda. It allows devs to create “serverless” apps [1], with relational databases, without 10+ second cold-start times. In the article, they measure it as 988ms. I have tried building an API using API Gateway Lambda, but had to choose between using DynamoDB to store data (no-SQL, so challenging to query) or suffering unacceptably long response times whenever a request happens to cause a cold-start. T…

*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.

Which is how most breach announcements start

"A database server was found with an open port exposed to the internet and no or poor authentication, all records were exposed."

This also should mean that Lambda's can get stable public IPs through a VPC for firewalls as well.

*edit for must to most.

Post reply on HN