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 Azure | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------ | ------------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scaling policy (target-tracking / step) | Autoscaling | Partial | Most usage | A supported metric-driven policy maps to the autoscale setting's utilization targets or threshold rules. Review translated thresholds: metric definitions, evaluation windows, cooldowns and scaling timing follow the target autoscaler. Custom or ASG-specific metrics need a supported target trigger; size bounds alone do not create a scaling policy. | | min\_size / max\_size | Autoscaling | Supported | Common | Map to the autoscale setting's bounds on desired capacity; min==max fixes the desired count. These bounds do not guarantee ready capacity or cap temporary replicas during replacement. | | SetDesiredCapacity / runtime scaling-policy mutations | Control plane | Out of scope | Full surface | SetDesiredCapacity and runtime scaling-policy changes are outside this mapping. Set size and bounds through infrastructure-as-code or the owning service's supported lifecycle configuration. The runtime group API separately supports discovery and deletion. | | Fleet provisioning (aws\_autoscaling\_group) | Fleet lifecycle | Supported | Common | your aws\_autoscaling\_group compiles to an Azure Virtual Machine Scale Set, one managed group whose instances use the same configuration | | Lifecycle hooks / instance refresh / warm pools / mixed-instances distribution | Fleet orchestration | Out of scope | Full surface | The AWS StartInstanceRefresh API, lifecycle hooks, warm pools and on-demand/Spot distribution are outside this mapping. Target-native rolling replacement during provisioning is separate and follows the target's documented update policy where supported. | | desired\_capacity | Fleet sizing | Supported | Common | Sets the desired number of replicas using the same launch configuration. Running and ready capacity converge as allocation, scheduling and health checks complete. | | Instance blueprint (launch template / launch configuration / mixed-instances policy) | Instance definition | Supported | Common | the ASG's instance definition (sourced from a launch template, a legacy launch configuration, or a mixed-instances policy) uses the same instance mapping as a standalone Azure Virtual Machine, so every replica inherits the disk, subnet, security groups, identity, and metadata of a single instance | | Instance metadata + identity on every replica | Metadata + identity | Supported | Most usage | each replica gets the same read-only instance-metadata (IMDS) API and workload identity as a standalone instance, so per-replica service discovery and credential lookups keep working | | Multi-AZ placement (vpc\_zone\_identifier) | Placement | Supported | Most usage | The ASG's subnets map to the fleet's selected target zones. Running capacity depends on allocation and health in those zones. | #### 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](/service-adapters/aws/compute-containers/ec2-auto-scaling#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 OCI | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------ | ------------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scaling policy (target-tracking / step) | Autoscaling | Partial | Most usage | A supported metric-driven policy maps to the autoscaling configuration's utilization targets or threshold rules. Review translated thresholds: metric definitions, evaluation windows, cooldowns and scaling timing follow the target autoscaler. Custom or ASG-specific metrics need a supported target trigger; size bounds alone do not create a scaling policy. | | min\_size / max\_size | Autoscaling | Supported | Common | Map to the autoscaling configuration's bounds on desired capacity; min==max fixes the desired count. These bounds do not guarantee ready capacity or cap temporary replicas during replacement. | | SetDesiredCapacity / runtime scaling-policy mutations | Control plane | Out of scope | Full surface | SetDesiredCapacity and runtime scaling-policy changes are outside this mapping. Set size and bounds through infrastructure-as-code or the owning service's supported lifecycle configuration. The runtime group API separately supports discovery and deletion. | | Fleet provisioning (aws\_autoscaling\_group) | Fleet lifecycle | Supported | Common | your aws\_autoscaling\_group compiles to an OCI Instance Pool, one managed group whose instances use the same configuration | | Lifecycle hooks / instance refresh / warm pools / mixed-instances distribution | Fleet orchestration | Out of scope | Full surface | The AWS StartInstanceRefresh API, lifecycle hooks, warm pools and on-demand/Spot distribution are outside this mapping. Target-native rolling replacement during provisioning is separate and follows the target's documented update policy where supported. | | desired\_capacity | Fleet sizing | Supported | Common | Sets the desired number of replicas using the same launch configuration. Running and ready capacity converge as allocation, scheduling and health checks complete. | | Instance blueprint (launch template / launch configuration / mixed-instances policy) | Instance definition | Supported | Common | the ASG's instance definition (sourced from a launch template, a legacy launch configuration, or a mixed-instances policy) uses the same instance mapping as a standalone OCI Compute instance, so every replica inherits the disk, subnet, security groups, identity, and metadata of a single instance | | Instance metadata + identity on every replica | Metadata + identity | Supported | Most usage | each replica gets the same read-only instance-metadata (IMDS) API and workload identity as a standalone instance, so per-replica service discovery and credential lookups keep working | | Multi-AZ placement (vpc\_zone\_identifier) | Placement | Supported | Most usage | The ASG's subnets map to the fleet's selected target zones. Running capacity depends on allocation and health in those zones. | #### 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](/service-adapters/aws/compute-containers/ec2-auto-scaling#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 Private Kubernetes | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------ | ------------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scaling policy (target-tracking / step) | Autoscaling | Partial | Most usage | A supported metric-driven policy maps to the horizontal pod autoscaler's utilization targets or threshold rules. Review translated thresholds: metric definitions, evaluation windows, cooldowns and scaling timing follow the target autoscaler. Custom or ASG-specific metrics need a supported target trigger; size bounds alone do not create a scaling policy. | | min\_size / max\_size | Autoscaling | Supported | Common | Map to the horizontal pod autoscaler's bounds on desired capacity; min==max fixes the desired count. These bounds do not guarantee ready capacity or cap temporary replicas during replacement. | | SetDesiredCapacity / runtime scaling-policy mutations | Control plane | Out of scope | Full surface | SetDesiredCapacity and runtime scaling-policy changes are outside this mapping. Set size and bounds through infrastructure-as-code or the owning service's supported lifecycle configuration. The runtime group API separately supports discovery and deletion. | | Fleet provisioning (aws\_autoscaling\_group) | Fleet lifecycle | Supported | Common | your aws\_autoscaling\_group compiles to a KubeVirt VirtualMachinePool, one managed group whose instances use the same configuration | | Lifecycle hooks / instance refresh / warm pools / mixed-instances distribution | Fleet orchestration | Out of scope | Full surface | The AWS StartInstanceRefresh API, lifecycle hooks, warm pools and on-demand/Spot distribution are outside this mapping. Target-native rolling replacement during provisioning is separate and follows the target's documented update policy where supported. | | desired\_capacity | Fleet sizing | Supported | Common | Sets the desired number of replicas using the same launch configuration. Running and ready capacity converge as allocation, scheduling and health checks complete. | | Instance blueprint (launch template / launch configuration / mixed-instances policy) | Instance definition | Supported | Common | the ASG's instance definition (sourced from a launch template, a legacy launch configuration, or a mixed-instances policy) uses the same instance mapping as a standalone KubeVirt VirtualMachine, so every replica inherits the disk, subnet, security groups, identity, and metadata of a single instance | | Instance metadata + identity on every replica | Metadata + identity | Supported | Most usage | each replica gets the same read-only instance-metadata (IMDS) API and workload identity as a standalone instance, so per-replica service discovery and credential lookups keep working | | Multi-AZ placement (vpc\_zone\_identifier) | Placement | Supported | Most usage | Zone spread requires nodes with zone topology labels, scheduling rules that use them, and schedulable capacity in each selected zone. | #### 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](/service-adapters/aws/compute-containers/ec2-auto-scaling#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. [Service Catalog](/service-adapters/catalog).