> ## 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. # Compute Engine > Compute Engine APIs with Cloud Adapter. This page describes how Compute Engine 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 | | Azure | 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 Compute Engine with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | Compute Engine | AWS | Azure | | ------------ | -------------- | ---- | ----- | | API coverage | full | high | high | ## On AWS ### EC2 Instances | Operation | Area | Support | Depth | Notes | | ---------------------------------------- | --------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | startup-script | Bootstrap | Partial | Most usage | re-expressed as cloud-init user data; a script that reads Google-specific metadata keys is named at the build | | In-guest metadata server | Identity | Partial | Common | Client libraries using the metadata server need its service-account token and instance-attribute endpoints to respond inside the target VM. | | OS Login | Identity | Out of scope | Full surface | The target uses SSH keys instead of OS Login's Google-identity-based guest access. The build identifies this change. | | Custom and golden images | Images | Out of scope | Most usage | Custom images must be rebuilt for the target cloud before they can boot there. | | instances.insert / delete / start / stop | Instances | Supported | Common | The instance becomes an EC2 instance with mapped capacity and a target-compatible image. Its interfaces, public address and disks use target resources; metadata differences are listed below. The build identifies unsupported size or image selections. | | Attached disks | Storage | Supported | Common | boot and data disks become EBS volumes attached to the instance | A Compute Engine instance becomes an EC2 instance with its network interfaces, public address and disks. Applications that obtain service-account credentials or instance attributes from Google's metadata endpoint still need that endpoint to respond inside the VM. ### Lifecycle and operation status The adapter accepts Compute Engine lifecycle calls and applies the requested VM, disk, and network changes to the target. It tracks requested and observed state separately. Wait for the operation to complete before using the machine; accepting the API request does not establish that the guest has booted. ### Boot and metadata dependencies Prepare a target-compatible image and startup configuration. Applications that read Google service-account tokens or instance attributes depend on the corresponding in-guest adapter endpoints as well as adaptations for the services they call. Verify those requests, SSH access, and attached disk contents from inside the running VM. ### Compatibility differences Custom images built for Compute Engine must be rebuilt for EC2. OS Login is not available on the target; guest access uses SSH keys. ## On Azure ### Virtual Machines | Operation | Area | Support | Depth | Notes | | ---------------------------------------- | --------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | startup-script | Bootstrap | Partial | Most usage | re-expressed as cloud-init user data; a script that reads Google-specific metadata keys is named at the build | | In-guest metadata server | Identity | Partial | Common | Client libraries using the metadata server need its service-account token and instance-attribute endpoints to respond inside the target VM. | | OS Login | Identity | Out of scope | Full surface | The target uses SSH keys instead of OS Login's Google-identity-based guest access. The build identifies this change. | | Custom and golden images | Images | Out of scope | Most usage | Custom images must be rebuilt for the target cloud before they can boot there. | | Image selection | Images | Supported | Most usage | Public Google images map to the corresponding Azure marketplace images. | | instances.insert / delete / start / stop | Instances | Supported | Common | The instance becomes an Azure Linux VM with mapped capacity and a target-compatible image. Its interface, public address and disks use target resources; metadata differences are listed below. The build identifies unsupported size or image selections. | | Attached disks | Storage | Supported | Common | boot and data disks become managed disks attached to the machine | A Compute Engine instance becomes an Azure Linux VM with its network interface, public address and disks. Public Google images map to corresponding Azure marketplace images. ### Lifecycle and operation status The adapter accepts Compute Engine lifecycle calls and applies the requested VM, disk, and network changes to the target. It tracks requested and observed state separately. Wait for the operation to complete before using the machine; accepting the API request does not establish that the guest has booted. ### Boot and metadata dependencies Prepare a target-compatible image and startup configuration. Applications that read Google service-account tokens or instance attributes depend on the corresponding in-guest adapter endpoints as well as adaptations for the services they call. Verify those requests, SSH access, and attached disk contents from inside the running VM. ### Compatibility differences Applications using Google's metadata endpoint for service-account tokens or instance attributes still need that endpoint inside the VM. Custom images must be rebuilt for Azure, and OS Login is not available. ## 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.