2

I have an EC2 instance in AWS account A. Its Private IPv4 addresses is 10.111.12.23.

I allowed it in a RDS security group rules in account B, to make Type CIDR/IP - Inbound's Rule 10.111.12.23/32. Also use transit gateway between these 2 accounts' vpc network, route them to let ec2 from account A to access account B.

When I login to ec2 in account A, can't ping the RDS cluster's endpoint. Check ip on the ec2 host, got

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 00:01:b2:31:d0:d2 brd ff:ff:ff:ff:ff:ff
    inet 10.111.12.23/27 brd 10.111.12.43 scope global dynamic eth0
       valid_lft 2390sec preferred_lft 2390sec
    inet6 ze20::202:b3fa:fe31:a0c2/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ed:6d:80:1a brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 ze20::20:b1fa:fl39:712x/64 scope link
       valid_lft forever preferred_lft forever
...

The IP 10.111.12.23/27's subnet is 27 but not 32. So is it the reason can't access the RDS, even it allowed IP with /32 but doesn't work.

And, a little much complex, I also want to access RDS in account B from account A' ec2 instance with docker on it. Login docker container, check its IP:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
117: eth0@if118: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 01:12:lc:22:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.5/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever

It's using the different network IP. So even can connect RDS from ec2 host, can it also access RDS inside docker on it?

Improve this question

1 Answer 1

Reset to default
4

can't ping the RDS cluster's endpoint

RDS typically doesn't respond to ping. Try to connect to it with your mysql or postgresql or whatever client right away without pinging.

Also make sure that all your routing is in order - that both VPCs have routes to the other VPCs through the TGW. The packets must find a way to go from EC2->TGW->RDS and also back from RDS->TGW->EC2.

Unless you have some other uses for TGW you may be better off with a simple VPC Peering for your usecase.

That /27 vs /32 doesn't matter. One is the subnet range and one is the host IP. In the RDS SG it's enough to allow the host IP.

Hope that helps :)

Improve this answer
5
  • Thank you very much. I tested with a db client to connect to RDS, it works! So the IP range doesn't matter and network setting also works. Use VPC Peering also work but doesn't it traffic with slow speed?
    – Miantian
    Commented Apr 20, 2021 at 2:17
  • @Miantian Nope, VPC Peering is the same speed but free (+ data transfer charges same as with TGW)
    – MLu
    Commented Apr 20, 2021 at 2:34
  • By the way, do you know if there is some trouble during the connection, how to debug the transit gateway network layer? Use AWS/TransitGateway with CloudWatch in AWS? But from my end its disable now. I tested most connection successful, but only one failed: psql: error: could not connect to server: Connection timed out. Is the server running on host "xxx-rds.amazonaws.com" (10.121.10.30) and accepting TCP/IP connections on port 5432?. It's in an another account so I think the TGW not work between EC2 and its RDS.
    – Miantian
    Commented Apr 20, 2021 at 8:56
  • @Miantian you can enable VPC Flow Logs on all interfaces in all VPCs and try to correlate where do the packets get lost. It’s usually quite a laborious work though. In cases like that I sometimes spin up another EC2 instance in the same subnet and same sec group as the RDS and use tcpdump on both EC2s to debug the traffic issues.
    – MLu
    Commented Apr 20, 2021 at 10:34
  • Thank you very much for your good methods! I will try.
    – Miantian
    Commented Apr 20, 2021 at 12:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .