How to Manage AWS When You Never Meant to Be the Cloud Person

I met a man who is the only cloud person at a fifty-person company. He's the one who gets the call when something breaks on the backend. Always him. He put it plainly: developers get their Saturdays and Sundays. He doesn't, because if something breaks at 2 AM, he's the only one who knows what any of it actually does.

And when it breaks, the work isn't fast. You sit there. You figure out what happened. You find the leak, find what broke. Then you follow procedure and get approval just to change anything. All of that, alone, at 2 AM.

Nobody applies for this job

Nobody gets hired to be the AWS person. It happens because someone was in the room when the account got created, or because they were curious enough to click around until it made sense, and then everyone in the company starts asking where things are. I know how that happens because it happened to me too. Early in my career, I built twenty-five servers in one shift, by hand, because someone had to and I was the one available.

The fear underneath

What actually scares that man is the risk. Something can go wrong at any moment, and if it goes wrong because of a choice he made, he's the one who has to answer for it.

I carry the same memory. Back in my server engineering days, a colleague flagged something being actively exploited, a real vulnerability, live. Getting proper approval to shut it down would have taken half a day. I did it immediately instead, because I understood the risk well enough to know waiting was the bigger danger. That's the actual weight of this job... knowing when to act and when to wait.

The 200+ services problem

AWS has over two hundred services. Most companies use about eight of them. When you're the only cloud person, you don't get to know just eight. You have to know enough about all two hundred, because you never know which one someone will ask about, or which one is quietly running up a bill, or which one has a door left open that nobody noticed.

What would actually help

What would actually help is knowing what's running in your account without having to hunt for it, being unable to break production by accident, and understanding why something happened instead of just being told that it did.

That's the part we built Liberra around. Your infrastructure gets indexed, so when you ask what's running or what changed, it already knows your account instead of starting from zero. Deletes are blocked in the code itself, not by a setting anyone could switch off by mistake. Every write pauses for your approval before it runs. And every action lands in your own CloudTrail, tied to whoever actually approved it.

It doesn't replace the 2 AM call. Someone still has to be there when something breaks. What it can do is make sure that person isn't standing there alone trying to remember what a service does while production is down, with something explaining the why as it goes. The man at the fifty-person company still has to be the one who gets the call. But he'd open the account knowing what's actually in it, instead of guessing which of two hundred services almost got him this time.

Founder, Liberra AI