SYNON › 記事 › Cloudflare・インフラ

AWS Client VPN → Cloudflare Zero Trust
社内システム接続基盤 移行計画書

約50クライアントのVPN接続を、Cloudflare WARP + Cloudflare Tunnel による Zero Trust 構成へ移行するための計画・設定手順書

作成日: 2026-08-12 対象: 社内Webシステム (HTTP/HTTPS) プラン: Zero Trust Free (〜50ユーザー) 独自ドメイン: 不要構成

1移行の背景と方針

現在、社内システムへのアクセスは AWS Client VPN でクライアントを制限しています。クライアント数が50に近づき、証明書配布・接続管理の運用負荷とVPN利用料が増加しているため、Cloudflare Zero Trust(WARPクライアント + Cloudflare Tunnel)へ移行します。

要件と採用構成の対応

要件Cloudflareでの実現方法
アクセス対象は社内Webアプリ (HTTP/HTTPS)Cloudflare Tunnel のプライベートネットワークルーティングでEC2のプライベートIPへ到達
接続元を「アプリを入れた端末」だけに限定したいWARPクライアントを各端末にインストールし、組織 (チーム) に登録済みの端末のみ通信を許可
ユーザー単位の認証WARP登録時にメールアドレス認証 (ワンタイムコード)。会社メールアドレスを持つ人だけが登録可能
EC2はインバウンドを開けたくない (現状: 外向きのみ)Tunnel は EC2 から外向きにのみ接続を張る方式。インバウンドポート開放は一切不要
独自ドメインは使いたくないプライベートIP直アクセス構成のためドメイン登録不要。Cloudflareが払い出す「チームドメイン」(例: synon.cloudflareaccess.com) のみ使用
コストを抑えたいZero Trust Freeプラン (50ユーザーまで無料) で開始
⚠ 認証方式についての重要な注意 Cloudflare単体には「メールアドレス + パスワード」という認証方式はありません。標準はメールアドレス宛のワンタイムコード (One-time PIN) 方式です (パスワード不要でメール受信できる人だけがログイン可能)。パスワード方式が必須の場合は Google Workspace / Microsoft Entra ID などの外部IdPを後から連携できます。本書ではまず One-time PIN で構築し、「接続元の限定」は WARPアプリ導入済み端末のみ許可で担保する設計とします。

2現状構成と移行後構成

現状: AWS Client VPN 構成

社内クライアント 約50台 VPNクライアント クライアント証明書 .ovpn 設定ファイル AWS (VPC) Client VPN エンドポイント 相互TLS認証 (証明書) サブネット関連付け課金 接続時間課金 EC2 インスタンス 社内Webアプリ (顧客向けサービスと同居) Private IP: 10.0.1.10 (例) インバウンド: VPN経由のみ OpenVPN接続 VPC内通信 課題: 証明書の発行・配布・失効管理の負荷 / クライアント増でVPN接続コスト増 / 端末単位の可視性が低い
図1: 現状構成 — AWS Client VPN による社内アクセス

移行後: Cloudflare WARP + Tunnel 構成

社内クライアント 約50台 WARP クライアント (無料アプリ) メールコードで組織登録 証明書配布は不要に Cloudflare グローバル網 Zero Trust (認証・ポリシー) 誰が・どの端末が・どこへ を判定 Gateway (通信フィルタ) 10.0.0.0/16 宛の通信を制御 Tunnel 終端 EC2からの常時接続を受付 AWS (VPC 10.0.0.0/16) EC2 インスタンス cloudflared (Tunnelコネクタ) 社内Webアプリ 10.0.1.10:443 (例) インバウンド開放: ゼロ 外向き接続のみ (現状維持) 暗号化トンネル (WireGuard/MASQUE) EC2から外向きに接続 TCP/UDP 7844 ポイント: クライアントは「WARPアプリ + メール認証」だけ。EC2は外向き接続のみでインバウンド開放ゼロ。 独自ドメイン不要 (プライベートIP 10.0.1.10 に今まで通りアクセス)。50ユーザーまで無料。
図2: 移行後構成 — Cloudflare WARP + Tunnel によるプライベートネットワークアクセス
ℹ アクセス方法は今までとほぼ同じ 移行後もユーザーはブラウザで http://10.0.1.10 (または社内アプリのプライベートIP/ポート) を開くだけです。WARPが有効な端末からの通信だけが Cloudflare 経由で Tunnel を通り EC2 に届きます。WARPを入れていない端末からは一切到達できません。

