Bastion Hosts and Transit Gateway in Multi-VPC environment


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.


Here are some considerations:

  • If you already have a Transit Gateway connecting all the VPCs, this is probably a good idea because you can consolidate the bastion fleet and you can also improve the security posture in most VPCs by eliminating IGWs or tightening up security group rules. (For example, don't allow inbound ssh anymore except on the one remaining bastion VPC.)

  • If you do not already have a Transit Gateway connecting the VPCs, then you need to weigh the costs of each solution in terms of both dollars and complexity:

  • Cost: If you don't already have a transit gateway, you will have to pay an additional hourly cost for each VPC attachment. This would likely be the biggest cost so you can weigh the cost of bastion instances against the attachment. For example, if you used 3 t2.micro hosts per VPC as bastion hosts, you can't save any money with TGW because the transit gateway attachment costs more than that. OTOH, if you use big bastion hosts or your fleet is large, it's quite easy.

  • Complexity: If you don't already have a Transit Gateway, you'll have to weigh the setup costs of of the Transit Gateway (creating attachments and adding routes) against the setup costs of setting up and running bastion hosts. It's likely that running hosts is a lot more work than the TGW setup but neither option is zero-touch.

回答済み 5年前

ログインしていません。 ログイン 回答を投稿する。