AWS Verified Access – Zero Trust Application Access

AWS Verified Access – Zero Trust Application Access

AWS Verified Access provides secure access to corporate applications and resources without requiring a virtual private network (VPN). It implements Zero Trust security principles by evaluating each access request in real time against fine-grained policies based on user identity and device security posture, ensuring that only authenticated and authorized users on compliant devices can reach your applications.

Zero Trust Principles

AWS Verified Access is built on the “never trust, always verify” model. Traditional perimeter-based security grants broad network access once a user connects via VPN. Zero Trust eliminates implicit trust by:

• Verifying every request: Each application access request is evaluated independently — no persistent trust based on network location
• Least-privilege access: Users get access only to specific applications they need, not the entire network
• Continuous validation: Identity and device posture are checked on every request, not just at initial connection
• Assume breach: The architecture limits lateral movement — compromising one application doesn’t grant access to others
• Context-aware decisions: Access decisions combine multiple signals: user identity, group membership, device health, and security posture

Architecture Components

AWS Verified Access consists of four core components that work together to enforce zero trust access:

Verified Access Instance

• The top-level container that evaluates access requests and enforces policies
• Each instance is associated with one or more trust providers
• Supports AWS WAF integration for additional web security (SQL injection, XSS protection)
• Logging is configured at the instance level (S3, CloudWatch Logs, Kinesis Data Firehose)
• Can be shared across AWS accounts using AWS Resource Access Manager (RAM)

Verified Access Trust Providers

• External services that supply user identity and device security posture data
• Two categories: Identity trust providers (who the user is) and Device trust providers (device health status)
• Each Verified Access instance can have one identity provider and multiple device trust providers
• Trust data is passed to Cedar policies for access evaluation

Verified Access Groups

• Logical groupings of endpoints with similar security requirements
• Group-level access policies apply to all endpoints in the group
• Simplifies policy management — define once, apply to many applications
• Each group is associated with a Verified Access instance

Verified Access Endpoints

• Represent individual applications or resources that users access
• Each endpoint belongs to a Verified Access group and inherits its policy
• Optional endpoint-level policy for additional application-specific controls
• Four endpoint types:
  • Load Balancer: Routes requests to ALB or NLB for application distribution
  • Network Interface: Sends requests to a specific ENI with protocol and port
  • Network CIDR: Routes requests to a specified IP address range
  • Amazon RDS: Provides access to RDS instances, clusters, or DB proxies

How AWS Verified Access Works

AWS Verified Access evaluates every access request using a combination of user identity verification and device posture assessment, eliminating the need for a VPN:

1. User requests access to a corporate application via its Verified Access endpoint URL (e.g., app.example.com)
2. Authentication: The user is redirected to the configured identity provider (IAM Identity Center or OIDC-compatible IdP) for authentication
3. Device posture check: The device trust provider assesses the device’s security state (OS patch level, firewall status, disk encryption, malware protection)
4. Policy evaluation: Verified Access evaluates Cedar policies using the identity and device trust data against group-level and endpoint-level policies
5. Access decision: If both policies return Allow, the request is forwarded to the application; otherwise, access is denied
6. Logging: Every access attempt (allowed or denied) is logged for audit and security analysis

For non-HTTP(S) applications (SSH, RDP, TCP), users install the AWS Verified Access Connectivity Client on their devices. The client encrypts traffic, attaches user identity and device context, and routes it to Verified Access for policy enforcement before forwarding to the target resource.

Trust Providers

Identity Trust Providers

Identity trust providers authenticate users and supply identity claims (email, groups, roles) to Cedar policies:

Device Trust Providers

Device trust providers assess the security posture of the user’s device and provide device health signals:

Cedar Policy Language

Access policies in AWS Verified Access are written in Cedar, an open-source policy language developed by AWS. Cedar provides:

• Human-readable syntax: Policies resemble natural language — easy to write and audit
• Provably correct evaluation: Uses automated reasoning to ensure deterministic results
• RBAC and ABAC support: Role-based and attribute-based access control in a single policy
• Principal/Action/Resource model: Defines who can do what on which resource under which conditions

Example Cedar Policy — Allow engineering team on compliant devices:

Example Cedar Policy — Deny access from non-compliant devices:

Integration with Application Load Balancer (ALB)

AWS Verified Access integrates with Application Load Balancers as a primary endpoint type for HTTP(S) applications:

