VM Auto Scaling is a managed service designed to launch or terminate VM instances horizontally to ensure you have the appropriate number of instances available to handle the load on your application.
You can optimize cost by reducing the number of VMs needed to run in parallel while ensuring your setup does not run into resource limitations.
One of your scaling policies was met. For example, when CPU utilization exceeds the defined threshold, you may check the Auto Scaling logs to see why a scaling action was triggered.
It is a defined group of VMs created from the same image template by the VM Auto Scaling feature.
When you delete the VM instances, all the underlying VMs will be deleted.
The Jobs tab contains information about the scaling operations that the feature initiates. You can view a list of actions triggered by the feature, its status, and when the process started.
If not explicitly configured differently, VM Auto Scaling deletes the oldest VM in your Auto Scaling group first when a scale in action is triggered. Thus changes will be propagated naturally through your group of VMs.
When your VM Auto Scaling Group qualifies for a scale in action according to the metrics you set, the oldest running VM in your group will be stopped. You repeat this process until all VMs are updated.
Currently, VM Auto Scaling only supports horizontal scaling. This means that the feature creates more VMs to support your workload based on the replica configuration of the appropriate group.
Note: The VM Auto Scaling feature does not handle VMs that are not part of a VM Auto Scaling Group. You will need to manually update them.
Although the feature now allows horizontal scaling, you can manually modify the replica configuration of a group. For example, you can increase the resources associated with your VMs, such as CPU cores or the size of the RAM. This notion is identical to vertical scaling (scaling up). After you save the configuration, the replicas created as part of the subsequent scale-out process contain the updated configuration. As mentioned earlier, for this change to propagate to all your VMs, the scaling in policy must be explicitly configured to delete the oldest replicas.
You can choose if the volumes must be retained when a VM is scaled in. Remember that choosing to retain the volumes during scale in process accumulates data over time.
You can combine VM Auto Scaling with an ALB to spread the load evenly across your VMs. You may also use CloudInit to configure your VMs during bootup based on the workload.
A Cross Connect is a feasible alternative to connect replicas on two different subnets. Hence, groups with replicas connected to these subnets will be connected via Cross Connect. Moreover, ensure that you make the necessary configurations as you would for VMs to communicate with one another. The approach is similar to physically connecting two subnets using a network cable.
Yes, the replicas (or VM instances) created as part of the scaling process function in the same way as the IONOS Cloud VMs configured in the VDC. For example, you can configure it with an ALB, Network Load Balancer, NAT Gateway, Managed Kubernetes clusters, and MongoDB clusters.