---
title: AWS Verified Access in Production: A Zero-Trust Network Access (ZTNA) Replacement for Legacy VPN
description: AWS Verified Access is the AWS-native Zero-Trust Network Access service for workforce app access. This guide covers deploying Verified Access endpoints, configuring trust providers (IAM Identity Center, OIDC, device-posture from Jamf / CrowdStrike / Jumpcloud), writing Cedar policies, and migrating workforce traffic off Client VPN.
url: https://www.factualminds.com/blog/aws-verified-access-ztna-zero-trust-network/
datePublished: 2026-04-28T00:00:00.000Z
dateModified: 2026-04-29T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: verified-access, ztna, zero-trust, vpn-replacement, network-security, cedar, identity-center, aws
---

# AWS Verified Access in Production: A Zero-Trust Network Access (ZTNA) Replacement for Legacy VPN

> AWS Verified Access is the AWS-native Zero-Trust Network Access service for workforce app access. This guide covers deploying Verified Access endpoints, configuring trust providers (IAM Identity Center, OIDC, device-posture from Jamf / CrowdStrike / Jumpcloud), writing Cedar policies, and migrating workforce traffic off Client VPN.

AWS Verified Access is the AWS-native **Zero-Trust Network Access (ZTNA)** service for workforce app access. It replaces the legacy "VPN gives the user a flat network and we hope IAM and security groups keep them out of things" pattern with **per-request Cedar policy evaluation** at the AWS network edge — no flat network, no broad implicit trust, and no client required for HTTP applications.

This guide is for platform engineers, security architects, and IT teams running internal applications on AWS for a workforce that currently connects through AWS Client VPN, OpenVPN, or a third-party ZTNA tool. It covers the architecture, trust-provider configuration, Cedar policy patterns, the 2025 TCP-application support, and the migration playbook off legacy VPN.

> **Need help migrating workforce access to Verified Access?** FactualMinds runs ZTNA migration engagements with IAM Identity Center as the workforce identity backbone. [See our cloud security service](/services/aws-cloud-security/) or [talk to our team](/contact-us/).

## Why ZTNA, not VPN

The "perimeter VPN" pattern — user authenticates once, gets a routable IP on the private network, accesses everything that IP can reach — has been the standard for 25 years and the source of most lateral-movement incidents in that window. Once an attacker compromises a user device, the VPN is the door into the entire internal estate.

ZTNA inverts the model:

- No flat network. Every application has its own endpoint.
- No broad trust. Every request is evaluated against a policy that considers principal, device posture, network, time, and request attributes.
- No persistent session privilege. The session is short-lived; the policy re-evaluates on connection and on context change.
- Application-aware. The endpoint understands HTTP and can apply WAF, rate limiting, and per-path policy.

AWS Verified Access implements this model AWS-natively: integrates with IAM Identity Center for workforce identity, with generic OIDC and SAML 2.0 for non-AWS IdPs, with device-posture providers (Jamf, CrowdStrike, Jumpcloud) for device verification, and with Cedar — the same open-source policy language that powers Amazon Verified Permissions — for the request-evaluation logic.

## Architecture overview

Verified Access components:

- **Verified Access instance** — a tenant-level resource that hosts one or more groups.
- **Verified Access trust providers** — identity sources (IAM Identity Center, OIDC, SAML 2.0) and device-posture providers (Jamf, CrowdStrike, Jumpcloud).
- **Verified Access groups** — logical groupings of endpoints that share a Cedar policy.
- **Verified Access endpoints** — per-application entry points. Each endpoint maps to a target (an Application Load Balancer, a Network Load Balancer, an EC2 instance via the new TCP support, or a private domain).

The request flow:

