Original Japanese article: AWSから見たSnowflake Storage for Iceberg

Introduction

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

On November 4, 2026, backups for Snowflake Storage for Apache Iceberg tables became generally available (GA) in Snowflake.
Snowflake Storage for Iceberg itself was released as a preview in April 2026 and became GA in June.
It lets you keep the data of Snowflake-managed Iceberg tables in storage managed by Snowflake, instead of in your own S3 bucket.

A common reason given for choosing Iceberg is "the data lives in your own S3, so you aren't locked into a specific product," and I've said this myself.
From that point of view, leaving the storage location of Iceberg data to Snowflake can feel like it's no different from being locked in.

To give the conclusion up front, I think the choice is decided not by "whether you use Iceberg" but by "whether you need to handle the files in your own AWS account."

In this article, from the standpoint of someone designing data platforms on AWS, I'll organize what changes between keeping managed Iceberg data in your own S3 and entrusting it to Snowflake.

Three Forms of Iceberg Tables in Snowflake

First, let's organize the forms in which Snowflake handles Iceberg tables.

This article compares the first two.
Both use Snowflake as the catalog, but they differ in where the data and metadata files are stored and how they are managed.

What Is Snowflake Storage for Iceberg?

Snowflake Storage for Iceberg is a mechanism that stores the data and metadata files of Snowflake-managed Iceberg tables in storage that Snowflake provides and manages.
Until now, using managed Iceberg required preparing your own S3 bucket and setting up an external volume and an IAM role so Snowflake could access it.
With Snowflake Storage, that preparation is no longer needed.

To use Snowflake Storage, specify SNOWFLAKE_MANAGED as the external volume when you create the table.

CREATE ICEBERG TABLE my_iceberg_table (col1 int) CATALOG = SNOWFLAKE EXTERNAL_VOLUME = SNOWFLAKE_MANAGED; 

SNOWFLAKE_MANAGED is a reserved value, not an external volume created by the user. So you don't need to run CREATE EXTERNAL VOLUME, or prepare an S3 bucket or IAM role.
The catalog must be SNOWFLAKE, so it can't be used for tables that use AWS Glue or S3 Tables as their catalog.

The files are managed by Snowflake, but the format is still Iceberg.
External engines such as Spark and Trino can also read and write the tables through the Iceberg REST Catalog API of Snowflake Horizon Catalog.

What's Different?

Based on the comparison in the Snowflake documentation, the differences can be summarized as follows.

Looking at them side by side, Snowflake Storage can be seen as an option that hands over to Snowflake the operations you had to own when storing in S3: bucket permissions, lifecycle, orphan file cleanup, and data protection.
The backups that became GA in November also apply to tables that use Snowflake Storage (and dynamic Iceberg tables that use it), and are available on AWS only.
Iceberg tables stored in your own S3 are not covered, so protecting them still has to be handled on the S3 side as before.

Note: If an external engine performs DML or DDL on a table through the Iceberg REST Catalog on or after May 21, 2026, compaction for that table becomes billable from that point on. The documentation doesn't say that the charges stop if you go back to writing only from Snowflake. Keep in mind that whether an external engine ever writes to the table changes your cost assumptions.

What Changes from the AWS Side

From here on, let's look at the differences from the AWS side.
Even though Snowflake Storage files physically live on AWS, they are not in an S3 bucket in your own AWS account.
That means the mechanisms you configured on your own S3 buckets can't be applied as is.

As for customer-managed keys, Tri-Secret Secure for Snowflake Storage became GA in October 2026.
You can encrypt the data written to Snowflake Storage with a customer-managed key (CMK) created in AWS KMS.

Note: Tri-Secret Secure requires Business Critical Edition or higher and is disabled by default. To enable it, you need to contact Snowflake Support. Also, activating the key applies to data written after activation.

The way you audit also changes.
On the Snowflake side, successful operations that external engines perform against the Horizon Iceberg REST Catalog are recorded in ACCESS_HISTORY.
In addition, if you enable the telemetry that became GA in October 2026, requests including their HTTP status codes are recorded in an event table, so you can also track failed requests.
What you used to track with AWS CloudTrail is now tracked with Snowflake's mechanisms.

Note: ACCESS_HISTORY is a view available in Enterprise Edition or higher. Telemetry is recorded when you configure the account's event table and set the log level (LOG_LEVEL) to INFO or higher.

Another thing to watch is the cost of reading from engines on the AWS side, such as Spark on EMR or Glue.
With Snowflake Storage, per-HTTP-request charges apply only when external engines access the tables through Horizon Catalog.
If the reader is in a different region or cloud, data transfer charges also apply.
In setups where engines on the AWS side read the data every day, these charges add up.

What "The Data Is in My Own S3" Really Means

Even with Snowflake Storage, the format remains Iceberg, and external engines can read it through REST.
In that sense, the openness of Iceberg is not lost.

However, something does change: control over where the files live.
If the files are in your own S3, you can access them without going through Snowflake, and decide permissions, auditing, and retention within your own account.
With Snowflake Storage, external engines also have to go through Snowflake's catalog to access the files.

I believe that an open format and owning the files yourself are two different things.
Snowflake Storage is an option that keeps the former while giving up the latter in exchange for less operational work.

Note: You can move data from Snowflake Storage to your own storage at any time using methods such as CTAS.
The documentation also says that for a one-time migration to your own storage in the same cloud platform and region, Snowflake reimburses eligible compute costs if conditions are met, such as the data being stored for at least 30 days and totaling at least 1 TB. (The form of the reimbursement isn't described, so check with Support if you plan to use it.) I think it's worth appreciating that an exit path is provided.

Which Should You Choose?

Let's organize some guidelines.

For data that stays inside Snowflake, especially intermediate data and working tables, Snowflake Storage is simply convenient.
On the other hand, for data used together with AWS services, or data whose permissions and auditing you want to manage in your own AWS account, I think keeping it in your own S3 as before is more natural.

If you want to use AWS Glue or S3 Tables as the catalog, you would choose externally managed Iceberg rather than managed Iceberg in the first place.

Since you can choose per table, there's no need to move everything to one side.
It seems best to ask, table by table, "Is there any chance we'll need to touch this table's files without going through Snowflake?"

Conclusion

In this article, I thought about whether to keep Snowflake-managed Iceberg data in your own S3 or entrust it to Snowflake.

With Snowflake Storage, you can leave bucket management and orphan file cleanup to Snowflake, and take advantage of Fail-safe for permanent tables and the backup feature available for eligible tables.
What you give up in exchange is handling the files in your own AWS account, in other words, control over permissions, auditing, and retention.

I believe using Iceberg and owning the files yourself are separate decisions.
If you're unsure which to choose, starting from whether you need to touch that table's files without going through Snowflake may be a good approach.

I hope this article is helpful to anyone considering where to keep Iceberg tables across Snowflake and AWS.