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

Cloud Adapter

On AWS

VPC

An Azure virtual network and its subnets become an AWS VPC and subnets with the same address ranges. Routes become route-table entries, and the NAT gateway uses a static address.

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 network security groups use ordered allow and deny rules. AWS security groups support unordered allow rules, so the mapping uses network ACLs for rules that need ordering or denial. Azure network security groups and AWS security groups are stateful. Network ACLs are stateless, so their rules must explicitly allow return traffic as well as the initiating traffic, in the appropriate direction on the affected subnets. The build requires acknowledgement of which rules use each mechanism. Azure service tags are translated to the target’s prefix lists because the two clouds use different address ranges.

On Google Cloud

Virtual Private Cloud (VPC)

An Azure virtual network becomes a Google Cloud VPC network with subnetworks in the same address ranges. Google Cloud firewall rules support priority ordering and denial, preserving those properties of Azure network security groups.

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 network becomes global while each subnetwork remains regional. Rules using Azure service tags are rewritten for the corresponding target address ranges; the build identifies these changes.

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.