2026.09.23 インフラ

AWS Client VPNとは？認証3方式の選び方とCLI・Terraform構築手順

AWS Client VPNとは？認証3方式の選び方とCLI・Terraform構築手順

AWS Client VPNは、手元の端末からVPC内やオンプレミス側のリソースへOpenVPNベースのクライアントで接続するマネージド型のリモートアクセスVPNです。仮想アプライアンスを自分で建てずに済む反面、認証方式の選択・認可ルールの設計・スプリットトンネルの扱いという3か所で設計判断を求められ、ここを飛ばすと「接続はできるのに何も届かない」状態から抜け出せなくなります。この記事では公式ドキュメントで確定できる数値を基に、エンドポイントの構成要素、認証3方式の要件、AWS CLIとTerraformでの構築コード、つながらないときの切り分けを実装者の目線で整理する構成です。拠点間接続との比較や月額の全体像はAWS VPNの料金と構築手順で扱っています。

まとめ：Client VPNは認証方式と認可ルールで運用の形が決まる

Client VPNの設計で後から取り返しにくいのは、料金ではなく認証方式の選択です。相互認証（証明書）・Active Directory・SAMLの3系統から選び、相互認証は他の2つと組み合わせられます。どれを選んでも、サーバー証明書をAWS Certificate Managerへ用意する工程は避けられません。

次に効いてくるのが認可ルールです。既定の挙動は拒否で、宛先ネットワークごとにルールを明示的に足さない限り通信は落ちます。評価は最長プレフィックス一致で、0.0.0.0/0のルールだけは作成順に関係なく最後に評価されます。この性質を知らないまま書いた結果が、特定ホストだけ届かない障害です。

スプリットトンネルは既定で無効で、そのままだとクライアントの経路表が0.0.0.0/0で上書きされ、社内向けでない通信までトンネルを通ります。有効化するなら、経路表の変更が全接続のリセットを伴う点を運用設計へ織り込んでください。

Client VPNを構成する5つの要素と接続が成立するまでの流れ

Client VPNは単体のサーバーではなく、エンドポイントを中心に5つの資源を組み合わせた構成です。どれか1つでも欠けると接続は成立しません。

エンドポイントとターゲットネットワークと認可ルールの役割分担

公式の管理者ガイドでは、構成要素としてエンドポイント・ターゲットネットワーク・ルート・認可ルール・クライアントの5つが定義されています。エンドポイントはVPNセッションの終端で、ターゲットネットワークはそこへ関連付けるVPCサブネット、またはAWS Transit Gatewayへの直接アタッチです。

ルートは「どの宛先へ行けるか」を決める経路表、認可ルールは「誰がその宛先へ行ってよいか」を決める許可リストで、役割が分かれています。経路が通っていても認可ルールが無ければ落ちますし、認可ルールがあっても経路が無ければ届きません。片方だけ設定して悩む例が多い箇所です。サブネットを関連付けると、そこにClient VPN用のネットワークインターフェイスが作られ、VPCへ入る通信はそこを経由します。

クライアントCIDRの決め方とSNATで書き換わる送信元アドレス

クライアントCIDRは、接続してきた端末へ割り当てるIPアドレスの範囲です。IPv4では10.2.0.0/16のような範囲を管理者が指定し、IPv6ではAWS側が自動で割り当てます。VPC側や拠点側のアドレスと重ならない範囲を選んでください。

IPv4の通信ではSNATが適用され、送信元アドレスはクライアントCIDRの値からネットワークインターフェイスのアドレスへ書き換えられます。接続先のログに並ぶのは、端末ごとではなくネットワークインターフェイスのアドレスです。IPv6ではSNATが適用されず接続元が見えるため、アクセス元の識別をアプリ側のログに頼る環境では、この差が監査要件に響きます。

待ち受けポートは443番と1194番でTCPとUDPの両方に対応

待ち受けポートは443番と1194番に対応し、TCPとUDPのどちらも選べます。既定は443番です。社外のネットワークで1194番が塞がれていても通りやすいという理由で、既定のまま443番を使う構成が多くなります。転送プロトコルの既定はUDPで、CLIリファレンスでもtcpとudpの2択と明記されています。

