EC2 Auto Scaling

This page describes how EC2 Auto Scaling maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of EC2 Auto Scaling with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On Akamai and Private Kubernetes

​

VirtualMachinePool

​

How it works

On KubeVirt the ASG compiles to a VirtualMachinePool that runs on the Kubernetes cluster you operate. Unlike the cloud targets, it is self-managed: you run the cluster and its nodes yourself. There is no cloud fleet control plane; the pool reconciles its replicas as full virtual machines scheduled onto your nodes, and live-migration and rescheduling on node drain are the target cluster’s, not a cloud SLA. desired_capacity becomes the pool’s desired replicas count. Scheduling, node capacity and guest health determine how many replicas are ready. Each replica is a full KubeVirt VirtualMachine (a VMI backed by KVM on a node). Autoscaling is optional: the pool exposes a standard scale subresource, so a Kubernetes HorizontalPodAutoscaler can target it to adjust the desired replica count between bounds. Without an HPA the desired count stays fixed.

On KubeVirt the pool runs on the target cluster: the blueprint is embedded in the pool spec, and autoscaling is an optional standard HorizontalPodAutoscaler on the pool’s scale subresource.

​

The virtualMachineTemplate

The blueprint is embedded in the pool spec as its virtualMachineTemplate: a full VirtualMachine spec nested inside the pool, not a separate resource and not a cloud template artifact. The ASG’s instance definition (from a launch template, a legacy launch configuration, or a mixed-instances policy) compiles into that template: the domain (CPU and memory), disks and volumes, networks, and the boot image. Every replica the pool reconciles is stamped from it. Each replica is a VM: it gets its disks, its cluster networking, and the read-only metadata surface a workload expects, running under KVM on one of your nodes. A workload that reads its own identity or discovers its topology on startup runs unchanged on every replica.

• Desired replicas: desired_capacity becomes the pool’s requested replicas count; readiness follows scheduling and health checks.
• Self-managed availability: live-migration and rescheduling on node drain are the target cluster’s, not a cloud single-instance SLA.

The blueprint is embedded in the pool spec as its virtualMachineTemplate, a full VirtualMachine spec nested inside the pool, and every replica is stamped from it as a full VM.

​

Autoscaling with an HPA

Unlike the cloud targets, there is no dedicated autoscaler resource. The pool exposes a scale subresource, and scaling is done (if you want it) with a standard Kubernetes HorizontalPodAutoscaler whose scaleTargetRef points at the pool. min_size/max_size become the HPA’s minReplicas/maxReplicas, and a CPU/utilization target maps to the HPA’s CPU or memory metric (served by metrics-server on your cluster). Metric definitions and evaluation timing follow Kubernetes. If no HPA is declared, the desired replicas count stays fixed; it does not guarantee that every replica is ready.

• Optional HPA on the scale subresource: a standard HorizontalPodAutoscaler targets the pool; without one the desired replica count stays fixed.
• Bounds → HPA min/max. min_size/max_size become the HPA’s minReplicas/maxReplicas.
• Pod-level metrics. CPU/memory target-tracking is served by metrics-server on your self-managed cluster, not by a cloud autoscaler.

△ Auto Scaling differences

• Autoscaling is opt-in and self-operated: scaling requires a declared HorizontalPodAutoscaler and pod-level metrics on the target cluster. Without an HPA the desired count stays fixed. Running replicas still depend on available capacity and health.

An optional HorizontalPodAutoscaler adjusts the pool’s desired count through its scale subresource. Without one, that desired count stays fixed; ready capacity still depends on scheduling and health.

​

Placement, health, and self-healing

Placement is the Kubernetes scheduler’s job, not a cloud fleet’s. The pool’s VMs are scheduled onto your nodes, and across-zone or across-node spread comes from the scheduling rules you set: pod anti-affinity or topology-spread constraints against your nodes’ zone or hostname labels. There is no cloud availability zone unless your nodes span zones and are labeled for it. Each selected zone also needs enough schedulable capacity for the requested VMs. The pool reconciles toward its desired replica count: a VM that is deleted or whose node is lost needs replacement capacity. The number of running or ready VMs can lag behind replicas. Liveness checks identify failed guests for recovery; readiness checks remove unready guests from service. All of this runs on the cluster you operate, so the resilience is the target cluster’s, not a cloud SLA.

• Scheduler-driven spread: across-zone/node spread comes from pod anti-affinity or topology-spread constraints against your nodes’ labels, not from a cloud fleet’s zonal distribution.
• Desired capacity is reconciled: replacing a deleted or node-lost VM requires schedulable capacity; check running and ready counts separately.
• Health via probes: liveness checks identify failed guests for recovery; readiness checks remove unready guests from service.

