Azure Platform Architecture

This document is written for those accountable for the Azure platform. Not for those designing diagrams.

For those responsible when structure breaks, access expands, controls drift, or security cannot be proven under audit.

Azure platform architecture is not a drawing. It is not a reference model. It is not a one-time design exercise.

It is the structure that determines whether governance, security, and control hold as the environment scales.

Most organizations believe they have an architecture. In reality, they have a diagram.

But architecture is not what is documented. It is what is enforced.

The problem with Azure architectures

Most Azure architectures start structured:

• Management groups are defined
• Subscriptions are organized
• Policies are assigned
• Identity is designed
• Security baselines are introduced

Then reality takes over:

• New subscriptions are created outside structure
• Access is granted outside defined roles
• Policies are modified or disabled
• Security controls are bypassed
• Logging becomes inconsistent

The architecture remains documented, but it no longer reflects the platform.

That is where control is lost.

What Azure platform architecture actually is

Azure platform architecture is a continuously enforced structure across four core layers:

• Management groups
• Identity
• Policy
• Security baseline

• Clear structure, so scope is defined
• Consistent identity, so access is controlled
• Policy enforcement, so standards cannot be bypassed
• Security baseline, so risk is reduced systematically

Architecture is not about placement. It is about behavior over time.

Management groups define control scope

• Consistent policy inheritance
• Separation of environments
• Central control with delegation

Without structure, governance becomes fragmented.

Identity is the control plane

• Clear ownership of roles
• Least-privilege access
• Separation of platform and workload identities
• Consistent role usage

If identity is not controlled, nothing is controlled.

Policy defines and enforces boundaries

• Consistent enforcement
• Prevention of drift
• Automatic inheritance

Without enforcement, policy becomes guidance. Guidance is ignored.

Security baseline reduces systemic risk

• Logging always active
• Controls consistently applied
• Risk reduced by default

Without baseline, security becomes reactive.

Architecture must be enforced continuously

• New services are introduced
• Teams move faster
• Exceptions increase
• Complexity grows

Without enforcement, architecture becomes irrelevant.

Where MyPlatform fits

• CAF-aligned management group structure
• Identity and access enforced by design
• Policy-as-code across environments
• Continuous security baseline

Everything runs inside the customer’s Azure tenant. No external control plane. No hidden logic.

The result is not an architecture diagram. It is an architecture that holds over time.

Start here

• Structure breaks
• Access expands
• Controls drift
• Risk accumulates

Define structure. Control identity. Enforce policy. Maintain security. Then scale.