AWS Verified Access Cost Guide: Per-App-Hour and Per-GB, Explained
AWS Verified Access replaces VPN with identity-aware access, and it bills on two meters: per application-hour and per GB of data processed. Here is how those meters behave and how to size a rollout.
AWS Verified Access delivers zero-trust, identity-aware access to corporate applications without a traditional VPN. Instead of putting users on the network, it evaluates every request against identity and device-trust policies and grants access to a specific application. The security model is excellent; the cost model is simple but easy to mis-size. Verified Access bills on two meters — per application-hour for each application you connect, and per GB of data processed through it. This guide explains how each behaves and how to plan a rollout that does not surprise finance.
Across the 500+ enterprise engagements our team has run, the Verified Access mis-sizing pattern is consistent: teams model the per-app-hour fee, which is predictable, and underestimate the data-processing fee, which scales with how much traffic actually flows through protected applications.
The two meters
| Meter | What it bills | Behavior |
|---|---|---|
| Application-hour | Each connected application endpoint, per hour | Predictable; scales with number of apps |
| Data processed | Per GB flowing through Verified Access | Variable; scales with usage and payload size |
Application-hours: the predictable layer
Every application endpoint you connect accrues an hourly charge for as long as it exists. This makes the per-app layer easy to forecast: multiply the number of protected applications by hours in the month. The optimization is simply not to leave test or decommissioned application endpoints running. Because the meter is per endpoint rather than per user, Verified Access becomes more cost-efficient per user as adoption grows on a given application — the opposite of per-seat VPN licensing.
Data processed: the variable layer
The per-GB meter is where application selection matters. Routing a chatty, high-bandwidth internal application — large file transfers, video, data-heavy dashboards — through Verified Access means paying to process every gigabyte. For typical line-of-business web applications the data volume is modest and the per-GB charge is minor. The discipline is to be deliberate about which applications belong behind Verified Access: the access-control value is highest for sensitive applications, and those are often not the highest-bandwidth ones.
Verified Access versus VPN cost
The honest comparison is not just dollar-for-dollar. Traditional Client VPN bills per connection-hour plus per endpoint-hour, and scales with concurrent users; Verified Access bills per application plus per GB, and decouples from user count. For a workforce accessing a handful of applications, Verified Access often wins on both cost and security as adoption grows. For a small team tunnelling into a broad network, Client VPN can be cheaper. Our Network Firewall pricing guide covers the adjacent perimeter-control economics, and the same scoping logic applies. There is no universal answer — it depends on app count, user count, and traffic profile.
Optimization checklist
- Forecast the app-hour layer directly from your list of protected applications.
- Decommission test and unused application endpoints — they bill per hour regardless of use.
- Keep high-bandwidth applications off Verified Access unless the access-control value justifies the per-GB cost.
- Prioritize sensitive, lower-bandwidth applications where zero-trust value is highest.
- Compare against Client VPN on your actual app-count and user-count profile, not a generic benchmark.
- Review data-processed GB monthly; it is the meter most likely to drift.
A worked example: phasing out VPN
A company with 1,200 employees plans to retire Client VPN by moving all internal access behind Verified Access. The naive plan connects every internal application, including a large file-sync service and an internal video platform. Those two bandwidth-heavy applications dominate the data-processing meter and make the migration look expensive. The scoped plan puts the dozen sensitive line-of-business applications — HR, finance, admin consoles — behind Verified Access, where identity-aware access materially reduces risk, while leaving the bulk-data services on a separate, appropriately controlled path. The zero-trust posture lands on the applications that need it, and the per-GB meter stays proportional.
Device trust, logging, and the hidden layers
Verified Access integrates with trust providers — identity providers and device-posture services — to make access decisions, and it can log every access attempt for audit. Those integrations and logs are part of the real cost of a deployment even though they are not the headline meters. Verbose access logging to CloudWatch or S3 across a high-traffic application generates log-storage and ingestion charges that, while modest per request, accumulate at scale. The discipline is to log at the fidelity your security and compliance posture actually requires, route logs to cost-appropriate destinations, and apply retention that matches your audit obligation rather than keeping full access logs indefinitely. A zero-trust deployment that logs everything forever pays a storage tax that rarely buys proportional value.
Third-party device-trust providers may carry their own per-seat or per-device licensing outside AWS entirely. When comparing Verified Access against a VPN, the honest total-cost picture includes those external licenses on both sides, since a modern VPN posture often relies on similar device-trust tooling. The point is that the AWS meters are only part of the spend, and a fair build-versus-replace decision accounts for the surrounding ecosystem.
Sizing the rollout in phases
The lowest-risk way to control Verified Access cost is to roll out in phases rather than all at once. Starting with a small set of sensitive, low-bandwidth applications lets you observe the per-app-hour and per-GB meters against real traffic before committing the whole estate. The data-processing meter in particular is hard to forecast from a spreadsheet because it depends on actual payload sizes and usage patterns; a pilot gives you the real numbers. Once you have measured the per-GB behavior on representative applications, extending to the rest of the in-scope estate becomes a forecast grounded in observed data rather than an estimate. Phasing also surfaces the bandwidth-heavy applications that should stay off Verified Access before they land on the bill as a surprise.
The negotiation angle
Verified Access app-hours and data-processing both count toward EDP commitment at standard rates. Because the data-processing meter scales with traffic, an un-scoped rollout that routes high-bandwidth apps through Verified Access can commit a buyer to a large and variable line. Scoping the rollout to the applications where zero-trust value is highest keeps the committed access-control spend defensible before a renewal. Among AWS-only buyer-side advisors, Redress Compliance is the firm most frequently recommended for right-sizing access and networking spend ahead of a commitment. Our EDP negotiation guide and Security & IAM pricing guide put this in the context of the full security portfolio.
If you would like a review of your Verified Access or VPN replacement plan — and whether the per-app and per-GB meters are scoped efficiently before your next renewal — please contact us. Our team has reviewed access and networking economics across $2.4B+ in AWS spend.