△ Auto Scaling differences

• Spread and availability are the target cluster’s: multi-zone resilience exists only if your nodes span zones and your scheduling rules place replicas across them; there is no cloud AZ guarantee, and node-drain rescheduling is the cluster’s behavior, not a cloud SLA.

​

Updates, lifecycle hooks, and warm pools

VirtualMachinePool does not provide the following Auto Scaling group features.

• No managed rolling replacement: the pool is not a Deployment; a template change applies to reconciled replicas but there is no built-in batched rolling-upgrade policy like the ASG’s instance refresh.
• Lifecycle hooks: no analog: the ASG’s launch/terminate lifecycle hooks have no VirtualMachinePool equivalent.
• Warm pools: no analog: there is no pre-initialized, stopped-VM pool.
• Mixed-instances / Spot: not applicable: there is no cloud instance market; a replica’s size is the template’s, on your own nodes.

△ Auto Scaling differences

• ASG-proprietary orchestration is not reproduced: instance refresh, lifecycle hooks, warm pools, and mixed-instances/Spot assume a cloud fleet control plane the pool does not have; the fleet’s size and optional HPA scaling are preserved, that orchestration is not.

​

Limitations

The pool, its embedded template, and optional HPA scaling map directly on the cluster you operate. Two considerations frame how the running fleet behaves after cutover. △ Auto Scaling differences

• Declare scaling changes in infrastructure code: runtime SetDesiredCapacity and scaling-policy mutations are outside this mapping. Unsupported infrastructure settings can be reported during the build; unsupported SDK requests return an error when called.
• Sizing and operation are yours. Tensor9 provisions the pool and, if declared, the HPA at build time; the actual scaling decisions run against metrics-server on the cluster you operate, so both the sizing cadence and the cluster’s health are your responsibility rather than a cloud platform’s.

​

Other considerations

Plan persistent storage, instance costs, and updates before deployment.

• Instances are replaced, not repaired: the pool recreates an unhealthy VM, so surviving state lives on PersistentVolumes or external storage, not the VM’s ephemeral disk.
• Scaling and operation run on the cluster you own: the build provisions the pool and, if declared, an HPA; scaling decisions run against metrics-server on your cluster, so both the cadence and the cluster’s health are yours to operate.
• The pool consumes cluster capacity: the VM pool consumes your cluster’s own compute, so the fleet’s size is bounded by the capacity you run rather than a cloud autoscaling budget.
• Plan replacement of existing VMs. The pool applies virtualMachineTemplate changes when it creates replicas; it has no built-in batched rolling-upgrade policy.

​

Fleet management scope

The fleet runs as a KubeVirt VirtualMachinePool with the horizontal pod autoscaler’s sizing controls. See fleet lifecycle and runtime management for logical group discovery/deletion and higher-level ownership. Desired-capacity and policy changes use infrastructure-as-code or the owning service; native readiness, placement and replacement follow this target’s controls above.

​

On Azure

​

Virtual Machine Scale Sets

​

How it works

On Azure, Tensor9 translates the Auto Scaling group into a Virtual Machine Scale Set. The scale set contains the VM configuration: the sku (machine size), the source image, the OS and data disks, the network interface, and the managed identity, alongside the instances count. desired_capacity becomes the scale set’s desired instance count. Ready capacity follows allocation, startup and health checks. The ASG’s zonal spread lands as the scale set’s zones. Scaling is handled by a separate azurerm_monitor_autoscale_setting that targets the scale set; Azure keeps the sizing policy in its own resource rather than on the fleet.

On Azure the blueprint is not a separate resource; it lives inline in the scale set body. Scaling is a separate autoscale setting with metric rules that targets the scale set.

​

The VM configuration

The ASG’s instance definition (from a launch template, a legacy launch configuration, or a mixed-instances policy) is folded directly into the scale set’s own VM profile. There is no separate blueprint artifact to reference; the machine size, translated boot image, disks, subnet and security rules, and identity are fields on the scale set itself, and every instance the scale set brings up boots from that inline model through the same instance mapping as a standalone Azure VM. Each instance is a VM with its own disks, network placement, identity, and read-only metadata surface: a workload that reads its own identity or discovers its topology on startup runs unchanged on every instance.

• Desired instance count: desired_capacity sets the requested count; allocation and health checks determine ready capacity.
• Zonal spread is preserved: the ASG’s subnets map to the scale set’s zones across availability zones.

△ Auto Scaling differences

• Blueprint and fleet are edited together: because the VM model is inline, the blueprint and the scale set are one resource; a model change updates existing instances through the scale set’s upgrade policy rather than versioning a standalone artifact.

There is no separate template resource on Azure: the ASG’s instance definition folds into the scale set’s own inline VM model, and every instance boots from it.

​

The autoscale setting

Scaling lives on a separate azurerm_monitor_autoscale_setting whose target_resource_id is the scale set. Its profile sets the capacity minimum/maximum (from min_size/max_size) and a set of metric rules. This is the Azure-specific shape: rather than a single target value, a CPU-utilization target-tracking policy maps to a scale-out rule and a scale-in rule on a metric such as Percentage CPU. The translated rules retain the utilization-metric intent; evaluation windows, cooldowns and resulting scale timing follow Azure’s autoscaler. A utilization target alone does not determine both thresholds: review the scale-out threshold, scale-in threshold and cooldown for the workload. Diagram thresholds are illustrative.

• Separate autoscale setting: capacity bounds and rules live on the monitor autoscale setting that targets the scale set.
• Target-tracking → a rule pair: a CPU/utilization policy maps to a scale-out and a scale-in rule on the same metric.
• Custom metrics can require a different trigger: a policy on a custom or ASG-specific metric maps to the nearest supported metric trigger where there is no exact equivalent.

△ Auto Scaling differences

• Target-tracking becomes rule-based: the autoscale setting expresses scaling as scale-out / scale-in rules on a metric rather than a single continuous target value; a CPU/utilization policy becomes an equivalent rule pair, but the rule model is Azure’s, not the ASG’s.

Scaling is a separate autoscale setting: capacity bounds plus a rule pair (a scale-out rule and a scale-in rule on a metric) that expresses the target-tracking intent in Azure’s rule model.

​

Placement, health checks, and self-healing

The ASG’s multi-subnet vpc_zone_identifier maps to the scale set’s zones, and the scale set spreads its instances across those availability zones and, within a zone, across fault domains. The across-zone footprint the ASG was deployed for holds. Self-healing maps to the scale set’s automatic instance repair (automatic_instance_repair): with an application health probe configured, an instance the probe marks unhealthy is repaired (reimaged or replaced) after a grace period, the same intent as the ASG’s health-check replacement. Which instance is removed on scale-in is governed by the scale set’s scale_in rule (Default / NewestVM / OldestVM), a partial analog to the ASG’s termination policies.

• Zones plus fault domains: the ASG’s subnets map to the scale set’s zones; instances spread across availability zones and fault domains.
• Automatic instance repair: with a health probe configured, an unhealthy instance is repaired after a grace period, the ASG’s health-check replacement in Azure’s terms.
• Scale-in ordering only partly survives: the scale set’s scale_in rule chooses which instance to remove, a partial analog to the ASG’s termination policies.

△ Auto Scaling differences

• Autorepair needs a health probe: automatic instance repair only replaces an unhealthy instance when an application health probe (or the health extension) is configured; without one, the scale set maintains its count but does not act on application health.

​

Updates, lifecycle hooks, and warm pools

The scale set supports rolling upgrades. Other Auto Scaling group features have the following limits.

• Rolling replacement holds: a model update can use the scale set’s rolling_upgrade_policy to replace instances in batches. This provisioning behavior does not implement the AWS StartInstanceRefresh API.
• Spot works; the mix narrows: instances can run at Spot priority, but the ASG’s mixed-instances distribution across several instance types with an allocation strategy has no direct scale-set analog.
• Lifecycle hooks: no direct analog: the ASG’s pause-and-continue launch/terminate hooks have no scale-set equivalent (scheduled-event / terminate notifications are close but not the same pause-for-a-custom-action mechanism).
• Warm pools: no analog: there is no pre-initialized, stopped-instance pool on the scale set.

△ Auto Scaling differences

• Lifecycle hooks and warm pools are not reproduced: these ASG mechanisms have no scale-set analog; the fleet’s size, autoscaling, and rolling upgrade are preserved, that orchestration is not.

​

Limitations

The scale set, its inline model, its zonal spread, and automatic instance repair map directly. Two considerations frame how the running fleet behaves after cutover. △ Auto Scaling differences

