- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of VPC with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
Infrastructure-only adaptation
On Google Cloud
How it works
Your application can keep using the AWS EC2 APIs to create networks, subnets, security groups, and other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the corresponding Google Cloud resources. Terraform’s AWS provider uses the same API path. The adapter checks the request and permissions, assigns an AWS-format resource ID, and saves the requested configuration. A background worker applies that configuration to the target cloud and tracks the result. For example,CreateVpc records the VPC together with its default security group, main route table, and default network ACL. DescribeVpcs reports pending until the cloud configuration has been applied, then available. Creating an API record does not mean the network is ready.
The customer’s cloud carries application traffic. The adapter handles network-management API calls; it does not forward the application’s packets.
Network layout
The VPC becomes a custom-mode Google Cloud network. Google places address ranges on subnetworks, so the AWS VPC’s overall CIDR remains part of the API model while each subnet’s IPv4 range becomes a native subnetwork range. Subnet references continue to identify the corresponding target subnet. A Google subnetwork is regional. An AWS subnet’s Availability Zone does not fix the target instance’s zone; review instance placement when the application depends on zone separation. Terraform subnet declarations usingcount or for_each retain their instance keys and address expressions.
Security groups and subnet filters
Security-group rules become Google Cloud firewall rules with the requested direction, protocol, ports, and address ranges. Group membership uses network tags: a same-VPC rule that names another group selects instances with that group’s tag. Membership changes must therefore update the native instance tags as well as the AWS-facing group record. Google source tags match within their own network and against primary internal addresses. A reference to a group in a peered VPC cannot be represented by the same tag rule and is rejected during application of the configuration. Secondary and alias IP behavior needs separate review. Network access control list (ACL) operations maintain ordered subnet rules, but Google’s firewall tracks connections and cannot preserve AWS’s stateless filtering exactly. Applying that reduced behavior requires an explicit acknowledgement; an accepted ACL API request alone does not establish equivalent packet filtering. Prefix-list security rules are omitted with a recorded limitation, leaving less traffic permitted.Routes and connectivity
Route-table APIs retain subnet associations and supported next hops. Internet-gateway routing uses Google’s internet gateway; private-subnet egress uses a Cloud Router and Cloud NAT for the selected subnetworks. A default internet route alone does not make an instance publicly reachable: addresses and firewall rules also matter. Private NAT gateways and multiple-address NAT requests are outside this mapping. Same-account, same-region VPC peering creates both directions of Google VPC Network Peering after acceptance. Routes naming that peering remain visible through the AWS API, while Google installs the peered subnet routes. If the peering is deleted, the AWS route can remain as a blackhole. Cross-account or cross-region peering and AWS peering DNS options are outside the adapter’s current binding. Transit-gateway, instance, interface, and other unsupported route next hops are rejected. Private Google Access provides access to Google APIs from eligible private workloads. Customer-published private services need a separate Private Service Connect configuration; an AWS PrivateLink endpoint is not created by this VPC mapping.Addresses and interfaces
The adapter keeps AWS-format VPC, subnet, security-group, and address identifiers for API callers and tracks the corresponding cloud resources separately. An AWS ID is not a native cloud resource name.AllocateAddress obtains a target-cloud public IP and waits for that allocation before returning the address. It does not preserve an existing AWS Elastic IP. A standalone CreateNetworkInterface records the subnet, private address, and security groups; the VM launch that names that interface creates the attached target interface. Standalone attach/detach operations and launches with multiple interfaces are outside this mapping.
Other compatibility differences
Use explicit IPv4 subnet ranges. AWS IPAM allocation, Amazon-provided IPv6 address blocks, custom DHCP option sets, and VPC-wide encryption enforcement are not reproduced. The public IPv6 aggregate AWS assigns to a VPC is different from Google’s independently allocated public subnet ranges. Flow-log requests enable native subnet logging in Google Cloud. Records use Google’s schema and logging destination; the 60-second and 600-second aggregation windows are preserved. An S3 or CloudWatch destination requires acknowledgement that it will not receive those records. Single-interface capture, AWS log-filter expressions, and ACCEPT-only or REJECT-only capture are not represented.Deployment and ongoing changes
The application signs its EC2 requests with credentials accepted by the appliance’s IAM/STS service. The adapter checks the requested action and resource before changing anything. Target-cloud credentials stay with the adapter; the application does not need a second set of cloud API calls. Keep using the normal status checks after a create or update. The adapter keeps requested configuration and observed cloud state separately, retries changes that can be retried, and reports errors when a requested setting cannot be applied. ADescribe response uses the saved AWS identity and configuration, with current cloud-assigned values where needed. Deletion checks dependencies: for example, a subnet remains in use while its NAT gateway is still being removed.
Before moving traffic, check subnet ranges and placement, test allowed and denied connections, and confirm that private-subnet egress uses the intended NAT gateway. Review peering, private service access, DNS, and log destinations separately. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.
On Azure
How it works
Your application can keep using the AWS EC2 APIs to create networks, subnets, security groups, and other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the corresponding Azure resources. Terraform’s AWS provider uses the same API path. The adapter checks the request and permissions, assigns an AWS-format resource ID, and saves the requested configuration. A background worker applies that configuration to the target cloud and tracks the result. For example,CreateVpc records the VPC together with its default security group, main route table, and default network ACL. DescribeVpcs reports pending until the cloud configuration has been applied, then available. Creating an API record does not mean the network is ready.
The customer’s cloud carries application traffic. The adapter handles network-management API calls; it does not forward the application’s packets.
Network layout
The VPC becomes an Azure Virtual Network (VNet), with subnets using the requested IPv4 ranges. The adapter keeps AWS subnet IDs so applications can use them in later requests. Azure VNet address spaces hold the network’s CIDR ranges; subnet ranges must fit within them. Azure subnets are regional. Choose availability zones on the workloads that need them rather than relying on an AWS subnet’s zone. Subnetcount and for_each declarations keep their instance keys and address expressions. Review the resulting VNet and workload placement together.
Security groups and subnet filters
Azure network security groups (NSGs) enforce the translated allow and deny rules. Rules preserve protocols, ports, direction, and address ranges while using Azure’s ordered priorities. Same-VPC references to another security group use Application Security Groups, which select the member interfaces. The adapter updates that membership when an instance’s security groups change. Review rules that combine group identity with subnet network ACLs (ordered, stateless traffic filters). Azure limits which selectors one rule can combine. AKS-managed node interfaces also cannot join Application Security Groups: where a subnet mixes managed nodes with other interfaces, a subnet-wide approximation requires explicit acknowledgement because it changes which traffic the rule selects. For network ACLs, the adapter composes ordered subnet filters with the security-group rules. Azure NSGs are stateful, so the translation cannot promise AWS’s stateless return-traffic behavior. Configurations whose rule ordering or selectors cannot be represented are rejected. A reduced stateful mapping requires explicit acknowledgement.Routes and connectivity
Supported route-table operations configure Azure routes and subnet associations. Internet access needs an explicit outbound method or an appropriate public frontend; do not rely on default outbound connectivity. Private-subnet egress uses an Azure NAT Gateway with a public IP, attached to the subnets that need it. Private NAT gateways and multiple-address NAT requests are outside this mapping. Same-account, same-region VPC peering becomes two directional VNet peerings. The AWS API retains the peering lifecycle and route references, while Azure installs routes to the peered address spaces. Cross-account or cross-region requests are outside the adapter’s binding, even though Azure has broader peering capabilities. AWS peering DNS options require a separate private-DNS design. Transit-gateway, instance, interface, and other unsupported route next hops are rejected. Azure Private Endpoint, Private Link, VPN, and custom DNS services require their own configuration; a VPC endpoint declaration does not create them automatically.Addresses and interfaces
The adapter keeps AWS-format VPC, subnet, security-group, and address identifiers for API callers and tracks the corresponding cloud resources separately. An AWS ID is not a native cloud resource name.AllocateAddress obtains a target-cloud public IP and waits for that allocation before returning the address. It does not preserve an existing AWS Elastic IP. A standalone CreateNetworkInterface records the subnet, private address, and security groups; the VM launch that names that interface creates the attached target interface. Standalone attach/detach operations and launches with multiple interfaces are outside this mapping.
Other compatibility differences
Use explicit IPv4 subnet ranges. AWS IPAM allocation, Amazon-provided IPv6 address blocks, and custom DHCP option sets are outside this mapping. Azure’s support for multiple VNet address ranges does not reproduce AWS address-allocation behavior. A VPC-wide encryption requirement must be expressed through supported target controls. Flow telemetry uses Azure’s logging facilities, with Azure fields and destinations. Update collectors and queries that expect AWS flow-log records or an AWS destination. Check log coverage for the subnets and interfaces the application depends on.Deployment and ongoing changes
The application signs its EC2 requests with credentials accepted by the appliance’s IAM/STS service. The adapter checks the requested action and resource before changing anything. Target-cloud credentials stay with the adapter; the application does not need a second set of cloud API calls. Keep using the normal status checks after a create or update. The adapter keeps requested configuration and observed cloud state separately, retries changes that can be retried, and reports errors when a requested setting cannot be applied. ADescribe response uses the saved AWS identity and configuration, with current cloud-assigned values where needed. Deletion checks dependencies: for example, a subnet remains in use while its NAT gateway is still being removed.
Before moving traffic, check subnet ranges and placement, test allowed and denied connections, and confirm that private-subnet egress uses the intended NAT gateway. Review peering, private service access, DNS, and log destinations separately. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.
On OCI
How it works
Your application can keep using the AWS EC2 APIs to create networks, subnets, security groups, and other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the corresponding OCI resources. Terraform’s AWS provider uses the same API path. The adapter checks the request and permissions, assigns an AWS-format resource ID, and saves the requested configuration. A background worker applies that configuration to the target cloud and tracks the result. For example,CreateVpc records the VPC together with its default security group, main route table, and default network ACL. DescribeVpcs reports pending until the cloud configuration has been applied, then available. Creating an API record does not mean the network is ready.
The customer’s cloud carries application traffic. The adapter handles network-management API calls; it does not forward the application’s packets.
Network layout
The VPC maps to an OCI Virtual Cloud Network (VCN), with the VPC’s IPv4 range in the VCN and each subnet range in an OCI subnet. AWS-facing identifiers remain available to later API requests; the adapter tracks the corresponding OCI identities separately. The mapped OCI subnets are regional. Availability-domain and fault-domain placement belongs to the workloads using those subnets, so review it when the application relies on AWS Availability Zone separation. Subnetcount and for_each declarations keep their keys and address expressions.
Security groups and subnet filters
Security groups map to OCI network security groups (NSGs) attached to the relevant virtual network interfaces. Rules specify direction, protocol, ports, and CIDR selectors. A rule naming a peer group uses OCI’s native NSG reference; a reference to a group outside the mapped environment needs separate configuration. OCI combines permissions from subnet security lists and interface NSGs. The adapter must account for both when applying the requested ingress policy. Adding a restrictive NSG does not cancel an existing security-list allow rule; review rules already present in the customer’s VCN as well as the groups the application creates. Internet reachability also requires the relevant route, gateway, and public address. AWS subnet network ACLs are outside this mapping. Do not treat stateful NSG rules as equivalent stateless filters. Check both permitted and denied connections after deploying the VCN.Routes and connectivity
The VCN uses OCI route tables and an internet gateway for public routing. Subnets that require outbound-only access use an OCI NAT Gateway and a private route table whose default route points to it. A custom next hop requires an appropriate OCI route; the AWS route-table declaration does not cover every OCI routing option. Private service access and connections to other VCNs need OCI-specific configuration. Service Gateway, Private Endpoint, Local Peering, and Remote Peering have different attachment and routing rules from AWS PrivateLink and VPC peering. They are outside this profile’s claimed automatic mapping.Addresses and interfaces
The adapter keeps AWS-format VPC, subnet, security-group, and address identifiers for API callers and tracks the corresponding cloud resources separately. An AWS ID is not a native cloud resource name.AllocateAddress obtains a target-cloud public IP and waits for that allocation before returning the address. It does not preserve an existing AWS Elastic IP. A standalone CreateNetworkInterface records the subnet, private address, and security groups; the VM launch that names that interface creates the attached target interface. Standalone attach/detach operations and launches with multiple interfaces are outside this mapping.
Other compatibility differences
The primary IPv4 VCN and subnet ranges are preserved. AWS IPAM allocation, IPv6 associations, secondary CIDR blocks, custom DHCP option sets, and subnet network ACLs are outside this profile. OCI offers related native features, but their presence alone does not preserve the AWS configuration. Flow telemetry uses OCI Logging and OCI’s record format. Update destinations and queries that depend on AWS flow logs. Public addresses are new OCI reserved addresses, so plan DNS and allowlist changes.Deployment and ongoing changes
The application signs its EC2 requests with credentials accepted by the appliance’s IAM/STS service. The adapter checks the requested action and resource before changing anything. Target-cloud credentials stay with the adapter; the application does not need a second set of cloud API calls. Keep using the normal status checks after a create or update. The adapter keeps requested configuration and observed cloud state separately, retries changes that can be retried, and reports errors when a requested setting cannot be applied. ADescribe response uses the saved AWS identity and configuration, with current cloud-assigned values where needed. Deletion checks dependencies: for example, a subnet remains in use while its NAT gateway is still being removed.
Before moving traffic, check subnet ranges and placement, test allowed and denied connections, and confirm that private-subnet egress uses the intended NAT gateway. Review peering, private service access, DNS, and log destinations separately. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.