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

71–80 of 100 posts

Re: Improved VPC Networking for AWS Lambda

#71

Post by meekins »

mvanbaak wrote: post #70
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…

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.

This comment doesn't seem to make sense, could you elaborate a bit? How would you replace the database working as a persistence layer to an API application by polling an event stream?

Re: Improved VPC Networking for AWS Lambda

#72

Post by dabeeeenster »

meekins wrote: post #71
mvanbaak wrote: post #70

Earlier quoted context omitted.

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.

This comment doesn't seem to make sense, could you elaborate a bit? How would you replace the database working as a persistence layer to an API application by polling an event stream?

It doesnt replace the DB. It just uses Kineses to be the messaging provider from the lambda to the DB and back. Not sure that's a great idea TBH but who knows?!

Re: Improved VPC Networking for AWS Lambda

#73

Post by k__ »

scarface74 wrote: post #50
k__ wrote: post #48

Earlier quoted context omitted.

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.

RDMS is not legacy, but perimeter security certainly is.

Re: Improved VPC Networking for AWS Lambda

#74

Post by k__ »

slovenlyrobot wrote: post #55
k__ wrote: post #48

Earlier quoted context omitted.

Major is a bit harsh. As far as I know this was only an issue for legacy architectures.

There is an entire ecosystem of tooling that will shit itself and wake up half the company if you assign a public IP address in the wrong VPC Stuff like this is pain in the ass, it was a major problem

https://www.securityroundtable.org/security-without-boundari...

Re: Improved VPC Networking for AWS Lambda

#75

Post by scarface74 »

StreamBright wrote: post #66
scarface74 wrote: post #37

Earlier quoted context omitted.

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.

I work with both style of AWS installations. Having organization is a constant pain for people who access multiple accounts even with something like Okta. 1 browser can access 1 account and if you switch you have to go through the switching process, or use multiple browsers. Quite often people would like to access cross account resources which a whole different level of discomfort. This is why I still think, old scho…

If you’re using AWS as a more expensive colo and mostly just using VMs it’s fine. But once you start actually using AWS for anything else it’s s pain. You have to worry about the different service limits and they are all shared.

What’s the process for giving developers access to experiment? When you have different accounts, the development department can have basically unlimited access to the account and moving to production is basically getting a CloudFormation template approved and run by the Devops team.

Re: Improved VPC Networking for AWS Lambda

#76

Post by scarface74 »

k__ wrote: post #73
scarface74 wrote: post #50

Earlier quoted context omitted.

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

RDMS is not legacy, but perimeter security certainly is.

I’m one of the harshest critics of “lift and shifters” - old school net ops people who get one certificates by watching an ACloudGuru video, duplicate their on prem infrastructure and processes to the cloud and don’t go all in on the advantages of it and end up costing their clients more - but nowhere is it considered “legacy” to not use perimeter security.

Re: Improved VPC Networking for AWS Lambda

#77

Post by scarface74 »

mvanbaak wrote: post #70
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…

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.

And then when you need to read the database?

Re: Improved VPC Networking for AWS Lambda

#78

Post by scarface74 »

jmb12686 wrote: post #41

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)

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

Re: Improved VPC Networking for AWS Lambda

#79

Post by scarface74 »

abhorrence wrote: post #60
reilly3000 wrote: post #49

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 gotc…

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

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.

Re: Improved VPC Networking for AWS Lambda

#80

Post by scarface74 »

fulafel wrote: post #62
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…

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 awa…

It’s never been considered best practice to expose services needlessly to the Internet. I’m as far from an old school net ops guy as you can get and jump at any new AWS technology that’s feasible as anyone but it would be the height of stupidity for me to expose my Aurora cluster to the Internet. Good luck explaining that to your external auditors.
Post reply on HN