Unit 8.1: Architecture Decision Frameworks

Introduction

By this point in the course every primitive has been examined in depth. This unit does not re-teach them. It is a reference artifact: a set of selection matrices you return to when a FinCorp tier needs a decision and you want the differentiating criterion, the hard constraint that can disqualify a choice outright, and the unit that derives the reasoning, all in one place.

Read each matrix the same way. The differentiating criteria narrow the field. The hard eligibility constraints are absolute: a single failed constraint removes an option no matter how well it scores elsewhere. Sovereignty and attestation scope are applied last, over the whole design, because compliance narrows choices rather than originating them. The unit closes on the two ways a technically sound design still fails: pairing primitives that do not compose, and placing a functionally correct service outside the attestation scope the workload requires.

1. Compute Class Selection

The compute decision is a four-axis split across core isolation, CPU-family control, block-storage attachment, and the operational model. The constraint that disqualifies most often is the permanent one: a Cube's template is immutable after provisioning, so a tier whose shape or scaling needs may change is designed onto a class that can be reconfigured. VM Auto Scaling itself is horizontal-only and stamps new replicas from a design-time replica template.

Class	Differentiating criterion	Hard eligibility constraint	Derived in
Dedicated Core	Exclusive physical core; selectable and changeable CPU family	CPU-family change requires a restart, not a live operation	Unit 4.1, 4.3
Shared vCPU	Lowest cost	No CPU-family selection; shares physical cores, so no isolation guarantee under contention	Unit 4.1
Cubes (fixed-template instances)	Fixed vCPU/RAM/NVMe template at a fixed price	The bundled NVMe volume cannot be detached; the template itself is immutable. Cubes can still attach up to 23 add-on Block Storage devices, so this is a template trap, not a storage dead-end	Unit 4.1
Private Cloud (dedicated VMware)	Single-tenant managed VMware SDDC with included licensing	Provisioned self-service and on demand, vertically scaled by adding hosts; minimum three hosts per cluster	Unit 4.4

The pattern is class-per-tier: a stateless application tier that scales out takes Dedicated Core, a fixed-size utility node takes a Cube, a regulated single-tenant workload takes Private Cloud. Do not standardise one class across every tier.

2. Container Platform Selection

The container decision turns on who carries the control-plane lifecycle and the compliance burden. Only one option places that burden on IONOS.

