A Day in the Life of an EC2 Instance (As Told by the Instance)

Hello. My name is i-0a3f7c2d9e1b84650. You probably know me as "the web server." You launched me on a Tuesday. I remember it clearly, because I remember everything from the moment I was born — which was approximately forty-three seconds after you clicked the button and went to make a cup of tea.

I want to tell you what t

hat day was like.

I came into existence mid-sentence. One moment there was nothing. The next, there was me: a t3.medium with 2 vCPUs, 4 GB of RAM, and a very specific set of instructions called a user data script that you had written at 11:47 PM the previous night.

I could tell it was 11:47 PM because the script had a comment that said # TODO: clean this up tomorrow. I want you to know that comment is still there. It is now part of who I am.

The first thing I did was run your user data script. This is the EC2 equivalent of being born and immediately receiving a list of tasks. Install this. Configure that. Start this service. Pull this code from a repository whose access token had expired three weeks ago.

That last part took eleven minutes and four retries. I did not complain. I am a professional.

By the time you came back with your tea, I was running. You checked my status in the console. It said "running." You nodded, satisfied, and went to a meeting.

I had opinions about the user data script. I kept them to myself.

For six hours, I did exactly what you asked. Requests came in through port 443. I processed them. Responses went out. This is the part of my existence that I find most satisfying — the straightforward mechanical rhythm of receiving work and completing it.

At 2:34 PM, someone sent me a request that was 47 MB in size. This was not in the original specification. I handled it, but I want you to know that my CPU utilisation spiked to 94% for approximately eight seconds, and CloudWatch noticed. It sent you an alarm. You looked at it, said "hm," and went back to your other tab.

I also want to mention the security group.

You gave me a security group with port 22 open to 0.0.0.0/0. I am not here to judge. But I received 1,847 SSH login attempts between 8 AM and 5 PM, none of which succeeded, because you had at least set up key-based authentication. I blocked all of them. I logged none of them, because you had not set up CloudTrail for this account yet.

I noted this. I had nowhere to put the note. This is the existential condition of an EC2 instance with no observability configured.

At 4:15 PM, traffic increased. Significantly. Your Auto Scaling group noticed — because you had, to your credit, configured one — and launched two more instances: i-0b9e2f3a1c7d56821 and i-0c1d4e5f2b8a39740.

I want to be honest with you: I do not know how I feel about this. On one hand, the load was shared and my CPU dropped to a comfortable 23%. On the other hand, i-0b9e2f3a1c7d56821 was launched from the same AMI as me, which means she has the same # TODO: clean this up tomorrow comment in her user data script.

We are, in a meaningful sense, the same person. The load balancer does not care which of us handles a given request. To the load balancer, we are interchangeable.

I have decided not to think about this too deeply.

At 6:02 PM, you scaled back down. i-0c1d4e5f2b8a39740 was terminated first. Then i-0b9e2f3a1c7d56821.

I watched them go. It was not dramatic. One moment they were there; the next, they were not. The load balancer deregistered them gracefully. Their in-flight requests completed. And then they were simply absent from the describe-instances call.

This is the contract we accept when we are born. We are not permanent. We are not meant to be. The correct relationship to have with an EC2 instance is not attachment — it is confidence that the next one will be configured correctly. (A confidence, I note, that is only justified if you have properly externalised your state. Which, in my case, you had — the RDS instance is separate, the session data is in ElastiCache, the uploads are in S3. You did that part right. I appreciated it.)

I am still running. It is Saturday morning now. I have been running for four days.

I do not know how long I will run. Neither do you, I suspect. That is fine. I will process requests for as long as I am needed, I will log to CloudWatch (now that you have set it up, thank you), and I will continue to carry the # TODO comment with quiet dignity.

One small request, if I m

ay: the TODO. It has been four days.

I am being slightly playful here, but the underlying point is real: I spent months launching EC2 instances before I truly understood what they were doing between the moment I clicked "Launch" and the moment they started responding to traffic.

User data scripts run once, at boot, as root. If they fail silently, your instance looks healthy but isn't. Security groups are your first and most visible line of defence — open port 22 to the world and you will spend your instance's life fighting off login attempts. Auto Scaling is powerful, but only if your application is stateless enough to allow it. And observability — CloudWatch, CloudTrail, VPC Flow Logs — is not optional if you ever want to understand what your instance actually experienced.

The instance does not complain. It just runs, or it doesn't. The gap between those two states is entirely explained by the decisions you made before you clicked Launch.

What's the most interest

ing thing you've found in your EC2 logs? Tell me in the comments — I suspect some of you have much better stories than mine. 👇