AWS Verified AccessとClient VPN：2026年におけるZTNA設計ガイド

従来のClient VPNは、2026年になってもほとんどの企業が依然として関心を持っているレガシーなアーキテクチャ上の負債です。AWS Client VPNは基本的な管理アクセスにとって機能的なツールであるものの、AWS Verified Access (AVA) を介したZero Trust Network Access (ZTNA) への移行は、現代のセキュリティ体制にとって唯一の実行可能な道筋を示しています。選択はプロトコルだけの問題ではなく、「接続後に認証」モデルから、ネットワークの境界が消滅する「継続的な検証」モデルへの移行を意味します。

アーキテクチャの分岐：トンネルベース vs. プロキシベース

AWS Verified Access (AVA) がアプリケーション配信において優れている理由を理解するには、パケットフローの違いを分析する必要があります。AWS Client VPNはOpenVPNの実装です。クライアントマシン上にVirtual Network Interface (VIF) を作成し、CIDRブロックからIPを割り当て、ローカルルーティングテーブルにルートをプッシュします。トンネルが確立されると、ユーザーは「ネットワーク上」にいることになります。Security Groupsを使用しても、ラテラルムーブメントの表面積は広大です。

AWS Verified Accessは、マネージドなリバースプロキシとして機能します。Cedarポリシー言語を使用して、すべてのリクエストを信頼データに対して評価します。トンネルは存在しません。ユーザーのマシンにクライアントIPは割り当てられません。ユーザーはパブリックエンドポイントと対話し、AVAはIDとデバイスのポスチャを評価し、許可された場合、リクエストを内部のLoad Balancer (ALB) またはENIにプロキシします。これにより、「ネットワークレベル」のアクセスの概念全体が排除され、適用ポイントがLayer 7に移行します。

信頼プロバイダーとの統合：IDとデバイスのポスチャ

AVAの真の力は、「トラストプロバイダー」を消費する能力にあります。標準的なClient VPNの設定では、通常、SAML 2.0に依存して一回限りの認証イベントを行います。セッションが確立されると、それで終わりです。AVAは、Identity Providers (IdP) とDevice Management (EDR/UEM) システムとの統合により、継続的な評価をサポートします。

• Identity Providers: AWS IAM Identity Center (旧SSO) またはOktaやAzure ADなど、OIDC準拠のプロバイダーとのネイティブ統合。
• Device Trust Providers: CrowdStrike、Jamf、またはTaniumとの統合。「ユーザーが『DevOps』グループに属しており、かつCrowdStrikeのセキュリティレベルが『High』の場合にのみ、Production CIDRへのアクセスを許可する」といったポリシーを作成できます。

// AVAのCedarポリシーの例
permit(
    principal,
    action == "http-request",
    resource
)
when {
    context.identity.groups.contains("Engineers") &&
    context.device.assessment.overall_health_score == "STABLE" &&
    context.device.assessment.jamf.compliance_status == "COMPLIANT"
};

AWS Client VPNの比較：レガシーなユースケース

ZTNAの優位性にもかかわらず、AWS Client VPNは廃れていません。Layer 7プロキシと相性が悪いプロトコルにとっては、依然として必要な悪です。エンジニアが、非標準ポートを介したRaw TCP/UDPストリームを必要とするシッククライアントアプリケーション（レガシーなSQL Server管理、カスタムRPCコール、ジャンプボックスを使用しない直接SSH/RDPなど）を使用する必要がある場合、AVAは主にHTTP/HTTPSトラフィックに最適化されているため、適していません。

さらに、Client VPNは「Full Tunnel」構成を可能にします。これは、一部の高度に規制された業界で、すべてのインターネット経由トラフィックを一元的な検査ポイント（AWS Network Firewallを備えたTransit Gatewayなど）を強制するために使用されます。AVAはこれを行うことができません。それは本質的に「Split-Tunnel」アプリケーションアクセスソリューションです。

コスト分析：ZTNAの隠れた税金

ハードウェアとライセンスの現実に触れましょう。AWS Client VPNの料金は予測可能です: エンドポイント関連付けあたり1時間あたり0.05ドル + アクティブなクライアント接続あたり1時間あたり0.05ドルです。100人のユーザーが1日8時間アクティブな場合、月額約400〜600ドルにデータ転送量が加算されます。これは安価ですが、「スマートではない」パイプです。

