Do BYOC Runners Need a NAT Gateway?

Only when the runners sit in private subnets. BYOC runners need an outbound route to the destinations listed in the AWS BYOC configuration prerequisites, and on AWS managed NAT gateways are how a private subnet gets that route; runners in public subnets reach the same destinations through the Internet Gateway with no gateway meter attached.

Answer

The documented requirement is internet connectivity. Which device provides it depends on where the runner instance sits.

The AWS BYOC configuration prerequisites state it directly: the VPC must have at least one public and one private subnet, the subnets must have internet connectivity, and the private subnets must route through NAT gateways. Route tables send internet-bound traffic through the Internet Gateway, and private subnets carry outbound traffic to the managed NAT service. Runners configured with static IPs use the addresses of those gateways as their external addresses, which is the one case where the managed service is mandatory rather than optional.

The route exists because a runner talks outbound before it does any work: it reaches the WarpBuild control plane, the GitHub API, and package managers before it can pull an image or run a step. The documented security group blocks all inbound traffic and allows outbound traffic to WarpBuild servers, the GitHub API, and package managers, so nothing about the design needs an inbound path into your VPC (AWS BYOC configuration).

BYOC runs on AWS, GCP, and Azure, and the shape is the same on all three: public subnet runners route straight out, private subnet runners route through the provider's managed translation service. The numbers on this page are the AWS ones, so price the GCP and Azure equivalents from their own published pricing pages before you commit to a layout.

Detail

What the prerequisites actually ask for

Rows come from the AWS BYOC configuration prerequisites, checked on 2026-08-13. The full network breakdown, including quota headroom per subnet, is on network requirements for BYOC runners on AWS, and the BYOC on AWS overview covers the stack around it.

What fills the gateway bill

Two traffic sources dominate: container image pulls and package downloads. Everything else a runner sends is small by comparison.

Take a fleet of 2,000 jobs a month, half of them pulling a container image.

Image pull bytes: 1,000 times 1.2 equals 1,200 GB. Package bytes: 2,000 times 0.4 equals 800 GB. Agent, API, and log traffic: 2,000 times 0.05 equals 100 GB.

The fixed side is 3 gateways times 730 hours times $0.045, which is $98.55 a month whether one job runs or every job does. Total AWS network charge on this profile: $193.05 a month, of which image pulls and package downloads account for 2,000 of the 2,100 metered gigabytes.

Set that next to the WarpBuild line for the same fleet. 2,000 jobs times 8 minutes is 16,000 minutes, and BYOC Linux runners are $0.002 per minute, which is $32.00 (pricing page, checked on 2026-08-13). On a private-subnet layout carrying this much image traffic, your own network line is the larger of the two, which is why the placement decision deserves a look before the runner size does.

Four levers on that number

1. Put only the workflows that need an allowlisted source address on private-subnet runners. Everything else runs in public subnets, where inbound bytes are $0.00 per GB.
2. Keep the documented S3 endpoint in place, so the artifact cache and runner telemetry stay off the meter.
3. Cut the bytes. Smaller images and higher cache hit rates move both of the dominant lines at once; the arithmetic is worked through in cut ECR pull costs in GitHub Actions.
4. Weigh zone count deliberately. One gateway is $32.85 a month against $98.55 for three, and the three-zone layout is the documented recommendation because it widens instance type availability.

On the enterprise tier, egress costs from your cloud drop to zero when runners pull large artifacts from ECR, S3, and similar stores during deployments, on BYOC and on WarpBuild-hosted runners alike; the terms are on the zero egress page.

One clarification that comes up in reviews: joining runners to a private network with the networking addon does not replace the outbound route. The addon gives a job reach into your own private services. Registration with WarpBuild and GitHub still travels the public path.

Related Questions

Can I run BYOC runners without NAT gateways?

Yes, when the runners sit in public subnets and the route table sends internet-bound traffic through the Internet Gateway. The documented prerequisite is that private subnets route through NAT gateways, and runners configured with static IPs use the gateway addresses as their external addresses (AWS BYOC configuration). Subnet placement is part of the setup covered on the BYOC on AWS overview.

How many NAT gateways does a WarpBuild AWS stack use?

Three in the recommended layout, one per availability zone. At $0.045 per gateway-hour in US East (N. Virginia), three gateways are $98.55 a month before any data moves (Amazon VPC pricing, checked on 2026-08-13). The per-subnet detail sits on network requirements for BYOC runners on AWS.

What fills the gateway bill on a runner fleet?

Container image pulls and package downloads. On the model above they are 2,000 of the 2,100 GB a fleet moves in a month, and agent traffic, GitHub API calls, and log shipping are the remaining 100 GB. For the definition of the device doing the metering, see NAT gateways explained.

Size your own layout against the prerequisites in the AWS BYOC configuration guide, price the runner minutes on the pricing page, and start on the BYOC on AWS overview.