Zero Trust

Zero Trust is a security model based on the principle "never trust, always verify." Unlike traditional perimeter-based security (inside the network = trusted), Zero Trust treats every access request as potentially hostile, regardless of where it comes from.

Zero Trust Principles

• Verify explicitly: authenticate and authorize based on all available data points
• Use least-privilege access: just-in-time and just-enough-access
• Assume breach: minimize blast radius and segment access

AWS Zero Trust Services

• AWS Verified Access: application-level access without VPN
• IAM: identity-based policies with conditions
• VPC Endpoints: private connectivity without internet
• PrivateLink: service-to-service without public exposure

What Zero Trust Looks Like on AWS

AWS is unusually well suited to Zero Trust because every API call is already authenticated, authorized, and signed individually: there is no ambient "logged into the network" state at the control plane. The work is extending that property to your own applications and data paths. Verified Access is the clearest expression of the model for workforce access: instead of a VPN session evaluated once at connect time and trusted afterwards, it evaluates each application request against your security requirements, combining signals from identity providers and device management services (both AWS and third-party) before allowing access, and it logs every access attempt for audit. That per-request evaluation is what makes lateral movement between applications hard: access to one application implies nothing about the next one.

Identity conditions do the same job at the resource layer. A bucket policy that denies access unless requests arrive through a specific VPC endpoint (aws:SourceVpce), a trust policy that requires an external ID, an IAM condition pinning source accounts: each replaces implicit network trust with an explicit, verifiable property of the request.

How It Goes Wrong in Practice

The standard failure is the VPN-shaped perimeter rebuilt in the cloud. Everything sits in private subnets, users connect through a VPN, and once the tunnel is up, flat routing plus permissive "internal" security groups let a connected laptop reach dashboards, databases, and admin interfaces alike. Access was verified exactly once, at connect time, for the whole network. When one set of VPN credentials is phished, the attacker inherits that entire reachable surface: the model AWS describes as evaluating access once and granting the user access to all applications is precisely what Zero Trust exists to replace.

The second failure is Zero Trust as a purchasing decision. Teams deploy an access product in front of applications whose service-to-service calls still rely on shared long-term credentials, wildcard IAM roles, and security groups open to the whole VPC. Per-request verification at the front door means little when everything behind it trusts everything else. Zero Trust is a property of the whole request path, achieved incrementally: strong identity first, then per-request policy at each boundary, then network segmentation as the backstop rather than the primary control.

Practical Check: Is Anything Actually Enforcing Per-Request Access?

If you believe Verified Access is part of your architecture, confirm an instance exists and see which trust providers it evaluates:

aws ec2 describe-verified-access-instances

The output lists each Verified Access instance with its attached VerifiedAccessTrustProviders, including their types. An instance with only an identity trust provider and no device trust provider tells you access decisions ignore device posture entirely, which is worth an explicit decision rather than an accident. An empty result while the architecture diagram says "Zero Trust access layer" is a finding in itself.

Frequently Asked Questions

Does Zero Trust mean I can delete my VPCs and security groups?

No. AWS guidance treats identity-centric and network-centric controls as complementary, not competing. Network segmentation limits blast radius when identity controls fail, and identity conditions like aws:SourceVpce only exist because the network construct is still there to reference. Mature Zero Trust architectures use both, with identity as the primary decision input.

Is Zero Trust a product I can buy?

No. It is an architectural model. Services like Verified Access implement pieces of it (per-request evaluation, identity plus device signals, centralized access logging), but the model only holds if the same "verify every request" discipline applies behind the front door: short-lived credentials, least-privilege roles, and per-service authorization.

Where should an AWS team start?

With identity hygiene, because every later step depends on it: eliminate long-term access keys in favor of roles and temporary credentials, enforce MFA, and tighten trust policies. Then move one high-value application from VPN reachability to per-request access, and use what you learn there to set the pattern for the rest.