AWS SSM Session Manager: Replace SSH Logging Guide

Every open SSH port is an attack vector. Every unmanaged key pair is a breach waiting to happen. Every bastion host is infrastructure you should not need. AWS Systems Manager Session Manager eliminates all three by providing secure, IAM-controlled, fully auditable shell access to EC2 instances without opening inbound ports. This guide covers the complete implementation — from IAM policies and SSM Agent configuration to CloudWatch log streaming, S3 session archival, CloudTrail integration, and VPC endpoint setup for private instances.

Key Takeaways

✓AWS SSM Session Manager provides secure shell access to EC2 instances without opening inbound port 22, managing SSH keys, or deploying bastion hosts — eliminating three major attack vectors simultaneously

✓Access control shifts from key-based authentication to IAM policies, enabling granular per-user, per-instance, and per-condition access control with MFA enforcement and time-based restrictions

✓Every session is fully auditable — all commands and output can be logged to CloudWatch Logs and archived to S3, while CloudTrail captures the management-plane API calls for compliance reporting

✓For private instances without internet access, VPC endpoints enable SSM communication over the AWS private network — no NAT gateways or public IPs required

✓At Boundev, we implement SSM-based infrastructure access as part of our software outsourcing engagements — from IAM policy design and Session Manager configuration to CloudWatch alerting and compliance-ready audit trails

SSH was designed in 1995 for a world where servers had public IPs, security perimeters were defined by firewalls, and key management meant keeping a file safe. That world is gone. Modern cloud infrastructure demands identity-based access, zero-trust networking, and comprehensive audit trails — none of which SSH provides natively. AWS Systems Manager Session Manager replaces SSH with a fundamentally more secure approach that treats identity, access, and auditability as first-class concerns.

At Boundev, we have migrated dozens of production environments from SSH-based access to SSM Session Manager. The results are consistent: smaller attack surface, simpler access management, complete session auditability, and no more key rotation emergencies at 2am. This guide covers the complete implementation from architecture to production-ready configuration.

Why SSH Is a Security Liability

SSH itself is not insecure — the way organizations manage SSH access at scale is. Every SSH deployment in a production environment creates three distinct categories of risk that compound as the infrastructure grows.

Open Ports

Port 22 must be open in security groups for SSH access. Every open port is a target for automated scanners, brute-force attacks, and exploitation of SSH vulnerabilities. Reducing the attack surface starts with closing ports you do not need open.

Key Management

SSH keys must be generated, distributed, rotated, and revoked. In practice, keys get shared over Slack, stored in unencrypted locations, left on personal laptops, and never rotated. A single compromised key can provide persistent access to production infrastructure.

Bastion Hosts

Jump boxes require their own patching, monitoring, access control, and auditing. They are additional infrastructure to maintain, additional attack surface to defend, and a single point of failure for all instance access in the environment.

How SSM Session Manager Works

Session Manager uses the SSM Agent, pre-installed on modern Amazon Machine Images, to establish an outbound connection from the EC2 instance to the Systems Manager service endpoint. Because the connection is initiated from inside the instance, no inbound ports need to be open. Authentication and authorization are handled entirely through IAM, and every session can be recorded to CloudWatch Logs and S3.

1SSM Agent Registers with Systems Manager

The SSM Agent on each EC2 instance establishes an outbound HTTPS connection to the Systems Manager service endpoint. This registration requires an IAM instance profile with the AmazonSSMManagedInstanceCore managed policy. No inbound ports, no public IP addresses needed.

2IAM Authenticates and Authorizes the User

When a user initiates a session via the AWS Console or CLI, IAM validates their identity (credentials + optional MFA) and checks their policy against the target instance. IAM policies can restrict access by instance ID, tag, time window, or IP range.

3Encrypted WebSocket Channel Opens

Session Manager establishes an encrypted WebSocket channel between the user's client and the SSM Agent on the instance. All traffic is encrypted in transit using TLS. The session operates as an interactive shell, behaving identically to SSH from the user's perspective.

