Unit 4.3: Elasticity and VM Auto Scaling

Introduction

Elasticity on IONOS has two distinct axes that are decided at different times. Vertical scaling grows a single running VM and is largely a live operation; horizontal scaling adds and removes whole replicas under a metric policy and is the platform's managed elasticity mechanism. The decision that ties the two together is made before either runs: VM Auto Scaling stamps new replicas from a replica template whose compute configuration (CPU architecture, cores, RAM) and storage are set up front, so choosing the managed horizontal path commits the tier's replica design back in Unit 4.1. This unit covers both axes, the anti-flapping controls that keep a scaling group stable, and the stateless precondition that makes horizontal scaling safe, then builds an auto-scaling group and performs a live resize on the FinCorp tier.

1. Vertical Elasticity: Live Vertical Scaling and Its Ceilings

Live Vertical Scaling (LVS) changes a VM's resources after provisioning. On both Dedicated Core and vCPU servers you can hotplug upward (add CPU, RAM, NICs, and storage volumes) while the server runs, which is how you react to a peak quickly without a maintenance window. The boundaries are specific and matter for design:

Upscale is live; downscale is asymmetric. You can live-upscale CPU, RAM, NICs, and storage volumes. You can live-downscale only NICs and storage volumes. Shrinking CPU or RAM requires a restart, so a downscale of compute is a planned operation, not a transparent one.
The RAM hotplug ceiling is 240 GB. RAM hotplugging is automatically disabled when the RAM size exceeds 240 GB. Above that limit, increasing RAM forces the VM to restart each time, which means LVS no longer applies to that dimension.
Windows is more constrained. Windows allows scaling CPU cores live but not RAM, and scaling beyond eight CPU cores requires a reboot. Plan Windows tiers accordingly.

Vertical scaling is the right lever when a single workload simply needs to be bigger and cannot be split, but it has a hard ceiling (a VM cannot exceed the host) and the asymmetric downscale makes it a poor fit for traffic that ebbs and flows. For that, you scale out.

2. Horizontal Elasticity: VM Auto Scaling

VM Auto Scaling is the managed service that launches and terminates whole VM replicas to match load. It currently supports horizontal scaling only: it creates more VMs based on a group's replica configuration rather than resizing existing ones. Two framing facts shape every design that uses it.

The replica configuration is decided up front. A VM Auto Scaling group stamps new VM replicas from a replica template, so the replica's compute shape (CPU architecture, cores, RAM) and storage are design-time decisions made back in Unit 4.1. The supported replica storage types are HDD, SSD Premium, and SSD Standard. VM Auto Scaling is an Early Access feature, and flow logs are not yet supported on auto-scaling replicas, which is a small but real observability gap to note.

Replica configuration applies to new replicas only. The group has a replica template (the VM definition new replicas are stamped from). Changing the template, or manually changing a replica's resources, affects only replicas created after the change; it does not resize the existing fleet. This is the precise sense in which the service does not perform vertical scaling: it does not add cores, RAM, or storage to running VMs. Auto-generated replica names are NAMEs, not server IDs, and cannot be used to retrieve information over the API, so build your operational tooling around the group, not around individual replica identities.

2.1 One Metric Policy, and the Anti-Flapping Controls

A group has exactly one metric policy: you define a single metric whose utilisation triggers scaling. The supported metrics are instance CPU utilisation average (percentage), and incoming/outgoing network bytes and packets. Within that one policy you define a scale-out action and a scale-in action, each with an amount type (Absolute or Percentage) and an amount.

The controls that keep the group from oscillating (flapping between scale-out and scale-in) are not optional niceties; they are the design of a stable group:

The mandatory threshold gap. The scale-in and scale-out thresholds must be separated by at least 40 percentage points. This dead band prevents a single noisy metric reading from triggering a scale-out and an immediate scale-in.
The cooldown. After a scaling action the group waits a cooldown period before acting again. The default is 5 minutes; the minimum is 120 seconds (2 minutes) and the maximum is 24 hours. A cooldown shorter than the time a new replica needs to warm up and start absorbing load is the classic cause of over-scaling.
The per-action batch size. Scale in batches: the recommended maximum is 5 VMs per scaling action, with a recommended group ceiling around 100 replicas and a floor of one replica. The minimum-one floor means there is no scale-to-zero; the group always keeps at least one warm replica.

Configuring a group creates two monitoring alarms automatically (one for scale-in, one for scale-out) according to the policy. Optionally, the replica configuration can reference a Backup Unit so replica VM backups are stored regularly, and it can associate a Managed Application Load Balancer target group (target weight range 1 to 256) so new replicas are automatically added behind the balancer as they appear. That ALB association is what makes a scaling tier usable: without it, new replicas would receive no traffic.

2.2 The Stateless Precondition

Horizontal scaling is only safe if a replica can be created or destroyed without losing user state, because the group adds and deletes whole VMs on its own schedule. That makes statelessness a precondition, not a nice-to-have. Any session or in-process state must be externalised off the replica, which is exactly the job of the In-Memory DB cache tier (Module 5): session and shared state live in the cache, the replicas stay stateless, and the auto-scaling group can churn them freely. This is the same In-Memory tier that Unit 1.3 named as the read-scaling substitution, now doing double duty as the state-externalisation layer that makes auto-scaling clean. A stateful tier (a database, for instance) is never the auto-scaling tier; it is reached through a private Layer 4 balancer and scaled by the data-tier patterns in Module 5.

Design Considerations

