AWS Verified Access: Secure Application Access Without a VPN
Broad, network-level VPN access is a liability every application inherits by default. Verified Access replaces it with per-request, per-application decisions based on identity and device posture.
Published July 2026·~14 min read·Implementation guide
Executive Summary
Traditional VPNs grant network-level access: once connected, a user (or an attacker with stolen credentials) typically has a path to far more of the network than any single task requires. It's a coarse, all-or-nothing model that predates zero-trust thinking, and it shows — in over-permissive access, inconsistent device checks, and audit logs that can't answer "who accessed which application, from what device."
AWS Verified Access is a managed service that replaces VPN-based access with per-application, per-request policy decisions. It sits in front of each application and evaluates every request against configurable policies that combine identity (via IAM Identity Center or an external IdP) and device posture (via an MDM/EDR integration) — with no VPN client, no split-tunnel configuration, and no broad network access granted by default.
This guide covers what Verified Access is, the problems it solves, reference architectures for both single-application and multi-application environments, and a step-by-step implementation walkthrough.
WHAT IT SOLVESOver-permissive VPN access — replaces it with per-application, identity- and device-aware access decisions
DEPLOYMENT MODELManaged AWS service — endpoints deployed in your VPC in front of existing ALB/NLB/EC2 targets
TYPICAL EFFORTA single application can be fronted in an afternoon; a multi-app, policy-grouped rollout is a multi-week project
KEY OUTCOMEVPN-less, zero-trust access with centralized policy and full request-level audit logging
01 What Is AWS Verified Access?
AWS Verified Access sits in front of your applications and resources and enforces conditional access policies on every request. It integrates with identity providers (IdPs) and device posture providers to continuously verify who the user is and whether their device meets your security requirements, before allowing access to a specific application.
Instead of "connect to VPN, then you're on the network," Verified Access applies per-application, least-privilege access, and logs every attempt for audit and incident response.
Key benefits
Per-request evaluation — every application request is checked against policy, reducing lateral movement risk compared to a persistent network-level VPN session.
VPN-less access — users reach applications via browser or client without managing VPN clients or split-tunnel configurations.
Integrated trust signals — combines identity (e.g. AWS IAM Identity Center, external IdPs) and device posture (MDM/EDR) to decide access.
Centralized policy & logging — policies and logs are managed centrally, simplifying operations and audits.
02 Problems It Solves
Problem
How it shows up
Over-permissive VPN access
Traditional VPNs often expose entire subnets once connected, making lateral movement easier for a compromised account or device.
Inconsistent device posture
Hard to ensure only compliant devices connect; posture checks are often one-time (at VPN connect) rather than continuous.
Complex user experience
VPN client issues, split-tunnel misconfigurations, and credential problems drive a disproportionate amount of support load.
Fragmented access policies
Different stacks — VPN, reverse proxies, app-level auth — lead to duplicated, inconsistent, and hard-to-audit rules.
Limited observability
Network-level logs rarely show which user accessed which app, with what device posture, at what time.
03 Common Use Cases
Secure remote workforce at scale
Remote employees and contractors can access only the applications they need, with access conditioned on identity, group membership, and device posture. When a contract ends, access is revoked centrally via the IdP and Verified Access policies — no VPN credential to separately deprovision.
Zero-trust access to internal web apps
Internal admin portals, dashboards, and line-of-business apps can be exposed through Verified Access endpoints. Each app has its own policy — for example, "only members of the Admins group, using a compliant corporate device, from specific countries."
Consistent access for web and non-web resources
Verified Access can front both web-based applications and infrastructure resources (e.g. SSH/RDP/TCP access to EC2 or databases via appropriate endpoints), giving you one consistent policy model across different protocols instead of a patchwork of tools.
04 Architecture: Single Application Access
The simplest deployment fronts a single application. A user requests the application URL, which resolves to a Verified Access endpoint. The endpoint evaluates the request against configured trust providers — identity and device posture — before forwarding traffic to the target application in your VPC.
Figure 1 — Browser-based access to an internal web application: the endpoint evaluates identity and device posture via trust providers before forwarding traffic.
In larger environments, applications are organized into groups that share similar security requirements — for example, Admin Apps, Finance Apps, and Dev/Test Apps. Each group can apply its own policy set while still giving every application its own dedicated endpoint and hostname.
Figure 2 — A single Verified Access instance governing multiple policy groups, each with its own endpoint and target application.
06 Detailed Implementation Guide
Confirm prerequisites
Before you start, make sure you have:
An AWS account and VPC — your applications should be deployed behind an ALB/NLB or directly on EC2.
An identity provider — AWS IAM Identity Center, or an external IdP (Okta, Azure AD, etc.) integrated with AWS.
A device posture provider (recommended) — an MDM/EDR solution that can expose device compliance signals to Verified Access.
DNS control — the ability to create public DNS records (e.g. in Route 53) for your Verified Access endpoints.
Create a trust provider
Trust providers are how Verified Access obtains identity and device posture information. Configure one or more and reference them in your policies:
Identity trust provider — integrate with IAM Identity Center or an external IdP using OIDC/SAML.
Device trust provider — integrate with your device management solution to expose signals like "corporate-managed," "OS version," or "disk encryption enabled."
Design tip. Start with identity-only policies, then progressively add device posture conditions once you've validated the integration and logging.
Create a Verified Access instance
The instance is the top-level container for your configuration. Within it, you define groups and endpoints.
Scope — decide whether you want one instance per environment (e.g. prod, non-prod) or per business unit.
Logging — enable logging to CloudWatch Logs or an S3 bucket for all access attempts from the outset.
Define groups and policies
Groups let you apply policies to sets of applications with similar security requirements. Each group can reference one or more trust providers and define conditional access rules.
Example groups — "Admin Apps," "Finance Apps," "Contractor Apps," "Developer Tools."
Example policy — only allow access if the user is in the Admins IdP group, device posture is "compliant" and "corporate-managed," and (optionally) the request originates from an allowed country or IP range.
Create Verified Access endpoints
Endpoints are what users actually connect to. Each endpoint is associated with a group and a target application in your VPC.
Endpoint type — choose the appropriate type (e.g. web application) and configure the target: ALB, NLB, or EC2.
Network configuration — place endpoints in subnets that can reach your application's load balancer or instances.
Security groups — ensure security groups allow traffic from the Verified Access endpoint to the target application.
Configure DNS for endpoints
For a good user experience, map friendly hostnames to your Verified Access endpoints via Route 53 CNAME (or equivalent) records — e.g. admin.example.com, finance.example.com, dev.example.com.
Add and refine access policies
Once endpoints are live, attach policies that reference your trust providers and enforce zero-trust access.
Start simple — identity-only policies (e.g. "user is in the Admins group").
Iterate — add device posture conditions and contextual rules (time of day, IP ranges, etc.).
Test — validate with test users and devices; confirm non-compliant devices are blocked as expected.
Set up observability and logging
Verified Access logs every access attempt, including whether it was allowed or denied and which policy was applied.
CloudWatch Logs — stream logs for dashboards and alerts (e.g. spikes in denied access).
S3 / SIEM — export logs to S3 and ingest into your SIEM for correlation with other security events.
Audit trails — use logs to answer "who accessed which app, when, and with what device posture?"
Harden and integrate
Combine with AWS WAF — place WAF in front of your application load balancers to protect against common web exploits, while Verified Access handles identity and posture.
Least privilege — ensure each endpoint's policies only allow the minimum necessary roles or groups.
Lifecycle management — integrate with HR/IdP processes so user offboarding automatically revokes access.
Environment separation — use separate instances or groups for prod vs. non-prod to avoid accidental cross-access.
07 End-to-End Flow Example
To make this concrete, here's an example flow for an internal admin portal protected by AWS Verified Access.
Figure 3 — End-to-end request flow for an internal admin portal, from initial request through to logged decision.
User navigates tohttps://admin.example.com, which resolves to a Verified Access endpoint.
Verified Access validates identity via the configured IdP (e.g. IAM Identity Center).
Device posture is checked via the device trust provider (e.g. MDM/EDR) to confirm compliance.
Policies are evaluated — the user must be in the Admins group and the device must be compliant.
If allowed, traffic is forwarded to the admin portal behind an ALB in the VPC.
The access attempt is logged with identity, device posture, decision (allow/deny), and endpoint details.
08 Summary
AWS Verified Access brings zero-trust principles directly to your application access layer, replacing broad VPN-based network access with granular, per-request decisions based on identity and device posture. By grouping applications, centralizing policies, and enabling rich logging, you can improve your security posture, simplify operations, and give users a smoother way to reach the tools they need — without the friction of traditional VPNs.