3仕組みの理解 (Tunnel / WARP)

移行の核となる2つのコンポーネントの動きを整理します。

Cloudflare Tunnel — インバウンドを開けずに公開する仕組み

EC2 (VPC内) cloudflared デーモン systemdで常駐 セキュリティグループ インバウンドルール: なし Cloudflare エッジ 世界中のデータセンターで Tunnel接続を待ち受け ユーザーからの通信を 確立済みトンネルへ折返し ① EC2 側から外向きに常時接続を確立 宛先: Cloudflare網 TCP/UDP 7844 (アウトバウンドのみ) ② ユーザーの通信は確立済みトンネルを逆流して届く 新規のインバウンド接続は発生しない
図3: Cloudflare Tunnel の接続方向 — すべてEC2側から始まる外向き接続

ファイアウォールやセキュリティグループの観点では、現在の「外向きのみ」ポリシーを一切変えずに済むのがこの方式の最大の利点です。AWS Client VPN のようにVPC側に受け口(エンドポイント)を作る必要がありません。

WARP — クライアント側の「鍵」になるアプリ

WARP は Cloudflare が無償配布するクライアントアプリ (Windows / macOS / Linux / iOS / Android 対応) です。組織の「チーム名」を入力してメール認証すると端末が組織に登録され、以後その端末の通信のうち社内宛て (例: 10.0.0.0/16) だけが Cloudflare 経由でトンネルにルーティングされます。

AWS Client VPN (現状)WARP (移行後)
端末の特定方法クライアント証明書を手動配布アプリ導入 + メール認証で端末登録 (証明書配布不要)
ユーザーの特定証明書=端末単位 (人の特定は別管理)メールアドレス単位で人を特定、ログに記録
接続操作都度VPNクライアントで接続常時ON可 (自動再接続)。一般Web閲覧は直接通信のまま
失効 (退職者対応)証明書失効リスト (CRL) 更新が必要管理画面でユーザー/端末を失効させるだけ

4認証とアクセス制限の設計

「誰が」「どの端末で」アクセスできるかを、次の3層で制限します。

ユーザー / 端末 Cloudflare EC2 (社内アプリ) WARPアプリを起動し チーム名を入力 登録ポリシーを確認し メールにコード送信 受信したコードを入力 → 端末が組織に登録される 以後の 10.0.0.0/16 宛通信を Gatewayポリシーで検査 (許可ユーザーのみ通過) http://10.0.1.10 へアクセス Tunnel経由で転送 社内アプリが応答 (既存のアプリ側認証はそのまま) WARP未導入端末は 10.0.1.10 に到達不可 (経路自体が存在しない)
図4: 登録〜アクセスまでの流れ (シーケンス)

3層の防御

層制限内容設定場所
① 端末登録制限会社メール (例: @synon.co.jp) を持つ人しかWARPを組織登録できないSettings → WARP Client → Device enrollment permissions
② 経路の限定社内システムへの経路はWARP登録済み端末にしか存在しない (インターネットから直接到達不能)Tunnel の Private Network 設定 + Split Tunnels
③ 通信ポリシー登録済み端末でも、Gatewayポリシーで許可したユーザーの通信だけがEC2に届く。退職者は即時失効Gateway → Firewall policies → Network
✓ 「アプリを入れた端末だけに限定したい」の実現 上記②により、WARPアプリ未導入の端末には社内システムへの経路そのものがありません。さらに①でアプリを入れられる人を会社メール保有者に限定し、③で個人単位の許可/失効を管理します。将来的にはデバイスポスチャ (OSバージョンやディスク暗号化の有無で制限) も追加できます。

