Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of VPC with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Max adaptation

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Your application and Terraform’s AWS provider keep using the AWS EC2 APIs to create VPCs, subnets, security groups and the other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the matching Google Cloud resources. The adapter checks each request and its permissions, gives the resource an AWS-format ID and saves the requested configuration. The ID is for API callers; it is not the Google Cloud resource’s name. A background worker then applies the configuration to Google Cloud and tracks the result. For example, CreateVpc records the VPC with its default security group, main route table and default network ACL, and DescribeVpcs reports pending until the network exists in Google Cloud, then available. A successful create call does not mean the network is ready. Application traffic runs on the customer’s cloud network. The adapter handles network-management calls only; it does not carry your application’s packets.
The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.

​
Network layout

The VPC becomes a custom-mode Google Cloud network. Google puts address ranges on subnetworks, so the AWS VPC’s overall CIDR stays part of the API view while each subnet’s IPv4 range becomes a subnetwork range. Subnet references keep pointing to the matching subnetwork. A Google subnetwork is regional. An AWS subnet’s Availability Zone does not set the instance’s zone, so review instance placement if your application depends on zone separation. Terraform subnet declarations using count or for_each keep their instance keys and address expressions.
Google Cloud VPC contains regional subnetworks. Workloads attach to those subnets, with access controlled by firewall rules.Google Cloud VPC contains regional subnetworks. Workloads attach to those subnets, with access controlled by firewall rules.

​
Security groups and subnet filters

Security-group rules become Google Cloud firewall rules with the same direction, protocol, ports and address ranges. Group membership uses network tags: a rule that names another group in the same VPC selects instances that have that group’s tag. A membership change therefore updates the instance tags as well as the AWS group record. Google source tags match within their own network and against primary internal addresses; review secondary and alias IP behaviour separately. Network ACL operations keep ordered subnet rules, but an accepted ACL request alone does not give equivalent packet filtering.

​
Routes and connectivity

Route-table APIs keep subnet associations and supported next hops. Internet-gateway routes use Google’s internet gateway, and private-subnet egress uses a Cloud Router and Cloud NAT for the selected subnetworks. A default internet route alone does not make an instance reachable from the internet: addresses and firewall rules matter too. VPC peering in the same account and region creates both directions of Google VPC Network Peering once it is accepted. Routes that name the peering stay visible through the AWS API, while Google adds the peered subnet routes. If the peering is deleted, a route that names it can stay in the route table, but no traffic uses it. Private Google Access lets eligible private workloads reach Google APIs.

​
Limitations

Where AWS VPC and this target differ
  • Network ACLs behave differently: Google’s firewall is stateful. Google’s firewall tracks connections and cannot keep AWS’s stateless filtering exactly. Applying that reduced behaviour needs your explicit acknowledgement.
  • Security-group rules that use prefix lists are not supported. They are left out and the limitation is recorded, so less traffic is allowed than on AWS.
  • Rules that name a security group in a peered VPC are not supported. Google source tags cannot express them, so such a rule is rejected when the configuration is applied.
  • Private NAT gateways are not supported. NAT gateway requests with more than one address are not supported either.
  • Cross-account and cross-region VPC peering are not supported. AWS peering DNS options are not supported either.
  • Routes to unsupported next hops are rejected. Routes to transit gateways, instances, network interfaces and other unsupported next hops are rejected.
  • PrivateLink endpoints are not created. Private services you publish need a separate Private Service Connect setup.
  • IPAM, Amazon-provided IPv6, custom DHCP options and VPC-wide encryption are not supported. Use explicit IPv4 subnet ranges. The public IPv6 range AWS gives a VPC differs from Google’s separately allocated public subnet ranges.
  • Flow logs behave differently: they use Google’s format. Flow-log requests turn on Google subnet logging, with Google’s records and destination; the 60- and 600-second aggregation windows are kept. An S3 or CloudWatch destination needs your acknowledgement that it will receive no records.
  • Some flow-log options are not supported. Single-interface capture, AWS log filter expressions, and ACCEPT-only or REJECT-only capture are not supported.
  • Existing Elastic IP addresses are not kept. AllocateAddress gets a new public IP in the target cloud and returns once it is allocated. An existing AWS Elastic IP does not move.
  • Attaching and detaching network interfaces is not supported. A standalone CreateNetworkInterface records the subnet, private address and security groups; the interface is created when a VM launch names it. Launches with more than one interface are not supported.

