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)
Improved VPC Networking for AWS Lambda
41–50 of 100 posts
Re: Improved VPC Networking for AWS Lambda
#42This 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.
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...
API-Gateway can return HTML?
Re: Improved VPC Networking for AWS Lambda
#43I dont understand why people use AWS Lambda. Here in France, people use PHP with docker and it works just fine. Another scam from amazon?
What do you run docker on?
Re: Improved VPC Networking for AWS Lambda
#44Earlier quoted context omitted.
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...
API-Gateway can return HTML?
Sure.
You can write Velocity templates for integration responses.
Normally they are JSON because that's what all the AWS services return and API-Gateway just passes them along.
But you could write something like this:
#set($pets = $input.path('$'))
Pets
ID
Type
Price
#foreach($pet in $pets)
$pet.id
$pet.type
$pet.price
#end
Re: Improved VPC Networking for AWS Lambda
#45Iconoclast 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…
> 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.
Re: Improved VPC Networking for AWS Lambda
#46Iconoclast 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…
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.
> RDS is the cloud atop postgres
Or MySQL. Or SQL Server.
Re: Improved VPC Networking for AWS Lambda
#47Earlier quoted context omitted.
Also, wasn't Aurora Serverless created because of that problem?
Aurora Serverless also handles connections. The problem of having a burst of 1000 concurrent invocations accessing your databases still exists even with VPC access
That limit can be raised, apparently. I've seen mention of limits up to 30K concurrent invocations.
Re: Improved VPC Networking for AWS Lambda
#48This 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
Major is a bit harsh.
As far as I know this was only an issue for legacy architectures.
Re: Improved VPC Networking for AWS Lambda
#49This 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.
Re: Improved VPC Networking for AWS Lambda
#50This 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
Major is a bit harsh. As far as I know this was only an issue for legacy architectures.
No. Using an RDMS instead of DynamoDB is not a “legacy” architecture. You also shouldn’t expose your database publicly.