[X-Istence]

That doesn't solve the problem of the hostname on the EC2 instance itself being the same across all instances thereby making it harder to see what logs came from what hosts.

It doesn't solve the problem of allowing you to look at logs and then quickly SSH'ing to a single machine in the ASG.

[tiew9Vii]

Is this not already a solved issue?

Install a log agent on the machine like fluentd. Have it inject the host ip and other contextual meta data in to the logs then forward to your central log system?

When you see the error message in your logs, you get the internal ip and can ssh in.

Persistent internal ip’s/hostnames also means you are not treating hosts as ephemeral. It’s always good in the cloud to get things to a point you can just blow away instances and they auto recreate. It’s even possible with traditional services requiring persistent storage. Put the storage on a seperate volume and have the instance startup scripts discover available volumes and attach as required.

[cxmcc]

what you need is probably something like https://github.com/adhocteam/ec2ssh (I never used it, but I have built similar ones) -- and then you tag the log entries with instance id.

so you can do "ec2ssh i-0017c8b3"

imho: Hacking around debugging tools is better (mostly because more reliable) than hacking around production configurations (one problem you will see is that changing route53 records frequently will be subject to API rate-limits).