5移行計画 (フェーズとスケジュール)

既存のAWS Client VPNを止めずに並行稼働させ、段階的に切り替えるリスク最小の計画です。

第1週 Phase 0: 準備 アカウント作成 チーム名決定 対象CIDR整理 利用者リスト作成 第1〜2週 Phase 1: 基盤構築 Cloudflare設定 (§6) EC2にcloudflared (§7) 既存VPNは稼働継続 ← 影響ゼロで構築可 第2〜3週 Phase 2: パイロット 管理者+3〜5名で検証 全業務画面の疎通確認 速度・安定性の確認 手順書の修正 第3〜5週 Phase 3: 全体展開 WARPを全端末へ配布 部署単位で順次移行 移行済ユーザーの VPN利用を停止 第6週 Phase 4: VPN廃止 1週間の安定稼働確認後 Client VPN削除 (§9) VPNコスト削減 完了 切り戻し戦略: Phase 3 完了まで AWS Client VPN を残すため、問題発生時はVPN接続に戻すだけで即復旧できる (Cloudflare側の構築・検証は既存環境に一切影響しない)
図5: 移行フェーズ — 約6週間の並行稼働方式
フェーズ作業内容担当完了条件
Phase 0
準備		Cloudflareアカウント作成、チーム名決定、対象システムのIP/CIDR一覧化、利用者50名のメールアドレスリスト作成情シスリスト確定
Phase 1
基盤構築		§6 Cloudflare設定 + §7 EC2設定。既存VPNに影響なし情シス管理者端末からWARP経由で社内アプリ表示
Phase 2
パイロット		3〜5名の先行ユーザーで2週間程度実業務利用情シス+先行ユーザー業務影響なしを確認
Phase 3
全体展開		部署単位でWARP導入案内 (§8 の手順書を配布)。ヘルプデスク対応情シス+各部署50クライアント全員がWARP経由に移行
Phase 4
VPN廃止		1週間の安定稼働後、§9 の手順でClient VPN削除情シスVPN課金停止を請求書で確認

6Cloudflare側の設定手順 Cloudflareダッシュボード

所要時間の目安: 約1〜2時間。ダッシュボードのメニュー名は Cloudflare One (Zero Trust) 管理画面 (one.dash.cloudflare.com) のものです。UIは更新されることがあるため、名称が近いメニューを探してください。

6-1. アカウント作成とチーム名の決定

Cloudflareアカウントを作成dash.cloudflare.com/sign-up から会社メールアドレスで登録します (クレジットカード不要)。
Zero Trust (Cloudflare One) を有効化ダッシュボード左メニューの「Zero Trust」を開き、チーム名 (team name) を決めます。例: synon → チームドメインは synon.cloudflareaccess.com になります。これはCloudflareが払い出すもので、独自ドメインの取得・移管は不要です。
Freeプランを選択プラン選択画面で Free (50ユーザーまで無料) を選びます。支払い情報の登録は求められる場合がありますが、50ユーザー以内なら課金されません。

6-2. デバイス登録ポリシー (誰がWARPを組織登録できるか)

認証方式 One-time PIN を有効化Zero Trust → Settings → Authentication → Login methods で「One-time PIN」を追加します (デフォルトで有効な場合はそのまま)。
登録許可ルールを作成Zero Trust → Settings → WARP Client → Device enrollment permissions → Manage でポリシーを追加:
・Rule name: 社員のみ登録許可
・Action: Allow
・Include: Emails ending in = @synon.co.jp
会社ドメイン以外のメールアドレス (例: 委託先) を許可する場合は Emails で個別アドレスを列挙します。
ℹ ここが「入口の鍵」このルールに合致するメールアドレスでコード認証できた端末だけが組織に登録されます。50名の利用者リスト (Phase 0) がそのまま許可対象になります。

6-3. Tunnel の作成

