Questions tagged with AWS Transit Gateway

We are facing an issue in our setup. We are unable to see the DNS query traffic in Palo alto firewall, But we can see the response to dns query from dns server to the host machine. We had a support call with palo alto, but we could not find anything abnormal in firewall. Below is the traffic flow and diagram. DNS Traffic : Query from host > Spoke vpc TGW eni > TGW > Transit vpc tgw eni > via local route to route 53 resolver endpoint > default route to GWLB endpoint > firewall > GWLB endpoint > TGW > Spoke VPC tgw eni > Host I need some pointers here.... please provide your inputs

Hi. We are in the process of setting up a Site-to-Site VPN between a TGW and a Customer Gateway . Having downloaded the configuration file, we have been advised by our networking partner that we need to amend the advertised remote-as BGP value. Creating a new CGW only gives the option to change the 'router bgp' value. How can we change the remote-as value to 12345 (for example)? As we are currently stuck with the IPSEC VPN up, but the overall status as DOWN. **#4: Border Gateway Protocol (BGP) Configuration** ``` router bgp 65001 bgp log-neighbor-changes bgp graceful-restart address-family ipv4 unicast neighbor 169.254.x.x remote-as 65000 ``` Many Thanks.

Our standard deployment when we setup VPN with a customer require us to use NAT between our subnet and the customer’s subnet . We need to be independent regardless to the subnets that the customer use and we don’t want to extend our customer networks / subnets to our AWS Tenant Account ,therefore we will need to setup NAT between our internal network and the customer network . This appears to be not supported with AWS VPN and does not seem to be on roadmap. What are some alternatives or workaround that can be used?

Hi, I have created a VPC peering connection between 2 VPCs within the same region. Both VPCs have 1 public subnet each. I configured the required routes for both VPCs that should go through peering connection however I can't ping the EC2 instances in each VPC public subnet. I tried another VPC setup, 2 VPC (VPC A and VPC B) with 1 public and 1 private subnet in each VPC, and then created a peering connection. Further added required routes. In this setup, I can ping successfully as below: Public instance (VPC A) to Private Instance (VPC B) Private instance (VPC A) to Private Instance (VPC B) Public instance (VPC B) to Private Instance (VPC A) Private instance (VPC B) to Private Instance (VPC A) The following pings don't work: Public instance (VPC A) to Public Instance (VPC B) Private instance (VPC A) to Public instance (VPC B) Public instance (VPC B) to Public Instance (VPC A) Private instance (VPC B) to Public instance (VPC A) Can someone have a look and confirm if this is as expected or there is some additional configuration required? I tried all possible configs and even tried to analyze through Network Analyzer but didn't get any solution to make this work. Any suggestion or guidance would be appreciated.

I want to expose the public IP of my ec2 over VPN, I already have a NAT instance that is reachable over VPN with elastic IP below my routes : * TGW routes table 1.2.3.4/32 -> VPC attachment, 5.6.7.8/32-> VPC attachment. * public route table 1.2.3.4/32 -> eni-nat, 5.6.7.8/32 -> eni-instance. * Private subnet route table 10.0.0.0/16->local, 0.0.0.0/0 ->eni-nat. When I try to ping the nat elastic IP it works, but the elastic IP of the instance is not working

I try to attach transmit gateway to ipv6 only subnet, but when treating tgw attachment I am getting error " There was an error creating transmit gateway attachment. Insufficient Free IP Addresses in subnet..." Not sure if this is supported configuration.

Customer with 2 Transit Gateways, both associated with the same Direct Connect gateway. They are looking to consolidate the prefixes on TGW A. Currently they have: TGW A 10.1.112.0/20, 10.1.144.0/20, 10.1.160.0/20, 10.1.176.0/20, 10.1.204.0/24, 10.1.224.0/20, 10.1.241.0/24 etc TGW B 10.1.0.0/20, 10.1.16.0/20, 10.1.208.0/20 and would like to consolidate down to: TGW A 10.1.0.0/16 TGW B 10.1.0.0/20, 10.1.16.0/20, 10.1.208.0/20 My question is, will prefixes be resolved using the longest prefix first? So routes matching the longer subnet masks on TGW B will still be routed, with everything else under the /16 mask being routed to TGW A?

