Skip to main content
This page describes how Virtual Private Cloud (VPC) 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 Virtual Private Cloud (VPC) with its adaptation on each target. A dash means this profile does not state the capability for that target.

Cloud Adapter

On AWS

VPC

A Google Cloud network and its subnetworks become an AWS VPC and subnets with the same address ranges. Custom routes become route-table entries.

Applying network changes

The adapter handles source network-management requests and saves the requested subnet, route, and firewall configuration. Background work applies the combined configuration to the target cloud. Wait for that work to complete before testing connectivity. Application packets use the target network directly.

Checking effective access

Test both permitted and denied connections, including return traffic, from the intended subnets. Rule direction, priority, and attachment scope matter as well as addresses and ports. Verify DNS and routing alongside firewall rules, then update external allowlists for any changed public addresses.

Compatibility differences

The build rejects networks spanning multiple regions because an AWS VPC is regional. Google firewall rules can use ordered allows and denies, while AWS security groups are unordered and allow-only. If the source rules rely on that ordering, the build requires acknowledgement of their rewritten form.

On Azure

Virtual Network

A Google Cloud network and its subnetworks become an Azure virtual network and subnets with the same address ranges. Azure network security groups preserve the priority ordering and deny rules of the Google firewall configuration.

Applying network changes

The adapter handles source network-management requests and saves the requested subnet, route, and firewall configuration. Background work applies the combined configuration to the target cloud. Wait for that work to complete before testing connectivity. Application packets use the target network directly.

Checking effective access

Test both permitted and denied connections, including return traffic, from the intended subnets. Rule direction, priority, and attachment scope matter as well as addresses and ports. Verify DNS and routing alongside firewall rules, then update external allowlists for any changed public addresses.

Compatibility differences

Azure virtual networks are regional, so the build rejects source networks whose subnetworks span multiple regions.

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.