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

61–70 of 100 posts

Re: Improved VPC Networking for AWS Lambda

#61

Post by scarface74 »

aledalgrande wrote: post #59
scarface74 wrote: post #57

Earlier quoted context omitted.

Maybe it increases the load time of the lambda? But I’m already using a lambda attached to a VPC using the proxy integration and running either Node/Express or C#/Web API so its not like I’m always using lambda as efficiently and lightweight as possible. So there’s that...

Mm are you using Lambda as a sort of router? The linked project is developed by Amazon and it translates into native Lambda layers. If they did their job with performance (which I trust Amazon devs to do), there should be no difference.

When you use proxy integration all requests go directly to your lambda instead of using API Gateway for routing and translation. The lambda integration translates the request into something your framework understands.

Node/Express:

https://github.com/awslabs/aws-serverless-express

C#/Web API:

https://aws.amazon.com/blogs/developer/deploy-an-existing-as...

Python/Flask:

https://pypi.org/project/flask-lambda-support/

Re: Improved VPC Networking for AWS Lambda

#62

Post by fulafel »

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

Re: Improved VPC Networking for AWS Lambda

#63

Post by fulafel »

jabart wrote: post #40
paulddraper wrote: post #6

Earlier quoted context omitted.

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

But VPC is not an especially efficient additional "defense-in-depth" layer against this kind of "fucked up both firewall and password" configuration mistake. The first 2 obvious ones are passwords, network-level firewalling, host-level firewalling of course, and after that you can add monitoring / port scanning for all your "must be firewalled" services. And you can mandate better-than-passwords authentication methods[1]. Etc. The latter is better because it is more general and doesn't add costly complexity to your networking topology (by way of NAT and/or ambiguous rfc1918 addressing)

[1] For example https://www.postgresql.org/docs/current/auth-cert.html or https://aws.amazon.com/premiumsupport/knowledge-center/users...

Re: Improved VPC Networking for AWS Lambda

#64

Post by fulafel »

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?

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.

Re: Improved VPC Networking for AWS Lambda

#65

Post by paxys »

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…

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.

Re: Improved VPC Networking for AWS Lambda

#66

Post by StreamBright »

scarface74 wrote: post #37
StreamBright wrote: post #30

Earlier quoted context omitted.

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.

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 school or not, that having a single account and multiple VPCs is a better option.

Re: Improved VPC Networking for AWS Lambda

#67

Post by scoopertrooper »

saurik wrote: post #11
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…

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…

VPCs are very helpful for when you have a large number of developers working in an AWS environment. It'd be oh so easy for a developer to accidently change a bit of terraform and expose your database to the internet without VPCs.

Re: Improved VPC Networking for AWS Lambda

#68

Post by StreamBright »

scarface74 wrote: post #36
StreamBright wrote: post #27

Earlier quoted context omitted.

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.

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.

Re: Improved VPC Networking for AWS Lambda

#69

Post by Niksko »

fulafel wrote: post #63
jabart wrote: post #40

Earlier quoted context omitted.

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.

But VPC is not an especially efficient additional "defense-in-depth" layer against this kind of "fucked up both firewall and password" configuration mistake. The first 2 obvious ones are passwords, network-level firewalling, host-level firewalling of course, and after that you can add monitoring / port scanning for all your "must be firewalled" services. And you can mandate better-than-passwords authentication method…

You mention defense in depth, but then immediately decide that an extra layer of defense is unnecessary.

Re: Improved VPC Networking for AWS Lambda

#70

Post by mvanbaak »

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.
Post reply on HN