Skip to content

Cloud infrastructure on Azure

Azure your team can run without me.

A landing zone as code in your repository: management groups, hub-spoke networking, identity with PIM and a policy baseline, with production changes going through the pipeline. Built in 4-8 weeks, documented to survive my leaving.

The management groups and the four guardrails of the landing zone
  1. Level 1: [org_prefix] (root)
  2. Level 2: Platform
  3. Level 3: Identity
  4. Level 3: Management
  5. Level 3: Connectivity
  6. Level 2: Landing Zones
  7. Level 3: Corp (internal)
  8. Level 3: Online (internet-facing)
  9. Level 2: Sandbox
  10. Level 2: Decommissioned

Policies assigned at the root

  1. Allowed locations (EU regions only)Checks the region of every resource that has a location and supports tags.
  2. Require tag '<key>' on resourcesowner, cost-centre, environment, data-class
  3. Storage accounts must disable public blob accessChecks every storage account.
  4. CIS Microsoft Azure Foundations BenchmarkAudit only: a backlog against CIS, nothing blocked.
Assigned in Audit mode first and flipped to Deny once the estate is clean (RUNBOOK-04).

You leave with

  • A landing zone, deployed and documented

    Management groups, subscriptions, hub-spoke networking, identity. Essential builds a starter landing zone: the root and the nine groups of the template, and 3 to 5 subscriptions. A full estate typically ends up with 5 to 15 subscriptions. Sized to your estate at discovery, with an ADR for every decision that would be expensive to reverse.

  • Terraform in your org, with CI/CD

    The module library lands in your GitHub organisation, state in your storage account, plan-and-apply workflows included. Contribution guide written so your team extends it without calling me.

  • Identity with just-in-time privilege

    Entra ID foundation with PIM for every privileged role. PIM needs Microsoft Entra ID P2 or Entra ID Governance for each eligible user and approver; Business Premium and Microsoft 365 E3 do not include it on their own. Break-glass accounts sit outside PIM and are covered by a tested procedure. Pipelines authenticate through workload identity federation instead of secrets.

  • A policy baseline that produces evidence

    CIS Azure Foundations mapped to Azure Policy initiatives, tagging and region rules with deny effects, Defender for Cloud reporting into a control-mapping matrix your auditor can use.

  • Runbooks and the Exit Kit

    Ten operating procedures written alongside the build. The Exit Kit adds the state hand-off procedure, access removal on my side, and the list of anything unfinished.

What is in the delivery kit

The kit is shown as it ships. I send any runbook you ask for before you buy.

  • 00-bootstrap

    Remote state + GitHub OIDC bootstrap SOP, and the week-1 discovery questionnaire.

    • SOP-bootstrap.md
    • DISCOVERY-questionnaire.md
  • 01-architecture-decision-records

    Every irreversible decision written down, starting with the management-group topology.

    • ADR-0001-management-group-topology.md
    • ADR-TEMPLATE.md
  • 02-terraform

    The module library and CI/CD workflows, validated clean. Deployed into your GitHub org, state in your storage.

    • main.tf
    • backend.tf
    • providers.tf
    • variables.tf
    • modules/management-groups/
    • modules/networking-hub/
    • modules/networking-spoke/
    • modules/policy/
    • modules/subscription-vending/
    • .github/workflows/terraform-plan.yml
    • .github/workflows/terraform-apply.yml
  • 03-runbooks

    Ten operating procedures for the platform tasks that recur.

    • RUNBOOK-01-subscription-vending.md
    • RUNBOOK-02-break-glass-access.md
    • RUNBOOK-03-add-a-spoke.md
    • RUNBOOK-04-brownfield-onboarding.md
    • RUNBOOK-05-pim-privileged-access.md
    • RUNBOOK-06-policy-exception.md
    • RUNBOOK-07-rotate-secret-keyvault.md
    • RUNBOOK-08-compliance-drop.md
    • RUNBOOK-09-dr-drill.md
    • RUNBOOK-10-decommission-subscription.md
  • 04-exit-kit

    The Exit Kit: a map of what stays with you (tenant, subscriptions, repository, state, access), plus the Terraform state hand-off procedure.

    • EXIT-KIT-azure-landing-zone.md
    • terraform-state-handoff.md
  • 05-compliance

    Controls mapped to DORA, NIS2 and GDPR, with the pipeline as the evidence source.

    • control-mapping-matrix.md
  • 06-cis-azure-foundations

    The CIS Azure Foundations baseline checklist and the policy initiative that audits against it.

    • baseline-checklist.md
    • policy-initiative.md
  • 07-scope-sheet.md

    Essential and Operate scope boundaries, the basis of the Statement of Work.

  • 08-operate-pack

    The monthly platform review template: drift, policy compliance, cost by owner, access review.

    • monthly-platform-review-template.md

