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 (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 or talk to our team.

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:

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.

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:

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:

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:

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:

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.
• Pair with IAM Identity Center for workforce SSO as the identity backbone.
• Pair with AWS Network Firewall + Firewall Manager for the broader network defense.
• Learn the Cedar policy language, the same language that powers Amazon Verified Permissions.
• Browse the AWS Security & Compliance hub and the Network & Application Security subtopic.

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.