-> The AWS Transit VPC is a Transit Overlay connection solution between multiple Spoke VPC's and reduces the overhead of configuring mesh of VPN connections between your datacenter to each different VPC's. Rather, the Spoke VPC's just need to connect to the Transit VPC for inter-spoke(VPC-VPC) connectivity and to extend the spokes to connect to the remote network/datacenters. This solution reduces the pain to implement individual IPsec VPN connections from your datacenters to each different VPCs located in different regions.
-> Transit VPC uses the same IPsec VPN environment to connect to different AWS regions as a normal IPsec VPN connection between two different regions. I reviewed the output [mtr and ping] you shared "mtr_result_manual_ipsec.png", "mtr_result_transit_vpc.png" and it looks like you are getting relatively same latency over Transit VPC setup and manual IPsec setup, which is normal as both the setup are using IPsec VPN tunnel between Singapore and Mumbai.
-> VPN tunnels are created over public Internet (one or more ISP) so they are subject to all states on path like traffic congestion,ISP limits, latency, fragmentation, MSS, MTU, and TCP windowing that will affect the traffic. Any disruptions or network changes over the Internet(ISP networks) will also affect the VPN traffic.
-> To conclude, both the setup uses IPsec VPN connection over Internet to connect to different geographical regions and there is no service level agreement provided for Transit VPC setup. Traffic for both the setup will be subjected to all adverse conditions over ISPs network.
-> Transit VPC provides better management in terms of architectural design and is not related to the traffic behavior. Transit VPC makes it easier for customer datacenter to connect to a transit hub which will establish a VPN connections with each different(Spoke) VPC's in different region rather establishing VPN connections separately from remote network to each VPCs in different region. Also, Transit VPC allows you to scale your infrastructure easily.
-> Transit VPC uses the same IPsec VPN environment to connect to different AWS regions as a normal IPsec VPN connection between two different regions. I reviewed the output [mtr and ping] you shared "mtr_result_manual_ipsec.png", "mtr_result_transit_vpc.png" and it looks like you are getting relatively same latency over Transit VPC setup and manual IPsec setup, which is normal as both the setup are using IPsec VPN tunnel between Singapore and Mumbai.
-> VPN tunnels are created over public Internet (one or more ISP) so they are subject to all states on path like traffic congestion,ISP limits, latency, fragmentation, MSS, MTU, and TCP windowing that will affect the traffic. Any disruptions or network changes over the Internet(ISP networks) will also affect the VPN traffic.
-> To conclude, both the setup uses IPsec VPN connection over Internet to connect to different geographical regions and there is no service level agreement provided for Transit VPC setup. Traffic for both the setup will be subjected to all adverse conditions over ISPs network.
-> Transit VPC provides better management in terms of architectural design and is not related to the traffic behavior. Transit VPC makes it easier for customer datacenter to connect to a transit hub which will establish a VPN connections with each different(Spoke) VPC's in different region rather establishing VPN connections separately from remote network to each VPCs in different region. Also, Transit VPC allows you to scale your infrastructure easily.
0 comments:
Post a Comment