How it runs

Illustrative run. The kit assigns policies in Audit first and flips them to Deny once the estate is clean (RUNBOOK-04); the CIS set runs in Audit only.

  1. Pull request opened: add analytics spoke

    terraform plan runs in CI and lands as a comment on the pull request: 12 to add, 2 to change, 0 to destroy. The reviewer reads the actual diff of the estate instead of a portal screenshot.

  2. Plan reviewed before merge

    Region and cost-allocation tag pass; a public IP on the data subnet breaks the ADR rule and the CIS set flags it in Audit mode. The reviewer rejects the change in the pull request, before anything reaches production.

  3. Private endpoint replaces the public IP

    The plan re-runs on every push, so the reviewer sees the fix in the same pull request. The plan now shows 13 to add, including the private endpoint.

  4. Reviewed merge applies the change

    A named reviewer approves; the pipeline authenticates through workload identity federation. Production is not changed from the portal: nobody holds a standing write role, PIM grants it just in time, and a manual change is drift that goes back into code (RUNBOOK-08).

  5. Drift scan verifies state vs reality

    A scheduled state-vs-actual scan closes the loop. A hand-made change anywhere in the estate shows up at the next scan as a finding with a pull request attached.

Engagement tiers

Each tier carries its delivery arc inside it: discovery and ADRs first, build with a pilot workload next, then operate or a documented hand-off. The Statement of Work is signed before discovery starts and fixes the tier, the fee and the dates; if discovery shows a different estate size, the Statement of Work is amended in writing.

  • Essential

    The starter landing zone, built and handed over.

    Fixed scope · 4-8 weeks

  • Operate

    The landing zone plus the monthly review that checks it against the design.

    Monthly retainer · 30 days' notice for either party

Azure Virtual Desktop

Host pools sized to real concurrency, FSLogix profiles that survive host churn, and an autoscale plan tuned to your sign-in storm instead of a vendor default. It rides on the landing zone above and adds the session boundary, the image pipeline and the cost model. Azure compute is billed in your subscription under your agreement with Microsoft or your Microsoft partner; not on my invoice unless you buy it through me (then at list price through Pax8, on a separate line).

What lands in your repository

  • Working host pools, documented image lifecycle

    Pooled Windows 11 multi-session estate from versioned golden images. Hosts are rebuilt, not repaired: the image-change path in the AVD build is the only way to change a host, and the previous image version is always kept.

  • Autoscale with a measured cost curve

    The scaling plan follows your sign-in storm, and the monthly review reports euros per concurrent-user-hour and warm-idle ratio against a target under 15%.

  • Runbooks and evidence in your repo

    The operating procedures, the security baseline checklist and a control mapping matrix for DORA and NIS2, committed next to the Terraform. A mapping for your reviewer, not a certification I hold.

  • A capacity and cost model

    Concurrency-based projection from discovery data, refreshed by the monthly report, so you can check the bill against a forecast.

AVD engagement tiers

Each tier's Statement of Work is signed before work starts, so what is included is written down.

  • AVD pilot

    Design plus a two-week pilot with real users.

    Fixed fee, about 3 weeks

  • AVD build

    The production estate, wired, evidenced and handed over.

    Fixed scope, 4-6 weeks

  • AVD operate

    Monthly cost, image and scaling review by me, the person who built it.

    Monthly · 30 days' notice for either party

Assess AVD requirements, architecture, FSLogix recovery, security, cost and regional outage readiness. Capacity, image, identity, network and application compatibility decisions require environment testing.

