Skip to main content
Bring your own cloud (BYOC) has two shapes on AWS. This page covers the peered deployment, where Tensorlake runs the Sandbox Proxy and you run only the executors. Sandbox traffic reaches your executors over a VPC peering connection that never crosses the public internet. If you want to run the Sandbox Proxy yourself on your own Amazon EKS cluster, use Set up BYOC on AWS instead. The two deployments are alternatives. Do not combine them.

​
What each side runs

Tensorlake runs the Sandbox Proxy for your project and gives it a dedicated public endpoint on TCP 443 and TCP 22. The proxy lives in a Tensorlake VPC in the same AWS Region as your executors. You run the executors on bare-metal Amazon EC2 instances in your own VPC, and you own the S3 bucket that holds sandbox state. The proxy reaches each executor across the peering connection on private TCP 5565 and TCP 8095-8097. Users reach a Sandbox Proxy that Tensorlake runs behind a load balancer in a Tensorlake AWS account. The proxy reaches executors in your AWS account across a VPC peering connection on private ports 5565 and 8095 to 8097. Executors write runtime data and snapshots to your Amazon S3 bucket, and both the proxy and the executors open outbound HTTPS connections to Tensorlake Cloud.

​
Before you begin

Prepare these resources in the AWS Region where Tensorlake runs your Sandbox Proxy. Both VPCs must be in that same Region.
  • A VPC that uses the 10.90.0.0/16 address range. Tensorlake standardizes on this range so that every peered deployment shares one network layout.
  • Three private subnets for the executors, one per Availability Zone.
  • A route table for each of the three subnets. You add return routes to these.
  • A security group for the executors. You add proxy sources to this.
  • An S3 bucket for runtime data, built images, and durable sandbox snapshots, and an EC2 instance profile that can use it. See Prepare project storage.
  • Capacity for at least one supported bare-metal EC2 instance with local NVMe instance storage. See Launch the first executor.

​
1. Send your account details

Give Tensorlake these values through your support channel: The executor subnet ranges are the destinations Tensorlake routes to. List the exact subnets, not the whole VPC range. Tensorlake configures your bucket in the fleet settings for your project. You do not set a bucket URI in Tensorlake Cloud in this deployment.

​
2. Receive the onboarding packet

Tensorlake creates the peering connection from its side and sends you a packet with these fields: Verify the account, VPC, ranges, and ports before you accept anything.

​
3. Accept the peering connection

Confirm the status:
The status must be active.

​
4. Route return traffic

Add a route in all three executor subnet route tables for each provider_node_cidrs value, with the peering connection as the target. Traffic that arrives from the proxy has no return path until you do.

​
5. Allow the proxy into the executor security group

Allow each provider_node_cidrs value into every executor security group on TCP 5565 and TCP 8095-8097. Allow the /27 node ranges only. Do not allow a pod range, and do not allow the whole Tensorlake VPC range. If restrictive network ACLs protect the executor subnets, allow both request and return traffic there as well. Do not expose these ports to the internet. They carry sandbox traffic that is already authenticated between the proxy and the executor.

​
6. Confirm the path

Tell Tensorlake when steps 3 through 5 are complete. Tensorlake then verifies that the peering is active in both accounts, that both route tables carry the expected routes, that your security groups list only the node ranges and ports above, and that each executor advertises a private address inside one of your executor subnets. Tensorlake activates the proxy after those checks pass. Enroll executors as described in Enroll the executor. An executor must take its address from EC2 instance metadata. It must not advertise a public address.

​
Troubleshooting