Architecture Neighborhoods

The neighborhoods, by risk band

A neighborhood is a zone within an environment — not a destination. Each data center, availability zone, colo, or cloud region is carved into a dozen or more of them, and every application is placed in the one that matches its profile. A dozen-plus neighborhoods usually cluster into five risk bands; the exact list varies by enterprise, the bands rarely do.

What defines a neighborhood

Five characteristics define a neighborhood. Most applications are pulled toward a zone by the strongest one or two.

1. Characteristic 1

   Risk & exposure

   internet-facing or not

   An application reachable from the public internet lives in a different trust world than one that isn't — and the two should never share a boundary.

2. Characteristic 2

   Security & trust

   a set of controls, not a location

   Segmentation, inspection, identity, least privilege. The zone enforces them so the app doesn't have to reinvent them.

3. Characteristic 3

   Data privacy & classification

   regulated data pulls hardest

   Cardholder data (PCI), customer PII, confidential, public. Regulated data pulls an application into a controlled neighborhood regardless of anything else about it.

4. Characteristic 4

   Business criticality

   crown jewels or dev/test

   Criticality sets how much isolation the neighborhood needs and how small its blast radius has to be.

5. Characteristic 5

   Regulatory & residency

   often decides first

   Data residency, sovereignty, audit boundaries. Often this closes the question before the other four are even weighed.

The Zoning Test

Ten checks before you zone an environment — or migrate one. Score one point per honest “yes.” Below seven, you're placing applications by convenience, and your blast radius is larger than you think.

1. Every application has a named neighborhood — not just a rack, a subnet, or a resource group.
2. Neighborhoods are defined by profile — risk, security, data class, criticality, regulatory — not by team or convenience.
3. Internet-facing, low-trust workloads never share a neighborhood with crown-jewel data.
4. Each neighborhood is a real boundary — shared segmentation, controls, and failure domain — not just a label.
5. Regulated data (PCI, PII) sits in a neighborhood whose controls actually meet the obligation, and can prove it.
6. The blast radius of each neighborhood is known and bounded — one compromise doesn't cross the boundary.
7. The same neighborhood map exists in every environment you run — owned DC, colo, and cloud.
8. A migration plan re-homes each app to its equivalent neighborhood, not “wherever it lands.”
9. Your most sensitive workload has a defined equivalent neighborhood in the target environment — if not, that gap is your migration risk.
10. Zoning standards run through architecture governance with conformance, so neighborhoods don't erode over time.

Going deeper

Sources worth your time, roughly in the order a team should read them.

• NIST SP 800-207 — Zero Trust ArchitectureThe reference for trust zones, segmentation, and least privilege — the security spine of a neighborhood.
• CISA — Zero Trust Maturity ModelSegmentation as a maturity pillar — a practical yardstick for how well your neighborhoods actually contain risk.
• Microsoft — Azure Landing ZonesHow a neighborhood is expressed in public cloud: subscriptions, management groups, and policy guardrails.
• AWS — Security Reference ArchitectureThe AWS counterpart: accounts, organizational units, and guardrails as segmentation — the same zoning, expressed in AWS.
• The TOGAF® StandardCarrying zoning standards through architecture governance, with conformance, so neighborhoods hold over time.
• Companion — You Don't Choose Five Nines (Part 4)Once an app is zoned, its reliability tier picks the deployment archetype. Zoning and posture, in sequence.