Segmentation

Good fences make good neighbors.

Before we can start building CI/CD pipelines or provisioning databases, we need to answer a fundamental question: how do we structure the underlying environments so that teams can work autonomously without interfering with each other?

This is where segmentation comes in.

Core Concepts

A segment is a physical or logical boundary around a set of workloads, resources, and users within a platform. It allows us to separate different parts of our infrastructure and apply distinct policies, security controls, and configurations to each.

Why Segment?

Segmentation solves a few critical problems in modern infrastructure:

1. Blast Radius Reduction: The “blast radius” is the scope of impact when something goes wrong. If you have a single, monolithic infrastructure, a compromised credential or a runaway process affects everything. Segmentation contains failures to specific, isolated boundaries.
2. Security and Compliance: Many regulatory frameworks, such as PCI-DSS or HIPAA, strictly require that systems processing sensitive data be entirely isolated from those that do not.
3. Cognitive Load: By narrowing the scope of an environment, you reduce the number of resources a developer has to think about. They only see the infrastructure relevant to their context.
4. Different Rules for Different Contexts: The policies that govern a production environment (strict access, heavy auditing) are counterproductive in a development environment where engineers need freedom to experiment.
5. Isolation by Design: If you share a unified infrastructure for all workloads, you must rely on complex configurations—nested IAM rules, Role-Based Access Control (RBAC), and intricate network policies—to prevent cross-contamination. Physical segmentation relies on hard boundaries, like separate cloud accounts. You don’t need a perfectly crafted policy to block traffic between two environments if they are physically separated without a route between them. The architecture inherently enforces the isolation.

However, segmentation is a balancing act. Too little, and you risk a catastrophic failure. Too much, and you introduce crippling operational complexity: suddenly your team is managing fifty separate Kubernetes clusters or a hundred nested cloud accounts.

To get it right, we must approach segmentation across four dimensions.

The Four Dimensions of Segmentation

While there are many ways to slice an infrastructure, and you can mix and match strategies to accommodate any business, I’ve found that effective platforms generally segment along four primary axes: Sector, Tier, Region, and Tenant. These four dimensions form the opinionated choice I will follow throughout the rest of this book. They represent the bare minimum I recommend for any serious platform — you can add more dimensions as your organization’s needs demand, but you rarely need fewer. You don’t need to implement all four on day one, but understanding them will help you design a platform that scales.

Sector (Domain / Line of Business)

The first and most critical level of segmentation separates the engineering platform domain from the business domain.

Your business applications—the code your company writes to make money—should not run alongside the tools you use to manage them. Your observability stack, CI/CD runners, and security scanners should live in a different sector than your e-commerce website. This separation draws inspiration from Domain-Driven Design [Evans, 2003], grouping resources that share a common business or technical context.

• Engineering Sector(s): Owned by internal enablement and platform teams. Common examples include a Platform sector (CI/CD, monitoring, identity management) and a Security sector (SIEM, log archiving, threat detection). These host the tooling that governs and supports the rest of the ecosystem.
• Business Sector(s): Owned by the product and development teams. These host the actual business workloads. A company with multiple lines of business—Retail, Finance, Insurance—might define a separate sector for each.

This separation is vital for two reasons. First, compliance: auditors will want to know exactly what processes have access to production databases. Keeping CI/CD runners physically separated from the business logic makes this boundary auditable. Second, resilience: if your business environment experiences an outage or a massive traffic spike, your observability and deployment tools must remain online so you can fix the problem.

Tier (Level of Criticality)

The second dimension separates workloads based on their criticality and the data they handle. I prefer to call these tiers rather than environments, because development teams often use terms like dev, qa, staging, and prod arbitrarily. Instead, think of tiers as strict boundaries governing access and data. The names and number of tiers are yours to define — you might use Sandbox and Live, or Sandbox, Training, and Live, or any other combination that reflects your organization’s risk and workflow boundaries. What matters is that each tier has a clearly defined access model and data policy. Throughout this book I use two tiers: Sandbox (non-production) and Live (production).