Tunnelを新規作成Zero Trust → Networks → Tunnels → Create a tunnel → コネクタ種別は cloudflared を選択 → Tunnel名を入力 (例: aws-vpc-tokyo)。
インストールコマンドをコピー作成画面に、トークン入りのインストールコマンドが表示されます (例: sudo cloudflared service install eyJh...)。これを§7でEC2に投入します。トークンは秘密情報として扱ってください。
Private Network ルートを追加Tunnel設定の Private Network タブで、社内システムのCIDRを追加します。
・最小構成: EC2単体なら 10.0.1.10/32 (対象IPのみ)
・VPC全体を対象にする場合: 10.0.0.0/16
必要最小限のCIDRで登録するのが安全です。

6-4. Split Tunnels 設定 (最重要・ハマりポイント)

⚠ デフォルトでは社内宛の通信がWARPを通りませんWARPの初期設定 (Excludeモード) では、プライベートIP帯 (10.0.0.0/8 など RFC1918 全体) が「WARPを通さない」除外リストに入っています。ここを直さないと「設定したのに繋がらない」状態になります。
Split Tunnels 設定を開くZero Trust → Settings → WARP Client → Device settings → Default プロファイル → Configure → Split Tunnels → Manage。
対象CIDRを除外リストから外すExcludeモードのリストから 10.0.0.0/8 を削除し、代わりに使っていない細分化されたレンジ (例: 10.128.0.0/9 など、自社VPCの 10.0.0.0/16 を含まない範囲) を再追加します。これで「10.0.0.0/16 宛だけWARPを通し、他は今まで通り」になります。
クライアント端末 WARP (Split Tunnel) 宛先で経路を振り分け 10.0.0.0/16 宛 → Cloudflare経由でEC2へ 社内システムの通信だけトンネルに入る その他のインターネット通信 → 従来どおり直接 YouTube等の一般通信は速度影響なし
図6: Split Tunnels — 社内宛だけをWARPに通す振り分け

6-5. Gateway ネットワークポリシー (許可ユーザーの制御)

許可ポリシーを作成Zero Trust → Gateway → Firewall policies → Network → Add a policy
・Policy name: 社内システム許可
・Traffic: Destination IP in 10.0.0.0/16 AND User Email matches regex .*@synon\.co\.jp
・Action: Allow
全拒否ポリシーを作成 (許可の下に配置)
・Policy name: 社内システム宛その他拒否
・Traffic: Destination IP in 10.0.0.0/16
・Action: Block
ポリシーは上から順に評価されるため、Allow を Block より上に置きます。
動作確認登録済み端末のブラウザから http://10.0.1.10 (社内アプリ) にアクセスして表示されること、WARPをOFFにすると繋がらないことを確認します。Zero Trust → Logs → Gateway → Network で通信ログにユーザーのメールアドレスが記録されていることも確認できます。

6-6. (任意) セキュリティ強化オプション

オプション効果設定場所
デバイスポスチャOSバージョン・ディスク暗号化・ファイアウォール有効などの条件を満たす端末のみ許可Settings → WARP Client → Device posture
セッション有効期限再認証を定期的に要求 (例: 1週間ごと)Settings → WARP Client → Device enrollment → Session duration
外部IdP連携Google Workspace / Microsoft Entra ID のパスワード+MFA認証に切替可能Settings → Authentication → Login methods

7EC2 (AWS) 側の設定手順 AWSコンソール / SSH

EC2側の作業は「cloudflaredのインストール」だけです。セキュリティグループのインバウンド開放は不要で、既存構成への変更は最小限です。

7-1. cloudflared のインストール

Tunnel作成画面 (§6-3) に表示されたコマンドをそのまま実行するのが最も簡単です。手動でインストールする場合:

Amazon Linux 2023 / RHEL系の場合:

# cloudflared をダウンロードしてインストール
curl -L -o cloudflared.rpm \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm
sudo rpm -i cloudflared.rpm

# バージョン確認
cloudflared --version

Ubuntu / Debian系の場合:

curl -L -o cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

7-2. Tunnel コネクタとしてサービス登録

# §6-3 でコピーしたトークン入りコマンドを実行 (systemdサービスとして常駐化)
sudo cloudflared service install eyJhIjoi...(ダッシュボードに表示されたトークン)

