Snowflake Data Connectivity Proxy for Private Data

| Source: Snowflake Blog

Tags: Snowflake, Openflow, data integration, data engineering, private cloud, enterprise data

Snowflake's new Data Connectivity Proxy (DCP) for Openflow lets enterprise data teams connect on-premises Oracle, Kafka, and multi-cloud sources to Snowflake's managed ETL service via an outbound-only TLS agent on port 443 — eliminating the multiweek firewall approvals and VPN projects that previously blocked private data integration.

Details

Enterprise data pipelines have long hit a wall with private sources. Organizations in financial services, healthcare, and manufacturing typically enforce deny-all-inbound network policies, turning what should be a pipeline configuration task into a weeks-long project involving network engineering teams and change advisory boards just to open an inbound port. Snowflake is launching Data Connectivity Proxy (DCP), a lightweight agent that runs inside your private network and connects outbound to Snowflake Openflow — the company's fully managed data integration service — over TLS on port 443. No inbound firewall rules, no VPN tunnels, and no cloud-provider-specific PrivateLink configuration per source. A single agent model handles Oracle databases on-premises, Kafka brokers in private VPCs, and databases spread across multiple cloud providers simultaneously. Before DCP, reaching private sources meant either building and operating custom ETL at every network boundary, or getting approvals to open inbound connectivity that typically takes multiple weeks and regulatory sign-off in heavily controlled industries. DCP removes that blocker by flipping the connection direction. One current limitation noted in the announcement: the agent's outbound traffic cannot be routed through an enterprise HTTPS_PROXY or CONNECT-based forward proxy — the host needs direct outbound access to Snowflake on port 443. For data teams already on Snowflake Openflow, DCP removes the last major barrier to migrating private and on-premises sources into a fully managed pipeline. Teams in regulated industries who previously could not justify Openflow for private data now have a viable path without negotiating network exceptions.