Auditors require that administrators can no longer connect to private EC2 instances over SSH on port 22, yet engineers still need an interactive shell for troubleshooting, with every session command logged to CloudWatch Logs for review. The instances run the SSM agent and have no public IP. Which approach meets the access and logging requirement with the least network exposure?
- AOpen SSH only from a bastion host in a public subnet and forward the bastion authentication logs to CloudWatch Logs so administrators retain an audited shell path.
- BUse Run Command to send individual troubleshooting commands to the instances and store the output in CloudWatch Logs so administrators avoid opening an SSH connection.
- CUse Session Manager to provide the interactive shell through the SSM agent and enable session logging to CloudWatch Logs, keeping inbound SSH closed. Correct
- DAttach an internet gateway and a security group that allows SSH from the corporate IP range, then send the instance SSH logs to CloudWatch Logs for the auditors.
Why A is wrong: A bastion still relies on port 22 and an internet-facing host, which the auditors are removing, and bastion logs capture connection events rather than the commands typed inside each interactive session.
Why B is wrong: Run Command executes discrete documents and returns their output but gives no live interactive shell, so engineers cannot troubleshoot iteratively the way an open session allows.
Why C is correct: Session Manager opens a shell over the agent and the Systems Manager service with no inbound port, and its logging feature streams session command output to CloudWatch Logs, meeting both the no-SSH and full-audit requirements.
Why D is wrong: This keeps SSH on port 22 open and adds internet reachability to private instances, directly contradicting the requirement to remove SSH access and minimise network exposure.