Table of Contents
Balancing Control and Innovation in Cloud Architecture
Azure is a vast, complex environment, with real costs and real operational considerations. A well-defined cloud architecture must support the business, enable innovation, and balance the complexities of cost management, security, and governance.
Failing to address these pillars of cloud adoption can quickly lead to chaos — and, worse, have significant financial and security consequences.
In this post, I’ll explore how to build a robust cloud platform that supports innovation and flexibility while maintaining the governance standards necessary to protect the business.
The paradox of over-control
As cloud architects, we often inherit existing cloud implementations that don’t follow the best practices or governance standards we aspire to implement. In these situations, it’s tempting to take drastic measures to regain control. Locking down an environment, removing access, and almost starting from scratch are common strategies.
We then add layers of governance and restrictions: strict RBAC controls, multiple Azure Policies, and auditing of all resources and actions — before allowing anyone loose in the platform.
While sometimes necessary, maintaining these strict controls without collaborating with the business users of the cloud often leads to Shadow IT. Teams find alternative ways to work and innovate — creating new environments outside the landing zone, or using unapproved partners to host and deploy solutions.
The result is the opposite of what we intended: more risk, less visibility, and often higher costs. The key is balance and understanding.
What do good guard rails look like?
When we talk about guardrails, we mean the controls we put in place to enforce our standards and minimum expectations. I like to break these standards down into three categories:
- Non-Negotiable’s
- Strong Recommendations
- Nice-to-Haves
Thinking about guardrails in these categories helps communicate and illustrate what your minimum expectations are.
Non-Negotiable’s include:
- A defined naming convention for all resources
- A robust tagging schema aligned with budgeting and reporting requirements
- Basic security standards — no public access, no plaintext passwords
- An enforced RBAC model granting only the access required
Strong Recommendations include:
- Use of shared resources within the landing zone (e.g., networking, logging)
- Deploying solutions following a cloud-native mindset — IaC, scalable, robust, secure by design
Nice-to-Haves are areas that help maximise the investment in the cloud, such as automation improvements, monitoring enhancements, or advanced cost optimisations.
Implementing Guardrails in Azure
Azure Policy
- Forms the fundamental governance and enforcement layer
- Applies to all management endpoints: portal, APIs, IaC, scripts, etc.
- When designing policies, think “Block” over “Allow” — it’s more efficient to block a small set of actions than to allow a large set
- Can also configure deployments, e.g., applying predefined tags or enabling diagnostic/audit logs
RBAC through PIM
- Use RBAC with Entra Groups and Privileged Identity Management (PIM) to grant access
- Apply permissions at the resource group layer to control all resources within it
- Grant least privilege; avoid over-arching roles like Contributor or Owner
- Use PIM for just-in-time access
- Avoid deny permissions — well-designed allow permissions are easier to manage
The key step in guardrail design is understanding what you’re trying to achieve and the desired outcome. Keep it simple — complexity makes management harder. Communicate clearly, and always share the “why” behind these settings and controls with the teams adopting the cloud.
Culture Over Configuration
When cloud teams “take control” of an environment, it can sometimes feel like an “us vs them” situation. This is rarely the intent — and it’s certainly not what I aim for when redesigning a cloud platform.
Taking control should be seen as a means to an end — a way to get the cloud working for the business within a well-defined and supportive framework. A platform that is structured, secure, and easy to adopt.
The real driver of cloud success isn’t configuration — it’s culture. Building a culture of learning, collaboration, and continuous improvement is what makes a cloud environment sustainable.
Establish a regular cadence with business stakeholders who want to invest in cloud technology to achieve business goals. Understand the requirements of developers building systems and applications. Create genuine value relationships between the cloud teams and the wider business.
When teams understand that governance exists to enable, not restrict, they begin to adopt it willingly. And that’s when true innovation happens — not because of configuration, but because of culture.
Finding the balance
The goal of cloud architecture should be a simple one: Enable delivery – don’t block it.
With that in mind, and considering the key points around governance and standards, we can align our architectural designs using a simple framework:
SAFE
S – Set guardrails
A – Automate where possible
F – Foster feedback
E – Empower teams
When we bring the SAFE framework into our architectural design, we consider both the needs of the stakeholders adopting the cloud and those of the business from a security, cost, and operational perspective.
Cloud teams can help the business by building toolsets that support and enable rapid delivery — reusable IaC modules and templates that follow consistent standards and enforce the non-negotiables.
We should also foster a culture of learning and continuous improvement. Form a community that collaborates, experiments, and iterates. Don’t let pride get in the way — neither side will get it right the first time. The key is to learn, adapt, and evolve. Governance should never be static; the first iteration shouldn’t become a hard and fast rule.
Finally, communicate clearly. When teams understand why something exists, the how naturally follows. Remember: clouds are built on trust, not restrictions.