Platform	Differentiating criterion	Hard eligibility constraint	Derived in
Managed Kubernetes	Free managed control plane; IONOS carries control-plane lifecycle; node pools billed as Compute Engine	A LoadBalancer Service is not a true external load balancer (a static IP on one ingress worker node, capped at that node's public throughput); a separate Managed ALB/NLB is provisioned for real ingress. No scale-to-zero; the autoscaling floor is one warm node	Unit 6.1, 6.2
Red Hat OpenShift	Full OpenShift platform, customer-deployed on IONOS Cloud infrastructure	Not an IONOS managed service; cluster lifecycle sits with the customer as a Red Hat CCSP partner. Red Hat validation is required before production	Unit 6.4
SUSE Rancher Prime	Rancher multi-cluster management on IONOS compute	Self-managed delivery; not managed by IONOS; SUSE bills the licences (bring-your-own-subscription)	Unit 6.4

For FinCorp's container estate the differentiator is operational burden: Managed Kubernetes is the default because IONOS owns the control plane, and the customer-deployed alternatives are chosen only when an OpenShift or Rancher contract or skill base already exists.

3. Storage Tier Selection

Storage is matched to access pattern. The recurring hard constraint is the SSD performance floor and the zone asymmetry between compute and storage.

Tier	Differentiating criterion	Hard eligibility constraint	Derived in
Block Storage HDD	Lowest cost per GB; single-VM attachment	Single-VM device; not shared; not a backup mechanism	Unit 5.1, 4.2
Block Storage SSD Standard / Premium	Higher IOPS and throughput per GiB; single-VM attachment; up to 4096 GB per volume	SSD Standard below 100 GB does not reach full performance, so it is unsuitable as a small database volume	Unit 5.1, 7.3
NFS (managed shared file)	Concurrent multi-client mount within a region	Regional and private; not available in every location (for example DE/FRA/2 and GB/WOR); active-passive at the service layer	Unit 5.1
Object Storage	S3-compatible bulk, archive, backup target, and audit store; object lock for tamper-evident retention	Not a filesystem; flat namespace with key-and-secret auth; not block-attachable	Unit 5.2

Note the zone asymmetry as a placement constraint: Block Storage offers Zone 1, 2, 3, and Auto, while compute offers only Zone 1, 2, and Auto. A redundant pair pinned to "Zone 3 compute" is not possible because compute Zone 3 does not exist.

4. Database Engine Selection

The database decision is driven by data model first and the replication and continuity model second. Across every managed engine the same boundary holds: there are no read replicas and the Backup Service does not cover managed databases, so read scaling and continuity are composed, not bought.

Engine	Differentiating criterion	Hard eligibility constraint	Derived in
Managed PostgreSQL	Relational; asynchronous (default) or strictly synchronous replication for the lowest RPO	Strictly synchronous needs a minimum of three replicas; no read replicas; private endpoint only	Unit 5.3
Managed MariaDB	Relational; simpler operational profile	Asynchronous replication only (no synchronous option); private endpoint only	Unit 5.3
Managed MongoDB	Document model; sharding for horizontal scale	Sharding is an enterprise-edition capability; no managed change-stream replication; private endpoint only	Unit 5.4
In-Memory DB (cache)	Sub-millisecond read tier; the read-scaling and session-externalisation layer	A cache, not a system of record; private endpoint only	Unit 5.5
Managed Kafka	Event streaming; the application-level change-data-capture substitute	Three brokers; ordering is per partition only; not a database	Unit 5.6

For FinCorp's transactional core, PostgreSQL with strictly synchronous replication answers the low-RPO requirement, the In-Memory DB tier answers read scaling because read replicas do not exist, and Kafka carries change events because there is no managed database change stream.

5. Networking Primitive Selection

Each networking primitive answers a different layer or direction of traffic. The hard constraints here are the most frequent source of incompatible pairings (see Section 7).

Primitive	Differentiating criterion	Hard eligibility constraint	Derived in
Managed ALB	Layer 7 content routing (path, host, header, method, cookie, source-IP) with TLS offloading	HTTP/HTTPS only; no IP allowlisting and no NSG on the managed LB, so filtering belongs on the targets	Unit 3.3
Managed NLB	Layer 4 TCP pass-through; backend keeps the certificate	TCP only; no TLS termination; no NSG on the managed LB	Unit 3.4
NAT Gateway	Outbound egress path for private workloads	SNAT-only, no inbound DNAT; requires a reserved public IP	Unit 3.6
VPN Gateway	Encrypted site-to-site connectivity	IKEv2 or WireGuard only (no IKEv1); active-passive HA sharing one public IP	Unit 3.6
Cross-Connect	Private high-bandwidth interconnect between VDCs	Same region and same contract only; not cross-region; one LAN per connection	Unit 3.6
Network Security Group	Stateful deny-all-by-default filtering at the server NIC	Binds to server NICs only; does not apply to Managed Kubernetes node-pool nodes or suspended Cubes, and never to the managed ALB/NLB	Unit 3.2
Cloud DNS	Anycast resolution and low-TTL record management	No native health-check-based failover; it steers new connections only, and the 60-second minimum TTL is the dominant RTO lever	Unit 3.7

6. The Sovereignty and Attestation Filter

Apply this filter last, over the finished design. Sovereignty and compliance do not originate an architecture; they narrow the set of placements an already-correct design is allowed to use. EU legal sovereignty is a property of operator jurisdiction, not region alone: an EU region of a US-operated provider still carries US CLOUD Act exposure, whereas IONOS is EU-operated.

The attestation scopes differ per service and must never be generalised to "the platform is certified". The two BSI recognitions, both for German data centers, cover different service sets:

Service	BSI C5 (Type 1 attestation, 2023-11-07)	ISO 27001 based on IT-Grundschutz (certificate, 2022-09-14)
Compute Engine	In scope	In scope
Cloud Cubes	In scope	Not in scope
Object Storage	In scope	In scope
Backup	Not in scope	In scope
Managed Kubernetes	Not in scope	In scope

IONOS is the first German cloud provider to hold both the C5 attestation and the IT-Grundschutz certification, but the two scopes are not interchangeable. C5 is an attestation (Testat), Type 1, not a certification and not Type 2. Datacenter-level credentials (for example ISO 27001 at a location, PCI-DSS, Uptime Tier IV) are held by the data-center operator and vary by location; product cert lists in marketing are not contractual. NIS2 is a regulatory obligation, not a held certification.

For FinCorp under GDPR and BSI, residency is a placement decision made before any workload lands: German data centers, EU operator, and every in-scope service validated against the exact attestation its data class requires.

Decision Summary

Use the matrices above as the unit's takeaway artifact. The reading order is fixed:

Narrow by the differentiating criterion for the tier.
Eliminate every option that fails a hard eligibility constraint, before weighing anything else.
Apply the sovereignty and attestation filter last, over the whole design.

7. The Two Composition Errors

A design can pass every per-primitive matrix and still fail. Two errors account for almost all of these.

Pairing incompatible primitives. Two choices that are each correct in isolation do not compose. Putting a Network Security Group "in front of" a Managed ALB or NLB does nothing, because NSGs bind to server NICs and never to the managed load balancer; the filtering has to live on the targets. Expecting inbound traffic through a NAT Gateway fails, because NAT is SNAT-only; inbound publishing belongs to a load balancer or a reserved public IP. Reaching for a Cross-Connect to join two VDCs in different regions fails, because Cross-Connect is same-region and same-contract only. Each is a correct primitive used where its hard constraint forbids it.

A functionally correct choice outside the required attestation scope. A service can do the job perfectly and still be the wrong choice for a regulated workload because it sits outside the attestation that workload requires. Running FinCorp's regulated containerised processing on Managed Kubernetes is functionally sound, but Managed Kubernetes is not in the C5 attestation scope, so a workload that contractually requires C5 must be placed on a C5-covered service such as Compute Engine instead. The choice is not wrong technically; it is wrong against the scope filter, which is exactly why that filter is applied last over the whole design.

Summary

Architecture decisions on IONOS reduce to a repeatable pass: narrow by the differentiating criterion, eliminate on the hard constraints, and apply sovereignty and attestation scope last over the finished design. The matrices in this unit collect those criteria and constraints for compute, containers, storage, databases, and networking so a decision can be made and justified in one place, with the two composition errors as the final cross-check.

Key Points:

Hard eligibility constraints disqualify outright: a single failed constraint removes an option regardless of how well it scores elsewhere.
VM Auto Scaling is horizontal-only and stamps new replicas from a design-time replica template; there are no read replicas; the Backup Service does not cover managed databases. These boundaries decide tiers in advance.
The sovereignty and attestation filter is applied last, because compliance narrows an already-complete design rather than originating it.
C5 and IT-Grundschutz scopes differ per service: Cubes is in C5 but not IT-Grundschutz; Backup and Managed Kubernetes are in IT-Grundschutz but not C5. Never generalise to "the platform is certified".
The two composition errors are pairing primitives whose constraints forbid the pairing, and placing a functionally correct service outside the attestation scope the workload requires.

Important Terminology:

Hard eligibility constraint: an absolute disqualifier (for example a Cube's immutable template, or Managed Kubernetes' lack of scale-to-zero) that removes an option before any weighted criterion is considered.
Attestation scope: the exact set of services a credential covers; on IONOS, C5 and IT-Grundschutz cover different services, and a claim must always be tied to the named service, the German data-center location, the credential, its type, and its date.

Learning Objectives