Skip to main content
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

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

On AWS

EC2 Instances

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

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 and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.