> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt > Use this file to discover all available pages before exploring further. # Set up BYOC on AWS with VPC peering > Run Tensorlake executors in your AWS account and let a Tensorlake-run Sandbox Proxy reach them over a private VPC peering connection. 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](/platform/self-hosted-compute/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. 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](/platform/self-hosted-compute/aws#1-prepare-project-storage). * Capacity for at least one supported bare-metal EC2 instance with local NVMe instance storage. See [Launch the first executor](/platform/self-hosted-compute/aws#8-launch-the-first-executor). ## 1. Send your account details Give Tensorlake these values through your support channel: | Value | Example | | --------------------------- | ------------------------------------------------------------------------- | | AWS account ID | `111111111111` | | AWS Region | `us-east-1` | | VPC ID | `vpc-0123456789abcdef0` | | VPC address range | `10.90.0.0/16` | | Executor subnet ranges | `10.90.64.0/24`, `10.90.65.0/24`, `10.90.66.0/24` | | Executor route table IDs | `rtb-0123456789abcdef0`, `rtb-0123456789abcdef1`, `rtb-0123456789abcdef2` | | Executor security group IDs | `sg-0123456789abcdef0` | | Project storage | `s3://customer-tensorlake` | 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: | Field | What it is | | ----------------------- | -------------------------------------------------------------------------------------------- | | `peering_connection_id` | The connection to accept | | `requester_account_id` | The Tensorlake AWS account | | `requester_vpc_id` | The Tensorlake VPC | | `provider_node_cidrs` | One `/27` per Availability Zone, so three ranges. These are the only sources the proxy uses. | | `destination_cidrs` | The executor subnets you sent, echoed back | | `destination_ports` | TCP `5565` and TCP `8095-8097` | Verify the account, VPC, ranges, and ports before you accept anything. ## 3. Accept the peering connection ```bash theme={null} aws ec2 accept-vpc-peering-connection \ --region "$AWS_REGION" \ --vpc-peering-connection-id "$PEERING_CONNECTION_ID" ``` Confirm the status: ```bash theme={null} aws ec2 describe-vpc-peering-connections \ --region "$AWS_REGION" \ --vpc-peering-connection-ids "$PEERING_CONNECTION_ID" \ --query 'VpcPeeringConnections[0].Status.Code' \ --output text ``` 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](/platform/self-hosted-compute/aws#9-enroll-the-executor). An executor must take its address from EC2 instance metadata. It must not advertise a public address. ## Troubleshooting | Symptom | What to check | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | The peering connection stays `pending-acceptance` | Accept it in the Region and account named in the packet. | | Sandboxes never become ready | Confirm the return routes in every executor subnet route table, not only the first. | | Traffic arrives but nothing answers | Confirm the executor security group allows every `provider_node_cidrs` value on TCP `5565` and TCP `8095-8097`. | | Some Availability Zones work and others do not | The proxy uses one node range per zone. Confirm all of them appear in your routes and security groups. | | The executor registers with a public address | Confirm the instance takes its address from instance metadata and sits in an executor subnet you sent. |