A customer would like to move their service from on-prem to AWS. Their service requires a site-to-site VPN to the client's physical location. The customer has hundreds of clients, and each of the clients may have anywhere between 1-50 locations. This adds up to a lot of site-to-site VPN connections. I have been brainstorming on how to architect this, and I am leaning towards leveraging TGW + site-to-site VPN connection with subnet level separation for each client. This is probably the simplest way of setting this up. Alternative could be to setup self-managed EC2 instances with open source VPN installed in a transit VPC. I suspect this will be more cost effective than the former, but harder to managed. There are still things like overlapping CIDR ranges to address but I am not sure if there are better options. Curious to see if anyone else has run into a similar situation and has any insights. Also are there any limitations I am missing in the above design?

A customer is trying to setup VPC to VPC routing through their on-prem firewall over TGW. The desired behavior is that traffic from VPC-A will route through the on-prem firewall to get to VPC-B. With the current setup, the traffic routes from VPC-A to VPC-B without making it to the on-prem firewall. When we perform a traceroute, the 2nd hop in the path is a 169.254.x.x address, which I believe may be the DXGW or something similar. I can replicate the same behavior If I have a 0.0.0.0 route defined to a nat gateway as well, but in that case the 2nd hop is the nat gateway address. The customer POC setup is as follows: VPC-A - 10.0.0.0/24 VPC-B - 10.0.1.0/24 DXGW connected to DX via TVIF **VPC-A-Route-Table Routes** 10.0.0.0/24, local 0.0.0.0, TGW **VPC-B-Route-Table Routes** 10.0.1.0/24, local 0.0.0.0, TGW **TGW -VPC-Traffic route table** **associations:** VPC-A VPC-B **Propagations:** DXGW **Routes:** On-Prem routes, propagated 0.0.0.0/0, DXGW attachment, static **TGW - On-prem traffic route table** **Associations:** DXGW **Propagations:** VPC-A VPC-B **Routes:** 10.0.0.0/24 10.0.1.0/24 I believe we are missing an explicit route to tell traffic to use the on-prem firewall for routing of VPC to VPC traffic, but I am not exactly sure of the best place to configure that in this scenario.

I just saw a [session][1] about Advanced Architecture with TGW where we show an example of a TGW with 4 attachments (2 VPCs, 1 DGW, 1 VPN). All attachments are associated with the single TGW route table and propagate their routes to it. Nevertheless the RT only shows 3 entries. The presenter says that’s due to DX is leveraged as primary connection to onPrem here and VPN only as a backup. In my understanding of path selection behavior DX propagated routes are preferred over VPN propagated routes. So what is the reason that the RT of the TGW does not show all 4 entries? I’ve built that setup in a lab environment and can confirm that you only see 3 entries there - VPN is missing. Only when you failover to VPN, the DX propagated routes are not shown anymore in the TGW RT. [1]: https://youtu.be/S9fEydjJ9qo?t=844

A Customer is planning to migrate to Amazon EKS, but will be operating their clusters in parallel for a while. They will be leveraging Transit Gateway (TGW) to connect to other VPCs, where database and auxiliary services live. The question is if it is worth it to use VPC Peering in addition to connecting the two cluster VPCs with each other instead of using the TGW for that traffic, as that might be more cost effective.

Is anyone aware of a solution/customer who has implemented the following requirements: 1. They require IPsec over DX 2. They need effective MTU (i.e. original packet not counting IPsec overhead) >= 1500 over IPsec as they don't/can't control host MTU settings, and they use DF 1. They don’t allow ICMP in their network so path MTU discovery is out 2. They don’t like TCP mss-adjust on the IPsec headends One solution I can think of is EC2 IPsec termination in a VPC via Private VIF (this allows the higher MTU). Then VPC attachment (as opposed to VPN) from the VPC to a TGW and deploy automation to handle failover. I also understand GWLB won’t help here as it’s a two-armed appliance (IPsec and ENI out towards TGW VPC attachment)

