AWS Verified Access has significantly simplified implementing Zero Trust access for internal applications without relying solely on traditional VPNs. I particularly like its policy-based access engine, continuous identity verification, device posture evaluation, and seamless integration with enterprise identity providers. The AWS Console provides a clean interface for configuring trust providers, access groups, applications, and access policies, making onboarding relatively straightforward for security teams.

The service integrates exceptionally well with AWS IAM Identity Center, Amazon Cognito, Microsoft Entra ID (Azure AD), Okta, EC2, Application Load Balancer, and AWS WAF. Performance has been excellent since authorization decisions are evaluated quickly without introducing noticeable latency for end users. From an ROI perspective, Verified Access reduces operational overhead by eliminating VPN infrastructure for many internal applications while strengthening security through continuous authorization. Although it is not an AI service, it complements Amazon Q Security and Security Hub by enforcing identity-aware access policies within a Zero Trust architecture. Review collected by and hosted on G2.com.

Initial policy design requires a solid understanding of Zero Trust principles and enterprise identity management. Organizations migrating from VPN-based access may need additional planning to map existing authentication and authorization workflows. Review collected by and hosted on G2.com.

What I like best about AWS Verified Access is the strong security and controlled access it provides to our PMS environment hosted on AWS, it’s very important that only authorized users can access our systems. AWS Verified Access helps us secure applications without relying only on traditional VPNs, improves identity-based access, and ensures our PMS remains protected, stable, and easily accessible for our teams working from different locations. Review collected by and hosted on G2.com.

A more guided setup, clearer dashboards, and easier policy configuration would make it faster for new teams to adopt and manage. Review collected by and hosted on G2.com.

AWS Verified Access enforces access based on user identity and device context, rather than relying on network location. Compared with legacy VPN approaches that often grant broader network access than necessary, this can significantly reduce risk.

It’s especially well-suited for protecting web applications, including internal dashboards, admin panels, and other private apps hosted behind AWS resources such as Application Load Balancers. Overall, it feels clean and scalable, and it’s clearly purpose-built for application-level access control. Review collected by and hosted on G2.com.

Not a general replacement for every VPN use case

Verified Access is best suited for HTTP/HTTPS applications, and it doesn’t fully address scenarios that require raw network access or other non-web workloads (for example, SSH or direct database access) unless you add additional tooling.

Device posture requirements depend on environment maturity

To get the most out of Verified Access, organizations generally need strong identity foundations and solid device management (MDM) already in place. Without that level of maturity, deployments can feel constrained and may not deliver the same breadth of coverage you’d expect from more fully developed Zero Trust / enterprise ZTNA approaches. Review collected by and hosted on G2.com.

What I value most about AWS Verified Access is its zero-trust security approach, which eliminates the need for a VPN yet still provides comprehensive access controls based on both identity and device for corporate applications. I also find that it integrates seamlessly with AWS IAM and third-party identity providers. Review collected by and hosted on G2.com.

Some users report that AWS Verified Access can be difficult to set up initially, as there is a learning curve involved in configuring policies and integrating with third-party identity providers. Additionally, the platform may present certain limitations in terms of protocol support, and costs can rise considerably when deploying at a larger scale. Review collected by and hosted on G2.com.

Helps us a lot for accessing many applications from a single login at a single place. Review collected by and hosted on G2.com.

The initial setup can feel a bit complex, especially when configuring policies and integrating identity providers. Troubleshooting can also be difficult because the logs and error messages aren’t always very clear. Review collected by and hosted on G2.com.

AWS Verified Access stands out for its strong, zero-trust, identity-aware approach to application access. I appreciate that it removes the need for traditional VPNs and instead makes access decisions based on user identity, device posture, and overall security context. Its tight integration with AWS IAM Identity Center and other AWS services helps keep policy enforcement consistent, centralized, and scalable. Once it’s configured properly, access control feels dependable and meaningfully improves security without getting in the way of end-user productivity. Review collected by and hosted on G2.com.

The initial setup and learning curve can be challenging, especially for teams that are new to zero-trust architectures or more advanced IAM policies. While the documentation is improving, it still takes time to fully understand the policy logic and the right troubleshooting steps. Cost visibility and pricing complexity can also be a concern, particularly for smaller teams or for environments where usage fluctuates. Review collected by and hosted on G2.com.

AVA enabled secure access to applications without requiring a traditional VPN. That means fewer client-install headaches and less user friction.

It supports integration with identity providers and device posture/trust provides, which means you don't always need to build everything from scratch.

Since access policies apply every time a user tries to connect AVA becomes a daily operational tool rather than something set and forget.

AVA offers fine grained access policies, you can define access based on user identity. device posture, location etc. Review collected by and hosted on G2.com.

While AWS verified access simplifies user access compared to VPNs, the initial setup can be quite complex.

Much of the configuration still depends on AWS CLI orJSON policy editing, with limiting graphical management tools. Review collected by and hosted on G2.com.

No more VPN struggles. I no longer have to deal with connection drop-offs, slow login times, or conflicts with VPN software. Verified Access lets me reach corporate apps securely without having to tunnel through a VPN. Review collected by and hosted on G2.com.

Sometimes latency or friction when new trust devices or device posture checks are added. There have been moments when accessing an app got delayed because some device compliance check was pending or misconfigured. Review collected by and hosted on G2.com.

I like how AWS Verified Access provides secure, identity-aware access to applications without relying on traditional VPNs, making access simpler, safer, and more reliable for users while reducing operational complexity for teams. Review collected by and hosted on G2.com.

One drawback is that AWS Verified Access can feel complex to set up initially, especially for teams new to AWS identity services, and it may require additional configuration and learning before it runs smoothly. Review collected by and hosted on G2.com.

VPN-less Secure Access (Native AWS Zero Trust)

One of the standout features is that Verified Access allows you to provide secure access to internal applications and services without requiring a traditional VPN.

This simplifies user workflows (fewer VPN client issues) and reduces the surface area of VPN-related problems.

Real-Time, Request-by-Request Evaluation (Granular Control)

Verified Access doesn’t grant blanket access once and forget it. Every application request is evaluated against the policy at the moment of the request, based on trust data (identity, device posture, etc.) Review collected by and hosted on G2.com.

Resource / Quota Limits

AWS imposes default quotas (limits) on how many Verified Access resources (instances, endpoints, groups, trust providers) you can have per region.

60-Second HTTP Idle Timeout

For HTTP/HTTPS traffic, if a request takes longer than 60 seconds, the client sees an HTTP 504 (gateway timeout). Review collected by and hosted on G2.com.