Implementing Zero Trust Architecture on AWS: Verified Access, VPC Lattice, and Identity-Centric Security

The traditional security model — "trust everything inside the network perimeter" — doesn't work in cloud. There is no perimeter. Resources span multiple accounts, regions, and connectivity paths. Developers deploy from home networks. APIs are called from everywhere.

Zero Trust flips the model: never trust, always verify. Every request is authenticated, authorized, and encrypted — regardless of where it comes from. On AWS, this isn't a single product. It's an architecture pattern built from multiple services working together.

This post covers how to implement Zero Trust on AWS using the services available today, with practical patterns for user-to-application access, service-to-service communication, and data protection.

Zero Trust Principles on AWS

Principle	AWS Implementation
Verify explicitly	Authenticate and authorize every request based on identity, device, location, and context
Least privilege access	IAM policies, SCPs, resource policies scoped to minimum required permissions
Assume breach	Micro-segmentation, encryption everywhere, continuous monitoring, blast radius isolation

The AWS Zero Trust Stack

┌─────────────────────────────────────────────────────────────────┐
│  USER-TO-APP ACCESS                                              │
│  AWS Verified Access | IAM Identity Center | Cognito             │
├─────────────────────────────────────────────────────────────────┤
│  SERVICE-TO-SERVICE                                              │
│  Amazon VPC Lattice | IAM Auth (SigV4) | PrivateLink            │
├─────────────────────────────────────────────────────────────────┤
│  NETWORK CONTROLS                                                │
│  Security Groups | NACLs | Network Firewall | VPC Endpoints     │
├─────────────────────────────────────────────────────────────────┤
│  DATA PROTECTION                                                 │
│  KMS Encryption | Macie | S3 Access Grants | Lake Formation     │
├─────────────────────────────────────────────────────────────────┤
│  CONTINUOUS VERIFICATION                                         │
│  GuardDuty | Security Hub | CloudTrail | IAM Access Analyzer    │
├─────────────────────────────────────────────────────────────────┤
│  GOVERNANCE                                                      │
│  SCPs | Config Rules | Resource Control Policies                 │
└─────────────────────────────────────────────────────────────────┘

---

Pillar 1: User-to-Application Access (Replace the VPN)

AWS Verified Access

Traditional pattern: User connects to VPN → gets network-level access to everything inside.

Zero Trust pattern: User requests access to a specific application → identity and device posture are verified → access granted only to that application.

AWS Verified Access implements this:

• No VPN required — users access applications directly via browser
• Per-request verification — every HTTP request is evaluated against access policies
• Identity-aware — integrates with IAM Identity Center, Okta, Azure AD, CrowdStrike, Jamf
• Device posture — check device compliance (managed device, antivirus active, OS updated)
• Application-level granularity — access to App A doesn't imply access to App B

How Verified Access Works

User (Browser)
    │
    ▼
┌──────────────────────┐
│  Verified Access      │
│  Endpoint             │
│  ┌────────────────┐  │
│  │ Trust Provider  │  │  ← Checks identity (IdP) + device (MDM)
│  │ (IdP + Device) │  │
│  └────────────────┘  │
│  ┌────────────────┐  │
│  │ Access Policy   │  │  ← Evaluates: user group + device trust + context
│  │ (Cedar)         │  │
│  └────────────────┘  │
└──────────┬───────────┘
           │ ✅ Allowed
           ▼
┌──────────────────────┐
│  Internal Application │
│  (ALB / NLB / ENI)   │
└──────────────────────┘

Access Policies with Cedar

Verified Access uses Cedar policy language for fine-grained decisions:

// Allow access only for engineering team on managed devices
permit(principal, action, resource)
when {
    context.identity.groups.contains("engineering") &&
    context.device.status == "compliant" &&
    context.identity.email.endsWith("@company.com")
};

When to Use Verified Access vs VPN

