Original Japanese article: Snowflakeのエディションごとの違いとAWSとのセキュアな接続方法

Introduction

I'm Aki, an AWS Community Builder (@jitepengin).

More and more organizations are adopting Snowflake as their data platform.
However, once you actually start planning an implementation, there is often a surprisingly common question:

“Which Snowflake edition should we choose?”

In particular, many teams struggle to decide between Enterprise Edition and Business Critical Edition.

This becomes even more important when Snowflake is used together with AWS and there is a requirement for secure network connectivity.

Snowflake offers four editions, and higher editions provide stronger capabilities around security, compliance, and availability.
In addition, private connectivity using AWS PrivateLink requires Business Critical Edition or higher.

This means that if you initially start with Enterprise Edition and later realize that you need PrivateLink, migrating afterward can introduce additional operational and architectural effort.

In this article, I would like to briefly organize the differences between Snowflake editions and then explore how to securely connect Snowflake with AWS using Business Critical Edition, especially through AWS PrivateLink.

Differences Between Snowflake Editions (Quick Overview)

Snowflake provides the following four editions.
Each higher edition includes all functionality from the lower editions, while credit pricing increases accordingly.

Standard Edition

This is the entry-level edition and provides the core Snowflake functionality.

It includes capabilities such as:

• SQL processing
• Semi-structured data support
• Data sharing
• 1-day Time Travel

For organizations simply looking to use Snowflake as a data warehouse, Standard Edition is often sufficient.

It is generally a good fit for startups or smaller analytics teams that want to begin using Snowflake quickly.

Enterprise Edition

Enterprise Edition adds several features that are effectively essential for production workloads.

Key additions include:

• Multi-cluster warehouses (for scaling concurrent users)
• Materialized Views
• Extended Time Travel (up to 90 days)
• Column-level and row-level security
• Dynamic Data Masking
• Query Acceleration Service
• Search Optimization Service

In practice, Enterprise Edition often feels like the real starting point for production Snowflake environments.

As data volume and concurrency increase, multi-cluster warehouses become especially important.

Business Critical Edition

Business Critical Edition is designed for organizations handling regulated or highly sensitive data.

In addition to all Enterprise features, it includes:

• AWS PrivateLink / Azure Private Link / Google Private Service Connect
• Tri-Secret Secure (dual encryption using customer-managed keys)
• Account failover / failback
• Client redirect
• Compliance support for HIPAA, HITRUST CSF, PCI DSS, FedRAMP

If you are handling sensitive information such as:

• PHI (medical data)
• PCI-related cardholder data
• Personally identifiable information

then Business Critical Edition becomes necessary.

It is also mandatory if your networking requirements specify that connectivity must avoid the public internet and use PrivateLink instead.

Data is one of the most important enterprise assets.
For that reason alone, I often see organizations adopting Business Critical Edition.

Virtual Private Snowflake (VPS)

This is Snowflake’s highest edition and provides a dedicated Snowflake environment.

Infrastructure is completely isolated and hardware resources are not shared with other customers.

It is intended for organizations with extremely strict security requirements, such as:

• Financial institutions
• Government agencies

I personally have not worked with VPS directly, and pricing/details require contacting Snowflake, so I will omit deeper discussion here.

Which Edition Should You Choose?

From a practical perspective, the decision criteria often look something like this:

• Standard: Evaluation, PoC, small analytics teams
• Enterprise: General production workloads (this is where many companies start)
• Business Critical: Regulated industries, sensitive data, or mandatory PrivateLink requirements
• VPS: Financial/government environments requiring complete isolation

One important point is that if you simply decide to “start with Enterprise,” you cannot use PrivateLink.

Because of this, it is safest to validate networking requirements at the beginning of the project.

Upgrading later is possible, but it may require revisiting architecture and pricing assumptions.

Considering Connectivity with AWS

When using Snowflake on AWS, network design—specifically how clients and applications connect—is tightly related to edition selection.

Here, I would like to organize connectivity approaches from both the Enterprise and Business Critical perspectives.

Connectivity with Enterprise Edition

Enterprise Edition does not support AWS PrivateLink, so connectivity to Snowflake is fundamentally internet-based.

Client / AWS Services
        ↓
    Internet
        ↓
    Snowflake

