How do you implement zero-trust networking in AWS?

Zero-trust networking replaces the traditional castle-and-moat model with a 'never trust, always verify' approach. Think of the old model like an office building: once you badge in at the front door, you can walk into any room. Zero-trust is like a hospital where every room has its own lock, every person wears an ID badge that's checked at every door, and the security system logs every entry.

The foundation starts with identity. Every workload, service, and user must have a cryptographically verifiable identity. In AWS, this means IAM roles for compute resources (never long-lived access keys), OIDC federation for external services, and IAM Identity Center (successor to AWS SSO) for human access. Critical production accounts should enforce hardware MFA tokens, not virtual MFA.

Network microsegmentation is the next layer. Traditional VPC security uses NACLs and security groups at the subnet and instance level. Zero-trust goes further: security groups should reference other security groups instead of CIDR blocks. For example, your payments-api security group allows inbound on port 8443 only from the checkout-service security group. This means if an attacker compromises a machine in the same subnet, they cannot reach the payments API because their security group is not authorized. VPC Lattice, launched as a service mesh alternative, handles service-to-service authentication and authorization at the network layer without sidecars.

Encryption in transit is non-negotiable. Deploy ACM Private CA to issue short-lived certificates (24-hour validity) to every service. Mutual TLS (mTLS) ensures both client and server verify each other's identity. AWS App Mesh or Envoy sidecars terminate and originate mTLS connections, so application code does not need to handle certificate management. For east-west traffic between VPCs, use PrivateLink endpoints instead of VPC peering because PrivateLink restricts access to specific services rather than exposing entire VPC CIDR ranges.

AWS Verified Access replaces traditional VPNs for application access. Instead of granting network-level access to a VPC (where a compromised laptop can scan the entire network), Verified Access evaluates trust policies based on user identity (from IAM Identity Center or third-party IdP), device posture (from CrowdStrike, Jamf, or AWS device trust), and application-specific conditions. Each application gets its own Verified Access endpoint, so compromising access to one application does not grant access to others.

Continuous monitoring completes the zero-trust model. VPC Flow Logs feed into a SIEM (Security Lake or third-party) for anomaly detection. GuardDuty monitors for credential exfiltration, cryptocurrency mining, and unusual API patterns. CloudTrail logs every API call across all accounts. AWS Config rules verify that security groups do not have 0.0.0.0/0 ingress rules and that all ALBs enforce HTTPS.

Production gotchas: mTLS certificate rotation must be automated; manual rotation causes outages. VPC Lattice has a 500 services-per-service-network limit that bites at scale. Security group rules referencing other security groups do not work across VPC peering connections in different regions; use PrivateLink instead. Verified Access adds 5-15ms latency per request, which matters for latency-sensitive APIs. Always deploy in 'monitor only' mode first to identify legitimate traffic patterns before enforcing deny rules.