# 稼働確認
sudo systemctl status cloudflared
# → active (running) であればOK。ダッシュボード側でもTunnelが HEALTHY 表示になる

# OS起動時の自動起動を確認 (service install で自動設定される)
sudo systemctl is-enabled cloudflared
ℹ IPフォワーディングEC2自身のアプリ (localhost/自IP) だけに繋ぐ場合は不要ですが、同一VPC内の他のサーバーにもトンネル経由で到達させる場合は、EC2がルーターとして動くため次を設定します:
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-cloudflared.conf && sudo sysctl --system

7-3. セキュリティグループの変更

変更前 (Client VPN 用) インバウンドルール HTTP/HTTPS 許可 (ソース: Client VPN のSG/CIDR) SSH 許可 (ソース: Client VPN のSG/CIDR) アウトバウンドルール 全許可 (0.0.0.0/0) — 外向きのみ運用 変更後 (Cloudflare Tunnel 用) インバウンドルール なし (全削除でOK) ※ VPN用の許可ルールは Phase 4 で削除 アウトバウンドルール 全許可のまま / 絞る場合は TCP・UDP 7844 + 443 を許可
図7: セキュリティグループの変更 — インバウンドは最終的にゼロにできる
タイミング作業
Phase 1 (並行稼働中)変更なし。cloudflaredは既存のアウトバウンド全許可で動作します。追加の穴あけは不要。
Phase 4 (VPN廃止時)Client VPN 向けのインバウンド許可ルールを削除。インバウンドルールは空にできます。
さらに絞る場合 (任意)アウトバウンドを TCP 7844 / UDP 7844 / TCP 443 (cloudflared用) + アプリが必要とする通信のみに限定。
✓ その他のAWS設定は変更不要ルートテーブル、NACL、サブネット構成、NAT Gateway等は一切変更不要です。cloudflaredは通常のアウトバウンドHTTPS通信と同様に動作します。

8クライアント端末側の手順 利用者向け配布手順

利用者に配布する手順です。1台あたり約5分で完了します。