Scalability. Decide the scaling axis per tier: vertical for a workload that must be bigger and cannot split (within the 240 GB hotplug ceiling and the restart-bearing CPU/RAM downscale), horizontal for traffic that ebbs and flows. Only the horizontal path is managed, and it stamps new replicas from a design-time replica template.
Reliability. The threshold gap, cooldown, and batch size are the stability controls. A too-short cooldown relative to replica warm-up time is the most common production failure, producing runaway scale-out.
Operations. Replica config changes apply only to new replicas, and replica names are not server IDs, so operate on the group abstraction. The minimum-one floor means budgeting for at least one always-on replica per scaling tier.

DCD Implementation Walkthrough

This walkthrough builds a VM Auto Scaling group for the FinCorp customer-facing application tier (the Dedicated Core tier from Unit 4.1) and then performs a live vertical resize to show the two elasticity axes side by side. The prerequisites are the Dedicated Core replica template (a server definition the group stamps replicas from) and, for traffic distribution, the public Layer 7 Application Load Balancer from Unit 3.3.

Build goal: Configure an auto-scaling group with a metric policy and a live resize.

Steps (in the Data Center Designer):

In the FinCorp VDC, start Create VM Auto Scaling Group. The create window shows an Autoscaling Setup tab and a Replica Configuration tab. Ensure the data center hosting the group has the required resources available.
In Autoscaling Setup, set the group's minimum and maximum replica counts (floor of one; recommended ceiling around 100).
Define the single metric policy. Select the Metric (for the FinCorp app, CPU utilisation average). Set the Scale Out Threshold and Scale In Threshold, keeping them at least 40 percentage points apart.
Define the Scale Out action: amount type (Absolute or Percentage) and amount (the number of replicas to add), keeping the batch at or below the recommended 5 per action.
Define the Scale In action the same way (minimum amount of one).
Set the cooldown (default 5 minutes; minimum 2 minutes, maximum 24 hours) to at least the replica warm-up time, so new replicas can absorb load before the next action.
In Replica Configuration, define the Dedicated Core replica template (cores, RAM, storage from the supported types, and the boot image). Associate the Unit 3.3 ALB target group so new replicas receive traffic (target weight 1 to 256; the ALB forwards to a configurable target port anywhere in the TCP range 1 to 65535, not a fixed port 80). Optionally reference a Backup Unit. Click Create.
To show vertical elasticity, select the underlying Dedicated Core server (or a manually managed VM) in the Workspace and, in the Inspector, increase CPU and RAM. Provision the change: upscale of CPU and RAM is live (below the 240 GB RAM hotplug ceiling), whereas a later CPU/RAM downscale would require a restart.

Common mistakes:

Setting the scale-in and scale-out thresholds closer than 40 percentage points. The mandatory gap is rejected if violated and exists precisely to stop flapping.
A cooldown shorter than replica warm-up time, which causes the group to keep scaling out before the previous replicas take load.
Forgetting to associate the ALB target group, so new replicas appear but receive no traffic.
Expecting a replica-template change to resize the running fleet. It applies only to new replicas; the existing fleet is unchanged.
Scaling a stateful tier. Externalise session/state to the In-Memory cache first; only stateless tiers auto-scale safely.

Architecture Pattern

The standard elastic web tier composes three of this course's threads. The public Layer 7 balancer (Unit 3.3) fronts a Dedicated Core auto-scaling group whose replicas are stateless, with session and shared state held in an In-Memory DB cache on the private network (Module 5). Under load, CPU utilisation crosses the scale-out threshold, the group adds replicas in batches of up to five, the ALB target group picks them up automatically, and the cooldown prevents over-correction; as load falls and crosses the scale-in threshold (at least 40 points lower), replicas are removed down to the one-replica floor. For FinCorp's customer-facing application, this is the tier that absorbs daily traffic swings: the baseline is sized small on Dedicated Core (Unit 4.1), peaks are handled by adding replicas rather than by a permanently large VM, and because the replicas hold no state, the group can churn them without affecting logged-in users.

Summary

IONOS elasticity has two axes decided at different times. Vertical scaling grows a single running VM, live for CPU/RAM/NIC/storage upscale and NIC/storage downscale, with CPU/RAM downscale needing a restart and RAM hotplug disabled above 240 GB. Horizontal scaling via VM Auto Scaling is the managed path, an Early Access feature that stamps new replicas from a design-time replica template, with one metric policy per group, a mandatory 40-point threshold gap, a cooldown from two minutes to 24 hours, batch guidance around five VMs per action, and a one-replica floor (no scale-to-zero). Replica config applies only to new replicas, and the scaled tier must be stateless, with state externalised to the In-Memory cache. The build wires a metric-driven group behind the ALB and shows a live resize alongside it.

Key Points:

Vertical: upscale CPU/RAM/NIC/storage live; downscale only NIC/storage live; CPU/RAM downscale needs a restart; RAM hotplug disabled above 240 GB.
Horizontal Auto Scaling stamps new replicas from a design-time replica template (compute shape and storage), committed back in Unit 4.1.
One metric policy per group; scale-in and scale-out thresholds must differ by at least 40 percentage points; cooldown default 5 minutes (2 minutes to 24 hours); recommended batch up to 5 VMs; floor of one replica, no scale-to-zero.
Replica configuration applies only to new replicas; the service does not resize the running fleet, and replica names are not server IDs.
The auto-scaling tier must be stateless, with session/state externalised to the In-Memory cache; associate an ALB target group so new replicas receive traffic.

Important Terminology:

Live Vertical Scaling (LVS): changing a running VM's resources, live for upscale and for NIC/storage downscale; CPU/RAM downscale and RAM above 240 GB need a restart.
Metric policy: the single rule per auto-scaling group (one metric, a scale-out and a scale-in action) that triggers scaling.
Cooldown: the wait after a scaling action before the next, the primary anti-over-scaling control.
Threshold gap: the mandatory 40-percentage-point minimum separation between scale-in and scale-out thresholds that prevents flapping.

Learning Objectives