Hacker News Reader

Comment by paulddraper | Hacker News Reader

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

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

Are you proposing that by acknowledging defense-in-depth, consistency dictates that one should pile up as many layers per attack vector as possible? Maybe, if you have infinite resources and don't need to make compromises on where you spend effort and resources in your risk management plan. But that's rarely the case in the real world.

You raise a fair point, this was possible, although it seems safe to say it would be a compromise on security.

I think it’s best not to expose the DB to outside connections in general, although it is still possible [1] when using RDS instances.

I think this is different for things like DynamoDB because, instead of a standard SQL-like db “connection”, they use AWS role-based auth for each request.

Of course, one could always configure some type of proxy service between the lambda and the DB... but that seems antithetical to going “serverless” in the first place.

[1] https://stackoverflow.com/questions/45227397/publicly-access...

Edit: I thought it was not possible to expose an RDS instance outside of a VPC, but I was wrong (you can place it in a public subnet, linked in [1]).

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.

I think Aurora Serverless has even worse [1] cold-start times (for the DB itself), and it was intended as more of a price-optimization than a performance boost.

[1] https://forums.aws.amazon.com/thread.jspa?threadID=288043

Reply on news.ycombinator.com