I'm migrating an API from SLS to SST and have loca...
# help
s
I'm migrating an API from SLS to SST and have local development working! 🎉 However, I'm having issues when I deploy and I believe it's related to my RDS database being within a VPC.
My assumption is that this works locally for me because I am running a VPN
and my local lambdas are hitting a local postgres I have installed in Docker
which, works surprisingly well
t
This is one of the reasons I switched to data API
Avoids VPN
s
but once I deploy to the cloud, I'm faced with 10 second timeouts in my lambdas which I assume is due to the VPC
t
Does it eventually work?
I ran into this as well
s
I'm my brief investigation into Data API, it appear that it only applies to Aurora Serverless?
I haven't bumped up the timeout yet, but it's certainly work a try
t
Oh right you're not on serverless
s
😢
t
I meant if you keep retrying
If not can you verify your lambdas are in a VPC?
s
They are not, which is what I'm just now learning
t
Ah yeah that's probably it then
s
I've been reading about that this morning, and it sounds pretty awful to set up
there's a lot needed to support the non-serverless RDS
t
It's pretty easy in SST. You have to import the vpc then can pass it into the function
s
hmm, that's definitely worth a try
I'm already provisioning my RDS DB in CDK via SST
wow, that's a lot of acronyms...
and in doing so, I'm already importing an existing VPC
Copy code
const vpc = ec2.Vpc.fromLookup(this, 'VPC', {
        vpcName: process.env.VPC_NAME,
      });
r
Yeah, it's pretty horrid. It's one the reasons we're migrating from MySQL to DynamoDB. Also, if your lambda needs to access RDS and the internet, you're looking at a permanent running NAT Gateway which means additional cost 😞
s
Fortunately, this is an internal service with no need for a public facing interface.
But yeah, this is super lame 😆
This service has well known access patterns, which makes it ideal for DynamoDB
t
The NAT Gateway was what made me jump to dynamo
The RDS DB already exists? Is that why you can't easily use serverless?
s
That's a great question. The RDS database does already exist in this service and I've been doing my best to leave everything as-is while I convert from SLS to SST. The service has been running internally for a year or so ingesting data, but isn't currently used to support any customer facing features. They are finally getting ready to do something useful with this service, so I'm getting it ready for active development and deployment.
Luckily, it looks like I wont need to worry about saving historical data that's been collected over the past year. Thus, I'll have the freedom to change a few things in the persistence layer. However, there are cultural hurdles to overcome 🙂
I know you've been spending time investigating SQL DB options in serverless apps. Within the AWS ecosystem, is Aurora Serverless your current recommendation? The AWS docs imply Aurora v1 isn't good for production workloads and v2 is still in preview.