Migrate from EC2 Self-Hosted Runners to Managed Runners

EC2 self-hosted runners mean Lambdas, launch templates, scaling logic, and an AMI pipeline you maintain. Managed runners give you ephemeral cloud runners with none of that AWS plumbing.

A typical EC2 runner stack - often built on terraform-aws-github-runner - uses webhooks, Lambdas, and launch templates to spin ephemeral EC2 runners. It works, but it is your AWS bill plus your maintenance. Managed runners replace the stack with a label.

What changes

Before and after

jobs:
  build:
    runs-on: [self-hosted, ec2, linux]   # your EC2 fleet
    steps:
      - uses: actions/checkout@v4
      - run: make build test

Managed equivalent

jobs:
  build:
    runs-on: latchkey-medium   # no AWS plumbing
    steps:
      - uses: actions/checkout@v4
      - run: make build test

Migration steps

1. Find workflows targeting your EC2 self-hosted labels.
2. Connect the managed-runner provider to your org.
3. Swap the label on one workflow and run in parallel.
4. Confirm parity, roll out, then stop launching EC2 runners.
5. Tear down the webhook/Lambda/launch-template stack.

Gotchas

• If jobs assumed an instance role for AWS access, switch to GitHub OIDC.
• Recreate AMI-baked tools as setup steps or a custom runner image.
• Keep the EC2 stack in place (not destroyed) until parallel runs prove parity.

What you gain

• Roughly 69% lower per-minute cost than GitHub-hosted runners.
• Warm pools remove queue time - jobs start almost immediately.
• Self-healing detects, fixes, and auto-retries transient and mechanical failures.
• Zero ops: no agents, autoscalers, or controllers to patch and babysit.

Key takeaways

• EC2 runners hide a Lambda + AMI maintenance burden.
• Managed runners replace that stack with a label.
• Switch IAM access to OIDC during the move.

Related guides