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:
User-to-app: Verified Access — replace VPN with per-request identity + device verification
Service-to-service: VPC Lattice — IAM-based authentication between services, even cross-account
Network: Micro-segmentation — security groups + Network Firewall + no public exposure
Data: Identity-driven access — KMS, S3 Access Grants, Lake Formation, RDS IAM auth
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.
SOCIAL SHARE CARD GENERATOR