Auditing and Logging Admin Sessions

Granting administrative access is only half the job; you must also record what administrators do. Session Manager provides rich logging so every command and session is accountable. The SCS-C02 exam stresses this auditability as a core advantage over SSH, where command-level logging is hard to centralize.

Session Manager logging has two layers: API-level logging of who started and stopped sessions, captured by CloudTrail, and session-content logging of the actual keystrokes and output, sent to CloudWatch Logs or S3. Together they answer both "who connected" and "what did they do."

CloudTrail records the StartSession and TerminateSession API calls, showing which IAM identity connected to which instance and when. Because these are management events, they appear in your trail automatically, giving a reliable, tamper-evident record of administrative access for investigations.

To capture the commands and output inside a session, you enable session logging in Session Manager preferences, directing it to an S3 bucket or a CloudWatch Logs group. Now every keystroke an operator types and every result returned is stored, the closest thing to a video recording of the session.

Session logs are evidence, so they must be tamper-resistant. Store them in a dedicated, locked-down S3 bucket, ideally in a separate logging account, with encryption and restrictive policies. This ensures an administrator, even a malicious one, cannot delete the record of their own session.

You can require KMS encryption for both the live session data and the stored logs. Enforcing encryption means session content is protected at rest and in transit, meeting compliance mandates and ensuring sensitive commands or outputs are never exposed in plaintext.

Beyond interactive sessions, SSM Run Command executes commands across many instances at once, and it is fully audited too. Each invocation is logged with who ran it, on which targets, and the output, so even fleet-wide administrative actions carry the same accountability as a single session.

You can wire session events to EventBridge and SNS to get real-time alerts when a session starts, especially on sensitive instances. A notification the moment someone connects to a production database server lets your security team watch privileged access as it happens, not after the fact.

Complete session auditing supports incident response, compliance, and deterrence. Knowing every action is recorded discourages misuse, and when an incident occurs, investigators can replay exactly what an operator did. This end-to-end accountability is a decisive reason the exam favors Session Manager over key-based SSH.

You can tighten sessions further by using SSM documents that limit a session to specific actions, and by disabling interactive shells for certain roles. Combined with logging, this means even an authorized operator is constrained to approved activity, narrowing what a compromised account could do while every action stays recorded.

Session Manager auditing combines CloudTrail for StartSession/TerminateSession API events with session-content logging to S3 or CloudWatch Logs, optionally KMS-encrypted. Protect logs in a locked-down, separate account, audit Run Command the same way, and use EventBridge/SNS for real-time alerts on privileged access.

Test session auditing.

Session Manager auditing has two layers: CloudTrail records StartSession/TerminateSession API events, while session-content logging sends keystrokes and output to S3 or CloudWatch Logs, optionally KMS-encrypted. Protect logs in a separate, locked-down account, audit Run Command too, and alert in real time via EventBridge/SNS.