Unit 8.2: The Reference Enterprise Architecture

Introduction

Every prior unit decided one thing in isolation: a compute class, a replication mode, a load-balancer layer, a failover mechanism. This unit puts them on one canvas at once. The purpose is not to re-teach any product but to show how the decisions compose, where a choice in one tier constrains a choice in another, and how the platform's honest boundaries shape the whole picture rather than just the part that touches them.

The reference architecture is FinCorp's: a German financial-services firm under GDPR and BSI oversight, migrating a large VMware estate and standing up an AI capability. It is the accumulation of every decision made across Modules 1 through 7, drawn as a single system. Treat it as a template you instantiate, not a diagram you copy.

1. The Assembled System

The design is organised by the canonical layered shape from Unit 1.2: a public Layer 7 edge, a stateless compute tier, a private Layer 4 balancer, and a private-only data tier. Around that spine sit the dedicated VMware estate, the container platform, the AI tier, and the hybrid links to FinCorp's premises. Everything lives inside one contract (the governance and billing boundary from Unit 2.1) and is segmented across Virtual Data Centers by region and environment.

1.1 Segmentation and the layered path

A LAN on IONOS is private until it is connected to internet access (Unit 3.1). FinCorp's production VDC carries three LANs: a public edge LAN, a private application LAN, and a private data LAN. North-south traffic enters at the public edge; east-west traffic between tiers stays on private LANs and never traverses a public IP.

The request path is layered deliberately. A public Managed Application Load Balancer (ALB) terminates TLS at the edge and routes on Layer 7 attributes; it serves as the edge device handling north-south traffic in and out of the data center. Behind it sits the stateless application tier on Dedicated Core compute. Those servers reach the data tier through a private Managed Network Load Balancer (NLB), which passes Layer 4 TCP through to the database endpoints and handles east-west traffic inside the data center. The public-ALB-to-private-NLB composition (Units 3.3 and 3.4) is the load-balancing backbone: content-aware at the edge where routing logic matters, fast TCP pass-through internally where it does not.

The application tier is stateless on purpose. That precondition is what lets it auto-scale (Unit 4.3) and what lets the fronting load balancer shift new connections onto healthy replicas without stranding session state. Session and read state are externalised to the in-memory cache tier rather than held on the servers.

1.2 Dedicated VMware for regulated processing

FinCorp's regulated core runs on IONOS Private Cloud: a managed dedicated VMware SDDC (vSphere Enterprise Plus, vSAN, NSX-T) on single-tenant hardware, with licensing included rather than brought (Unit 4.4). Single-tenancy is the design driver here: the workloads that carry the strictest isolation and predictability requirements sit on hardware no other tenant shares. Provisioning is a guided engagement, not a self-service console action, which is why this part of the estate is designed rather than built in the Data Center Designer.

The VMware estate is not an island. It links to the elastic standard-compute edge over the hybrid connectivity described below, giving FinCorp the proven hybrid pattern: a dedicated VMware core for regulated, steady-state processing plus elastic standard compute for variable edge load. The VMware stack here is NSX-T 3.2 with vCenter for in-cluster management; the only VMware mobility and replication tooling in scope is what the platform actually provides, covered under migration below.

1.3 Managed Kubernetes for containers

New and refactored services run on Managed Kubernetes (Unit 6.1). The control plane is managed and free; FinCorp pays for node pools, which carry their own SLA separate from the control plane. The cluster attaches to the layered shape through a separately provisioned load balancer plus an in-cluster ingress controller, because a Kubernetes manifest does not auto-provision an IONOS managed load balancer. A LoadBalancer-type Service resolves to a single-node static IP, not a managed balancer, so the production ingress path is an ALB in front of an in-cluster ingress controller. This is the API-gateway substitution realised: ALB path rules plus in-cluster ingress stand in for a managed API gateway, which IONOS does not sell.

Security on the cluster is split honestly. Network Security Groups and NIC firewalls bind to worker-node NICs, not to the cluster abstraction, so pod-to-pod control is enforced with in-cluster network policies. Container images come from the Container Registry, governed by token discipline (one narrowly scoped token per pipeline stage, with expiry and rotation; tokens are deleted, not disabled) because the registry has no RBAC.

1.4 The data platform