Scenario	Verified Access	VPN
Web applications (HTTP/HTTPS)	✅ Best fit	Overkill
SSH/RDP to EC2	Use SSM Session Manager instead	Legacy option
Non-HTTP protocols (database clients)	Not supported	Still needed
Third-party contractor access	✅ Scoped, auditable	Risky (broad access)
BYOD users	✅ Device posture checks	Hard to enforce

---

Pillar 2: Service-to-Service Communication

Amazon VPC Lattice

In microservices architectures, services call other services constantly. Without Zero Trust, any service in the VPC can call any other service — one compromised service exposes everything.

VPC Lattice provides identity-based, service-to-service authorization:

• Service network — logical boundary grouping related services
• Auth policies — IAM-based (SigV4) authentication between services
• Per-request authorization — every call verified against policy
• Cross-account — services in different accounts can communicate securely without VPC peering
• No networking changes — works alongside existing VPCs, no route table modifications

VPC Lattice Architecture

┌─────────────────────────────────────────────────────┐
│               Service Network                         │
│                                                       │
│  ┌─────────┐        ┌─────────┐        ┌─────────┐ │
│  │Service A │──IAM──→│Service B │──IAM──→│Service C │ │
│  │(Account1)│  Auth  │(Account2)│  Auth  │(Account3)│ │
│  └─────────┘        └─────────┘        └─────────┘ │
│                                                       │
│  Auth Policy: Service A can call Service B            │
│  Auth Policy: Service B can call Service C            │
│  Deny all other combinations                          │
└─────────────────────────────────────────────────────┘

VPC Lattice Auth Policy Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/ServiceA-Role"
      },
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "arn:aws:vpc-lattice:us-east-1:222222222222:service/svc-abc123/*",
      "Condition": {
        "StringEquals": {
          "vpc-lattice-svcs:RequestMethod": "GET"
        }
      }
    }
  ]
}

This policy: Service A (Account 1) can make GET requests to Service B (Account 2). Nothing else. No network path matters — even if networking allows it, IAM denies it.

VPC Lattice vs PrivateLink vs Service Mesh

Feature	VPC Lattice	PrivateLink	Service Mesh (e.g., App Mesh)
Auth model	IAM (native)	Network-level only	mTLS (self-managed)
Cross-account	Built-in	Complex (endpoint services)	Requires mesh federation
Protocol support	HTTP, HTTPS, gRPC, TCP	Any TCP	HTTP, gRPC
Observability	Built-in access logs	Limited	Sidecar-based (Envoy)
Complexity	Low	Medium	High
Cost model	Per request + data	Per endpoint-hour + data	Proxy instances

---

Pillar 3: Network Micro-Segmentation

Zero Trust doesn't eliminate networks — it adds identity verification ON TOP of network controls:

Defense in Depth: Layered Network Controls

Layer 1: VPC Isolation (account-per-workload)
  └── Layer 2: Subnet segmentation (public/private/isolated)
       └── Layer 3: Security Groups (instance-level, stateful)
            └── Layer 4: Network Firewall (domain filtering, IPS)
                 └── Layer 5: VPC Lattice / Verified Access (identity-based)

Key Network Zero Trust Patterns

Pattern 1: No public subnets for applications
All applications live in private subnets. Access only through Verified Access (users) or VPC Lattice (services). No direct internet exposure.

Pattern 2: VPC endpoints for AWS services
Don't route AWS API calls through the internet. Use Interface VPC Endpoints — traffic stays on AWS backbone, accessible only from your VPC.

Pattern 3: DNS-based network firewall
AWS Network Firewall with domain-based rules — allow only approved domains for egress. Block everything else by default.

Pattern 4: Eliminate broad security group rules
Replace 0.0.0.0/0 ingress with prefix lists or security group references. Every rule should have a documented justification.

---

Pillar 4: Data Protection

Zero Trust for data means: even if someone has network access and authenticated identity, they only see data they're explicitly authorized for.

Service	Zero Trust Capability
KMS	Encryption keys with key policies — even admins can't decrypt without explicit grant
S3 Access Grants	Map identities (from Identity Center) to specific S3 prefixes — fine-grained data access
Lake Formation	Column-level and row-level access control for analytics data
Macie	Continuously discover and alert on sensitive data in S3
RDS IAM Auth	Database access via IAM tokens instead of passwords
Secrets Manager	Rotate credentials automatically — no long-lived database passwords