​
Other considerations

Credentials. Your application signs its EC2 requests with credentials that the appliance’s IAM and STS service accepts. The adapter checks the action and resource before changing anything. It holds the target-cloud credentials, so your application needs no second set of cloud API calls. What to watch. Keep using the normal status checks after a create or update. The adapter keeps the requested configuration and the observed cloud state separately, retries changes that can be retried, and reports an error when a setting cannot be applied. A Describe response shows the saved AWS IDs and configuration, with current cloud-assigned values where needed. Deletes check dependencies: for example, a subnet stays 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. Moving from AWS. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Virtual network and NAT allocation (VPC) · Selected network GiB per month
Feature: Virtual network and NAT allocation (VPC). Estimated monthly service charges by Selected network GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic. Cloud NAT bills USD 0.0014 per assigned VM-hour, capped at 0.044 from 32 VMs, plus 0.005/hour per NAT IP; the default gateway-hour is the 32-VM cap, so lower it for small node pools.
  • Amazon VPC pricing: https://aws.amazon.com/vpc/pricing/
  • AWS Price List API, AmazonEC2 offer (CSV): https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.csv
  • Cloud NAT pricing: https://cloud.google.com/nat/pricing
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-e3747b96fbaaafb9d5b0a89ae6f48d55edf6ca32 / 2026-10-22.planning.2. Curve: workload-1. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), Cloud NAT pricing. Virtual network and NAT allocation (VPC) → Virtual Private Cloud (VPC): Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 0 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 1,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 730 resource-hour.
  • Independent inventory: 0 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 1,000 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic. Cloud NAT bills USD 0.0014 per assigned VM-hour, capped at 0.044 from 32 VMs, plus 0.005/hour per NAT IP; the default gateway-hour is the 32-VM cap, so lower it for small node pools.
List prices read: 2026-10-22. Model: plan-e3747b96fbaaafb9d5b0a89ae6f48d55edf6ca32 / 2026-10-22.planning.2. Scenario: planning-example. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), Cloud NAT pricing.

​
On Azure

​
How it works

Your application and Terraform’s AWS provider keep using the AWS EC2 APIs to create VPCs, subnets, security groups and the other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the matching Azure resources. The adapter checks each request and its permissions, gives the resource an AWS-format ID and saves the requested configuration. The ID is for API callers; it is not the Azure resource’s name. A background worker then applies the configuration to Azure and tracks the result. For example, CreateVpc records the VPC with its default security group, main route table and default network ACL, and DescribeVpcs reports pending until the network exists in Azure, then available. A successful create call does not mean the network is ready. Application traffic runs on the customer’s cloud network. The adapter handles network-management calls only; it does not carry your application’s packets.
The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.

​
Network layout

The VPC becomes an Azure Virtual Network (VNet), and each subnet keeps its requested IPv4 range. The adapter keeps the AWS subnet IDs, so your application can use them in later requests. The VNet’s address spaces hold the network’s CIDR ranges, and subnet ranges must fit inside them. Azure subnets are regional. Set availability zones on the workloads that need them instead of relying on an AWS subnet’s zone, and review the VNet and workload placement together. Subnet count and for_each declarations keep their instance keys and address expressions.
Azure Virtual Network contains regional subnets. Workloads attach to those subnets, with access controlled by NSGs and application groups.Azure Virtual Network contains regional subnets. Workloads attach to those subnets, with access controlled by NSGs and application groups.

​
Security groups and subnet filters

Azure network security groups (NSGs) enforce your allow and deny rules, keeping protocols, ports, direction and address ranges, in Azure’s priority order. A rule that names another security group in the same VPC uses an Application Security Group, which selects the member interfaces. The adapter updates that membership when an instance’s security groups change. Review rules that combine group membership with subnet network ACLs (ordered, stateless traffic filters): Azure limits which selectors one rule can combine. For network ACLs, the adapter combines ordered subnet filters with the security-group rules. A rule order or selector Azure cannot express is rejected.