4Session Logging and Audit Trail

Every command typed and every output generated is streamed to CloudWatch Logs in real time and archived to S3 for long-term retention. CloudTrail independently records the API calls (session start, session end) for management-plane auditing and compliance.

Implementation: Step by Step

The implementation has four layers: IAM configuration, SSM Agent setup, Session Manager preferences, and logging infrastructure. Each layer is independent but they compose into a complete, production-ready access system.

1. IAM Configuration

json

// EC2 Instance IAM Role — attach AmazonSSMManagedInstanceCore
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::your-session-logs-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}

2. User IAM Policy (Least Privilege)

json

// User IAM Policy — restrict to specific instances by tag
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:us-east-1:123456789012:instance/*"
      ],
      "Condition": {
        "StringEquals": {
          "ssm:resourceTag/Environment": "staging"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

3. Starting a Session via CLI

bash

# Start an interactive session
aws ssm start-session --target i-0abcdef1234567890

# Use SSM as an SSH proxy (supports scp and rsync)
# Add to ~/.ssh/config:
Host i-* mi-*
  ProxyCommand sh -c "aws ssm start-session     --target %h     --document-name AWS-StartSSHSession     --parameters 'portNumber=%p'"

# Then connect normally — IAM authenticates, not SSH keys
ssh ec2-user@i-0abcdef1234567890

# Port forwarding through SSM (e.g., access RDS on port 5432)
aws ssm start-session   --target i-0abcdef1234567890   --document-name AWS-StartPortForwardingSession   --parameters '{"portNumber":["5432"],"localPortNumber":["5432"]}'

Need AWS Infrastructure Engineering?

Boundev implements production-grade SSM configurations through dedicated teams. From IAM policy design and VPC endpoint setup to CloudWatch alerting and compliance-ready audit trails.

Talk to Our Team

Session Logging Architecture

Session Manager's logging capabilities are what make it a compliance-ready alternative to SSH. Every keystroke and every byte of output can be captured, stored, and analyzed. The logging architecture has three layers that serve different purposes.

Log Layer	What It Captures	Where It Stores	Use Case
CloudWatch Logs	Real-time session data — commands typed and shell output streamed as the session happens	CloudWatch Log Group (configurable retention)	Real-time monitoring, alerting on suspicious commands, operational debugging
S3 Session Archive	Complete session transcripts archived after session ends, optionally encrypted with KMS	S3 bucket with lifecycle policies	Long-term compliance retention, forensic investigation, audit response
CloudTrail	Management-plane API calls: StartSession, TerminateSession, ResumeSession, with user identity and timestamp	CloudTrail trail (S3 + optional CloudWatch)	Who accessed what instance, when, and how long — management-level audit trail

VPC Endpoints for Private Instances

Instances in private subnets without internet access cannot reach the Systems Manager service endpoint by default. VPC endpoints solve this by enabling private communication between the instance and the SSM service over the AWS backbone network — no NAT gateways, no internet gateways, no public IP addresses required.

Required VPC Endpoints

● com.amazonaws.region.ssm — for Systems Manager API calls (instance registration, parameter store)

● com.amazonaws.region.ssmmessages — for Session Manager data channel (the actual shell session)

● com.amazonaws.region.ec2messages — for Systems Manager to send commands to the SSM Agent

● com.amazonaws.region.logs — for streaming session logs to CloudWatch (if logging to CloudWatch)

● com.amazonaws.region.s3 — Gateway endpoint for archiving session logs to S3 (if logging to S3)

Endpoint Security

● Security groups — attach security groups to interface endpoints that allow inbound HTTPS (443) from the instance security groups only

● Endpoint policies — restrict which principals and resources can use each endpoint, applying least-privilege at the network level

● Private DNS — enable private DNS on interface endpoints so the SSM Agent resolves service hostnames to private IPs automatically

● Cost awareness — interface endpoints incur hourly charges per AZ; deploy only in AZs where managed instances run

SSH vs SSM: Complete Comparison

Traditional SSH:

✗ Requires inbound port 22 open in security groups

✗ SSH key pairs must be generated, distributed, rotated, and revoked

✗ Bastion hosts add infrastructure, cost, and maintenance burden

✗ No native session logging — requires custom tooling for audit trails

✗ Access revocation requires key removal from every authorized_keys file

✗ No native MFA — requires PAM integration or custom setup

SSM Session Manager:

✓ Zero inbound ports — connection initiated outbound by SSM Agent

✓ No key management — authentication handled entirely by IAM

✓ No bastion hosts — direct access through AWS infrastructure

✓ Full session logging to CloudWatch Logs and S3 with KMS encryption

✓ Instant access revocation by modifying IAM policies

✓ Native MFA enforcement through IAM Condition keys

Migration Tip: When we migrate teams from SSH to SSM through staff augmentation, we configure the SSH ProxyCommand approach first so developers can continue using familiar ssh, scp, and rsync commands while IAM handles authentication behind the scenes. This eliminates workflow disruption while immediately gaining the security benefits of SSM.

Security Improvements: By the Numbers

Inbound ports required for instance access

SSH keys to manage, rotate, or revoke

100%

Session commands logged and auditable

<1s

Time to revoke access via IAM policy change

FAQ

What is AWS SSM Session Manager?

AWS Systems Manager Session Manager is a fully managed capability that provides secure, auditable shell access to Amazon EC2 instances without requiring inbound ports, SSH keys, or bastion hosts. It uses the SSM Agent (pre-installed on modern AMIs) to establish an outbound connection to the Systems Manager service, and authenticates users through IAM policies. Every session can be logged to CloudWatch Logs and S3, and all API calls are recorded in CloudTrail, creating a comprehensive audit trail for compliance and security investigations.

Can I use SSM Session Manager with existing SSH tools like scp and rsync?

Yes. Session Manager supports an SSH proxy mode where you configure your SSH client to use SSM as the transport layer. By adding a ProxyCommand to your SSH config, you can use standard ssh, scp, and rsync commands while authentication is handled by IAM instead of SSH keys. This provides the familiar workflow developers are used to while gaining SSM security benefits: no open ports, IAM-based access control, and full session auditability.

How do I log all Session Manager commands for compliance?

Enable session logging in Session Manager preferences (AWS Console > Systems Manager > Session Manager > Preferences). Configure CloudWatch Logs for real-time streaming of all commands and output to a specific log group, and S3 for long-term session transcript archival. Encrypt both with KMS for data-at-rest protection. Additionally, enable CloudTrail across all regions to capture management-plane API calls (who started sessions, when, and to which instances). The EC2 instance IAM role must include permissions to write to both the CloudWatch Log group and the S3 bucket.

How do I use SSM Session Manager with private instances that have no internet access?

Create VPC interface endpoints for three SSM services: com.amazonaws.region.ssm, com.amazonaws.region.ssmmessages, and com.amazonaws.region.ec2messages. If logging to CloudWatch, also create a com.amazonaws.region.logs endpoint. For S3 logging, create a Gateway endpoint for com.amazonaws.region.s3. Enable private DNS on all interface endpoints, and attach security groups that allow inbound HTTPS (443) from your instance security groups. This enables all SSM communication over the AWS private backbone without NAT gateways or public IP addresses.

What are the prerequisites for using SSM Session Manager?

Three prerequisites are required: (1) the SSM Agent must be installed and running on the EC2 instance (pre-installed on Amazon Linux 2, Amazon Linux 2023, Ubuntu 16.04+, and most modern AMIs), (2) the EC2 instance must have an IAM instance profile attached with the AmazonSSMManagedInstanceCore managed policy (which grants permissions for the agent to communicate with Systems Manager), and (3) the instance must have network connectivity to the SSM service endpoints, either through internet access or VPC endpoints for private subnets. At Boundev, we automate this setup through software outsourcing using Terraform or CloudFormation templates that configure all three prerequisites as part of the instance launch template.

AWS SSM Session Manager: Replace SSH with Auditable Access