A customer who is setting up a TGW which will route to an on-prem prefix. For resiliency, the plan is to have a primary route to the prefix through a primary datacenter connected by a VPN tunnel, and a secondary route to the same prefix through a secondary datacenter connected by a VPN tunnel. The thought is that if for some reason both VPN tunnels drop for the connection between the TGW and the primary datacenter, that traffic can still be routed to the prefix through the VPN connection to the secondary datacenter. I know this behavior can be achieved by using more specific prefixes with BGP or by using static routes when defining the route through the primary datacenter. However, I was wondering if there is something more elegant that can be done similar to using local preference BGP communities if we were working with two direct connects. I had also considered using AS Path prepending for this, but in the docs this is discouraged so that the MED value is honored when performing maintenance and need to switch primary and secondary tunnels. Suggestions or confirmation that the above options are the best we can do would be appreciated

A customer has the following question: In linked account `x` I have a VPC which subnets are shared with specific OUs and TGW which also shared with specific OUs. Now account `x` right now is in OU `a` and I want to move it to OU `b` . My question: is there any risk of performing such move of account `x` from `a` to `b` OU? Reason why I am asking is because these subnets, and TGW has business critical apps running in it. In docs I didn't find any notes that would warn about any issues, but can some please confirm if such move is a safe thing to do for the customer.

Customer is looking to deploy an application into a VPC (three subnets) and would like to enable multicast. As I understand it the VPC itself only supports unicast, however the TGW can act as a multicast router. Am I correct that if the VPC is attached to a TGW, and then a multicast domain is created with the three subnets attached, then the customer will set the result they're after? What are the cost implications of the set up?

Is the dynamic routes advertised from a customer gateway device to a Site-to-Site VPN connection on a Transit Gateway (TGW) limit of 100 per attachment or aggregate? What happens if there are multiple VPN attachments to the same TGW? Say I have a VPN to the TGW and I’m learning 75 routes there from propagation, and then another VPN attached to the TGW with another 75 routes advertised there. Will that have any issues, since it will be 150 routes learned to the TGW? Is the total aggregate to the TGW or per connection and then limited to the total 10,000 total routes per TGW?

Hi, IHAC who is looking for a solution to access their S3 VPC Endpoints in one VPC from another VPC in another region/account. They have set VPC Peering in between. **Source VPC:** - **region**: us-east-1 - resources in private subnet - vpc peering established with Destination VPC **Destination VPC:** - **region**: ca-central-1 - resources in private subnet - vpc peering established with Source VPC - S3 VPC endpoint created Now, from Destination VPC, the S3 VPC endpoint is accessible on regional S3 url: `s3.ca-central-1.amazonaws.com` However, the S3 VPC endpoint is not accessible from the Source VPC. Is there something different that we need to do to achieve this?

My customer has a Direct Connect Gateway and an Transit Gateway association. They asked a question if the TGW ASN will be visible on the on-prem side e.g. via the AS path list on received routing updates?

Two of my customers want to use DX (with VPN) connected to a TGW with an additional VPN failover. They want to avoid routing traffic over that failover link unless the primary DX isn’t routing traffic. All VPN connections seem to default to ECMP if you enable ECMP on the TGW, meaning all traffic is split across all VPN links all the time. Could you do BGP route manipulation on the on-prem side to achieve this? A combination of advertising a lower-cost route for AWS->on-prem traffic, and AS path prepending for on-prem->AWS?

When setting up a VPN connection to Transit Gateway, is there way to control which routes are propagated across the VPN tunnel via BGP?. Currently, any new attachments to the Transit Gateway will propagate the subnets across the VPN tunnels. How can a user control which IP ranges are propagated and how can they only propagate certain custom ranges?

