How can an ECS Fargate task access an RDS database in another private subnet?

Confirm the ECS tasks and RDS instance have routes through their respective subnet route tables, and check network ACLs if the security group configuration looks correct. The exact error helps narrow it down: a timeout often points to routing, NACLs, or blocked security groups, while a connection-refused error usually means the host is reachable but the service or port is not accepting connections. You can test DNS resolution and the database port from inside the running task.

If both services are in the same VPC, different private subnets normally aren’t a problem. The first thing to check is the RDS security group: add an inbound rule for the database port, such as 5432 for PostgreSQL or 3306 for MySQL, with the ECS task security group as the source. Referencing the security group directly is better than allowing a broad subnet CIDR. Also verify that the task is using the correct RDS endpoint and that VPC DNS resolution is enabled.

If the database and tasks are actually in separate VPCs, they won’t communicate just because both subnets are private. You’ll need VPC peering or a transit gateway, routes on both sides, compatible security-group and network-ACL rules, and working DNS resolution for the database endpoint. For a same-VPC setup, keep the database private and allow access only from the ECS task security group.