i am confused with so many access methods provided by aws – native ssh, ec2 instance connect, session manager and now serial console – that’s 4. why doesn’t it provide 1 recommended and best method to connect to ec2 instances?

Yeah, AWS really did a “collect them all” with EC2 access methods 😅
The good news: they each exist for a different primary use case. You don’t need to use all four.

Let me map them out in plain English and then I’ll give you a recommendation for one main way to use going forward.

The 4 ways in one sentence each

1. Native SSH
   • Old-school: ssh ubuntu@ip.
   • Uses your key pair, Security Groups, public IP / bastion.
   • Simple, familiar, but tied to network exposure and key management.
2. EC2 Instance Connect (browser / CLI)
   • Still SSH under the hood, but AWS temporarily injects an SSH key for you.
   • Good for ad-hoc admin, less key-juggling, still needs port 22 open.
3. Session Manager (SSM)
   • No SSH, no open ports, no public IP needed.
   • Uses SSM agent + IAM. You connect via AWS console / CLI.
   • Great for locked-down prod instances and auditing.
4. EC2 Serial Console
   • Like plugging a keyboard+monitor physically into the box.
   • Works even when SSH/network/fw is broken.
   • Pure break-glass / recovery tool, not for daily use.

Why AWS doesn’t say “just use this one”

Because different customers have very different priorities:

• Old existing systems → expect classic SSH.
• Enterprises / regulated environments → want no inbound ports, full audit → prefer Session Manager.
• People who occasionally need OS-level recovery → need Serial Console.
• People who like SSH but hate key distribution → Instance Connect is a compromise.

AWS can’t kill SSH (too widely used), but also can’t tell banks “yeah just keep 22 open to the internet”. So you end up with a menu instead of a single “best” choice.

How you can think about it (practical mental model)

For a startup / solo dev like you, a sane mental model is:

1. Pick ONE as your “everyday access”

If you’re comfortable with AWS-y stuff and IAM:

Use Session Manager as your primary.

• No open SSH port
• Works even if public IP changes
• Auditable and more secure by default

If you just want something familiar and fast:

Use native SSH as your primary, but:

• Lock Security Group to your IP (not 0.0.0.0/0 if possible)
• Use good key hygiene
• Maybe also enable SSM for backup

2. Keep ONE “break glass” method

• That should be EC2 Serial Console (plus SSM if available).
• You only touch it when:
  • sshd is broken,
  • firewall rules are wrong,
  • you’ve locked yourself out.

3. Treat EC2 Instance Connect as optional sugar

• It’s just a nicer way to do SSH without juggling keys.
• You don’t need it if you’re happy with SSH or SSM.

Concrete recommendation tailored to you

Given how deep you already are with AWS and how this SSH lockout just bit you:

If I were in your shoes, I’d do this going forward:

1. Enable SSM + Session Manager on all EC2s
   • Attach an IAM role with AmazonSSMManagedInstanceCore.
   • Make sure SSM agent is installed (it is by default on most Amazon Linux / Ubuntu AMIs).
   • Use Session Manager as your “I just need a shell to debug/patch something” tool.
2. Keep SSH, but treat it as a convenience
   • Keep port 22 open only from your current IP (or use a small bastion).
   • Use it for git push/port forwarding/etc. when it’s working.
   • But know that when SSH breaks, you have SSM + Serial Console.
3. Enable EC2 Serial Console as the last line of defense
   • Give access only to your own admin role (or “break-glass” role).
   • Use it only when:
     • SSM isn’t set up / not working, and
     • SSH is dead, and you don’t want to detach volumes.

That way you’re not “choosing between four things” every time. It becomes:

• Daily shell: Session Manager (or SSH if you really prefer).
• Emergency: Serial Console.
• Instance Connect: nice-to-have, not required.

• Although SSM might be suggested as the preferred choice by above answer, in practice, SSM suffers from this annoying problem: https://repost.aws/questions/QUg8ZbWfDES8qKlZl-pxSDWg/ssm-session-hangs. AFAICT this is a bug in AWS.
• EC2 instance connect comes with its own bug: https://repost.aws/questions/QUrrBobPLBRuu03eGBDnHa7A/ec2-instance-connect-logs-me-out-after-an-hour-with-this-message-websocket-closure-reason-connection-exceeded-session-timeout

The issue you’re experiencing with EC2 Instance Connect is related to the default session timeout. EC2 Instance Connect sessions typically last for one hour, after which you’re automatically disconnected even if you’re actively using the session.

Unfortunately, this one-hour session limit for EC2 Instance Connect is a fixed value and cannot be extended. This is different from the idle timeout that can be configured in some other AWS services.

Controlling the SSM session duration

aws ssm update-session-manager-settings --idle-session-timeout <minutes> --max-session-duration <minutes>

You can configure these settings in the Session Manager preferences within the AWS Systems Manager console or by using the AWS CLI. 

Using the AWS Console

1. Sign in to the AWS Systems Manager console.
2. In the left navigation pane, choose Session Manager.
3. Choose the Preferences tab.
4. Choose Edit and modify the values for Idle session timeout and/or Maximum session duration.
5. Choose Save changes to apply the new settings. 

Using SSH+SSM to connect to VM

add this to ~/.ssh/config:

Host king-cobra
      HostName i-xxx
      User ubuntu
      IdentityFile ~/.ssh/id_ed25519
      ProxyCommand aws ssm start-session --target %h --region us-west-2 --document-name AWS-StartSSHSession --parameters portNumber=%p

Some more tips on SSM

Run these commands on your local computer (not EC2) if you see permissions denied errors. These commands create the logs directory where SSM stores its logs and gives it permissions over the directory. See this for more. You also need to create /usr/local/sessionmanagerplugin/seelog.xml file.

sudo mkdir -p /usr/local/sessionmanagerplugin/logs
sudo chown $USER:$USER /usr/local/sessionmanagerplugin/logs

Command to connect to EC2 using SSM:

aws ssm start-session --target i-xxx --region us-west-2 --document-name AWS-StartInteractiveCommand --parameters command="sudo su - ubuntu"

The command="sudo su - ubuntu" will log in as ubuntu. By default SSM will log you in as ssm-user which may not be very helpful.