1. User opens https://app.internal.example.com (the Verified Access endpoint URL).
2. Verified Access redirects to the trust provider for authentication.
3. User authenticates (IAM Identity Center → Okta/Entra ID/Identity Center directory, plus MFA).
4. Verified Access collects device-posture signals from the configured device-posture trust provider.
5. Verified Access evaluates the Cedar policy with a context containing principal, request, device, and trust-provider data.
6. If the policy permits, the request is forwarded to the target application.
7. Every decision is logged to CloudWatch Logs / S3 / Kinesis Firehose for audit.

## Step 1: Set up trust providers

Two categories — identity and device.

**Identity provider.** For workforce, IAM Identity Center is the right choice — it centralizes the federation to your IdP (Okta, Microsoft Entra ID, Google Workspace, or its own directory), propagates the user identity through to the Verified Access policy context, and is the same Identity Center you use for AWS Console / CLI access. Configure once:

```bash
aws verifiedaccess create-verified-access-trust-provider \
    --type user \
    --user-trust-provider-type iam-identity-center \
    --policy-reference-name "iam-idc"
```

For non-AWS workforces or third-party tools, use generic OIDC pointing at your IdP's OIDC discovery URL.

**Device-posture provider.** Optional but recommended for high-sensitivity apps. Verified Access integrates with Jamf (macOS), CrowdStrike (Windows/macOS/Linux endpoint protection), and Jumpcloud (cross-platform). The provider returns a posture document on every request (compliance status, OS version, encryption status, last-known-good check-in time) which is exposed to the Cedar policy as `device.is_compliant`, `device.last_seen`, etc.

```bash
aws verifiedaccess create-verified-access-trust-provider \
    --type device \
    --device-trust-provider-type jamf \
    --device-options TenantId=jamf-tenant-id \
    --policy-reference-name "device-jamf"
```

## Step 2: Create groups and write Cedar policies

A group bundles endpoints that share a policy. Typical layout: `engineering-internal-tools`, `finance-back-office`, `executive-only`.

A simple Cedar policy:

```text
permit (
  principal,
  action,
  resource
)
when {
  principal in IAMIdentityCenterUser::"engineering-group" &&
  context.http_request.method in ["GET", "POST", "PUT", "DELETE"] &&
  context.device.is_compliant == true &&
  context.geo.country in ["US", "UK", "DE", "IN"]
};
```

A more advanced policy that escalates MFA for sensitive paths:

```text
permit (
  principal,
  action,
  resource
)
when {
  principal in IAMIdentityCenterUser::"finance-group" &&
  context.device.is_compliant == true
}
unless {
  context.http_request.path like "/admin/*" &&
  context.identity_center.amr.contains("mfa") == false
};
```

Cedar is type-checked on save; a typo in `device.is_complient` (sic) fails validation rather than silently denying.

## Step 3: Create Verified Access endpoints

For an Application Load Balancer target:

```bash
aws verifiedaccess create-verified-access-endpoint \
    --verified-access-group-id vagrp-1234567890abcdef0 \
    --endpoint-type load-balancer \
    --attachment-type vpc \
    --domain-certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/abc \
    --application-domain app.internal.example.com \
    --endpoint-domain-prefix app \
    --load-balancer-options '{"Protocol":"HTTPS","Port":443,"LoadBalancerArn":"arn:aws:elasticloadbalancing:..."}'
```

The endpoint exposes a public DNS name (under `*.vae.amazonaws.com`); CNAME your `app.internal.example.com` record to that DNS name. For the TCP-endpoint variant added in 2025, the target is a Network Load Balancer or specific EC2 ENIs and users connect via the AWS Verified Access client.

## Step 4: Wire WAF and Shield

Verified Access endpoints can sit behind AWS WAF. The pattern: a single Verified Access WAF Web ACL with managed rule groups (AWS-AWSManagedRulesCommonRuleSet, AWS-AWSManagedRulesKnownBadInputsRuleSet, AWS-AWSManagedRulesIpReputationList) attached to every Verified Access endpoint. AWS Shield Standard is automatically applied; for high-value endpoints, AWS Shield Advanced provides DDoS mitigation reporting and emergency response.

## Step 5: Enable logging

