termalOn a long-lived server, session recording is a setup question: pick a tool, install it, done. On EC2 the question changes shape, because the server itself is temporary. Instances get replaced by autoscaling, rebuilt from fresh AMIs, terminated by a deploy — and anything stored on the box, recordings included, goes with them. Cattle, not pets, is the whole cloud operating model; an audit trail that lives on the cattle is not an audit trail.
So the real question isn’t “how do I record sessions on this instance” — it’s “how do I keep a record of what happened on instances that may not exist by the time anyone asks.” There are four honest answers, each with a different shape.
Option 1: SSM Session Manager with session logging
AWS’s own answer, and for many teams the right starting point. Session Manager gives you a shell on an instance through the SSM agent’s outbound connection — no inbound port 22, no SSH keys to manage at all. Who can open a session to which instances is pure IAM policy, and every session start lands in CloudTrail with the caller’s identity. Turn on session logging and the transcript of each session is shipped to an S3 bucket and/or CloudWatch Logs — off the instance, which is exactly the property the cloud demands.
Those are real strengths: centralized identity, no key sprawl, logs that outlive the box, all managed by the platform. Now the limits, stated plainly rather than as complaints:
- The logged surface is the interactive session. The transcripts cover shells opened through Session Manager itself. Sessions that go through Session Manager’s port forwarding, or SSH tunneled over SSM (the
ProxyCommand+AWS-StartSSHSessionpattern), are not captured — SSH encrypts that stream end to end, so the platform sees ciphertext passing through. If your team adopted SSM specifically to keep usingsshandscpon top of it, the recording feature quietly doesn’t apply to them. - Storage is only as private as your bucket. Transcripts land as readable text; encryption is whatever server-side option you configure (SSE-KMS at best). That’s provider-managed encryption — the storage layer and anyone with read access to the bucket or log group can read every session. Fine for many threat models, worth stating out loud for others.
- It’s a transcript, not a recording. You get the text of what happened, which answers most audit questions — but no timing, no replay. Reconstructing how an incident unfolded from a flat transcript is doable and joyless, and full-screen programs (editors,
top) come out as escape-code soup.
None of this makes SSM logging bad. It makes it a coverage-oriented compliance layer — excellent at “prove every console session was captured,” weaker at “let me watch what actually happened.”
Option 2: EC2 Instance Connect
Worth a paragraph mostly to prevent a wrong assumption. Instance Connect solves the key problem: it pushes a short-lived public key to the instance via the metadata service, valid for about a minute, with the push recorded in CloudTrail. IAM decides who may push keys to which instances — a genuinely nice replacement for baked-in authorized_keys.
But after the key lands, what follows is a plain SSH connection, and nothing records its content. Instance Connect tells you that someone connected and as whom — never what they did. If you’re reading this article, it’s a complement, not an answer.
Option 3: sshd plus tlog on the instance
The traditional server-side recorder works on EC2 the same way it works anywhere: wrap login shells in tlog-rec-session, journal every session, catch every user regardless of client. The setup sketch — and the operational care it needs — is the same as on a bastion, covered in record and audit SSH sessions on a bastion host.
The cloud adds two sharp edges. First, the recording dies with the instance unless it leaves the box: local journald on a terminated instance is gone, so forwarding to a remote collector (or Elasticsearch) isn’t an optimization here, it’s the difference between having recordings and not. Second, the setup has to survive the AMI pipeline — baked into the image or applied by user-data on boot, because any instance the recorder didn’t reach is an unrecorded instance, and autoscaling will happily create those at 3 a.m.
If your fleet funnels through a bastion anyway — common in VPC designs — recording at the bastion instead of on every instance concentrates the ops burden onto one box you already treat as special.
Option 4: client-side recording
Flip the problem around: instead of chasing recordings across instances that keep dying, record at the one place that persists — the operator’s SSH client. The recording is made as the session happens and stored with the operator, so it survives instance churn by construction. The same setup covers every target — EC2 today, another cloud tomorrow, the box under the desk — with no agent to install, no instance role, nothing baked into an AMI. And a client can enforce the rule server-side stacks have to be carefully configured into: capture output only, never keystrokes, so the archive can’t become a file of sudo passwords. (Why that rule matters more than it sounds: recording without keylogging yourself.)
The honest limit, same as always: client-side recording covers the operators who use that client. It cannot testify about a session someone opened from a stock ssh on an unmanaged laptop. If your requirement is “every session, every human, provably” — that’s what options 1 and 3 are for, and the strongest setups pair one of them with this one.
Storage, retention, encryption
Wherever the recordings come from, the same three decisions determine whether they’re an asset or a liability:
- Retention is a policy, not an accident. SSM transcripts in S3 want a lifecycle rule that expires them on schedule; client-side recordings want a retention window that prunes automatically. Sessions contain config files and query results — an archive kept forever is a breach multiplier.
- Decide who can replay before the first recording exists. A recording readable by everyone with bucket access has the same audience as a public wiki page, just with worse content.
- Know your encryption model. Server-side encryption (SSE-KMS on a bucket) protects against lost disks and keeps honest people out; the provider and anyone with the right IAM path can still read content. End-to-end encryption — recordings encrypted on the operator’s device before upload, decrypted only at replay — removes the storage layer from the trust equation entirely. Neither is “correct”; they answer different threat models, and you should know which one you’re buying.
Where Termalin fits
Termalin is option 4 done properly. Sessions to your EC2 instances — direct or through a jump host — are recorded output-only at the client, with a per-host toggle and an automatic retention window, and replayed on a timeline with original timing rather than as a flat transcript. The audit log keeps who/when/from-where — host, time, device, IP — next to each recording, and commands issued by an AI agent are marked as the agent’s, with live sessions mirrored in the watch grid. On paid plans recordings sync end-to-end encrypted: the server stores ciphertext it cannot replay, while you can replay from the web cabinet on any machine — which is precisely the “outlives the instance, readable only by you” combination the cloud model calls for. Run it alongside SSM logging where compliance demands platform-side coverage; the two see different things, and that’s the point.
Termalin’s Free tier records and replays locally with no host limits — download it, or see session recording in detail.