Can I attach a VPC to two different TGW's in the same region?

Hello, I have a customer that is looking at migrating their existing PrivateVIF/DXGW/VGW setup to use TGW. The new setup will preferably be using TransitVIF/DXGW/TGW/VPC. Has anyone executed this change? In this case, for minimal downtime, is it feasible to setup transitVIF/DXGW/TGW/VPC as a passive link to the original connection and failover? If it is possible, how do we handle the moving parts such as: 1) VPC Route tables changes, TGW routing 2) Can we use AS-Path prepend, Local pref to make sure that the redundant link of transitVIF/DXGW/TGW/VPC be the passive link until failover? Thanks

A customer needs to establish a site-to-site VPN connection with a provider that does not allow both VPN tunnels that AWS generates, to terminate on the same customer gateway. Does the native AWS VPN solution allow Tunnel 1 from a site-to-site VPN connection to terminate on customer gateway 1 and Tunnel 2 to customer gateway 2 for example?

A customer has an on-premise data platform (Hadoop) which gets data from third party Oracle DB Read Replica (hosted on EC2 instance of AWS system owned by said 3rd party). Migration of this data platform to AWS has been considered. There is a question on method of connection between this migrated data platform (on AWS) and the 3rd party read replica (in a separate AWS env). One of the suggestions is VPC sharing, which for security reason, is not allowed. What other options can they consider for connecting their VPC to this separate VPC that's owned by the 3rd party? Site-to-Site VPN, TGW are some of the suggestions but would love to hear some recommendations.

Consider a setup similar to: DC1: 192.168.1.0/24 DC2: 192.168.1.0/24 VPC1: 10.0.0.0/16 VPC2: 10.1.0.0/16 You want to use a Transit Gateway and site-to-site VPN to connect each on-premises data center with one of the VPCs. Is this possible if the DCs have the same CIDR Ranges? How does the TGW know where to route traffic back?

When I added the VPN to a transit gateway attachment, the VPN route was automatically propagated through BGP to the routing table on the transit gateway. 1. Is this an expected behavior for routes to propagate automatically when the routes are added to the attachment? This can cause a communication problem. The IP CIDR that is in use by the on-premise server engine might conflict with the VPC CIDR range. 2. Is there a way to disable the route propagation setting for BGP on the routing table of the transit gateway?

Looking for some clarity on how Transit Gateway (TGW) to Transit Gateway pricing works. Do we configure/price that as 1 attachment per TGW? Or 1 attachment total between the 2 TGW instances? With regular VPC/VPN peering attachment, the same attachment is charged once, however with TGW - TGW, seems that we may be charging the attachment twice (1 per TGW).

Does an Amazon VPC transit gateway attachment in "Failed" status automatically get deleted after a short period of time? For example, a failed NAT gateway is automatically deleted after about an hour.

For customers who are using Transit VPC and now moving to Transit Gateway, is there any migration tool available?

Hello, We are working with a client that has the following setup: 1 TGW that has 5 VPC attachments - non-prod a attachment - non-prod b attachment - prod-a attachment - prod-b attachment - shared-services attachment **Requirements:** The client would like to allow only for inter-communication of both the non-prod VPCs, as well as the prod VPCs. Additionally, the client would like for shared-services to be able to reach any of the VPCs. **My initial approach and the problem:** Initially, my thought was to create 3 isolated routing domains, which were represented by 3 separate TGW route tables. I was unable to achieve this because there is a limitation of only being able to associate 1 attachment with 1 TGW route table. If we were able to make more than one attachment for the same VPC, we could get around this issue, but unfortunately that is not possible. **Looking for recommendations on the best way to address the above requirements.** The only other option I can think of to accomplish these requirements is to use 1 TGW route table, associate all of the attachments with it, and then ultimately use NACLs in the individual VPCs to restrict traffic. To me, this seems like a pain to maintain, so I wanted to see if there are any other ways to address this problem. ---------- **More Information on what I've already tried** My initial idea was to have 3 TGW route tables (one for each "routing domain"): - non-prod (associated with the non-prod-* attachments) - prod (associated with the prod-* attachments) - shared (associated with all attachments) The problem with this approach is the **shared** TGW route table because as I mentioned above, you can't associate an attachment with more than one route table. In essence this is a "flat" routing architecture rather than isolated and directly contradicts with what I'm trying to do causing this problem. Thanks in advance!

