Platform Landing Zone
Company-wide foundation for governance, identity, security, networking, cost controls, and automation.
Open Platform Landing ZoneSTACKIT Service Portfolio Map
STACKIT
Landing Zone Journey
Last updated on
STACKIT
Landing Zone Journey
Guided landing zone presentation covering definition, timing, architecture layers, workload scope, accelerator implementation, and STACKIT managed delivery.
Explore the STACKIT Service Portfolio
General
Architecture portfolio reference services architecture
STACKIT
The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.
Use this interactive map to explore the STACKIT service portfolio. Select a product or access tool to open its current documentation or related Cloud Framework asset.
Interactive Service Portfolio
Section titled “Interactive Service Portfolio”Usage Notes
Section titled “Usage Notes”The map is a navigation aid rather than a lifecycle commitment. Check each linked product page for current regions, availability, service levels, and release status.
Browse all STACKIT product documentation Open the documentationPlace the Landing Zone in the Migration Framework
A landing zone is the shared runway for governed migration. Establish its platform stream during Design and Mobilize, so migration waves inherit a working baseline for controlled delivery and stable operations.
Define the Platform Landing Zone
Introduce a landing zone as the structured cloud foundation for governed operations on STACKIT. Use this opening to align stakeholders on the key questions: which guardrails are mandatory, who owns them, and what application needs must be supported.
Understanding Landing Zones
Section titled “Understanding Landing Zones”A landing zone is the structured cloud foundation that defines how your organization operates on STACKIT from day 1. It combines governance, identity, security, network design, cost controls, and automation into one coherent baseline.
Without this foundation, migration waves typically stall due to missing approvals, inconsistent controls, and repeated platform decisions.
Core components
Section titled “Core components”The following visual summarizes the core components that should be addressed for a reliable platform baseline.
Why you need a landing zone
Section titled “Why you need a landing zone”- Control and risk reduction: Enforce security and compliance controls consistently across teams.
- Scalable delivery baseline: Enable repeatable provisioning patterns for multiple migration waves.
- Clear responsibilities: Define ownership boundaries for platform, security, and application teams.
- Faster migration throughput: Avoid redesigning core controls for each application move.
When to start
Section titled “When to start”Start the landing-zone stream as early as possible, in parallel with discovery.
- Too late: Productive migrations are blocked because mandatory controls are not yet available.
- Too early without discovery feedback: Application constraints are missed and later cause rework.
The practical model is a dual track: establish the platform baseline early, then refine application landing zone templates as discovery insights mature.
Two layers: Platform and Application Landing Zones
Section titled “Two layers: Platform and Application Landing Zones”Application Landing Zone
Workload-specific implementation patterns derived from the platform baseline and discovery findings.
Open Application Landing ZoneTypical enterprise inputs
Section titled “Typical enterprise inputs”To design a landing zone effectively, enterprises usually provide:
- Organization and ownership model: Entities, project boundaries, and accountability model.
- Compliance and policy requirements: Regulatory obligations and internal control policies.
- Security requirements: IAM standards, network segmentation, encryption, and logging expectations.
- Operations and support constraints: Incident handling, escalation paths, and handover model.
- Application portfolio insights: Discovery findings about workload archetypes and dependencies.
Delivery model
Section titled “Delivery model”- Define enterprise guardrails and target control model.
- Build and validate the platform landing zone baseline as code.
- Derive application landing zone templates from discovery and migration design.
- Pilot with selected workloads, then scale through migration factory runbooks.
STACKIT acceleration assets
Section titled “STACKIT acceleration assets”To accelerate delivery, STACKIT provides concrete best practices and reusable templates:
Asset title
Framework
Asset type
Migration
Blueprint
Migration
Blueprint
Migration
Guide
Migration
Blueprint
Migration
Guide
Migration
Guide
Migration
Guide
Migration
Service
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Guide
Advisory
Service
Structure Account Governance
Establish the organizational structure, project boundaries, and ownership model that make landing-zone governance repeatable across teams and environments.
Purpose
Section titled “Purpose”Account governance defines how you separate environments, teams, and responsibilities in a way that remains auditable and scalable.
It creates the organizational control plane for migration waves: where workloads are hosted, who owns which scope, and how new projects are added without bypassing guardrails.
Governance hierarchy
Section titled “Governance hierarchy”
Governance design and delivery
Section titled “Governance design and delivery”Core governance building blocks
Section titled “Core governance building blocks”- Regions: Region strategy determines data locality, latency profile, and resilience boundaries for workloads and shared services. Define region usage principles early and align them with compliance and continuity requirements. Documentation
- Customer Account: The customer account is the top governance boundary for ownership, billing, and administration. It is the anchor for organization-wide standards and control responsibilities. Documentation
- STACKIT Folder: Folders structure organizational domains (for example platform, shared services, business units, environments) and allow policy inheritance and clean delegation models. Resource Manager
- STACKIT Projects: Projects are the delivery scopes where resources are deployed and operated. They should be attached to folders through a defined onboarding model, not created ad hoc. Resource Manager
How these elements work together
Section titled “How these elements work together”- Region principles first: Define which regions are allowed for which workload classes.
- Customer account as governance root: Set global ownership, policy intent, and financial accountability.
- Folders for structure and delegation: Translate the operating model into scalable organizational boundaries.
- Projects for delivery: Provision project scopes through a standard lifecycle with mandatory controls inherited from the folder model.
Key design decisions
Section titled “Key design decisions”- Region governance model: Decide single-region, dual-region, or workload-based region strategy and required exceptions.
- Customer-account responsibilities: Define which central teams own governance, billing oversight, and control operations.
- Folder topology: Decide how folders map to domains such as platform, environments, and business units.
- Project onboarding model: Standardize project creation, naming, tagging, and lifecycle controls.
- Policy and exceptions: Define mandatory guardrails and transparent exception workflows.
Typical outputs
Section titled “Typical outputs”- Governance blueprint: Customer-account, folder, and project topology with ownership matrix.
- Region usage policy: Approved region patterns per workload type and risk profile.
- Project onboarding standard: Repeatable process for creating and connecting governed projects.
- Control baseline: Enforced naming, tagging, and policy controls with documented exception flow.
Related Target Operating Model guidance
Section titled “Related Target Operating Model guidance”Governance and Decision Making assigns decision rights and escalation paths for these account, folder, and project boundaries.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- No region policy: Region selection per team or project without enterprise rules.
- Unstructured project sprawl: Projects created without folder strategy, ownership clarity, or lifecycle standards.
- Governance only on paper: Controls documented but not embedded in project onboarding and operations.
Purpose
Section titled “Purpose”IAM ensures that every action on the platform is attributable, authorized, and aligned with enterprise security requirements.
For migration landing zones, IAM is the control backbone that connects human identities, machine identities, and authorization rules into one governable operating model.
Core IAM building blocks
Section titled “Core IAM building blocks”- Access and Identity (central domain): Use the platform domain as the central reference for IAM capabilities and operating responsibilities. Documentation
- STACKIT IDP: Use STACKIT IDP as the identity control point for authentication and account access flows. Documentation
- Federation (SAML 2.0): Integrate enterprise identities through federation to enforce central identity lifecycle and reduce local account sprawl. Documentation
- Roles and Permissions: Define role-based authorization boundaries for platform teams, application teams, and operations. Documentation
- Custom Roles: Implement least-privilege patterns when default roles are too broad for enterprise controls. Documentation
- Service Accounts: Separate machine identities from user identities for automation, CI/CD, and operational integrations. Documentation
How these elements work together
Section titled “How these elements work together”- Identity source and trust: STACKIT IDP plus federation establish who is authenticated and under which enterprise identity policies.
- Authorization model: Roles and Permissions define who can do what in each governance scope.
- Least-privilege refinement: Custom Roles close permission gaps where standard roles do not match enterprise separation-of-duties requirements.
- Automation identity model: Service Accounts provide non-human identities for repeatable operations without exposing personal credentials.
Key design decisions
Section titled “Key design decisions”- Identity integration approach: Decide how enterprise identity is federated and how lifecycle events are synchronized.
- Role architecture per scope: Design role boundaries for platform, security, operations, and application teams.
- Custom role strategy: Define when custom roles are required and how they are reviewed and approved.
- Privileged access controls: Define approval workflows, temporary elevation, and emergency access handling.
- Service-account governance: Standardize creation, ownership, credential rotation, and traceability for machine identities.
Typical outputs
Section titled “Typical outputs”- IAM architecture baseline: Federated authentication model with documented trust boundaries.
- Role and permission matrix: Standard and custom role mapping per organizational scope.
- Service identity standard: Guardrails for Service Accounts in automation and platform operations.
- Operational IAM run model: Procedures for privileged access, approvals, and emergency access.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- No federation strategy: Local identity silos and inconsistent lifecycle handling.
- Over-privileged default roles: Broad permissions used without custom least-privilege controls.
- Shared privileged users: Administrative actions cannot be attributed to a single accountable identity.
- Automation with human identities: Pipelines and integrations run under personal accounts instead of Service Accounts.
Security and Compliance topics
Map security and compliance topics early so control requirements, evidence, sovereignty decisions, and zero-trust principles inform the landing-zone design.
Purpose
Section titled “Purpose”Security and Compliance define the guardrails for migration decisions across design, landing zones, and migration delivery.
The goal is to translate policy intent into enforceable controls and verifiable evidence from day 1.
Security and compliance topic map
Section titled “Security and compliance topic map”Use this semantic map as a structured entry point into all subtopics of this module.
Why this stream must start early
Section titled “Why this stream must start early”Security and Compliance are not a final hardening step. They shape core platform decisions from the beginning:
- Architecture first: Trust boundaries, network models, and identity controls are expensive to retrofit later.
- Delivery continuity: Missing mandatory controls block approvals and delay migration waves.
- Evidence by design: Compliance evidence must be generated continuously, not reconstructed late.
- Shared accountability: Every design stream needs Security and Compliance review to avoid local optimization and enterprise risk.
How this module supports design and landing zones
Section titled “How this module supports design and landing zones”- Design perspective: Define architecture patterns, control principles, and governance model.
- Landing-zone perspective: Apply these principles to platform and application landing-zone implementation.
This module provides the cross-cutting baseline that must be used in both contexts.
On-premises to cloud security shift
Section titled “On-premises to cloud security shift”Cloud migration changes security assumptions:
- From static boundaries to dynamic scopes: Projects and services change faster than classic zones.
- From manual approvals to policy enforcement: Controls must be testable and automated.
- From isolated logs to correlated telemetry: Audit, platform, and application signals must work together.
- From infrastructure focus to shared capabilities: Identity, keys, observability, and governance are platform-level capabilities.
Architecture approaches to combine
Section titled “Architecture approaches to combine”- Boundary-centric architecture: Hub-and-spoke routing, centralized firewall controls, and segmentation.
- Zero Trust-oriented architecture: Explicit identity, strong authentication, end-to-end encryption, and least-privilege enforcement.
Most enterprise target states need both approaches with clear selection criteria per workload class.
Digital sovereignty and compliance context
Section titled “Digital sovereignty and compliance context”For many migration programs, compliance, and digital sovereignty are primary drivers.
- Legal and residency requirements: Region and data-location decisions influence architecture and controls.
- Operational sovereignty goals: Governance, portability, and transparency reduce dependency risks.
- EU Cloud Sovereignty Framework (CSF): Use CSF-oriented control and evidence mapping to structure requirements and maturity.
- European Sovereign Stack Standard (ES3): Use ES3 as a practical maturity extension to make sovereignty posture measurable.
Compliance in migration: what stays, what changes
Section titled “Compliance in migration: what stays, what changes”During on-premises to cloud migration, enterprise compliance obligations remain unchanged in intent.
What changes is how controls are implemented, how evidence is produced, and how operating responsibilities are distributed.
- What stays the same: Regulatory obligations, internal policies, audit readiness, and accountable ownership.
- What changes: Controls become more automated, evidence becomes continuous, and ownership boundaries shift across platform and product teams.
Typical compliance categories to structure migration decisions:
- Data protection and data location: Requirements for data classes, residency, and access boundaries.
- Identity and access governance: Requirements for role models, separation of duties, and privileged access.
- Logging and evidence: Requirements for completeness, retention, and evidence quality.
- Operational resilience and recovery: Requirements for availability, recovery targets, and incident readiness.
- Supplier and contract governance: Requirements for provider controls, contractual obligations, and verifiable assurances.
How STACKIT concretely supports compliance outcomes
Section titled “How STACKIT concretely supports compliance outcomes”- Assured security baseline: Certified data-center operations and established security standards provide a reliable baseline for regulated workloads.
- C5 as auditable evidence: The C5 attestation provides structured evidence across key control domains such as risk, operations, access, encryption, and incident handling.
- Audit transparency: Test reports and documented controls support internal audit, external assurance, and enterprise risk assessment.
- Implementation guidance: Architecture, role model, and control-mapping guidance helps teams implement compliance requirements in cloud-native ways.
- Shared-responsibility clarity: STACKIT provides platform controls and evidence; the customer remains accountable for configuration, access governance, and data classification.
Module structure
Section titled “Module structure”Operating Model and Governance
Define roles, decision rights, ownership, and mandatory Security and Compliance checkpoints.
Open moduleArchitecture Patterns
Define where boundary-centric controls remain mandatory and where Zero Trust controls are primary.
Open moduleSecurity by Design Baseline
Define baseline requirements and recommendations for identity, network, workload, and data protection.
Open moduleControls and Evidence Pipeline
Define preventive and detective controls and automated compliance evidence generation.
Open moduleOn-Premises to Cloud Shift
Clarify which security assumptions and operating practices must change in cloud migration.
Open moduleDigital Sovereignty and CSF Alignment
Translate sovereignty, CSF, and ES3 requirements into architecture, controls, and evidence responsibilities.
Open modulePurpose
Section titled “Purpose”In landing zones, Security, and Compliance are implementation constraints that must follow the cross-cutting design baseline from the dedicated module.
Use this page to apply module outcomes to platform and application landing-zone decisions.
Use the dedicated module as source of truth
Section titled “Use the dedicated module as source of truth”- Module overview: /migration/design-and-mobilize/security-and-compliance/overview/
- Operating Model and Governance: /migration/design-and-mobilize/security-and-compliance/operating-model-and-governance/
- Architecture Patterns: /migration/design-and-mobilize/security-and-compliance/architecture-patterns/
- Security by Design Baseline: /migration/design-and-mobilize/security-and-compliance/security-by-design-baseline/
- Controls and Evidence Pipeline: /migration/design-and-mobilize/security-and-compliance/controls-and-evidence-pipeline/
- On-Premises to Cloud Shift: /migration/design-and-mobilize/security-and-compliance/onpremises-to-cloud-shift/
- Digital Sovereignty and CSF Alignment: /migration/design-and-mobilize/security-and-compliance/digital-sovereignty-and-csf-alignment/
Landing-zone implementation focus
Section titled “Landing-zone implementation focus”- Audit Logging: Use central audit logging as the authoritative record for security-relevant platform actions and administrative changes. Documentation
- Telemetry Router: Route and normalize telemetry streams so logs and metrics from distributed workloads can be collected consistently. Documentation
- Logs: Establish centralized log collection patterns for operational and security analysis. Documentation
- Observability: Design observability as a layered model: application log streams per application plus central audit logging and platform telemetry for governance and incident analysis. Documentation
- Network Security: Apply network hardening principles for segmentation, controlled traffic paths, and reduced exposure surface. Documentation
- Compute Security: Define workload hardening baselines and secure runtime practices for compute resources. Documentation
- Secrets Manager: Store and govern sensitive credentials and application secrets through managed controls instead of ad hoc handling. Documentation
- KMS: Manage key lifecycles and encryption governance through a centralized key management approach. Documentation
- ACL patterns for PaaS services: Use service-level access control lists to constrain connectivity paths for managed services. PostgreSQL is one example, but this pattern applies across STACKIT PaaS services. PostgreSQL reference: Documentation .
- Unified Firewall: Use centralized firewall controls for consistent network policy enforcement across zones and workloads. Documentation
How this applies to landing zones
Section titled “How this applies to landing zones”- Evidence and detection layer: Audit Logging, Logs, Telemetry Router, and Observability provide the data foundation for compliance evidence and incident analysis.
- Preventive hardening layer: Network Security, Compute Security, Unified Firewall, and service ACLs reduce exposure and enforce approved traffic and runtime boundaries.
- Data protection layer: Secrets Manager and KMS protect sensitive data paths and cryptographic assets throughout workload life cycles.
- Operational model: Application teams provide workload telemetry while central teams run shared governance visibility across projects.
Translate the compute-hardening recommendations into an owned, testable VM baseline before onboarding workloads.
From the STACKIT docsSecurity in Compute Engine › System hardening
The security of your virtual machines (VMs) is paramount to ensuring the integrity of your infrastructure. The following are recommended measures to harden the security of your VMs:
- Installation: Install only the packages required for your use case. Reduce the number of running services and use a minimal installation image if possible.
- User management: Disable root login and use
sudofor administrative tasks instead. Implement strong password policies and remove or disable unused users and groups. For secure authentication, we recommend using SSH keys. - File permissions and ownership: Verify permissions for system files and directories using tools such as
chmodandchown. The sticky bit should be set for global directories, such as/tmp, and ensure that there are no non-root files in directories such as/bin,/usr/bin, and/sbin. - Firewall and ports: Use a firewall, for example with
iptablesorfirewalld, and allow only necessary ports. Deny all access by default and whitelist only the necessary services. You can also use STACKIT Security Groups to allow only necessary ports. - Service management: Disable and stop services that are not needed. Run services only with the minimum required rights.
- SSH hardening: Change the default SSH port and disable root login via SSH by setting “PermitRootLogin no” in the
sshd\_config. Use SSH keys instead of passwords and disable empty passwords by settingPermitEmptyPasswords no.
You can find additional recommendations and guidelines at the following links:
- Choosing Policy, OpenSCAP Portal
- BSI - SiSyPHuS Win10: Empfehlung zur Härtung von Windows 10 mit Bordmitteln
- BSI - SYS.1.3 Server unter Linux und Unix
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
Validate service-local access rules separately from network routing. The following ACL behavior is specific to PostgreSQL Flex; confirm the corresponding rules for every other managed service rather than assuming identical defaults.
From the STACKIT docsCreate and manage instances › ACL
With the ACL entries, you control which source IPs are allowed to connect to your instance. Note, that this is an additional security layer and does not replace the need for proper authentication and security best practices. There are two predefined entries: 193.148.160.0/19 and 45.129.40.0/21. They ensure that you can access your instance from STACKIT cloud services. If you want to access your instance from the public net, you need to add the client’s IPv4 address or subnet. The entries follow the CIDR notation. If you want to allow a single IP address (e.g. single host), then set 32as the subnet parameter. E.g. to allow a host with the source IPv4 address of 93.229.84.137, add 93.229.84.137/32 as ACL entry. At the moment, you can’t add IPv6 addresses.
Do not set 0.0.0.0/0 as an ACL IP, because then your instance can be accessed from every IP.
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
Key design decisions
Section titled “Key design decisions”- Logging architecture boundaries: Define logging scope at application level, platform level, and audit level, and where each stream is retained.
- Telemetry and observability model: Define routing, enrichment, and ownership for logs, metrics, and traces.
- Hardening baseline scope: Define mandatory controls for network and compute domains, including firewall and service ACL patterns.
- Secrets and key governance: Standardize Secrets Manager and KMS usage, ownership, and life cycle responsibilities.
- Compliance operating model: Define who owns evidence collection, control verification, and reporting cadence.
Typical outputs
Section titled “Typical outputs”- Security baseline catalog: Controls for network, compute, identity, and data protection.
- Logging and evidence architecture: Central audit logging plus workload observability with clear ownership boundaries.
- Secrets and encryption standard: Defined usage model for Secrets Manager, KMS, and key and secret life cycle handling.
- Response and escalation model: Operational runbooks for detection, assessment, and incident reporting.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- Security deferred to late migration phases: Controls are added after workload onboarding instead of by design.
- Disconnected telemetry stacks: Audit, platform, and application signals cannot be correlated in incidents.
- Secrets in code or unmanaged stores: Sensitive values are not governed through dedicated secret management.
- Flat network access without service controls: Missing firewall and ACL boundaries allow excessive lateral movement.
Design Network Architecture
Define segmentation, connectivity, DNS, routing, and secure communication patterns for shared services and workload environments.
Purpose
Section titled “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
Section titled “Reference topology”
Connectivity design and delivery
Section titled “Connectivity design and delivery”Core connectivity building blocks
Section titled “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 docsConcepts
The source shows pictures here that this page leaves out (1). See them in Concepts
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:
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
From the STACKIT docsRouting tables › Route types and priorities
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. |
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
From the STACKIT docsProduct overview
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). 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, 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.
What is this?
This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.
Key design decisions
Section titled “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
Section titled “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
Section titled “Asset container references”Asset title
Framework
Asset type
Migration
Software
Architecture
Service
Anti-patterns to avoid
Section titled “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.
Purpose
Section titled “Purpose”Cost management makes cloud spend visible, attributable, and controllable across migration waves and steady-state operations.
For migration landing zones, this requires a shared financial control model across platform teams, application teams, and business stakeholders.
Core cost governance building blocks
Section titled “Core cost governance building blocks”- Costs and Billing (central domain): Use the cost and billing domain as the central baseline for spend transparency, governance responsibilities, and reporting logic. Documentation
- Billing Accounts: Define Billing Accounts as structural boundaries for ownership, invoicing context, and financial accountability. Documentation
- FOCUS: Use the FOCUS model to standardize and normalize cost data for transparent analysis and cross-team financial reporting. Documentation
- Resource Labeling: Enforce consistent labels to map technical usage to accountable teams, products, environments, and cost centers. Documentation
How these elements work together
Section titled “How these elements work together”- Financial structure layer: Billing Accounts define where costs are accumulated and who is accountable for them.
- Data standardization layer: FOCUS provides a consistent cost-data model across services and teams.
- Allocation and ownership layer: Resource labels connect cloud usage to business and engineering ownership.
- Operating layer (FinOps): FinOps establishes a recurring cycle of visibility, optimization actions, and accountability tracking.
FinOps in the landing zone context
Section titled “FinOps in the landing zone context”FinOps should be embedded from the beginning of landing zone design, not added after migration waves start.
- Visibility: Build shared transparency for platform, shared services, and workload spend.
- Accountability: Assign clear cost ownership per Billing Account, team, and service domain.
- Optimization: Maintain an active optimization backlog with regular review cadence.
- Governance: Tie budget thresholds and escalation paths to named owners and decision forums.
Key design decisions
Section titled “Key design decisions”- Allocation model boundaries: Define how spend is allocated across Billing Accounts, products, teams, and environments.
- Data model standardization: Decide how FOCUS and internal reporting dimensions are implemented consistently.
- Label strategy: Define mandatory labels and quality controls for reliable allocation and chargeback/showback.
- Budget and escalation model: Establish thresholds, ownership, and response workflows.
- FinOps cadence: Define review frequency, optimization governance, and tracking of realized savings.
Typical outputs
Section titled “Typical outputs”- Cost taxonomy and ownership model: Standardized mapping across Billing Accounts, labels, and responsible teams.
- Cost reporting baseline: FOCUS-aligned financial views for trend analysis and stakeholder reporting.
- Budget guardrails: Defined thresholds with documented escalation and decision ownership.
- FinOps operating model: Regular review rhythm with prioritized optimization backlog and outcome tracking.
Related Target Operating Model guidance
Section titled “Related Target Operating Model guidance”Governance and Decision Making and Measurement and Continuous Improvement assign FinOps decision rights and turn financial signals into improvement actions.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- No Billing Account strategy: Spend is visible only at aggregate level without clear accountability.
- Inconsistent or missing labels: Usage cannot be attributed to products, teams, or environments.
- No data standardization: Cost views differ by team and cannot be compared reliably.
- FinOps only as reporting: No recurring optimization process and no ownership for improvement actions.
Purpose
Section titled “Purpose”Automation ensures that landing-zone capabilities are reproducible, versioned, and tested instead of manually configured.
For migration landing zones, automation is the delivery backbone that connects platform APIs, IaC tools, developer workflows, and release controls into one reliable operating model.
Core automation building blocks
Section titled “Core automation building blocks”- STACKIT API: Use the API as the foundational control surface for platform automation and integration patterns. Documentation
- Terraform Provider: Use the official provider for declarative infrastructure provisioning and lifecycle control. Documentation
- OpenTofu Provider: Use OpenTofu with the STACKIT provider as an open IaC option with comparable declarative workflows. Documentation
- Pulumi: Use Pulumi when teams prefer general-purpose languages for infrastructure automation. Documentation
- Ansible: Use Ansible primarily for post-provisioning configuration and operational tasks. In a combined model, Terraform/OpenTofu provision infrastructure while Ansible applies OS and middleware configuration.
- STACKIT CLI: Standardize CLI-based operations for scripting, troubleshooting, and repeatable operational run tasks. Documentation
- SDKs (Go, Python, Java): Use SDKs for custom automation and service integrations where IaC abstractions are not sufficient. Go SDK , Python SDK , Java SDK .
- STACKIT Git: Use Git as the source of truth for IaC modules, policies, and delivery workflows. Documentation
- CI/CD Pipeline: Use pipelines for validation, policy checks, controlled promotion, and auditable releases. Documentation
- Container Registry: Use a central registry for versioned build artifacts and deployment consistency across environments. Documentation
How these elements work together
Section titled “How these elements work together”- Control layer: STACKIT API, CLI, and SDKs provide direct and programmable control interfaces.
- Provisioning layer: Terraform/OpenTofu and Pulumi define and reconcile desired infrastructure state.
- Configuration layer: Ansible applies host and middleware configuration after infrastructure provisioning.
- Delivery layer: Git and CI/CD pipelines enforce quality gates, policy checks, and controlled rollout across environments.
- Artifact layer: Container Registry delivers immutable and versioned artifacts for predictable deployments.
Terraform/OpenTofu and Ansible delivery flow
Section titled “Terraform/OpenTofu and Ansible delivery flow”Terraform or OpenTofu and Ansible solve different parts of one delivery workflow. Keep the boundary explicit so infrastructure changes remain reviewable and host configuration remains repeatable.
Terraform / OpenTofu
Own the infrastructure lifecycle: projects, networks, security controls, compute, storage, managed services, and the outputs required by configuration management.
Ansible
Own configuration inside the reachable target: operating-system packages, middleware, application artifacts, service units, and workload-level validation.
- Version infrastructure inputs, configuration, and application artifact references in Git.
- Validate and review the Terraform/OpenTofu plan, including replacement and security effects.
- Apply the approved plan and expose only the target inventory and outputs required by Ansible.
- Run Ansible idempotently to configure the operating system, middleware, workload, and telemetry.
- Validate infrastructure state, service health, and operational controls, then retain the evidence.
- Promote the same versioned workflow through environments instead of repeating manual setup.
Do not use provisioners or ad hoc scripts to blur ownership between both layers. Triggering Ansible from Terraform can be a practical bridge, but each tool must remain independently understandable, testable, and rerunnable.
Recommended operating model
Section titled “Recommended operating model”- Recommendation 1: Use Git plus CI/CD as default control path and avoid direct manual changes in productive scopes.
- Recommendation 2: Choose one primary IaC engine per platform domain (Terraform or OpenTofu) to reduce fragmentation.
- Recommendation 3: Use Ansible for configuration management, not as a replacement for declarative infrastructure provisioning.
- Recommendation 4: Use SDKs for domain-specific automation where provider resources do not cover required behavior.
- Recommendation 5: Version and promote container artifacts through clear environment stages with rollback-ready tags.
Key design decisions
Section titled “Key design decisions”- Automation interface strategy: Define where API, CLI, SDK, and IaC tools are used as primary interfaces.
- IaC engine strategy: Decide Terraform versus OpenTofu versus Pulumi based on skills, governance, and ecosystem fit.
- Module and repository strategy: Define reusable module boundaries, versioning, and ownership.
- Pipeline control model: Implement validation, policy checks, approvals, and promotion gates.
- Artifact and release strategy: Define registry usage, image versioning, and rollback standards.
Typical outputs
Section titled “Typical outputs”- Reusable automation baseline: IaC modules, templates, and configuration playbooks with ownership model.
- Delivery blueprint: CI/CD flow with quality gates, policy checks, and staged promotions.
- Integration toolkit: Standardized use of CLI and SDK automation for operational and product-specific workflows.
- Release baseline: Versioned artifact lifecycle in Container Registry with rollback-ready practices.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”- Too many automation paradigms: Parallel tool stacks with no clear ownership or governance model.
- Provisioning and configuration mixed ad hoc: No clean boundary between IaC provisioning and Ansible configuration.
- No artifact discipline: Mutable container tags and unclear release traceability.
- CLI scripts without Git and pipeline controls: Operational automation cannot be audited or reproduced reliably.
Understanding Platform Landing Zones
Section titled “Understanding Platform Landing Zones”A platform landing zone is the company-wide target operating baseline for cloud adoption on STACKIT. It defines the cross-cutting controls and platform guardrails that every product team must inherit.
Without this baseline, migration teams usually face inconsistent controls, duplicated design decisions, and delayed approvals.
Core capability areas
Section titled “Core capability areas”Account governance
Structure organizations, projects, and environments with clear ownership boundaries.
Identity and access
Define IAM model, role patterns, least-privilege principles, and separation of duties.
Security and compliance
Implement mandatory controls, logging, evidence pathways, and policy enforcement.
Network architecture
Define segmentation, connectivity patterns, and secure communication standards.
Cost management
Establish tagging, budget controls, chargeback/showback, and cost transparency.
Automation
Provision and evolve the baseline through OpenTofu/Terraform-based Infrastructure as Code.
Typical inputs and prerequisites
Section titled “Typical inputs and prerequisites”- Organizational model: Business units, ownership boundaries, and environment strategy.
- Regulatory constraints: Industry requirements, audit scope, and evidence obligations.
- Security standards: Identity model, encryption standards, secrets handling, and incident response.
- Connectivity requirements: On-prem, partner, internet, and service integration needs.
- Operating model constraints: Roles, escalation paths, and handover boundaries.
Delivery sequence
Section titled “Delivery sequence”- Define governance and control objectives with enterprise stakeholders.
- Design platform baseline patterns for identity, networking, security, and cost control.
- Implement baseline automation and policy guardrails as reusable modules.
- Validate controls with pilot workloads and close architecture/compliance gaps.
- Operationalize with ownership model, runbook standards, and change process.
Design principles
Section titled “Design principles”- Standardize first, then allow exceptions: Keep exceptions explicit, approved, and time-bound.
- Automate controls: Treat policy and baseline setup as code to reduce manual drift.
- Shift evidence left: Build compliance evidence generation into day-1 platform design.
- Design for scale: Assume multiple teams and application archetypes from the start.
Understanding Platform Landing Zones
Section titled “Understanding Platform Landing Zones”A platform landing zone is the company-wide target operating baseline for cloud adoption on STACKIT. It defines the cross-cutting controls and platform guardrails that every product team must inherit.
Without this baseline, migration teams usually face inconsistent controls, duplicated design decisions, and delayed approvals.
Core capability areas
Section titled “Core capability areas”Account governance
Structure organizations, projects, and environments with clear ownership boundaries.
Identity and access
Define IAM model, role patterns, least-privilege principles, and separation of duties.
Security and compliance
Implement mandatory controls, logging, evidence pathways, and policy enforcement.
Network architecture
Define segmentation, connectivity patterns, and secure communication standards.
Cost management
Establish tagging, budget controls, chargeback/showback, and cost transparency.
Automation
Provision and evolve the baseline through OpenTofu/Terraform-based Infrastructure as Code.
Typical inputs and prerequisites
Section titled “Typical inputs and prerequisites”- Organizational model: Business units, ownership boundaries, and environment strategy.
- Regulatory constraints: Industry requirements, audit scope, and evidence obligations.
- Security standards: Identity model, encryption standards, secrets handling, and incident response.
- Connectivity requirements: On-prem, partner, internet, and service integration needs.
- Operating model constraints: Roles, escalation paths, and handover boundaries.
Delivery sequence
Section titled “Delivery sequence”- Define governance and control objectives with enterprise stakeholders.
- Design platform baseline patterns for identity, networking, security, and cost control.
- Implement baseline automation and policy guardrails as reusable modules.
- Validate controls with pilot workloads and close architecture/compliance gaps.
- Operationalize with ownership model, runbook standards, and change process.
Design principles
Section titled “Design principles”- Standardize first, then allow exceptions: Keep exceptions explicit, approved, and time-bound.
- Automate controls: Treat policy and baseline setup as code to reduce manual drift.
- Shift evidence left: Build compliance evidence generation into day-1 platform design.
- Design for scale: Assume multiple teams and application archetypes from the start.
Understanding Platform Landing Zones
Section titled “Understanding Platform Landing Zones”A platform landing zone is the company-wide target operating baseline for cloud adoption on STACKIT. It defines the cross-cutting controls and platform guardrails that every product team must inherit.
Without this baseline, migration teams usually face inconsistent controls, duplicated design decisions, and delayed approvals.
Core capability areas
Section titled “Core capability areas”Account governance
Structure organizations, projects, and environments with clear ownership boundaries.
Identity and access
Define IAM model, role patterns, least-privilege principles, and separation of duties.
Security and compliance
Implement mandatory controls, logging, evidence pathways, and policy enforcement.
Network architecture
Define segmentation, connectivity patterns, and secure communication standards.
Cost management
Establish tagging, budget controls, chargeback/showback, and cost transparency.
Automation
Provision and evolve the baseline through OpenTofu/Terraform-based Infrastructure as Code.
Typical inputs and prerequisites
Section titled “Typical inputs and prerequisites”- Organizational model: Business units, ownership boundaries, and environment strategy.
- Regulatory constraints: Industry requirements, audit scope, and evidence obligations.
- Security standards: Identity model, encryption standards, secrets handling, and incident response.
- Connectivity requirements: On-prem, partner, internet, and service integration needs.
- Operating model constraints: Roles, escalation paths, and handover boundaries.
Delivery sequence
Section titled “Delivery sequence”- Define governance and control objectives with enterprise stakeholders.
- Design platform baseline patterns for identity, networking, security, and cost control.
- Implement baseline automation and policy guardrails as reusable modules.
- Validate controls with pilot workloads and close architecture/compliance gaps.
- Operationalize with ownership model, runbook standards, and change process.
Design principles
Section titled “Design principles”- Standardize first, then allow exceptions: Keep exceptions explicit, approved, and time-bound.
- Automate controls: Treat policy and baseline setup as code to reduce manual drift.
- Shift evidence left: Build compliance evidence generation into day-1 platform design.
- Design for scale: Assume multiple teams and application archetypes from the start.
Understanding Platform Landing Zones
Section titled “Understanding Platform Landing Zones”A platform landing zone is the company-wide target operating baseline for cloud adoption on STACKIT. It defines the cross-cutting controls and platform guardrails that every product team must inherit.
Without this baseline, migration teams usually face inconsistent controls, duplicated design decisions, and delayed approvals.
Core capability areas
Section titled “Core capability areas”Account governance
Structure organizations, projects, and environments with clear ownership boundaries.
Identity and access
Define IAM model, role patterns, least-privilege principles, and separation of duties.
Security and compliance
Implement mandatory controls, logging, evidence pathways, and policy enforcement.
Network architecture
Define segmentation, connectivity patterns, and secure communication standards.
Cost management
Establish tagging, budget controls, chargeback/showback, and cost transparency.
Automation
Provision and evolve the baseline through OpenTofu/Terraform-based Infrastructure as Code.
Typical inputs and prerequisites
Section titled “Typical inputs and prerequisites”- Organizational model: Business units, ownership boundaries, and environment strategy.
- Regulatory constraints: Industry requirements, audit scope, and evidence obligations.
- Security standards: Identity model, encryption standards, secrets handling, and incident response.
- Connectivity requirements: On-prem, partner, internet, and service integration needs.
- Operating model constraints: Roles, escalation paths, and handover boundaries.
Delivery sequence
Section titled “Delivery sequence”- Define governance and control objectives with enterprise stakeholders.
- Design platform baseline patterns for identity, networking, security, and cost control.
- Implement baseline automation and policy guardrails as reusable modules.
- Validate controls with pilot workloads and close architecture/compliance gaps.
- Operationalize with ownership model, runbook standards, and change process.
Design principles
Section titled “Design principles”- Standardize first, then allow exceptions: Keep exceptions explicit, approved, and time-bound.
- Automate controls: Treat policy and baseline setup as code to reduce manual drift.
- Shift evidence left: Build compliance evidence generation into day-1 platform design.
- Design for scale: Assume multiple teams and application archetypes from the start.
Connect R-Strategy to Landing Zone Design
Use the selected R-strategy and target architecture for each application to derive the landing-zone capabilities, controls, connectivity, and service patterns its migration requires.
What this module delivers
Section titled “What this module delivers”The Design module creates the executable migration design for each application identified in Discovery. It is not a generic architecture exercise. The target is a concrete design package that a migration factory can run with predictable quality.
Target design per application
Defines workload architecture, service choices, integration approach, and constraints in the STACKIT context.
R-strategy-backed decision record
Documents the selected migration strategy and why alternatives were rejected.
Factory-ready migration runbook
Provides a step-by-step procedure for run teams, including rollback and validation checkpoints.
Handover package
Delivers all required inputs to Migration Factory Setup, Landing Zone, and Migration Plan.
Module boundaries and dependencies
Section titled “Module boundaries and dependencies”These modules are connected, but they have different responsibilities:
Design (this module)
Decides target design and migration strategy per application and creates executable runbooks.
Migration Factory Setup
Enables delivery by selecting and preparing the right factory model, partner setup, and tooling stack.
Landing Zone
Provides the platform foundation and governance controls that target designs must comply with.
Migration Plan
Converts completed designs into realistic waves, sequencing, dependencies, and delivery milestones.
R-strategy as core design method
Section titled “R-strategy as core design method”The R-strategy model is the core decision framework in this module. For each application, the selected R-strategy must be justified with architecture, business, risk, and operability evidence.
Decision Criteria by R-Strategy
Section titled “Decision Criteria by R-Strategy”- Relocate: Choose when moving virtualization stacks is faster than redesign and governance constraints still allow conversion to cloud-native operations.
- Rehost: Choose for low change tolerance and strict timelines, where speed is prioritized over immediate modernization.
- Replatform: Choose when moderate changes unlock major benefits through STACKIT managed platform capabilities.
- Repurchase: Choose only for services available in the STACKIT ecosystem, including SaaS options such as ServiceNow, SAP, and partner offerings when they better fit business needs.
- Refactor: Choose for strategic applications where cloud-native redesign creates clear value in resilience, agility, or cost profile.
- Retain: Choose retain when timing or dependencies block migration now.
- Retire: Choose retire when business value no longer justifies operational effort.
Cross-path steps in the diagram
Section titled “Cross-path steps in the diagram”The diagram is not only an orientation aid. It is the shared decision and handover spine across Design, Landing Zones, Migration Factory Setup, and Migration Plan.
1. Discovery input
Section titled “1. Discovery input”Consolidate inventory, dependency map, risk profile, and non-functional constraints before strategy branching starts.
2. Evaluate and prioritize
Section titled “2. Evaluate and prioritize”Prioritize workload candidates by criticality, effort, and wave feasibility to focus design capacity where delivery risk is highest.
3. Determine migration path
Section titled “3. Determine migration path”Select the right R-strategy per workload and route into the dedicated strategy page with explicit rationale and alternatives considered.
4. Validation
Section titled “4. Validation”Run a shared quality gate across architecture, security/compliance, runbook quality, and operating readiness before approving wave execution.
5. Transition
Section titled “5. Transition”Prepare controlled handover into migration execution with release readiness, communication model, and clearly assigned ownership for wave run and escalation paths.
6. Production
Section titled “6. Production”Finalize production handover criteria and Day-1 operating baseline so migrated workloads enter run operations with clear accountability and evidence.
How to build the target design per application
Section titled “How to build the target design per application”- Confirm the application scope and baseline from Discovery (dependencies, usage, criticality, constraints).
- Define business and technical design goals, including availability, security, compliance, and performance targets.
- Evaluate the R-strategy options against objective criteria and record the selected strategy with rationale.
- Map the target to STACKIT products and platform capabilities, including networking, identity, data, and operations patterns.
- Specify migration approach details (cutover model, data movement, integration transition, rollback strategy).
- Create the migration run book for the factory with explicit tasks, quality checks, and acceptance criteria.
- Validate design assumptions with architecture, security, platform, and business owners.
- Hand over the approved design package to Migration Factory Setup and Migration Plan.
Design package required for factory run
Section titled “Design package required for factory run”At minimum, each application package should include:
- Target architecture definition: Workload placement, service mapping, integration model, and non-functional requirements.
- R-strategy decision record: Selected strategy, decision criteria, alternatives considered, and key risks.
- Migration run book: Sequenced run steps, checks before run, rollback path, validation steps, and go-live criteria.
- Dependency and interface impact: Required coordination with upstream/downstream systems and transition windows.
- Compliance and security controls: Mandatory controls and evidence requirements for release readiness.
Cloud design patterns for typical STACKIT applications
Section titled “Cloud design patterns for typical STACKIT applications”Use a dedicated pattern page to define a concrete target architecture before selecting the migration runbook.
Workload use-case lens for migration variants
Section titled “Workload use-case lens for migration variants”In addition to R-strategy, use the workload lens to classify what is migrated and to select feasible implementation variants with explicit boundary conditions.
AI-assisted design assets
Section titled “AI-assisted design assets”AI-assisted design assets support architects in turning application requirements, source-service context, and R-strategy options into reviewable target-design proposals. Use their outputs as input for architecture, security, platform, and business validation before approving a migration path.
Asset title
Framework
Asset type
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Guide
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Adoption
Service
Advisory
Service
Migration
Software
Migration
Service
Migration
Guide
Runbook assets
Section titled “Runbook assets”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
How design drives the migration plan
Section titled “How design drives the migration plan”Migration planning quality depends on design quality. Wave sequencing, factory throughput, and delivery risk are directly influenced by how precise the target designs and run books are. In practice, incomplete designs lead to unstable waves and avoidable delivery delays.
Application Landing Zones
Understanding Application Landing Zones
Section titled “Understanding Application Landing Zones”An application landing zone is a workload-specific implementation blueprint derived from the platform landing zone baseline.
It translates enterprise guardrails into practical patterns for concrete application types, for example VM-centric Rehost, containerized workloads, or data platform workloads.
Why it depends on Discovery
Section titled “Why it depends on Discovery”Application landing zones are not designed in isolation. They require validated discovery input for dependencies, data sensitivity, runtime behavior, and operational constraints.
Typical discovery-driven design inputs:
- Dependency profile: Inbound/outbound communication paths and trust boundaries.
- Runtime profile: Resource behavior, availability expectations, and scaling characteristics.
- Data and compliance profile: Classification, retention, and control obligations.
- Migration strategy fit: Rehost, Replatform, or refactor constraints for each workload.
Typical application landing zone patterns
Section titled “Typical application landing zone patterns”Rehost-ready pattern
Minimal change target for VM-based workloads with inherited central controls.
Container platform pattern
Segmented, policy-driven setup for Kubernetes-based workload groups.
Data workload pattern
Landing zone profile for data services, integration paths, and stricter controls.
Shared service pattern
Isolated setup for foundational services used by multiple product teams.
Delivery approach
Section titled “Delivery approach”- Classify workload archetypes from discovery findings and target strategy.
- Map platform baseline controls to each archetype and identify controlled deviations.
- Build reusable IaC templates and policy sets for each application landing zone profile.
- Validate with pilot workloads and production-like cutover scenarios.
- Publish templates, runbooks, and onboarding guidance for migration waves.
Best practices
Section titled “Best practices”- Prefer templates over one-off designs: Reusable patterns accelerate migration waves.
- Document deviations explicitly: Keep risk, owner, and expiry date transparent.
- Align with migration factory: Integrate landing zone patterns into wave runbooks.
- Continuously improve: Feed migration and run feedback into the template backlog.
Understanding Application Landing Zones
Section titled “Understanding Application Landing Zones”An application landing zone is a workload-specific implementation blueprint derived from the platform landing zone baseline.
It translates enterprise guardrails into practical patterns for concrete application types, for example VM-centric Rehost, containerized workloads, or data platform workloads.
Why it depends on Discovery
Section titled “Why it depends on Discovery”Application landing zones are not designed in isolation. They require validated discovery input for dependencies, data sensitivity, runtime behavior, and operational constraints.
Typical discovery-driven design inputs:
- Dependency profile: Inbound/outbound communication paths and trust boundaries.
- Runtime profile: Resource behavior, availability expectations, and scaling characteristics.
- Data and compliance profile: Classification, retention, and control obligations.
- Migration strategy fit: Rehost, Replatform, or refactor constraints for each workload.
Typical application landing zone patterns
Section titled “Typical application landing zone patterns”Rehost-ready pattern
Minimal change target for VM-based workloads with inherited central controls.
Container platform pattern
Segmented, policy-driven setup for Kubernetes-based workload groups.
Data workload pattern
Landing zone profile for data services, integration paths, and stricter controls.
Shared service pattern
Isolated setup for foundational services used by multiple product teams.
Delivery approach
Section titled “Delivery approach”- Classify workload archetypes from discovery findings and target strategy.
- Map platform baseline controls to each archetype and identify controlled deviations.
- Build reusable IaC templates and policy sets for each application landing zone profile.
- Validate with pilot workloads and production-like cutover scenarios.
- Publish templates, runbooks, and onboarding guidance for migration waves.
Best practices
Section titled “Best practices”- Prefer templates over one-off designs: Reusable patterns accelerate migration waves.
- Document deviations explicitly: Keep risk, owner, and expiry date transparent.
- Align with migration factory: Integrate landing zone patterns into wave runbooks.
- Continuously improve: Feed migration and run feedback into the template backlog.
Understanding Application Landing Zones
Section titled “Understanding Application Landing Zones”An application landing zone is a workload-specific implementation blueprint derived from the platform landing zone baseline.
It translates enterprise guardrails into practical patterns for concrete application types, for example VM-centric Rehost, containerized workloads, or data platform workloads.
Why it depends on Discovery
Section titled “Why it depends on Discovery”Application landing zones are not designed in isolation. They require validated discovery input for dependencies, data sensitivity, runtime behavior, and operational constraints.
Typical discovery-driven design inputs:
- Dependency profile: Inbound/outbound communication paths and trust boundaries.
- Runtime profile: Resource behavior, availability expectations, and scaling characteristics.
- Data and compliance profile: Classification, retention, and control obligations.
- Migration strategy fit: Rehost, Replatform, or refactor constraints for each workload.
Typical application landing zone patterns
Section titled “Typical application landing zone patterns”Rehost-ready pattern
Minimal change target for VM-based workloads with inherited central controls.
Container platform pattern
Segmented, policy-driven setup for Kubernetes-based workload groups.
Data workload pattern
Landing zone profile for data services, integration paths, and stricter controls.
Shared service pattern
Isolated setup for foundational services used by multiple product teams.
Delivery approach
Section titled “Delivery approach”- Classify workload archetypes from discovery findings and target strategy.
- Map platform baseline controls to each archetype and identify controlled deviations.
- Build reusable IaC templates and policy sets for each application landing zone profile.
- Validate with pilot workloads and production-like cutover scenarios.
- Publish templates, runbooks, and onboarding guidance for migration waves.
Best practices
Section titled “Best practices”- Prefer templates over one-off designs: Reusable patterns accelerate migration waves.
- Document deviations explicitly: Keep risk, owner, and expiry date transparent.
- Align with migration factory: Integrate landing zone patterns into wave runbooks.
- Continuously improve: Feed migration and run feedback into the template backlog.
Understanding Discovery
Section titled “Understanding Discovery”Discovery is one of the first and most critical modules in the Design and Mobilize phase. It refines Rapid Discovery results and adds the depth needed to make architecture and migration-wave decisions with confidence.
The primary objective is to establish a realistic, evidence-based understanding of the current IT landscape, business priorities, and organizational readiness before detailed target design and migration planning are finalized.
Core Objectives
Section titled “Core Objectives”Complete baseline
Create a reliable application and infrastructure baseline that goes beyond pure quantities.
Dependency transparency
Identify technical and process dependencies to avoid hidden migration blockers.
Business alignment
Link technical findings with business criticality, timelines, and risk tolerance.
Planning readiness
Produce decision-ready input for target design and migration-wave planning.
What Discovery Typically Captures
Section titled “What Discovery Typically Captures”Inventory
Comprehensive capture of servers, virtual machines, databases, middleware, and applications.
Dependency analysis
Mapping of communication paths and runtime dependencies between systems and applications.
Resource utilization
Analysis of actual CPU, memory, storage, and I/O behavior over a representative period.
Operational context
Collection of backup, patching, SLA, compliance, and operational constraints.
Application owner input
Structured questionnaires and interviews to validate assumptions and close data gaps.
Typical Delivery Setup
Section titled “Typical Delivery Setup”In practice, Discovery is often run together with STACKIT partners. Partners typically use their own tooling landscape to collect and normalize technical data into a central repository. Many programs also trigger targeted questionnaires for application owners directly from these tools to enrich technical findings with business and operational context.
This combined model improves speed and consistency while keeping stakeholder validation built into the process.
Two Evidence Streams: Technical vs. Human-Driven
Section titled “Two Evidence Streams: Technical vs. Human-Driven”Discovery intentionally combines two evidence streams that complement each other:
- Technically derived evidence: Tooling-generated findings from inventory exports, runtime metrics, and dependency signals. This stream provides scale, consistency, and repeatability.
- Application-owner enrichment (human-driven): Validated business criticality, lifecycle intent, release constraints, and operational realities from owner interviews and questionnaires.
Neither stream is sufficient on its own. Technical evidence without owner context can misclassify critical workloads, while human input without technical grounding can hide coupling and capacity risks. Discovery quality depends on reconciling both streams into one decision-ready view.
Discovery Process at a Glance
Section titled “Discovery Process at a Glance”The following diagram shows how Discovery transforms technical and stakeholder input into decision-ready outputs for the downstream modules.
Typical Analysis Patterns in Discovery Tooling
Section titled “Typical Analysis Patterns in Discovery Tooling”During Discovery, tooling commonly applies the following analysis patterns:
- Record normalization: Merge heterogeneous exports into one coherent application model.
- Dependency mapping: Detect communication paths, data exchange, and coupling patterns.
- Criticality and risk scoring: Evaluate business impact, failure domain, and compliance exposure.
- Utilization profiling: Build workload demand baselines for right-sizing and target planning.
- Segmentation analysis: Cluster applications by readiness, constraints, and migration strategy fit.
- Wave simulation: Model move groups and sequence options under dependency constraints.
- Gap and assumption tracking: Keep unresolved findings transparent with confidence levels.
These analyses establish the technical fact base. The human-driven stream then validates, prioritizes, and contextualizes these findings for executable migration decisions.
AI-assisted discovery assets
Section titled “AI-assisted discovery assets”Use AI-assisted discovery assets to structure workload inputs, service mapping, readiness findings, and R-strategy signals before architects validate the resulting discovery baseline.
Asset title
Framework
Asset type
Migration
Software
Adoption
Service
Method in Practice
Section titled “Method in Practice”- Aggregate source data from CMDBs, hypervisors, cloud inventories, monitoring, and export files.
- Normalize and consolidate records into a common application-centric model.
- Discover and validate dependencies (network, data, identity, integration, and batch flows).
- Enrich with owner input on criticality, lifecycle, constraints, and migration feasibility.
- Classify workloads for migration strategy options and wave sequencing.
- Validate findings with architecture, security, platform, and business stakeholders.
Why Discovery Is Critical
Section titled “Why Discovery Is Critical”- Reduces migration risk: Early visibility of hidden dependencies lowers outage and rollback risk.
- Improves wave planning: Workloads can be grouped realistically by coupling, criticality, and readiness.
- Prevents over/under-sizing: Measured utilization replaces assumptions in target capacity planning.
- Supports governance: Security, compliance, and operational constraints are addressed before rollout.
- Strengthens stakeholder buy-in: Shared facts improve decision quality across business and IT.
Relevance for Follow-On Modules
Section titled “Relevance for Follow-On Modules”Discovery outputs are directly reused by the next modules in Design and Mobilize:
Design
Uses dependency, capacity, and risk insights to shape target architecture options.
Security and Compliance
Uses data classification and control gaps to define prioritized security requirements.
Landing Zone
Uses platform and governance constraints to define foundational setup decisions.
Migration Plan
Uses move groups, criticality, and sequencing constraints for realistic wave planning.
Operating Model and Business Case
Uses ownership, process impact, and value/risk signals for staffing and investment priorities.
Discovery Outputs
Section titled “Discovery Outputs”At minimum, Discovery should produce the following outputs:
- Consolidated application baseline: Mapped inventory by domain, environment, and criticality.
- Dependency map: Verified upstream/downstream relationships and integration touchpoints.
- Utilization profile: Evidence-based resource behavior and sizing assumptions.
- Constraint register: Security, compliance, licensing, and operational constraints.
- Migration readiness view: Prioritized candidates, risks, and sequencing recommendations.
These outputs are essential prerequisites for continuing with detailed design work and a credible migration plan.
Understanding Application Landing Zones
Section titled “Understanding Application Landing Zones”An application landing zone is a workload-specific implementation blueprint derived from the platform landing zone baseline.
It translates enterprise guardrails into practical patterns for concrete application types, for example VM-centric Rehost, containerized workloads, or data platform workloads.
Why it depends on Discovery
Section titled “Why it depends on Discovery”Application landing zones are not designed in isolation. They require validated discovery input for dependencies, data sensitivity, runtime behavior, and operational constraints.
Typical discovery-driven design inputs:
- Dependency profile: Inbound/outbound communication paths and trust boundaries.
- Runtime profile: Resource behavior, availability expectations, and scaling characteristics.
- Data and compliance profile: Classification, retention, and control obligations.
- Migration strategy fit: Rehost, Replatform, or refactor constraints for each workload.
Typical application landing zone patterns
Section titled “Typical application landing zone patterns”Rehost-ready pattern
Minimal change target for VM-based workloads with inherited central controls.
Container platform pattern
Segmented, policy-driven setup for Kubernetes-based workload groups.
Data workload pattern
Landing zone profile for data services, integration paths, and stricter controls.
Shared service pattern
Isolated setup for foundational services used by multiple product teams.
Delivery approach
Section titled “Delivery approach”- Classify workload archetypes from discovery findings and target strategy.
- Map platform baseline controls to each archetype and identify controlled deviations.
- Build reusable IaC templates and policy sets for each application landing zone profile.
- Validate with pilot workloads and production-like cutover scenarios.
- Publish templates, runbooks, and onboarding guidance for migration waves.
Best practices
Section titled “Best practices”- Prefer templates over one-off designs: Reusable patterns accelerate migration waves.
- Document deviations explicitly: Keep risk, owner, and expiry date transparent.
- Align with migration factory: Integrate landing zone patterns into wave runbooks.
- Continuously improve: Feed migration and run feedback into the template backlog.
Understanding Application Landing Zones
Section titled “Understanding Application Landing Zones”An application landing zone is a workload-specific implementation blueprint derived from the platform landing zone baseline.
It translates enterprise guardrails into practical patterns for concrete application types, for example VM-centric Rehost, containerized workloads, or data platform workloads.
Why it depends on Discovery
Section titled “Why it depends on Discovery”Application landing zones are not designed in isolation. They require validated discovery input for dependencies, data sensitivity, runtime behavior, and operational constraints.
Typical discovery-driven design inputs:
- Dependency profile: Inbound/outbound communication paths and trust boundaries.
- Runtime profile: Resource behavior, availability expectations, and scaling characteristics.
- Data and compliance profile: Classification, retention, and control obligations.
- Migration strategy fit: Rehost, Replatform, or refactor constraints for each workload.
Typical application landing zone patterns
Section titled “Typical application landing zone patterns”Rehost-ready pattern
Minimal change target for VM-based workloads with inherited central controls.
Container platform pattern
Segmented, policy-driven setup for Kubernetes-based workload groups.
Data workload pattern
Landing zone profile for data services, integration paths, and stricter controls.
Shared service pattern
Isolated setup for foundational services used by multiple product teams.
Delivery approach
Section titled “Delivery approach”- Classify workload archetypes from discovery findings and target strategy.
- Map platform baseline controls to each archetype and identify controlled deviations.
- Build reusable IaC templates and policy sets for each application landing zone profile.
- Validate with pilot workloads and production-like cutover scenarios.
- Publish templates, runbooks, and onboarding guidance for migration waves.
Best practices
Section titled “Best practices”- Prefer templates over one-off designs: Reusable patterns accelerate migration waves.
- Document deviations explicitly: Keep risk, owner, and expiry date transparent.
- Align with migration factory: Integrate landing zone patterns into wave runbooks.
- Continuously improve: Feed migration and run feedback into the template backlog.
Accelerate the Foundation as Code
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Establish the Platform Baseline
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Start with a Standalone Foundation
Choose the smallest accelerator topology when workloads need independent networks and direct internet access without shared private connectivity.
Connect Corporate Workloads Privately
Introduce a central connectivity project, shared Network Area, and DNS when corporate workloads need private east-west communication.
Centralize Egress Inspection
Extend hub-and-spoke with an OPNsense firewall when corporate traffic requires a consistent inspection point and controlled egress path.
Separate Business Unit Domains
Give finance and research independent ownership, address plans, connectivity projects, and private workload domains inside one organization.
Separate Regulated and Shared Workloads
Create distinct Network Areas and DNS zones when regulated and shared workloads must have no implicit private routing between them.
Build Independent Regional Hubs
Deploy isolated foundations in eu01 and eu02 when regional workloads need their own connectivity, landing-zone, and platform boundaries.
Isolate Production from Non-production
Use separate Network Areas and firewalls when production requires a stronger boundary while development and test can share a non-production domain.
Isolate Tenant Connectivity
Create independent ownership, address plans, and private connectivity domains when multiple tenants share the organization but must not route to one another.
Provision Application Environments
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Accelerator architecture
Section titled “Accelerator architecture”
Overview
Section titled “Overview”This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.
Repository:
How the repository works
Section titled “How the repository works”This repository is a single root-module accelerator with modular submodules.
- The root module in
src/main.tforchestrates all platform and landing-zone building blocks. - Configuration is provided through flavor-specific variable files in
src/config/. - You can deploy with OpenTofu or Terraform (same module graph).
- The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.
Deployment flavours and what they enable
Section titled “Deployment flavours and what they enable”The repository provides eight reference configurations in src/config/. Choose the simplest
topology that satisfies the required network, security, organizational, tenant, and regional
boundaries.
Standalone
Section titled “Standalone”
Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a
public application landing zone with its own network and direct internet access. It creates no
shared Network Area or connectivity hub, making it suitable when workloads do not require private
east-west connectivity or central DNS.
Hub-and-spoke
Section titled “Hub-and-spoke”
Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central
connectivity project provides the Network Area and DNS, the corporate data platform joins that
private domain, and public workloads retain independent networks with direct internet access.
Hub-and-spoke with firewall
Section titled “Hub-and-spoke with firewall”
Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control
point. It extends the shared Network Area with an OPNsense firewall and steers corporate default
routes through the appliance, while public landing zones remain directly connected.
Finance and research separation
Section titled “Finance and research separation”
Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and
private connectivity. Finance and research each receive their own address plan, connectivity
project, Network Area, and workload landing zone within the same STACKIT organization.
Regulated and shared network areas
Section titled “Regulated and shared network areas”
Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate
private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit
routing between them.
Independent regional hubs
Section titled “Independent regional hubs”
Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region
receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes
cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.
Production and non-production isolation
Section titled “Production and non-production isolation”
Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from
non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development
and test share the non-production domain while remaining separate landing zones.
Tenant isolation
Section titled “Tenant isolation”
Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every
tenant receives an independent owner, address plan, Network Area, connectivity project, and
workload landing zone, without private routing to the other tenant domains.
Module-by-module breakdown
Section titled “Module-by-module breakdown”1. Governance module (src/modules/governance)
Section titled “1. Governance module (src/modules/governance)”Purpose:
- Creates RM folder structure (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Assigns folder-level owners and auditors.
- Assigns organization-level owners and auditors.
- Creates custom roles at organization scope.
Landing-zone classification:
- Platform Landing Zone: core governance baseline.
2. Management module (src/modules/management)
Section titled “2. Management module (src/modules/management)”Purpose:
- Creates a central management project.
- Provisions Secrets Manager and default access user.
- Provisions object storage buckets (including a remote state bucket).
- Creates object-storage credentials and stores them in Secrets Manager.
- Creates automation service account + rotating keys, stores key in Secrets Manager.
- Optionally provisions observability and stores observability credentials in Secrets Manager.
- Optionally configures federated identity providers for the automation service account.
Landing-zone classification:
- Platform Landing Zone: shared operations and automation control plane.
3. Connectivity module (src/modules/connectivity)
Section titled “3. Connectivity module (src/modules/connectivity)”Purpose:
- Creates a dedicated connectivity project.
- Creates network area and regional network-area configuration.
- Creates DNS zones for shared naming domains.
- Optionally creates firewall image, volume, server, interfaces, public IP.
- Exposes firewall next-hop IP for route injection into corporate landing zones.
Landing-zone classification:
- Platform Landing Zone: shared network and routing baseline.
4. DevOps module (src/modules/devops)
Section titled “4. DevOps module (src/modules/devops)”Purpose:
- Creates a dedicated DevOps project.
- Optionally creates a central STACKIT Git instance with ACL ranges.
Landing-zone classification:
- Platform Landing Zone in this accelerator’s architecture.
- Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.
5. Landing-Zone module (src/modules/landing-zone)
Section titled “5. Landing-Zone module (src/modules/landing-zone)”Purpose:
- Creates application-facing landing-zone projects (iterative via
for_each). - Supports corporate landing zones (network area-connected) and public landing zones.
- Creates routed networks, optional routing-table default route via firewall next hop.
- Optionally creates per-project child DNS zones.
- Creates project-level custom roles and role assignments.
- Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.
Landing-zone classification:
- Application Landing Zone: primary ALZ implementation module.
6. Sandboxes module (src/modules/sandboxes)
Section titled “6. Sandboxes module (src/modules/sandboxes)”Purpose:
- Creates lightweight sandbox projects in the dedicated
sandboxesfolder. - Assigns project owners.
Landing-zone classification:
- Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.
Newly implemented scope in this asset
Section titled “Newly implemented scope in this asset”The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.
Platform landing zone for central Kubernetes
Section titled “Platform landing zone for central Kubernetes”The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.
- Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
- Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
- Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
- Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.
Application landing zone for namespace tenants
Section titled “Application landing zone for namespace tenants”Application landing zones can now consume namespace service from the central Kubernetes platform cluster.
- Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
- Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
- Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
- Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.
Extra platform features used in this setup
Section titled “Extra platform features used in this setup”- External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
- Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
- Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
- Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
- Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.
What developers get in an application landing zone
Section titled “What developers get in an application landing zone”- Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
- Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
- Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
- Governed secret usage: Central secret governance with namespace-level consumption patterns.
- Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.
Platform vs application landing zone scope in this repository
Section titled “Platform vs application landing zone scope in this repository”- Platform Landing Zone focus (majority of implementation):
governancemanagementconnectivitydevops
- Application Landing Zone scope (narrower by design):
landing-zone(core ALZ provisioning)sandboxes(supporting ALZ-adjacent environments)
This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.
How to use this asset in migration programs
Section titled “How to use this asset in migration programs”- Start the platform baseline early (governance, management, connectivity, optional DevOps).
- Define corporate vs public ALZ patterns based on connectivity and compliance needs.
- Instantiate application landing zones with the
landing-zonemap in your variable files. - Use sandboxes for team onboarding and controlled early experiments.
- Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.
What you get
Section titled “What you get”- Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
- Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
- IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
- Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.
Typical use in migration programs
Section titled “Typical use in migration programs”- Early platform stream: Start foundation setup in parallel with discovery.
- Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
- Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Recommended prerequisites
Section titled “Recommended prerequisites”- Organization and ownership model for projects/environments.
- Security and compliance requirements (identity, logging, evidence, segmentation).
- Connectivity constraints and integration requirements.
- Operating model alignment across platform, security, and application teams.
Scale Through Managed Delivery
Service
Managed Landing Zone Service
STACKIT
Migration design-and-mobilize landing-zone managed-service opentofu terragrunt
STACKIT
The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.
Overview
Section titled “Overview”This managed asset builds on the STACKIT landing zone foundation and adds structured advisory, setup support, and implementation guidance as a service.
It supports organizations that need both technical accelerators and delivery governance to establish a production-ready cloud baseline.
Service scope
Section titled “Service scope”- Advisory and target design: Definition of landing zone scope, control model, and rollout plan.
- Catalog-based implementation: Structured setup based on predefined capability and control catalogs.
- Technical enablement: Implementation support with OpenTofu,
Terragrunt, and boilerplate patterns. - Operational handover: Transfer into customer operating model with documented responsibilities.
Typical outcomes
Section titled “Typical outcomes”- Governed platform baseline: Mandatory controls and ownership boundaries are implemented.
- Reusable automation stack: IaC modules and conventions are standardized for future change.
- Faster migration readiness: Productive migration waves can start without core platform blockers.
- Reduced delivery risk: Platform, security, and application teams align on one implementation model.
Engagement model
Section titled “Engagement model”Typical engagements run in close collaboration with platform, security, and application stakeholders. The service can be delivered as a focused setup initiative or integrated into a broader migration factory program.
Overview
Section titled “Overview”This managed asset builds on the STACKIT landing zone foundation and adds structured advisory, setup support, and implementation guidance as a service.
It supports organizations that need both technical accelerators and delivery governance to establish a production-ready cloud baseline.
Service scope
Section titled “Service scope”- Advisory and target design: Definition of landing zone scope, control model, and rollout plan.
- Catalog-based implementation: Structured setup based on predefined capability and control catalogs.
- Technical enablement: Implementation support with OpenTofu,
Terragrunt, and boilerplate patterns. - Operational handover: Transfer into customer operating model with documented responsibilities.
Typical outcomes
Section titled “Typical outcomes”- Governed platform baseline: Mandatory controls and ownership boundaries are implemented.
- Reusable automation stack: IaC modules and conventions are standardized for future change.
- Faster migration readiness: Productive migration waves can start without core platform blockers.
- Reduced delivery risk: Platform, security, and application teams align on one implementation model.
Engagement model
Section titled “Engagement model”Typical engagements run in close collaboration with platform, security, and application stakeholders. The service can be delivered as a focused setup initiative or integrated into a broader migration factory program.
Overview
Section titled “Overview”This managed asset builds on the STACKIT landing zone foundation and adds structured advisory, setup support, and implementation guidance as a service.
It supports organizations that need both technical accelerators and delivery governance to establish a production-ready cloud baseline.
Service scope
Section titled “Service scope”- Advisory and target design: Definition of landing zone scope, control model, and rollout plan.
- Catalog-based implementation: Structured setup based on predefined capability and control catalogs.
- Technical enablement: Implementation support with OpenTofu,
Terragrunt, and boilerplate patterns. - Operational handover: Transfer into customer operating model with documented responsibilities.
Typical outcomes
Section titled “Typical outcomes”- Governed platform baseline: Mandatory controls and ownership boundaries are implemented.
- Reusable automation stack: IaC modules and conventions are standardized for future change.
- Faster migration readiness: Productive migration waves can start without core platform blockers.
- Reduced delivery risk: Platform, security, and application teams align on one implementation model.
Engagement model
Section titled “Engagement model”Typical engagements run in close collaboration with platform, security, and application stakeholders. The service can be delivered as a focused setup initiative or integrated into a broader migration factory program.
Overview
Section titled “Overview”This managed asset builds on the STACKIT landing zone foundation and adds structured advisory, setup support, and implementation guidance as a service.
It supports organizations that need both technical accelerators and delivery governance to establish a production-ready cloud baseline.
Service scope
Section titled “Service scope”- Advisory and target design: Definition of landing zone scope, control model, and rollout plan.
- Catalog-based implementation: Structured setup based on predefined capability and control catalogs.
- Technical enablement: Implementation support with OpenTofu,
Terragrunt, and boilerplate patterns. - Operational handover: Transfer into customer operating model with documented responsibilities.
Typical outcomes
Section titled “Typical outcomes”- Governed platform baseline: Mandatory controls and ownership boundaries are implemented.
- Reusable automation stack: IaC modules and conventions are standardized for future change.
- Faster migration readiness: Productive migration waves can start without core platform blockers.
- Reduced delivery risk: Platform, security, and application teams align on one implementation model.
Engagement model
Section titled “Engagement model”Typical engagements run in close collaboration with platform, security, and application stakeholders. The service can be delivered as a focused setup initiative or integrated into a broader migration factory program.
meshStack Simplifies Landing Zone Management
Architecture
Section titled “Architecture”
Overview
Section titled “Overview”The STACKIT Landing Zone Accelerator provisions the platform baseline as code. This reference architecture adds the layer above it: meshStack registers the STACKIT platform, its landing zones and a set of building block definitions, so application teams order STACKIT projects and routed networks themselves instead of filing a ticket with the platform team.
It is implemented as OpenTofu in the meshStack Hub and deployed once per workspace.
How the two parts compose
Section titled “How the two parts compose”The Accelerator’s management module creates an automation service account, assigns it owner at organization scope, and stores its key in Secrets Manager.
That is exactly the credential this reference architecture needs: it takes one STACKIT service account key with resource-manager.admin on the organization.
So the two run together as one stack — deploy the Accelerator, read the automation key from Secrets Manager, and hand it to the meshStack landing zone.
What it provisions
Section titled “What it provisions”- STACKIT platform and landing zones: The
STACKIT Projectplatform is registered in meshStack together with its landing zones, wired to the service account that creates projects. - Project building block: A
stackit/projectbuilding block definition that application teams order to get a STACKIT project, with meshStack roles mapped to STACKIT project roles. - Optional hub-and-spoke networking: A shared network area holding the IPv4 address plan, plus a tenant-level
stackit/networkbuilding block. Each order draws its subnet from the shared plan, so two teams cannot collide on CIDR ranges. - Self-service starterkit: A
STACKIT Project Starterkitdefinition that composes the two building blocks above into one order. It is always registered, and the landing zones it offers are the ones the deployment actually created. - Resource hierarchy: A dedicated resourcemanager folder that tenant projects are created in, and a foundation project for the landing zone’s own service account.
Leaving the network configuration unset deploys the sandbox foundation only, which is the smallest useful starting point.
What application teams get
Section titled “What application teams get”- A working project from one order: The starterkit creates the project in the landing zone the team picked and applies the role assignments, so nobody has to order the pieces separately.
- A subnet without coordination: On the networked landing zone the same order adds a routed network inside that project, its CIDR range assigned from the shared address plan.
- Visible ownership: Every project and network has a named owning team, which is what cost allocation and policy reporting build on.
Shared responsibilities
Section titled “Shared responsibilities”| Responsibility | Platform Team | Application Team |
|---|---|---|
| Provision the STACKIT platform baseline with the Accelerator | ✅ | ❌ |
| Register the platform, landing zones and building block definitions | ✅ | ❌ |
| Choose the shared address plan (when networking is enabled) | ✅ | ❌ |
| Request STACKIT projects through a landing zone | ❌ | ✅ |
| Order routed networks inside their own projects | ❌ | ✅ |
| Operate the workloads inside their projects | ❌ | ✅ |
Reference
Section titled “Reference”- Source: meshstack-hub on GitHub
Architecture
Section titled “Architecture”
Overview
Section titled “Overview”The STACKIT Landing Zone Accelerator provisions the platform baseline as code. This reference architecture adds the layer above it: meshStack registers the STACKIT platform, its landing zones and a set of building block definitions, so application teams order STACKIT projects and routed networks themselves instead of filing a ticket with the platform team.
It is implemented as OpenTofu in the meshStack Hub and deployed once per workspace.
How the two parts compose
Section titled “How the two parts compose”The Accelerator’s management module creates an automation service account, assigns it owner at organization scope, and stores its key in Secrets Manager.
That is exactly the credential this reference architecture needs: it takes one STACKIT service account key with resource-manager.admin on the organization.
So the two run together as one stack — deploy the Accelerator, read the automation key from Secrets Manager, and hand it to the meshStack landing zone.
What it provisions
Section titled “What it provisions”- STACKIT platform and landing zones: The
STACKIT Projectplatform is registered in meshStack together with its landing zones, wired to the service account that creates projects. - Project building block: A
stackit/projectbuilding block definition that application teams order to get a STACKIT project, with meshStack roles mapped to STACKIT project roles. - Optional hub-and-spoke networking: A shared network area holding the IPv4 address plan, plus a tenant-level
stackit/networkbuilding block. Each order draws its subnet from the shared plan, so two teams cannot collide on CIDR ranges. - Self-service starterkit: A
STACKIT Project Starterkitdefinition that composes the two building blocks above into one order. It is always registered, and the landing zones it offers are the ones the deployment actually created. - Resource hierarchy: A dedicated resourcemanager folder that tenant projects are created in, and a foundation project for the landing zone’s own service account.
Leaving the network configuration unset deploys the sandbox foundation only, which is the smallest useful starting point.
What application teams get
Section titled “What application teams get”- A working project from one order: The starterkit creates the project in the landing zone the team picked and applies the role assignments, so nobody has to order the pieces separately.
- A subnet without coordination: On the networked landing zone the same order adds a routed network inside that project, its CIDR range assigned from the shared address plan.
- Visible ownership: Every project and network has a named owning team, which is what cost allocation and policy reporting build on.
Shared responsibilities
Section titled “Shared responsibilities”| Responsibility | Platform Team | Application Team |
|---|---|---|
| Provision the STACKIT platform baseline with the Accelerator | ✅ | ❌ |
| Register the platform, landing zones and building block definitions | ✅ | ❌ |
| Choose the shared address plan (when networking is enabled) | ✅ | ❌ |
| Request STACKIT projects through a landing zone | ❌ | ✅ |
| Order routed networks inside their own projects | ❌ | ✅ |
| Operate the workloads inside their projects | ❌ | ✅ |
Reference
Section titled “Reference”- Source: meshstack-hub on GitHub
Deliver Projects and Networks Through Self-Service
Architecture
Section titled “Architecture”
Overview
Section titled “Overview”The STACKIT Landing Zone Accelerator provisions the platform baseline as code. This reference architecture adds the layer above it: meshStack registers the STACKIT platform, its landing zones and a set of building block definitions, so application teams order STACKIT projects and routed networks themselves instead of filing a ticket with the platform team.
It is implemented as OpenTofu in the meshStack Hub and deployed once per workspace.
How the two parts compose
Section titled “How the two parts compose”The Accelerator’s management module creates an automation service account, assigns it owner at organization scope, and stores its key in Secrets Manager.
That is exactly the credential this reference architecture needs: it takes one STACKIT service account key with resource-manager.admin on the organization.
So the two run together as one stack — deploy the Accelerator, read the automation key from Secrets Manager, and hand it to the meshStack landing zone.
What it provisions
Section titled “What it provisions”- STACKIT platform and landing zones: The
STACKIT Projectplatform is registered in meshStack together with its landing zones, wired to the service account that creates projects. - Project building block: A
stackit/projectbuilding block definition that application teams order to get a STACKIT project, with meshStack roles mapped to STACKIT project roles. - Optional hub-and-spoke networking: A shared network area holding the IPv4 address plan, plus a tenant-level
stackit/networkbuilding block. Each order draws its subnet from the shared plan, so two teams cannot collide on CIDR ranges. - Self-service starterkit: A
STACKIT Project Starterkitdefinition that composes the two building blocks above into one order. It is always registered, and the landing zones it offers are the ones the deployment actually created. - Resource hierarchy: A dedicated resourcemanager folder that tenant projects are created in, and a foundation project for the landing zone’s own service account.
Leaving the network configuration unset deploys the sandbox foundation only, which is the smallest useful starting point.
What application teams get
Section titled “What application teams get”- A working project from one order: The starterkit creates the project in the landing zone the team picked and applies the role assignments, so nobody has to order the pieces separately.
- A subnet without coordination: On the networked landing zone the same order adds a routed network inside that project, its CIDR range assigned from the shared address plan.
- Visible ownership: Every project and network has a named owning team, which is what cost allocation and policy reporting build on.
Shared responsibilities
Section titled “Shared responsibilities”| Responsibility | Platform Team | Application Team |
|---|---|---|
| Provision the STACKIT platform baseline with the Accelerator | ✅ | ❌ |
| Register the platform, landing zones and building block definitions | ✅ | ❌ |
| Choose the shared address plan (when networking is enabled) | ✅ | ❌ |
| Request STACKIT projects through a landing zone | ❌ | ✅ |
| Order routed networks inside their own projects | ❌ | ✅ |
| Operate the workloads inside their projects | ❌ | ✅ |
Reference
Section titled “Reference”- Source: meshstack-hub on GitHub
Architecture
Section titled “Architecture”
Overview
Section titled “Overview”The STACKIT Landing Zone Accelerator provisions the platform baseline as code. This reference architecture adds the layer above it: meshStack registers the STACKIT platform, its landing zones and a set of building block definitions, so application teams order STACKIT projects and routed networks themselves instead of filing a ticket with the platform team.
It is implemented as OpenTofu in the meshStack Hub and deployed once per workspace.
How the two parts compose
Section titled “How the two parts compose”The Accelerator’s management module creates an automation service account, assigns it owner at organization scope, and stores its key in Secrets Manager.
That is exactly the credential this reference architecture needs: it takes one STACKIT service account key with resource-manager.admin on the organization.
So the two run together as one stack — deploy the Accelerator, read the automation key from Secrets Manager, and hand it to the meshStack landing zone.
What it provisions
Section titled “What it provisions”- STACKIT platform and landing zones: The
STACKIT Projectplatform is registered in meshStack together with its landing zones, wired to the service account that creates projects. - Project building block: A
stackit/projectbuilding block definition that application teams order to get a STACKIT project, with meshStack roles mapped to STACKIT project roles. - Optional hub-and-spoke networking: A shared network area holding the IPv4 address plan, plus a tenant-level
stackit/networkbuilding block. Each order draws its subnet from the shared plan, so two teams cannot collide on CIDR ranges. - Self-service starterkit: A
STACKIT Project Starterkitdefinition that composes the two building blocks above into one order. It is always registered, and the landing zones it offers are the ones the deployment actually created. - Resource hierarchy: A dedicated resourcemanager folder that tenant projects are created in, and a foundation project for the landing zone’s own service account.
Leaving the network configuration unset deploys the sandbox foundation only, which is the smallest useful starting point.
What application teams get
Section titled “What application teams get”- A working project from one order: The starterkit creates the project in the landing zone the team picked and applies the role assignments, so nobody has to order the pieces separately.
- A subnet without coordination: On the networked landing zone the same order adds a routed network inside that project, its CIDR range assigned from the shared address plan.
- Visible ownership: Every project and network has a named owning team, which is what cost allocation and policy reporting build on.
Shared responsibilities
Section titled “Shared responsibilities”| Responsibility | Platform Team | Application Team |
|---|---|---|
| Provision the STACKIT platform baseline with the Accelerator | ✅ | ❌ |
| Register the platform, landing zones and building block definitions | ✅ | ❌ |
| Choose the shared address plan (when networking is enabled) | ✅ | ❌ |
| Request STACKIT projects through a landing zone | ❌ | ✅ |
| Order routed networks inside their own projects | ❌ | ✅ |
| Operate the workloads inside their projects | ❌ | ✅ |
Reference
Section titled “Reference”- Source: meshstack-hub on GitHub
Architecture
Section titled “Architecture”
Overview
Section titled “Overview”The STACKIT Landing Zone Accelerator provisions the platform baseline as code. This reference architecture adds the layer above it: meshStack registers the STACKIT platform, its landing zones and a set of building block definitions, so application teams order STACKIT projects and routed networks themselves instead of filing a ticket with the platform team.
It is implemented as OpenTofu in the meshStack Hub and deployed once per workspace.
How the two parts compose
Section titled “How the two parts compose”The Accelerator’s management module creates an automation service account, assigns it owner at organization scope, and stores its key in Secrets Manager.
That is exactly the credential this reference architecture needs: it takes one STACKIT service account key with resource-manager.admin on the organization.
So the two run together as one stack — deploy the Accelerator, read the automation key from Secrets Manager, and hand it to the meshStack landing zone.
What it provisions
Section titled “What it provisions”- STACKIT platform and landing zones: The
STACKIT Projectplatform is registered in meshStack together with its landing zones, wired to the service account that creates projects. - Project building block: A
stackit/projectbuilding block definition that application teams order to get a STACKIT project, with meshStack roles mapped to STACKIT project roles. - Optional hub-and-spoke networking: A shared network area holding the IPv4 address plan, plus a tenant-level
stackit/networkbuilding block. Each order draws its subnet from the shared plan, so two teams cannot collide on CIDR ranges. - Self-service starterkit: A
STACKIT Project Starterkitdefinition that composes the two building blocks above into one order. It is always registered, and the landing zones it offers are the ones the deployment actually created. - Resource hierarchy: A dedicated resourcemanager folder that tenant projects are created in, and a foundation project for the landing zone’s own service account.
Leaving the network configuration unset deploys the sandbox foundation only, which is the smallest useful starting point.
What application teams get
Section titled “What application teams get”- A working project from one order: The starterkit creates the project in the landing zone the team picked and applies the role assignments, so nobody has to order the pieces separately.
- A subnet without coordination: On the networked landing zone the same order adds a routed network inside that project, its CIDR range assigned from the shared address plan.
- Visible ownership: Every project and network has a named owning team, which is what cost allocation and policy reporting build on.
Shared responsibilities
Section titled “Shared responsibilities”| Responsibility | Platform Team | Application Team |
|---|---|---|
| Provision the STACKIT platform baseline with the Accelerator | ✅ | ❌ |
| Register the platform, landing zones and building block definitions | ✅ | ❌ |
| Choose the shared address plan (when networking is enabled) | ✅ | ❌ |
| Request STACKIT projects through a landing zone | ❌ | ✅ |
| Order routed networks inside their own projects | ❌ | ✅ |
| Operate the workloads inside their projects | ❌ | ✅ |
Reference
Section titled “Reference”- Source: meshstack-hub on GitHub
Trail historyActive 7 of the last 12 weeksLWUpdatedNo updates · 1 bar = 1 week i
Maintainers
- LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updateswww.linkedin.com/in/lukas-weberruß-a360b081
LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in STACKIT
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in STACKITLukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 24, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 24, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 15, 2026
Show full history (17 more)
Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Sep 11, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 26, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Aug 25, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Aug 24, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 19, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Aug 11, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 7, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 24, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 23, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 21, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 21, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 20, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 20, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 20, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 16, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Jul 15, 2026Lukas Weberruß
Lukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081
· Jul 13, 2026