S3 Access Grants: Identity-Based Data Access

Instead of broad S3 bucket policies:

User/Role → Identity Center Group → Access Grant → S3 Prefix

Marketing team → can read s3://data-lake/marketing/*
Engineering team → can read/write s3://data-lake/engineering/*
Finance team → can read s3://data-lake/finance/* (with Macie monitoring)

No bucket policies to manage. Identity drives data access.

---

Pillar 5: Continuous Verification and Monitoring

Zero Trust isn't set-and-forget. Continuous verification detects drift and threats:

Service	What It Monitors
GuardDuty	Threat detection — compromised credentials, crypto mining, C&C communication
IAM Access Analyzer	External access — finds resources shared outside your organization
Security Hub	Compliance — CIS benchmarks, AWS Foundational Security Best Practices
CloudTrail	Audit — every API call, who did what, when, from where
Config	Drift — detects when resources deviate from compliant state
Detective	Investigation — visualize and investigate security findings
VPC Flow Logs	Network — all traffic flows for forensic analysis

Automated Response Pattern

GuardDuty Finding (e.g., compromised credentials)
    │
    ▼
EventBridge Rule
    │
    ▼
Lambda: Auto-remediate
    ├── Revoke active sessions
    ├── Attach deny-all SCP to affected account
    ├── Isolate EC2 (restrict security group)
    └── Create ITSM incident

---

Implementation Roadmap

Phase 1: Foundation (Weeks 1-4)

• Enable CloudTrail, GuardDuty, Security Hub across all accounts
• Implement mandatory tagging and Config rules
• Audit existing security group rules — remove 0.0.0.0/0
• Enable VPC endpoints for S3, DynamoDB, and frequently-used AWS APIs

Phase 2: Identity-Centric Access (Weeks 5-8)

• Deploy Verified Access for top 3 internal web applications
• Migrate users off VPN for those applications
• Implement IAM Identity Center with MFA and device trust
• Enable RDS IAM authentication (eliminate static database passwords)

Phase 3: Service-to-Service (Weeks 9-12)

• Deploy VPC Lattice for critical service-to-service paths
• Implement IAM auth policies (SigV4 signing)
• Remove overly broad security group rules between services
• Enable VPC Lattice access logs for audit

Phase 4: Data and Continuous (Ongoing)

• Enable S3 Access Grants for data lake
• Deploy Macie for sensitive data discovery
• Implement automated remediation (GuardDuty → Lambda)
• Regular access reviews with IAM Access Analyzer

---

Common Objections (and Answers)

Objection	Answer
"We already have a VPN"	VPN gives network access. Zero Trust gives application access. Breach one VPN credential = access everything.
"It's too complex to implement"	Phase it. Start with Verified Access for one app. Don't boil the ocean.
"Performance overhead?"	Verified Access adds <10ms latency. VPC Lattice is in-line networking (negligible).
"We trust our internal services"	Assume breach. One compromised container shouldn't access your payment service.
"Compliance requires VPN"	Most compliance frameworks (SOC2, ISO27001) now accept Zero Trust as equivalent or superior to VPN.

---

Summary

Zero Trust on AWS is built from five pillars:

1. User-to-app: Verified Access — replace VPN with per-request identity + device verification
2. Service-to-service: VPC Lattice — IAM-based authentication between services, even cross-account
3. Network: Micro-segmentation — security groups + Network Firewall + no public exposure
4. Data: Identity-driven access — KMS, S3 Access Grants, Lake Formation, RDS IAM auth
5. Continuous: Monitor and respond — GuardDuty, Security Hub, automated remediation

The key shift: network location is no longer a trust signal. Identity is. Every request proves who it is, every service proves it's allowed, and every data access is scoped to exactly what's needed.

---

Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS security architecture and cloud infrastructure automation. Connect on LinkedIn.