Can our use case for the legacy runner be built with the new setup?

[joerg]

Hi,

We have built a setup with the legacy runner which works very well for us and I wanted to ask if our requirements can be built with the new runner setup.
So what we do is, that we run the now legacy ARC in AWS EKS with a Fargate Profile for the runners. The core idea is that we have no or very little base costs and can still have high performance runners on-demand available. Everything is set up by Terraform and stateless, so we can destroy and recreate everything from scratch at any time.
So there is module to set up EKS with the controller and then we have a module to set up runners for us which looks like this:

module "service_account" {
  source = ...
  name   = "example_role_name"
  role_policy_arns = ["arn:aws:iam::aws:policy/AdministratorAccess"]
}

module "runner" {
  source   = ....

  github_org      = "<org-name>"
  github_repo     = "<repo-name>"
  runner_labels   = ["label1", "label2"]

  service_account = module.service_account
}

What this allows us are a few core features that we quite like:

• Scale to absolute zero. Unless there is a job not a single pod is running except for the controller.
• Every runner and every github repository can have its own Service Account with an attached IAM Role, so we can hand out AWS permissions very granular.
• Label selectors allow selecting only the runner we want/need right now. One job can run on a strong container with a lot of CPUs and RAM, while the other might run on a weak one.

Can this be achieved with the new controller version? As far as I understood it, every runner definition will spin up a listener pod which will have a certain base cost since we are running in AWS Fargate. And the documentation says there are no more label selectors which is also quite strange to me.