Cloud Architecture: why technology is the easy part

Major cloud project starts in the same place,not with a technical requirement, but with a business aspiration. Someone, somewhere, has a goal: innovate faster, improve resilience, reduce costs. And then it lands on your desk: “We need to move to the cloud.” Sometimes it arrives as a polished strategy deck. Sometimes it is a two-line email from someone whose title contains the word “Chief.” Either way, the subtext is identical: make it happen, make it secure, make it compliant, and ideally make it happen by yesterday.

On paper, it sounds simple. In reality, the complexity does not come from the cloud itself, it comes from everything around it. The people, the expectations, the legacy systems, and the weight of decisions that nobody has made yet. This is what cloud architecture actually looks like, beyond the polished diagrams and the well-intentioned landing zone blueprints. It is messy. It is human. And it is the story of turning business aspirations into architecture that actually works.

“Just moving to Azure”

That initial meeting is full of optimism. The cloud is strategic. Competitors are doing it. It promises speed and agility. Everyone in the room is nodding. Then the meeting ends, and you are left with a one-line brief and about forty unasked questions.

The first challenge is unpacking what “moving to Azure” actually means. These are foundational cloud architecture decisions with different timelines, budgets, and risk profiles. A modernisation effort, refactoring applications to use managed services? Or building something new from scratch? These are not implementation details, they are fundamentally different projects with different timelines, budgets, and risk profiles. Before a single resource is deployed, you are navigating a maze of questions about regulatory requirements, organisational maturity, security posture, and the real, unspoken business objectives hiding behind the marketing language.

The hardest part, you quickly learn, is translation. The business talks about outcomes. Finance talks about budgets. Security talks about risks. Developers just want clean Bicep or Terraform and a pipeline that does not take twenty minutes to run. And almost everyone, from the project sponsor to the CIO arrives with the quiet conviction that the cloud will be cheaper. That assumption is the ghost that haunts every future conversation. The first Azure bill will exorcise it, loudly, at exactly the wrong moment.

Everyone agrees on the destination called “the cloud.” Rarely does anyone agree on what that place actually looks like.

The invisible architecture

One of the biggest surprises for people outside the role is how much of cloud architecture is invisible. For every visible resource, a virtual machine, a SQL database, a virtual network, there are dozens of unseen decisions shaping its existence. Naming conventions, tagging strategies, identity governance, region selection, cost-control guardrails, management group hierarchies, Azure Policy assignments, compliance baselines. These are the invisible foundations of sound cloud architecture, the things you build so that nobody ever notices they are there.

People are often surprised to learn that Azure does not enforce your naming standards, does not automatically segment network traffic, and will not prevent a developer from accidentally exposing a storage account to the public internet at 4pm on a Friday. The cloud provides extraordinarily powerful tools. The architect’s job is to build a safe, coherent system around those tools, and then enforce it consistently across teams who have different priorities, different timelines, and different definitions of the word “done.”

The tools that make it stick

Two tools do most of the heavy lifting here. Azure Policy lets you define and enforce rules across your entire Azure environment, preventing resources from deploying outside approved regions, requiring specific tags, enforcing encryption standards, and auditing compliance continuously. Microsoft Defender for Cloud provides a continuous security posture score, threat detection, and compliance assessments against frameworks like CIS, NIST, and ISO 27001. Together, they are how you make the invisible architecture stick, not through documentation that nobody reads, but through technical enforcement that leaves no room for accidental deviation.

This work is made harder because it never happens in a vacuum. You design within an ecosystem of legacy systems, entrenched processes, siloed teams, and a security department that is justifiably wary of change and has seen enough “we will fix it after go-live” promises to last several careers. The irony is that the most elegant cloud environments look effortless. That effortlessness is a hard-won victory, the result of countless arguments, compromises, and decisions made long before the first workload goes live.

The Landing Zone: Architecture’s first major battle

Before any workload touches Azure, the cloud architecture needs a foundation. That foundation has a name: the landing zone. And it is where cloud architecture stops being a theoretical exercise and starts being a political one.

A landing zone is not a collection of Bicep templates. It is a binding agreement between teams about how they will work together in the cloud, expressed in infrastructure. Management group and subscription structure defines how you organise Azure resources across teams, environments, and business units. Networking topology comes next, hub-and-spoke or Virtual WAN, how connectivity to on-premises works, where the firewalls sit. Identity governance follows: who has access to what, through what mechanisms, with what approval processes.

Security baselines are enforced through Azure Policy, and logging, monitoring, and cost management are established from day one.

Microsoft publishes the Azure Landing Zone accelerator as a reference architecture, and it is genuinely excellent. The challenge is that a reference architecture assumes a clean starting point. Most organisations do not have a clean starting point. They have three existing subscriptions someone created without a naming convention, a legacy VPN that became permanent somewhere around 2019, and four teams who each have their own definition of what “production” means.