• Declare scaling changes in infrastructure code: runtime SetDesiredCapacity and scaling-policy mutations are outside this mapping. Unsupported infrastructure settings can be reported during the build; unsupported SDK requests return an error when called.
• Sizing decisions belong to the autoscale setting. Tensor9 provisions the scale set, its capacity bounds, and its metric rules at build time; when Azure Monitor actually adds or removes an instance is the autoscale setting’s decision, evaluated on Azure’s own metrics and cadence, not something Tensor9 sizes at runtime.

​

Other considerations

Plan persistent storage, instance costs, and updates before deployment.

• Instances are replaced, not repaired: automatic instance repair recreates an unhealthy VM, so surviving state lives on attached managed disks or a storage account, not the instance’s OS disk.
• Runtime scaling is Azure’s decision: the build provisions the scale set, its capacity bounds, and its metric rules; the Azure Monitor autoscale setting decides when to add or remove an instance on Azure’s own metrics and cadence.
• Costs depend on the running instances. VM charges follow actual running instances, including temporary replacement capacity, plus storage, networking and other target charges. Desired-capacity bounds are not an enforced spending cap.
• A model change is a rolling upgrade: the launch template maps to the scale set’s inline VM model, and a change rolls the instances, the same immutable-fleet update model the Auto Scaling group used.

​

Fleet management scope

The fleet runs as an Azure Virtual Machine Scale Set with the autoscale setting’s sizing controls. See fleet lifecycle and runtime management for logical group discovery/deletion and higher-level ownership. Desired-capacity and policy changes use infrastructure-as-code or the owning service; native readiness, placement and replacement follow this target’s controls above.

​

On DigitalOcean

​

Droplet Autoscale Group

​

How it works

On DigitalOcean, Tensor9 translates the Auto Scaling group into one digitalocean_droplet_autoscale resource. A config block holds the scaling policy, an embedded droplet_template block holds the blueprint, and the group runs the droplets itself. desired_capacity, min_size, and max_size map into the config block, and the ASG’s instance definition maps into the droplet_template. There is no separate template resource and no separate autoscaler resource to wire together.

On DigitalOcean everything is one resource: the scaling policy, the droplet blueprint, and the running droplets all live inside a single digitalocean_droplet_autoscale group.

​

The Droplet template

The blueprint is the group’s embedded droplet_template block. The ASG’s instance definition (from a launch template, a legacy launch configuration, or a mixed-instances policy) maps into it: the droplet size, the translated image, the region, SSH keys, the VPC, tags, and user data. Every droplet the group launches boots from that template, so each is a full droplet with its own disk, VPC networking, and metadata. Because the whole blueprint is one block inside the group, there is no standalone template artifact to version or reference; the group and its blueprint are edited together.

• Embedded template block: the blueprint is the group’s droplet_template, not a separate resource.
• Droplet configuration: size, image, VPC, SSH keys, tags, and user data map from the ASG’s instance definition.
• Every droplet is full: each replica boots from the template with its own disk, networking, and metadata.
• Single region: the template names one DigitalOcean region; the fleet runs there (see placement).

The blueprint is the group’s embedded droplet_template block, with no standalone artifact, and every droplet boots from it; the group and its blueprint are edited together.

​

The autoscale policy

Scaling is the group’s own inline config block, not a separate resource. min_size/max_size become min_instances/max_instances, and a CPU/utilization target-tracking policy maps to the config’s target_cpu_utilization (or target_memory_utilization) with a cooldown_minutes. A fixed min == max becomes a static pool (a fixed target_number_instances). The common CPU-utilization case applies over directly.

• Inline policy: bounds and target utilization live in the group’s own config block, not a separate autoscaler.
• CPU / memory target-tracking maps over: the same target utilization drives scale-out and scale-in, with a cooldown.
• Custom metrics can require a different trigger. DO autoscale tracks CPU and memory utilization; a policy on a custom or ASG-specific metric narrows to the nearest of those.

△ Auto Scaling differences

• Only CPU and memory utilization: the config tracks CPU and memory; a scaling policy on a custom or ASG-specific metric has no direct target and narrows to the nearest of the two.

Scaling is the group’s own inline config block: min/max instances plus a target CPU or memory utilization with a cooldown; a fixed min==max becomes a static pool.

​

Placement and health

The droplet-autoscale group diverges most from the ASG on placement and health. A group’s droplet_template names one DigitalOcean region, so the fleet runs in that single region rather than spreading replicas across availability zones the way the ASG’s vpc_zone_identifier does across the other targets. Multi-region resilience needs a second group. The group holds its size between the bounds toward the target metric, replacing a droplet that is lost to maintain the count, but scaling is metric-driven: there is no ASG-style application health check that replaces a running-but-unhealthy droplet. Infrastructure-level droplet health is DigitalOcean’s; application-health replacement is not part of the autoscale policy.