• Load Balancer endpoint type: Verified Access forwards authenticated and authorized requests to an internal ALB or NLB
• No public exposure needed: The ALB remains in a private subnet — only Verified Access endpoints are internet-facing
• Health checks maintained: ALB continues to perform health checks on target applications
• WAF at both layers: AWS WAF can be attached to both the Verified Access instance and the ALB for defense-in-depth
• Signed identity headers: Verified Access injects signed user identity information into HTTP headers forwarded to the ALB, allowing applications to identify the authenticated user without separate authentication logic
• On-premises applications: By pointing a Verified Access endpoint at an NLB with IP targets, you can provide zero trust access to on-premises applications connected via Direct Connect or VPN

Architecture Pattern: Verified Access + ALB

AWS WAF Integration

• Associate an AWS WAF Web ACL with a Verified Access instance for additional protection
• Provides protection against common exploits: SQL injection, XSS, known bad IPs
• With IAM Identity Center: WAF inspects traffic before user authentication
• With OIDC providers: WAF inspects traffic after user authentication
• Rate limiting and geo-blocking rules apply at the Verified Access level

Use Cases

1. Replacing Traditional VPN

• Eliminate VPN infrastructure management, licensing costs, and scalability issues
• Remove broad network access — users access only the applications they need
• Reduce VPN-related support tickets (connectivity issues, split tunneling, performance)
• No client software needed for HTTP(S) applications (browser-only access)
• Gradual migration: run Verified Access alongside Client VPN during transition

2. BYOD (Bring Your Own Device) Access

• Enable personal device access to corporate applications without VPN tunnel to corporate network
• Device trust providers verify minimum security posture (encryption, patches, antivirus)
• Conditional access: allow browser-based apps from BYOD but restrict sensitive resources to managed devices
• No corporate certificates or VPN profiles needed on personal devices

3. Contractor and Third-Party Access

• Grant time-limited, application-specific access to external contractors
• Federate contractor identities through OIDC without creating AWS or corporate accounts
• Apply stricter device posture requirements or limit to specific applications
• Easy revocation: update group policy or remove contractor from IdP group

4. Multi-Account Application Access

• Share Verified Access instances across accounts using AWS Resource Access Manager
• Centralize access policies while applications remain in separate AWS accounts
• Consistent security posture across organizational units

5. Securing Non-HTTP Resources

• Provide zero trust access to SSH sessions, RDP desktops, and TCP-based applications
• Uses AWS Verified Access Connectivity Client on user devices
• Supports access to RDS databases without exposing them publicly
• Apply same identity and device trust policies to infrastructure access

AWS Verified Access vs Client VPN vs Direct Connect vs PrivateLink

Pricing

AWS Verified Access uses a pay-as-you-go model with no upfront commitment or minimum fees:

HTTP(S) Applications

Non-HTTP(S) Applications

Logging and Observability

AWS Verified Access logs every access attempt (both allowed and denied), providing centralized visibility for security audits and incident response:

Log Destinations

• Amazon S3: Long-term archival, Athena queries, and compliance retention
• Amazon CloudWatch Logs: Real-time monitoring, alarms, and dashboards
• Amazon Kinesis Data Firehose: Stream to SIEM tools, Splunk, Datadog, or OpenSearch

Log Contents

• Timestamp and request ID
• Source IP address and port
• Verified Access instance, group, and endpoint IDs
• Access decision (Allow or Deny)
• User identity information (from trust provider)
• Device trust data (optionally included)
• HTTP method, URI, status code (for HTTP requests)
• Policy evaluation details

AWS Certification Exam Relevance

AWS Verified Access Practice Questions

1. A company wants to provide secure access to internal web applications for remote employees without deploying VPN infrastructure. They require per-request identity verification and device compliance checks. Which AWS service should they use?

   1. AWS Client VPN with MFA
   2. AWS PrivateLink with VPC endpoints
   3. AWS Verified Access
   4. Amazon CloudFront with signed URLs
   Show Answer

   Answer: C –

   Explanation: AWS Verified Access provides secure application access without VPN by evaluating each request against identity and device posture policies. Client VPN provides network-level access, not per-application zero trust. PrivateLink is for service-to-service connectivity within AWS. CloudFront signed URLs don’t provide identity/device verification.

