Docs
IaaS
Networking
VPC Peering

VPC Peering in Thalassa Cloud

VPC Peering enables you to connect two Virtual Private Clouds (VPCs) together, allowing resources in different VPCs to communicate with each other as if they were in the same network. VPC peering connections can be established between VPCs within the same organisation or across different organisations, providing flexible networking options for multi-VPC architectures.

VPC Peering Capabilities

CapabilityDescription
Cross-Organisation PeeringConnect VPCs owned by different organisations, enabling secure inter-organisational networking
Intra-Organisation PeeringConnect VPCs within the same organisation for network segmentation and isolation
Manual AcceptanceControl peering requests through manual acceptance or automatic acceptance (same org/region only)
Route Table IntegrationConfigure route tables to direct traffic through peering connections
Status TrackingMonitor peering connection status (pending, active, rejected, expired)
Automatic ExpiryPeering requests automatically expire if not accepted within a specified timeframe

VPC Peering Architecture

Requester and Accepter

A VPC peering connection involves two parties:

  • Requester VPC: The VPC that initiates the peering request. This is your VPC when you want to connect to another VPC.
  • Accepter VPC: The VPC that receives and must accept the peering request. This can be a VPC in your organisation or another organisation.

When peering across organisations, you’ll need to know the target organisation’s ID to create the peering connection. The accepter organisation will then need to approve the connection in their console.

Connection Lifecycle

A VPC peering connection goes through several states:

  1. Pending: The peering request has been created but not yet accepted
  2. Active: The peering connection has been accepted and is operational
  3. Rejected: The peering request has been rejected by the accepter
  4. Expired: The peering request expired before being accepted

Auto-Accept

For VPCs within the same organisation and same region, peering connections can be automatically accepted. This means the connection becomes active immediately without waiting for manual approval. For cross-organisation peering or VPCs in different regions, manual acceptance is always required for security and control.

Route Configuration

After a peering connection is accepted and becomes active, traffic won’t flow automatically. You must configure route tables in both VPCs to enable communication:

  • In the requester VPC: Add a route that sends traffic destined for the accepter VPC’s IP address range through the peering connection
  • In the accepter VPC: Add a route that sends traffic destined for the requester VPC’s IP address range through the peering connection

Both sides need routes configured for bidirectional communication to work. Routes can only be added after the peering connection is in an active state.

Creating Peering Connections

When creating a peering connection, you’ll need to provide:

  • A name for the peering connection
  • Your VPC (the requester VPC)
  • The target VPC (the accepter VPC)
  • For cross-organisation peering: The target organisation’s ID

You can optionally provide a description to document the purpose of the peering connection. Peering requests have a timeout period and will expire if not accepted, so coordinate with the accepter organisation if needed.

Peering Across Organisations

Peering VPCs across different organisations enables secure collaboration while maintaining clear ownership boundaries. The process works as follows:

  1. Request Creation: Your organisation creates a peering request and specifies the target organisation
  2. Pending Status: The peering connection appears in a pending state until accepted
  3. Acceptance: The target organisation reviews and accepts the request in their console
  4. Active Connection: Once accepted, the connection becomes active
  5. Route Configuration: Both organisations configure their route tables to enable traffic flow

Important Considerations

CIDR Block Requirements

VPCs that you want to peer must have non-overlapping CIDR blocks. If two VPCs use the same IP address ranges, routing conflicts will prevent proper communication. Plan your IP address space carefully before setting up peering connections.

Security Considerations

There is no built-in firewalling on a VPC peering connection—traffic between peered VPCs is not filtered by default. You must use security groups to explicitly control and restrict traffic flowing between resources in peered VPCs. Always:

  • Configure security groups to only allow traffic that is necessary between VPCs
  • Apply the principle of least privilege to minimize the attack surface
  • Regularly review and audit your security group configurations and active peering connections

Failure to properly configure security groups may expose your resources to unwanted traffic from peered networks.

Network Performance

VPC peering provides private connectivity between VPCs. Traffic flows through Thalassa Cloud’s internal network, providing low latency and high bandwidth. Keep in mind that traffic still travels through network hops, so latency-sensitive applications should consider this when designing their architecture.

Related Documentation