potiuk opened a new pull request, #82: URL: https://github.com/apache/airflow-ci-infra/pull/82
The CloudFormation stack places RunsOn runners only in use2-az1 and use2-az2, and its template has no parameter to change that. On 2026-10-30 those were the worst zones in us-east-2 for the runners' instance families (Spot placement score 1 in each, against 9 in use2-az3 for x64 8-16 vCPU). From 2026-10-25 to 2026-10-30, AWS reclaimed 911 of 16,145 Spot runners (5.6%), with a median of 7 minutes after launch, and 30% of runners ran on-demand. apache/airflow#76084 already dropped the instance families reclaimed most often. This PR adds the missing zone. `terraform/runs-on-flex` deploys the same runners from RunsOn's Terraform module (Flex, v3.5.1) into a new VPC (10.3.0.0/16) with a public subnet in each of the three zones. The subnets are pinned by zone ID. It runs as a second stack with environment `flex`, so it takes only jobs labelled `env=flex`. The CloudFormation stack keeps running until the jobs of apache/airflow move; a separate change then removes it. The setup steps (license-key parameter, second GitHub App installed by ASF Infra, moving the labels) are in the module's README. Unlike the CloudFormation flow, the apply role creates the resources itself. `terraform/runs-on-access/runs-on-flex.tf` gives it AdministratorAccess with these denies: - IAM writes are allowed only on `runs-on-flex-*` roles, and only with the `runs-on-flex-boundary` permissions boundary. - It may attach only the two AWS-managed policies the module uses. - S3 is limited to the stack's cache bucket and its own state. - It cannot assume other roles. - It works only in us-east-2. The Terraform roles are named `runs-on-terraform-flex-*`, outside the stack prefix, so the apply role cannot remove its own guardrails. The plan role has ReadOnlyAccess, because refreshing the module reads across a dozen services. Its denies block other objects in the state bucket, decryption of SSM parameters and Secrets Manager values. Changes to this module therefore deserve the same review as changes to the access roles; the README says so. `terraform/runs-on-access` must be applied by an account admin before the new workflow can plan. Checks run: `terraform fmt` and roborev. Roborev's finding that the apply role matched its own IAM pattern is fixed by the role rename above. Not yet run: `terraform init` / `terraform validate`. `terraform/runs-on-flex/.terraform.lock.hcl` follows in a separate commit, and the workflow's `-lockfile=readonly` init fails until it lands. --- Generated-by: Claude Code (Claude Opus 5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