​
Routes and connectivity

Supported route-table operations set Azure routes and subnet associations. Internet access needs an explicit outbound method or a suitable public frontend; do not rely on Azure’s default outbound access. Private-subnet egress uses an Azure NAT Gateway with a public IP, attached to the subnets that need it. VPC peering in the same account and region becomes two one-way VNet peerings. The AWS API keeps the peering’s lifecycle and the routes that refer to it, while Azure adds routes to the peered address spaces.

​
Limitations

Where AWS VPC and this target differ
  • Network ACLs behave differently: Azure filters are stateful. Azure NSGs track connections, so AWS’s stateless handling of return traffic is not guaranteed. A reduced, stateful mapping needs your explicit acknowledgement.
  • Group rules behave differently on AKS-managed nodes. AKS-managed node interfaces cannot join Application Security Groups. Where a subnet mixes managed nodes with other interfaces, a subnet-wide rule needs your explicit acknowledgement, because it changes which traffic the rule selects.
  • Private NAT gateways are not supported. NAT gateway requests with more than one address are not supported either.
  • Cross-account and cross-region VPC peering are not supported. Azure supports broader peering, but the adapter does not map it. AWS peering DNS options need a separate private-DNS design.
  • Routes to unsupported next hops are rejected. Routes to transit gateways, instances, network interfaces and other unsupported next hops are rejected.
  • VPC endpoints do not create Azure private connectivity. Azure Private Endpoint, Private Link, VPN and custom DNS services each need their own configuration; a VPC endpoint declaration does not create them.
  • IPAM, Amazon-provided IPv6 and custom DHCP options are not supported. Use explicit IPv4 subnet ranges. Azure’s multiple VNet address ranges do not reproduce AWS address allocation.
  • You must express VPC-wide encryption through Azure controls. A VPC-wide encryption requirement is not kept as such; use the supported Azure controls.
  • Flow logs behave differently: they use Azure’s format. Flow records use Azure’s logging, fields and destinations. Update collectors and queries that expect AWS flow-log records or destinations, and check coverage for the subnets and interfaces your application uses.
  • Existing Elastic IP addresses are not kept. AllocateAddress gets a new public IP in the target cloud and returns once it is allocated. An existing AWS Elastic IP does not move.
  • Attaching and detaching network interfaces is not supported. A standalone CreateNetworkInterface records the subnet, private address and security groups; the interface is created when a VM launch names it. Launches with more than one interface are not supported.

​
Other considerations

Credentials. Your application signs its EC2 requests with credentials that the appliance’s IAM and STS service accepts. The adapter checks the action and resource before changing anything. It holds the target-cloud credentials, so your application needs no second set of cloud API calls. What to watch. Keep using the normal status checks after a create or update. The adapter keeps the requested configuration and the observed cloud state separately, retries changes that can be retried, and reports an error when a setting cannot be applied. A Describe response shows the saved AWS IDs and configuration, with current cloud-assigned values where needed. Deletes check dependencies: for example, a subnet stays 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. Moving from AWS. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Virtual network and NAT allocation (VPC) · Selected network GiB per month
Feature: Virtual network and NAT allocation (VPC). Estimated monthly service charges by Selected network GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: Global; currency: USD.
Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → Global, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic.
  • Amazon VPC pricing: https://aws.amazon.com/vpc/pricing/
  • AWS Price List API, AmazonEC2 offer (CSV): https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.csv
  • Azure Retail Prices API: https://prices.azure.com/api/retail/prices
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-34eea51598bf0f8620a54e3566f90ac9abbc71fb / 2026-10-22.planning.2. Curve: workload-1. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), Azure Retail Prices API. Virtual network and NAT allocation (VPC) → Virtual Network: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: Global. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 0 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 1,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 730 resource-hour.
  • Independent inventory: 0 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 1,000 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic.