The landing zone meets resistance because it makes implicit decisions explicit. Teams that have operated independently suddenly have to agree on shared standards. Decisions that were previously deferred, what is our tagging strategy? who owns the hub network? which team is responsible for the firewall policies?, can no longer be ignored. This is why landing zone projects regularly take longer than expected. The

Bicep is the easy part. The consensus is not.

Identity: Where Architecture meets organisational history

If you want to test a cloud architect’s patience, ask them to map out the identity landscape. Every cloud journey eventually collides with the reality of Microsoft Entra ID, and the collision is rarely graceful.

Identity is where abstract architecture meets concrete organisational history. You are not just designing a structure for who-can-do-what, you are excavating a digital archaeology site. Expect to find deeply nested security groups whose original purpose nobody can remember.

Service principals with Contributor rights on every subscription and no documented owner. Orphaned accounts belonging to contractors who left eighteen months ago. Administrators holding Global Admin rights “just in case”, which, translated, means “I don’t trust the access model enough to give it up.” Nothing says “we have been doing this for ten years” quite like a service principal with Owner permissions on the root management group and a last-used date of never.

The conversation rapidly stops being about technology and becomes about sociology. Cleaning up the identity estate and establishing a proper framework, defining administrative units, enforcing least privilege, planning regular access reviews, implementing Privileged Identity Management for just-in-time role activation, is foundational work. Identity is the security perimeter now. The network perimeter still matters, but it is a secondary line of defence, not the primary one.

Because identity is messy and touches every part of the organisation, it is almost always the first and most politically charged challenge. The technical fix is straightforward. Getting twelve teams to agree to give up their standing permissions is a different kind of project entirely.

Networking: Where every choice casts a long shadow

You can change policies. You can reassign roles. Networks are stubborn. The address spaces, region topology, peering model, and connectivity decisions you make today will shape or constrain your organisation for years. These are architectural decisions with consequences that compound over time.

This is where you find yourself explaining to leadership why a “simple peering connection” is not a long-term strategy, or why that “temporary” VPN has now become a permanent, unsupported, and undocumented piece of the architecture that three critical workloads depend on. Hybrid connectivity is the great equaliser of ambition, it introduces you to the joys of overlapping IP address spaces, on-premises networks that nobody fully documented, and the persistent belief that connecting everything is simply a matter of purchasing the correct SKU.

Overlapping IP ranges are not a networking problem. They are a time machine, they take you straight back to the day someone said “we’ll plan the address space properly later” and then never did. Resolving them after the fact, with live workloads depending on the affected ranges, is an exercise in patience that no architect forgets.

Azure networking is genuinely powerful, but good cloud architecture demands long-term thinking from the very first decision for hub-and-spoke topologies, Azure Virtual WAN for global connectivity, Azure Firewall for centralised traffic inspection, Private Endpoints for keeping PaaS services off the public internet. The capabilities are excellent. However, the architecture demands long-term thinking from the very first decision. Every shortcut taken today becomes a problem the architect will have to solve, or explain, tomorrow.

Security, compliance, and the art of the necessary no

Everyone agrees security is critical. Right up until it slows something down. That is the central tension of cloud architecture, and it never fully resolves.

You present a Zero Trust model, verifying every identity, validating every device, assuming breach as a baseline. Everyone nods. You recommend managed identities instead of stored credentials, just-in-time access through Privileged Identity Management, and Conditional Access policies enforcing device compliance. Everyone agrees it sounds sensible. Then a developer needs Owner permissions on a production subscription “just for a few days to get things done,” and the consensus evaporates. Just-in-time access is excellent until the developer needs access at 4pm on a Friday and the approver is at a football match. At that point it becomes, briefly, a barrier to innovation.

The architect’s role is maintaining the boundary between agility and chaos. Saying no is not about being obstructive, it is about protecting the environment from well-intentioned but dangerous shortcuts. The shortcuts that seem harmless individually have a way of accumulating into a security posture that looks fine in a diagram and falls apart under scrutiny.

When Compliance Becomes an Architectural Driver

In Europe, this responsibility carries additional weight. GDPR dictates how personal data must be handled, stored, and protected and non-compliance carries fines that make the Azure bill look modest. NIS2 establishes security requirements for operators of essential services across sectors including energy, transport, healthcare, and digital infrastructure. For organisations in financial services, DORA, the Digital Operational Resilience Act adds specific requirements around ICT risk management, incident reporting, and third-party provider oversight.

These regulations are not checkboxes. They are architectural drivers. They dictate data residency decisions, audit trail requirements, encryption standards, and operational processes. You are not just designing a technically sound system, you are designing one that can survive legal scrutiny, a regulatory audit, and a breach investigation in which every decision you made will be reviewed with the benefit of hindsight.

Compliance rarely gets the recognition it deserves. It is almost never the hero of the story. It quietly shapes every chapter anyway.

FinOps: The discipline nobody wants until the bill arrives

