Cloud Architecture: why technology is the easy part

Every cloud project I’ve touched starts the same way. Not with requirements. Not even with a real conversation. Someone with “Chief” in their title decides we need to “innovate faster” or whatever. Then you get a two-line email. Make it happen, make it secure, make it compliant. Oh and ideally we wanted it done last quarter.

Sounds doable on paper.

But here’s the thing. The cloud itself? Not the problem. The problem is literally everything else. People. Expectations that don’t line up. That system from 2019 that was supposed to be “temporary” but is now holding up half of production. Decisions nobody actually made but everyone assumes got sorted. That’s what cloud architecture really looks like. Messy. Political. And nothing like the nice clean diagrams in the strategy deck.

“Just Move Us to Azure.”

First meeting. Everyone’s optimistic. Cloud is the future, blah blah, everyone’s doing it. More agile. More modern. Whatever that means. Heads nod. Meeting ends. And now you’re stuck with a one line brief and about forty questions that nobody thought to ask.

So what does “moving to Azure” actually mean? Because honestly it could mean a lot of things. Refactoring apps? Lift and shift and deal with the mess later? Building something completely new? Those are wildly different projects. Different timelines. Different costs. Different ways things can blow up in your face.

The hardest bit is translation. Business people talk outcomes. Finance talks budget lines. Security wants to know about risk. Developers just want clean Terraform and a pipeline that doesn’t take forever. And everyone, literally everyone, from the project sponsor to the CIO, quietly assumes cloud is gonna be cheaper.

That assumption tends to stick around right until the first Azure bill shows up. Then things get… interesting.

The stuff nobody mentions but everything depends on

What surprises people is how much architecture is just invisible. Every resource you see in the portal, VM, database, whatever, has dozens of decisions underneath it. Naming conventions. Tagging. Access controls. Region choices. Policy assignments. The stuff that actually makes a cloud environment governable.

Azure won’t enforce your naming rules. It won’t segment your network traffic for you. And it definitely won’t stop some developer from accidentally making a storage account public at 4pm on a Friday.

Yes. That’s happened. More than once. At orgs that thought they had it under control.

The cloud gives you powerful building blocks. Great. Turning those into something coherent across teams with completely different goals? That’s the architect’s job. And when it works, nobody notices.

The tools that actually work

Two things do the heavy lifting for governance.

Azure Policy. You define rules, you enforce them. Resources can’t deploy outside approved regions. Everything needs proper tags. Encryption standards get met. Compliance checks run continuously, not as some annual audit thing. It keeps everything consistent even when different teams are doing different things at different times.

Defender for Cloud handles security posture. Tracks threats, surfaces vulnerabilities, checks against standards like CIS, NIST, ISO 27001. Not perfect. But it shows you what’s actually happening versus what you think is happening. Big difference.

Of course none of this runs smoothly in a vacuum. You’re building inside a landscape of legacy systems, rigid processes, siloed teams. Security people who’ve heard “we’ll fix it after go live” way too many times. The clean experience you eventually get? That comes from a ton of debates and compromises made way before the first workload goes live.

Landing zones: Architecture’s first proper fight

Before any workload touches Azure, you need a foundation. That’s the landing zone. And this is where cloud architecture stops being technical and starts being political.

A landing zone isn’t just Bicep templates. It’s a shared agreement. A contract. How are subscriptions structured? How’s the network designed? Where do the firewalls live? Who gets access to what? Which baselines apply? How’s logging built in from day one instead of bolted on later?

Microsoft’s Azure Landing Zone accelerator is decent. Solid reference architecture. The catch? It assumes a clean slate. Most orgs I’ve worked with don’t have that. They’ve got three subscriptions someone created three years ago with no naming conventions. A VPN that was “temporary” and is now carrying production traffic. Four teams with four definitions of what “production” even means.

Landing zones hit resistance because they force conversations people have been avoiding. All the unspoken stuff gets surfaced. Teams that worked independently suddenly need to agree on shared standards. Questions that got quietly ignored, who owns the hub, who manages firewall rules, can’t be deferred anymore.

That’s why these projects always take longer than expected.

Writing the Bicep? Easy. Getting twelve people to agree on naming conventions? Somehow takes three months. I’ve seen it happen. Three months. For naming conventions.

Identity: The archaeology layer

Want to know how mature an org’s cloud thinking really is? Look at their identity setup. Every cloud journey crashes into Entra ID at some point. Rarely graceful.

What you find is less “designed structure” and more excavation. Security groups nested so deep nobody knows why. Service principals with Contributor rights across everything, no documented owner. Orphaned accounts from contractors who left 18 months ago. Admins holding Global Admin “just in case” which means they don’t trust the access model. And somewhere, always, a service principal with Owner on the root management group. Last used: never.

Cleaning this up, administrative units, least privilege, access reviews, PIM for just in time access, that’s foundational. Identity IS the security perimeter now. Network still matters but it’s secondary.

The conversation stops being about tech real fast. Becomes organisational politics. And because identity touches everything, it’s usually the first genuinely charged challenge. Technical work isn’t hard. Getting twelve teams to give up standing permissions? Completely different problem.

Networking casts long shadows

Policy assignments? Update in minutes. Networks? Different story.

Address spaces, region topology, peering decisions. These get made early and shape everything for years. Consequences compound quietly. Until they don’t.

This is where you find yourself explaining to leadership why a “simple peering connection” isn’t a sustainable strategy. Why that “temporary” VPN is now permanent infrastructure that three critical workloads depend on.