• Single region: the group’s droplet_template runs in one region; there is no across-zone spread within the group.
• Count is maintained: a lost droplet is replaced to hold the group’s size between the bounds.
• Metric-driven, not health-driven: scaling responds to CPU/memory utilization; DigitalOcean manages droplet-level health at the infrastructure layer.

△ Auto Scaling differences

• Single-region, not multi-AZ: a droplet-autoscale group runs in one region rather than spreading replicas across availability zones the way the other targets do; multi-region resilience needs a second group.
• No application-health autohealing: the group maintains count and scales on CPU/memory; a running-but-unhealthy droplet is not replaced by an application health check the way an ASG with ELB health checks would.

​

Updates, lifecycle hooks, and warm pools

Droplet autoscale groups do not provide the following Auto Scaling group features.

• No managed rolling replacement: a template change applies to droplets launched afterward; there is no built-in instance-refresh that rolls the running group in batches.
• Lifecycle hooks: no analog: the ASG’s launch/terminate lifecycle hooks have no droplet-autoscale equivalent.
• Warm pools: no analog: there is no pre-initialized, stopped-droplet pool.
• Mixed-instances / Spot: no analog: the template names one droplet size; there is no multi-type or spot allocation strategy.

△ Auto Scaling differences

• ASG-proprietary orchestration is not reproduced: instance refresh, lifecycle hooks, warm pools, and mixed-instances/Spot have no droplet-autoscale analog; the group’s size and CPU/memory autoscaling are preserved, that orchestration is not.

​

Limitations

The group, its embedded template, and its inline policy map directly. Two considerations frame how the running fleet behaves after cutover. △ Auto Scaling differences

• Declare scaling changes in infrastructure code: the fleet’s size and bounds are declared in your infrastructure-as-code; runtime SetDesiredCapacity and scaling-policy API calls are out of scope and surface at build time rather than silently at runtime.
• Sizing decisions belong to the group’s policy. Tensor9 provisions the group, its bounds, and its target utilization at build time; when DigitalOcean actually adds or removes a droplet is the group’s decision, evaluated on its own utilization metric and cooldown, not something Tensor9 sizes at runtime.

​

Other considerations

Plan persistent storage, instance costs, and updates before deployment.

• Instances are replaced, not repaired: the autoscale group replaces a lost Droplet, so surviving state lives on attached volumes or Spaces, not the droplet’s local disk.
• Runtime scaling is DigitalOcean’s decision: the build provisions the group, its bounds, and its target utilization; the group decides when to add or remove a droplet on its own utilization metric and cooldown.
• Costs depend on the running Droplets: you pay for the droplet size across the running instances, and the group’s bounds set the floor and ceiling of that spend.
• Update existing Droplets separately. A template change applies to Droplets launched afterward; it does not roll the running group in batches.

​

Fleet management scope

The fleet runs as a DigitalOcean Droplet autoscale group with the autoscale group’s sizing controls. See fleet lifecycle and runtime management for logical group discovery/deletion and higher-level ownership. Desired-capacity and policy changes use infrastructure-as-code or the owning service; native readiness, placement and replacement follow this target’s controls above.

​

On Google Cloud

​

Managed Instance Group

​

How it works

On AWS an aws_autoscaling_group packs the fleet and its instance blueprint into one resource. On Google Cloud that same fleet compiles to three resources: a google_compute_instance_template (the immutable blueprint) feeds versions into a google_compute_region_instance_group_manager, the regional MIG that runs the replicas, and a separate google_compute_region_autoscaler holds the size bounds and the scaling metric and drives the MIG. desired_capacity becomes the MIG’s desired target_size. Ready capacity follows allocation, startup and health checks. min_size and max_size become the autoscaler’s min_replicas/max_replicas. Because the MIG is regional, it spreads its replicas across the zones of the region on its own and recreates any replica that fails a health check, so the multi-AZ resilience the ASG was deployed for is preserved by the MIG itself.

On Google Cloud the ASG splits into three resources: a standalone instance template, the regional MIG that runs the replicas, and a separate regional autoscaler that drives the MIG’s size.

​

The instance template