WARPアプリをインストールWindows / macOS: one.one.one.one または情シス配布のインストーラから「Cloudflare One (WARP)」をインストール。スマホは App Store / Google Play で「1.1.1.1」を検索。
組織 (チーム) にログインアプリの 設定 → アカウント → 「Cloudflare Zero Trust にログイン」 を選び、チーム名 synon (§6-1で決めた名前) を入力。
メール認証ブラウザが開くので会社のメールアドレスを入力 → 届いた6桁前後のコードを入力。これで端末が組織に登録されます。
接続をONにするアプリのスイッチをONにする (以後は自動接続)。タスクトレイ/メニューバーのアイコンがオレンジの「Zero Trust」表示になっていればOK。
動作確認ブラウザで社内システム (例: http://10.0.1.10) を開いて表示されることを確認。従来のVPN接続はOFFのままにしてください。
ℹ 一斉配布する場合 (MDM)Jamf / Intune などのMDMを利用している場合は、チーム名を埋め込んだ設定ファイル (mdm.xml / plist / レジストリ) と共にWARPを配布すれば、利用者はメール認証だけで済みます。手動配布でも上記5ステップで完了します。

9AWS Client VPN の廃止手順 AWSコンソール

Phase 3 完了後、1週間程度の安定稼働を確認してから実施します。削除した時点でVPN経由のアクセスはできなくなるため、全員の移行完了を必ず確認してください。

接続状況の最終確認VPCコンソール → Client VPN エンドポイント → 接続 タブで、アクティブな接続が無いこと (全員がWARPに移行済み) を確認します。
ターゲットネットワークの関連付け解除対象エンドポイント → ターゲットネットワークの関連付け タブ → 関連付けを選択して 関連付け解除。この時点でサブネット関連付けの時間課金 (約$0.15/時) が停止します。
エンドポイントの削除承認ルール・ルートが残っていても、関連付け解除後にエンドポイント自体を 削除 できます。
証明書のクリーンアップACM に登録したサーバー証明書/クライアントCA証明書のうち不要なものを削除。社内の証明書配布物 (.ovpnファイル等) の破棄も案内します。
セキュリティグループ整理§7-3 のとおり、Client VPN 向けインバウンドルールを削除します。
課金停止の確認翌月の請求書 (Cost Explorer) で Client VPN の課金が消えていることを確認します。

10コスト比較

東京リージョンのAWS Client VPN料金と、Cloudflare Zero Trust Freeプランの比較です (概算・50クライアント想定)。

AWS Client VPN (現状)Cloudflare Zero Trust Free (移行後)
基本料金サブネット関連付け 約$0.15/時 × 730時間 ≒ 約$110/月$0 (50ユーザーまで)
接続課金約$0.05/時/接続。例: 50人 × 平日8時間 (約170h/月) ≒ 約$425/月$0 (接続時間・データ量の課金なし)
データ転送VPN経由のアウト転送に通常のDTO課金Tunnel経由のEC2アウト転送は通常のDTO課金 (同等)
月額合計 (概算)約$500〜550/月$0 (EC2側の通常料金を除く)
51ユーザー以上になった場合—Pay-as-you-go 約$7/ユーザー/月 (年払い) に移行
⚠ 概算値についての注意AWS料金は利用実態 (接続時間・関連付けサブネット数) により変動します。正確な現状コストは Cost Explorer で「Client VPN」のタグ/サービスをフィルタして確認してください。Cloudflareの価格は変更される可能性があるため、契約前に公式の料金ページで最新価格を確認してください。

11注意点・リスクと運用

移行時の注意点

項目内容と対策
Freeプランの50ユーザー上限現在「50クライアント近く」のため上限ぴったり。ユーザー数=登録メールアドレス数です。増員が見えたら Pay-as-you-go (約$7/ユーザー/月) への切替を予算化しておく。それでもVPN費用より安価な水準。
ログ保持は24時間 (Free)Gatewayログの保持が短いため、監査要件がある場合はLogpush (有料) か、アプリ側のアクセスログで補完する。
Split Tunnels 設定漏れ§6-4 を忘れると「繋がらない」の典型原因。トラブル時は最初にここを確認。
cloudflared の単一障害点EC2 1台の cloudflared が止まると全員アクセス不可。同じトークンで2台目 (別AZの小型インスタンス等) にもインストールするとレプリカとして自動冗長化される。最低でも systemd の自動再起動 (デフォルト有効) を確認。
メール受信への依存One-time PIN はメールが届かないとログイン不可。メールサーバー障害時の代替手段 (管理者によるバイパス等) を決めておく。
社内DNS名でアクセスしている場合IP直ではなく http://kintai.internal のような内部ホスト名を使っている場合は、Gateway の Local Domain Fallback / リゾルバポリシーの追加設定が必要。パイロットで洗い出す。
顧客向けサービスへの影響本構成は社内アクセス経路の変更のみで、同居する顧客向けサービスの経路には影響しない。ただしcloudflared導入時のリソース消費 (通常は軽微) を監視する。

日常運用

運用作業手順
利用者の追加①登録許可ルールの対象なら追加作業ゼロ (本人がWARP登録するだけ)。②個別アドレス指定方式なら Device enrollment permissions にアドレス追加。
利用者の削除 (退職時)Zero Trust → My Team → Users → 対象ユーザーを Revoke。端末のWARPは即座に組織から切断される。メールアカウント自体の停止も併せて実施。
接続状況の確認My Team → Devices で端末一覧・最終接続時刻を確認。Logs → Gateway で通信ログ (誰がどこへ) を確認。
cloudflared の更新数か月に一度 sudo yum update cloudflared (または apt) 実施。Tunnelのヘルスはダッシュボードで監視。

将来の拡張

本構成を土台に、次の拡張が追加設定だけで可能です: SSH/RDPのブラウザ経由アクセス、Google Workspace / Entra ID とのSSO連携 (パスワード+MFA認証への切替)、デバイスポスチャによる端末健全性チェック、顧客向けサービスのCloudflare WAF/CDN化 (この場合はドメインが必要)。