RunsOnの代替：フルマネージドで自己修復するGitHub Actionsランナー
RunsOnは自社のAWS内にランナーが欲しい場合に最適です。AWSをまったく運用したくないなら、主な代替はフルマネージドのランナーサービスです。
RunsOnのドキュメントによれば、RunsOnはライセンスの下で自社のAWSアカウント内で実行されるセルフホストのGitHub Actionsランナーで、"Kubernetesなし、管理すべきコントローラーなし"で、EC2/S3はマークアップなしで直接あなたに請求されます（runs-on.com）。これは自社クラウドでのデータ所在地と最も低い生のスポットコンピュート価格が欲しい場合に理想的です。トレードオフは、CloudFormationスタック、IAM、VPC、スポットキャパシティ、AWSのクォータを運用することです。その運用面が代替を探している理由なら、Latchkeyのようなフルマネージドサービスはそれを完全に取り除き、自己修復を追加します。選ぶ前に、runs-on.comで現在のRunsOnの価格とサポートされるランナーを確認してください。
各モデルが適する場面
| RunsOn（自社AWS内でセルフホスト） | Latchkey（フルマネージド） | |
|---|---|---|
| AWSアカウントが必要 | はい（RunsOnのquickstart） | いいえ |
| スタックを自分で運用 | はい（CloudFormation / Terraform） | いいえ |
| 自社クラウドでのデータ所在地 | はい（RunsOnのドキュメント） | マネージド |
| 生のコンピュートコスト | 最も低い（自社AWSのスポット、マークアップなし） | 低い、分単位 |
| 自己修復による障害対応 | なし | あり |
| 無制限のin-VPC S3キャッシュ | はい（"Magic Cache"、RunsOnのドキュメント） | 組み込みキャッシュ |
RunsOnが本当に優れている点
RunsOnには挙げるに値する本物の強みがあります。ランナーはデータ所在地のために自社のAWSアカウント内に置かれ、"Magic Cache"はキャッシュごとの10GB上限なしの無制限のin-VPC S3キャッシュと無料のin-VPC帯域幅を提供し（runs-on.com/caching/s3-cache-for-github-actions）、x64、ARM64、GPU、NVMeにわたって1から896 vCPUまでの巨大なインスタンス範囲をサポートし（runs-on.com/runners）、分単位のマークアップなしでAWSに直接支払います。自社クラウドと最も低い生スポットコストを望むチームにとって、これは強力なパッケージです。
マネージドの代替を選ぶべき場合
- CloudFormationスタック、IAMロール、スポットキャパシティ、AWSのクォータを運用したくない。
- そもそも自社のAWSアカウント内でランナーを実行したくない。
- 一時的および機械的な障害を、呼び出しを受けたり手動の再実行を強いられたりするのではなく、自動的に自己修復させたい。
Latchkeyが追加するもの
Latchkeyはフルマネージドなので、運用すべきAWSアカウント、スタック、スポットキャパシティはありません。自己修復型のCIを追加します。メモリ不足、ディスクフル、レジストリのタイムアウトの障害は自動的に検出、修正、リトライされます。標準のGitHub Actionsランナーを使うため、切り替えはruns-onを1行変更するだけです。
結論
自社AWS内のランナーと最も低い生スポットコストが運用の手間を上回るなら、RunsOnが正しい選択です。逆のトレードを望むなら、AWSアカウントなし、スタックなし、すべてのジョブで自己修復があり、Latchkeyがフルマネージドの代替です。無料で始めて、実際のパイプラインでベンチマークしましょう。