A team currently runs an EC2 instance configured as a NAT instance so that private subnet traffic can reach the internet, and they also use that same instance as an SSH bastion host with a custom port-forwarding rule. They are considering migrating to a NAT gateway. Which statement about this migration is accurate?
- The NAT gateway will support the same bastion and port-forwarding functionality, since NAT gateways are simply a managed version of NAT instances with identical features
- A NAT gateway cannot be used as a bastion host and does not support custom port-forwarding configuration; those two functions would need to be moved to a separate instance
- NAT gateways support port forwarding but not bastion functionality
- NAT gateways support bastion functionality but not port forwarding
Why B? And why not the others?
Correct answer: B. A NAT gateway cannot be used as a bastion host and does not support custom port-forwarding configuration; those two functions would need to be moved to a separate instance
AWS's own NAT gateway vs. NAT instance comparison table explicitly marks 'Bastion servers' and 'Port forwarding' as 'Not supported' for NAT gateways, while both are available on NAT instances (port forwarding via manual configuration, bastion usage because it's just a regular EC2 instance you can SSH into and configure freely). So migrating away from a NAT instance to a NAT gateway would lose both capabilities, requiring a separate dedicated instance for bastion access and any custom forwarding rules. Option A incorrectly assumes feature parity; NAT gateways trade away instance-level flexibility for AWS-managed high availability and scale. Options C and D each get half the comparison backwards — both listed capabilities are unsupported on NAT gateways, not just one of them.
Source: AWS VPC docs: Compare NAT gateways and NAT instances