Transit gateway and central VPC

I checked your TGW route table screenshot , and while the re:Post Agent provided a good overview, there are a few specific "silent killers" in this setup that you should verify:

1. The Asymmetric Routing Issue (NAT GW Return Path):

While the agent mentioned return routes , it is crucial to verify the specific route table of the NAT Gateway's public subnet in VPC2. Even if the NAT Gateway can reach 8.8.8.8 , the return traffic will fail if the NAT GW's subnet route table lacks an entry for VPC1's CIDR (10.1.0.0/16) pointing back to the Transit Gateway. Without this explicit route, the NAT Gateway does not know how to send response packets back to EC2-VM1 at 10.1.1.10.

see also: https://repost.aws/knowledge-center/transit-gateway-internet-egress-vpc

2. TGW Route Table Validation (Static Route):

Based on your screenshot of the Transit Gateway route table, you have a Static Route for 0.0.0.0/0. It is vital to double-check that the Attachment ID associated with this route is actually the attachment for VPC2 and not VPC1. If this static route points to the VPC1 attachment by mistake, it creates a routing loop where traffic never reaches the NAT Gateway in VPC2.

"Use a separate subnet for each transit gateway VPC attachment. For each subnet, use a small CIDR, for example /28, so that you have more addresses for EC2 resources." source: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html

3. Dedicated TGW-Attachment Subnet in VPC2:

The re:Post agent touches on the TGW ENI subnet, but the specific architecture is key. Best practice is to have the Transit Gateway Attachment in its own dedicated subnet in VPC2, separate from the NAT Gateway subnet. The route table for the TGW Attachment subnet must have a default route (0.0.0.0/0) pointing to the NAT Gateway. If you placed the TGW Attachment in the same subnet as the NAT Gateway, the routing logic can become circular or fail, as the NAT Gateway cannot use itself as a next hop for traffic originating from the TGW interface.

see also: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/using-nat-gateway-for-centralized-egress.html

PS: for learning, hands-on experience is the best experience.... however as a supplement, I recommend the following free AWS Skill Builder trainings:

• https://skillbuilder.aws/learn/HW3UTUHEBY/build-with-aws-transit-gateway/H5Z9G1GFT9
• https://skillbuilder.aws/learn/MEMK249TNV/aws-transit-gateway-getting-started/8DFGZ1Z6X9
• https://skillbuilder.aws/learn/9UKAD6K8DJ/aws-transit-gateway--troubleshooting/ABA8NRHG2U

Based on your setup, there are several routing configurations you need to verify to enable EC2-VM1 in VPC2 to reach the internet through VPC2's NAT gateway via the transit gateway:

1. VPC2 Subnet Route Table (where EC2-VM1 resides): Your subnet containing EC2-VM1 needs a route pointing internet-bound traffic (0.0.0.0/0) to the transit gateway as the next hop. This ensures traffic destined for 8.8.8.8 goes through the transit gateway first.

2. Transit Gateway Route Table: You need a static route in the transit gateway route table pointing all internet traffic (0.0.0.0/0) to the VPC2 attachment. This directs the traffic back into VPC2 where your NAT gateway resides.

3. Transit Gateway Attachment Subnet Route Table in VPC2: The subnet where the transit gateway has its elastic network interfaces (ENIs) in VPC2 must have a route pointing internet traffic (0.0.0.0/0) to the NAT gateway in the same Availability Zone. This minimizes cross-AZ traffic.

4. NAT Gateway Subnet Route Table: The subnet containing the NAT gateway needs:

• A route for 0.0.0.0/0 pointing to the internet gateway for outbound traffic
• A route for VPC2's CIDR (10.1.1.0/24) pointing back to the transit gateway for return traffic

5. Network ACLs: For transit gateway subnets, it's best practice to configure network ACLs with open inbound and outbound rules. Specifically verify that outbound rules include the destination public IP address and inbound rules include the NAT gateway's private IP address.

The key issue is likely missing return routes - traffic can go out but cannot find its way back to EC2-VM1 without proper routing configured in both the NAT gateway subnet and the transit gateway attachment subnet.
Sources
Troubleshoot Transit Gateway internet access through a centralized egress VPC | AWS re:Post
Using the NAT gateway for centralized IPv4 egress - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
Amazon VPC attachments in AWS Transit Gateway - Amazon VPC