A Security Checklist for BYOC on AWS

A WarpBuild BYOC stack on AWS hardens to six documented controls, in this order: a dedicated AWS account or VPC, blocked inbound connections, disallowed inter-instance communication, restricted outbound traffic, least-privilege instance profiles, and required IMDSv2. Every one of them is set in your own AWS account or in the runner configuration, which means the whole checklist is yours to apply without opening a ticket.

This page takes the six items from the AWS BYOC security hardening guide in the documented order, states what each one defends against, and shows where the setting lives. Start from the BYOC on AWS overview if the stack does not exist yet.

Overview

Two properties hold before you change any of the six. Each GitHub Actions job runs on a distinct, freshly provisioned EC2 instance that is terminated when the job completes, so no state and no credentials survive into the next job. And the permissions available to runner instances are exactly what you provide through security groups and IAM roles or instance profiles, because WarpBuild does not inject additional permissions into runner workloads.

For the vendor half of a review, the attestation is SOC 2 Type 2, with trust.warpbuild.com as the linked evidence path. Reviewers request the report and the supporting security documentation there. The platform-level answers on isolation, storage lifetime, and secret handling live in the security documentation and are collected for review packets on the security review checklist.

Architecture

The WarpBuild stack is a CloudFormation stack that provisions networking and an S3 bucket. It does not provision IAM permissions for your workloads, which is why item 5 exists as a separate step.

Rows come from the AWS BYOC security hardening guide, checked on 2026-08-13. The security group is a stack-level object. In create mode the template provisions it. In import mode you select an existing security group when the stack is created, which is the mode to use when your network team owns group definitions.

BYOC runs on AWS, GCP, and Azure, and this checklist is the AWS one; the GCP and Azure stacks expose their own equivalents. The runner sets launched inside an AWS account are the Linux and Windows ones.

Configuration

1. Dedicated VPC or AWS account. Deploy the stack in a separate VPC in the same account, or in an account dedicated to GitHub Actions workloads. Cross-account access is managed with AWS Organizations.

2. Block all inbound connections. Runner agents open outbound connections and hold them, so no inbound rule is required for a job to run. Remove every inbound rule from the runner security group and avoid attaching groups that allow 0.0.0.0/0 or the VPC CIDR inbound. In import mode, create the group with an empty inbound list.

{
  "InboundRules": [],
  "OutboundRules": [
    {
      "IpProtocol": "-1",
      "Destination": "0.0.0.0/0",
      "Description": "Allow all outbound"
    }
  ]
}

The S3 and ECR endpoints keep working under outbound-only rules, because the runner initiates those connections.

3. Disallow inter-instance communication. Runner instances have no reason to talk to each other. Use network ACLs on the subnets to deny intra-subnet traffic between instances while leaving the paths to the endpoints and the gateways open, or attach a tighter security group that allows egress to 0.0.0.0/0 and admits ingress only from the endpoint network interfaces rather than the whole subnet CIDR. The AWS network ACL documentation covers the rule syntax.

4. Restrict outbound traffic. Runners need outbound access, and the required set is short.

Allowlist those, add the external services your builds call, and drop the rest. The per-destination detail and the failure modes when a destination is missing are on outbound traffic controls for BYOC runners.

5. Least-privilege instance profiles. An instance profile is set per runner in the WarpBuild dashboard under Custom Runner configuration, in the Instance Profile ARN field, so a runner that deploys to production can hold a role that a pull request runner never sees. Scope the policy to the exact resources the job touches.

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["ecr:GetAuthorizationToken"], "Resource": "*" },
    {
      "Effect": "Allow",
      "Action": ["ecr:BatchCheckLayerAvailability", "ecr:PutImage", "ecr:UploadLayerPart"],
      "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<your-repo>"
    }
  ]
}

The role also needs iam:PassRole granted to the WarpBuild connection role, conditioned on iam:PassedToService being ec2.amazonaws.com. The full command sequence is on the IAM permissions page and in the instance profile guide.

6. Require IMDSv2. Both IMDS v1 and v2 are supported by default. Set Require IMDSv2 on the Update Runner page, in the Runner Specs section, to close the v1 path that SSRF attacks target. Per-runner behavior and the rollout order are on IMDSv2 on BYOC runners.

Operations

A checklist passes once and then drifts, so tie re-verification to three events: a stack template upgrade, an import-mode security group edit by the network team, and the creation of any new custom runner. New runners start with no instance profile attached and the default metadata setting, so items 5 and 6 are per-runner work rather than per-stack work.

Four operational items sit alongside the six controls. Configure S3 bucket lifecycle policies so cache objects expire on a schedule you chose. Scope the endpoint policies to the resources runners actually reach. Keep the managed-by: warpbuild tag in place, since it is the hook for tag-based access control policies and for cost attribution. And watch the resource naming patterns when you write cleanup or audit queries: EC2 instances and EBS volumes are named warp-*, launch templates tmpl-warp-*, and stack buckets warpbuild-*.

The cost side of the decision is small and worth stating plainly. BYOC Linux and Windows runners are $0.002 per runner minute in WarpBuild fees, with EC2, EBS, and data transfer billed by your own AWS account at your own rates (pricing page, checked on 2026-08-13).

FAQ

What does the default BYOC stack allow before I harden it?

The CloudFormation stack creates a security group that allows all egress to 0.0.0.0/0 and ingress from VPC subnet CIDRs only, default VPC network ACLs that allow all traffic, S3 and ECR endpoints for the VPC, an S3 bucket for cache data, and public subnets with optional private subnets. The six checklist items tighten that starting posture, and the defaults are listed in the AWS BYOC security hardening guide.

Does WarpBuild add IAM permissions to my runner instances?

No. The permissions available to runner instances are exactly what you provide through security groups and IAM roles or instance profiles, and WarpBuild does not inject additional permissions into runner workloads. All IAM permissions for runner workloads are managed by you through instance profiles set per custom runner.

Which outbound destinations have to stay open?

api.warpbuild.com for runner registration and lifecycle, api.github.com and github.com for the GitHub API and git operations, outbound HTTPS for runner telemetry, and any package registries your builds depend on. Stack bucket traffic is routed through the S3 endpoint the stack provisions, so it does not need a separate internet path.