Unit 8.3: Capstone Lab - Build the Enterprise Core End-to-End

Introduction

Every prior module built one piece of FinCorp's environment in isolation and kept that build deliberately lean. This unit is where the pieces become a system. You will stand up the production core in a single Virtual Data Center: the three-tier topology from Module 3, the public Layer 7 and private Layer 4 balancers, the PostgreSQL cluster and the In-Memory DB cache on the private data tier from Module 5, a Managed Kubernetes cluster from Module 6, and the hybrid VPN and NAT gateways that carry the cutover.

The capstone does not re-teach each build; it references the unit that did. What it adds is the thing no single unit could show: the order of assembly and the dependencies between resources. The recurring failure when these builds meet is not a wrong field value, it is a wrong sequence, a balancer created before its targets exist, a gateway created before its public IP is reserved, a database given an address that collides with DHCP. Get the order right and the architecture from Unit 8.2 becomes real.

1. Build Order Is a Dependency Graph, Not a Checklist

The single most consequential decision in an integrated build is sequence. Several IONOS resources cannot be created, or cannot function, until something else exists first, and the platform does not always reorder the work for you. Treat the build as a dependency graph and resolve it bottom-up.

Four ordering rules carry most of the risk, and each was established in an earlier unit:

Reserve public IPs first. A public ALB needs at least one listener IP, the VPN Gateway and the NAT Gateway each select from reserved addresses, and a Kubernetes LoadBalancer ingress IP should be reserved so deleting a Service does not release it. Reserved IPv4 is region-bound, so reserve it in the VDC's region. This is the rule behind the common mistakes in Units 3.1, 3.3, and 3.6.
The VDC and its LANs precede everything. The three-LAN topology from Unit 3.1 is the substrate. Servers, databases, balancers, and gateways all attach to LANs that must already exist, with addressing reserved so managed services and gateways have room (the .2 to .9 range kept clear, the data tier on a stable static address).
A balancer needs its targets first. The private Layer 4 NLB from Unit 3.4 distributes to data-tier servers that must already be provisioned on their private LAN; an NLB pointed at targets that do not exist has nothing to route. The same applies to the application targets behind the Layer 7 ALB.
The hybrid network precedes the workloads that depend on it. The NAT Gateway must exist and the LAN default route must point at it before private workloads can reach the internet for package installation or outbound API calls; the routing change is the step teams forget.

These rules produce one natural order: network substrate, then compute, then the data tier, then the balancers that front it, then the container platform, then the hybrid edge. The walkthrough below follows exactly that order.

2. The Integrated Architecture FinCorp Is Building

The target is the canonical layered shape from Unit 1.2, now populated with the specific products chosen across the course. The following table maps each tier to its product, the unit that built it, and the design decision behind the choice, so the walkthrough can reference rather than repeat.

Tier / role	Product	Built in	Design decision
Network substrate	Three-LAN VDC topology, reserved public IPs	Unit 2.1, 3.1	Private-by-default segmentation; region and naming are permanent
Public Layer 7 entry	Managed Application Load Balancer (HTTPS listener, TLS termination)	Unit 3.3	Content-aware routing and the API-gateway substitution; the managed LB has no NSG, so filtering lives on targets
Application tier	Dedicated Core servers (stateless)	Unit 4.1	Dedicated Core for a predictable performance guarantee; kept stateless so it can scale horizontally and fail over, with the replica compute shape set in the auto-scaling replica template (Unit 4.3)
Private Layer 4 balancer	Managed Network Load Balancer (TCP pass-through)	Unit 3.4	Encrypted east-west traffic to the data tier; no TLS termination, certificate stays on the backend
Relational data	Managed PostgreSQL, multi-node, strictly synchronous	Unit 5.3	Ledger-grade durability; private endpoint only; no read replicas
Read scaling / state	In-Memory DB cache	Unit 5.5	The no-read-replica substitution and the stateless-tier precondition for auto-scaling
Container platform	Managed Kubernetes, public cluster, Frankfurt control plane	Unit 6.2	Free managed control plane; Frankfurt keeps control-plane data in Germany
Hybrid edge	VPN Gateway (IKEv2) and NAT Gateway (SNAT-only)	Unit 3.6	Encrypted link to the corporate data centre for cutover; outbound-only egress for private workloads

All of this lands in one VDC, in one region chosen back in Unit 1.4 to satisfy GDPR and BSI residency. The data tier never touches a public LAN; the only internet-facing surfaces are the public ALB and the two gateways' reserved IPs.

