Business Challenge
#78 ended on a token whose claims were fixed at issuance: remove a user from a group and the token in their browser still says they are in it. #79 made a decision per request but from attributes the caller supplied. This is the service that closes that loop, and AWS frames it as a direct contrast with what came before:
“A traditional security model evaluates access once and grants the user access to all applications. Verified Access evaluates each application access request in real time. This makes it difficult for bad actors to move from one application to another.”
The mechanism is the part worth reading twice: “When a user tries to access an application, Verified Access gets their data from the trust provider and evaluates it against the policies that you set for the application.” Not reads a claim. Gets the data.
The constraint is stated once and has structural consequences: “You must attach at least one trust provider to each Verified Access instance. You can attach a single identity trust provider and multiple device trust providers to each Verified Access instance.”
So device signals are plural by design — you can combine an MDM and an EDR and have both contribute — while identity is singular. An instance speaks to exactly one directory.
That is a sensible default and it decides your topology. Contractors in a separate directory from employees, or an acquisition on its own tenant, cannot be served by one instance. You get a second instance, with its own groups, its own endpoints and its own policies to keep in step — and each application that must serve both populations needs an endpoint in each.
FixSettle the identity topology before the application topology. The number of directories you must satisfy is the number of Verified Access instances you will run, and that multiplies everything beneath it.
“Verified Access evaluates the request against the access policy for the group and any application-specific endpoint policies.”
And the inheritance is automatic: “Each endpoint is associated with a Verified Access group and inherits the access policy for the group. You can optionally attach an application-specific endpoint policy to each endpoint.”
So an endpoint policy is additive rather than a replacement. Adding a stricter rule to one application does not loosen the group's, and — more to the point — loosening one application means editing the group, which reaches every endpoint in it. The grouping AWS recommends is “endpoints for applications with similar security requirements”, and that recommendation is load-bearing rather than cosmetic.
FixGroup by the policy you want, not by team or environment. A group is the unit at which a rule is written once and applied to everything inside it, so an application with genuinely different requirements wants its own group rather than an exception.
“All application requests are denied by default, until a policy is defined.”
Which is the correct default and the one that produces a confusing first hour. Stand up an instance, a group and an endpoint, point a browser at the application, and the answer is no — not because anything is misconfigured, but because nothing has said yes yet.
It is the same shape as #79, where a DENY with no determining policy means nobody granted rather than somebody forbade. Here the equivalent question is whether the deny came from a policy you wrote or from the absence of one, and the distinction matters in exactly the same way.
FixUse the logs. “Verified Access logs all access attempts”, so a denial during setup is visible rather than inferred — and knowing a default deny from an evaluated one is worth the time it takes to wire logging up first.
Architecture
Five nouns, and the relationships between them decide everything else.
The five components
| Component | What it is |
|---|---|
| Instance | “an AWS resource that helps you organize your trust providers and Verified Access groups” — and the thing that evaluates |
| Endpoint | “represents an application” — load balancer, network interface, network CIDR, or RDS |
| Group | “A collection of Verified Access endpoints”, sharing one inherited policy |
| Access policy | Rules on “a combination of factors, including user identity and device security state” |
| Trust provider | “A service that manages user identities or device security state” |
What "trust data" actually is, and the word AWS uses for it
“Trust data — The security-related data for users or devices that your trust provider sends to Verified Access. Also referred to as user claims or trust context.”
User claims is the same word #78 was about, and the difference is entirely in the timing. A Cognito claim is written into a token at issuance and asserts what was true then. A Verified Access claim is fetched from the provider when the request arrives. Same noun, opposite freshness guarantee.
The examples show the range: “attributes based on user identity, such as an email address” or membership in a named organisational group, or “device information such as installed security patches or anti-virus software version”. The second half is the part a bearer token cannot carry usefully, because a patch level at nine in the morning says nothing about the laptop at five.
The endpoint types are “Load balancer… Network interface… Network CIDR… Amazon Relational Database Service (RDS) — Application requests are sent to an RDS instance, RDS cluster, or RDS DB proxy.”
Everything else on that list is a way of reaching a web application. RDS is a database — so this is per-request, device-aware, identity-aware access control in front of a database, for the analyst connecting with a SQL client rather than a browser. That is a different problem from the one Verified Access is usually described as solving, and it is the one most organisations currently answer with a bastion host and a VPN.
Where policy actually lives
Two levels, evaluated together:
Group policy — written once, “inherited by all endpoints in the group”. This is where the rules that apply to a class of application belong: the device must be managed, the user must be in the right directory group, the posture must be current.
Endpoint policy — “optionally” attached to one application. This is for the requirement that genuinely differs: the finance application that additionally wants a stronger authentication assurance, say.
Because both are evaluated, the group is a floor you cannot go below from an endpoint. Any argument that ends with "but this one application needs to be more permissive" is an argument for a different group, not for an endpoint policy.
Why This Architecture Holds Up
Removing the VPN removes a class of problem rather than relocating it
“Verified Access removes the need for users to use a VPN to access your applications. This helps reduce the number of support cases arising from VPN-related issues.”
The support-case framing undersells it. A VPN's real cost is architectural: it makes network position a proxy for authorisation, so every application behind it inherits the same trust decision, made once at connection time. The lateral movement AWS mentions — “difficult for bad actors to move from one application to another” — is the direct consequence of per-application evaluation replacing per-session admission.
Logging every attempt is what makes the model auditable
“Verified Access logs all access attempts, providing centralized visibility into application access, to help you quickly respond to security incidents and audit requests.”
All attempts, not all grants. That is the difference between a log that answers "who used this application" and one that answers "who tried". For a service whose default is deny, the denials are the interesting half — they are where a failing device posture or a removed directory membership shows up as behaviour rather than as a ticket.
It is also the answer to the setup confusion in card 3: a default deny and a policy-evaluated deny both end a request, and the log is the only thing that distinguishes them.
“You are charged hourly for each application on Verified Access, and you are charged for the amount of data processed by Verified Access.”
Two components with different shapes. Data processing scales with use, which is the half people plan for. The per-application hourly charge does not — an endpoint for an application nobody has opened since March bills exactly like one carrying production traffic.
So the number of endpoints is a standing cost, and decommissioning an application means deleting its endpoint rather than merely pointing it nowhere. That belongs in the same checklist as #80's point about share definitions in code: the resource outlives the thing it was created for unless something removes it.
The device half is where this earns its place
Multiple device trust providers, evaluated per request, against data like “installed security patches or anti-virus software version”. That is a control a token-based model cannot express at all, because the facts change on a timescale shorter than any sensible token lifetime.
It is also the connection to a backlog item from last week: Client VPN gained device posture assessment on 5 October. Both are answers to the same question — the credential was valid and the device should not have been there — and the difference is where the check sits. Client VPN checks at admission to the network; Verified Access checks at admission to each application.
Key Architecture Decisions
| Decision | Choice | Reasoning |
|---|---|---|
| Number of instances | One per identity source | “a single identity trust provider” per instance is the hard constraint. |
| Device signals | Attach more than one where you have them | “multiple device trust providers” are supported, and they answer different questions. |
| Grouping endpoints | By security requirement, not by team | The group policy is “inherited by all endpoints in the group”. |
| An application needing looser rules | Give it its own group | Endpoint policy is additive; it cannot relax the group's floor. |
| First deployment | Wire up logging before the first endpoint | Default deny means your first test fails, and the log is what tells you why. |
| Database access | Consider the RDS endpoint type | It reaches “an RDS instance, RDS cluster, or RDS DB proxy” — the bastion-host problem. |
| Decommissioning | Delete the endpoint | The hourly charge is “for each application” regardless of traffic. |
| Auditing access | Read denials as well as grants | “logs all access attempts”, and for a default-deny service the denials carry the signal. |
The audit worth running
Count your Verified Access endpoints and reconcile them against applications that still exist. Each one is an hourly charge and a policy surface, and an endpoint whose application was retired is both a cost and a row that makes the inventory harder to read.
Then look at which endpoints carry their own policy. Every endpoint policy is a statement that this application differs from its group — which is sometimes true and is more often a sign that the grouping was done by org chart rather than by requirement.
Closing Thought
This is the post that resolves something four others have been circling. #78 showed a credential asserting what was true when it was signed. #79 showed a decision made per request but from data the caller chose to send. #80 showed access whose other half was administered elsewhere. Verified Access answers all three the same way: it goes and asks, every time, and the asking is the product.
What it costs is a different kind of coupling. You are now live-dependent on a trust provider for every request rather than once per session, your identity topology is pinned to one directory per instance, and every application is an hourly line item whether anyone opens it or not. Those are real trades, and they are the honest price of not having a network perimeter do your authorisation for you.
The sentence to carry away is AWS's own, because it is the whole design in one line: “A traditional security model evaluates access once and grants the user access to all applications.” Every bearer token, every VPN session and every long-lived credential in this series has been a variation on that sentence. This is the first service in the block built to refuse it.
Security & Identity — Amazon Security Lake: what normalising to OCSF actually changes about a query, why subscriber access is not the same as bucket access, and what happens to data you were already collecting elsewhere.
Official AWS Reference
- What is AWS Verified Access — the per-request evaluation model, the contrast with evaluating access once, the logging guarantee, and the two-part pricing
- How Verified Access works — the five components, the default-deny rule, group policy inheritance alongside endpoint policies, the single-identity and multiple-device trust provider constraint, and the definition of trust data
- Trust providers for Verified Access — what trust context contains and the two supported provider categories
- Verified Access endpoints — that an endpoint represents an application and inherits its group's policy, and the four endpoint types including RDS
- Verified Access instances — what an instance organises and evaluates
- Verified Access groups — further reading on group management; no claims in this post are drawn from it
Comments