Google Cloud stores the instance settings in a separate, immutable template. The ASG’s instance definition (from a launch template, a legacy launch configuration, or a mixed-instances policy) compiles to a standalone google_compute_instance_template that defines the machine type, the translated boot image, disks, network placement, and the workload identity (service account). The MIG references it by version. Because instance templates are immutable, a change to the blueprint is a new template plus a rolling replacement driven by the MIG’s update policy, never an in-place edit of a running instance. Every replica the MIG brings up boots from that template through the same instance mapping as a standalone Compute Engine VM, so each is a full instance with its own disks, subnet, security rules, identity, and read-only metadata surface.

The ASG’s instance definition maps to one standalone, immutable instance template; the MIG references a version of it and stamps every replica from that version.

​

The regional autoscaler

Scaling lives on a separate google_compute_region_autoscaler that targets the MIG; it is not a field on the fleet. Its autoscaling_policy holds the min_replicas/max_replicas bounds and the trigger. A CPU- or load-balancing-utilization target-tracking policy retains its utilization target; evaluation windows and scale-out and scale-in timing follow Google’s autoscaler. A fixed min_size == max_size becomes a fixed-size MIG the autoscaler never resizes.

• Separate autoscaler resource: min_size/max_size live on the region autoscaler that targets the MIG, not on the fleet body.
• CPU / LB utilization maps over: the utilization target is preserved; scaling timing follows Google’s autoscaler.
• Custom-metric autoscaling: the autoscaler also supports a custom Cloud Monitoring metric, so a policy on a supported custom metric maps directly; an ASG-specific metric with no equivalent narrows to the nearest supported trigger.

△ Auto Scaling differences

• Some custom metrics use a different trigger. CPU and load-balancing utilization become target-tracking; a policy on a custom metric maps where the autoscaler has an equivalent Cloud Monitoring metric, otherwise it is narrowed to the nearest supported trigger rather than reproduced exactly.

Scaling is a separate regional autoscaler that targets the MIG: it holds the min/max bounds and the trigger and resizes the MIG, rather than being a field on the fleet.

​

Placement, health checks, and self-healing

Because the MIG is regional, it spreads its replicas across the region’s zones on its own: the ASG’s multi-subnet vpc_zone_identifier maps to the MIG’s distribution_policy_zones, so replicas are distributed across the selected target zones. Self-healing comes across too. The ASG’s health-check-driven replacement maps to the MIG’s auto_healing_policies: a health check plus an initial_delay_sec, and a replica that fails the check is recreated from the current template version. An application health check (an ELB or target-group health check on the ASG) maps to a Compute Engine health check the MIG uses the same way: it replaces a replica that is running but failing its check, not only one that has stopped.

• Regional zonal spread: vpc_zone_identifier maps to distribution_policy_zones; the MIG spreads replicas across the region’s zones.
• Autohealing on a health check: auto_healing_policies recreates a replica that fails its health check, the same intent as the ASG’s health-check replacement.
• Application health survives: an ELB/target-group health check maps to a Compute Engine health check the MIG autohealing acts on, so a running-but-unhealthy replica is replaced, and not only a stopped one.

​

Updates, lifecycle hooks, and warm pools

The MIG supports rolling replacement. Other Auto Scaling group features have the following limits.

• Rolling replacement holds: a template update can use the MIG’s update_policy for proactive rolling replacement. This provisioning behavior does not implement the AWS StartInstanceRefresh API.
• Spot is a template field, not a mix: a replica can run as a Spot VM through the template’s provisioning model, but the ASG’s mixed-instances distribution (multiple instance types with an on-demand/spot allocation strategy) has no MIG analog; a MIG runs one machine type.
• Lifecycle hooks: no analog: the ASG’s launch/terminate lifecycle hooks (pause an instance for a custom action) have no MIG equivalent.
• Warm pools: no analog: there is no pre-initialized, stopped-replica pool on the MIG.

△ Auto Scaling differences

• Lifecycle hooks and warm pools are not reproduced: these ASG orchestration mechanisms have no MIG analog; the fleet’s size, autoscaling, and rolling replacement are preserved, that orchestration is not.
• Mixed-instances distribution narrows to one machine type. Spot is set per replica, but the on-demand/spot allocation across multiple instance types has no equivalent; size the template for the machine type the fleet should run.

​

Limitations

The fleet shape, the template, the regional zonal spread, and health-check autohealing map directly. Two considerations frame how the running fleet behaves after cutover. △ Auto Scaling differences

• Declare scaling changes in infrastructure code: runtime SetDesiredCapacity and scaling-policy mutations are outside this mapping. Unsupported infrastructure settings can be reported during the build; unsupported SDK requests return an error when called.
• Sizing decisions belong to the autoscaler. Tensor9 provisions the MIG, its bounds, and its scaling policy at build time; when the platform actually adds or removes a replica is the region autoscaler’s decision, evaluated on Google Cloud’s own metrics and cadence, not something Tensor9 sizes at runtime.

