はじめに
IP制限されたサーバーにファイルをデプロイしたいケースがあります。
特に GitHubからのCI/CDフローでSFTP接続 したい場合、通常のGitHub Actionsランナーでは固定IPを持たないため、そのままでは接続できません。
この記事では、3つの構成パターン を紹介し、それぞれのメリット・デメリットを整理します。
前提条件
- デプロイ対象は静的ファイル（HTML/CSS/JSなど）
- デプロイ先サーバーはIP制限あり
- GitHub ActionsやCI/CDから自動でデプロイしたい
- SFTP接続でファイルをアップロード
パターン1：踏み台サーバー（インスタンス）経由
構成イメージ
GitHub Actions
↓
Self-hosted Runner（ビルド兼踏み台サーバー）
↓
デプロイ先サーバー（IP制限あり）
概要
- 任意のサーバーに固定IPを付与
- サーバーを GitHub Self-hosted Runner として登録
- 単純に踏み台サーバーを用意して、Actions経由でビルドスクリプトを実行する形式でもOK
- 注意）Self-hosted Runnerは必ずPrivate Repositoryで使用してください
- サーバー内でビルド & SFTPアップロードを実行
補足: ビルド兼踏み台サーバーには何を使う？
小規模なら GCP Compute Engine の無料枠（e2-microなど）に収まるのでGCPで良いかと思います。（構築が面倒ならさくらとかでもあり？）
GCP 無料枠の詳細
補足2: ビルドとデプロイの役割分離
低スペックマシンではビルドに時間がかかる場合があります。
その場合は以下のように役割を分離すると良いと思います。
- ビルド: 高性能な GitHub-hosted Runner でビルド
- 成果物: ビルド成果物を upload-artifact で保存
- デプロイ: Self-hosted Runner（固定IPの踏み台）で download-artifact し、SFTPでアップロード
メリット
- 簡単な構成で実装可能
- 小規模・低頻度アクセス向きでコストが低い
- OSやネットワーク設定を自由にカスタマイズ可能
デメリット
- インスタンスの管理・保守が必要
- 高性能サーバーを常時稼働させる場合、コストは割高
パターン2：踏み台サーバー（コンテナ）経由
構成イメージ
GitHub Actions
↓
コンテナサービス（ECS / Cloud Run / Azure Container Instances）
↓
NAT Gateway + 固定IP
↓
デプロイ先サーバー（IP制限あり）
概要
- GitHub Actionsからコンテナサービスを実行
- コンテナサービスの外向き通信を NAT Gateway 経由にして固定IP化
- コンテナ内でビルド & SFTPアップロードを実行
補足1: コンテナサービスの選択
・AWS ECS、Azure Container Instances、GCP Cloud Run などがあると思います。
・料金・構成はほぼ同等で、NAT Gatewayに固定IPを割り当てる構成は共通です。
補足2: コンテナの実行トリガー
・GitHub Actionsからコンテナを実行するには、各クラウドのCLI（aws ecs run-task や gcloud run jobs execute など）をワークフロー内から呼び出す必要があります。
・aws-actions/configure-aws-credentials のような公式の認証Actionが提供されています。
メリット
- サーバーレスで保守負荷が軽い
- 短時間・高負荷のビルドに向く（常駐サーバー不要）
デメリット
- 構成がやや複雑
- NAT Gatewayのコストがかかる
- AWS / GCP / Azuleを比較しましたが概ね月35$前後でした。
パターン3：デプロイサービス利用
構成イメージ
GitHub Actions
↓
CI/CDサービス（CircleCIなど）
↓
デプロイ先サーバー（IP制限あり）
概要
- 固定IPをサポートしているCI/CDサービスを利用
- サービス側で SFTPアップロードを実行
補足: CI/CDサービス例
- CircleCI: 「IP Ranges」で固定IPレンジを割り当て可能（Performanceプラン）
-
GitHub hosted runner: 「Larger runners」で固定IPレンジを割り当て可能（Enterprise Cloudプラン）
- 注意）90日以上使用されないとIPレンジはリセットされる
メリット
- 自前サーバー不要
- CI/CDフローをサービス側で完結可能
デメリット
- 複数の固定IPを許可する必要がある場合がある
- サービス利用料が発生
選び方
| パターン | 向いているケース | コスト | 管理 | 特徴 |
|---|---|---|---|---|
| 踏み台サーバー（インスタンス） | 小規模・低頻度デプロイ | 低（インスタンス料金のみ） | 中（インスタンスの保守・管理が必要） | 設定自由度が高く、固定IP管理も簡単 |
| 踏み台サーバー（コンテナ） | 高負荷ビルド、短時間デプロイ | 中（NAT Gateway + コンテナ料金） | 中〜低（サーバーレスで保守負荷軽減） | 短時間稼働向き、サーバーレスでスケーラブル |
| デプロイサービス利用 | 自前サーバー管理を避けたい場合 | 中〜高（サービス利用料） | 低（サーバー管理不要） | 自前サーバー不要 |
まとめ
今回は小規模な静的サイトのデプロイを前提として検討したため、料金や構築の簡単さの面で パターン1（インスタンス） が最も優れていると思いました。
特に「補足2」の役割分離を行えば、コストとパフォーマンスを両立しやすいです。
NAT Gatewayの固定費（月35$前後）を許容できるなら パターン2（コンテナ） を採用し、サーバー管理から解放されるメリットを享受する方が良いかもしれません
パターン3 は最も簡潔な構成で済みますが、思ったよりも料金や仕様的な制約が強く、選択肢としてはやや微妙でした。