Skip to content

Private networking

Introduction

Private networking enables secure, direct connectivity between your customer's on-premises infrastructure or cloud networks and their deployed services in the cloud provider's account. This approach solves a critical challenge in cloud deployments: providing customers with secure access to their services without exposing them to the public internet.

The Problem

When deploying services in a cloud provider account, enterprise customers often need to:

  • Connect their existing infrastructure to deployed services securely
  • Avoid routing sensitive traffic over the public internet
  • Maintain network isolation and security boundaries
  • Comply with regulatory requirements that mandate private connectivity

The Solution

Private networking addresses these challenges by establishing secure, private connections between networks. This is achieved through various mechanisms:

  • VPC Peering: Direct network connections between Virtual Private Clouds (VPCs) in the same or different cloud accounts
  • AWS PrivateLink: Provides private connectivity between VPCs and AWS services, enabling secure access without exposing traffic to the public internet.
  • Direct Connection: Dedicated, high-bandwidth private connections between customer networks and cloud provider infrastructure, bypassing the public internet for enhanced security and performance.

These private networking options ensure that:

  • Traffic remains within private network boundaries
  • Network latency is minimized through direct routing
  • Security is enhanced by avoiding public internet exposure
  • Compliance requirements are met for data transmission

VPC peering

VPC peering allows you to connect two networks in different accounts or regions. This can be useful when you want to allow connectivity to resources from another account, without exposing them to public internet.

It can be established from a network in the customer account to a network where customer resources are located. Because of that, this feature is limited only to BYOC Deployment Model, or Service Provider Deployment Model with "Customer Networks" feature enabled. In both those cases, each network is dedicated to a single customer.

The VPC peering process can only be initiated by the customer, and the owner of the cloud network needs to accept the peering request. In the case of the Service Provider Deployment Model, that owner is the Service Provider. VPC peering for BYOC can be done solely by the customer.

Warning

VPC peering is currently not supported for Azure cloud provider. If you required this feature pls reach out to [email protected].

Warning

In order to make peering possible, CIDR blocks of source and target networks cannot overlap. This needs to be considered by the customer as they are the ones owning the source network and can also define the target network (which can either be imported existing network, created as a custom network with CIDR specified, or created as a default network by Omnistrate with default CIDR for a hosting cloud provider region).

Step by Step instruction to configure VPC peering

The following sections present the step-by-step guide to setting up VPC peering for AWS and GCP:

AWS

  1. Customer locates the network and collects details
    1. On SaaS UI, navigate to "Tenant Management" -> "Customer Networks".
    2. Locate the custom network you plan to peer. If it's not present, then such a network doesn't support VPC peering.
    3. Note the following values:
      1. Native ID - VPC ID of the network.
      2. CIDR - CIDR range of the network (customer picked this value, but it can help with configuration).
      3. AWS Account ID - AWS account ID that hosts the network (this will be one of your accounts).
      4. AWS Region - AWS region of the network.
    4. Share these values with your customer.
  2. Customer uses the provided details to create a peering request. This can be done from within the AWS Console, CLI, or API. The next steps present an example of how to configure it using AWS Console:
    1. In the AWS console navigate to: VPC -> Peering connections -> Create peering connection.
    2. Select source VPC from the current account "VPC ID (Requester)".
    3. Use AWS Account ID as a value for the "Another account" field.
    4. Use AWS Region as a value for the "Another region" field (can be skipped if the region is matching).
    5. Use Native ID as a value for the "VPC ID (Accepter)" field.
    6. Configure the route table to route traffic to peered VPC. Configuration depends on CIDR of the target network (Accepter). For details, please see AWS documentation.
    7. Make sure "ACLs" on your VPC will not block outbound traffic.
  3. Owner accepts a peering request (Service Provider or Customer, based on the Deployment Model)
    1. In AWS console navigate to: VPC -> Peering connections.
    2. Locate peering request.
    3. Accept it.
    4. Configure the VPC security group to allow traffic from peered VPC. For details, please see AWS documentation.