Open the AVD readiness pack

What is not included

  • The landing zone

    I list exclusions so delivery stays fast. If something you need is here, I will tell you which service or partner picks it up.

    • Application migration to Azure (separate per-workload scope)
    • On-prem AD upgrade (case-by-case)
    • Custom ISV deployment automation (separate scope)
    • Cost optimisation beyond the landing-zone baseline. The free Cost Review for Azure reads your export first.
    • SOC or MDR coverage, on-call, and response to an active compromise.

    Cost Review for Azure, free

  • Azure Virtual Desktop

    Outside the AVD scope.

    • End-user training
    • Custom in-session app development
    • Citrix licensing procurement

Check it before you scope it

A free planning pack: six templates, the security baseline and policy intent, and the break-glass and monthly review procedures. It ships without Terraform, and the pack says so.

Open the landing zone readiness pack

The free Cost Review for Azure reads a Cost Management export in your browser, nothing uploaded. Every figure names the column or API it came from, and anything the read could not see is reported as unread rather than as zero.

Open the Cost Review for Azure

Legal entity, Microsoft partner identifiers, data location and exit terms in one register.

Open the register of information

Pricing

Fixed in writing before any work starts, from a 30-minute call. The price depends on the rows below.

Billing basis
Fixed fee per tier, set in the Statement of Work, which is signed before discovery starts.
AVD
AVD pilot and AVD build are a fixed fee each, set in the Statement of Work. AVD operate is the same monthly retainer as Azure Operate: ten hours a month.
Contract days
From €600 a day. Excluding VAT. Minimum two days. Invoiced monthly in arrears. Remote, Central European Time.
Azure consumption
Billed in your subscription under your agreement with Microsoft or your Microsoft partner; not on my invoice unless you buy it through me (then at list price through Pax8, on a separate line).
Currency
EUR, excluding VAT.
VAT
Reverse charge for EU businesses outside Malta whose VAT number validates in VIES. Malta VAT otherwise.
Invoiced by
Michal Jatczak, sole trader registered in Malta.
Service level
No SLA and no on-call duty. Dates are written into the Statement of Work.

Book a 30-minute call

The detail, if you want it

What each Azure tier includes
  • Essential

    • Weeks 1-2: discovery, regulatory mapping, ADR set signed
    • Weeks 3-6: landing zone + Terraform library deployed, pilot workload through it
    • Starter topology: the root and the nine groups of the template, 3 to 5 subscriptions
    • Entra ID + PIM foundation (PIM needs Entra ID P2 or Entra ID Governance), CIS policy + tagging baseline
    • 10 platform runbooks + 30-day hand-off support window

    A governed Azure estate your own team operates, with the design decisions on paper.

  • Operate

    • Everything in Essential
    • Drift scans on the schedule agreed at scoping; findings arrive as pull requests
    • Monthly platform review: drift, policy compliance, cost by owner
    • Quarterly Azure Policy + RBAC review with Defender tuning
    • Monthly retainer: ten hours a month, no roll-over, delivered by me, no response time promised, no minimum term, 30 days' notice for either party, invoiced monthly in advance

    The estate stays as designed. Your auditor can trace every change deployed through the pipeline to a reviewed pull request; a change outside the pipeline comes back as a finding with a pull request.

Azure Virtual Desktop: scope and what each tier includes
  • Host-pool topology and capacity model
  • Image pipeline (Packer or Azure VM Image Builder, plus Azure Compute Gallery)
  • FSLogix profile and Office container deployment
  • Autoscaling with a measured cost curve
  • App delivery: App Attach (MSIX or Appx packages), FSLogix App Masking or install-on-image per inventory
  • AVD pilot

    • Discovery questionnaire and capacity model
    • ADR set: topology, region, FSLogix, image strategy
    • Security baseline gap read
    • Pilot host pool with 5-10 real users for two weeks
    • Go or no-go memo with measured sign-in and cost numbers

    You know how AVD behaves with your users and your apps before committing.

  • AVD build

    • Terraform library deployed into your GitHub organisation
    • Host pools, FSLogix premium storage, scaling plan per the ADRs
    • Image pipeline with Azure Compute Gallery and first golden image
    • App delivery (App Attach or on-image per inventory)
    • All ten runbooks, baseline verified, Exit Kit included

    A production AVD estate your team can operate from the runbooks alone.

  • AVD operate

    • Monthly cost-vs-concurrency report with one proposed change
    • Monthly image rolls with pilot-group validation
    • Scaling plan tuning as working patterns move
    • Quarterly baseline re-check and control matrix refresh
    • Questions answered within the monthly hours, no response time promised
    • Monthly retainer: ten hours a month, no roll-over, delivered by me, no response time promised, no minimum term, 30 days' notice for either party, invoiced monthly in advance

    Sign-in stays fast and cost stays inside the reviewed model.

