I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC, and anything inside of a VPC needs an IP address, so the Lambda function has to wait ~10 seconds on cold-start for the Elastic IP service.
The only workaround I've heard of is to setup a service, such as CloudWatch, to call your Lambda function every ~25 secs to keep it "warm", but this seems anti-thetical to the value proposition of serverless architecture in the first place.
Of course, you could "just" use DyanmoDB, but IMO the query language is really limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)
> I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)
This is due to the fact that DynamoDB's query API is a standard AWS API which means granular internal/external access can be provided through IAM mechanisms (ie: roles, temporary tokens, federation, etc.).
On the contrary, to access RDS, Redshift or DocumentDB you would use standard ODBC/JDBC/Mongo facilities, which do not rely on IAM mechanisms, leaving VPC/Security Groups as the only isolation option.
Not quite. It’s not the auth mechanism or even the wire protocol. The issue is to accesS traditional resources in a VPC you need to have an IP address within the VPV to route network traffic to/from it. It’d be the same if you ran a DB on and EC2 instance or even ran your own DynamoDB clone with no auth.
AWS services don’t have that issue because they’re accessible from anywhere on the network, even through an internet gateway / internal NAT.
Services with "native" AWS APIs use IAM for granular access management.
Other services can only support access restrictions using the network so that means VPC/Security Groups.
The key is that DynamoDB is just any old web service as far as you code is concerned. Everyone uses the same public endpoint, same domain name, same API, authenticate with IAM. You can also integrate it by using DynamoDB Streams as a trigger for Lambda functions which is of course a purpose-built feature. There is DynamoDB Accelerator (DAX) which is a cacher running in EC2 that runs as a normal VM with an EIP.
TL;DR: RDS and this new DocumentDB are essentially AWS managing your database VMs in EC2. Advantage is drop in compat with regular apps expecting to reach a local server, because it is local to your VPC and uses normal ports. Can make them public accessible via VPC firewall, but less secure that way. DynamoDB was designed from the ground up as an HTTPS API and that's the only way its accessed.
https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat...
I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC, and anything inside of a VPC needs an IP address, so the Lambda function has to wait ~10 seconds on cold-start for the Elastic IP service.
The only workaround I've heard of is to setup a service, such as CloudWatch, to call your Lambda function every ~25 secs to keep it "warm", but this seems anti-thetical to the value proposition of serverless architecture in the first place.
Of course, you could "just" use DyanmoDB, but IMO the query language is really limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)