The data tier is private-endpoint-only and composed from several managed engines, each matched to an access pattern:

• Relational (Managed PostgreSQL / MariaDB): the system of record. There are no read replicas. Replication is in-cluster (PostgreSQL async by default, with synchronous and strictly-synchronous modes available; MariaDB async-only) for durability and intra-cluster auto-promotion, not for read scaling.
• In-Memory cache: the read-scaling and state-externalisation layer (Unit 5.5). It fronts the relational tier and absorbs read load, and it holds session state lifted off the stateless application tier. This cache is what makes both the no-read-replica pattern and safe auto-scaling work; it is not optional decoration.
• Document (Managed MongoDB): for the workloads whose shape fits a document model better than relational rows.
• Streaming (Managed Kafka): the ingestion spine and the change-data-capture substitute. Because there is no managed database change stream, applications publish events to Kafka at the application level. Partitions are the unit of ordering and consumer parallelism; the topic and partition design is the load-bearing decision.
• Object archive (Object Storage): the S3-compatible flat-namespace store that serves as backup target, audit archive, dataset and artifact store, and the dead-letter and archive tail for Kafka. Object lock provides tamper-evident retention.

1.5 The AI tier

FinCorp's AI capability defaults to managed inference on the AI Model Hub: an OpenAI-compatible inference API, per-token pricing, stateless, with EU data residency and in-country processing. Retrieval-augmented generation is customer-built from platform parts: embeddings from the hub, vectors stored in Managed PostgreSQL, and the source corpus in Object Storage. The hub's managed vector-store feature is avoided in favour of this composed pattern, which keeps the retrieval store under FinCorp's own database governance.

1.6 Hybrid connectivity

FinCorp's premises and its VMware estate reach the cloud over the connectivity primitives from Unit 3.6. A VPN Gateway (IKEv2 or WireGuard, no IKEv1; active-passive HA sharing one public IP) carries encrypted site-to-cloud traffic. A NAT Gateway provides outbound egress for private workloads that have no public IP; it is SNAT-only, so it is an egress path, never an inbound entry point. Private Cross-Connect links VDCs in the same region and contract over a shared private interconnect, including the cross-VDC node traffic a private Kubernetes cluster depends on.

1.7 Resilience, observability, and cost as the operating envelope

Resilience (Unit 7.1) rests on platform primitives rather than a managed failover product, which does not exist. Redundant pairs are placed in explicit availability zones (never Auto, which can co-locate them), and the managed load balancers health-check their targets and stop routing to a failed backend; Cloud DNS provides anycast resolution and a low minimum TTL for fast record propagation, but performs no native health-check-based failover. The traffic-steering plane (DNS) is kept separate from the data-continuity plane (backups, snapshots, PITR, Object Storage archive). Observability (Unit 7.2) spans four fixed-scope telemetry planes, metrics, logs, audit, and network flow logs, fanned in to an external SIEM because there is no cross-contract aggregation and Kubernetes control-plane events do not flow through the logging service. Cost (Unit 2.4) is governed by allocation per contract and VDC, storage tiered to access pattern, and Savings Plans committed to the steady-state floor.

2. Cross-Cutting Concerns, Not Isolated Features

The architecture only holds together because four concerns run through every tier rather than living in one box.

High availability is composed, not bought. The edge ALB and NLB are managed and resilient; redundant compute and data nodes are placed across explicit zones; the managed load balancers health-check their targets and route around failed backends; and the dedicated VMware estate adds vSAN fault tolerance and vSphere HA within its cluster. No single product delivers end-to-end HA; the design layers these mechanisms.

Load balancing appears at two altitudes for two reasons. Layer 7 at the public edge gives content-aware routing and TLS termination; Layer 4 internally gives fast TCP pass-through with the backend keeping its own certificate. Neither managed balancer accepts a Network Security Group or an IP allowlist, so filtering belongs on the targets behind them.

Security is enforced where it binds: NIC firewalls and NSGs on server and worker NICs, in-cluster network policies inside Kubernetes, token discipline on the registry, and group-and-grant access control across the contract. There is no policy-language IAM and no deny rule; least privilege is achieved by not granting, and federation (SAML/OIDC) is authentication only, so the joiner-mover-leaver process is a manual runbook.

