AWS Verified Accessを理解する〜VPNレスで実現するZTNA〜

Posted at 2026-07-08

はじめに

AWSにゼロトラストネットワークアクセス (ZTNA)を実現するサービスがあることをご存じでしょうか？
AWS Verified Accessは、VPNを使わずに企業内アプリケーションへのセキュアなアクセスを実現するゼロトラストネットワークアクセス (ZTNA)です。
本記事では、AWS Verified Accessの概要や構成、アクセスの流れ、各コンポーネントの役割について整理しながら解説します。

この記事で分かること

VPNとゼロトラストネットワークアクセス (ZTNA)
AWS Verified Accessの概要
Endpoint Typeの種類
Trust Providerの種類
アクセスの流れ
料金
関連機能

VPNとゼロトラストネットワークアクセス (ZTNA)

まず本題に入る前に、VPNとゼロトラストネットワークアクセス (ZTNA) の違いについて整理しておきましょう。

VPN：ユーザーを認証し、通信を暗号化したうえで社内ネットワークへ安全に接続する仕組みです。一度接続すると、社内ネットワークは信頼できる環境であることを前提として、社内のシステムやサーバーへアクセスできます。

ゼロトラストネットワークアクセス (ZTNA)：通信を暗号化するとともに、ネットワークの内外を問わず、すべてのアクセスを信頼しないことを前提とする考え方です。ユーザーIDだけでなく、デバイスの状態や行動属性なども考慮した動的なポリシーに基づいて、リソースへのアクセス要求ごとに認証・認可を行います。

