Troubleshooting

you'll need to stop the instance to recover access. Here's the secure approach:

1. Private instance:

   • ID: i-0ccddc6308d8c9ce1

   • Private IP: 10.0.1.18

   • Subnet: subnet-01eaa207113bdb362 (private subnet)

   • Root volume: vol-0678c27f5169d384c

Here are the specific steps to recover access:

1. Stop the instance (i-0ccddc6308d8c9ce1)

2. Create a snapshot of vol-0678c27f5169d384c

3. Create a new volume from that snapshot in us-east-1d AZ

4. Launch a temporary bastion instance in the public subnet (subnet-08f046c30e43a604e) with:

   • Amazon Linux 2 AMI

   • Same security group as your target instance

   • SSM role already in use (architecture-InstanceProfileSSM-TxD0LYJl8DxH)

5. Attach the new volume to the bastion as /dev/xvdf

6. On the bastion:

sudo mkdir /mnt/recovery

sudo mount /dev/xvdf1 /mnt/recovery

sudo chroot /mnt/recovery

amazon-linux-extras install -y amazon-ssm-agent

systemctl enable amazon-ssm-agent

7. If you also need SSH access:

mkdir -p /home/ec2-user/.ssh

chmod 700 /home/ec2-user/.ssh

# Add your public key to /home/ec2-user/.ssh/authorized_keys

chmod 600 /home/ec2-user/.ssh/authorized_keys

chown -R ec2-user:ec2-user /home/ec2-user/.ssh

8. Exit chroot, unmount and detach the volume:

exit

sudo umount /mnt/recovery

9. In the AWS Console:

   • Stop the original instance

   • Detach vol-0678c27f5169d384c

   • Attach the modified volume as /dev/xvda

   • Start the instance

After recovery, immediately:

1. Verify SSM connection through Session Manager

2. Remove the temporary bastion host

3. Consider implementing proper instance deployment procedures to prevent this in the future