• Sandbox (Non-Production): The realm of innovation. Here, engineers use synthetic or heavily anonymized data. Product teams have the freedom to try new ideas, experiment, and break things without impacting the business. Security policies are more relaxed, fostering autonomy and speed.
• Live (Production): The realm of revenue. This tier processes real customer data. Access is strictly controlled, heavily audited, and monitored. Direct human access to resources here should be the exception (e.g., “break-glass” emergency access), with all changes flowing through automated pipelines.

By creating distinct Sandbox and Live tiers—often implemented as completely separate cloud accounts or subscriptions—you ensure that a developer writing a messy script in a Sandbox can never accidentally drop a Live database. Environment concepts like qa or dev become logical spaces inside the Sandbox tier, while staging and prod live inside the Live tier.

Region (Geography and Availability)

The third dimension organizes workloads by their physical location in the world.

Region segmentation involves deploying separate instances of your platform in different geographies. You deploy in the US and Europe to reduce latency for local users, or because data residency regulations (like GDPR) require European citizen data to never leave European servers.

Even within a single country, regional segmentation often involves dividing workloads across different Availability Zones or configuring specialized clusters for High Availability vs. Standard Availability.

You might also group regions into Region Groups (e.g., global, europe, americas). This allows you to place resources that don’t need to be strictly tied to a single datacenter but still operate within a defined geographical boundary, or to identify truly global resources like worldwide traffic routing configurations.

Tenant (Team or Customer)

The final dimension isolates workloads based on the owner.

In a large engineering organization, you segment by internal Team. The Payments team gets their own isolated space, separate from the Recommendations team. This limits the blast radius between different microservices, tightens security through least-privilege access, and enables accurate cost attribution. You know exactly what the Payments team’s infrastructure costs.

Alternatively, if your company builds B2B software, you might segment by Customer, providing dedicated infrastructure for high-value clients who require strict data isolation from other tenants.

The Platform Coordinate System

By combining these four dimensions, we create what I call the Platform Coordinate System. Every resource, workload, or data store in your platform is assigned a specific coordinate (Sector, Tier, Region, Tenant) that defines exactly where it lives and the policies that govern it.

But this coordinate system is far more than a naming convention. It is the generative formula that drives all infrastructure decisions. Different types of resources are instantiated at different coordinate granularities:

Consider the Payments team running in Europe on the live tier of our e-commerce sector. Its placement coordinate is (ecommerce, live, eu01, payments). Because the infrastructure is standardized, this placement can automatically map to a unified DNS scheme. Any engineer seeing the internal endpoint db.payments.eu01.live.internal.mountainlab.io immediately understands the exact context, security posture, and criticality of that database.

Coordinate Notation

To express patterns across the coordinate system, we use two special symbols:

• * (wildcard) means “all values” of a dimension. An Azure Policy applied at the subscription level governs (ecommerce, live, *, *) — all regions and all tenants within that subscription.
• _ (ignore) means the dimension is not relevant for the resource being described. An AWS Account for the payments tenant exists independently of region: (ecommerce, live, _, payments). Region-specific resources like VPCs are then created inside that account.

This notation becomes essential when mapping the coordinate system to cloud provider structures, because each provider’s primitives express different dimensions naturally. An Azure Subscription might represent (Sector, Tier), while an AWS Account might represent (Sector, Tier, _, Tenant). The coordinate system stays the same; the cloud mapping changes.

Segmentation and Landing Zones

If you’ve read about cloud architecture, you’ve almost certainly encountered the term landing zone. AWS, Azure, and GCP all use it to describe a pre-configured, secure, scalable cloud environment that serves as the foundation for all workloads [Services, 2023] [Cloud, 2023].

This is worth saying plainly: the Platform Coordinate System and a landing zone are not the same thing, but they are deeply related. Segmentation is the concept—the model you use to decide how your platform is divided. A landing zone is the implementation—the specific cloud account structure, policies, and guardrails that enforce your segmentation model using a cloud provider’s native primitives.