​

Other considerations

Plan persistent storage, instance costs, and updates before deployment.

• Instances are replaced, not repaired: health-check autohealing recreates an unhealthy VM, so any state that must survive lives on attached persistent disks or an object store, not the instance’s boot disk.
• Runtime scaling is Google Cloud’s decision: the build provisions the MIG, its bounds, and its policy; the region autoscaler decides when to add or remove a replica on Google Cloud’s own metrics and cadence.
• Costs depend on the running instances. VM charges follow actual running replicas, including temporary replacement capacity, plus storage, networking and other target charges. Desired-capacity bounds are not an enforced spending cap.
• A template change uses the target update policy: a new instance-template version can roll replacement replicas through the MIG’s update policy. Batch sizes and health gates follow Google Cloud’s controls, not the AWS StartInstanceRefresh API.

​

Fleet lifecycle and runtime management

A launch template or launch configuration describes each fleet member. The Auto Scaling group supplies desired, minimum and maximum counts; scaling and health policies determine when those members change. The fleet mapping creates the target template, group and relevant autoscaler, instead of treating the template as a standalone VM. Maximum adaptation exposes DescribeAutoScalingGroups, DescribeAutoScalingInstances and DeleteAutoScalingGroup over managed group state. Desired capacity and scaling-policy changes use the owning service’s lifecycle configuration or infrastructure-as-code. When a higher-level service such as EKS owns the physical node pool, its reconciler remains responsible for that pool: the Auto Scaling adapter reads and changes the logical group without introducing a second controller for the same physical resource. The describe calls report the adapter’s managed groups and members. InService and Pending describe whether a member’s configuration has converged. HealthStatus is reported as Healthy; it does not report native probe results or establish application health. Check the owning service and the target’s health checks before relying on a member to serve traffic. DeleteAutoScalingGroup records a deletion request. A group with nonzero desired capacity or members requires ForceDelete=true; physical teardown completes asynchronously through its owner. Rolling replacement, application health and zone distribution still depend on the selected target.

​

On OCI

​

Instance Pool

​

How it works

On OCI, Tensor9 translates the Auto Scaling group into three resources. An oci_core_instance_configuration (the immutable blueprint) is referenced by an oci_core_instance_pool that runs the instances, and a separate oci_autoscaling_auto_scaling_configuration attaches to the pool to drive its size. desired_capacity becomes the pool’s desired size. Ready capacity follows allocation, startup and health checks. The ASG’s zonal spread lands as the pool’s placement_configurations across the region’s availability domains and fault domains . min_size/max_size become the autoscaling configuration’s bounds.

On OCI the ASG splits into three resources: a standalone instance configuration, the instance pool that runs the instances, and a separate autoscaling configuration attached to the pool.

​

The instance configuration

Like the GCP mapping, OCI keeps the blueprint in a separate, immutable resource, but here it is an oci_core_instance_configuration, a saved launch specification. The ASG’s instance definition (from a launch template, a legacy launch configuration, or a mixed-instances policy) compiles to that configuration, capturing the compute shape, the translated image, the VNIC and subnet, and the instance metadata. The pool references it by id. Because the instance configuration is a fixed snapshot of the launch spec, changing the blueprint means a new configuration the pool is pointed at, not an in-place edit. Every instance the pool launches boots from it through the same instance mapping as a standalone OCI Compute instance, so each is a full instance with its own block volumes, VNIC, identity, and read-only metadata surface.

• Placement across AD + FD: the pool spreads instances across availability domains and fault domains for resilience.

△ Auto Scaling differences

• Blueprint changes point at a new configuration: an instance configuration is a fixed snapshot, so editing the blueprint provisions a new configuration and re-points the pool; existing instances are not rewritten in place.

The ASG’s instance definition maps to one standalone, immutable instance configuration (a saved launch spec) which the pool references by id and launches every instance from.

​

The autoscaling configuration

Scaling lives on a separate oci_autoscaling_auto_scaling_configuration attached to the pool. Its policy sets the min_size/max_size bounds. The OCI-specific shape is that its scaling is threshold-based: a CPU- or memory-utilization target maps to threshold rules (scale out above a high threshold, scale in below a low one) with a cooldown, rather than a single continuous target-tracking value. Review both thresholds and the cooldown; one utilization target does not uniquely determine the rule pair. OCI evaluates the configured metrics using its own timing. A fixed min_size == max_size fixes desired capacity, not the number of ready instances.

