EC2 Instance Connect and Session Manager are both ways to get a shell on your EC2 instances, but they solve fundamentally different problems and have vastly different security implications.
Let’s see them in action.
First, EC2 Instance Connect. You’ve got an instance, and you want to SSH into it. You’ve probably set up your security groups to allow port 22 from your IP, and you’re using SSH keys.
With EC2 Instance Connect, you still use SSH, but it streamlines the key management. Instead of pre-distributing your private keys to every instance, you push a temporary public key to the instance’s authorized_keys file via the EC2 Instance Connect API.
Here’s how it works from your terminal:
# You need the EC2 Instance Connect CLI installed
# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-to-instance.html#ec2-instance-connect-install-cli
# Get a temporary SSH key pair
ssh-keygen -t rsa -b 4096 -f ec2_instance_connect_key
# Use the EC2 Instance Connect CLI to push your public key to the instance
# Replace 'i-0123456789abcdef0' with your instance ID
# Replace 'ec2-user' with the appropriate username for your AMI
aws ec2-instance-connect send-ssh-public-key \
--instance-id i-0123456789abcdef0 \
--instance-os-user ec2-user \
--ssh-public-key fileb://ec2_instance_connect_key.pub
# Now you can SSH into the instance using your private key
# The key will only be authorized for a short period (typically 60 seconds)
ssh -i ec2_instance_connect_key ec2-user@<your-instance-public-ip>
Notice the aws ec2-instance-connect send-ssh-public-key command. That’s the core of it. It makes an API call to AWS, which then configures the instance (via a special agent or pre-baked user data) to accept your public key for a limited time. Your security group still needs to allow SSH (port 22) from your IP.
Now, Session Manager. This is a completely different beast. It doesn’t use SSH at all. Instead, it leverages the AWS Systems Manager Agent (SSM Agent) on your instance and communicates over HTTPS (port 443) to the SSM API endpoints.
You initiate a Session Manager session from your AWS CLI:
# Ensure you have the AWS CLI configured and SSM Agent running on the instance
# Ensure your instance has an IAM role attached with permissions for Systems Manager
# https://docs.aws.amazon.com/systems-manager/latest/userguide/iam-permissions-for-service-role.html
aws ssm start-session \
--target i-0123456789abcdef0
This command opens an interactive shell on the instance. No SSH keys, no open port 22 in your security group. The instance just needs to be able to reach the SSM endpoints (either directly or via a VPC endpoint).
Here’s the mental model:
EC2 Instance Connect is an enhancement to traditional SSH.
- Problem Solved: Simplifying SSH key distribution and management for ad-hoc access. You don’t want to manually
ssh-copy-idor manage long-lived keys on instances. - How it Works: Pushes a temporary public key to the instance for SSH authentication.
- Security: Relies on SSH security (port 22 open, SSH keys). The "instance connect" part is about how the key gets there and for how long, not a replacement for SSH itself.
- Levers: IAM permissions to use the
send-ssh-public-keyAPI call, security group rules allowing port 22 from your IP. - Use Case: Quick, interactive SSH access when you need a full shell and are comfortable with SSH’s security model. Good for development or troubleshooting where you might need to run arbitrary commands interactively.
Session Manager is a secure, auditable, and agent-based command-line access mechanism.
- Problem Solved: Providing secure, audited, and controlled command-line access to EC2 instances without opening SSH ports and without managing SSH keys. It’s about policy-driven access and central logging.
- How it Works: Uses the SSM Agent on the instance to establish a secure tunnel (over HTTPS) to the SSM service. The agent forwards commands and output.
- Security: No inbound SSH port (port 22) needed. Access is controlled via IAM policies and can be logged to S3 or CloudWatch Logs. You can even use IAM to grant specific users or roles permission to start sessions on specific instances.
- Levers: IAM policies for
ssm:StartSession,ssm:TerminateSession, etc. Instance IAM role with SSM permissions. VPC configuration for SSM endpoint access. SSM Association documents for running commands non-interactively. Session Manager preferences for logging and shell type. - Use Case: Production environments where security and auditability are paramount. Compliance requirements often push towards solutions like this. Also great for running automated tasks or scripts on fleets of instances.
The most surprising thing about Session Manager’s underlying mechanism is how it leverages the outbound HTTPS connection from the instance to AWS. The SSM Agent isn’t listening for inbound SSH connections; it’s actively "phoning home" to AWS, waiting for instructions. This fundamentally changes the security posture, as you don’t need to expose your instances to inbound traffic on management ports.
When you use aws ssm start-session, you’re essentially telling the SSM service to tell the SSM Agent on your target instance to open a shell and stream its input/output back to your CLI session. The IAM role attached to your instance is critical here, as it’s what authorizes the SSM Agent to communicate with the SSM service. Without it, the agent can’t get commands, and you can’t start a session.
You might think that because Session Manager uses the SSM Agent, it’s just for running commands. But the start-session command gives you a full, interactive shell experience, just like SSH. The difference is the security and auditability baked into the SSM service. You can configure Session Manager to log every command executed, every character typed, to an S3 bucket or CloudWatch Logs, providing an invaluable audit trail.
If you’re trying to get interactive shell access to an instance and you’re seeing an error like "Connection timed out" or "Permission denied (publickey)", and you’ve confirmed your security group allows port 22 and your SSH key is correct, you might be looking at an EC2 Instance Connect issue. The next error you’ll hit after fixing everything is likely an IAM permission denial for the ec2-instance-connect:SendSSHPublicKey action.