List prices read: 2026-10-22. Model: plan-34eea51598bf0f8620a54e3566f90ac9abbc71fb / 2026-10-22.planning.2. Scenario: planning-example. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), Azure Retail Prices API.

​
On OCI

​
How it works

Your application and Terraform’s AWS provider keep using the AWS EC2 APIs to create VPCs, subnets, security groups and the other supported VPC resources in the customer’s environment. The Tensor9 service adapter accepts those requests and manages the matching OCI resources. The adapter checks each request and its permissions, gives the resource an AWS-format ID and saves the requested configuration. The ID is for API callers; it is not the OCI resource’s name. A background worker then applies the configuration to OCI and tracks the result. For example, CreateVpc records the VPC with its default security group, main route table and default network ACL, and DescribeVpcs reports pending until the network exists in OCI, then available. A successful create call does not mean the network is ready. Application traffic runs on the customer’s cloud network. The adapter handles network-management calls only; it does not carry your application’s packets.
The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.The AWS SDK or Terraform sends network-management requests to the Tensor9 adapter, which saves the requested configuration and applies it through the target cloud API. Application traffic runs on the customer's cloud network, not through the adapter.

​
Network layout

The VPC becomes an OCI Virtual Cloud Network (VCN): the VPC’s IPv4 range goes on the VCN, and each subnet range on an OCI subnet. AWS IDs stay available to later API requests, and the adapter tracks the matching OCI resources separately. The OCI subnets are regional. Availability-domain and fault-domain placement belongs to the workloads that use those subnets, so review it if your application relies on AWS Availability Zone separation. Subnet count and for_each declarations keep their keys and address expressions.
OCI Virtual Cloud Network contains regional subnets. Workloads attach to those subnets, with access controlled by network security groups.OCI Virtual Cloud Network contains regional subnets. Workloads attach to those subnets, with access controlled by network security groups.

​
Security groups and subnet filters

Security groups become OCI network security groups (NSGs) attached to the relevant virtual network interfaces. Rules keep direction, protocol, ports and CIDR ranges. A rule that names another group uses OCI’s own NSG reference. OCI combines the permissions of subnet security lists and interface NSGs, and the adapter accounts for both when it applies your ingress rules. Adding a restrictive NSG does not cancel an allow rule already in a security list, so review the rules already in the customer’s VCN as well as the groups your application creates. Internet access also needs the right route, gateway and public address.

​
Routes and connectivity

The VCN uses OCI route tables and an internet gateway for public routing. Subnets that need outbound-only access use an OCI NAT Gateway and a private route table whose default route points to it.

​
Limitations

Where AWS VPC and this target differ
  • Network ACLs are not supported. AWS subnet network ACLs are outside this mapping. Stateful NSG rules are not the same as stateless filters: test both allowed and denied connections after deploying the VCN.
  • You must configure references to groups outside this environment. A rule that names a security group outside the mapped environment needs separate configuration.
  • Private service access and VCN peering are not set up for you. Service Gateway, Private Endpoint, Local Peering and Remote Peering attach and route differently from AWS PrivateLink and VPC peering, and are not mapped automatically.
  • Custom route next hops behave differently. A custom next hop needs a suitable OCI route; the AWS route-table declaration does not cover every OCI routing option.
  • IPAM, IPv6, secondary CIDR blocks and custom DHCP options are not supported. The primary IPv4 VCN and subnet ranges are kept. OCI has related features, but their presence alone does not reproduce the AWS configuration.
  • Flow logs behave differently: they use OCI Logging. Flow records use OCI’s format. Update destinations and queries that depend on AWS flow logs.
  • Existing Elastic IP addresses are not kept. AllocateAddress gets a new public IP in the target cloud and returns once it is allocated. An existing AWS Elastic IP does not move.
  • Attaching and detaching network interfaces is not supported. A standalone CreateNetworkInterface records the subnet, private address and security groups; the interface is created when a VM launch names it. Launches with more than one interface are not supported.

​
Other considerations

