Lesson 2: The Standard Hybrid Profile

Why start with a profile, not a product

In Level 1 you saw every Azure hybrid and edge service on one map. Faced with that map, it's tempting to point at a box and say "we'll use Azure Local". Experienced architects hold off. They write down the problem first, then let the services compete for it.

The tool for that is a standard hybrid profile: one short document, filled in the same way for every organisation, that you can reuse for every service lesson that follows. Think of it like a patient's chart. A doctor records the symptoms before prescribing, so the next specialist doesn't start from zero.

The profile has two halves:

1. Why an Azure region will not do. If no reason survives scrutiny, the answer is "move to a region" and you can stop.
2. The facts of the estate: sites, connectivity, workloads, who maintains the hardware, update windows, compliance, team skills and the cost model.

Part 1: the four reasons a region won't do

There are four reasons you can defend. Anything else, such as "we've always run it here", usually points to a migration problem, not a hybrid one.

Rank them. Most organisations have more than one reason, and services trade them off differently. Give each reason a weight and mark whether it is a hard gate (fail it and the service is out) or a preference.

Gotcha: teams often list "latency" when nobody has measured it. Before you rank it, run a ping or HTTP timing test from the site to the nearest region. One measured number beats ten opinions.

Part 2: the rest of the profile

Here is a filled-in profile for a sample organisation, a UK food manufacturer with two plants, kept as YAML so it can live in git next to your infrastructure code:

# hybrid-profile.yaml  (version it; review every 6 months)
org: Northvale Foods
date: 2026-10-30
why_not_region:              # ranked, highest weight first
  - reason: latency
    weight: 5
    hard_gate: true          # vision QA must answer in <10 ms
    evidence: "measured 28 ms p95 to UK South, 2026-10-12"
  - reason: disconnected_operation
    weight: 4
    hard_gate: true          # lines must run 72 h with WAN down
  - reason: existing_hardware
    weight: 2
    hard_gate: false         # nice to reuse, not required
  - reason: data_residency
    weight: 1
    hard_gate: false         # UK-only; a UK region would satisfy it
sites:
  - {name: Leeds, racks: 1, power_kw: 4, cooling: yes, staff_on_site: "IT 9-5"}
  - {name: Hull,  racks: 0.5, power_kw: 2, cooling: no,  staff_on_site: "none"}
connectivity: {Leeds: "1 Gbps fibre, single path", Hull: "100 Mbps, 4G backup"}
workloads:
  - {name: vision-qa, type: containers, gpu: true}
  - {name: mes-db, type: "SQL Server VM", cores: 8}
  - {name: file-shares, type: SMB, size_tb: 12}
hardware_maintained_by: "us (Leeds); nobody (Hull)"
update_windows: "Sun 02:00-06:00, max 1 per month; never in Dec peak"
compliance: [ISO 27001, BRCGS food safety]
team_skills: {windows_server: strong, kubernetes: weak, azure: medium}

Notice what each line is for. Hull: staff_on_site: none already rules out anything that needs someone on site to swap disks. kubernetes: weak is a cost too: training or a partner.

Part 3: turn answers into pass/fail requirements

A profile answer such as "poor network" can't be tested. A requirement can. Rewrite every answer as a statement that a service either meets or fails:

Now each service lesson becomes a quick exercise: run R1–R4 against it and mark pass or fail.

Part 4: the cost model inputs

Hybrid pricing comes in several units, so record the inputs before you compare anything. These examples are dated October 2026 and come from Azure's public pricing pages. Treat them as examples and check the pricing calculator before you quote.

• Per server: e.g. Azure Update Manager on an Arc-connected server is $5 per server per month.
• Per physical core: Azure Local charges a host fee per physical core per month (60-day free trial). The Windows Server guest subscription is listed at $23.30 per core per month. Azure Hybrid Benefit (Datacenter + Software Assurance) waives both, but only for the standard connected hyperconverged deployment.
• Per vCPU or per core per year: Azure Stack Hub offers pay-as-you-use per vCPU, or an annual capacity model priced per physical core for disconnected sites.
• Hardware as a subscription: Azure Stack Edge Pro 2 is listed at roughly $399–$615 per month. Billing starts on delivery and stops only when you start the return, so a device sitting unused still costs money.
• Hardware buy or lease: purchase price, lease term, and support contract end date.
• Commitment length: one or three years, and the penalty for leaving early.
• Data transfer: GB per month leaving Azure, plus one-off bulk moves.

A tiny script makes the comparison honest by bringing everything to a 36-month figure:

# cost_inputs.py: normalise to 36 months (example numbers)
cores, months = 32, 36
host_fee_per_core = 10.0       # $ example; confirm in calculator
win_guest_per_core = 23.30     # $ list, Oct 2026
hardware_buy = 60_000          # $ one-off, 2 nodes
egress_gb_month, egress_rate = 500, 0.08

total = (cores * (host_fee_per_core + win_guest_per_core) * months
         + hardware_buy
         + egress_gb_month * egress_rate * months)
print(f"36-month total: ${total:,.0f}")
# -> 36-month total: $99,805

Best practice: record which numbers are list prices and which are quotes, and add the date. A cost model with no date goes stale without anyone noticing.

Key takeaways

• Write the profile before you pick a product. If none of the four reasons (latency, residency, disconnected operation, existing hardware) holds up, use a region.
• Rank the reasons with weights, and mark each one as a hard gate or a preference. Measure latency before you claim it.
• Record sites, connectivity, workloads, who maintains the hardware, update windows, compliance and team skills.
• Rewrite each answer as a testable requirement that a service can pass or fail.
• Cost inputs come in different units (per server, per core, per vCPU, hardware subscription, buy or lease, commitment, data transfer). Convert them all to the same time period, and date every price.