Estuary

Secure Snowflake: Deploying Industry-Grade Snowflake Integrations

Learn how to securely connect Snowflake using PrivateLink and BYOC in order to keep data off the public internet while meeting security and compliance requirements.

Blog post hero image
Share this article

In regulated industries, Snowflake is the go-to system for storing and reviewing private information. Banks, healthcare firms, and major companies turn to it because it guarantees that safety and legal standards are fully adhered to while protecting confidential data.

However, as an increasing number of companies has started adopting Snowflake, it’s become clearer that linking different tools is not that simple. Systems are often found in different clouds or on internal networks. In some setups, on-premises and cloud-based components are combined, which makes direct online connection difficult.

To address this, companies have started storing information locally in the form of customer-owned cloud accounts or VPCs instead of in public environments. They use private links that limit outside access while increasing the separation between networks.

A connection between Estuary and Snowflake can follow this model. Teams that want more control can choose a private setup or BYOC (Bring Your Own Cloud). This way, they can keep their information inside their system while linking to Snowflake via PrivateLink. Their data remains within their control, and they retain full authority.

In this guide, you'll learn how to securely connect Estuary to Snowflake using PrivateLink and BYOC. As a result, your data will remain off the public internet while meeting security and compliance requirements.

Key Takeaways

  • PrivateLink keeps Snowflake traffic off the public internet by using private endpoints.

  • With BYOC deployments, the data plane remains inside the customer’s cloud account for stronger control.

  • Standard SaaS ELT models can introduce visibility gaps, shared-tenancy concerns, and egress costs.

  • The setup process is similar across AWS, Azure, and GCP, with small provider differences.

  • Estuary can be configured to use private hostnames for Snowflake connections in BYOC environments.

Security Problems With Standard Snowflake Integrations

Nowadays, many Snowflake users rely on independent SaaS platforms to move data. These platforms are simple to use and handle changes smoothly.

A flow chart for the traditional SaaS ELT model. A vendor cloud account shows a multi-tenant environment, traveling from source to public internet to a multi-tenant control plane, then to Snowflake.
In traditional SaaS ELT architectures, data is processed in vendor-managed, multi-tenant environments and typically traverses the public internet to reach Snowflake.

In typical SaaS ELT setups, data moves through vendor-controlled systems and is accessed by multiple users simultaneously. From there, it often travels over public networks to reach Snowflake.

In this model, visibility and control can be limited. Architects may struggle to understand where each tenant's load fits, who gains access to live systems, or who handles problems. Managing expenses becomes harder, as well. Moving data from a user's cloud to the provider's VPC and then onward to Snowflake incurs additional costs, such as data transfer fees, which increase rapidly as data accumulates.

For companies with strict rules about security, audits, and oversight, it becomes increasingly difficult to strike balance. Basic protections, such as firewalls or routine checks, are no longer sufficient.

As regulatory rules shift toward zero-trust architecture and split accountability, many companies opt for setups that integrate with cloud safeguards rather than operating independently in public clouds beyond the control of the company.

BYOC and Secure Data Integration for Snowflake

When using Estuary to connect to Snowflake, you can either opt for out-of-the-box encrypted data movement or set up PrivateLink in conjunction with a private or BYOC deployment. With the latter approach, you get full control over moving data.

Two columns representing Estuary's deployment options: private deployment or Bring Your Own Cloud (BYOC). The distinction is that customers own their hardware in BYOC, while Estuary owns it in private deployment.
Estuary's Bring Your Own Cloud and secure data integration setups are key reasons why Snowflake integrations are effective for cloud tasks. They not only provide transparency of ownership and governance, but also give control over the ‍‌‍‍‌expenditure.

What sets Estuary apart is its capacity to manage Bring Your Own Cloud and private data integration using Snowflake, which makes it just right for handling cloud-based tasks. When set up correctly, ownership and monitoring are clearly defined, and control over spending is built into the system's design.

With Estuary’s split architecture, data planes operate separately from the control plane. This model works well for large teams that require strict isolation (such as banks and medical service providers), where clearly defined boundaries are essential.

Security and compliance rules determine how Estuary handles data. It’s encrypted in transit and at rest alike, and access to it is governed by IAM policies. Network rules set within virtual private clouds and subnets add another layer of protection.

