---
title: Network Architecture
description: Design secure and scalable connectivity patterns across platform, shared services, and migrated workloads.
sidebar:
label: Network Architecture
order: 13
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/landing-zones/network-architecture/"
source_file: "docs/migration/design-and-mobilize/landing-zones/network-architecture.mdx"
---
## Purpose
Network architecture defines how workloads communicate securely, how traffic is segmented, and how central connectivity services are governed across shared and project-specific landing zones.
In most enterprise migrations, this topic is less about individual subnets and more about operating a controlled connectivity model over time: who connects which project, via which paths, and under which guardrails.
## Reference topology
## Connectivity design and delivery
### Core connectivity building blocks
- **STACKIT Network Area**: Use a shared enterprise network scope as the central backbone for project connectivity planning and governance. Documentation
- **Routing Tables**: Define and enforce how projects inside a Network Area are connected and whether the architecture should follow a hub-and-spoke model with central firewall controls or a flatter topology. Documentation
- **DNS**: Standardize naming and service discovery early so connectivity design, certificate handling, and workload cutovers are consistent. Documentation
- **VPN (Connectivity)**: Treat VPN as a central connectivity capability for hybrid and multi-cloud integration patterns, not as an isolated point solution. Documentation
Confirm the product connectivity boundaries before choosing a topology. Network Area scope,
route precedence, and VPN gateway behavior constrain the design; they do not replace the
workload connectivity matrix or security approval.
> From the STACKIT docs: [Concepts](https://docs.stackit.cloud/products/network/core-networking/network-area/basics/concepts/) (Source updated 11.12.2025, copied 06.10.2026)
The STACKIT Network Area (SNA) allows projects within an organization to be connected to each other on a network level. This makes it possible to connect various resources of the projects within an SNA and also simplifies the connection with on-prem environments (hybrid cloud).
An SNA project differs from a public project in the fact that it is connected to an internal transfer network. When creating a network in a SNA project, the address range is defined using the specified prefix length from the network ranges of the SNA. To make the connectivity within the SNA projects available, the project router gets connected to the SNA transfer network. When editing the networks of SNA projects, the routing table of all project routers is automatically adjusted, no manual adjustment is necessary. Access control at network level is carried out exclusively by security groups, all incoming traffic is denied by default.
SNA is a global resource which you need to enable for the regions you want to use it in. Currently traffic between regions is only possible via the public internet. Private connectivity between regions inside of an SNA is planned for the future.
Example topology of an SNA with 2 projects:
> From the STACKIT docs: [Routing tables › Route types and priorities](https://docs.stackit.cloud/products/network/core-networking/network-area/basics/routing-tables/#route-types-and-priorities) (Source updated 14.04.2026, copied 06.10.2026)
Routing tables consist of different types of routes serving different purposes and having a different priority in the overall routing context. Route types with a higher priority value are preferred over lower priority ones if they have the same prefix length. If routes of the same route type have the same prefix length, equal-cost-multi-path (ECMP) is performed.
| priority | route type | description |
| --- | --- | --- |
| 4 | system routes | System routes are automatically generated routes for connectivity between projects inside an SNA. System routes are enabled by default for routing tables but can be disabled to manage traffic and isolation within a network environment. |
| 3 | service routes | Service routes are routes which are added by a STACKIT service to reach it. Service routes are always enabled and can’t be disabled/removed by the user directly. |
| 2 | static routes | Static routes are routes which are added by a user. They can have different next-hops such as an IP-address, black hole or the internet. |
| 1 | dynamic routes | Dynamic routes are routes which are learned through a dynamic routing protocol like BGP. Dynamic routes are enabled by default for routing tables but can be disabled. |
> From the STACKIT docs: [Product overview](https://docs.stackit.cloud/products/network/connectivity-hybrid-multi-cloud/vpn/basics/product-overview/) (Source updated 30.04.2026, copied 06.10.2026)
A Virtual Private Network (VPN) with STACKIT creates a secure, encrypted connection over the internet between your remote network and your [STACKIT Network Area (SNA)](https://docs.stackit.cloud/products/network/core-networking/network-area/). This secure tunnel allows data to be transmitted safely, protecting it from eavesdropping, interception, or unauthorized access.
With STACKIT VPN, you can securely connect to your [STACKIT Network Area](https://docs.stackit.cloud/products/network/core-networking/network-area/), enabling access to its resources as if you were directly connected to the remote network. This capability is particularly useful for accessing services, applications, and data within the SNA from remote locations, ensuring both privacy and security in all communications.
A STACKIT VPN typically consists of two key components; the **VPN gateway** and the **VPN connection**:
- **VPN gateway:**
The VPN gateway in STACKIT serves as the access point to the SNA from the internet. It is the gateway through which encrypted traffic flows between your SNA and your remote data center or private network. In an high available active-active setup the VPN gateway internally consists of two instances. The VPN gateway hosts the VPN connections.
- **VPN connection:**
The VPN connection is the encrypted tunnels being established between the STACKIT VPN gateway and your remote gateway. It utilizes advanced encryption protocols and techniques to ensure that all data transmitted between your local data center and the STACKIT SNA remains confidential and intact, effectively preventing unauthorized access or data breaches. In an high available active-active setup each of the two VPN gateway instances establish a tunnel to the same remote site.
STACKIT VPN is an essential tool for securely connecting distributed resources, enabling remote access to cloud-based services while maintaining the integrity and privacy of your data within the STACKIT cloud environment.
### Key design decisions
- **Network Area ownership model**: Decide who centrally governs shared connectivity and onboarding criteria for projects attaching to the Network Area.
- **Routing strategy per domain**: Decide where hub-and-spoke with central inspection is mandatory and where simpler flat routing is acceptable.
- **Hybrid connectivity baseline**: Define how VPN-based connectivity is integrated into platform standards and lifecycle operations.
- **Name-resolution design**: Standardize DNS boundaries and patterns for platform services, shared services, and application landing zones.
### Typical outputs
- **Target topology and trust boundaries**: A documented target state for segmentation and cross-project communication.
- **Network Area onboarding principles**: Clear criteria for which projects are attached, how they are reviewed, and how changes are approved.
- **Routing governance model**: Defined use of Routing Tables including hub-and-spoke versus flat routing decision criteria.
- **Connectivity baseline**: Reusable standards for VPN, DNS, and shared network services.
### Asset container references
### Anti-patterns to avoid
- **Unplanned Network Area growth**: Connecting projects without central architecture review and ownership.
- **Routing Tables used ad hoc**: Inconsistent route logic per project with no reference architecture.
- **DNS treated as afterthought**: Late-stage DNS decisions that break migration timelines or service discovery.
- **VPN as exception path**: Managing VPN as one-off workaround instead of governed connectivity foundation.