3
votes

I was running a serverless web application on a lambda inside a VPC, and connecting to a Aurora-MySQL RDS instance, with inbound rules to allow traffic from the security group of the lambda The connection was working fine, however, quite often the lambda cold start was giving me a timeout. After some research, I found out that running a lambda on a VPC brings an additional cost on startup and I saw the recommendation in more than 1 place to avoid using lambda on a VPC except if you strictly need to access some resource in the VPC.

So, I decided to move my RDS to a publicly accessible instance, so my lambda can access it over the internet and remove the lambda from the VPC.

So, I changed the RDS Public accessibility option to Yes and edited the security group to allow inbound connection from any IP. I have also removed the VPC from the lambda, so the lambda is not running on a VPC anymore I thought it was gonna be enough.

But then my lambda started failing to connect to the database I tried to connect using my local client, again, failure

tried pinging to the hostname, got request timeouts

After digging a bit into it, I found that my DB instance subnet group having some private subnets might be a problem (?) So, I have created a new subnet group with only public subnets, and tried to move my db instance to the new subnet group... but got this message:

You cannot move DB instance my-instance to subnet group my-new-group. The specified DB subnet group and DB instance are in the same VPC.

Ok, it seems that I can't move to a different subnet in the same VPC, I started trying to create a new VPC, but it doesn't seem to be right and I'm sure there is something else I am missing here.

I also read about Network ACL, and thought that this might be the problem, but my rules seem to be fine, with the default rule to allow any traffic (and the rule * to DENY)

ALL Traffic ALL ALL 0.0.0.0/0 ALLOW

My RDS Network settings

Subnet group
default

Subnets
subnet-11111111
subnet-22222222
subnet-33333333
subnet-44444444
subnet-55555555
subnet-66666666

Security
VPC security groups
default (sg-111111)
( active )

Public accessibility
Yes

My Security group inbound rules

Type Protocol Port range    Source  Description - optional
All traffic All All 0.0.0.0/0   -
All traffic All All ::/0    -

Still can't connect, can't connect with my local client, can't even ping it:

Connecting through my local client

Can't connect to MySQL server on 'my-instance.xxxxxxxxxx.us-east-1.rds.amazonaws.com' 
ping my-instance.xxxxxxx.us-east-1.rds.amazonaws.com
PING ec2-xx-xx-xx-xx.compute-1.amazonaws.com (xx.xx.xx.xx): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

Any idea of what I am missing here?

UPDATE

My VPC has internet access (I can access internet services from it, not an issue), I have an Internet Gateway and NAT Gateway in place.

I'm using Zappa for the lambda deployment, which takes care of creating a keep-warm function... however, I know that concurrent requests could still be an issue

The issue with VPC in lambda is that it can add 10s on the cold start, which is a no-deal for some of my use cases: https://www.freecodecamp.org/news/lambda-vpc-cold-starts-a-latency-killer-5408323278dd/

2
The "cold start in a VPC" issue has been fixed by AWS (see Announcing improved VPC networking for AWS Lambda functions | AWS Compute Blog). It is unlikely you will need to do all that pre-warm stuff now.John Rotenstein
@JohnRotenstein Amazing! Thanksdfranca

2 Answers

2
votes

Besides enabling "public access" on your RDS instance, you need to enable internet to the VPC using an internet gateway. After you attach it to the VPC, you need to route the data from the database subnets to the internet gateway. Check here

But I would not advise you expose your database like this. If you are having issues with lambda cold start, you should create an event to keep it warm.

1
votes

Things you need to is :

  • Create new subnet group with default VPC
  • assign two subnet for availability zone
  • then modify your RDS instance
  • change subnet group to newly created group
  • mark "Publicly accessibility" to Yes.
  • Check your VPC is using internet gateway or not.

Check lambda security group whether it's open for outbound connection for Database port is not available or not.

No need to create different VPC for RDS. Use Default VPC.

As recommended by @stargazer try to not to expose publicly or out of VPC. Its works well inside VPC.