GCP

  1. Customer locates the network and collects details
    1. On SaaS UI, navigate to "Tenant Management" -> "Customer Networks".
    2. Locate the custom network you plan to peer. If it's not present, then such a network doesn't support VPC peering.
    3. Note the following values:
      1. Native ID - GPC network identifier
      2. CIDR - CIDR range of the network (customer picked this value, but it can help with configuration)
      3. GCP Project ID - GCP project ID that hosts the network (this will be one of your projects)
    4. Share these values with your customer
  2. Customer uses the provided details to create a peering request. This can be done from within the GCP UI, CLI, or API. The next steps present an example of how to configure it using GCP UI:
    1. On the GCP console navigate to: VPC Network -> VPC network details (of the network that will be peered) -> VPC network peering -> Add peering.
    2. Pick a name for the peering connection that will help you identify it.
    3. Select "In another project" and use GCP Project ID as a value for the "Project" field.
    4. Use Native ID as a value for the "VPC network name" field.
    5. Select "Import custom routes" and "Export custom routes".
  3. Owner accepts a peering request (Service Provider or Customer, based on the Deployment Model)
    1. On the GCP console navigate to: VPC Network -> VPC network details (of the Native ID network).
    2. You should see the peering request.
    3. Accept it.
    4. Create firewall rules to allow traffic from the peered network. For details, please see GCP documentation.

Retrieve Network Information for VPC Peering from a Deployment Instance

  1. Install the Omnistrate CTL from the here
  2. Identify the deployment cell associated with the deployment instance.
omnistrate-ctl instance describe <instance-id> -o json | jq '.DeploymentCellID'
  1. Obtain network details for the deployment cell identified in the previous step.
omnistrate-ctl custom-network list -f host_cluster_id:<deployment-cell-id>

AWS PrivateLink provides secure, private connectivity between VPCs and AWS services or customer-hosted services without exposing traffic to the public internet. It creates a private endpoint within your VPC that acts as an entry point for traffic destined to supported AWS services or VPC endpoint services.

Using Omnistrate you can enable your customers to connect to their deployed services using AWS PrivateLink by automatically exposing VPC endpoint services that customers can reach from their own VPCs. This integration provides:

  • Endpoint Service Creation: Creates and manages VPC endpoint services for your service deployment
  • Private Connectivity: Customers can establish private connections to their services without exposing traffic to the public internet
  • Cross-Account Access: Secure connectivity between customer VPCs and Service Provider managed infrastructure
  • Simplified Management: Omnistrate handles the complexity of endpoint service configuration and management

How It Works with Omnistrate

  1. Service Deployment: When services are deployed through Omnistrate, VPC endpoint services are automatically created
  2. Endpoint Exposure: Omnistrate exposes these endpoint services with appropriate permissions for customer access
  3. Customer Connection: Customers create VPC endpoints in their own VPCs that connect to the Omnistrate-managed endpoint services
  4. Private Communication: Traffic flows privately between customer VPCs and deployed services through the PrivateLink connection

This approach allows customers to maintain private connectivity to their services while benefiting from Omnistrate's managed infrastructure and simplified networking configuration.

For detailed implementation steps and support, reach out to [email protected].

Dedicated Connection

Dedicated Connection provides dedicated, private connections between customer on-premises infrastructure and cloud provider networks, bypassing the public internet entirely. This enterprise connectivity solution offers enhanced security, predictable performance, and reduced latency.

How Dedicated Connection Works

Direct link establishes a dedicated connection between customer premises and cloud provider infrastructure through:

  1. Physical Connection: A dedicated circuit between customer network and cloud provider edge location
  2. Virtual Interfaces: Multiple virtual connections (VLANs) over the physical connection
  3. BGP Routing: Border Gateway Protocol exchanges routing information between networks
  4. Private Routing: Traffic flows directly through the private connection

Benefits

  • Enhanced Security: Traffic never traverses the public internet
  • Predictable Performance: Dedicated bandwidth with consistent latency
  • Cost Optimization: Reduced data transfer costs for high-volume workloads
  • Compliance: Meets regulatory requirements for private data transmission

Setup Overview

Setting up dedicated link requires coordination between customer, Service Provider, and cloud provider. The customer is responsible for network planning (determining bandwidth requirements and routing design), arranging physical connectivity to the cloud provider's edge location, configuring BGP routing protocols and policies, and ordering the dedicated circuit through the cloud provider. The Service Provider must accept the virtual interface in their account, configure network gateways and routing tables, set up security groups and access controls, and establish connection health monitoring.

Cloud Provider Options

  • AWS Direct Connect: Dedicated connections to AWS infrastructure
  • Azure ExpressRoute: Private connections to Microsoft Azure
  • Google Cloud Interconnect: Dedicated connectivity to Google Cloud

Key Considerations

  • Redundancy: Establish multiple connections for high availability
  • Security: Implement network segmentation and access controls
  • Monitoring: Track connection health and performance metrics
  • Cost Management: Right-size bandwidth and optimize data transfer costs

For detailed implementation steps and support, reach out to [email protected].