Lambda访问RDS（含Internet Gateway）相关疑问及路由表变更后访问故障排查

1. Can I Replace NAT Gateway with Internet Gateway for Private Subnet Resources? #

Great question—let’s break this down based on your use case:

• Public vs. Private Subnet Basics: A public subnet has a direct route to an Internet Gateway (IGW), so resources here can get a public IP and connect directly to the internet. A private subnet intentionally lacks this direct IGW route—instead, it uses a NAT Gateway (deployed in a public subnet) to let resources access the internet without exposing their private IPs to the public.

• For Lambda accessing RDS: If your Lambda is in a private subnet, you can’t use an IGW instead of a NAT Gateway. Here’s why: Lambda functions in private subnets don’t get public IPs. An IGW only works for resources with a public/Elastic IP to initiate and receive internet traffic. A NAT Gateway acts as a middleman—it translates the private IP of your Lambda to its own public IP, enabling outbound internet access while keeping your Lambda’s private IP hidden.

• Exception: If your Lambda is in a public subnet, you don’t need a NAT Gateway at all—you can use the IGW directly. Just keep in mind, putting Lambda in a public subnet isn’t ideal if you want to keep it isolated from direct internet exposure.

2. Why Can’t I Access RDS After Splitting Route Tables? Do I Need a New VPC? #

You definitely don’t need to create a new VPC and migrate—let’s troubleshoot the root cause first:

First, recap your setup change:

Previously, a single route table (with an IGW route) was attached to all 3 subnets. Now you have two route tables: PublicNetwork (2 subnets, IGW route) and PrivateNetwork (1 subnet, no IGW route). Your RDS uses a subnet group containing all 3 subnets.

The Likely Problem: RDS Instance Landed in the Private Subnet #

AWS RDS automatically places your instance in one of the subnets in its subnet group. If it landed in the PrivateNetwork subnet (the one without an IGW route), here’s what happens when you try to connect via SSMS from your local IP:

1. Your SSMS request hits RDS’s public IP (assuming you enabled "Publicly Accessible" on RDS).
2. RDS’s instance (in the private subnet) tries to send a response back to your IP—but the private subnet’s route table has no path to the IGW. Without that route, the response can’t reach you, so the connection times out or fails.

Fixes to Try (No VPC Migration Needed) #

• Check where your RDS instance is running: Go to the RDS console, navigate to the "Connectivity & security" tab, and note the "Subnet" field. If it’s in the private subnet, you have a few options:
  1. Move RDS to public subnets: Update your RDS subnet group to only include the two public subnets (attached to the PublicNetwork route table). RDS will reboot and move to one of those subnets, and since they have an IGW route, responses can reach your local IP.
  2. Add a targeted route to the private subnet’s route table: If you want to keep the subnet private but allow your specific IP to connect, add a route rule in the PrivateNetwork route table: Destination = your local IP (e.g., 192.168.1.1/32), Target = your IGW. This lets RDS send responses only to your IP via the IGW, while other internet traffic still uses the NAT Gateway (if you set that up).
  3. Use a bastion host: Deploy an EC2 instance in the public subnet (with a public IP), allow your local IP to SSH into it, then use SSMS from the bastion host to connect to RDS’s private IP. This is the most secure long-term option, as it keeps RDS completely isolated from the public internet.
• Verify RDS settings: Double-check that "Publicly Accessible" is enabled (if you’re connecting directly) and that your RDS security group’s inbound rule allows MS SQL traffic from your local IP (not just the VPC CIDR).

内容的提问来源于stack exchange，提问作者H.C