AWS Verified Accessの料金はより複雑で、大規模な場合ははるかに高くなります。アプリケーションあたり（1時間あたり0.20ドル）と処理されたGBあたり（1GBあたり0.02ドル）で課金されます。AVA経由で公開したい内部マイクロサービスが50ある場合、「アプリケーションあたり」のコストだけで月額7,200ドルになります。ここでアーキテクチャの統合が必要になります。スマートなエンジニアは、「ワイルドカード」アプローチを使用するか、コストを管理するためにアプリケーションを中央のエントリーポイントの背後に集約しますが、それでもAVAはプレミアムなセキュリティ製品として位置づけられています。

AVA vs. Palo Alto Prisma Access：エンタープライズの戦い

Palo Alto Firewallsをすでに運用している組織にとって、疑問はしばしば「Prisma Accessがあるのに、なぜAVAを使うのか？」というものです。これは「Global Secure Access」のビジョンに関係しています。Prisma Accessは、Webトラフィックだけでなく、すべてのポートとプロトコルを処理する、より成熟したZTNA 2.0フレームワークを提供します。また、AVAにはネイティブに欠けているDLPと高度な脅威防御も統合されています。

しかし、AVAはAWSネイティブな統合で優勢です。スタック全体が us-east-1 と eu-west-1 にある場合、AVAはGlobalProtectエージェントやサードパーティのSASEクラウドへのGRE/IPsecトンネルを管理するオーバーヘッドなしに、AWSバックボーンとIAMエコシステムを活用します。Palo Altoの会社であれば、統一されたポリシーエンジンについてはPrismaを使い続けるべきです。クラウドネイティブであり、グローバルエージェントからの移行を検討している場合は、AVAがより軽量な選択肢です。

デプロイ戦略：2026年におけるZTNAへの移行

週末にVPN全体をAVAにリフト＆シフトしようとしないでください。2026年のベストプラクティスはハイブリッドアプローチです。Client VPNは「Backstage」管理アクセス（Raw VPCアクセスを必要とする5%のユーザー）に使用し、一般スタッフの95%はWebベースのツール（Jira、内部ポータル、人事アプリ）のためにAVAに移行させます。

ステップ1：OIDCの連携

AWS IAM Identity Centerを設定します。これは前提条件です。AVAのローカルユーザーを管理しようとしないでください。Google WorkspaceまたはAzure ADのIDを同期させます。これにより、IdPからユーザーがオフボーディングされたときに、すべてのAVAで保護されたアプリケーションへのアクセスがリアルタイムで取り消されることが保証されます。

ステップ2：Verified Accessインスタンス

Verified Accessインスタンスを作成します。これは、信頼プロバイダーとグループを保持するグローバルリソースです。Verified Accessエンドポイントを介して、ターゲットVPCに関連付けます。これらのエンドポイントは、Load BalancerベースまたはNetwork Interfaceベースにすることができます。

ステップ3：Cedarポリシーの定義

グループ内で「すべての許可」から始め、徐々に絞り込みます。context.deviceフィールドを使用して、会社管理のラップトップのみが接続できるように強制します。この1つの動きで、管理されていない「自宅のPC」がマルウェアを環境に持ち込む脅威が排除されます。

評決：AVAは未来、Client VPNは補助手段

AWS Client VPNは、レガシーな考え方のためのレガシーなツールです。セキュリティを「内部」か「外部」かという二元的な状態として扱います。2026年において、それは壊滅的な侵害のレシピです。AWS Verified Accessは、設定にかかるコストと複雑さが増すにもかかわらず、最新のコンプライアンスフレームワーク（SOC2やFedRAMP Highなど）が要求する、粒度の細かい、ID認識型、デバイス認識型の制御を提供します。トラフィックが主にWebベースである場合、トンネルの構築をやめ、プロキシを使用してください。

VPC到達性モデルからID認識型プロキシへの移行に苦労している方のために、techleague.ioのチームは、AWSのペリメーターをリファクタリングするための実践的なエンジニアリングの専門知識を提供します。現在のイングレスパターンに関する詳細なアーキテクチャレビューを予約するためにご連絡ください。