セッションの最大時間は8・10・12・24時間から選べ、既定は24時間です。業務時間を超えて接続を保持させたくないなら、8時間へ寄せて切断を有効にします。

サブネットの関連付け数で決まる同時接続数とエンドポイント数の上限

同時接続数の上限は固定値ではなく、エンドポイントへ関連付けたサブネットの数で変わります。クォータの一覧に載っている既定値は次のとおりです。

関連付けたサブネット数 同時接続数の既定上限
1 7,000
2 36,500
3 66,500
4 96,500
5 126,000

1リージョンあたりのエンドポイント数は既定5、エンドポイントあたりの認可ルールは200、関連付け1件あたりのルートは100が既定で、いずれも引き上げ申請ができます。証明書失効リストの登録数は20,000で、こちらは引き上げできません。デュアルスタック構成ではIPv4とIPv6でこれらの枠を共有します。

可用性の観点では、サブネットを2つ以上関連付けて別々のアベイラビリティゾーンに置く構成が基本です。関連付けの数はそのまま時間課金の数でもあるため、可用性と費用の折り合いをここで決めます。

相互認証とActive DirectoryとSAMLの3方式から認証を選ぶ基準

クライアント認証のページでは、Active Directory認証（利用者ベース）・相互認証（証明書ベース）・SAMLによるシングルサインオン（利用者ベース）の3種類が定義されています。単独で使うほか、相互認証とSAML、相互認証とActive Directoryという組み合わせも選べます。組み合わせた場合は両方の認証を通らないと接続できません。

どの認証方式を選んでもACMのサーバー証明書を先に用意しておく

3方式のどれを選んでも、エンドポイントを作る前にAWS Certificate Managerへサーバー証明書を用意する必要があります。公式ガイドの前提も、認証方式によらないACMへのプロビジョニングです。証明書の調達や更新の運用はAWS Certificate Managerの仕組みと有効期間で整理しているので、有効期間と自動更新の条件を先に押さえておくと手戻りが減ります。

証明書を更新したとき、ACMの自動ローテーション・手動インポート・IAM Identity Centerのメタデータ更新のいずれであっても、エンドポイントへの反映は自動で行われます。ただし反映までに最大5時間かかると公式に記載されています。証明書の切り替え当日に接続試験を予定するなら、この待ち時間を工程に入れてください。

相互認証で自前の管理が必要なクライアント証明書の配布と失効リスト

相互認証は、サーバー証明書に加えてクライアント証明書とキーを配る方式です。ID基盤を持たない環境でも始められる代わりに、端末が増えるほど配布と失効の手作業が増えます。退職や端末紛失のたびに失効リストへ登録する運用が回るかどうかが採否の分かれ目で、検証環境や端末が十数台で固定された構成なら足りますが、人の出入りがある組織では証明書の棚卸しが専任作業になっていきます。

SAML認証で押さえる35001番ポートとNameIDの形式の制約

SAMLベースのフェデレーション認証は制約が具体的で、ここを外すと接続直前で必ず失敗します。公式に明記されている条件を抜き出します。

  • アサーションとレスポンスの両方に署名が必要で、レスポンスの上限は128KB
  • NameIDはメールアドレス形式で、長さの上限は1024バイト。超えた接続は拒否される
  • AWS提供クライアントが必須で、版は1.2.0以降
  • クライアントはSAMLレスポンスの受け取りに端末のTCP 35001番を使う
  • 1つのエンドポイントに設定できるIdPは1つだけ
  • シングルログアウトは非対応で、切断は利用者側の操作か管理者側の接続終了で行う
  • 多要素認証はIdP側で有効にしてあれば利用できる

IdP側にアプリを作るときの値も公開されています。Assertion Consumer ServiceのURLはhttp://127.0.0.1:35001、Audience URIはurn:amazon:webservices:clientvpnです。グループ単位で宛先を分けるならSAMLレスポンスにmemberOf属性を含めます。属性名は大文字と小文字を区別するため、表記を変えると認可ルールが効きません。

自己サービスポータルを使うなら、IdPのアプリへhttps://self-service.clientvpn.amazonaws.com/api/auth/sso/samlというACS URLを追加します。複数のACS URLに対応しないIdPでは、ポータル用のアプリとIAM SAML IDプロバイダをもう1組作り、エンドポイントへ両方を指定する設定が必要です。AWS側のID基盤を使うならAWS IAM Identity Centerの権限セット設計を先に決めると、グループの切り方が認可ルールとそろいます。

