Zero Trust Network Access - Achieving Secure Access Without a VPN with AWS Verified Access

An explanation of VPN-less zero trust access using AWS Verified Access. Identity provider integration, device trust, policy-based access control, and a comparison with traditional VPNs are introduced.

The Problems with VPNs and the Need for Zero Trust

VPNs used to be the mainstream approach for remote access to internal applications. However, VPNs have many problems. When you connect to a VPN, you can end up accessing the entire network, which violates the principle of least privilege. The bandwidth of VPN concentrators becomes a bottleneck, and performance declines as the number of remote workers increases. Installing and configuring the VPN client is a burden on users. If VPN credentials are leaked, the entire network is put at risk. The zero trust model is based on the principle of verifying access regardless of whether it comes from inside or outside the network, and it serves as a countermeasure to these problems. AWS Verified Access is a zero trust network access service released in 2023 that grants access per application after verifying the user's identity and the trustworthiness of the device.

Architecture and Policy Definition

Verified Access consists of Verified Access instances, trust providers, access groups, endpoints, and access policies. An access group is a group of endpoints that share policies. An endpoint represents an application to be protected, and there are 4 types: load balancer, network interface, network CIDR, and Amazon RDS. You define access policies in the Cedar policy language. Cedar is an open-source policy language developed by AWS that lets you write access rules declaratively.

// Allow access when the user is in the engineering group and the device is compliant
permit(principal, action, resource)
when {
    context.identity.groups.contains("engineering") &&
    context.device.status == "compliant"
};

Fine-grained control that combines user attributes (groups, email domain), device attributes (OS version, encryption status, patch status), and request attributes (IP address, time of day) is possible.

Deployment and Integration with Existing Applications

Verified Access can be deployed by placing it in front of existing applications. You place a Verified Access endpoint in front of the ALB, and users access the Verified Access endpoint URL from a browser. Verified Access verifies the identity and the device, and forwards the request to the ALB only if the request matches the policy. For HTTP applications, users can access the application from a browser without installing a VPN client. Because Verified Access adds user information (email address, groups, and so on) to the request headers and forwards the request to the ALB, it is also possible to make use of the user information on the application side. Through integration with CloudWatch Logs, access logs are recorded, and it is possible to audit who accessed which application and when.

Comparison with VPNs and Pricing

The main differences between Verified Access and VPNs are the granularity of access and the user experience. A VPN provides network-level access, and after connecting, you reach a wide range of resources in the network. Verified Access provides application-level access, and you can access only the applications allowed by the policy. A VPN is used by installing client software, while with Verified Access you connect to HTTP applications from a browser and to non-HTTP applications from the Connectivity Client. With a VPN, the bandwidth of the concentrator can become a bottleneck, while Verified Access evaluates each request to an application against the policy. However, there are also cases in which a VPN is needed. When you use network-level access, choosing a VPN (Client VPN) continues to be a good fit. TCP communication such as direct server access via SSH or RDP can be handled by the Verified Access Connectivity Client (as of October 2026). Pricing is $0.27/hour (about $197/month) per application associated with an HTTP endpoint, plus $0.02/GB for data processing (as of August 2026).

Suitable Applications and Scope of Use

Zero trust access is a good fit for protecting systems that allow access only to specific users, such as internal web applications and admin screens. If you place business systems that were previously published over a VPN behind Verified Access, users can access them directly from a browser without starting a VPN. On the other hand, this mechanism is not suited to general public sites open to an unspecified number of people. One approach is to first apply it to internal systems in which you want to strictly control access, and then expand the scope while confirming the effect. Identifying the applications to protect and defining the scope of use is the starting point for adopting zero trust.

Summary - Guidelines for Making Use of Verified Access

AWS Verified Access is a service that controls access to internal applications with the zero trust model without using a VPN. You use it by combining integration with identity providers and device management solutions, fine-grained access control with Cedar policies, and deployment in front of existing applications. In use cases where remote workers access web-based internal applications, it is worth considering as an alternative to VPNs.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Share