DCD Implementation Walkthrough

You will assemble the complete FinCorp core in the VDC created back in Unit 2.1, stitching together the builds from Modules 3, 5, and 6 in dependency order. Rather than restate every field, each step names the unit that documents the detailed build and states only what the integration adds: what must already exist, where it attaches, and the one decision that ties it to its neighbours. Treat the per-unit walkthroughs as the field-level reference and this as the assembly sequence.

Build goal: Build the FinCorp enterprise core end to end in the Data Center Designer, tying together the module walkthroughs.

Prerequisites: The FinCorp VDC from Unit 2.1 with its region fixed; the Reserve IP Blocks and Create Kubernetes Clusters privileges; an imported PEM certificate (single RSA leaf plus matching key) in the Certificate Manager for the ALB's HTTPS listener; and the connection details for the corporate data centre's IKEv2 peer.

Steps (in the Data Center Designer):

Reserve the public IPs (do this first). In Menu > Network Services > IP Management, reserve public IPv4 addresses in the VDC's region for: the public ALB listener, the VPN Gateway, the NAT Gateway, and the Kubernetes ingress endpoint. You receive addresses from the pool rather than choosing them, and each is region-bound. This single up-front step removes the most common ordering failure across Units 3.1, 3.3, and 3.6.
Build the three-LAN topology (as built in Unit 3.1). In the FinCorp VDC, create the public edge LAN (the only LAN attached to Internet Access), the private application LAN, and the private data LAN. Keep each default /24, leave .2 to .9 clear for managed services and gateways, and connect neither private LAN to the internet. This segmentation is what lets the managed balancers and the database stay safe without an NSG.
Provision the application-tier servers (as built in Unit 4.1). Place the stateless application servers on the private application LAN as Dedicated Core servers. Dedicated Core is the deliberate choice for a predictable performance guarantee under load; the tier is kept stateless so session data lives in the cache, not on the server, and so VM Auto Scaling can add and remove replicas freely (Unit 4.3).
Provision the data-tier servers or endpoints on the private data LAN. The Layer 4 balancer in step 7 needs targets that already exist, so the data-tier targets must be present before the NLB is created. Give the data-tier NICs stable static addresses outside the DHCP range.
Build the PostgreSQL cluster (as built in Unit 5.3). Under Menu > Databases > PostgreSQL, create a multi-node cluster on the private data LAN. For FinCorp's ledger, select Strictly Synchronous replication with three or more instances, set a real off-peak maintenance window, and assign a private IP ending between .3 and .10 so it never collides with DHCP. There is no public endpoint and no read replica; that gap is filled in the next step.
Build the In-Memory DB cache (as built in Unit 5.5). Under Menu > Databases > In-Memory DB, create the cache on the same private data LAN with a single private connection. This is the read-scaling half of the no-read-replica pattern and the externalised-state store that makes the application tier safe to auto-scale. Size it by RAM to the working set; capture the credentials at creation because they cannot be changed later.
Build the private Layer 4 NLB in front of the data tier (as built in Unit 3.4). Place a Network Load Balancer with both interfaces on private LANs: the listener on the application LAN, the backend on the data LAN. Add the now-existing data-tier servers as targets with a TCP forwarding rule and a TCP health check. The NLB does not terminate TLS, so the certificate stays on the backend; this is the private end of the layered path.
Build the public Layer 7 ALB at the edge (as built in Unit 3.3). Create the target group of application servers first, then place an Application Load Balancer with its northern interface on Internet Access and its southern interface on the application LAN. Configure the HTTPS listener on the reserved public IP from step 1 with the imported PEM certificate, add a path-based forwarding rule pointing at the target group, and order specific rules above the default. The ALB terminates TLS and gives the API-gateway substitution its edge half; it has no allowlist or NSG, so filtering stays on the target NICs.
Build the Managed Kubernetes cluster (as built in Unit 6.2). Under Menu > Containers > Managed Kubernetes, create a public cluster with a Frankfurt-backed control plane to keep control-plane data in Germany, then add a Dedicated Core node pool. Attach the cluster's node-pool LAN within the same VDC. Reserve the ingress IP from step 1, deploy an in-cluster ingress controller exposed as a single LoadBalancer Service pinned to that IP, and remember a LoadBalancer Service is a single-node static IP, not a managed balancer; real Layer 7 in front of the cluster is the ALB from step 8.
Build the NAT Gateway for private egress (as built in Unit 3.6). Add a NAT Gateway, connect it to the private application LAN, assign it a reserved public IP from step 1, and create a SNAT rule for the application subnet. Then set the private LAN's default route (0.0.0.0/0) to the gateway; without this routing change egress silently never happens. NAT is SNAT-only, so it provides no inbound path. Add a UDP SNAT rule so DNS still resolves for VMs using the NAT default route.
Build the VPN Gateway and tunnel to the corporate data centre (as built in Unit 3.6). Create an IKEv2 VPN Gateway on its reserved public IP, attach it to the private LAN with a gateway address in the .2 to .9 range, then create a tunnel to the corporate peer with a strong PSK and matching phase-1 and phase-2 parameters. List the cloud and peer network CIDRs as the static routing contract; there is no BGP. Select the High Availability tier variant so the active-passive pair shares the single gateway IP.
Provision and validate the whole VDC. Provision the accumulated changes. Validate the layered path end to end: a client reaches the ALB on its public IP over HTTPS, the application tier reads through the cache and falls back to PostgreSQL on a miss, the NLB distributes encrypted connections to the data tier, private workloads reach the internet only through the NAT Gateway, and the corporate data centre reaches the private LANs only across the VPN tunnel. The data tier is reachable from nowhere public.

