1 Answers
You should definitely use a VPN to connect to the Bastion host (or Direct Connect). By only exposing the Bastion host to SSH or RDP connections, you minimize the attack surface because it allows you to connect to your EC2 instances in private subnets without exposing them to any external networks.
Of course there is now the option of using SSM, but you do still need to know about the use of a Bastion host as it will definitely come up in the exam! a Bastion is of course more versatile as you can use it to reach your private instances using protocols other than SSH, like HTTPS or whatever protocols your application uses.
In my opinion, you should establish a VPN (ie. OpenVPN) to your bastion subnet and then jump from there to your public/private subnets. You do not want to allow your users have access directly your subnets public or private where you’re running workloads.
From my point of view in the last years there was a priority order like Direct Connect >> Site-2-Site-VPN >> Client VPN >> Bastion Host. Nevertheless, you can still have both: a Client VPN which is attached to a dedicated Subnet and then connecting to a Bastion host in the "VPN-Subnet" to securely SSH into the private subnet instances. You can add more and more security steps, if needed/required.
I’m inclined to agree with Marcell on this one. The choice "access hosts in the private subnet using a bastion host" makes a lot of best-case scenario assumptions (both in terms of architecture and security configuration). I can see many cases where a private gateway and site-to-site VPN would be preferred over a standalone bastion host (especially if it has inbound ports open to the public). Given the recent critical pre-authentication exploits for remote administration protocols like BlueKeep (CVE-2019-0708) and the latest Remote Desktop Gateway (CVE-2020-0609), the bastion is being phased out by newer models. This was likely one of the driving forces behind AWS delivering SSM.