Active Directory認証で効いてくる同一アカウント制約とグループ上限

Active Directory認証では、エンドポイントをAWS Directory Serviceの資源と同じAWSアカウントに置く必要があります。SAML認証のIAM SAML IDプロバイダも同様で、認証基盤だけ別アカウントへ寄せている環境ではこの制約が構成変更の理由になります。加えて、利用者が所属できるグループは最大200で201番目以降は無視され、グループIDと名前IDの上限はどちらも255文字です。

AWS CLIで最小構成のClient VPNエンドポイントを作る手順

ここからは実行できる形で並べます。相互認証・スプリットトンネル有効・接続ログ有効という、社内利用でよく採る構成を例にします。ここで構築先として前提にしているリージョンは東京です。

create-client-vpn-endpointで待ち受けとログを指定して作る

最初にエンドポイントを作ります。認証オプションは配列で渡し、相互認証ではクライアント側ルート証明書のARNを指定します。

aws ec2 create-client-vpn-endpoint \
  --client-cidr-block 10.200.0.0/16 \
  --server-certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/11111111-2222-3333-4444-555555555555 \
  --authentication-options Type=certificate-authentication,MutualAuthentication={ClientRootCertificateChainArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/66666666-7777-8888-9999-000000000000} \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/aws/clientvpn/prod \
  --vpn-port 443 \
  --transport-protocol udp \
  --split-tunnel \
  --session-timeout-hours 8 \
  --disconnect-on-session-timeout \
  --description "corp-remote-access" \
  --region ap-northeast-1

成功するとエンドポイントIDとDNS名が返り、状態はpending-associateになります。接続先のネットワークがまだ無いため、この時点ではavailableに変わりません。接続ログのロググループは事前に作成しておきます。

VPCへの接続に必要なサブネット関連付けと認可ルールと経路の3つの設定

関連付け・認可ルール・経路を順に投入します。関連付けが完了するまで数分かかるので、続けて実行する場合は状態を確認してから進めてください。

ENDPOINT=cvpn-endpoint-0123456789abcdef0

# 1. ターゲットネットワーク（サブネット）を関連付ける
aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id $ENDPOINT \
  --subnet-id subnet-0aa11bb22cc33dd44 \
  --region ap-northeast-1

# 2. VPC全体への到達を全利用者へ許可する
aws ec2 authorize-client-vpn-ingress \
  --client-vpn-endpoint-id $ENDPOINT \
  --target-network-cidr 10.0.0.0/16 \
  --authorize-all-groups \
  --description "allow vpc" \
  --region ap-northeast-1

# 3. 状態を確認する（availableになるまで待つ）
aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids $ENDPOINT \
  --query "ClientVpnEndpoints[0].Status" \
  --region ap-northeast-1

グループごとに宛先を分けるなら、–authorize-all-groupsの代わりに–access-group-idでグループIDを渡します。SAML認証の場合、ここへ入れる値はIdPから渡されるグループ属性の値です。Active Directory認証ではS-1-5-21で始まるSIDを使います。

クライアント設定ファイルの書き出しと配布用プロファイルへの仕上げ

構築手順の最後に行うのは、クライアント設定ファイルの書き出しです。公式の手順にあるとおり、書き出したファイルには接続先のDNS名と認証に必要な情報が含まれます。相互認証ではクライアント証明書とキーを追記してから配布します。

aws ec2 export-client-vpn-client-configuration \
  --client-vpn-endpoint-id $ENDPOINT \
  --output text \
  --region ap-northeast-1 > corp-client-config.ovpn

相互認証では、このファイルへクライアント証明書とキーの記述を足してから配ります。端末ごとに別のクライアント証明書を配っておくと、失効を端末単位で行えます。

Terraformでエンドポイントと認可ルールを恒久化する記述

CLIで動作を確認したら、同じ構成をコードへ移します。プロバイダ公式のaws_ec2_client_vpn_endpointのドキュメントでは、認証オプションと接続ログオプションが必須の引数として定義されています。

Terraformでエンドポイントと関連付けと認可ルールを3資源に分ける記述

