A startup runs 80 EC2 instances in private subnets with open SSH security groups and shared key pairs for vendor support. Auditors demand no inbound SSH, no long-lived credentials, and full session auditing. Developers still need on-demand shell access. Which administrative access design satisfies all constraints?

Session Manager with IAM and logging to S3 and CloudWatch Logs meets every constraint because the SSM agent makes outbound HTTPS connections so private instances need no port 22 ingress, authorization uses short-lived IAM credentials and instance profiles rather than shared key pairs, full session transcripts are delivered to S3 and CloudWatch Logs for auditors (add S3 Object Lock if immutability is required), and developers keep on-demand shells without bastions or VPN. EC2 Instance Connect with IAM short-lived keys and locked-down groups fails on transport because it is still SSH and requires TCP 22 to remain open to the client, which directly violates the no inbound SSH mandate even with narrow CIDRs and ephemeral keys. Session Manager with private endpoints and CloudTrail API logging only fails on audit depth because CloudTrail logs only the StartSession API call and identity, not interactive session content, so it cannot replace S3 and CloudWatch Logs session transcripts. AWS Client VPN with MFA and centrally managed key pairs for private SSH fails on credential lifetime because SSH user keys are persistent long-lived secrets that require manual rotation and revocation, unlike temporary IAM session authorization. An exam caveat is that hardened SSH is still SSH and API logging is still not session logging, so verify port requirements and log payload. A practical check is to confirm SSM agent and instance profile coverage, VPC endpoints for Systems Manager, enforced S3 and CloudWatch logging, security groups with no port 22 ingress, and removal of old shared keys.