The same segmentation model can produce very different landing zone designs. One organization might create a single production subscription for all tenants at (ecommerce, live) and use resource groups for tenant isolation. Another might create one subscription per tenant, mapping directly to (ecommerce, live, _, payments). The coordinate system stays the same. The implementation varies based on blast radius tolerance, compliance requirements, and operational capacity.

Throughout this book, the coordinate system is our cloud-agnostic landing zone. When we talk about infrastructure, networking, CI/CD, and observability in later chapters, every design decision will reference coordinates.

The Isolation Spectrum

Not all boundaries are created equal. A separate cloud account provides much stronger isolation than a Kubernetes namespace, but it also costs more to operate. To make informed decisions about where to place each boundary, it helps to think of isolation as a spectrum from hardest to softest.

At the top of the spectrum, an air-gapped system in a disconnected data center offers absolute isolation—no network means no cross-contamination. This is the world of military and classified government workloads. At the bottom, a Kubernetes namespace with RBAC provides logical separation, but workloads share the same API server, scheduler, and node kernel. A noisy neighbor can still exhaust shared resources.

The design heuristic is straightforward: use the hardest boundary your budget allows for Sector and Tier, and softer boundaries for Region and Tenant. In practice, this means cloud accounts or subscriptions at Level 3 for your most critical segmentations, separate networks at Level 4 for regional isolation, and resource groups or namespaces at Levels 5–6 for tenant isolation within those hardened boundaries.

Silo, Pool, and Bridge

The AWS Well-Architected SaaS Lens [Services, 2023] introduces three isolation models that map well to the spectrum:

• Silo: Every tenant gets dedicated resources. A dedicated database instance per tenant. A dedicated cluster per team. Strong isolation, high cost.
• Pool: Tenants share resources with logical separation. A shared Kubernetes cluster with namespaces. A shared database with row-level security. Efficient, but noisy-neighbor risk.
• Bridge: Different resource types within the same coordinate use different isolation levels. Your database might be silo-isolated (dedicated instance per tenant) while your compute is pool-isolated (shared cluster, dedicated namespace).

Most real-world platforms are bridge models. The coordinate system enables this naturally—you choose the isolation level per resource type, per coordinate. The Payments team might warrant a dedicated database (silo) but share a compute cluster (pool) with other teams, all within the same (ecommerce, live, eu01, payments) coordinate.

Translating Segmentation to Cloud Structure

While the four dimensions are abstract concepts, they must eventually be mapped to structural primitives within your cloud provider. The goal is to use the native boundaries the cloud vendor provides to enforce isolation, rather than relying purely on complex software-defined rules.

Each cloud provider offers different structural primitives, and there is no single “right” mapping. The examples below show one common design per cloud, with alternatives discussed. Your organization must choose which coordinate granularity maps to which cloud primitive based on its blast radius tolerance, compliance requirements, and operational capacity.

Structural Mapping in Microsoft Azure

Azure provides a well-defined hierarchy of management scopes. One common approach maps Sector to Management Groups and Tier to Subscriptions:

graph TD
    Root["Tenant Root Group (Entra ID)"]
    Root --> PMG["Management Group: Platform\n(Sector)"]
    Root --> ECMG["Management Group: ECommerce\n(Sector)"]
    PMG --> PS["Subscription: Platform-Sandbox\n(Platform, Sandbox)"]
    PMG --> PL["Subscription: Platform-Live\n(Platform, Live)"]
    ECMG --> ECS["Subscription: ECommerce-Sandbox\n(ECommerce, Sandbox)"]
    ECMG --> ECL["Subscription: ECommerce-Live\n(ECommerce, Live)"]
    ECS --> RG1["RG: rg-payments-eu01-sandbox\n(ECommerce, Sandbox, EU01, Payments)"]
    ECL --> RG2["RG: rg-payments-eu01-live\n(ECommerce, Live, EU01, Payments)"]

