Identity, not IP — stops lateral movement
Zero-trust VPC on AWS — VPC Lattice, Verified Access, and IAM-everywhere
Identity-aware service mesh on VPC Lattice, IAM-everywhere via Roles Anywhere, AWS Verified Access at $5–10/user/month replacing $5K+/mo VPN appliances, and not a single security group rule that grants by IP range.
Last updated: May 1, 2026 Author: FactualMinds AWS Architects Reviewed by: Palaniappan P · AWS Solutions Architect — Professional
Problem
Most AWS networks accumulate a graveyard of VPC peering links, security groups that grant 0.0.0.0/0 to internal CIDRs, and IAM policies that trust 'whatever's in the VPC'. A breach inside any account or subnet escalates laterally because the network was the trust boundary. Adding a new service requires another peering link, another set of security groups, and another decade of audit explanations.
Solution
Replace IP-based trust with identity. VPC Lattice (with ECS/Fargate support added July 2025) puts an IAM-aware proxy in front of every service-to-service call; IAM Roles Anywhere brings AWS IAM identities to non-AWS workloads; AWS Verified Access replaces VPN with device-and-identity-aware access for humans; AWS Verified Permissions (Cedar) handles fine-grained authz; PrivateLink consumes third-party SaaS without ever opening an internet route. The network becomes a conduit, not a trust boundary.
AWS services in this pattern
| Service | Role |
|---|---|
| Amazon VPC Lattice | IAM-aware service mesh — every service-to-service call is authenticated and authorized via IAM policy, regardless of which VPC or account the caller lives in; ECS/Fargate origins supported as of July 2025 |
| AWS IAM Roles Anywhere | Brings AWS IAM identities to workloads outside AWS — on-prem servers, other clouds, build agents — using X.509 certificates from your existing PKI; eliminates long-lived AWS access keys |
| AWS PrivateLink | Consume third-party SaaS over private VPC endpoints — no NAT gateway, no internet route; the SaaS vendor's service appears as a private DNS name in your VPC |
| AWS Verified Access | Identity-and-device-aware access to internal applications — replaces traditional VPN for human users; integrates with your IdP and a device-trust signal source |
| AWS Verified Permissions | Cedar-based fine-grained authorization service — externalize per-resource permission decisions from application code; the policy plane that complements Lattice's coarse IAM auth |
| AWS WAF (v2) | Layer-7 application protection at the edge — replaces WAF Classic, which was retired September 2025; rate limiting, geo-match, and managed rule groups for the OWASP top ten |
| AWS Network Firewall | Stateful Layer-3/4 inspection at the VPC boundary — egress filtering, intrusion prevention, domain-name allow-listing for outbound traffic |
| Amazon GuardDuty | Continuous threat detection across VPC flow logs, DNS logs, CloudTrail, and S3 access logs — the always-on signal source feeding Security Hub |
| AWS Security Hub | Central findings aggregator — Lattice access denials, GuardDuty alerts, Config rule violations, and third-party-tool findings flow into a single posture view |
| AWS Resource Access Manager (RAM) | Cross-account resource sharing without VPC peering — share Lattice service networks, Transit Gateway attachments, and subnets across the AWS Organization |
Architecture components
Service mesh layer
VPC Lattice service network spans accounts and VPCs in the AWS Organization; every service registers with the network; every call is authenticated by IAM policy attached to the service. Cross-account, cross-region calls have the same trust contract as in-VPC ones.
Human access layer
AWS Verified Access in front of every internal application; IdP carries the identity; a device-trust provider (Jamf, Intune, CrowdStrike Zero Trust, etc.) carries the posture; no VPN client to maintain.
Workload identity layer
Workloads inside AWS get IAM via task roles, instance profiles, IRSA, or pod identity. Workloads outside AWS get IAM via Roles Anywhere with certificates from your PKI. There are no long-lived access keys anywhere in the architecture.
Authorization layer
Coarse IAM authorization at Lattice; fine-grained per-resource decisions in Verified Permissions (Cedar); application code calls IsAuthorized rather than embedding permission logic. The authorization story is auditable and uniform across services.
Egress control
Network Firewall at the VPC egress with a domain-name allow-list; centralized inspection VPC pattern via Transit Gateway when multi-account; logs to S3 + Security Hub. Outbound traffic is treated with the same scrutiny as inbound.
Edge layer
AWS WAF (v2) on every public-facing CloudFront distribution and ALB — managed rule groups, rate-based rules, and geo-match. WAF Classic is gone; new deployments must use WAF v2.
Why this pattern
Network-as-trust-boundary is the architectural mistake that costs the most on every breach we review. A flat VPC with friendly security groups and a peering mesh between accounts means a single credential leak or a single compromised pod inside any subnet escalates laterally with almost no resistance. The network was the security control; once the attacker was inside, the network had no more answers.
Zero-trust on AWS replaces that boundary with identity. Every service-to-service call is authenticated by IAM. Every human session is identity-and-device-aware. Every workload — inside or outside AWS — has a short-lived signed credential, not a long-lived access key. The network becomes a conduit. The result is dramatically better lateral-movement defense and an audit story that is fundamentally simpler — a single authorization plane instead of seven overlapping ones.
Choosing your zero-trust posture
| Capability | Today | Zero-trust replacement |
|---|---|---|
| Service-to-service auth | Security groups | VPC Lattice with IAM auth policies |
| Cross-account connectivity | VPC peering | Lattice service network shared via RAM |
| Human remote access | VPN concentrator | AWS Verified Access (identity + device) |
| Non-AWS workload AWS access | Long-lived AK/SK | IAM Roles Anywhere |
| Third-party SaaS consumption | Internet + NAT GW | PrivateLink |
| Per-resource authorization in app code | Embedded if/else | AWS Verified Permissions (Cedar) |
| Edge protection | WAF Classic | AWS WAF (v2) — Classic was retired Sep 2025 |
| Egress filtering | Allow-everything | Network Firewall with domain allow-list |
What the rollout looks like
Trying to flip the whole estate to zero-trust in a single program almost always stalls. The pattern we deploy is incremental:
- Pick a bounded context — one product line or one team’s services.
- Port that context to VPC Lattice in parallel with the existing security groups; Lattice IAM auth becomes the primary control, security groups remain as defense-in-depth.
- Roll Verified Access out for that team’s internal tools so they get the human-side experience first.
- Retire the long-lived access keys for that team’s CI and external workloads via Roles Anywhere.
- Expand to the next bounded context — usually about a quarter per context once the playbook is in place.
The teams that succeed treat zero-trust as a multi-quarter program with a per-context milestone, not a single-quarter mandate. The teams that try to do it as a single mandate ship a brittle half-migration and live with both architectures forever.
Where this pattern shows up in our consulting
We deploy zero-trust architectures most often in AWS Cloud Security engagements at customers under audit pressure or post-incident, and in Managed SOC / MDR onboarding where the security operations team needs a defensible monitoring contract. For healthcare specifically, this pattern composes with the HIPAA on AWS for healthtech pattern — the zero-trust controls are exactly the controls a HIPAA auditor wants to see.
Trade-offs
Pro
Lateral movement requires IAM authorization on every cross-service call — a credential leak in one service cannot pivot to another, regardless of network position.
Con
VPC Lattice is a learning curve for teams who have spent years on security-group thinking. Plan a one-quarter rollout — pick one bounded context, port it to Lattice, run it in production, then expand. Trying to convert the whole estate in a single program almost always stalls.
Pro
Verified Access removes the operational tax of running and patching VPN concentrators — and adds device-trust, which most VPN setups never managed properly. User experience also improves; Verified Access integrates with the browser via a lightweight client.
Con
Not every internal application is HTTP-friendly out of the box. Verified Access supports HTTPS and a growing set of TCP applications, but legacy thick-client tools may need a bastion or RDP gateway to bridge.
Pro
Roles Anywhere ends the long-lived-AWS-access-key era for non-AWS workloads — the single biggest source of credential-theft incidents on AWS. CI agents, on-prem batch jobs, and build infrastructure all authenticate with short-lived signed credentials.
Con
Roles Anywhere requires a PKI you control or trust — typically AWS Private CA or an existing enterprise PKI. Teams without an existing PKI have a multi-week setup before they can adopt the pattern; the time investment pays for itself in audit posture but is not zero.
Cost notes
VPC Lattice is priced per request and per service-network attachment — typical mid-size estate at 100M requests/month and 30 services lands around $300–700/month in Lattice spend. Verified Access is per-user per-month plus a small data-transfer surcharge — typically $5–10/user/month, dramatically cheaper than the VPN appliance + maintenance line it replaces. Roles Anywhere has no per-call cost; PrivateLink endpoints are around $7/month per AZ plus standard data-transfer. The ROI is overwhelmingly on the incident-response and audit lines, not the AWS bill — a credential-leak incident or an audit re-do costs an order of magnitude more than the entire pattern.
Related patterns
HIPAA on AWS for healthtech — The Smallest Defensible Footprint
BAA-eligible reference architecture for a Series A healthtech on AWS — Cognito, ALB, Fargate, Aurora encrypted with KMS CMKs, S3 with object-level encryption, CloudTrail Lake, AWS Config HIPAA conformance pack, GuardDuty, Macie, Audit Manager, and Bedrock for HIPAA-eligible AI features.
Multi-Tenant SaaS on AWS — Pool, Silo, and Bridge
Production-ready multi-tenant architecture for SaaS on AWS. Covers tenant isolation models (pool, silo, bridge), per-tenant cost attribution, noisy-neighbor mitigation, and the trade-offs CTOs actually wrestle with at Series B and beyond.
Consulting engagements that deliver this pattern
AWS Security Consulting
AWS security consulting from an AWS Select Tier Partner. 2-week assessment, 4–6 week remediation, zero disruption. IAM hardening, public exposure, compliance gaps, and continuous monitoring.
AWS Managed SOC & MDR Services
24/7 managed SOC and MDR for AWS — GuardDuty, Security Hub, Security Lake. Threat hunting, automated containment, incident response from an AWS Select Tier Partner.
AWS Well-Architected Review — Free Assessment
Free AWS Well-Architected Review from FactualMinds. Identify risks, compliance gaps, and optimization opportunities.
Deep dives
AWS VPC Networking Best Practices for Production
A VPC misdesign at month two becomes a multi-quarter migration at year two. CIDR planning, subnet strategies, NAT gateways, VPC endpoints, Transit Gateway, and the network architecture patterns that scale without forcing a re-IP.
AWS Verified Access in Production: A Zero-Trust Network Access (ZTNA) Replacement for Legacy VPN
AWS Verified Access is the AWS-native Zero-Trust Network Access service for workforce app access. This guide covers deploying Verified Access endpoints, configuring trust providers (IAM Identity Center, OIDC, device-posture from Jamf / CrowdStrike / Jumpcloud), writing Cedar policies, and migrating workforce traffic off Client VPN.
How to Set Up AWS Security Hub for Compliance Monitoring
AWS Security Hub aggregates security findings from 200+ sources (GuardDuty, Config, IAM Access Analyzer, Inspector). This guide covers setup, compliance standards (PCI-DSS, CIS, NIST), automated remediation, and building a compliance dashboard without hiring a SOC team.
Frequently asked questions
Do we still need VPCs and security groups under zero-trust?
Yes, but as defense-in-depth rather than as the primary trust boundary. VPC isolation and security groups still defend against the broken-machine case (a compromised workload trying to scan the network); IAM-based authorization on Lattice defends against the credential-theft case. Removing security groups in a zero-trust architecture is the wrong move; demoting them from primary control to defense-in-depth is the right one.
How does VPC Lattice compare to a traditional service mesh like Istio or App Mesh?
VPC Lattice is AWS-native, uses IAM as the auth model, and works across accounts and VPCs in the Organization out of the box. Istio gives you more control over traffic routing, observability, and policy expressiveness — at the cost of running and patching the control plane yourself. AWS App Mesh is end-of-life as a separately marketed product; new AWS-native deployments should default to Lattice. For Kubernetes-heavy estates that already run Istio, the right answer is often to keep Istio inside clusters and use Lattice between clusters and to non-EKS workloads.
What replaces AWS WAF Classic?
AWS WAF v2 — usually just called 'AWS WAF' now. WAF Classic was retired September 30, 2025; if any part of your estate still references the legacy resource type, it has already lost protection. Migration is straightforward but not automatic — managed rule groups, rate-based rules, and the rule structure all changed. Run the WAF v2 managed rule groups for the OWASP top ten as a baseline.
How do we handle legacy applications that cannot run behind Verified Access?
Most can be wrapped — put a small reverse-proxy in front (CloudFront + ALB or a Fargate sidecar) and let Verified Access handle the identity contract. Truly legacy thick-client TCP applications usually justify a bastion or RDP gateway behind Verified Access for the human session. The pattern we deploy most often is 'Verified Access for 95% of internal apps, bastion for the long tail of legacy tools.'
How does Verified Permissions interact with our existing authz code?
Verified Permissions externalizes the per-resource permission decision — your application code calls IsAuthorized with the principal, action, resource, and context, and gets back a permit or deny based on Cedar policy. The win is that policy lives outside application code, can be reviewed by security as a single artifact, and changes without a deploy. Migration is incremental: pick one resource type (typically a high-value one like documents or accounts), port the authorization decisions, then expand.
Is this pattern HIPAA / PCI / SOC 2 friendly?
All the components in this pattern are HIPAA-eligible and serve as load-bearing controls for SOC 2 and PCI-DSS. The zero-trust architecture is dramatically easier to audit than the IP-based design it replaces — every cross-service call is authenticated by IAM, every human session is identity-and-device-aware, every long-lived access key has been retired. The HIPAA on AWS for healthtech pattern walks the specific control map for healthcare; the same primitives apply to PCI and SOC 2.
Want this pattern deployed end-to-end?
Our team builds these patterns in production for SaaS, healthcare, fintech, and enterprise customers. Tell us your constraints and we'll scope the engagement.