Verified Access logging exports per-request decisions:

```bash
aws verifiedaccess update-verified-access-instance-logging-configuration \
    --verified-access-instance-id vai-1234567890abcdef0 \
    --access-logs CloudWatchLogs={Enabled=true,LogGroup=/aws/verified-access/instance-1}
```

Each log entry includes the principal, request attributes, evaluated policy, decision, and trust-provider data — gold for incident investigation and audit. Route to Security Lake (OCSF format) for SIEM ingestion.

## Migration playbook from Client VPN

For a mid-size deployment (say, 30 internal apps, 300 users currently on Client VPN):

1. **Inventory.** List every internal application reachable through Client VPN. Classify HTTPS-front (Verified Access target), TCP/UDP-only legacy (TCP endpoint or remain on Client VPN), thick-client legacy (likely remain on Client VPN until app modernization).
2. **Identity backbone.** Confirm IAM Identity Center is configured and federated to your workforce IdP. If not, set up Identity Center first — it is a prerequisite for the workforce identity story.
3. **First wave (web apps, lowest risk).** Pick 3-5 internal HTTPS apps that are not business-critical (internal docs, internal status dashboards). Set up Verified Access endpoints with a permissive Cedar policy (group membership + MFA only). Pilot with the IT and security teams for two weeks.
4. **Tighten policy.** Add device-posture, add geo-restrictions, add path-based MFA escalation. Confirm legitimate workflows still work; fix any false-positive denies in the policy.
5. **Second wave (developer tools, higher risk).** Migrate Jenkins, ArgoCD, internal Grafana, internal Confluence/Jira. Engage the engineering team in policy design — they know which paths are sensitive.
6. **Third wave (back-office and finance).** Migrate finance-team and HR-tool access. Tighter device-posture requirements, stricter geo-restrictions, time-of-day controls if relevant.
7. **TCP endpoints (if needed).** For SSH bastion access, internal Postgres consoles, RDP fleets — set up Verified Access TCP endpoints with the AWS Verified Access client.
8. **Decommission.** Once 90% of traffic has moved to Verified Access, sunset Client VPN endpoints. Keep one fallback Client VPN for legacy thick-client apps until they are modernized or replaced.

Typical timeline for a 30-app / 300-user migration: 8-12 weeks if you do not hit unexpected app-specific weirdness; 16-20 weeks with the typical real-world surprises.

## Common pitfalls

1. **Skipping IAM Identity Center.** Verified Access works without Identity Center (using generic OIDC) but the integration loses workforce-identity propagation. Set up Identity Center first.
2. **Permissive Cedar policies that never tighten.** Most teams ship a wide-open policy for the first wave and never come back. Schedule a 30-day review where the policy is tightened to the minimum that keeps legitimate workflows working.
3. **Forgetting WAF.** Verified Access endpoints are public; a misconfigured Cedar policy plus no WAF is the worst-case scenario. Default-attach a WAF ACL to every endpoint.
4. **Logging not routed to Security Lake.** Verified Access logs are gold for investigation. If they only go to a CloudWatch log group nobody reads, you lose the audit value.
5. **Mixing identity providers in one group.** A group with both an IAM Identity Center trust provider and an OIDC trust provider creates ambiguous policy semantics. Use one identity trust provider per group; create separate groups for separate populations.

## Where to go next

