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                 │
└─────────────────────────────────────────────────────────────────┘

Enter fullscreen mode Exit fullscreen mode

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)   │
└──────────────────────┘

Enter fullscreen mode Exit fullscreen mode

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")
};

Enter fullscreen mode Exit fullscreen mode

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                          │
└─────────────────────────────────────────────────────┘

Enter fullscreen mode Exit fullscreen mode

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"
        }
      }
    }
  ]
}

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.