Credentials. Your application signs its EC2 requests with credentials that the appliance’s IAM and STS service accepts. The adapter checks the action and resource before changing anything. It holds the target-cloud credentials, so your application needs no second set of cloud API calls. What to watch. Keep using the normal status checks after a create or update. The adapter keeps the requested configuration and the observed cloud state separately, retries changes that can be retried, and reports an error when a setting cannot be applied. A Describe response shows the saved AWS IDs and configuration, with current cloud-assigned values where needed. Deletes check dependencies: for example, a subnet stays 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. Moving from AWS. Public IP addresses change, so update DNS records and external allowlists. Existing connections do not survive the move to the new network.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Virtual network and NAT allocation (VPC) · Selected network GiB per month
Feature: Virtual network and NAT allocation (VPC). Estimated monthly service charges by Selected network GiB per month. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; currency: USD.
Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.Virtual network and NAT allocation (VPC) · Selected network GiB per month: monthly service charges by Selected network GiB per month. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic. OCI lists no NAT gateway charge; traffic leaving the VCN bills as internet egress after 10 TB a month.
  • Amazon VPC pricing: https://aws.amazon.com/vpc/pricing/
  • AWS Price List API, AmazonEC2 offer (CSV): https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.csv
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-95441666831b4ce50a1ee860569b2535dc66553c / 2026-10-22.planning.2. Curve: workload-1. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), OCI price list API. Virtual network and NAT allocation (VPC) → Virtual Cloud Network: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-ashburn-1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Public IPv4, VPN/interconnect, firewalls, private endpoints, DNS, peering and traffic outside the selected transfer scope.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 0 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 1,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 730 resource-hour.
  • Independent inventory: 0 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 1,000 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • Resource-hours represent selected gateway allocation, not a claim that the network object has an hourly fee.
  • Use matching source and target traffic scope: NAT processing, inter-zone transfer and internet egress are different meters.
  • Resource-hours are the selected NAT/gateway allocation, not a fee for the network object; network GiB is the gateway’s processed or transferred traffic. Free management API calls do not reveal network traffic. OCI lists no NAT gateway charge; traffic leaving the VCN bills as internet egress after 10 TB a month.
List prices read: 2026-10-22. Model: plan-95441666831b4ce50a1ee860569b2535dc66553c / 2026-10-22.planning.2. Scenario: planning-example. Sources: Amazon VPC pricing, AWS Price List API, AmazonEC2 offer (CSV), OCI price list API.

​
On Private Kubernetes

​
How it works

The customer’s Kubernetes cluster already supplies the network used by the application. Tensor9 translates the workload resources to use that cluster. It keeps the source VPC-family references needed by the generated infrastructure, but creates no separate VPC, subnet, NAT gateway, or AWS security-group boundary through this backend.

​
What source network outputs mean

A source network identifier can feed another resource or module output even though the target cluster has no corresponding AWS network object. Compilation preserves a resolvable value for that reference and records which source resource it came from. The value is not a routable address or proof that a new network was provisioned. Use the deployed workload and Service endpoints to determine actual connectivity.

​
Traffic policy and external access

The customer platform team must configure the cluster’s network plugin, network policies, ingress or load balancer integration, DNS, and outbound routes. This VPC backend does not convert source security groups or stateless subnet ACLs into enforced Kubernetes rules. Verify both allowed and denied connections, including traffic between application components and other workloads sharing the cluster.

​
Runtime API and cutover

Applications that create or change AWS VPC resources at runtime cannot use this existing-network backend for those operations. The AWS-compatible VPC management described for Google Cloud, Azure, and OCI is a different mapping. Before cutover, prepare cluster connectivity, deploy the translated workloads, and update DNS and external allowlists for their target endpoints.

​
Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications. Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: VPC costs.

​
Service level agreements

These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​
VPC to Virtual Network

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on azure::1.0.0::vnet. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.

​
How the latency targets were chosen

