
Improved VPC Networking for AWS Lambda - joaofs
https://aws.amazon.com/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
======
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](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.

~~~
k__
Also, wasn't Aurora Serverless created because of that problem?

~~~
nostrebored
Aurora Serverless also handles connections. The problem of having a burst of
1000 concurrent invocations accessing your databases still exists even with
VPC access

~~~
reilly3000
That limit can be raised, apparently. I've seen mention of limits up to 30K
concurrent invocations.

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

~~~
scarface74
No. Using an RDMS instead of DynamoDB is not a “legacy” architecture. You also
shouldn’t expose your database publicly.

~~~
k__
RDMS is not legacy, but perimeter security certainly is.

~~~
jimmychangas
Honest question: what, in you opinion, is the state-of-the-art approach?
Something like BeyondCorp?

~~~
k__
I think zero-trust goes into a good direction.

[https://www.securityroundtable.org/zero-trust-approach-
can-m...](https://www.securityroundtable.org/zero-trust-approach-can-make-
cloud-secure/)

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

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

~~~
scarface74
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.

~~~
StreamBright
Sorry but it does not matter how many since everything is automated and you
create the warm up scheduler when you create the function. As other pointed
out in this thread that are other challenges with this approach.

>> Just use Fargate

We were trying to and we decided that is not our cup of tea. Lambdas are.

~~~
scarface74
Yes it does matter. In your scheduler, how do you ensure your ping (the way
you start an instance) is actually creating another instance to keep warm or
reusing another instance?

If you want to always keep 20 instances warm, you have to keep the first ping
active until the 20th one is done.

In other words, if you want to keep 20 active instances warm and you send 20
requests in 5 seconds, if each request only takes .25 seconds. You will only
have 5 warm lambdas. The 6th real concurrent connection will still have a cold
start. Also while you are pinging the request to keep it warm, that instance
can serve a real user.

Also, API Gateway has an algorithm to decide whether to launch a new lambda
are cache a request hoping that using an already warm lambda will free up.

------
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...](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html)

~~~
scarface74
This is not meant to be a criticism of AWS, I’m an AWS true believer, but the
main purpose of going to AWS is to make the “undifferentiated heavy lifting”
someone else’s problem not to save money.

Going to AWS to save money on resources is about like going to the Apple Store
to buy a cheap laptop.

~~~
reilly3000
I’m not against AWS or $36/mo. It just is kinda a drag when the promise of
serverless is pay per user and scaling to zero. You could get a nice EC2
t3.medium and do a lot more RPS for the cost of that NAT and Lambda
invocations.

~~~
scarface74
If you don’t care about cold starts, there is always Aurora Serverless with
the Data API. I don’t believe it requires either a NAT or for the lambda to be
attached to your VPC.

------
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) :/.

~~~
paulddraper
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.

~~~
StreamBright
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.

~~~
watermelon0
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.

~~~
WaxProlix
Accounts are the correct level to separate these at. Keeps credentials easier
to manage for devs, techs, etc, and limits blast radius if unauthorized
accesses take place.

~~~
StreamBright
>> This also means that developers can have close to admin privileges

>> limits blast radius if unauthorized accesses take place.

I am not sure if admin privileges are the right way of limiting blast radius.
Reasonable roles with least privileges are.

"In information security, computer science, and other fields, the principle of
least privilege (PoLP), also known as the principle of minimal privilege or
the principle of least authority, requires that in a particular abstraction
layer of a computing environment, every module (such as a process, a user, or
a program, depending on the subject) must be able to access only the
information and resources that are necessary for its legitimate purpose."

~~~
WaxProlix
Yeah, and you want those roles and accounts scoped appropriately. Someone with
the 'Admin' role in a pre-prod account wouldn't necessarily get that same role
in a production one. Someone with admin in a standard prod account might not
get that same privilege in an account that you manage for a customer, or one
with extra compliance requirements, etc.