Overlapping IP ranges aren’t a networking problem. They’re a time machine. Take you straight back to when someone said “we’ll sort the address space later” and then didn’t. Untangling that with live workloads depending on it? That stays with you.

Azure’s networking is genuinely strong. Hub and spoke. Virtual WAN. Azure Firewall. Private Endpoints. The tools exist. But good architecture means making long term decisions from the start. Every shortcut today is a problem someone else explains later. Or fixes.

Security, compliance, and saying no

Everyone agrees security matters. Until it slows something down.

You present Zero Trust. Verify every identity, validate every device, assume breach. Everyone agrees. You recommend managed identities, PIM, Conditional Access with device compliance. Sensible, they say.

Then a developer needs Owner on production “just for a few days.” Consensus dissolves.

Just in time access sounds great in a presentation. At 4pm Friday when someone needs access urgently and the approver’s in a meeting? Suddenly it’s a “barrier to progress.”

The architect’s job is holding the line between agility and chaos. Saying no isn’t obstruction. It’s protection. Shortcuts that seem harmless accumulate. You end up with a security posture that looks good in a diagram and falls apart under actual scrutiny.

Compliance drives architecture

In Europe this gets heavier. GDPR dictates how personal data gets handled. Non compliance carries penalties that make surprise Azure bills look manageable. NIS2 hits operators of essential services, energy, transport, healthcare. DORA adds requirements for financial services around ICT risk, incident reporting, third party oversight.

Not checkboxes. Architectural drivers. They shape data residency, audit trails, encryption, ops processes. You’re not just building something technically sound. You’re building something that survives regulatory audits. Breach investigations.

Every decision reviewed with hindsight by people who weren’t there when you made it.

Compliance rarely gets recognition. Not the hero of the story. Shapes every chapter anyway.

FinOps: nobody cares till the invoice arrives

Cost conversation always comes. Sometimes too early, based on assumptions and some slide about “cloud savings.” More often way too late. Like, within 48 hours of the first monthly invoice. Finance email with a lot of question marks in the subject line.

Cloud economics are different. The elasticity that makes cloud powerful makes it expensive without discipline. A proof of concept nobody deleted. An oversized database SKU from a performance panic six months ago. A Premium SSD still attached to a VM that’s been deallocated since Q2. Stuff accumulates. Fast.

FinOps isn’t about barriers to deployment. It’s about cost being a feature, not a surprise. Tag everything. Set budget alerts. Build showback reports connecting spend to teams. Have cost reviews that result in actual action instead of spreadsheets that circulate and die.

First Azure bill is a rite of passage. Someone in finance goes pale. Suddenly everyone wants to talk governance. The architect’s job? Have that conversation before the bill. Not after.

Operations: the unglamorous stuff

Architecture in place. Landing zone deployed. Policies enforced. First workloads live. Now the real work starts.

Monitoring and logging aren’t optional. Azure Monitor and Log Analytics give you solid tooling. Without them, diagnosing issues means working blind. Manageable until it isn’t. And the moment it isn’t? Worst possible timing, obviously. Alerts need owners. Runbooks need to exist. On call processes need definition before incidents, not during.

Disaster recovery deserves attention because it’s consistently under invested until something breaks. Azure Site Recovery and Backup are capable. But they’re only as good as the objectives driving them. RTO, how long can the business tolerate this being down? RPO, how much data loss is actually acceptable? Business questions. Not technical ones. Get answers before disaster. Not during.

Operations doesn’t appear in presentations or strategy decks. It’s the difference between an environment that holds up under pressure and one that looks great on paper and fails the first real incident.

The multi team reality

Most difficulty in cloud architecture comes from team count. Not service count.

Platform team handles landing zone and shared infra. App teams want to deploy fast and have opinions about how the platform should work, opinions based entirely on their own needs. Security team has non negotiable standards and healthy scepticism. Networking team has strong views on the firewall. CISO read about a storage account breach and now wants to review every design decision. Finance keeps asking if there’s a cheaper option.

All legitimate concerns. Timelines differ massively. Success looks different to each of them. The architect sits in the middle. Translating between technical languages. Mediating between priorities. Occasionally delivering news that the agreed approach won’t work for reasons nobody raised.

Technical decisions aren’t the hard part. Getting twelve people from six teams to agree on naming? Takes forever. I’ve seen it take three months. For a naming convention.

What the job actually is

After all the technical decisions, the persistent challenge is human. Primary users of cloud platforms are developers. If the platform feels slow, confusing, restrictive, they’ll route around it. Not malice. Reasonable desire to deliver and meet deadlines. Shadow IT doesn’t happen because developers are reckless. Happens because the official path was harder than the unofficial one.

Architect’s job is empathy as much as engineering. Build a platform where teams move fast safely. Guardrails invisible enough not to feel like obstacles. Robust enough to catch problems nobody anticipated. Deploying should be straightforward, not bureaucratic. Secure path should also be easy path. Because if secure is hard, people find paths that aren’t.

Cloud architecture isn’t managing resources. It’s managing change. Building systems technically sound but also working for people, culture, business.
Anyone can deploy a VM. The architect makes sure that VM has proper naming, sits in the right subnet, has the right policies, gets monitored from day one, and can be explained to an auditor two years later without anyone sweating.

That’s harder. Also the only way that works.

---

Found this useful? Read more architecture and platform articles on larsschouwenaars.com/architecture. For questions or feedback, reach out via the about page.