Where I should use TGW (Transit Gateway) and where I should use VGW (Virtual Private Gateway)?

Your understanding is correct and well-articulated. Here's a summary to reinforce your points:

Use VGW (Virtual Private Gateway) when:

• You have a single VPC that needs hybrid connectivity to on-premises networks via Site-to-Site VPN or Direct Connect
• You need dedicated, isolated connectivity for a specific VPC without requiring inter-VPC communication
• Your architecture is simple and doesn't require centralized routing management

Use TGW (Transit Gateway) when:

• You need to connect multiple VPCs (potentially thousands) with each other and/or with on-premises networks
• You want centralized routing control - managing your entire AWS routing configuration from a single gateway
• You need a hub-and-spoke model where VPCs only connect to the Transit Gateway to access other connected networks
• You require scalability - Transit Gateway can handle connections across multiple accounts and regions
• You want to consolidate hybrid connectivity (VPN and Direct Connect) to a single gateway
• You need advanced features like equal cost multi-path (ECMP) routing over multiple connections
• You want to reduce operational complexity and management overhead compared to managing multiple VGW connections

The key differentiator is that VGW can only support a single VPC at a time, while Transit Gateway is specifically designed to simplify interconnectivity of tens or hundreds of VPCs while aggregating their connectivity to on-premises resources. Transit Gateway acts as a highly available virtual cloud router that significantly reduces management complexity in multi-VPC environments.
Sources
AWS hybrid connectivity services - Hybrid Connectivity
Community | Design and Create VPC in AWS
AWS Transit Gateway  - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

Your overall understanding is correct.

dedicated, isolated connectivity for a specific VPC

This part requires correction. The VGW itself does not possess a function to enforce isolation. By default, VPCs are completely isolated from one another unless you explicitly configure peering, TGW, or inter-VPC routing. The accurate way to phrase this is: a scenario where both the production VPC and the development VPC need to connect to the on-premises environment independently, but you do not want the VPCs to communicate with each other.

Your understanding is correct.

A Virtual Private Gateway (VGW) is best suited for simple, single-VPC hybrid connectivity — for example, when one VPC needs to connect to an on-premises data center via AWS Site-to-Site VPN or Direct Connect, with no inter-VPC communication required. It works well for small-scale, isolated environments where routing is static and straightforward, such as a production VPC pulling data from a legacy on-prem system. However, VGW lacks scalability for multi-VPC architectures and doesn’t support centralized routing or shared services across VPCs.

On the other hand, a Transit Gateway (TGW) is designed for enterprise-scale, multi-VPC hybrid architectures. It acts as a centralized hub that connects multiple VPCs (across accounts or regions) and on-premises networks through a single attachment point. TGW excels when you need** dynamic, scalable routing, cross-account/cross-region connectivity, or centralized policy enforcement** — for example, attaching a shared firewall VPC or enabling consistent routing rules across dozens of VPCs. While TGW offers greater flexibility and future growth, it comes at a higher cost and complexity, making it ideal for large, evolving networks rather than simple, single-VPC use cases.

In short: Use VGW for simple, single-VPC hybrid setups, and choose TGW for multi-VPC, scalable architectures that require centralized control, shared services, or cross-account/region connectivity.