5 ms·

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 me

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 7y ago
*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.
- deleted 7y ago
  [deleted]
- k__ 7y ago
  Also, wasn't Aurora Serverless created because of that problem?
  - nostrebored 7y ago
    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 7y ago
      That limit can be raised, apparently. I've seen mention of limits up to 30K concurrent invocations.
  - gazzini 7y ago
    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 https://forums.aws.amazon.com/thread.jspa?threadID=288043
- gazzini 7y ago
  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-accessing-aws-rds-from-outside-vpc 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]).
- jabart 7y ago
  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.
  - fulafel 7y ago
    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 https://www.postgresql.org/docs/current/auth-cert.html or https://aws.amazon.com/premiumsupport/knowledge-center/users-connect-rds-iam/ https://aws.amazon.com/premiumsupport/knowledge-center/users...
    - Niksko 7y ago
      You mention defense in depth, but then immediately decide that an extra layer of defense is unnecessary.
      - fulafel 7y ago
        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.
danb232 7y ago
is that a good tutorial? looks really good on the surface!
mvanbaak 7y ago
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.
- meekins 7y ago
  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?
  - dabeeeenster 7y ago
    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?!
- scarface74 7y ago
  And then when you need to read the database?

paulddraper 7y ago

*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.

deleted 7y ago
[deleted]
k__ 7y ago
Also, wasn't Aurora Serverless created because of that problem?
- nostrebored 7y ago
  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 7y ago
    That limit can be raised, apparently. I've seen mention of limits up to 30K concurrent invocations.
- gazzini 7y ago
  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 https://forums.aws.amazon.com/thread.jspa?threadID=288043
gazzini 7y ago
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-accessing-aws-rds-from-outside-vpc 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]).
jabart 7y ago
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.
- fulafel 7y ago
  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 https://www.postgresql.org/docs/current/auth-cert.html or https://aws.amazon.com/premiumsupport/knowledge-center/users-connect-rds-iam/ https://aws.amazon.com/premiumsupport/knowledge-center/users...
  - Niksko 7y ago
    You mention defense in depth, but then immediately decide that an extra layer of defense is unnecessary.
    - fulafel 7y ago
      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.

danb232 7y ago

is that a good tutorial? looks really good on the surface!

mvanbaak 7y ago

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.

meekins 7y ago
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?
- dabeeeenster 7y ago
  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?!
scarface74 7y ago
And then when you need to read the database?