Setting up cloud infrastructure is the easy 10%. You click through a console or run a few Terraform files, things come up, it works, everyone's happy. Then the other 90% starts, the part that actually decides whether your setup is a foundation or a slow-motion incident, and almost nobody talks about that part until they're living in it at 3am.
So here's the 90%, roughly in the order it bites.
Setting up cloud infrastructure is the easy 10%. You click through a console or run a few Terraform files, things come up, it works, everyone's happy. Then the other 90% starts, the part that actually decides whether your setup is a foundation or a slow-motion incident, and almost nobody talks about that part until they're living in it at 3am.
So here's the 90%, roughly in the order it bites.
If it's not in code, it doesn't exist
The single biggest split I see between teams that stay sane and teams that don't is whether their infrastructure lives in code. Someone clicking around a console to set things up feels faster on day one. It's a trap. Six months later nobody remembers why that security group has that rule, there's no record of who changed what, and rebuilding the environment is an archaeology project.
Infrastructure as code fixes this, and not for the reason people usually say. Yes, it's repeatable. The bigger win is that your infrastructure becomes reviewable and diffable. A change is a pull request. You can see what's about to happen before it happens, someone else can catch the mistake, and there's a history. Console clicking has none of that. If you take one thing from this post: stop making changes by hand.
Cost is a design decision, not a monthly surprise
The cloud bill is where good architecture and bad architecture become visible, and usually too late. Nobody notices cost while building. They notice it when finance forwards the invoice with a lot of question marks.
The thing to internalise is that cost is baked in at design time, not tuned afterwards. The instance types you pick, whether you actually use autoscaling or just run everything at peak size all the time, how much data you move between regions (that egress will get you), whether you left a dozen things running that nobody uses. By the time it's a big bill, the expensive choices are already load-bearing and painful to unwind. Build with cost as a design constraint from the start, or budget for the surprise.
Observability before you need it, not during the outage
Everyone agrees monitoring matters. Almost everyone adds it after the first outage they couldn't explain. Do it the other way. When something breaks, and it will, the question is whether you can see what's happening or whether you're guessing. Logs, metrics, traces, and actual alerting that pages a human on the things that matter and stays quiet about the things that don't. Alert fatigue is its own failure mode, a wall of noise nobody reads is the same as no alerts at all.
*The access sprawl that becomes a breach
*
This is the one that ties into everything, and the one that quietly rots. Permissions in the cloud sprawl. A role gets over-granted to unblock someone, a service account gets admin because scoping it was annoying, keys get created and never rotated. Each one is fine in isolation. Together they're the map of your next incident.
Least privilege isn't a one-time setup, it's ongoing hygiene. Scope things down, review who and what can reach what, rotate credentials, and pay special attention to the non-human identities, the service accounts and automation, because they usually have the broadest access and the least oversight. Most cloud breaches aren't clever. They're an over-permissioned thing that got popped and could reach far more than it should have.
**
The unglamorous truth**
Managing cloud infrastructure well is mostly discipline, not cleverness. Everything in code. Cost as a constraint. Observability up front. Access kept tight and reviewed. None of it is exciting, none of it demos well, and all of it is the difference between infrastructure you run and infrastructure that runs you.
The setup was the easy part. The management is the job.
Top comments (0)