Red Team perspective on AWS VPC Lattice

Exploring AWS VPC Lattice and how attackers could abuse it for stealth, movement, and hidden access paths.

Cloud services evolve at a rapid pace, and with every new feature comes new opportunities—both for defenders to build resilient architectures and for attackers to misuse them in creative ways. One of the more recent additions to AWS networking is VPC Lattice, a fully managed application networking service designed to simplify communication between services across multiple VPCs. While it was created for legitimate use cases like microservices, hybrid applications, and service-to-service communication, it also introduces a new dimension for red teamers to explore: stealthy, internal-only infrastructure communication that avoids traditional detection paths.

What is AWS VPC Lattice?

Traditionally, connecting workloads across multiple VPCs requires peering connections, Transit Gateways, or complex networking setups. AWS VPC Lattice simplifies this by providing an application-level networking layer. Instead of managing IPs and routing tables, developers can connect services to a Lattice service network and allow communication through service names.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

In simpler words, it creates a service mesh-like system within AWS that abstracts away the networking headaches. Services inside VPCs can communicate securely and consistently without needing public exposure or manual routing.

Key benefits of VPC Lattice include:

• Service-to-service communication without exposing public endpoints.

• Consistent authentication and authorization using IAM and policies.

• Cross-VPC and cross-account connectivity without the need for complex peering setups.

• Managed observability with built-in logging and monitoring.

Visualization of VPC Lattice

Imagine three different applications running in different VPCs—App A in VPC1, App B in VPC2, and App C in VPC3. Normally, connecting them requires networking workarounds. With VPC Lattice, they can all join a service network and communicate through it as if they were part of the same logical group.

   +-------------------+
   |  VPC Lattice      |
   |  Service Network  |
   +-------------------+
      /        |       \
   App A      App B    App C
  (VPC 1)   (VPC 2)   (VPC 3)

Each application only needs to register with Lattice and can then send requests to others through a managed and secure channel. No public IPs, no internet gateways, no external exposure.

Why is this Important for Red Teams?

From a defensive perspective, VPC Lattice is great—it reduces attack surface by removing the need for public endpoints and simplifies networking. However, from a red team perspective, these same features open up stealth opportunities once access to a target environment has been gained.

If an organization already uses VPC Lattice to connect microservices, a compromised workload may inherit trusted access across multiple VPCs. This creates possibilities such as:

• Lateral movement across VPCs by abusing existing service-to-service communication.

• Blending in with legitimate traffic, since Lattice requests look like normal microservice activity.

• Bypassing traditional boundaries, avoiding internet gateways, load balancers, or public endpoints entirely.

The critical point here is that VPC Lattice hides complexity and exposure for defenders, but at the same time, it hides malicious activity for attackers.

TL;DR
- AWS VPC Lattice simplifies service-to-service communication across VPCs.
- It removes public exposure by routing traffic inside AWS’ private network.
- Attackers can abuse existing Lattice setups for stealth and lateral movement.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.