Does anyone know why after adding a VPC to my lamb...
# help
c
Does anyone know why after adding a VPC to my lambda it causes the lambda to reach the max timeout? I'm trying to setup the VPC so that I can use RDS Proxy
Copy code
// Import VPC
const existingVpc = ec2.Vpc.fromLookup(this, "VPC", {
   vpcId: "vpc-XYZ",
});

// Sample function to connect function to VPC
function: {
    handler: "src/claim/index.handler",
    permissions: claimPermissions,
    vpc: existingVpc,
    allowPublicSubnet: true,
},
I can see that the VPC is correctly attached in AWS console on the lambda page, but running lambda causes it to timeout
t
I think if the lambda is in a VPC it cannot work with live debugging, it's a current limitation
I conditionally set the vpc whether it's running in local or prod mode with
app.local ? vpc : undefined
If it's timing out with an
sst deploy
it's likely there's a misconfiguration in the security groups
c
Ah, does that include trying to run the lambda through the aws console? - the lambda deployed through
sst start
I'll give the sst deploy a shot
t
yeah I believe lambdas in vpcs have some issue with the way we forward requests to your local machine. Although might need @Frank to chime in - don't recall why this was an issue
c
Can confirm deploying through
sst deploy
works, will try and see if I can setup a VPN connection as described here but it seems a bit complex Thanks again for the help!
f
Hey @Colin Cheung, does ur Lambda function make calls to other resources in the VPC? ie. an RDS server?
c
Yeah it does, it calls RDS through the RDS proxy
@Frank Do you know if I need to do any further setup with this guide? I managed to setup a VPN connection to the VPC and was successfully able to connect to my RDS db through the RDS proxy from my local machine using my database client However I still got the same timeout issue, when redeploying via
sst start
and checking cloudwatch the only log is
connectAndSendMessage()
The only thing I didn't do in the guide was to setup DNS resolvers for the VPC Client Endpoint as that really confused the heck out of me, not sure if that has anything to do with it
f
hmm.. i think it’s because
allowPublicSubnet
is set to
true
. The Lambda function can’t access the internet, hence can’t connect to the websocket server.
Any reason to deploy the lambdas into public subnets? just curious
c
Hmm okay that may be problematic, reason is that's how its currently configured in the company I don't really know enough about the networking of the VPC and differences between private & public subnets to say any more on the topic. However currently all 3 subnets that the RDS instance is on is public, should I look into making at least one of them private?
f
Yeah, usually ppl don’t launch RDS into public subnet due to security reasons.
Lemme check something w/ Dax. @thdxr can ur RDS be in public subnet, Lambda in private subnet, and have the Lambdas connect to the RDS?
t
If rds is in public your lambdas don't need to be in a vpc
As long as the rds security group is setup right
But yes there should be not issue for lambda in private connecting to rds in public
s
Chiming in with a similar experience using AWS MSK (Kafka) as an event source for Lambda
The live lambda development environment could not receive messages, but it worked just fine after deployment
The cloudwatch logs for the websocket API were logging 403's, no output locally