Hearing “internet-based connectivity” may sound concerning at first.
However, even with Enterprise Edition, it is possible to achieve a practical security level by combining multiple controls.

1. Restricting Source IPs with Network Policies

Snowflake network policies can restrict allowed source IP addresses.

By limiting access to known egress IPs such as:

• Corporate network addresses
• Elastic IPs attached to NAT Gateways

you can significantly reduce the risk of unauthorized access.

2. Key Pair Authentication + AWS Secrets Manager

For credential management, password authentication should generally be avoided in favor of key pair authentication.

As of 2026, Snowflake is actively moving away from single-factor password authentication.
For system integrations, Key Pair authentication or OAuth is now the recommended approach.

When connecting from services such as AWS Lambda, storing private keys in AWS Secrets Manager is a practical approach.

Event Source
    ↓
AWS Lambda
    ↓
Secrets Manager
    ↓
Retrieve Private Key
    ↓
Snowflake (TLS over Internet)

I covered this approach in a previous article as well:

Securely Implementing Snowflake AWS Lambda Integration with Key Pair Authentication + Secrets Manager

3. TLS Encryption

All communication with Snowflake is encrypted via TLS.

This means the communication channel itself remains confidential.

In other words, even with Enterprise Edition, combining:

• IP restrictions
• Key Pair authentication
• TLS encryption

can provide a practical level of security.

However, traffic still traverses the public internet.

Limitations of Enterprise Edition

Enterprise Edition cannot satisfy requirements such as:

• Audit/compliance mandates requiring “no internet-based connectivity”
• Internal security policies mandating PrivateLink
• Handling regulated data under HIPAA or PCI DSS
• Encrypting data using customer-managed KMS keys (Tri-Secret Secure)

Once these requirements appear, Business Critical Edition or higher becomes necessary.

Connectivity with Business Critical Edition

Business Critical Edition supports AWS PrivateLink, enabling private connectivity between AWS VPCs and Snowflake.

In this architecture, traffic remains entirely within the AWS backbone network and never traverses the public internet.

    AWS VPC
        ↓
VPC Interface Endpoint
        ↓
 AWS PrivateLink
        ↓
   Snowflake VPC

High-Level Setup Procedure

Following the official documentation, the configuration can be summarized in several major steps.

1. Enable PrivateLink on the Snowflake Side

Using the ACCOUNTADMIN role, authorize AWS PrivateLink for the Snowflake account.

First, obtain a federation token using AWS STS.

aws sts get-federation-token --name your-user-name

Then execute authorization from the Snowflake side.

USE ROLE ACCOUNTADMIN;

SELECT SYSTEM$AUTHORIZE_PRIVATELINK(
  '<aws_account_id>',
  '<federated_token>'
);

You can verify authorization with the following function.

SELECT SYSTEM$GET_PRIVATELINK('<aws_account_id>', '<federated_token>');

If the response returns:

Account is authorized for PrivateLink.

then authorization succeeded.

2. Retrieve the VPC Endpoint ID

Retrieve the information required for AWS VPC Endpoint creation.

SELECT SYSTEM$GET_PRIVATELINK_CONFIG();

Take note of the privatelink-vpce-id value returned in the JSON response.

This ID becomes the “service name” when creating the VPC Endpoint on AWS.

3. Create the VPC Endpoint on AWS

Create an AWS VPC Interface Endpoint using the following configuration.

• Service Name: the privatelink-vpce-id
• VPC: the source VPC
• Subnets: multi-AZ deployment is recommended
• Security Groups: allow ports 443 and 80 from Lambda/EC2

Port 80 is required for OCSP (certificate revocation checking), so do not forget to allow it.

4. Configure DNS

When using PrivateLink, the Snowflake account URL changes to the following format:

<account_identifier>.privatelink.snowflakecomputing.com

You must create a CNAME record mapping the endpoint returned by SYSTEM$GET_PRIVATELINK_CONFIG() to the DNS name of the AWS VPC Endpoint.

Using a Route 53 Private Hosted Zone is the most common approach.

5. Verify Connectivity

Finally, verify connectivity from the client side.

For diagnostics, the SnowCD (Snowflake Connectivity Diagnostic Tool) is useful for validating PrivateLink connectivity.

snowcd <hostfile>

Configuring VPC Endpoints for S3 Access