Bounded VPC management reads: +10 ms monthly p99 (adapter-added). DescribeAvailabilityZones, DescribeFlowLogs, DescribeInternetGateways, DescribeNatGateways, DescribeNetworkAcls, DescribeRouteTables, DescribeSecurityGroupRules, DescribeSecurityGroups, DescribeSubnets, DescribeVpcAttribute, DescribeVpcPeeringConnections, DescribeVpcs, GetFlowLogsIntegrationTemplate, GetSecurityGroupsForVpc. Bounded adapter state lookup and AWS response mapping; packet forwarding is excluded. VPC topology and policy mutation: +25 ms monthly p99 (adapter-added). AcceptVpcPeeringConnection, AssociateRouteTable, AssociateSecurityGroupVpc, AssociateSubnetCidrBlock, AssociateVpcCidrBlock, AttachInternetGateway, AuthorizeSecurityGroupEgress, AuthorizeSecurityGroupIngress, CreateDefaultSubnet, CreateDefaultVpc, CreateFlowLogs, CreateInternetGateway, CreateNatGateway, CreateNetworkAcl, CreateNetworkAclEntry, CreateRoute, CreateRouteTable, CreateSecurityGroup, CreateSubnet, CreateVpc, CreateVpcPeeringConnection, DeleteFlowLogs, DeleteInternetGateway, DeleteNatGateway, DeleteNetworkAcl, DeleteNetworkAclEntry, DeleteRoute, DeleteRouteTable, DeleteSecurityGroup, DeleteSubnet, DeleteVpc, DeleteVpcPeeringConnection, DetachInternetGateway, DisableVgwRoutePropagation, DisassociateRouteTable, DisassociateSecurityGroupVpc, DisassociateSubnetCidrBlock, DisassociateVpcCidrBlock, EnableVgwRoutePropagation, ModifyAvailabilityZoneGroup, ModifySecurityGroupRules, ModifySubnetAttribute, ModifyVpcAttribute, ModifyVpcPeeringConnectionOptions, ModifyVpcTenancy, RejectVpcPeeringConnection, ReplaceNetworkAclAssociation, ReplaceNetworkAclEntry, ReplaceRoute, RevokeSecurityGroupEgress, RevokeSecurityGroupIngress. Whole-request validation, durable desired-state admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.

​
Example and diagnosis

Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
VPC to Virtual Private Cloud (VPC)

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on google::1.0.0::compute::network. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.

​
How the latency targets were chosen

Bounded VPC management reads: +10 ms monthly p99 (adapter-added). DescribeAddresses, DescribeAddressesAttribute, DescribeAvailabilityZones, DescribeFlowLogs, DescribeInternetGateways, DescribeNatGateways, DescribeNetworkAcls, DescribeNetworkInterfaceAttribute, DescribeNetworkInterfaces, DescribeRouteTables, DescribeSecurityGroupRules, DescribeSecurityGroups, DescribeSubnets, DescribeTags, DescribeVpcAttribute, DescribeVpcPeeringConnections, DescribeVpcs, GetFlowLogsIntegrationTemplate, GetSecurityGroupsForVpc. Bounded adapter state lookup and AWS response mapping; packet forwarding is excluded. VPC topology and policy mutation: +25 ms monthly p99 (adapter-added). AcceptVpcPeeringConnection, AllocateAddress, AssignIpv6Addresses, AssignPrivateIpAddresses, AssociateAddress, AssociateRouteTable, AssociateSecurityGroupVpc, AssociateSubnetCidrBlock, AssociateVpcCidrBlock, AttachInternetGateway, AttachNetworkInterface, AuthorizeSecurityGroupEgress, AuthorizeSecurityGroupIngress, CreateDefaultSubnet, CreateDefaultVpc, CreateFlowLogs, CreateInternetGateway, CreateNatGateway, CreateNetworkAcl, CreateNetworkAclEntry, CreateNetworkInterface, CreateRoute, CreateRouteTable, CreateSecurityGroup, CreateSubnet, CreateTags, CreateVpc, CreateVpcPeeringConnection, DeleteFlowLogs, DeleteInternetGateway, DeleteNatGateway, DeleteNetworkAcl, DeleteNetworkAclEntry, DeleteNetworkInterface, DeleteRoute, DeleteRouteTable, DeleteSecurityGroup, DeleteSubnet, DeleteTags, DeleteVpc, DeleteVpcPeeringConnection, DetachInternetGateway, DetachNetworkInterface, DisableVgwRoutePropagation, DisassociateAddress, DisassociateRouteTable, DisassociateSecurityGroupVpc, DisassociateSubnetCidrBlock, DisassociateVpcCidrBlock, EnableVgwRoutePropagation, ModifyAvailabilityZoneGroup, ModifyNetworkInterfaceAttribute, ModifySecurityGroupRules, ModifySubnetAttribute, ModifyVpcAttribute, ModifyVpcPeeringConnectionOptions, ModifyVpcTenancy, RejectVpcPeeringConnection, ReleaseAddress, ReplaceNetworkAclAssociation, ReplaceNetworkAclEntry, ReplaceRoute, ResetNetworkInterfaceAttribute, RevokeSecurityGroupEgress, RevokeSecurityGroupIngress, UnassignIpv6Addresses, UnassignPrivateIpAddresses. Whole-request validation, durable desired-state admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.