Once data is hidden within guarded cloud sections, organizations can align with specific frameworks, such as HIPAA, GDPR or SOC 2, by using built-in features. No additional apps are needed.

PrivateLink is managed by cloud providers such as AWS. Instead of routing traffic over public internet paths, resources connect privately inside controlled networks. Traffic stays hidden from external flows, which reduces public access and leads to lower risk exposure.

A VPC securely connecting to AWS services, partner VPCs, and internal resources using PrivateLink and different endpoint types.
Here's how a VPC can securely connect to AWS services, partner VPCs, and internal resources using PrivateLink and different endpoint types. (Source)

For teams working with private or BYOC deployments, PrivateLink ensures safer connections and strengthens control over system interactions.

Some of its key traits include:

  • Private connectivity: Service connections use IP addresses that the traffic cannot see. All the information is kept in the cloud.
  • Clear trust boundaries: Imagine someone at each location setting up their own endpoint, without a central team involved. Authority spreads from the center to the edges, shaping who can do what across the system. Access gets restricted just enough to keep things manageable.
  • Simpler security reviews: Setups usually become easier to design and review because traffic avoids public networks.

Links (like the ones in Estuary) use secret hostnames when you use PrivateLink, ensuring information moves inside protected cloud areas rather than across open routes. Snowflake connects with tools that benefit from tighter control.

As mentioned, this guide shows you how to connect Estuary to Snowflake using PrivateLink within a private or Bring Your Own Cloud (BYOC) environment.

Flow chart showing Estuary data plane (BYOC or private deployment) flowing to PrivateLink then to Snowflake, outside of the Customer's Cloud Account.
Estuary allows customers to use their own cloud setups and private networks, ensuring that all data traffic with Snowflake stays secure and doesn't go through the public internet.

The goal is simple: each link routes data directly from Estuary into Snowflake’s private cloud, keeping all traffic isolated from public networks.

The approach remains similar regardless of the cloud you pick (AWS, Azure, or GCP), but each provider has slight differences in configuration.

Step 1: What You Need Before You Start

Before you start, you will need a Snowflake account that supports private connectivity, an Estuary private or BYOC deployment, and a cloud network, such as VPC or VNet, located in the same region as both Snowflake and your private Estuary deployment. You will also need admin access to Snowflake and permissions to create private endpoints in your cloud account.

Supported clouds include:

  • AWS → PrivateLink
  • Azure → Azure Private Link
  • GCP → Private Service Connect (PSC)

Step 2. Enable Private Connectivity on the Snowflake Side

Before you can create any endpoints, private connectivity must be enabled by Snowflake. To do this, you should contact Snowflake Support and ask them to enable AWS PrivateLink, Azure Private Link, or GCP Private Service Connect.

You will be asked to provide your Snowflake account name and locator, your Snowflake region, and the cloud provider account ID for the cloud that you wish to connect, where Estuary’s data plane runs (this will be your Estuary data plane service account ID, such as the data plane’s AWS IAM ARN).

After this is done, Snowflake will set up a connection (one link) with your cloud setup. The support will share a VPCe when they’re done. Make sure that you save this information.

Step 3. Retrieve Snowflake’s Private Connection Details

Once private connectivity has been turned on in Snowflake, open a worksheet and execute this query:

sql
SELECT SYSTEM$GET_PRIVATELINK_CONFIG();

This command returns Snowflake’s private connection details, including the private account URL, service identifiers, and cloud-specific endpoint details.

Save this output.

Step 4. Share Endpoint Details with Estuary

Share the information you’ve collected with the Estuary team, including the result of running SYSTEM$GET_PRIVATELINK_CONFIG() and the VPCe from Snowflake.

From there, Estuary completes the remaining configuration steps. It gives you access to a private DNS hostname, or a private IP address. This is the address Estuary will use to connect to Snowflake.

Step 5. Configure Snowflake in Estuary

In the Estuary UI:

  1. Go to Destinations → New materialization
  2. Select Snowflake
  3. For the Data Plane, make sure to choose your private data plane
  4. In Host (Account URL):
    • Enter the private hostname or private IP given by Estuary
    • Avoid the public .snowflakecomputing.com URL
  5. Fill in:
    • DatabaseESTUARY_DB (or your value)
    • SchemaESTUARY_SCHEMA
    • WarehouseESTUARY_WH
    • RoleESTUARY_ROLE (optional)
  6. Set up the authentication (JWT / key-pair)