Connectivity stitches the estate together: private LANs for east-west tier traffic, VPN for site-to-cloud, NAT for private egress, and Cross-Connect for same-region cross-VDC links. The topology itself is a security control, because isolating the data tier on a private LAN is what compensates for the managed balancers' lack of NSG support.

The following table maps each IONOS capability boundary to the native pattern that composes around it, realised in this architecture.

Migration into the regulated VMware core uses only the tooling the platform provides: VMware Cloud Director Availability (VCDA, version 4.7.x) for asynchronous replication, migration, and live failover at roughly 50 EUR per protected VM per month; NSX-T's built-in L2 VPN for Layer 2 network extension (a standard NSX-T Edge feature, not a separately licensed add-on); and intra-cluster vMotion. vMotion is intra-cluster only and is not a cross-site live-mobility capability. Workloads with no VMware-native path are rehosted via image conversion and upload, and databases migrate by dump and restore, since the Backup Service does not cover managed databases.

Decision Summary

The reference architecture's load-bearing artifact is the service-by-service map: where each component is placed, and exactly which BSI recognition covers it. Compliance is scoped per service and per data-center location, never platform-wide, so the map is what an auditor reads. BSI C5 is a Type 1 attestation (Testat) granted 2023-11-07; IT-Grundschutz is an ISO 27001 certificate granted 2022-09-14 (BSI). Both apply to German data centers, and their scopes differ by service. IONOS is the first German cloud provider to hold both.

Two reading rules govern this table. First, "in scope" means that named service in German data centers carries that BSI recognition; it never licenses a platform-wide claim. C5 covers exactly Compute Engine, Cloud Cubes, and S3 Object Storage; IT-Grundschutz covers exactly Compute Engine, S3 Object Storage, Backup, and Managed Kubernetes. The two scopes diverge: Cubes sit under C5 but not IT-Grundschutz, while Managed Kubernetes and Backup sit under IT-Grundschutz but not C5. Second, the sovereignty filter from Unit 1.4 is applied last, over the whole design: every component is operated under EU jurisdiction, which is a property of the operator and not merely of the region.

The two composition errors to check the assembled design against are pairing incompatible primitives (for example, expecting an NSG to protect a managed balancer, or reaching for a Cross-Connect to join two VDCs in different regions) and placing a functionally correct service outside its required attestation scope (for example, running C5-required regulated processing on a service C5 does not cover).

Summary

The reference enterprise architecture is the whole course drawn as one system: a layered public-L7-to-private-L4 path over a stateless compute tier and a private data platform, with a dedicated VMware core for regulated processing, Managed Kubernetes for containers, an AI tier defaulting to managed inference, and hybrid links binding it to FinCorp's premises. High availability, load balancing, security, and connectivity are not features in boxes but concerns that thread through every tier, and the native-substitution set is what fills the gaps the platform deliberately does not sell as managed products. The service-by-service placement and compliance map is the artifact that makes the design defensible under audit.

Key Points:

• The layered shape is the spine; everything else (VMware core, Kubernetes, AI, data engines, hybrid links) attaches to it, and segmentation plus private-by-default drive the layout.
• HA, load balancing, security, and connectivity are cross-cutting: each is composed across tiers from platform primitives, not delivered by one product.
• The native-substitution set is realised end to end: API routing via ALB plus ingress, read scaling via cache, failover via load-balancer target health checks across zoned endpoints, CDC via Kafka, VM import via image conversion, access via group-and-grant.
• Compliance is per service and per data-center location: C5 (Type 1 attestation, 2023-11-07) and IT-Grundschutz (ISO 27001 certificate, 2022-09-14) have different service scopes, and the placement map encodes both.
• The regulated VMware core uses only VCDA, NSX-T L2 VPN, and intra-cluster vMotion; there is no cross-site live mobility, and databases migrate by dump and restore.

Further Reading

• Unit 8.1: Architecture Decision Frameworks (the selection matrices this design instantiates)
• Unit 8.3: Capstone Lab, which builds the FinCorp enterprise core end to end in the Data Center Designer
• Unit 1.2: The Canonical Layered Architecture; Unit 1.3: The Native-Substitution Model; Unit 1.4: Sovereignty and Compliance as Design Inputs
• IONOS Cloud Architecture Center