Platform landing zones on Azure — roadshow notes

SoftServe’s RoadShow Poland tour passed through Rzeszów on 12 October and Kraków on 14 October. I had the same lecture slot at both campuses — Platform Landing Zone for Azure Cloud — and most people in the room had never registered an Azure tenant for a company before.

Instead of opening with enterprise vocabulary, I used a simple story: imagine you and a few colleagues just founded a student association, or a first small startup after graduation. You need a place to manage accounts, shared mail, maybe an app or two, and eventually something you deploy for users — but nobody has done “company cloud” before. Walking through that scenario made it easier to explain what a tenant is, why Entra groups exist, and why Microsoft separates a platform landing zone (shared identity and foundation) from an application landing zone (where your product actually runs). Register the association’s domain, add members, set who can do what, then think about subscriptions and resources — same building blocks, smaller scale than a bank, but the same ideas.

The slides are not on this site — I would prefer to avoid anything with company branding on my private website — so this post is what I covered, in the order the roadshow ran it.

Platform vs application — the split I used on stage

Microsoft’s Cloud Adoption Framework framing is what I leaned on when a question started at “we need a VM in Azure.”

Platform landing zone is the shared foundation: management groups, policy, connectivity, central logging, identity patterns — guardrails every workload inherits, even when an app team is focused on their own code.

Application landing zone is where a product team works: dev, test, prod, networking into shared services, pipelines that deploy their application.

In the deck I spent time on Entra ID in that student-association frame — users, security groups, M365 groups, device policies, SSO for apps the whole circle uses. For many students that was when Azure started to look broader than virtual machines. The “platform” part was everything the association shares; the “application” part was whichever project one team inside the group is shipping.

It helps to be explicit about who may create subscriptions and assign high-privilege roles. When that is undefined, teams usually improvise — and improvisation does not age well, whether you are three friends with a startup or three hundred people in a delivery organization.

Entra and RBAC in plain language

I prefer assigning RBAC to groups rather than to individual users. It takes a bit more setup, but access reviews and handovers are much easier. Platform engineers typically need rights on policy, hub networking, and shared services. Application teams need rights within their own scope — usually not on shared connectivity resources that many workloads depend on.

Device management and conditional access were overview topics — enough to show that “cloud for a company” is not only VMs and storage accounts. Once the same Entra tenant serves everyday engineer access and separate break-glass paths for production, keeping those paths distinct matters. I only had time to point at the idea; nobody in the room was ready to implement it that afternoon.

Policy and diagrams

Landing zone diagrams on Microsoft Learn are clean and helpful. The practical message I tried to leave: even a small organization benefits from a little Azure Policy early — allowed regions, required tags, sensible defaults on encryption. Teams often wait until cost or compliance forces the conversation; starting with a small mandatory set is easier than retrofitting after ten subscriptions exist.

A question from Kraków that stuck with me: “Can we skip the platform layer if we only have one app?” Honest answer: you can, until you have two apps and three people who each set up logging differently. The platform layer does not need to be huge on day one. Clear boundaries help early.

Pricing habits — light topic, real topic

The roadshow deck ended on pricing: pre-paid vs pay-as-you-go, the pricing calculator, and deleting resources you no longer need. Light topic for an open lecture day between VR demos and speed recruiting; still the thing students asked about in the corridor afterward.

Sandbox subscriptions without owners, temporary environments that never get torn down, and shared services with no budget line — those show up in production later, not in a ninety-minute slot. Worth mentioning so the first Azure bill is not a complete surprise.

If you are past “create a tenant and a VM,” pick Terraform or Bicep, standardize on one, document who owns the shared layer, and read the landing zone design areas before the second application team arrives.

Four years later

Re-reading this in 2026, the student-association framing still works for onboarding — but enterprise customers now ask about AI workloads on the same landing zone: which subscription hosts Azure OpenAI or Foundry, how private endpoints and policy apply to model endpoints, and whether the platform team or the app team owns agent deployment. The split between platform and application landing zones did not change; the list of “shared services” did. Identity, policy, and connectivity remain the hard parts. The new services are another reason to get the boundaries right early.