When configuring the connector, Estuary expects:

plaintext language-jsx
credentials: auth_type: jwt user: ESTUARY_USER privateKey: | -----BEGIN PRIVATE KEY----- MIIEv.... -----END PRIVATE KEY-----

In the UI, this corresponds to:

  • UserESTUARY_USER
  • Private key: Paste contents of rsa_key.p8
  1. Select source collections:
    • Link your capture (Postgres, Kafka, Stripe, Jira, or similar) and pick the collections meant for Snowflake.
    • When using Snowpipe Streaming or append-style writes, you can activate delta updates on bindings, though this feature is not required.
  2. Move on by clicking Next → Test → Save and Publish so the materialization can be deployed.
The Estuary UI displays a Destination page for setting up a Snowflake materialization.
Setting up Snowflake inside the Estuary interface.

See additional setup details and advanced configuration options in Estuary's docs.

Step 6. Verify Everything Is Working

Finally, make sure that everything is working as expected.

In Estuary, check whether the materialization is active and currently executing, and in Snowflake, query the tables and confirm that new data is arriving.

Within your cloud provider, verify that traffic reaches the private endpoint and that no internet gateway or NAT is involved.

Result

Estuary now connects to Snowflake using private network paths only. There is no public internet traffic, network ownership is clearly defined, and audits and compliance reviews become easier to manage.

For example, you can stream CDC data from PostgreSQL into Estuary and materialize it into Snowflake over PrivateLink from a BYOC deployment.

Notes

  • PrivateLink is optional. Estuary also supports public Snowflake connections when private networking isn’t required.
  • Steps on the Snowflake side may vary slightly depending on the cloud provider.
  • For BYOC setups, Estuary manages the control plane, while the data plane operates within your cloud.

How Architects Compare Different Deployment Models Used by Competitors

Some teams prioritize processing data within apps, while others prefer to do so externally. When making this choice, they mostly focus on security, ease of use, and the way data moves since this directly impacts data safety.

A good way to evaluate integration platforms would be to classify them into four main types.

Common Data Plane Deployment Models

Deployment modelWhere the data plane runsWho owns the cloud accountNetwork and egress controlCompliance and audit alignmentOperational visibility
Multi-tenant SaaSVendor-managed, shared infrastructureVendorVendor-controlled; often uses public endpointsRequires trusting vendor controls and processesLimited to vendor-provided logs and metrics
Vendor-managed “private” VPCDedicated VPC, still in vendor accountVendorPartially isolated, but egress and routing owned by vendorImproved isolation, but auditors still assess vendor accountsModerate; visibility depends on vendor tooling
Gateway / agent-based modelLightweight agent in customer network, processing in vendor cloudSplitPartial control; data still leaves the environmentReduces exposure but does not fully eliminate vendor trustFragmented; logs split across systems
Bring Your Own Cloud (BYOC) Data PlaneFully inside customer cloud accountCustomerCustomer-controlled routing, egress, and endpointsStrong alignment with internal compliance and security reviewsFull visibility using existing cloud tools

Architecture Aspects to Consider

With Snowflake in BYOC or private deployments, choices about architecture determine how effectively the system scales, remains secure, and complies with regulations across different zones and cloud platforms.

  • Cloud account ownership: In vendor-run SaaS or private VPC setups, auditors usually have to look inside the service provider's cloud space, which complicates oversight and prolongs confirmation time. Estuary's BYOC approach means that the data layer operates fully within the customer's own account. As a result, every audit check stays inside the infrastructure that is controlled by the company.
  • Network and egress control: Without internet access, some online apps might not work properly. This could affect people using them and may lead to surprising costs. Estuary addresses the risk in two ways: through a fully enclosed approach or through Bring Your Own Cloud. Each of them features guarded routes, strict firewall logic, and direct links to Snowflake via PrivateLink.
  • Compliance and audit scope: Laws might limit where critical information stays within regulated organizations. With Estuary’s approach, that information remains within legal zones alongside similar internal tools.
  • Incident response and operations: Estuary builds its data setup straight inside customers’ clouds. That means the security and SRE teams get to keep working with familiar monitoring tools, logs, and response routines, just as they would with internal services.

