Skip to content
Beta

Architecture Patterns

Last updated on

This module helps you define where boundary-centric controls are required and where Zero Trust patterns should be the default.

  • Core principle: Protect workloads through segmentation, route control, and centralized inspection.
  • Typical implementation: Hub-and-spoke topology with central firewall and managed ingress and egress paths.
  • Primary strengths: Clear traffic governance and familiar operations for on-premises teams.
  • Typical limits: Risk of over-reliance on network boundaries for identity and workload protection.

The following diagram illustrates a typical implementation of the hub & spoke principle in STACKIT:

  • Each project (spoke) is connected to the central Shared Network Area (SNA) through peering.
  • The routing tables in the SNA enforce that all traffic between projects and to the internet always passes through the central firewall in the hub.
  • The hub provides central network functions: firewall (all communication is routed here), VPN gateway (on-premises connectivity), and internet breakout (internet access).
  • Shared services are available to all projects and are also connected through the SNA.
  • Communication to the internet or on-premises is only possible through the central components in the hub. This ensures clear separation, central control, and high security—no direct traffic between projects, everything is routed through the central infrastructure.

STACKIT Network Area hub-and-spoke architecture with Routing Tables, central firewall, VPN router, application landing zone spokes, on-premises, and internet connectivity

Pattern 2: Zero Trust-oriented architecture

Section titled “Pattern 2: Zero Trust-oriented architecture”
  • Core principle: Never trust by location; verify explicitly and continuously.
  • Typical implementation: Identity-based access, strong authentication, encryption, and policy enforcement close to workloads.
  • Primary strengths: Strong fit for distributed systems and internet-facing patterns.
  • Typical limits: Requires mature identity governance and disciplined policy operations.

Use the interactive map to open the dedicated domain pages.

Swipe sideways to see the whole diagram
Zero Trust architecture in security Five zero trust domains for data, devices, networks, workload, and people. Each card links to its deep dive page. Zero Trust architecture in securityFive focused domains that carry the security baseline across the migration.Zero trust dataZERO TRUSTDataClassification, encryption, keys, and retention controlsZero trust devicesZERO TRUSTDevicesDevice posture, endpoint hardening, and secure administrationZero trust networksZERO TRUSTNetworksSegmentation, traffic policy, and controlled connectivityZero trust workloadZERO TRUSTWorkloadRuntime hardening, least privilege, and workload isolationZero trust peopleZERO TRUSTPeopleIdentity lifecycle, privileged access, and account hygiene
  • Foundation layer: Keep mandatory network controls for segmentation and regulated paths.
  • Access layer: Use identity-first authorization for user and service access.
  • Data layer: Enforce encryption and key-governance controls independent of location.
  • Operations layer: Correlate network and identity telemetry for detection and evidence.
  • Topology as security proxy: Segmentation is treated as replacement for identity and workload controls.
  • Zero Trust in name only: Missing strong authentication, policy enforcement, or encryption standards.
  • Unmanaged transition patterns: Temporary hybrid patterns remain without convergence plan.