2. An organization is configuring AWS Verified Access and needs to enforce that users can only access applications from devices with disk encryption enabled and an up-to-date OS. Which combination of trust providers should they configure? (Choose TWO)

   1. AWS IAM Identity Center as an identity trust provider
   2. CrowdStrike as a device trust provider
   3. Amazon Cognito as an identity trust provider
   4. AWS Config as a device trust provider
   5. Amazon Inspector as a device posture provider
   Show Answer

   Answer: A, B

   Explanation: Verified Access requires an identity trust provider (IAM Identity Center or OIDC) and a device trust provider (CrowdStrike, Jamf, or JumpCloud). CrowdStrike provides device posture signals including disk encryption and OS version. Amazon Cognito, AWS Config, and Inspector are not supported as Verified Access trust providers.

3. A security engineer is writing a Cedar policy for AWS Verified Access that should allow access only to users in the “finance” group who have a CrowdStrike ZTA assessment of “pass”. Which policy correctly implements this requirement?

   1. allow(principal in Group::"finance", action, resource) when { context.device.crowdstrike.overall_assessment == "pass" };
   2. permit(principal, action, resource) when { context.identity.groups.contains("finance") && context.device.crowdstrike.overall_assessment == "pass" };
   3. grant(principal, action, resource) when { identity.group == "finance" AND device.assessment == "pass" };
   4. permit(principal, action, resource) when { context.identity.email.endsWith("@finance.com") };
   Show Answer

   Answer: B –

   Explanation: Cedar policies use permit or forbid keywords (not “allow” or “grant”). The trust data is accessed via the context object, with identity data under context.identity and device data under context.device.[provider]. Option B correctly checks both group membership and device assessment.

4. A company currently uses AWS Client VPN but wants to migrate to AWS Verified Access for their web applications. During the transition, they need to maintain access for applications that use SSH and RDP. What should the solutions architect recommend?

   1. Use Verified Access for all applications immediately — it supports all protocols
   2. Use Verified Access for HTTP(S) applications and deploy the AWS Verified Access Connectivity Client for SSH/RDP access to non-HTTP endpoints
   3. Continue using Client VPN for SSH/RDP; Verified Access only supports HTTP(S)
   4. Use AWS Systems Manager Session Manager for SSH/RDP and Verified Access for HTTP(S) only
   Show Answer

   Answer: B –

   Explanation: Since February 2025, AWS Verified Access supports non-HTTP(S) protocols (SSH, RDP, TCP) through the AWS Verified Access Connectivity Client. Users install the client on their devices to access non-HTTP resources with the same zero trust policy enforcement. This eliminates the need for Client VPN for these protocols.

5. An organization needs to log all Verified Access requests for compliance auditing, including the identity claims and device posture data used in each access decision. Where can they send these logs? (Choose THREE)

   1. Amazon S3
   2. Amazon CloudWatch Logs
   3. Amazon Kinesis Data Firehose
   4. AWS CloudTrail
   5. Amazon DynamoDB
   6. Amazon SQS
   Show Answer

   Answer: A, B, C

   Explanation: AWS Verified Access supports three log destinations: Amazon S3, CloudWatch Logs, and Kinesis Data Firehose. Trust data (identity and device context) can optionally be included in these logs. CloudTrail records API calls for Verified Access management operations but does not capture per-request access logs. DynamoDB and SQS are not supported log destinations.

Frequently Asked Questions

What is AWS Verified Access?

AWS Verified Access provides secure access to corporate applications without a VPN. It evaluates each request against identity and device posture policies using Cedar policy language, following zero trust principles of ‘never trust, always verify’.

How does Verified Access replace VPN?

Instead of granting broad network access via VPN, Verified Access grants per-application access based on user identity and device security posture. Users connect directly to applications through their browser without installing VPN clients.

What trust providers does Verified Access support?

For identity: IAM Identity Center, Okta, Ping Identity, and any OIDC provider. For device posture: CrowdStrike, Jamf, and JumpCloud. You can combine identity + device trust for stronger security.

Related Posts

• AWS VPC
• AWS Security Services Cheat Sheet

References

• AWS Verified Access – Product Page
• AWS Verified Access – Documentation
• AWS Verified Access – Pricing
• Introducing AWS Verified Access – GA Blog Post
• Client VPN to Verified Access Migration Patterns
• A Walk Through AWS Verified Access Policies (Cedar)
• Non-HTTP(S) Protocol Support Blog
• Integrating with Device Trust Providers