Hi @MohammedBanabila 

I appreciate your query about setting up connectivity between transit gateways. To ensure that I fully understand your requirements and provide the most accurate information, could you kindly provide an example scenario of what you're aiming to achieve?

For instance, if you're referring to peering two transit gateways within the same region, could you specify if these gateways are part of a common networking strategy? Any additional context you can provide will greatly assist in offering a precise and helpful response.

Best practices suggest that each VPC should be connected to a central transit gateway to facilitate streamlined network management, rather than having multiple transit gateways within a single VPC. 

To maintain the efficiency and manageability of your network architecture, it's advisable to use a singular Aviatrix Transit Gateway per VPC and leverage transit peering to connect multiple regions.  This avoids the complexity and potential routing issues that could arise from having more than one transit gateway in the same VPC. (please, refer to Use AWS Transit Gateway to Access Multiple VPCs in One Region, Single-Region Multicloud Transit Network Workflow and Building a Single-Region Transit Network.

Regarding question (2), are you inquiring about how to manage and allocate public IP addresses within the strict, unchangeable maximum limits set by each Cloud Service Provider (CSP), or are you referring to the initial soft limits that can be increased upon request? 

In addition to the previous question, are you referring to a specific Cloud Service Provider (CSP)? If so, could you please provide the name of the CSP you are referring to?

When designing your network and strategizing around the allocation and management of public IP addresses (question 3), it's crucial to recognize that each Cloud Service Provider has distinct constraints and limits on these resources. According to insights from the Aviatrix community, it is recommended to approach IP management with meticulous planning to avoid depleting your available quota, considering the differing limitations set by each provider. Network designs and IP allocation strategies should be customized on a case-by-case basis to account for these variances and to ensure optimal usage within the given constraints.

Could you please clarify if the core of your question (4) is to determine whether it's necessary or mandatory to assign a public IP address to each spoke gateway?

It should be noted that SNAT for managing and securing outbound Internet traffic from VPCs/VNets is implemented at the Aviatrix Gateway, either at the Transit or Spoke Gateways level. The specific deployment of SNAT will, however, depend on the scenario you are planning for.
 

Cheers,

Nico

my aiming  goal  was  manage and segment  spoke on their network domain and policy  at  same region.

less use  for public ip   at spoke   for example aws  eip  that has quota limit per account.  let transit vpc has contains  two transit gateway that pass traffic to their segment spoke .   those two transit  gateway are in same vpc  pass communication  between spoke gateway by peering those two transit gateway. 

to be accurate on this part  if  mandatory  for deploy  public ip   with spoke gateway 

use those transit gateway be only way out to internet  using nat and implement firewall rule 

Hi @MohammedBanabila 

regarding your first message line “my aiming  goal  was  manage and segment  spoke on their network domain and policy  at  same region.”, ow about considering a dive into Implementing Network Segmentation in an Aviatrix-Managed Network?

Have you had the opportunity to review my previous message and the Aviatrix Best Practices document that I shared? Are we considering deploying two Aviatrix Transit Gateways in the same VPC for a specific reason, or are we discussing implementing an Aviatrix Transit Gateway in High Availability (HA) mode?
 

Cheers,

Nico

yes i  check  it   and  two aviatrix transit gateway at same vpc  and HA  both  

Apologies for repeating the question @MohammedBanabila but could you clarify why there's a need to deploy two Aviatrix Transit Gateways in the same VPC (considering both of them are in High Availability mode)?

each  aviatrix transit gateway  are in  different availability zone so  each transit gateway attached to their spoke gateways that are segment it of multiple spoke vpc as lab diagram  in same region .    for    fault tolerance   to  keep  connection available without interruption   and  failover  scenario

To summarize:

The Transit VPC hosts an Aviatrix Transit Gateway set up for High Availability (HA), consisting of 2 EC2 Instances located in two separate Availability Zones.

Each of the 2 Spoke VPCs contains an Aviatrix Spoke Gateway also configured for High Availability, with 2 EC2 Instances across two different Availability Zones for each VPC.

Have I understood correctly? If so, do you have any additional questions regarding this network setup?

Cheers,

Nico

yes  as  you mentioned .   , no , its clear