> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Virtual Machine Scale Sets > Virtual Machine Scale Sets APIs with Cloud Adapter. This page describes how Virtual Machine Scale Sets 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 | Environment | Mapping | | ------------ | ------- | | AWS | API | | Google Cloud | API | 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 Virtual Machine Scale Sets with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | Virtual Machine Scale Sets | AWS | Google Cloud | | ------------ | -------------------------- | ---- | ------------ | | API coverage | full | high | high | ## On AWS ### EC2 Auto Scaling | Operation | Area | Support | Depth | Notes | | ---------------------------------------- | ------ | --------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Autoscale settings | Fleet | Supported | Common | Metric rules are translated into target scaling policies. The build identifies differences in metric availability, statistic, evaluation window and thresholds. Unsupported rules are flagged. | | Inline machine model | Fleet | Supported | Common | The launch template defines the size, image, disks, network interface and identity originally stored in the scale set. | | Overprovisioning | Fleet | Supported | Most usage | The target creates spare instances during scale-out and removes those that fail to start. | | Rolling upgrade and reimage | Fleet | Partial | Most usage | Instance refresh replaces VMs instead of reimaging them in place. Target update controls determine batch size, pauses and readiness checks; the build identifies differences from the source policy. Instance identities change. | | Scale set lifecycle | Fleet | Supported | Common | The scale set becomes a launch template and Auto Scaling group, preserving the desired instance count and minimum and maximum sizes. | | Application health extension | Health | Supported | Most usage | The target uses load-balancer health checks to determine instance health. | | Automatic operating-system image upgrade | Images | Partial | Most usage | Running instances retain their original image when a newer version is published. The build requires acknowledgement if the scale set expects automatic image upgrades. | A scale set becomes an EC2 launch template and Auto Scaling group. The template defines the instance size, image, disks, network interface and identity. Metric rules become scaling policies, and the target provides overprovisioning and load-balancer health checks. ### Capacity changes and update state The adapter applies the source scale-set configuration to the target group and its launch template. Desired count controls capacity; template settings describe how a new instance boots. An updated template does not establish that existing members have changed, so inspect the group's rolling-update state before completing the deployment. ### Readiness and replacement Scaling policies change capacity, while health checks decide when a failed member should be replaced. Check readiness time, batch size, and remaining capacity during updates. A replacement can have a new identity and empty local state; keep durable application data outside disposable fleet members. ### Compatibility differences Rolling upgrades use instance refresh, which replaces instances instead of reimaging them in place. Publishing a newer image does not automatically update running instances. The build requires acknowledgement if the scale set depends on automatic image upgrades. ## On Google Cloud ### Managed Instance Group | Operation | Area | Support | Depth | Notes | | ---------------------------------------- | ------ | --------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Autoscale settings | Fleet | Supported | Common | Metric rules map to an autoscaler on the managed instance group. The build identifies differences in metric availability, statistic, evaluation window and thresholds. Unsupported rules are flagged. | | Inline machine model | Fleet | Supported | Common | The instance template defines the size, image, disks, network interface and identity originally stored in the scale set. | | Rolling upgrade | Fleet | Supported | Most usage | The target performs rolling updates using its own batch, pause and readiness controls. The build identifies differences from the source update policy. | | Scale set lifecycle | Fleet | Supported | Common | The scale set becomes an instance template and managed instance group, with its instance count as the group's target size. | | Application health extension | Health | Supported | Most usage | instance health becomes the group's autohealing policy over a health check, which the target provides directly | | Automatic operating-system image upgrade | Images | Supported | Most usage | Updating the instance template selects the new image version; a rolling update replaces the running instances. | A scale set becomes a Compute Engine instance template and managed instance group. The template defines the VM size, image, disks, network interface and identity. ### Capacity changes and update state The adapter applies the source scale-set configuration to the target group and its instance template. Desired count controls capacity; template settings describe how a new instance boots. An updated template does not establish that existing members have changed, so inspect the group's rolling-update state before completing the deployment. ### Readiness and replacement Scaling policies change capacity, while health checks decide when a failed member should be replaced. Check readiness time, batch size, and remaining capacity during updates. A replacement can have a new identity and empty local state; keep durable application data outside disposable fleet members. ### Compatibility differences Metric rules become an autoscaler, the health extension becomes an autohealing policy, and rolling upgrades use managed instance group rolling updates. New image versions reach running instances through that update process. ## 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.