Management Groups enforce Azure Policy and RBAC at the Sector level. You can nest sub-management-groups for finer policy inheritance if needed. Subscriptions provide billing, identity (separate service principals in Entra ID), and API limit isolation—here mapped to (Sector, Tier). Resource Groups provide RBAC delegation and resource grouping—here mapped to the full coordinate (Sector, Tier, Region, Tenant).

This approach gives Azure customers a clean, built-in hierarchy: Management Group → Subscription → Resource Group.

For organizations requiring stricter tenant isolation, an alternative is to create subscriptions per (Sector, Tier, _, Tenant)—for example, a dedicated Payments-Live subscription. This trades operational simplicity for harder boundaries between tenants.

Structural Mapping in Amazon Web Services

AWS relies primarily on isolated Accounts bound together by an Organization. Because AWS does not have an equivalent to Azure’s Resource Groups, the account boundary often absorbs the Tenant dimension:

graph TD
    Root["AWS Organization Root"]
    Root --> POU["OU: Platform\n(Sector)"]
    Root --> ECOU["OU: ECommerce\n(Sector)"]
    POU --> PSA["Account: Platform-Sandbox\n(Platform, Sandbox)"]
    POU --> PLA["Account: Platform-Live\n(Platform, Live)"]
    ECOU --> SBOU["Sub-OU: Sandbox\n(Tier grouping)"]
    ECOU --> LOU["Sub-OU: Live\n(Tier grouping)"]
    SBOU --> PaySb["Account: Payments-Sandbox\n(ECommerce, Sandbox, _, Payments)"]
    LOU --> PayLv["Account: Payments-Live\n(ECommerce, Live, _, Payments)"]
    PayLv --> VPC["VPC: payments-live-eu01\n(ECommerce, Live, EU01, Payments)"]

Organizational Units (OUs) enforce Service Control Policies (SCPs) and the newer Resource Control Policies (RCPs) at the Sector level. Sub-OUs can provide additional policy layering for Tier grouping. Accounts provide the hardest isolation boundary—IAM, billing, and API limits are all account-scoped. Here they’re mapped to (Sector, Tier, _, Tenant), with region-specific resources like VPCs created inside each account.

For smaller organizations, a simpler alternative is to use accounts per (Sector, Tier) only—ECommerce-Sandbox and ECommerce-Live—with tenant isolation handled via IAM boundaries within the account. This is simpler but offers weaker isolation between tenants.

Structural Mapping in Google Cloud Platform

GCP uses a resource hierarchy of Organization, Folders, and Projects. Projects are the primary isolation primitive, analogous to AWS Accounts:

graph TD
    Root["GCP Organization"]
    Root --> PF["Folder: Platform\n(Sector)"]
    Root --> ECF["Folder: ECommerce\n(Sector)"]
    PF --> PP["Project: platform-sandbox\n(Platform, Sandbox)"]
    PF --> PPL["Project: platform-live\n(Platform, Live)"]
    ECF --> SBF["Folder: Sandbox\n(Tier grouping)"]
    ECF --> LF["Folder: Live\n(Tier grouping)"]
    SBF --> PSP["Project: payments-sandbox\n(ECommerce, Sandbox, _, Payments)"]
    LF --> PLP["Project: payments-live\n(ECommerce, Live, _, Payments)"]

Folders (nestable up to 10 levels) provide Organization Policy inheritance and IAM grouping—used here for Sector and Tier grouping. Projects are the hard boundary: billing, IAM, and quotas are all project-scoped. GCP has no Resource Group equivalent; resources belong directly to projects. Region-specific resources are created within projects, mapping to the full coordinate (Sector, Tier, Region, Tenant).

GCP recommends keeping the folder hierarchy above projects as flat as possible, since every layer of nesting can define policy exceptions that add management overhead. It’s also worth noting that GCP explicitly advises against loading billing concerns onto the resource hierarchy [Cloud, 2023]. Use separate Billing Accounts linked to projects for cost attribution, and rely on labels for additional cost metadata.

