Unit 2.4: Cost Architecture and FinOps

Introduction

Cloud cost on IONOS is not a billing problem solved after the fact; it is an architectural property decided at design time, when you choose a compute class, a storage tier, a scaling strategy, and a commitment term. Each of those is a lever, and they differ enormously in magnitude: the compute contention choice can move the bill more than every dashboard tweak combined. FinOps here is therefore mostly architecture, with a thin operational layer of allocation and alerting on top. This unit walks the levers in order of impact, sets out how Savings Plans commit spend correctly, and ends by building the one well-documented guardrail, a cost alert, in the Data Center Designer.

1. Compute Contention: The First Cost Lever

The largest single cost decision is how a workload shares physical CPU. Compute Engine offers two CPU use classes: Dedicated Core servers, where the core is Exclusive to the VM, and vCPU servers, where the core is Shared with other tenants. Shared cores are cheaper and are correct for bursty, latency-tolerant, or non-production workloads. Exclusive cores cost more and are correct where performance must be predictable or where isolation is itself a requirement, which for a regulated estate is frequently the case.

This is where deliberate over-provisioning becomes a justified control cost rather than waste. For FinCorp's in-scope, regulated hosts, single-tenancy and predictable performance are compliance and risk inputs, so paying for dedicated cores (and provisioning headroom above the measured baseline) buys isolation and stability that a shared-core saving would undermine. The discipline is to be deliberate: over-provision the hosts that carry compliance or performance obligations, and use shared cores everywhere the workload tolerates contention. Note also that VM Auto Scaling stamps new replicas from a design-time replica template, so a tier that must scale automatically has its per-replica compute shape, and therefore its per-replica cost, fixed at design time, which folds the elasticity decision into the cost decision.

2. Storage Tiering to Access Pattern

Storage cost is set by matching the tier to the access pattern, and the three block tiers carry materially different price points. The published per-GB-per-month prices are:

Two constraints shape the choice beyond price. First, the SSD performance floor: both SSD Standard and SSD Premium volumes require a minimum size of 100 GB to reach full performance, so an undersized SSD volume pays SSD prices without delivering SSD performance, which is a common and avoidable waste on database disks. Second, block storage is not the home for bulk or archive data; Object Storage is the right tier for backups, audit archives, datasets, and cold data, and it is where the Object-Lock archive from Unit 2.3 lives. The pattern is to put hot, latency-sensitive data on appropriately sized SSD, capacity data on HDD, and everything bulk or archival on Object Storage.

3. Scale-Up Versus Cache-Based Scale-Out for the Data Tier

The data tier has a distinctive cost shape because the platform has no read replicas (Unit 1.3 and Module 5). The two ways to handle growing read load have very different economics. Scaling up means buying a larger database instance, which raises a predictable, always-on cost and eventually hits ceilings. Scaling out reads means placing an in-memory cache in front of the relational tier and absorbing read traffic there, which is typically far cheaper per served read and protects the database from being over-sized purely to handle read bursts. For most read-heavy FinCorp workloads, a right-sized database plus a cache tier costs less than a perpetually scaled-up database, and it is also the only horizontal read-scaling path the platform offers. The cost lesson is to size the database for its write and working-set needs and let the cache, not a bigger instance, absorb read growth.

4. Savings Plans: Committing the Floor Correctly

A Savings Plan is a resource-based commitment that trades a fixed term for a discount on Compute Engine Dedicated Core servers, Managed Kubernetes Dedicated Core node pools, and Nextcloud Workspace, covering the Cores and RAM (GB) dimensions. The economics are precise:

Several rules make this safe only if you respect them. A plan reserves billing, not physical capacity, so it never blocks provisioning. Overflow is handled gracefully: usage above the committed quantity is billed at the standard PAYG rate, so over-commitment is the only real risk. When several plans cover the same product, they apply oldest-first (chronologically by creation), and within a product the discount applies oldest-VM-first. The AMD Opteron CPU family is excluded. A plan does not auto-renew, and only a contract owner may purchase one.

The single most important operational fact is that a Savings Plan cannot be edited after activation; the only editable field is the plan name, and it cannot be cancelled after purchase. That makes the commitment a one-way decision, and it dictates the discipline: commit the floor. Commit only the steady-state baseline you are certain to run for the whole term, take the PAYG overflow for everything above it, and lengthen the term only for capacity you are confident persists for three years. Committing optimistically to peak usage locks in spend you cannot edit down; committing the floor captures the discount on guaranteed usage while leaving variable load on flexible PAYG.

5. Allocation, Showback, and Chargeback

Cost allocation rides on the structure from Unit 2.1. Because each VDC already produces its own section on the monthly bill, the contract-and-VDC hierarchy is the primary allocation axis: a contract groups a governance and billing realm, and VDCs within it separate environments or projects into distinct bill lines. The Cost & Usage view in the DCD is the analysis surface for this, and a Cost & Usage API exists to feed billing workflows programmatically.