Customer has implemented TGW and initially had very limited east/west routing in place (just service account, DX , etc). They are now increasingly needing to implement connectivity between VPCs and due to the large number of AWS accounts involved don't want to use VPC peering. They are considering opening up the routing to allow all the accounts to route to each other but then need a way of securing access for some of them. The TGW ENI's all terminate in dedicated subnets in each account and one option they are wondering about is to use NACLs in each of these subnets to control access to/from the transit gateway and other accounts. Does this sound like a workable solution or is there an alternative/best practice option for doing this? Thanks

I am not able to find any reference for TGW Peering Jumbo MTU support, can you please confirm if this is supported? I can see in the VPC docs, that inter-region VPC peering doesn't support Jumbo frames, since TGW Peering also uses the same architecture (I believe) it should also not support Jumbo MTU. I tried a test (EC2 to EC2 across TGW Peering with DF bit set) and it works up to 8500 MTU. Apologies if I am missing something very obvious here. ``` h-4.2$ ping -M do -s 8472 10.2.1.167. PING 10.2.1.167 (10.2.1.167) 8472(8500) bytes of data. 8480 bytes from 10.2.1.167: icmp_seq=1 ttl=253 time=73.3 ms. 8480 bytes from 10.2.1.167: icmp_seq=2 ttl=253 time=72.4 ms. 8480 bytes from 10.2.1.167: icmp_seq=3 ttl=253 time=72.5 ms. 8480 bytes from 10.2.1.167: icmp_seq=4 ttl=253 time=72.3 ms. ^C. --- 10.2.1.167 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms. ```

A customer is going through the HIPAA compliance audit is asking why VPN is not listed under HIPAA eligible services where as TGW is: https://aws.amazon.com/transit-gateway/faqs/ Q: With which compliance programs does AWS Transit Gateway conform? A: AWS Transit Gateway inherits compliance from Amazon Virtual Private Cloud (Amazon VPC) and meets the standards for PCI DSS Level 1, ISO 9001, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, FedRAMP Moderate, FedRAMP High and HIPAA eligibility.

How would an organization that currently uses VPC peering move to Transit Gateway given that the same routes that currently exist between VPC peers would need to be set up for Transit Gateway routing.

A customer in the telco industry wants to leverage Outposts for multicast applications. Questions: 1. Transit Gateway now supports multicast. Will it work for Outposts as well when Direct Connect or site-to-site VPN is in between Outposts and region? 2. Even if #1 is possible, traffic goes back to the region. Is it possible to leverage Local Gateway (LGW) for multicast in Outposts and customer's local network?

Customer has an existing VPC with 2 subnets which are attached to a Transit Gateway. The subnet is running out of available IP space. So they added a new CIDR range to the VPC and added two subnets (Subnet 3 and 4). Subnet 1 and Subnet 3 share the same AZ while Subnet 4 is in a new AZ. When attaching the new subnets to the Transit Gateway, you can select Subnet4 to be attached. Since Subnet 1 and Subnet 3 are in the same AZ, the Transit Gateway attachment option allows you to select only subnet 1 or subnet 3. The question is whether Transit Gateway will know a route/path to subnet 3 if the transit gateway attachment is not explicitly made. In another word, would you need to detach subnet 1 from the Transit Gateway attachment and attach subnet 3?

We can associate multiple TGWs to DX GW. Could we route in following scenario? Transit Gateway (account-1) to Direct Connect Gateway (account-2) to Transit Gateway (account-2) , all within same region or inter-region? Initial thoughts are NO, because we can: - Either do TGW to TGW peering (inter-region only?) - Or attach VPC from account-2, direct to TGW in account-1 (same region only?)