Microsegmentation

The segmentation model we’ve built so far—Sector, Tier, Region, Tenant—handles the coarse boundaries. But what happens inside a segment?

Even within a single tenant’s namespace, services communicate with each other. Traditional segmentation focuses on north-south traffic: the traffic crossing the perimeter (user requests hitting a load balancer, API calls entering from the internet). But in modern architectures, the majority of traffic is east-west: service-to-service communication within a segment. A payment service calling a fraud detection service. A webhook receiver querying a database.

Microsegmentation controls this east-west traffic. It is not a fifth dimension of the coordinate system—it’s an enforcement mechanism within segments, operating at the finest granularity. Think of it as the last layer of defense:

Sector boundary       → cloud organization level
  └── Tier boundary     → account / subscription level
      └── Network boundary → VPC / VNet level
          └── Tenant boundary  → namespace / resource group level
              └── Microsegmentation → service-to-service policies

The platform team’s role is to provide microsegmentation as infrastructure—deploying a container network interface (CNI) that supports network policies, or a service mesh that enforces mutual authentication—and to set a baseline policy of default-deny. Application teams then explicitly open the communication paths their services need, defined as code and reviewed through pull requests.

This is particularly important in regulated environments. PCI-DSS v4.0 explicitly recognizes microsegmentation as a scoping mechanism for the Cardholder Data Environment. If you can prove that only specific services within a segment can reach your payment processor, the rest of your infrastructure falls outside the compliance scope.

We won’t go deeper into implementation here—networking, CNI choices, and service mesh patterns belong in Chapter 4 (Infrastructure) and Chapter 7 (Security and Compliance). But the concept matters for segmentation design: your segments define the walls, and microsegmentation controls the doors within those walls.

Patterns and Anti-Patterns

When designing your platform’s boundaries, keep these common traps and best practices in mind.

Anti-Pattern: The Mega-Cluster

Putting all teams, all tiers, and all applications into a single cloud account or a single massive Kubernetes cluster separated only by namespaces. While it saves money early on, a single misconfigured IAM policy or a noisy neighbor will bring down the entire company. Mountain Lab’s opening story is a textbook example.

Anti-Pattern: Premature Granularity

The opposite of the mega-cluster. A startup with twenty engineers decides to give every developer their own dedicated cloud account and Kubernetes cluster. The infrastructure overhead instantly grinds the engineering team to a halt, as they spend all their time updating cluster versions and managing cross-account networking instead of building product.

Anti-Pattern: Billing-Driven Hierarchy

Structuring your cloud organization to match cost centers rather than security and isolation needs. This creates weak boundaries where you need strong ones (between environments handling different data classifications) and strong boundaries where you don’t (between cost centers that share the same security posture). Cost attribution should be handled through tags and labels as a metadata overlay, not through structural hierarchy.

Pattern: Account-per-(Sector, Tier) Matrix

A proven approach for organizations of all sizes is mapping Sectors and Tiers directly to the cloud provider’s hardest boundary primitive [Services, 2023]. A standard core setup involves one dedicated account or subscription for each (Sector, Tier) combination:

• Platform-Sandbox
• Platform-Live
• ECommerce-Sandbox
• ECommerce-Live

By adopting this matrix, you harness the cloud provider’s strongest security and cost-attribution boundaries for your most critical segmentations. You can then safely use softer boundaries—like namespaces, resource groups, and network policies—for Region and Tenant segmentation operating inside those hardened accounts.

Pattern: Network-per-(Sector, Tier, Region)

Create separate virtual networks for each (Sector, Tier, Region) combination. No default routing between them. Cross-network connectivity is explicit and controlled through peering or transit gateways. This enforces network-level isolation aligned with geographic and data residency requirements. We’ll cover the networking implementation in detail in Chapter 4.

Pattern: Bridge Isolation Model