resource "aws_ec2_client_vpn_endpoint" "corp" {
  description            = "corp-remote-access"
  server_certificate_arn = aws_acm_certificate.server.arn
  client_cidr_block      = "10.200.0.0/16"
  split_tunnel           = true
  vpn_port               = 443
  transport_protocol     = "udp"
  session_timeout_hours  = 8

  authentication_options {
    type                       = "certificate-authentication"
    root_certificate_chain_arn = aws_acm_certificate.client_root.arn
  }

  connection_log_options {
    enabled               = true
    cloudwatch_log_group  = aws_cloudwatch_log_group.cvpn.name
    cloudwatch_log_stream = aws_cloudwatch_log_stream.cvpn.name
  }
}

resource "aws_ec2_client_vpn_network_association" "corp" {
  for_each               = toset(var.private_subnet_ids)
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.corp.id
  subnet_id              = each.value
}

resource "aws_ec2_client_vpn_authorization_rule" "vpc" {
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.corp.id
  target_network_cidr    = "10.0.0.0/16"
  authorize_all_groups   = true
}

SAML認証へ切り替えるときは、typeをfederated-authenticationにしてsaml_provider_arnを渡します。Active Directory認証ならdirectory-service-authenticationとactive_directory_idの組み合わせです。認可ルールをグループ単位にするなら、authorize_all_groupsを外してaccess_group_idを指定します。

社内利用で想定する挙動に合わせて既定値を上書きする引数と指定の目安

プロバイダ側の既定値は、社内利用で望ましい値とずれていることがあります。明示的に書いておきたい引数を並べます。

引数 既定値 指定の目安
split_tunnel false 社内宛だけ通すならtrue
vpn_port 443 既定のまま
transport_protocol udp 遮断される環境はtcp
session_timeout_hours 24 業務時間に合わせ8
self_service_portal disabled SAML利用時に検討

自己サービスポータルを有効にすると、利用者が自分でクライアントと設定ファイルを取得できます。ポータルはグローバルのサービスで、東京を含む4つのリージョンのスタックで提供されています。

クライアントが接続できない・通信が届かないときに見る切り分け手順

症状は大きく「接続そのものが張れない」と「接続は張れるのに通信が届かない」に分かれます。見る場所がまったく違うので、最初にどちらかを確定させてください。

認可ルールの既定の拒否動作と最長プレフィックス一致による評価の優先順位

接続は成功するのに何も届かない場合、まず認可ルールを疑います。公式の認可ルールのページには、宛先ネットワークへの到達を許すにはルールを明示的に足す必要があり、既定の挙動は拒否だと書かれています。逆に「制限するためのルール」は作れません。

評価の順序にも癖があります。評価に使われるのは最長プレフィックス一致で、優先されるのはより細かいプレフィックスのルールです。0.0.0.0/0だけは特別扱いで、作成順に関係なく最後に評価されます。公式の例では、管理者グループに10.0.2.119/32のルールを足した結果、10.0.0.0/16を許可されている開発グループがそのホストだけ到達できなくなる挙動が説明されています。グループごとに宛先を分ける設計では、細かいルールを足すたびに他グループの到達範囲が削れていないか確認してください。

スプリットトンネルの有無によるクライアントへの経路表の配られ方の違い

接続後に社内も社外も通らないときは、スプリットトンネルの仕様を確認します。無効のとき、クライアントの経路表は0.0.0.0/0のエントリで上書きされ、すべての通信がトンネルを通ります。有効にすると、エンドポイントの経路表にあるルートがクライアントへ配られ、トンネルを通る通信はその宛先への通信だけです。

ここで公式が明確に非推奨としているのが、スプリットトンネル有効の状態でエンドポイントの経路表に0.0.0.0/0を足す構成です。接続が不安定になる原因として挙げられています。また、スプリットトンネル有効時に経路表を変更すると、その時点で全クライアントの接続がリセットされます。業務時間中に経路を追加する運用は避けてください。

SAML接続で失敗するときに確認する3か所と接続ログの出力先の確認

SAML認証で接続できないときは、端末側・IdP側・エンドポイント側の3か所を順に見ます。端末側はTCP 35001番を他のアプリが使っていないか、AWS提供クライアントが1.2.0以降かの2点です。IdP側はNameIDがメールアドレス形式になっているか、レスポンスに署名があるかを確認します。

