VPC peering is a private network connection between two virtual private clouds that allows traffic to move between them without traversing the public internet. It is commonly used to connect separate projects or environments, but it still depends on correct routing, firewall rules, and host or cluster policy settings.
Expanded Definition
VPC peering is a private connectivity pattern used to route traffic between two virtual private clouds while keeping the traffic off the public internet. It is most useful when teams need controlled east-west communication between separate application environments, business units, or cloud projects. Unlike a broader transit or hub-and-spoke design, peering creates a direct relationship between two specific networks, so route tables, security groups, network ACLs, and workload policies still decide what is actually reachable.
For security teams, the distinction matters because peering is a network path, not an access decision by itself. It does not automatically create trust between workloads, and it does not replace identity-based authorization, segmentation, or application-layer controls. The operational question is not simply whether two VPCs can connect, but whether each allowed route is intentionally scoped and monitored. The most common misapplication is treating peering as implicit trust, which occurs when teams expose more subnets or ports than the original use case requires.
Examples and Use Cases
Implementing VPC peering rigorously often introduces routing complexity, requiring organisations to balance low-latency private communication against the cost of managing overlapping policies and hidden trust paths.
- Two production VPCs host related services in separate accounts, and peering is used to allow only specific application ports while keeping administrative access isolated.
- A shared logging or security analytics environment needs private access to application subnets, but only from narrowly defined source ranges and service endpoints.
- Development and test VPCs are peered temporarily for integration testing, then the routes are removed once the test window closes.
- A data-processing workload in one VPC must call an internal API in another VPC, with firewall rules limiting traffic to one workload identity and one port.
- Hybrid architecture teams compare peering with hub routing and find that direct peering is suitable only when the communication pattern is simple and stable.
When peering is being evaluated against broader governance expectations, NIST Cybersecurity Framework 2.0 is useful for mapping the network change to access control, monitoring, and risk management outcomes.
Why It Matters for Security Teams
VPC peering matters because it can reduce exposure to the public internet while still expanding the reachable attack surface inside the cloud estate. If route propagation, security group rules, or cluster network policy are too permissive, a single peered path can become an unplanned bridge between sensitive environments. That creates operational risk for segmentation, incident containment, and change control, especially when multiple teams manage different VPCs independently.
The identity angle is often overlooked. Peering may make service-to-service communication possible, but it does not answer who or what is allowed to use that path. For NHI-heavy environments, such as workloads authenticated by secrets, certificates, or cloud-native service identities, the network link must be paired with workload identity controls and secret hygiene. Security teams also need to remember that peering is usually bilateral and static, which means it can persist long after the business need has ended unless governance is explicit. Organisations typically encounter the consequences only after an unexpected lateral movement path or data exposure is discovered, at which point VPC peering becomes operationally unavoidable to review and dismantle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions and network segmentation govern what peered VPCs can reach. |
Apply least-privilege routing and validate that each peered path is explicitly justified.
Related resources from NHI Mgmt Group
- What do teams get wrong about securing Kafka with VPC peering?
- Why do regulated AI workloads often require VPC isolation instead of direct use of public model APIs?
- What is the difference between public multi-tenant AI gateways and private VPC-deployed gateways?
- How should security teams ingest AWS VPC Flow Logs without overwhelming the SIEM or breaking the budget?
