AWS: Actions Runner Controller on EKS or Fargate-Backed terraform-aws-github-runner

The two viable patterns on AWS:

1. ARC on EKS — runners are pods, scale via the AutoscalingRunnerSet CRD, scheduled onto Karpenter-managed Spot nodes. Runner pods are ephemeral, deleted after each job.
2. terraform-aws-github-runner (Philips Labs) — runners are EC2 instances or Lambda-launched containers, lifecycle-managed by Lambda functions reacting to the GitHub workflow_job webhook. No Kubernetes required.

For ARC on EKS, the runner-set definition looks like this:

apiVersion: actions.github.com/v1alpha1
kind: AutoscalingRunnerSet
metadata:
  name: opsio-eks-runners
  namespace: arc-runners
spec:
  githubConfigUrl: https://github.com/opsio/platform
  githubConfigSecret: gh-app-secret
  minRunners: 0
  maxRunners: 50
  runnerScaleSetName: linux-x64-large
  template:
    spec:
      nodeSelector:
        karpenter.sh/capacity-type: spot
        kubernetes.io/arch: amd64
      containers:
        - name: runner
          image: ghcr.io/actions/actions-runner:2.319.1
          resources:
            requests: { cpu: 4, memory: 8Gi }
            limits:   { cpu: 4, memory: 8Gi }

Runners authenticate to GitHub via a GitHub App installation, not a personal access token. Per-job AWS access uses OIDC federation: the runner's GITHUB_TOKEN exchange via aws-actions/configure-aws-credentials@v4 assumes an IAM role scoped to that workflow. No long-lived AWS credentials live on the runner.

Azure: ARC on AKS or VMSS-Backed Runners

On Azure the equivalent patterns are ARC on AKS (functionally identical to the EKS configuration above) or Azure VM Scale Sets driven by an Azure Function listening to the workflow_job webhook. AKS with Karpenter (now generally available on Azure) is our default for customers already operating AKS clusters; VMSS is the lightest-weight option for organisations that want self-hosted runners without operating Kubernetes.

For Azure-specific OIDC, the runner uses azure/login@v2 with workload identity federation:

- uses: azure/login@v2
  with:
    client-id: ${{ vars.AZURE_CLIENT_ID }}
    tenant-id: ${{ vars.AZURE_TENANT_ID }}
    subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

The trust relationship on the Entra ID app registration must allow the GitHub OIDC issuer (https://token.actions.githubusercontent.com) and scope the federated identity credential to the specific repository and branch or environment. Wildcards on this trust ("any workflow on any branch") are the most common Azure misconfiguration we see — restrict the audience and subject claims explicitly.

Customers running broader Azure DevOps estates frequently combine self-hosted runners with our azure devops services for the workflow design and migration work.

GCP: ARC on GKE or Cloud Run Jobs

On GCP, ARC on GKE follows the same shape as EKS or AKS. The newer alternative is Cloud Run Jobs running runner containers on demand — simpler to operate than GKE for organisations that don't already run Kubernetes, with cold-start times of 5-15 seconds for a fresh runner.

OIDC federation uses Workload Identity Federation: the runner exchanges its GitHub OIDC token for a short-lived GCP access token via a Workload Identity Pool. Configuration:

- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: projects/123/locations/global/workloadIdentityPools/gh/providers/gh
    service_account: gha-deploy@my-project.iam.gserviceaccount.com

Security: The Five Controls Every Self-Hosted Runner Needs

Self-hosted runners are arbitrary code-execution environments. The five controls below are non-negotiable in any production deployment:

1. Ephemeral runners only — never persist state between jobs. ARC and the terraform-aws-github-runner module both default to ephemeral; do not turn this off
2. Network egress restrictions — runners should only reach the registries, package mirrors, and cloud APIs they need. Blanket internet egress is how supply-chain attacks reach you
3. Short-lived credentials only — OIDC federation, never PATs or long-lived service-account keys on the runner filesystem
4. Repository allowlist — runner groups should only accept jobs from explicitly named repositories, not "any repo in the org"
5. No public-fork acceptance — never run unreviewed PRs from public-fork contributors on self-hosted runners. Use the workflow_run pattern to separate untrusted execution from trusted deploy

The fifth control is the one most teams skip — and it is the one that has caused most of the publicly disclosed self-hosted-runner compromises (including the well-known 2023 incident on a major OSS project).

Operational Costs at Steady State

A typical mid-market customer (50 engineers, 200 PRs/week, mixed test suites) running ARC on EKS-Karpenter-Spot in eu-west-1 spends roughly:

• Compute: $400-900/month (vs. $2,500-4,500 on managed runners)
• EKS control plane: $73/month per cluster
• Karpenter, ARC, observability stack: bundled into existing platform overhead

The break-even on the migration effort is typically 2-4 months. Beyond that, self-hosted is pure savings, and you also gain the VPC and compliance properties as side effects.

How Opsio Helps

Opsio's managed github actions service deploys self-hosted runners with the security and autoscaling configuration above as a managed offering on AWS, Azure, or GCP. Most engagements run 6-10 weeks: discovery and workload classification, runner topology design, ARC deployment, OIDC federation rollout, and a documented operating model the customer's platform team owns afterwards. For customers running broader cloud platforms underneath the runner fleet, we also operate aws cloud delivery and devops services on top of which the runner infrastructure runs.

For hands-on delivery, see cloud solutions services.