CloudHub is more like a strategy/architecture than a service, right? I mean, it is implemented using a single private gateway connected to multiple gateways. And the main difference for a Transit Gateway (I believe is preferred) is the fact that Transit Gateway implies the connection of VPCs, while I could use CloudHub without a VPC. Is all that correct? Any comments/corrections will be appreciated.
And, BTW, can I really use a Private Gateway while it is detached (in red), i.e., without a VPC?
1 Answers
Hi Fanca,
Jan’s explaination is really good so nothing to add there. However, I would caution on declaring Transit Gateways as preferred. Gateways can simplify your network but there are some reasons why a more traditional transit VPC might be used. Practically speaking, some people don’t like the fact that a Transit Gateway is kind of a black box.
AWS will be the first to say there is no "best" way because of so many different variables. (See AWS Transit Gateway Tech Talk: https://www.youtube.com/watch?v=A_2qq9fFxVU). For the exam, it’s important to know the general use cases where a Transit VPC or a Transit Gateway might be used but I wouldn’t worry about which is "right".
–Scott
A CloudHub is indeed just an architecture where a VPW connects to multiple clients sites with their on premise hardware (logically represented by Customer gateways in AWS) and allows routing traffic between the different offices and from the offices to the VPC. A Transit Gateway is a way to connect multiple VPCs together, and connect it to a DX via a DXGW so it can allow traffic between the VPCs and between the office and VPC. The Transitgateway is a regional contruct, so only VPCs (up to 5000) from the same region can be connected to it. You can connect Transit gateways in different regions to each other though