A security team wants engineers to connect to private EC2 instances that have no public IP address and no inbound rule for SSH or RDP, without managing SSH key pairs or a bastion host, while keeping a centralized, IAM-controlled, logged record of every session. Which approach satisfies all of these requirements?
- EC2 Instance Connect, since it also avoids opening inbound SSH ports
- AWS Systems Manager Session Manager, using the SSM Agent and an IAM role attached to the instance
- A bastion host in a public subnet with a security group restricted to the engineers' office IP range
- Enabling IMDSv2 on each instance to allow authenticated shell access over the metadata endpoint
Why B? And why not the others?
Correct answer: B. AWS Systems Manager Session Manager, using the SSM Agent and an IAM role attached to the instance
Session Manager connects to managed nodes through the SSM Agent running on the instance together with an IAM role attached to it, using an outbound-only connection to the Systems Manager service, so it needs no inbound SSH or RDP port open, no bastion host, no SSH key management, and no public IP address on the target, while still giving administrators centralized, IAM-policy-based access control and optional session logging to CloudTrail, S3, or CloudWatch Logs. EC2 Instance Connect still relies on SSH over port 22, since it merely pushes a short-lived public key rather than eliminating the SSH connection itself, so it does not satisfy the requirement to avoid inbound SSH access entirely. A bastion host in a public subnet is a workable pattern but still requires a running host, managed inbound access, and typically SSH keys, which is exactly the operational overhead the team wants to avoid. IMDSv2 only hardens how an instance queries its own metadata endpoint from within itself; it plays no role in providing remote shell access to engineers.
Source: AWS Systems Manager documentation: Session Manager overview