Common mistakes:

Building a consumer before its reserved IP exists. The ALB listener, both gateways, and the Kubernetes ingress all expect a reserved address; reserve all of them in step 1, in the correct region, before anything consumes one.
Creating the NLB before the data-tier targets exist. A balancer pointed at absent targets routes to nothing; provision the data tier (step 4) before the NLB (step 7).
Pointing the NAT Gateway at the wrong thing, or forgetting the default route. NAT is SNAT-only with no inbound path, and the gateway does nothing until the private LAN's default route is repointed at it. Add the UDP SNAT rule too, or DNS breaks for those VMs.
Treating the Kubernetes LoadBalancer Service as the cluster's real front door. It is a single-node static IP capped at that node's throughput; the production Layer 7 entry is the separately provisioned ALB, with the in-cluster ingress controller behind it.
Placing the Kubernetes control plane in a US datacenter for this regulated workload. Choose the Frankfurt control plane so control-plane data stays in Germany; node-pool data stays in the chosen region regardless.
Connecting a private LAN to the internet "to test", or trying to wrap a managed ALB or NLB in a Network Security Group. The managed balancers have no NSG; the data tier's safety comes entirely from living on a private LAN, so a single internet connection on the data LAN dismantles the compliance argument.
Giving the PostgreSQL cluster or the cache an address inside the DHCP range. Reuse the LAN's first three octets and pick an address DHCP never assigns (ending .3 to .10); a collision produces intermittent, hard-to-diagnose connection failures.
Mismatching the VPN phase-1 or phase-2 parameters between the IONOS gateway and the corporate peer, or looking for an IKEv1 option. There is no IKEv1; the parameters must match exactly on both ends or the tunnel never establishes, and the HA pair presents one shared IP to the peer.

Summary

The FinCorp core is now one VDC that realises the layered architecture from Unit 1.2: a public Layer 7 ALB terminating TLS at the edge, a stateless Dedicated Core application tier, a private Layer 4 NLB, and a private-only data tier of a strictly synchronous PostgreSQL cluster fronted by an In-Memory DB cache, with a Managed Kubernetes cluster and the hybrid VPN and NAT gateways attached. The lesson of the capstone is not any single field value; those were established in the per-module builds. It is that an integrated environment is a dependency graph, and that building bottom-up (IPs, then LANs, then compute, then data, then balancers, then containers, then the hybrid edge) is what turns a set of correct individual builds into one coherent, compliant, production architecture.

Key Points:

The build order is a dependency graph: reserve public IPs first, create LANs before anything attaches, provision targets before the balancer that serves them, and repoint the default route before expecting NAT egress.
The data tier never touches a public LAN; segmentation, not an NSG, is what protects the managed balancers and the database, because the managed balancers have no NSG.
The PostgreSQL cluster has no read replica; the In-Memory DB cache is the read-scaling substitution and the externalised state that lets the application tier scale and fail over safely.
The Kubernetes cluster's LoadBalancer Service is a single-node static IP, not the production entry point; the public ALB plus an in-cluster ingress controller is the real Layer 7 front door, and a Frankfurt control plane keeps control-plane data in Germany.
The capstone references each per-module unit rather than repeating it: the lean per-module labs exist so this integration lab can carry the synthesis.