ENIs are under ec2 in the console, not VPC, on API/CLI they're all under ec2 together with all networking.
If you click an instance and go to its networking tab you get a list of ENI IDs that are clickable links to the resource, same for vpc and subnet. If you click subnet you can just click the route table tab, so if you're on an instances networking tab the route table is 2 clicks away.
But rather than doing this you could use reachability analyzer that allows you to check routing tables and security groups for a source and destination IP/resource and port on same or different VPCs connected with peering or TGW and it will tell you if you're missing routes or SG rules in either direction. I created a slackbot that allowed our devs to input src/dst IP/domain and port an that used this API to do the check for them, saved a lot of time troubleshooting.
I had an absolutely horrendous time working in Azure a few years ago (as a network engineer), we did have quite a complex setup with custom route tables and Azure Firewall though and VPN connectivity between Azure and AWS, but stuff like their VPN gateway taking 40+ minutes to change instance size on, wtf? I've filed 2-3 bugs to AWS in the almost 10 years I've worked with it, all for newly created APIs/services, they were all fixed within a week or two. I filed 8+ bugs to Azure in the first month using them, none of them were fixed as they had workarounds instead. And their documentation is absolutely useless, I could never trust that I understood what I read correctly, I always had to verify that it worked that way by testing it.
If you click an instance and go to its networking tab you get a list of ENI IDs that are clickable links to the resource, same for vpc and subnet. If you click subnet you can just click the route table tab, so if you're on an instances networking tab the route table is 2 clicks away.
But rather than doing this you could use reachability analyzer that allows you to check routing tables and security groups for a source and destination IP/resource and port on same or different VPCs connected with peering or TGW and it will tell you if you're missing routes or SG rules in either direction. I created a slackbot that allowed our devs to input src/dst IP/domain and port an that used this API to do the check for them, saved a lot of time troubleshooting.
I had an absolutely horrendous time working in Azure a few years ago (as a network engineer), we did have quite a complex setup with custom route tables and Azure Firewall though and VPN connectivity between Azure and AWS, but stuff like their VPN gateway taking 40+ minutes to change instance size on, wtf? I've filed 2-3 bugs to AWS in the almost 10 years I've worked with it, all for newly created APIs/services, they were all fixed within a week or two. I filed 8+ bugs to Azure in the first month using them, none of them were fixed as they had workarounds instead. And their documentation is absolutely useless, I could never trust that I understood what I read correctly, I always had to verify that it worked that way by testing it.