項目	VPN	ZTNA (例：Verified Access）
基本的な考え方	社内ネットワークへ安全に接続する	アプリケーションごと (NIST SP 800-207でいうリソースごと) にアクセスを制御する
信頼の考え方	一度接続すると、社内ネットワーク内の通信を基本的に信頼	すべてのアクセスを信頼せず、アクセスのたびに評価する
アクセス制御	ネットワーク単位	アプリケーション単位 (NIST SP 800-207でいうリソース単位)
認証・認可	ユーザーIDとクレデンシャル（MFAを含む）を用いた認証	ユーザーIDに加え、デバイス状態や行動属性などを考慮した動的ポリシーによる認証・認可

AWS Verified Accessの概要

AWS Verified Accessは、ユーザーのIDやデバイスの状態などの情報をもとにアクセス可否を判断し、許可されたユーザーのみが企業内アプリケーションへアクセスできるよう制御します。
従来のVPNのようにネットワーク全体への接続を許可するのではなく、アプリケーション単位でアクセスを制御できることが特徴です。

主要コンポーネント

Verified Access Instance

Verified Accessの中核となるリソースです。ユーザーが利用するデバイスからのアクセス要求を評価し、Access Policyに基づいてアクセス可否を判定します。

Access Policy

「誰が」「どのデバイスから」「どの条件で」アクセスできるかを定義するルールです。 Verified Accessでは2段階のポリシーでアクセスを制御します。

Verified Access Group Policy

グループに1つ設定
グループ配下のすべてのエンドポイントに適用される

Verified Access Endpoint Policy

エンドポイントごとに1つ設定（任意）
そのエンドポイント固有の条件を追加できる

アクセス時は、グループポリシーとエンドポイントポリシー（設定されている場合）の両方が評価され、許可された場合のみアクセスできます。

Verified Access Endpoint

アプリケーションやサービスへの接続先を定義するリソースです。また、Endpointの実体はElastic Network Interface（ENI）であり、作成時に指定したサブネットに配置されます。

Verified Access Group

Verified Access Endpointをグループ化するための管理単位です。グループごとにAccess Policyを設定でき、同じアクセス制御ルールを複数のEndpointへ適用できます。用途やシステムごとにグループを分けることで、アクセス制御を効率的に管理できます。

（例えば、本記事の上記構成では、Webアプリケーション向けの「Web」グループと、管理者向けSSHアクセス用の「Admin」グループを作成し、それぞれ異なるAccess Policyを適用しています。）

Trust Provider

Verified Accessがアクセス可否を判定するために必要な情報を提供するサービスです。ユーザーの認証情報やデバイスのセキュリティ状態などをVerified Accessへ提供します。

Trust Data

Trust Providerから取得する情報です。例えば、ユーザーの認証情報や所属グループ、デバイスの管理状態やコンプライアンス情報などが含まれます。Verified Accessは、これらの情報とAccess Policyを基にアクセス可否を判定します。

Endpoint Typeの種類

Verified Access Endpointでは、公開したいアプリケーションやサービスに応じてEndpoint Typeを選択します。
Endpoint Typeによって接続先が異なり、Webアプリケーションだけでなく、SSHやRDP、Amazon RDS、オンプレミス環境のTCPサービス（Site-to-Site VPNやDirect Connectなどで接続されている環境）など、さまざまなリソースを保護できます。
Verified Access Endpoint Type (接続先のタイプ) は4種類あります。

Endpoint Type	接続先	接続イメージ	主な用途
Load balancer	Application Load Balancer (ALB) または Network Load Balancer (NLB)	Verified Access Endpoint (ENI) → ALB/NLB → アプリケーション	Webアプリケーションへのアクセス
Network interface	Elastic Network Interface (ENI)	Verified Access Endpoint (ENI) → EC2 (ENI)	SSH、RDP、独自TCPアプリケーションへのアクセス
RDS	Amazon RDS	Verified Access Endpoint (ENI) → RDS	Amazon RDSへのアクセス
Network CIDR	指定したCIDR内のIPアドレス	Verified Access Endpoint (ENI) → CIDR内のIPアドレス	VPC内やオンプレミス環境のTCPサービスへのアクセス

Trust Providerの種類

Trust Providerには、ユーザー認証を行うUser-identity Trust Providerと、デバイスのセキュリティ状態を提供するDevice-based Trust Providerの２種類があります。

AWSでは、User-identity Trust ProviderとしてAWS IAM Identity Centerを利用できるほか、Microsoft Entra IDやOktaなどの外部IDプロバイダーとも連携できます。
また、Device-based Trust ProviderとしてMicrosoft IntuneやJamfなどと連携し、OSのバージョン、暗号化の有無、アンチウイルスソフトの稼働状況、デバイスのコンプライアンス状態などの情報を取得できます。

User-identity Trust Providerは、Verified Access Instanceごとに1つ設定する必要があります。
一方、Device-based Trust Providerの設定は任意で、必要に応じて複数設定できます。

項目	User-identity Trust Provider	Device-based Trust Provider
役割	ユーザー認証を行う	デバイスのセキュリティ状態を提供する
主な情報	ユーザーの認証情報、所属グループなど	OSのバージョン、パッチ適用状況、ディスク暗号化の有無、アンチウイルスソフトの稼働状況、デバイスのコンプライアンス状態など
設定	必須（1つのみ設定可能）	任意（複数設定可能）

アクセスの流れ

先ほど登場した図に流れを赤字で記載しました。

ユーザーがデバイスからアプリケーションへアクセスします。
アクセス要求はVerified Access Instanceに送信されます。
Verified Access Instanceは、Trust Providerからユーザー情報やデバイス情報（Trust Data）を取得します。
Access Policyに基づき、アクセス要求を評価します。
アクセスが許可された場合、Verified Access Endpointを介してALB、EC2、RDSなどの接続先へ通信します。
アクセス条件を満たさない場合は、アプリケーションへのアクセスを拒否します。

料金

AWS Verified Accessは従量課金制で、課金体系は、HTTP(S)アプリケーションと非HTTP(S)アプリケーションで異なります。

HTTP(S)アプリケーションでは、以下の2つに対して料金が発生します。

課金項目	内容	料金（2026年7月時点）
アプリケーション時間	アクティブなHTTP(S) Verified Access Endpointに関連付けられたアプリケーションごとに時間単位で課金	0.35 USD / アプリケーション時間（最初の148,800時間/月） 0.26 USD / アプリケーション時間（148,801時間/月以降）
データ処理	Verified Accessで処理したデータ量	0.02 USD / GB

SSHやRDP、TCPアプリケーションなどの非HTTP(S)アプリケーションでは、以下の2つに対して料金が発生します。

課金項目	内容	料金（2026年7月時点）
エンドポイント時間	アクティブな非HTTP Verified Access Endpointごとに時間単位で課金	0.26 USD / エンドポイント時間
接続	Verified Access Instanceへの接続	100接続/エンドポイント/時間まで無料超過分は 0.001 USD / 接続時間

記載は2026年7月時点の東京リージョンの金額です。料金は変動する可能性がありますので、AWS公式料金ページよりご確認ください。
※2026年7月時点では大阪リージョンでAWS Verified Accessの利用は不可

User-identity Trust Provider	AWS WAFがリクエストを検査するタイミング
AWS IAM Identity Center	認証前
Microsoft Entra ID、Oktaなどの外部IDプロバイダー	認証後

ログ	内容	出力先
Verified Access Access Logs	アクセス要求、許可・拒否結果などを記録	CloudWatch Logs、Amazon S3、Amazon Data Firehose
AWS CloudTrail	Verified Accessリソースの作成・変更・削除などのAPI操作を記録	AWS CloudTrail

さいごに

今回は、AWS Verified Accessについて紹介しました。

この記事が、AWS Verified Accessを学ぶ際の参考になれば幸いです！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS Verified Accessを理解する 〜VPNレスで実現するZTNA〜