Lesson 2: The Standard Hybrid Profile

Why a profile comes before a product

In Level 1 you saw every AWS hybrid and edge service on one page. The usual next mistake is to pick one straight away ("we'll get an Outpost") before anyone has written down what the site needs. Experienced teams do it the other way round. They fill in one standard hybrid profile per site, and the profile points to the service.

Think of it as a surveyor's report done before you choose a builder. It's the same form for every site and every project, so two sites, or AWS and another cloud, can be compared on the same terms. Later levels score each service against this profile. Today you just fill it in.

Step 1: Name the reason a region won't do

Your default should always be "run it in a region". It's the cheapest option for you to operate and has the most features. You need a written reason to leave it, and there are only four that hold up:

Gotcha: "The business prefers on-prem" is not a reason. If none of the four applies, the profile should say region and you can stop there. If two apply, write down which one is binding, meaning the one that would still rule out a region if the others went away.

Step 2: Fill in the profile

Keep it as YAML in the project repository so it gets reviewed like code. Here is a worked example for a food-processing plant in Leeds:

# hybrid-profile/leeds-plant.yaml  (reviewed 2026-10-30)
site:
  name: leeds-plant
  parent_region: eu-west-2          # nearest AWS Region (London)
  floor_space: "2 x 42U racks free"
  power_cooling: "8 kVA per rack, N+1 cooling"
  physical_access: "badge + escort; loading dock 2.4 m door"
why_not_region:
  binding: disconnected_operation   # the one that rules a region out
  others: [latency]                 # 8 ms line-control loop
  evidence: "Line must run 24 h with the WAN down (ops policy OP-12)"
connectivity:                       # measured figures, not hopes
  rtt_to_region_ms_p95: 14
  bandwidth_mbps: 1000
  redundant_links: false
  longest_expected_outage_h: 24
workloads:
  - {name: line-control, type: containers, vcpu: 96, state: local-db}
  - {name: reporting,   type: vm,         vcpu: 16, state: none}
hardware:
  owner: customer                   # customer | provider
  maintained_by: "local IT, 1 engineer, business hours"
updates:
  window: "Sun 02:00-06:00"
  max_version_lag: "one minor release"
compliance: [ISO27001, "BRCGS food safety audit logs kept 3 years"]
team_skills: {kubernetes: medium, ecs: low, vmware: high, aws: medium}

Each field leads to a later decision. Hardware owner tells you whether provider-maintained racks are even on the table. Team skills often settle Kubernetes against ECS before any feature comparison does.

Step 3: Put connectivity in numbers

The networking course covered link types: VPN, Direct Connect, redundancy. Here you only record three numbers, and you measure them rather than guess:

# Round-trip time to the parent region (use a test instance's endpoint)
ping -c 100 ec2.eu-west-2.amazonaws.com | tail -1
# rtt min/avg/max/mdev = 12.8/13.6/21.4/1.9 ms  -> record the p95 (~14 ms), not the minimum

# Usable bandwidth to an EC2 test host in the region running `iperf3 -s`
iperf3 -c 203.0.113.10 -t 30 -P 4
# [SUM] 0.00-30.00 sec  3.30 GBytes  945 Mbits/sec  receiver

The third number, longest expected outage, comes from the link's history and the carrier's contract, not from a command.

These numbers matter because some services set hard thresholds. Outposts racks, for example, are documented as needing a service link of at least 500 Mbps per compute rack with a round trip no longer than 175 ms to the region. A profile that says "a decent link" can't be checked against a rule like that. A profile that says "14 ms, 1,000 Mbps, single link, 24 h outage" can.

Step 4: Draft the cost model

Hybrid costs are spread across more lines than region costs, and the lines people forget are where projects go over budget. Use these five lines every time. The prices below are dated examples (US list prices, October 2026), so check them again before you use them.

Add it up with a few lines of code rather than a spreadsheet nobody can review:

H = 730  # hours per month
# Option: EKS Hybrid Nodes on the plant's own 6 x 16-vCPU servers
nodes_vcpu   = 6 * 16 * H * 0.020   # = $1,401.60/month (first price tier)
cluster      = 1 * H * 0.10         # = $73.00/month
staff        = 0.2 * 120_000 / 12   # = $2,000.00/month
hw_deprec    = 90_000 / 60          # owned servers over 5 years = $1,500/month
print(round(nodes_vcpu + cluster + staff + hw_deprec, 2))  # 4974.6

Trade-off: per-vCPU fees grow with the size of each server, while per-instance fees (ECS Anywhere: about $7.48 a month for each node) don't. Per-cluster subscriptions favour a few large clusters. Write down which unit each line is priced in.

Things change, so date every line. On 30 June 2026 AWS removed the Systems Manager Advanced Instances tier. You can now register any number of hybrid nodes with no per-node fee, and since 30 September 2026 you pay per use for Session Manager and Run Command on those nodes. A cost model written in 2025 would show a per-node fee that no longer exists.

Pitfall with hardware terms: check what happens when the term ends. AWS says Outposts racks that are neither renewed nor returned roll on to monthly billing at the No Upfront rate. Put the end date in the profile.

Key takeaways

• Start from "use a region" and leave it only with a written reason: latency, residency, disconnected operation or existing hardware. Mark which reason is binding.
• Keep one YAML profile per site: site, why not a region, connectivity, workloads, hardware owner and maintainer, update policy, compliance and team skills.
• Record connectivity as measured numbers: p95 round-trip time, usable bandwidth and longest expected outage.
• Every cost model has five lines: hardware term, per-server or per-core fees, per-cluster fees, data transfer and staff time. Date each price.
• Prices and tiers change, as the Systems Manager change in 2026 shows. Check them again before each decision.