Do you support Bicep, Pulumi, CDK or Terraform?

Terraform is the default and the only language the kit ships. Bicep, CDK or Pulumi are possible where your team already works in them, scoped separately.

Do we need a full CAF deployment, or can we start smaller?

Start smaller. Essential builds a starter landing zone: the root and the nine groups of the template, and 3 to 5 subscriptions. A full estate typically ends up with 5 to 15 subscriptions. Existing subscriptions stay where they are until a planned wave moves them.

Can our team still use the portal?

For reading, dashboards and diagnostics: yes. Production is not changed from the portal: nobody holds a standing write role, PIM grants it just in time, and a manual change is drift that goes back into code (RUNBOOK-08). A documented break-glass path covers real emergencies. Sandbox subscriptions stay open for experiments, so the guardrails protect production without slowing anyone's learning down.

Who approves changes: you or me?

Your people. Reviewers on the repository and PIM approvers are named client roles from day one; I submit pull requests like everyone else. On Operate I also review, and the approval authority stays with your people.

What does the landing zone itself cost to run?

The management plane (management groups, policy, RBAC) costs nothing. Run-rate comes from the hub (Azure Firewall and gateways), logging retention and the paid Defender for Cloud plan the kit enables, since Defender for Cloud shows the CIS standard only with a paid plan. Each is sized and priced in the design phase before anything is deployed. If a Firewall SKU is oversized for your estate, the design says so.

We already have resources in Azure. Greenfield only?

Brownfield is the normal case. Existing subscriptions are inventoried at discovery, imported into state or migrated in planned waves, and nothing is moved without its owner knowing the window.

What happens to the Terraform if we part ways?

It stays with you: it was in your GitHub organisation and your state storage from the first commit. Once paid for, you may use and change the deliverables, this code included, inside your organisation for good, and pass them to another supplier (Terms of Service, section 6). The Exit Kit adds the state hand-off procedure, access removal on my side, and the list of anything unfinished. That applies to every tier.

AVD or Windows 365?

Different problems. Windows 365: simple, per-user, low flexibility. AVD: dense, cost-efficient at scale, more operational overhead.

Why is an AVD bill so unpredictable?

Almost always one of two things: hosts sized to headcount instead of measured concurrency, or autoscale never enabled because nobody trusted it with live sessions. The kit fixes both: the capacity model sizes to peak concurrency, and the scaling plan drains hosts only at zero active sessions.

Do your Microsoft 365 E3, Microsoft 365 E5 or Business Premium licences already cover AVD?

For Windows 11 Enterprise multi-session access rights: yes, those licences carry them (confirmed against current Microsoft terms during discovery). What you pay on top is Azure compute and storage, which is the part the capacity model and autoscale keep in check.

Can contractors use AVD from personal devices?

That is one of the main reasons to run AVD. Contractors get browser access to published apps only: no client install, no drive or clipboard redirection, access that expires on the project end date by default. The contractor access flow is part of the AVD build runbooks. Each contractor needs an AVD-eligible licence (Microsoft 365 E3 or Business Premium, for example) assigned to their account in your tenant; a licence from their own company generally does not count.

Write the subscription design down before the next resource group appears.

Two hours live on your subscriptions, identity, network boundary and policy intent. A written pack follows within 5 business days.

Exit Kit with state hand-off, every tier.

Clause effective 28 October 2026