Improved VPC Networking for AWS Lambda

[gazzini]

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. Theoretically, this problem is now going away!

[1] https://serverless-stack.com

[paulddraper]

*It allows devs to create those apps _within a VPC_.

You could always have fast startup with Lambda + database outside the VPC.

[danb232]

is that a good tutorial? looks really good on the surface!

[mvanbaak]

If you put an event bus in the middle (kinesis) your api-lambda functions don't need direct access to your RDS. Subscribe lambda functions to your kinesis stream, and let them handle the link to your RDS. This way you wont notice the cold starts.

[jmb12686]

AWS announced this enhancement at 2018 re:Invent. It was slated for "sometime in 2019". I was excited, and I'm impressed that they released the feature well ahead of the end of the year (and before the next conference, which would obviously raise a few questions)

[scarface74]

They did something similar with drift detection and cloud formation. They announced it at reInvent 2017 and released it one week before reInvent 2018.

[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

[k__]

Major is a bit harsh.

As far as I know this was only an issue for legacy architectures.

[ajoy]

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.

[nostrebored]

Solves might be strong, but it removes a big portion of the cold start latency that was difficult to optimize for and out of the control of developers. Creating minimal images isn't difficult for a number of environments (e.g. webpacking your node.js lambdas) and barring necessarily large images (think pandas on Lambda) this puts a lot of control for the cold start p99 back in the hands of customers.

Overall, definitely a big win!

[k__]

I found it a bit strange that they sold Lambda as THE new way to do API development.

You can connect API-Gateway with other services via Velocity templates, which don't have cold starts.

AppSync also doesn't suffer from cold starts.

Both are also serverless services.

Lambda is good if the other solutions are missing something, so you can drop it in quickly, but I wouldn't use it as the go to services for that...

[StreamBright]

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

[jfbaro]

Wow! That's great. Cold starts are no longer a show stopper! Rust powered APIs running on AWS .. It sounds really exciting

[reilly3000]

This is great news, but I'm bummed they didn't bundle the NAT gateway with this service. In a typical function that calls out to get data from a service and reads/writes from a DB in a VPC, that requires the somewhat painful configuration of a NAT gateway and dedicated subnets, as well as a $36/month bill for the NAT gateway service.

There are some workarounds that using multiple lambdas, but they have their own gotchas.

Still, hooray, this is good news. The Data API is great for Serverless Aurora, but I can't use that with BI tools.

[abhorrence]

You can run your own gateway instance(s) for a lot cheaper than the nat gateway service. There are definitely some tradeoffs, but if $36/mo is an issue, they can be worthwhile: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Ins...

[EwanToo]

This is a great improvement for Lambda users, much reduced cold start times!

[paulddraper]

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 of cloud services. This isn't any different than, say, how Firebase or a million other services run. Should I be concerned that my Firebase apps are insecure because someone isn't overlaying a 10.* network on them?

EDIT: I should clarify that I understand the legitimacy of security groups, especially for technologies that weren't meant to operate outside a firewall. But that's mostly a different subject; AWS had security groups years before VPCs and subnets and NATs.

[saurik]

So making the actual listening port for a database server "public" is generally a bad idea as that is another attack surface of code that honestly is hardly ever made public... but if when you say "public" you mean you are using security groups (which are super trivial to use and easy to understand) to define which other AWS devices can access the port, then yeah: I have never seen any reason why this entire feature should exist and the concept of having to think about IP address ranges as if they somehow matter is one of the things I was escaping when I moved to cloud in the first place, and somehow they wanted to reintroduce it? Why?!? It doesn't even work well (!!), and introduces tons of latency into everything it touches (not just Lambda) :/.

[fulafel]

This is true, AWS is pretty anti-internet in all their architecture recommendations. IMO security is better done by firewalling and protocol level authentication (belt + suspenders) because it keeps your configuration clean and understandable, and complexity is the enemy of security.

The attitude has two things in AWS interest: 1) keep lock-in by encouraging customers to build AWS-internal networks 2) don't scare away the lift-and-shift customers who want to transplant their 1990s style "intranet" (or mental model, at least) onto AWS.

Explains also why they aren't very keen about IPv6 because that would encourage internetworking.

Just don't tell anyone that you can access the AWS console from the internet :)

[enitihas]

VPCs are very useful when running things like elasticache though( memcache and redis), because AFAIK those don't have an authentication ecosystem so making them public would be a terrible idea.

[cle]

Defense in depth. Not having public routes to your database adds another layer of protection. You should have multiple, and they should be redundant.

[Scarbutt]

Firebase was made specifically for the cloud, RDS is the cloud atop postgres, I don't know how secure RDS is (against the myriads of attacks) but it wouldn't be bad idea to use the built-in aws firewall to at least restrict access to trusted IPs ;)

Also, VPCs are really useful if you have many systems and services(yours or theirs) inside AWS.

[paxys]

Exposing a database to the public internet is a terrible idea. Yes, it's behind an auth layer, but is a username and password really enough protection for literally all of your company's data? Heck most people here have probably set up 2FA for their social media profiles, and for good reason.

[dragonwriter]

> 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)

VPC is a very convenient fit for enterprise customers extending on-premises networks into the cloud, I think that's the market it's mainly focussed on.

> I know it's "public", but that seems irrelevant in the era of cloud services.

It's not irrelevant, but neither is it necessary critical all the time; there doesn't need to be a one-size- (or even one-shape-)fits-all universal approach to network security, and AWS encompasses a lot of different customer setups, including enterprises for which it is a virtual extensions of the on-premises internal network.

[serkanh]

Say you have bunch of ec2 instances with public ip addresses that runs an application that makes calls to 3rd party service. Say that 3rd party service allows only access from certain ip ranges, would you rather give them a single ip or hundreds of ips for them to whitelist? What you say may be acceptable for small infra but not in large setup.

[momokoko]

You need to realize that the point of AWS is lock in. Once your service becomes a ball of various AWS pieces, it becomes almost impossible to leave once you start scaling.

So there is always a priority towards things that cause more lock in like VPC.

[AmericanChopper]

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.

[whalesalad]

I don't understand why people drive cars. Here in XYZ we ride horses everywhere and it works just fine.

[k__]

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.

[fulafel]

It's takes care of turning the containers on and off automatically. It's the Heroku / Google App Engine idea. But more popular because it's from Amazon.

[empath75]

The entire country uses php and docker?

[staticassertion]

What do you run docker on?

[paulddraper]

FaaS offers more responsive resource scaling and is "easier" to manage.

[StreamBright]

I just migrated one of the largest French companies to AWS, they do not use PHP at all.