Does Transit Gateway support detailed monitoring (i.e. 1 minute interval)?

A customer has asked the following question: > "What is the scalability of Transit Gateway based multicast? For example, when 10 VMs are created within a single Placement Group Cluster, can we have 5 multicast sessions, each transmitting at 12Gbps?" I'm assuming that the EC2 acting as the multicast source would be limited to the normal 5Gbps bandwidth for single-flow traffic, which would be the limiting factor here, but wanted to check that multicast traffic wasn't treated differently in some way and hence subject to different limits. I'm also assuming that the multicast group address wouldn't be counted as being within the cluster placement group and so wouldn't get the 10Gbps limit instead. Could someone more knowledgeable validate my assumptions please! Thanks!

A customer has the below set-up: Branch Subnets----(Layer 2)----> Data Center Subnets ------(VPN Tunnel via AWS Transit Gateway)--------->Transit VPC(AWS)------(VPC Peering)-----> Citrix VPC(AWS)-----(VPC Peering)----> Prod VPC(AWS) Some constraints: 1. Prod VPC and Data Center Subnets have overlapping CIDRs as few servers have IP address affinity. 2. Direct VPN connectivity between branches and Citrix VPC would not be possible immediately Problem - They need to get printing working from Citrix VPC EC2 instances to the printers in Branches. What would be recommended implementation approach for IP forwarding for printing to work knowing the above constraints?

We know Direct Connect and the DX Gateway can support Jumbo Frame (8500 for Transit Virtual Interface/9001 for Private Virtual interface), but does the TGW to VPC peering connection support Jumbo Frames? Trying to determine if we could even get jumbo frames all the way from an EC2 instance in a VPC connected to a TGW back to a customer CNF via Direct Connect.

Is same Payer ID required for cross-account TGW peering? A customer is wanting to peer with multiple 3rd parties using DGW. I understand that cross-region and cross-account TGW peering is supported. However, it's not clear if cross-account peering requires the accounts to have the same Payer ID, similar to how associations between TGW and DXG in separate accounts do.

What is the best practice and downtime for migrating an existing AWS environment to use the Transit Gateway? For example, if there are currently separate VPCs, each with access to the Internet, which will be migrating to use the Transit Gateway with traffic sent through a central egress VPC to the Internet, what is the best practice for migrating this environment and the downtime involved? Thanks!

As per https://aws.amazon.com/transit-gateway/pricing/ "Price per AWS Transit Gateway attachment" i.e. 5 or 7c /hr https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html "When you attach a VPC to a transit gateway, you must specify one subnet from each Availability Zone to be used by the transit gateway to route traffic. Specifying one subnet from an Availability Zone enables traffic to reach resources in every subnet in that Availability Zone." Does this mean for a VPC with 3 AZs/Subnets , customers would pay 3 x 7 = 21 c/hr for a VPC ?

At the time of writing, the [pricing][1] page does not explicitly mention pricing for this new feature. Would it be correct to assume that you pay the attachment costs for each peered TGW and inter-region) traffic costs (as in VPC peering)? [1]: https://aws.amazon.com/transit-gateway/pricing/

Is it possible to update an existing Transit Gateway to alter the default route table used for association and/or propagation? My customer wants to use these default features but needs them to be different tables. When creating a TGW it seems you cannot get it to create 2 separate tables for these settings. Hence i would get one auto created and then hope to be able to update the TGW afterwards to change one of them to a different table.

A customer currently has a VPN connected to a VPC with a VPG using static routing. They would like to switch to have a Direct Connect connected to a Transit Gateway which is connected to the VPC. They are wanting to know how to do this migration with limited downtime. I've tried to find any guides around doing this type of migration, but haven't been able to find anything. I'm assuming that this is a little trickier due to them using static routing on the existing VPN connection, but not sure how or if that would change anything. Any guidance on this process would be helpful. Thanks!