The cost conversation always comes. Sometimes too early, before any architecture decisions are made and based entirely on assumptions. More often, far too late, typically within forty-eight hours of the first monthly Azure invoice, accompanied by an email from finance with a lot of question marks in the subject line.

Cloud economics are fundamentally different from on-premises economics. The elasticity that makes the cloud powerful also makes it expensive without governance. An abandoned proof-of-concept still running because nobody remembered to delete it. An oversized database SKU chosen during a performance concern that was resolved six months ago. A forgotten Premium SSD disk attached to a deallocated VM. These things quietly bleed budget, and they accumulate faster than anyone expects.

FinOps, the practice of financial accountability in cloud environments is not about creating barriers to deployment. It is about building a culture where cost is treated as a feature, not a surprise. The FinOps Foundation defines it as a discipline requiring active collaboration between engineering, finance, and business teams, not a set of technical controls that the cloud architect imposes unilaterally. In practice, this means tagging every resource with meaningful metadata, setting budgets with automated alerts, building showback and chargeback reports that connect cloud spend to the teams generating it, and establishing a regular cadence of cost reviews that actually result in action.

The first Azure bill is a rite of passage. It arrives, someone in finance goes pale, and suddenly everyone wants to talk about governance. The architect’s job is to have the governance conversation before that moment, not after it.

Operations: The unglamorous work that keeps everything running

Once the architecture is designed, the landing zone is deployed, the policies are enforced, and the first workloads are live, the real work begins. Operations is where beautiful architecture meets the real world, and the real world is not always kind.

Monitoring and logging are non-negotiable. Azure Monitor and Log Analytics provide excellent tooling for aggregating metrics, logs, and traces from across your environment. Without them, diagnosing a performance issue or a security incident means flying blind, which is fine until it is not, and the moment it is not is always at the worst possible time. Alerts need owners. Runbooks need to exist and be current. On-call processes need to be defined before an incident, not improvised during one.

Disaster recovery deserves particular attention because it is the area most frequently under-invested until something actually goes wrong. Azure Site Recovery and Azure Backup provide strong capabilities, but the tools are only as good as the recovery objectives behind them. What is the Recovery Time Objective, how long can the business tolerate this system being unavailable? What is the Recovery Point Objective, how much data loss is acceptable? These are business questions, not technical ones, and getting answers to them before a disaster is considerably more productive than getting answers to them during one.

Operations is unglamorous. It does not make it into architecture presentations or strategy decks. It is, however, the difference between a cloud environment that works reliably under pressure and one that looks excellent in a diagram and collapses at the first real incident.

The multi-team reality nobody puts in the project plan

Here is something that does not appear in cloud architecture textbooks: most of the difficulty comes from the number of teams involved, not the number of services.

A typical enterprise cloud project involves a platform team responsible for the landing zone and shared infrastructure. Application teams who want to deploy workloads and have opinions about how the platform should work, shaped entirely by their specific requirements. A security team with non-negotiable requirements and a healthy scepticism toward everyone else’s risk assessments. A networking team that has strong feelings about the firewall and is not entirely sure they trust the cloud team’s routing decisions. A CISO who has read about a breach involving a misconfigured storage account and now wants to review every architecture decision personally. And a finance team who keep asking if there is a cheaper option.

Each of these teams has legitimate concerns. Their timelines differ significantly. Success, for each of them, means something entirely different. The cloud architect sits at the intersection of all of them, translating between technical languages, mediating between competing priorities, and occasionally delivering the unwelcome news that the approach everyone has agreed on will not actually work for a reason nobody thought to ask about.

The technical decisions in cloud architecture are rarely the hardest ones. Getting twelve people from six teams to agree on a naming convention, on the other hand, can take a surprisingly long time.

The Architect’s true role

After all the technical decisions are made, the most persistent challenge remains the human one. A cloud platform’s primary users are developers, and if that platform is slow, confusing, or restrictive, they will find ways around it. Not out of malice, out of a perfectly reasonable desire to deliver value and meet their deadlines. Shadow IT does not happen because developers are reckless. It happens because the official path was harder than the unofficial one.

The architect’s job, therefore, is empathy as much as engineering. Build a platform that empowers teams to move fast safely, where the guardrails are invisible enough not to feel like obstacles, and robust enough to catch the problems nobody anticipated. Where deploying a new workload is straightforward, not a bureaucratic exercise. Where the secure path is also the easy path, because if the secure path is hard, developers will find a path that is not.

The unseen work of cloud architecture is not managing cloud resources, it is managing change. It is building systems that are not just technically sound, but that work for the people, the culture, and the business they are meant to serve.

Anyone can deploy a virtual machine. The architect’s job is to build the environment where that virtual machine belongs to a naming convention, sits in the right subnet, has the correct policies applied, gets monitored from day one, and can be explained to an auditor two years later without anyone breaking into a sweat.

That is the hard way. It is also the only way that actually works.

---

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