​
Example and diagnosis

Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
VPC to Virtual Cloud Network

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

Network control calls validate AWS-shaped topology, record desired state and reconcile native networking on oci::1.0.0::vcn. Application packets, load-balancer forwarding and health-probe network time are not adapter request latency. Local graph validation, rule translation, admission, status lookup and response encoding remain covered.

​
How the latency targets were chosen

Bounded VPC management reads: +10 ms monthly p99 (adapter-added). DescribeAvailabilityZones, DescribeFlowLogs, DescribeInternetGateways, DescribeNatGateways, DescribeRouteTables, DescribeSecurityGroupRules, DescribeSecurityGroups, DescribeSubnets, DescribeVpcAttribute, DescribeVpcs, GetFlowLogsIntegrationTemplate, GetSecurityGroupsForVpc. Bounded adapter state lookup and AWS response mapping; packet forwarding is excluded. VPC topology and policy mutation: +25 ms monthly p99 (adapter-added). AssociateRouteTable, AssociateSecurityGroupVpc, AttachInternetGateway, AuthorizeSecurityGroupEgress, AuthorizeSecurityGroupIngress, CreateDefaultSubnet, CreateDefaultVpc, CreateFlowLogs, CreateInternetGateway, CreateNatGateway, CreateRoute, CreateRouteTable, CreateSecurityGroup, CreateSubnet, CreateVpc, DeleteFlowLogs, DeleteInternetGateway, DeleteNatGateway, DeleteRoute, DeleteRouteTable, DeleteSecurityGroup, DeleteSubnet, DeleteVpc, DetachInternetGateway, DisableVgwRoutePropagation, DisassociateRouteTable, DisassociateSecurityGroupVpc, EnableVgwRoutePropagation, ModifyAvailabilityZoneGroup, ModifySecurityGroupRules, ModifySubnetAttribute, ModifyVpcAttribute, ModifyVpcTenancy, ReplaceRoute, RevokeSecurityGroupEgress, RevokeSecurityGroupIngress. Whole-request validation, durable desired-state admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent load balancers, networks and flow-log records reconcile concurrently; changes to one object serialize by generation. Qualification fixes listeners, rules, target groups, routes, security rules, tags and returned page size. Large rule trees receive their own bounded group rather than inheriting a point-write estimate. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

The adapter preserves exposure, protocol, address family, listener/rule priority, target membership and fail-closed security intent. A successful change is durable before acknowledgement, stale generations cannot re-open removed access, and readiness reflects observed native state.

​
Example and diagnosis

Adding one HTTPS listener with ten routing rules is a bounded policy mutation. The adapter target covers validation, durable recording and native-plan construction; provider provisioning and certificate readiness are separate. The response cannot claim ACTIVE until the native listener is observed. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
VPC to Scaleway VPC

SLA status: Not applicable This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.

​
VPC to Tensor9 Trivial

SLA status: Not applicable This mapping configures native networking. Application packets pass through the target network or load balancer, not the adapter fabric, and this directed mapping does not expose an origin-cloud network-management endpoint. The target provider’s networking terms apply.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.