Customer has an AWS Landing Zone (ALZ) implementation where they are sharing a Transit Gateway (TGW) between accounts. Sharing a TGW results in error unless `Allow external accounts` is checked, even though the account is in the same organization. The account that they are trying to share the TGW with, is under the same root Organization by ALZ and AWS Control Tower configuration Why these accounts are considered externals?. Once allow external accounts is checked the TGW can be shared and the principal type shows "Account (External)"

A customer has a large number of VPCs with EC2 bastion hosts in each one. Is Transit Gateway a good solution to allow a much smaller number of bastion hosts to provide access to all the VPCs? Or are there any drawbacks to this approach? The number of VPCs has grown recently and spending on bastion hosts is now a fairly significant line item by itself. The customer would obviously like to reduce spend on bastions. Longer term, the customer is evaluating alternatives like AppStream or System Manager.

We are working with a customer on a new project to simplify their routing decisions using a Transit Gateway with 2 route tables. As part of evaluating their requirements and growth needs, I can’t find any information about the propagated routes limit per route table in the limits page (https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-limits.html) Does anyone know how many propagated routes can be imported into a specific route table? For example, how many propagated routes such as 10.192.0.0/16 or 10.194.0.0/16 can be added to a TGW route table?

I believe the answer is yes but just wanted to double check.