The Significance of BYOC for Business Snowflake Users

Teams that operate Snowflake within their approved environments can achieve security and oversight through a BYOC integration with Estuary. Since the data pathway runs through their own cloud setup, combining datasets becomes just another process.

Alignment With Enterprise Security Patterns

Estuary’s BYOC model operates in the same way as present-day cloud security systems, which companies use to protect their cloud infrastructure.

  • Cloud security basics: The data plane at Estuary operates through established security zones, which enable customers to handle their encryption needs, follow established tagging standards, and maintain proper log management.
  • Least privilege and IAM governance: Existing IAM roles manage access in Estuary, giving teams control over Snowflake, source systems, and cloud resources without requiring modifications.
  • Zero trust networking: Estuary lets users specify where they want their data to be transferred. PrivateLink enables you to move data to Snowflake through a secure path, which prevents any information from traveling through public internet connections.

Inside managed VPCs, Snowflake links adhere to current security policies. With PrivateLink, Estuary’s cloud setup uses BYOC to keep connections locked down.

What Architects Should Do

Architects need to make important choices to keep Snowflake integrations safe and simple to manage, especially when using Estuary in a private or BYOC setup:

  • Pick the deployment that fits your needs. Estuary supports both vendor-managed setups and BYOC models.
  • Keep your data processing in the same cloud area where Snowflake is running. This will make things move faster and reduce costs.
  • Maintain a locked-down network. PrivateLink between Estuary and Snowflake gives you personal Virtual Private Clouds and subnets fully under your control. Data exiting your domain isn’t random. Access is carefully filtered, giving you ownership over exits, which improves trust and reduces risk.
  • Link Estuary to IAM, KMS, logging, and monitoring. Connect Estuary to the tools you already run, so your pipelines follow the exact same policies as your current applications. Same setup, just for new tasks.
  • Use Estuary to track everything with the same tools. That way, everyone can see the same information.

With Estuary, Snowflake connections aren’t just additional layers. They become integral elements.

Conclusion

Where you place your integration setup makes a big difference. It shapes how secure, affordable, and easy to use your connections are.

Most tools operate within their provider's cloud, which limits your control. In contrast, Estuary lets you watch data flow right from your own digital space. Connections to Snowflake occur through PrivateLink, which keeps data off public networks and away from prying eyes.

With Estuary, your data stays with you, within your own configuration. This setup makes it easier over time to protect, organize, and manage more data.

FAQs

    What is Snowflake PrivateLink and how does it work?

    Snowflake PrivateLink allows you to privately connect Snowflake to services that are running in your cloud. It does this by sending traffic through the cloud provider's internal network instead of the public internet.
    PrivateLink is the recommended solution that protects resources from public network access when organizations need to meet their strict security and compliance requirements.
    Standard SaaS integrations use vendor-controlled multi-tenant platforms that process data through public internet connections. These platforms have limited visibility into network pathways and access points, and do not provide audit capabilities. They are exposed to the public network.
    BYOC (Bring Your Own Cloud) means the data plane runs entirely inside your own cloud account. This gives you complete authority to manage the network, security, compliance, and visibility of operations during Snowflake integration.
    Estuary lets users set up their own private and BYOC solutions. This way, customers can run their data in their own cloud environment. They can also use PrivateLink to connect to Snowflake, which enables them to transfer data securely over the internet while keeping complete control of their data.

Start streaming your data for free

Build a Pipeline

About the author

Picture of Jaume Boguñá
Jaume BoguñáData Engineer

I am a dynamic and results-driven data engineer with a strong background in aerospace and data science. Experienced in delivering scalable, data-driven solutions and in managing complex projects from start to finish. I am currently designing and deploying scalable batch and streaming pipelines at Banco Santander. I also create technical content on LinkedIn and Medium, where I share daily insights on data engineering.

Streaming Pipelines.
Simple to Deploy.
Simply Priced.
$0.50/GB of data moved + $.14/connector/hour;
50% less than competing ETL/ELT solutions;
<100ms latency on streaming sinks/sources.