Zero Trust with VPC Lattice Auth Policy and SigV4

Yes, VPC Lattice's IAM Auth Policy + SigV4 authentication enables service identity-based Zero Trust networking, and it can operate complementarily alongside existing Security Groups.

How It Differs from the Traditional Approach

• Traditional (L3/L4): Security Groups, NACLs → IP/Port-based allow rules
• VPC Lattice (L7): Auth Policy → Fine-grained authorization based on service IAM Role, HTTP Method, Path, Organization ID, etc.

In other words, Security Groups control "which IPs can access," while VPC Lattice Auth Policy controls "which service can access which API path using which HTTP method."

Configuration Steps

1. Enable IAM authentication on the VPC Lattice Service: Set authType to AWS_IAM.

2. Define fine-grained authorization rules with Auth Policy. For example, to allow only a service with the order-service Role to make GET requests to the /api/stock path on inventory-service:

• Action: vpc-lattice-svcs:Invoke
• Principal: arn:aws:iam::123456789012:role/order-service-role
• Conditions such as vpc-lattice-svcs:RequestMethod = GET, aws:PrincipalOrgID = o-myorgid, etc.

3. Apply SigV4 signing on the client service. Use Python boto3's SigV4Auth to add a signature to requests. The service name is vpc-lattice-svcs.

Coexistence Strategy with Existing Security Groups

• Keep Security Groups as-is. They serve as the baseline L3/L4 defense layer, blocking unnecessary ports/IPs.
• VPC Lattice adds an L7 layer on top, so there's no need to modify existing configurations.
• A gradual transition is recommended. First deploy VPC Lattice with authType: NONE, analyze Access Logs to understand actual call patterns, then switch Auth Policy to Allow mode.

Monitoring

By checking the authenticationType, principalArn, and sourceIdentity fields in VPC Lattice Access Logs, you get a complete audit trail of which service called which. Set up CloudWatch Alarms for spikes in authentication failures (403) to detect misconfigurations or attack attempts.