- Read the **[AWS Verified Access User Guide](https://docs.aws.amazon.com/verified-access/)**.
- Pair with **[IAM Identity Center for workforce SSO](/blog/aws-iam-identity-center-workforce-sso-identity-propagation/)** as the identity backbone.
- Pair with **[AWS Network Firewall + Firewall Manager](/blog/aws-network-firewall-firewall-manager-multi-account/)** for the broader network defense.
- Learn the **[Cedar policy language](https://www.cedarpolicy.com/)**, the same language that powers Amazon Verified Permissions.
- Browse the **[AWS Security & Compliance hub](/security-compliance/)** and the **[Network & Application Security subtopic](/security-compliance/network-application-security/)**.

ZTNA is the workforce-access architecture for the next decade. Verified Access makes the migration AWS-native and the policy easier to evolve than custom VPN ACLs. Most teams discover that the Cedar policy is more readable, more reviewable, and less error-prone than the security-group + VPN ACL combination it replaces.

## FAQ

### What workloads should we migrate from Client VPN to Verified Access?
Web and HTTPS-fronted internal applications are the right target — internal Jenkins, ArgoCD, internal Grafana, internal SaaS clones, internal admin dashboards, internal Confluence/Jira, ML notebook gateways, internal API consoles. With Verified Access, each application has its own endpoint, trust providers, and Cedar policy that decides per-request whether to allow access. There is no client to install for HTTP apps. Keep Client VPN only for legacy use cases that need raw TCP/UDP at scale to broad subnets — finance/healthcare back-office tools, RDP fleets, legacy thick-client apps. Even there, plan the Verified Access migration as those legacy apps go web-first. Verified Access also supports raw TCP endpoints (added 2025) so the gap is narrowing.

### How does Verified Access differ from third-party ZTNA (Zscaler, Cloudflare Access, Twingate)?
Verified Access is AWS-native and integrates directly with IAM Identity Center, AWS WAF, and Cedar policy — no agent required for HTTP applications, the policy evaluation runs at the AWS network edge, and findings flow to Security Hub. Third-party ZTNA tools add capabilities AWS does not (cross-cloud reach to Azure/GCP, deep agent-based device posture, broader app catalog connectors, browser-isolation features) and may be the right call for organisations that already standardize on Zscaler or Cloudflare for security. For AWS-only workforce app estates, Verified Access wins on integration and operational simplicity. Many enterprises run both: Verified Access for AWS-native apps, third-party ZTNA for cross-cloud and on-prem.

### Do users need to install a client for Verified Access?
No client is needed for HTTP/HTTPS applications — users access via a standard browser pointed at the Verified Access endpoint URL. The only requirement on the user side is authentication through the configured trust provider (IAM Identity Center, generic OIDC, SAML 2.0). For TCP applications added in the 2025 release (RDP, SSH, internal Postgres, internal Redis), the AWS Verified Access client is required — a thin client comparable to AWS Client VPN that establishes a tunnel from the user device to the Verified Access endpoint. The client adds device-posture verification (combined with Jamf, CrowdStrike, Jumpcloud, or other trust providers) and supports SSO via IAM Identity Center.

### How do Cedar policies work in Verified Access?
Each Verified Access group attaches a Cedar policy that evaluates on every request. The policy receives a context including the authenticated principal (from IAM Identity Center or OIDC), HTTP request attributes (path, method, source IP, headers), and trust-provider data (device-posture score from Jamf, geo-location, MFA status). A typical policy: permit when principal in `["group::engineering"]` AND http_request.method in ["GET","POST"] AND device.is_compliant=true AND geo.country in ["US","UK","DE"]. Cedar policies are version-controlled in the AWS Console / Terraform / CloudFormation, validated for type-safety on save, and evaluated at the AWS network edge with sub-millisecond latency. Updates take effect within seconds across all endpoints.

### What does Verified Access cost compared to Client VPN?
Verified Access pricing has two components: per Verified Access endpoint per hour (charged per running endpoint regardless of traffic) and per-hour application connection-time (charged when users are authenticated). Most organisations find the cost comparable to or lower than AWS Client VPN at the same user scale, with the operational benefit of per-application granularity instead of per-VPN broad subnet access. The break-even depends on app count, user count, and how aggressively you scope each endpoint — if you have 50 internal apps and 500 users, Verified Access typically lands well below an equivalent Client VPN footprint with broad-subnet access. Run the AWS Pricing Calculator with your specific numbers before quoting executive-level cost projections.

---

*Source: https://www.factualminds.com/blog/aws-verified-access-ztna-zero-trust-network/*