With the given options, bastion host is the correct answer. However, since AWS has been promoting Systems Manager as a replacement for bastions, I think it will be good to add that option as well. SSM is definitely more secure than a bastion.
For accessing management services like SSH, I tend to agree with you. SSM’s session manager is a good alternative to bastion/jump hosts.
BUT, you still have to be careful with the policy in the IAM role which is assigned to the EC2 instance the SSM agent is running on. As AWS Community Hero Michael Wittig wrote in his great blog article “AWS SSM is a trojan horse: fix it now!” (see: https://cloudonaut.io/aws-ssm-is-a-trojan-horse-fix-it-now/ ), the default AWS managed policy AmazonEC2RoleforSSM is too open and should not be used blindly. Among others, it allows access to S3 and CloudWatch.
Therefore, an "owned" EC2 instance with enabled SSM (+ AmazonEC2RoleforSSM policy) can cause more collateral damage than an "owned" bastion (if you do not leave private SSH keys on it 😉 )
And, as Faye mentioned in a previous lecture, bastion hosts can still be used if you want to "tunnel" non-management traffic through to a host in a private subnet.
UPDATE: AWS marked the managed policy AmazonEC2RoleforSSM as DEPRECATED. Now, AmazonSSMManagedInstanceCore should be used for SSM’s Core functionality. See: https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html
Agree with the additional permissions issue. BTW, SSM also can be used for tunneling now. So even RDP can be done without the need of a bastion.
Thanks for that, Ebin. I did not know that.