Different resource types within the same coordinate use different isolation levels. The Payments team’s database is silo-isolated (dedicated instance) while their compute is pool-isolated (shared cluster, dedicated namespace). This is how most real-world platforms work. The coordinate system enables it—you choose the isolation level per resource type, not a single level for all resources at a given coordinate.

Pattern: Dedicated Security Sector

Isolate security tooling—log archives, audit systems, SIEM—into a dedicated sector, separate from both platform and business workloads. If business infrastructure is compromised, your security observability must remain intact to investigate and respond. All three major cloud providers recommend this in their landing zone guidance.

Decision Frameworks

How do you choose your level of segmentation? Consider your organization’s maturity, industry, and resources.

• Startups (Pre-Product Market Fit): Keep it simple. Two tiers: Sandbox and Live, each in its own cloud account or subscription. One sector is fine. Don’t over-engineer. You’re at the bottom of the isolation spectrum (Levels 5–6 for most resources), and that’s appropriate. Focus on finding market fit.
• Scale-ups (Growth Phase): Introduce the Platform sector to pull shared tools out of the product boundaries. Add the Tenant dimension logically—namespaces and resource groups—to track costs and manage access as headcount grows. Start moving critical resources up the isolation spectrum to Levels 3–4.
• Enterprise / Heavily Regulated: Implement all four dimensions with hard physical boundaries. Account-per-(Sector, Tier) at minimum, possibly account-per-(Sector, Tier, _, Tenant) for sensitive workloads. Microsegmentation within segments. Strict network isolation and policy enforcement to satisfy auditors and compliance frameworks. You’re operating at Levels 2–4 across the board.

Cross-Cutting Concerns

The four dimensions define the structural boundaries of your platform. But several concerns cut across those boundaries as policy overlays—they influence how you configure segments, but they aren’t dimensions that create new infrastructure.

Data Classification

Not all data is equal. A common model classifies data into four tiers: Public, Internal, Confidential, and Restricted. This overlays the Tier dimension—your Live tier handles Confidential and Restricted data, but not every Live workload touches PCI cardholder data or medical records. Only a subset of coordinates needs the strictest isolation. Data classification helps you decide which coordinates warrant moving up the isolation spectrum.

Identity Alignment

Your identity and access management should align with the coordinate system. Separate identity providers or tenants for Sandbox and Live tiers. Separate service principals per Sector. Short-lived tokens instead of long-lived credentials. As zero trust architecture gains traction [nist2020sp800207?], identity is increasingly the primary enforcement boundary—not the network.

Cost Attribution

Cost attribution is a metadata overlay, not a structural dimension. The coordinate system naturally enables it: every resource at (ECommerce, Live, EU01, Payments) is attributable to the Payments team. Use tags and labels to enrich this further, but resist the urge to restructure your cloud hierarchy around billing. The hierarchy should serve security and isolation first; cost tracking follows through metadata.

CI/CD Pipeline Isolation

Build and deploy pipelines should respect segmentation boundaries. Sandbox build runners cannot access Live secrets. Pipeline credentials should be scoped per (Sector, Tier) at minimum. We’ll cover this in depth in Chapter 5, but the principle is simple: your CI/CD system is only as secure as its weakest credential scope.

Summary

• Segmentation protects the business: By limiting the blast radius, failures stay localized and don’t cascade across the system.
• Four dimensions define the model: Sector separates platform from product. Tier separates sandbox from live. Region separates geographies. Tenant separates teams or customers.
• The coordinate system is generative: (Sector, Tier, Region, Tenant) doesn’t just label resources—it drives which infrastructure gets created, at what granularity, and with what policies.
• Isolation is a spectrum: From air-gapped hardware to shared namespaces, match the isolation level to the actual risk and your operational capacity.
• Most platforms are bridge models: Different resource types at different isolation levels within the same coordinate. A silo database alongside a pool compute cluster.
• Start simple, evolve as needed: Apply dimensions progressively as your organization’s complexity and regulatory needs scale.