This is an easy detail to overlook.

Snowflake drivers such as:

• JDBC
• ODBC
• Python Connector

internally access Amazon S3 during data load/unload operations against stages.

Even if Snowflake connectivity itself is private via PrivateLink, S3 traffic may still traverse the public internet unless additional configuration is performed.

Available approaches include:

• Creating AWS VPC Interface Endpoints for Snowflake internal stages (recommended)
• Creating an S3 Gateway Endpoint to privatize S3 bucket access
• Allowing internet-based S3 access (strongly discouraged)

If you want a fully private architecture, Snowflake officially recommends creating VPC Interface Endpoints for internal stages.

Blocking Public Access

After establishing PrivateLink connectivity, you can also block public access from the Snowflake side.

This allows only PrivateLink-based connectivity.

CREATE NETWORK POLICY privatelink_only
  ALLOWED_IP_LIST = ('10.0.0.0/8');

ALTER ACCOUNT SET NETWORK_POLICY = privatelink_only;

Snowflake also provides:

• SYSTEM$ENFORCE_PRIVATELINK_ACCESS_ONLY
• “Enforce privatelink-only access”

which are also valid approaches.

Combining VPN-based corporate IP ranges with PrivateLink-only access can create an even more secure architecture.

Leveraging Tri-Secret Secure

Business Critical Edition also supports Tri-Secret Secure using AWS KMS customer-managed keys (CMKs).

This mechanism requires both:

• Snowflake-managed keys
• Customer-managed keys

as an AND condition for decryption.

Even if Snowflake itself were compromised, data could not be decrypted without the customer-managed key.

Combining:

• PrivateLink
• Tri-Secret Secure

creates a very strong architecture for regulatory compliance.

I have not personally implemented this feature, so I will omit further details here.

Cross-Region Connectivity

AWS PrivateLink is fundamentally designed for same-region connectivity.

However, Business Critical Edition and above also support cross-region connectivity.

For example:

• Snowflake account in US-EAST
• AWS VPC in AP-NORTHEAST-1 (Tokyo)

can still communicate privately via PrivateLink.

That said, there are several caveats:

• PaaS services such as S3 and KMS do not support cross-region PrivateLink
• Government and China regions are not supported
• “Enable Cross Region Endpoint” must be enabled in the VPC console

In practice, aligning the Snowflake region with the application region generally results in a simpler and easier-to-operate architecture.

Still, for globally distributed data platforms, these considerations become important.

Balancing Edition Selection and Cost

Business Critical Edition provides major security advantages, but the credit cost is roughly 1.3x higher than Enterprise Edition.

As rough on-demand reference pricing for US East in 2026:

• Standard: approximately $2/credit
• Enterprise: approximately $3/credit
• Business Critical: approximately $4/credit

If you have a strict requirement that traffic must never traverse the public internet, Business Critical is effectively the only option.

However, from a practical standpoint, balancing data sensitivity and cost often leads to architectures such as:

• Production data warehouse (including sensitive data): Business Critical
• Development / testing environments: Enterprise
• Dedicated data sharing accounts: Enterprise

Using multiple editions strategically within the same organization can also be a reasonable approach.

Conclusion

In this article, including some reflections from my own experience, I introduced the differences between Snowflake editions and explored secure AWS connectivity using Business Critical Edition.

The key points are:

• Snowflake provides four editions (Standard / Enterprise / Business Critical / VPS), with higher editions adding stronger security and compliance capabilities
• AWS PrivateLink requires Business Critical Edition or higher, so networking/security requirements should be validated early
• Even Enterprise Edition can achieve reasonable security through network policies, Key Pair authentication, and TLS
• Business Critical enables private connectivity between AWS VPCs and Snowflake through PrivateLink, fully isolating traffic from the public internet
• S3 access must also be privatized, so VPC Endpoints for internal stages should be configured as well
• Combining Tri-Secret Secure with PrivateLink enables architectures well suited for regulatory compliance

I think many teams struggle specifically with deciding between Enterprise Edition and Business Critical Edition.

Although edition upgrades are possible later, they can significantly impact both architecture and cost.
For that reason, it is best to organize these requirements carefully during the early stages of requirements definition and architecture design.

I hope this article helps anyone looking to use Snowflake securely on AWS.