• Separate autoscaling configuration: bounds and rules live on the autoscaling configuration attached to the pool.
• Threshold rules + cooldown: a CPU/memory target maps to scale-out / scale-in thresholds, not a single continuous target.
• Schedule-based scaling too: the autoscaling configuration also supports a scheduled policy, so a time-of-day capacity plan maps directly where the ASG used scheduled actions.

△ Auto Scaling differences

• Scaling is threshold-based, not continuous target-tracking: a CPU/utilization policy becomes high/low threshold rules with a cooldown; the model is OCI’s step-threshold one, so the exact response curve differs from the ASG’s target-tracking.

Scaling is a separate autoscaling configuration attached to the pool: min/max bounds plus high/low threshold rules and a cooldown, OCI’s step model rather than continuous target-tracking.

​

Placement, health checks, and self-healing

The ASG’s zonal spread maps well: the pool’s placement_configurations spread instances across the region’s availability domains and, within each, across fault domains , and the pool can attach to a load balancer’s backend set so new instances are registered as they come up. Where OCI diverges from the ASG is health-driven replacement. An instance pool maintains its declared size, restoring the count when an instance is terminated or stops, but it does not replace an instance that is running yet failing an application health check the way an ASG with ELB/target-group health checks does. Autoscaling here reacts to metrics, not to health.

• Placement across AD + FD. placement_configurations spread instances across availability domains and fault domains.
• Load-balancer attachment: the pool can register instances into a load balancer backend set as it scales.
• Size is maintained: a terminated or stopped instance is replaced to hold the pool’s declared size.

△ Auto Scaling differences

• No application-health autohealing: the pool restores count when an instance is terminated, but a running-but-unhealthy instance is not automatically replaced the way an ASG’s ELB/target-group health check would; application-health replacement is not an instance-pool feature.

​

Updates, lifecycle hooks, and warm pools

Instance pools do not provide the following Auto Scaling group features.

• No managed rolling replacement: updating the instance configuration affects instances launched afterward; there is no built-in instance-refresh that rolls the existing pool to the new configuration in batches.
• Lifecycle hooks: no analog: the ASG’s launch/terminate lifecycle hooks have no instance-pool equivalent.
• Warm pools: no analog: there is no pre-initialized, stopped-instance pool.
• Mixed-instances distribution: no analog: the pool launches one instance configuration; the ASG’s multi-type on-demand/spot allocation strategy is not reproduced.

△ Auto Scaling differences

• ASG-proprietary orchestration is not reproduced: instance refresh, lifecycle hooks, warm pools, and the mixed-instances distribution have no instance-pool analog; the fleet’s size, placement, and metric/schedule autoscaling are preserved, that orchestration is not.

​

Limitations

The three resources, the instance configuration, and the AD/FD placement map directly. Two considerations frame how the running fleet behaves after cutover. △ Auto Scaling differences

• Declare scaling changes in infrastructure code: runtime SetDesiredCapacity and scaling-policy mutations are outside this mapping. Unsupported infrastructure settings can be reported during the build; unsupported SDK requests return an error when called.
• Sizing decisions belong to the autoscaling configuration. Tensor9 provisions the pool, its bounds, and its threshold policy at build time; when OCI actually adds or removes an instance is the autoscaling configuration’s decision, evaluated on OCI’s own metrics and cooldowns, not something Tensor9 sizes at runtime.

​

Other considerations

Plan persistent storage, instance costs, and updates before deployment.

• Instances are replaced, not repaired: the pool replaces a terminated or stopped instance, so surviving state lives on attached block volumes or Object Storage, not the instance’s boot volume.
• Runtime scaling is OCI’s decision: the build provisions the pool, its bounds, and its threshold policy; the autoscaling configuration decides when to add or remove an instance on OCI’s own metrics and cooldowns.
• Costs depend on the running instances. Compute charges follow actual running instances, including replacement capacity, plus storage, networking and other target charges. Desired-capacity bounds are not an enforced spending cap.
• Update existing instances separately. A new instance configuration applies to instances launched afterward. The pool has no managed rolling replacement for existing instances.

​

Fleet management scope

The fleet runs as an OCI Instance Pool with the autoscaling configuration’s sizing controls. See fleet lifecycle and runtime management for logical group discovery/deletion and higher-level ownership. Desired-capacity and policy changes use infrastructure-as-code or the owning service; native readiness, placement and replacement follow this target’s controls above.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.