If your users still fire up a VPN just to reach an internal app, you’re carrying old complexity into a world that’s moved to Zero Trust. AWS Verified Access is Amazon’s managed service that gives employees, contractors, and partners secure access to private apps without a VPN. It checks who the user is and whether their device is healthy every single time they try to reach an app, and only then lets them in.
Why do we need it?
Traditional VPNs implicitly trust anything on the network once connected. That creates big blast radiuses (one compromised laptop can wander around your network) and painful user experiences (slow, clunky). Verified Access flips this: each request is verified against policies using identity and device posture, so you can grant the least access needed and block risky devices automatically. It also simplifies operations—policies live in one place instead of being sprinkled across appliances and apps.
Where it helps right away:
Developers & DevOps tools – Restrict access to Jenkins, GitLab, or SonarQube without exposing the whole VPC.
Cloud admins – Secure entry to Systems Manager or CloudWatch with MFA and device health checks.
Contractors/partners – Grant time-bound, auditable access to only the AWS resources they need.
BYOD/mixed fleets – Verify posture of Windows/macOS/Linux devices before allowing access.
Regulated workloads – Centralize policies and logs to meet compliance and audit requirements.
What exactly is Verified Access?
Think of it as a managed reverse proxy + policy engine that sits in front of your private applications. When someone tries to open your app, Verified Access:
Collects “trust data” from your identity provider (user, group, email) and optional device provider (OS version, EDR status, encryption, etc.).
Evaluates your policy for that app or group of apps.
Allows or blocks the request and logs the decision.
Under the hood, your building blocks are:
Verified Access instance – the top-level container for your setup.
Groups – to share policies across sets of applications.
Endpoints – each application you protect gets an endpoint and inherits the group policy (you can add app-specific rules too).
Policies are written in Cedar, AWS’s policy language, so you can express rules like “Allow HR staff on a compliant device during business hours.”
How does it work with identity and devices?
Verified Access instances – Check application requests and allow access only if security requirements are met.
Verified Access endpoints – Each endpoint represents an application (e.g., an app hosted on EC2 behind a load balancer).
Verified Access groups – A collection of endpoints with similar security needs, making policy management easier (e.g., grouping all sales apps).
Access policies – Rules that allow or deny access based on factors like user identity and device state. Group policies apply to all endpoints, and you can also set app-specific policies.
Trust providers – Manage user identity or device security (AWS or third-party). Each instance needs at least one identity provider and can have multiple device providers.
Trust data – Security data (like user email or device OS version) sent by trust providers. Verified Access uses this data to enforce access policies.
This combo lets you write fine-grained rules. Examples:
Grant access to monitoring tools (Grafana, Prometheus) only to users with MFA enabled and devices with up-to-date vulnerability scans
Permit Jenkins/GitLab access only from build agents with specific security baseline configurations and valid certificates
Does it only work for web apps?
It started with HTTP(S) apps, but now also supports non-HTTP resources such as RDS databases or anything reachable via ENI/LB/IP inside your VPC. That means you can provide VPN-less access to databases and other TCP services using the same identity/device checks.
What does setting it up look like?
At a high level:
Create a Verified Access instance.
Add trust providers: your IdP (IAM Identity Center, Okta, Duo SSO, etc.)
Create a group and attach policies (Cedar).
Create endpoints—one per app (web or non-HTTP). Each endpoint inherits the group policy; add app-specific rules if needed.
Test with a pilot user group, review logs, then scale.
Tip: Start with identity-only rules (user/group) to prove value, then layer device posture once your device provider is integrated.
Pricing in plain words
You pay for:
Per-application hours (each protected app/endpoint accrues an hourly charge).
Data processed (for HTTP/S) or endpoint hours + per-connection (for non-HTTP).
Check the current table for your Region before planning, because rates vary. Cost drivers are how many apps you protect, how long they’re “on,” and traffic volume.
What about logging and audits?
Verified Access logs every access attempt, including the policy evaluation context. That helps with incident response, forensics, and compliance audits (who accessed what, when, and why it was allowed). Pipe logs to CloudWatch Logs/S3/SIEM like Splunk to alert on anomalies (e.g., repeated device-health failures).
Pros :
What you’ll likely love
No VPN client or split tunnel wrangling for most use cases.
Centralized, human-readable policies evaluated on every request.
Fits neatly with Zero Trust rollouts; easy wins with a few high-value apps first
Things to plan for
Budget model it early with your Region’s rates.
Device posture signals require integrating a provider and deploying a small browser extension (Chrome/Firefox are supporteer protected app and traffic—d).
Good starter patterns
DevOps dashboards – Secure Jenkins/GitLab with identity + MFA.
AWS consoles – Require healthy devices before accessing CloudWatch or SSM.
Databases – Gate RDS access with identity + posture, no VPN.
Kubernetes – Enforce verified devices for EKS kubectl access.
Bottom line
AWS Verified Access is a practical way to modernize remote access. It removes the VPN dependency for many internal apps, replaces “network trust” with per-request verification, and centralizes policies that blend identity and device health. Start small—protect one internal app with identity rules—then turn on device posture and expand to non-HTTP services like databases. You’ll improve security and the user experience in one move.