エンドポイント側では接続ログを見ます。接続ログはCloudWatch Logsのロググループへ出るため、作成時に有効化していない環境ではログを出す設定から入ることになります。障害が起きてから有効化しても過去の接続は追えないので、本番投入時は最初から有効にしておく判断が妥当です。

Client VPNを採用してよい条件と別の方式へ寄せるべき場面

マネージドである点は運用の軽さに直結しますが、あらゆるリモートアクセスに向くわけではありません。条件を切って判断します。

採用してよいのはIdPを持ちネットワーク単位で許可を出す組織

採用が合うのは、SAML対応のIdPかActive Directoryをすでに運用していて、社外の端末からVPC内の複数のリソースへ到達させたい構成です。データベースや内部APIのようにブラウザ越しでは扱いにくい宛先が混じる場合、ネットワーク単位で許可を出せる利点が効いてきます。グループ単位で宛先を分けられるため、開発と運用で到達範囲を変える設計も素直に書けます。

東京リージョンの単価はエンドポイントの関連付けが0.15ドル毎時、接続が0.05ドル毎時で、使う人数と時間に比例して増えます。課金を止めるために必要なのは、接続の切断に加えてサブネットの関連付けを解除する操作です。月額の試算と他方式との比較はAWS VPNの2方式と料金実額にまとめています。

Client VPNの採用を見送れる踏み台用途とブラウザ完結の業務だけの条件

EC2への操作が目的で、対象がSSHやRDPに限られるなら、Client VPNを建てずにSystems Managerのセッション機能で対応できる範囲です。VPNの経路設計も証明書配布も不要になり、接続の記録もそのまま残ります。社内Webアプリへのアクセスだけが要件なら、アプリ単位で認可するAWS Verified Accessのほうが範囲を絞れます。

拠点ごと常時つなぐ要件が主で端末単位の接続が従なら、Site-to-Site VPNやDirect Connectによる専用線接続を先に検討してください。帯域と安定性の要件が厳しいほど、リモートアクセスVPNで受けるより素直に収まります。いずれの構成でも認証基盤とネットワークの設計を同時に決めることになるため、既存環境の棚卸しから入るのが早道です。設計と構築をまとめて任せたい場合は、AWS・Google Cloud・Azureのインフラ構築でご相談ください。

よくある質問

Client VPNは使っていない時間も課金されますか？

エンドポイントとサブネットの関連付けは、接続の有無にかかわらず時間で課金されます。東京リージョンでは関連付け1件あたり0.15ドル毎時、クライアント接続1本あたり0.05ドル毎時です（AWS Price List APIのap-northeast-1・2026-09-17公開版で実測）。止めたい期間は関連付けを解除してください。状態はpending-associateへ戻り、再び関連付ければ接続を再開できます。

同時に接続できる人数に上限はありますか？

関連付けたサブネットの数で変わり、既定では1つで7,000、2つで36,500、5つで126,000です。可用性のために2つ以上を関連付ける構成が一般的なので、人数の上限が実務で先に問題になることはほとんどありません。引き上げ申請も可能です。

全部の通信をVPNに通さない設定はできますか？

スプリットトンネルを有効にすると、エンドポイントの経路表にある宛先だけがトンネルを通り、それ以外は端末の通常の経路へ流れます。既定は無効で、すべての通信がトンネル経由になります。有効にした状態で経路表へ0.0.0.0/0を足す構成は公式に非推奨とされているので避けてください。

多要素認証を組み合わせることはできますか？

SAML認証では、IdP側で多要素認証を有効にしてあればそのまま利用でき、Client VPN側の追加設定は要りません。相互認証だけの構成は端末に配った証明書が事実上の資格情報になるため、多要素の要件がある環境では相互認証とSAMLの組み合わせを検討してください。

証明書を更新したらすぐ反映されますか？

ACMの自動ローテーション・手動インポート・IAM Identity Centerのメタデータ更新のいずれでも反映は自動ですが、公式ドキュメントには最大5時間かかると記載されています。更新直後の接続試験では古い証明書のまま応答することがあるため、切り替えは余裕をもった時間帯に計画してください。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る