AWS Glue job fails to connect to RDS PostgreSQL (Publicly Accessible) — “SocketTimeoutException: connect timed out”

Hi there,

This is a classic but tricky Glue-to-RDS connectivity issue, and it’s great that you’ve already confirmed the basics like VPC, subnet, and security group rules. The key thing to know here is that AWS Glue’s network behavior during job execution is a little different from what most people expect when the connection test passes but the job itself fails. The connection test uses a short-lived network probe from the Glue control plane, while the actual job runs in a container inside your specified subnet and relies on the runtime’s data path configuration. That difference often exposes subtle networking gaps.

Here’s how I would troubleshoot and fix this step-by-step:

Verify Subnet Route and NAT Configuration Even though your subnet is public, check that the Glue job is actually launched in that subnet and not automatically picking a private subnet without a NAT route. If Glue cannot establish outbound traffic to the RDS endpoint due to missing routes or improper subnet mapping, you’ll see a SocketTimeoutException just like this. In the Glue job configuration, explicitly select the subnet you want rather than relying on “default.”

Check Security Group Ingress Rules Your RDS security group should explicitly allow inbound traffic on port 5432 from the Glue job’s security group. In other words, instead of using broad CIDR ranges or default group references, add a rule like:

Type: PostgreSQL Protocol: TCP Port range: 5432 Source: sg-wxyz (Glue job SG)

If you’re using a default security group on both ends, confirm that the Glue job’s network interface is attached to that same SG, since “default” can differ between VPCs or accounts.

Confirm DNS Resolution and Endpoint Reachability Inside the Glue job’s runtime environment, DNS resolution can fail silently if the VPC resolver configuration is off. If your RDS endpoint looks like your-db.wxyz.us-east-1.rds.amazonaws.com, make sure that the subnet running the Glue job has a VPC DNS resolver and that “Enable DNS Hostnames” is turned on for the VPC. A quick test is to run a small Glue Python Shell job that just performs a DNS lookup on the RDS endpoint.

Verify the RDS Endpoint Type If your RDS instance has multiple endpoints (for example, writer and reader, or Multi-AZ failover), check that the connection string used in your Glue job points to the correct one. Using the writer endpoint during maintenance or failover can cause temporary socket timeouts.

Check Connection Properties in Glue Within your Glue Connection definition, ensure that “Network Connection” is properly configured with the right subnet and security group. If you tested the connection and it succeeded, it means the Glue control plane can reach the DB, but the job runtime may still fail if the subnet or security group defined at job runtime differs.

Cross-Account or Region Mismatch If your RDS instance and Glue job are not in the same region or account, the test connection can still succeed through cross-account IAM permissions, but runtime connections fail since the job’s network interface is region-bound.

CloudWatch and VPC Flow Logs The best way to confirm what’s happening is to enable VPC Flow Logs on both the subnet and RDS security group. Look for entries where the Glue ENI attempts to reach port 5432 and whether it’s “ACCEPT” or “REJECT.” This will tell you immediately if packets are getting blocked or timing out due to routing.

If everything looks correct and you still see the timeout, it’s often because Glue is running in a private subnet without a route to the RDS endpoint even though the endpoint is publicly accessible. Public accessibility alone doesn’t guarantee connectivity if the subnet route table or Glue connection setup doesn’t align.

A quick workaround for testing is to create a small EC2 instance in the same subnet as your Glue job, use the same security group, and try connecting to the database using psql. If that fails, it’s definitely a subnet or route configuration issue rather than Glue itself.

To take this further, you could harden your setup by keeping RDS private and connecting Glue through VPC endpoints or AWS PrivateLink for a fully secure data path. That’s the pattern most production environments adopt once connectivity is confirmed.

If you’d like, I can share a reference VPC architecture diagram and Terraform template that shows the correct subnet mapping, route tables, and security group setup for Glue-to-RDS connections across private or public networks. It’s a proven setup I’ve used on several large-scale data migration and ETL pipelines. Would that help?