Allocation supports two operating models. Showback reports each team or project its share of cost for visibility and accountability without moving money. Chargeback actually bills the cost back to the consuming unit. Showback is the lighter-weight starting point and is usually sufficient to change behaviour; chargeback adds financial enforcement at the cost of more billing machinery. For FinCorp, mapping VDCs to projects so each lands on its own bill line gives clean showback immediately, with chargeback layered on later if finance requires it. (Treat the dashboard and allocation navigation as the analysis layer; the build below is the cost-alert guardrail, which is the well-documented create-path.)

DCD Implementation Walkthrough

You will create a cost alert that emails a recipient when contract spend crosses a budget threshold. This is the one well-documented cost build; it is the operational guardrail that backs up the architectural levers above. The prerequisite is contract-owner or administrator access, since only those roles can create cost alerts. Note that the alert is set at the contract level (an amount and an email), so allocation across VDCs is a reporting concern handled in the Cost & Usage view, not in the alert itself.

Build goal: Create a cost alert against a budget threshold.

Steps (in the Data Center Designer):

1. Go to Menu > Management > Cost alert. The Cost alert window opens; this view also lists any existing alerts.
2. Choose Create cost alert.
3. In the dialog, enter the amount (the spending threshold for the contract) and the email address that should be notified.
4. Choose Create cost alert to confirm. The alert is now active and will email the recipient once contract spend exceeds the threshold.

Common mistakes:

• Expecting the alert to cap or stop spend. It only notifies; it is a tripwire, not a hard budget enforcement. Spend continues past the threshold.
• Setting it per VDC. The cost alert is contract-level (amount plus email); use the Cost & Usage view for per-VDC analysis and allocation.
• Relying on alerts instead of architecture. The alert catches drift; the compute class, storage tier, and Savings Plan decisions are what actually set the bill.
• Pointing the alert at a personal mailbox. Send it to a monitored finance or operations address so the notification is seen and acted on.

Architecture Pattern

A defensible FinCorp cost architecture layers the levers by impact. At the base, compute class is chosen per tier: dedicated cores for the in-scope regulated and auto-scaling tiers (with deliberate headroom as a justified control cost), shared cores for tolerant and non-production workloads. Storage is tiered to access pattern, with SSD volumes kept at or above the 100 GB floor and bulk/archive data on Object Storage. The data tier is sized for writes and working set, with an in-memory cache absorbing read growth instead of an oversized database. Over that, a Savings Plan commits only the steady-state dedicated-core and RAM floor on a term matched to genuine persistence, taking PAYG overflow above it. On top, allocation maps VDCs to projects for showback, and a contract-level cost alert provides the drift tripwire. As a worked figure, a tier running a steady 32 dedicated cores would cost about EUR 1.28 per hour at PAYG (32 x 0.04); committing that floor on a 3-year plan brings the core charge to about EUR 0.77 per hour (32 x 0.024), a 40% reduction on the guaranteed baseline, while any burst above 32 cores still bills at PAYG.

Summary

Cloud cost on IONOS is architected, not merely monitored. The compute contention class is the largest lever, with deliberate over-provisioning of in-scope hosts justified as a control cost; storage is tiered to access pattern within the SSD performance floor; and the data tier scales reads through a cache rather than an oversized instance. Savings Plans capture term discounts of 15% (1-year) and 40% (3-year) on dedicated cores and RAM but cannot be edited after activation, which mandates committing only the certain floor and taking PAYG overflow. Allocation rides the contract-and-VDC structure for showback or chargeback, and a contract-level cost alert provides the operational tripwire built in the DCD.

Key Points:

• Compute contention is the first cost lever: shared cores are cheaper, exclusive (dedicated) cores buy predictability and isolation; auto-scaling fixes each replica's compute shape at design time, folding elasticity into the cost decision.
• Tier storage to access pattern: HDD 0.04, SSD Standard 0.07, SSD Premium 0.15 EUR/GB/month; keep SSD volumes at or above the 100 GB full-performance floor; put bulk and archive on Object Storage.
• Scale data-tier reads with an in-memory cache, not an oversized database, since there are no read replicas.
• Savings Plans give 15% (1-year) and 40% (3-year) discounts on dedicated cores and RAM, overflow bills at PAYG, plans apply oldest-first, and they cannot be edited after activation, so commit only the certain floor.
• Allocate by contract and VDC (each VDC already bills as its own line); choose showback or chargeback; a contract-level cost alert (amount plus email) is the build-time guardrail and only notifies, it does not cap spend.

Important Terminology:

• CPU use class: Whether a server's cores are Exclusive (Dedicated Core) or Shared (vCPU); the primary compute cost and performance lever.
• Savings Plan: A resource-based 1-year or 3-year billing commitment on dedicated cores and RAM, with PAYG overflow, not editable after activation, purchasable only by the contract owner.
• Showback / Chargeback: Reporting a team its cost share for accountability (showback) versus actually billing the cost back to it (chargeback).
• Cost alert: A contract-level threshold (amount plus email) that notifies on spend overrun; it warns but does not cap.