Who is responsible for data transfer OUT charges when the transfer is originated by a VPC in one account, and that data passes through a Transit Gateway in another account on its way out through a Direct Connect (DX and TGW owned by the same account)? ***Details*** With the recent announcement on Direct Connect granular cost allocation (https://aws.amazon.com/about-aws/whats-new/2019/10/aws-direct-connect-aws-direct-connect-announces-the-support-for-granular-cost-allocation-and-removal-of-payer-id-restriction-for-direct-connect-gateway-association/), it is stated that we now "allocate Data Transfer Out charges to the AWS account responsible for the Data Transfer." I have a customer who acts as a transport service provider, and they own multiple DX connections that they plan to connect to Transit Gateways via a Transit VIF and DX-GW. The customers of my customer have VPCs in separate accounts that will be connected to my customer's TGW. With my customer owning the TGW, I am unclear on whether the cost allocation per the above announcement will consider the owner of the TGW responsible for the data transfer OUT, or whether that responsibility will be attributed to the owner of the VPC that originated the transfer. Also, if traffic routes through a firewall or IPS in Transit VPC owned by the DX an TGW owner on the way out of AWS, will that change the consideration of cost allocation?

A customer needs to connect his site to a Transit Gateway (which will be connected to several VPCs) using a Palo Alto firewall on premise, following this standard architecture (https://docs.aws.amazon.com/en_pv/vpc/latest/tgw/transit-gateway-isolated-shared.html). Key aspect is they want to connect without using BGP. As described in this AWS doc (https://docs.aws.amazon.com/vpc/latest/adminguide/GenericConfigNoBGP.html), it should be possible to do so in environments with other manufacturers. However, Palo Alto is not listed as one of the devices with a template for not using BGP. The Palo Alto documentation (https://docs.paloaltonetworks.com/prisma/prisma-access/prisma-access-panorama-integration/secure-your-public-cloud-deployment-with-prisma-access/onboard-aws-vpcs) describes how to connect to such transit gateway using either static routes, default routes or BGP routing, so I assume it would be possible to do so. Anybody has faced a similar requirement from a customer and could confirm or deny my proposal?

I have a customer who is using Transit Gateway in a central network account for VPC to VPC connectivity with other accounts and with their on premise network. They have the following questions about Transit Gateway. 1. Will Transit Gateway support route filters? 2. Are there any recommendations when they need more than 100 routes propagated on a DX connection? We have already discussed summarizing routes, but this is a large client and they will likely need more than the 100. 3. Is there an option for BGP on a Transit Gateway VPC attachment. The reason for this is they are running Cloud ASAs in a VPC and want to propagate the routes between the ASAs and the Transit Gateway.

Is a Transit Gateway, configured with ECMP and multiple VPNs advertising the same CIDR range, flow aware to prevent asynchronous routing?

Customer has multiple VPC's and is looking to avoid creating an S3 endpoint in each VPC. Is there a way for transit gateway to allow cross VPC endpoint communication?

I have a 500Mbps hosted Direct Connect. Is there a way to connect this to Transit Gateway?

With reference to the Direct Connect limit "[Number of prefixes per AWS Transit Gateway from AWS to on-premise on a transit virtual interface][1]" (20). My interpretation of this is that if you had, say, 25 VPC attachments on a TGW, 5 CIDRs would not be advertised to the Customer Gateway. Are the 5 prefixes just suppressed from BGP Updates? Does the BGP neighbor relationship take a hit (similar to exceeding the inbound prefix limit)? How are others designing around this limitation in situations where the customer has > 20 VPC attachments? [1]: https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html

I have a customer that is trying to setup a Direct Connect into both a commercial account and a GovCloud account and associate it with a Transit Gateway. It looks like the recommended way to do this is to create a Direct Connect Gateway in the commercial account and that will get automatically propagated to the associated GovCloud account. From there you can associate a Transit Gateway to the corresponding Direct Connect Gateway. My question is how do you set this up if you need to have VPN over Direct Connect for the GovCloud account (and potentially not need it for the commercial account)? I see other posts that talk about configuring VPN over Direct Connect and then associating the VPN with the Transit Gateway. Would you use this method for the GovCloud account and then the DX -> DXGW -> TGW method for the commercial account? Thanks

A customer would implement a multi account, multi VPC infrastructure and use Transit Gateway to connect all the Account/VPC. The customer would also connect his on-premises dc to the transit gateway by a DX connection. He would use SD-WAN device to improve the connection between the on-premises dc and the AWS cloud. Do we have a reference architecture on how to use SD-WAN devices and transit gateway?

When a Transit Gateway (TGW) is created, either in CloudFormation or in the console, several properties can be configured, specifically: - AutoAcceptSharedAttachments - DefaultRouteTableAssociation - DefaultRouteTablePropagation - Description - DnsSupport - VpnEcmpSupport Once the TGW is created, Is there a way for a user to change these properties after creation without having to re-create the TGW again?

One of my customer want to connect with their customers in the following scenarios:- Scenario with their Customer A Their Customer A has a Direct Connect and they need to get connectivity to private APIs that are in their Customer A's on premise data center. I think they can use PrivateLink. Need confirmation/validation and also things to watch out for (things that might not be supported etc.). https://aws.amazon.com/blogs/aws/aws-privatelink-update-vpc-endpoints-for-your-own-applications-services/ Scenario with their Customer B Their Customer B has a Direct Connect and wants to leverage Transit Gateway with multiple VPC to achieve something similar. Again need validation if this approach works and things to watch out for. https://aws.amazon.com/blogs/aws/use-aws-transit-gateway-direct-connect-to-centralize-and-streamline-your-network-connectivity/ Also, what should be our recommended option or pros and cons of the two solutions.

A customer is looking to attach DX's to multiple VPC's via Transit Gateway. DX's are connected to Transit Gateways via DX Gateways. DXGW's can receive and propagate routes to a VPC via BGP. Is it correct to say: 1. DXGW and TXGW can exchange routes advertised to DXGW from on-prem to the TXGW route table 2. Since TXGW can't propagate routes to the VPC routing table, one loses the ability to propagate on-prem routes to the VPC routing table via BGP, therefore requiring statics? Looking for guidance on how route propagation flows through the stack.

Hello, A customer recently asked me how highly available is Transit GW. It becomes a crucial element in an infrastructure, connecting multiple VPCs/VPNs together. I didn't find public documentation or FAQ entry on Transit GW being highly available or having a reliability engineering goal. I understand Transit GW leverages HyperPlane, perhaps I need to dig deeper here. [1]: https://aws.amazon.com/legal/service-level-agreements/