Private connections
Many organizations require network paths that never traverse the public internet. Common drivers include:
Data security and exfiltration risk reduction: Keep traffic on the cloud provider’s private backbone and out of public address space.
Compliance and governance: Meet regulatory or internal controls that mandate private access to services and data stores.
Predictable controls: Use familiar VPC/VNet constructs (subnets, security groups/NSGs, route tables, firewalls) for centralized policy and auditing.
Stable connectivity architecture: Reduce dependencies on public IPs, NATs, and open egress while simplifying allow-listing and segmentation.
Cloud vendors provide native, managed "private access" offerings to enable private connectivity between services in their cloud or to securely connect with on-premise or cross-cloud services. Examples include Azure Private Link, AWS PrivateLink, and Google Cloud Private Service Connect—each keeping service traffic on the provider’s backbone instead of the public internet.
Private connectivity in Striim Cloud
Striim Cloud uses each cloud service provider’s most secure, first-party private networking primitives to reach sources and targets privately:
AWS: On AWS, Striim connects through AWS PrivateLink (interface endpoints) so traffic to supported AWS or on-prem sources appears "as if" it’s inside your VPC; no internet gateway, NAT, or public IPs required.
Azure: Striim integrates with Azure Private Endpoints (and, where appropriate, customer-managed Azure Private Link services behind internal load balancers) so connections to data sources hosted and on-prem services stay on the Azure backbone.
Google Cloud: In GCP, Striim uses Private Service Connect (PSC) to privately access managed services from inside your VPC, avoiding exposure on the public internet.
Cloud-specific setup
For detailed instructions and examples, see the following sections: