DEV Community: Aki

Connecting Amazon S3 Tables and Snowflake (via the S3 Tables Iceberg REST Endpoint)

Aki — Fri, 14 Aug 2026 12:26:11 +0000

Original Japanese article: Amazon S3 TablesとSnowflakeを連携する（S3 Tables Iceberg RESTエンドポイント経由）

Introduction

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

In an earlier article, I verified how to read from and write to an Iceberg table on S3 Tables using Snowflake's Catalog Integration via the AWS Glue Iceberg REST endpoint.

Connecting Amazon S3 Tables with Snowflake

That setup routed through Snowflake → the Glue Iceberg REST endpoint → Lake Formation → S3 Tables, and required setting up an IAM policy, a trust policy, registering a Lake Formation data location, and granting permissions across all three levels (Catalog / Database / Table).

On 2026/8/10, Snowflake's Amazon S3 Tables Iceberg REST catalog integration went GA! This is a new route that connects with SigV4 authentication directly to S3 Tables' native Iceberg REST endpoint, without going through Glue at all.

https://docs.snowflake.com/en/release-notes/2026/other/2026-08-10-amazon-s3-tables-iceberg-rest-catalog-integration-ga

This time, I wanted to put this new route to the test.

Test Environment

I reused the same resources as the previous article.

Table bucket: penguin-rest-test
Namespace: analytics
Table: daily_sales (columns sales_date, amount)
Region: ap-northeast-1

Architecture

This time's architecture connects the S3 Tables gold layer to Snowflake. The key point is that it uses the Amazon S3 Tables Iceberg REST catalog integration instead of Glue Data Catalog.

Differences from the Glue Route (Configuration)

The CATALOG INTEGRATION parameters differ, as shown below, configured specifically for S3 Tables.

Item	Via Glue (previous article)	Direct to S3 Tables (this article)
`CATALOG_API_TYPE`	`AWS_GLUE`	`AWS_S3TABLES`
`CATALOG_URI`	`glue.<region>.amazonaws.com/iceberg`	`s3tables.<region>.amazonaws.com/iceberg`
`CATALOG_NAME`	`<account_id>:s3tablescatalog/<bucket>`	`arn:aws:s3tables:<region>:<account_id>:bucket/<bucket>`

Differences from the Glue Route (Setup Steps)

Of the steps required in the previous article, the following Lake Formation-related steps simply don't exist here:

Registering the Lake Formation data location (register-resource --with-federation --with-privileged-access)
Granting Lake Formation permissions across all three levels (Catalog / Database / Table)
Adding sts:SetSourceIdentity / sts:SetContext to the data access role's trust policy

I wanted to make sure "Lake Formation setup really isn't required" is actually true, so I later confirmed this via CloudTrail.

Creating the IAM Role

Starting from the previous article's IAM policy, I removed all Lake Formation- and Glue-related actions, and tested with a minimal-privilege policy scoped down to just s3tables:* actions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3TablesDirectAccess",
            "Effect": "Allow",
            "Action": [
                "s3tables:GetTableBucket",
                "s3tables:ListNamespaces",
                "s3tables:GetNamespace",
                "s3tables:ListTables",
                "s3tables:GetTable",
                "s3tables:GetTableMetadataLocation",
                "s3tables:UpdateTableMetadataLocation",
                "s3tables:GetTableData",
                "s3tables:PutTableData"
            ],
            "Resource": [
                "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test",
                "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test/table/*"
            ]
        }
    ]
}

The key point is that there's no need to include lakeformation:GetDataAccess or any glue:* actions.

Creating the Catalog Integration

On the Snowflake side, I created a catalog integration that connects directly to the S3 Tables Iceberg REST endpoint.

CREATE OR REPLACE CATALOG INTEGRATION penguin_s3tables_direct_int
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  REST_CONFIG = (
    CATALOG_URI = 'https://s3tables.ap-northeast-1.amazonaws.com/iceberg'
    CATALOG_API_TYPE = AWS_S3TABLES
    ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS
    CATALOG_NAME = 'arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test'
  )
  REST_AUTHENTICATION = (
    TYPE = SIGV4
    SIGV4_IAM_ROLE = 'arn:aws:iam::123456789012:role/penguin-s3tables-direct-role'
    SIGV4_SIGNING_REGION = 'ap-northeast-1'
  )
  ENABLED = TRUE;

Compared side by side with the Glue-based article, CATALOG_API_TYPE changes from AWS_GLUE to AWS_S3TABLES, and CATALOG_URI changes from the Glue Iceberg REST endpoint to S3 Tables' native endpoint. CATALOG_NAME also now takes the S3 Tables bucket ARN directly, so the previous article's distinctive <account_id>:s3tablescatalog/<bucket> prefix notation is not used here.

Setting Up the Trust Policy

The steps for retrieving Snowflake's IAM user ARN and external ID via DESC CATALOG INTEGRATION, then setting them on the trust policy of the role specified in SIGV4_IAM_ROLE, are the same as with the Glue route.

DESC CATALOG INTEGRATION penguin_s3tables_direct_int;

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "<AWS_IAM_USER_ARN>"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "<AWS_EXTERNAL_ID>"
                }
            }
        }
    ]
}

Everything up to this point is unchanged from the previous article. The difference shows up from here on: we move straight to table creation with no Lake Formation setup at all.

Creating the Table

CREATE OR REPLACE ICEBERG TABLE GOLD.GOLD.s3tables_direct_table
  CATALOG = 'penguin_s3tables_direct_int'
  CATALOG_NAMESPACE = 'analytics'
  CATALOG_TABLE_NAME = 'daily_sales'
  AUTO_REFRESH = TRUE;

The table was created without any issues, with no Lake Formation data location registration or grants in place.

Verifying It Works (Read)

ALTER ICEBERG TABLE GOLD.GOLD.s3tables_direct_table REFRESH;
SELECT * FROM GOLD.GOLD.s3tables_direct_table;

Data that had already been loaded via Athena was readable from Snowflake without any problem.

Confirming the Lake Formation Calls via CloudTrail

This is the heart of this article. I traced through CloudTrail to see exactly which APIs penguin-s3tables-direct-role was actually calling.

Looking at the logs right after running the read operation, this role only calls GetTableBucket, GetNamespace, ListNamespaces, GetTable, ListTables, and GetTableMetadataLocation against s3tables.amazonaws.com, all of them readOnly: true events.

Three things sealed it:

No invokedBy field
Events from the Glue-based Snowflake_Catalog_Integration role always carry "invokedBy": "glue.amazonaws.com", proof that the resource is being accessed via Glue's service role. Events from the direct role have no such field at all, showing that Snowflake is hitting s3tables.amazonaws.com directly.
sourceIPAddress is a real IP
Events from the direct role record Snowflake's actual source IP in sourceIPAddress, whereas Glue-route events show sourceIPAddress: "glue.amazonaws.com", the notation for an internal service-to-service call.
Zero lakeformation.amazonaws.com events
Across the entire test window (roughly 30 minutes, several hundred CloudTrail events including both reads and writes), there were zero lakeformation.amazonaws.com events attributable to penguin-s3tables-direct-role. During that same window, Snowflake_Catalog_Integration (the Glue route) generated a large volume of lakeformation:GetDataAccess calls, so this isn't a case of events happening to not show up in the log; it's a structural fact that the direct route never goes through Lake Formation.

Verifying It Works (Write)

Beyond reads, let's confirm writes work too. Since the IAM policy already includes s3tables:PutTableData, this can be tested with no additional permission changes.

INSERT INTO GOLD.GOLD.s3tables_direct_table (sales_date, amount)
VALUES
    ('2026-08-14', 99999),
    ('2026-08-14', 88888);

Checking from the Athena side, the data inserted from Snowflake was visible without issue.

SELECT * FROM "analytics"."daily_sales" ORDER BY sales_date DESC LIMIT 10;

I also checked CloudTrail for the write operation, and just as with the read, found no Lake Formation events attributable to penguin-s3tables-direct-role.

Checking Catalog-Linked Database

In the previous article, I verified automatic table discovery via a Glue-based Catalog-Linked Database (CLD), so I wanted to confirm the same works on the direct route.

CREATE OR REPLACE DATABASE penguin_s3tables_direct_linked_db
  LINKED_CATALOG = (
    CATALOG = 'penguin_s3tables_direct_int'
  );

As soon as this was created, daily_sales and daily_sales2 under the analytics namespace showed up automatically in the table list, with no DDL required.

Confirming Auto-Discovery

I created a new daily_sales3 table from the Athena side, and it was automatically detected on the SnowSight side as well.

-- On the Athena side
CREATE TABLE `analytics`.daily_sales3 (
  sale_date date,
  product_category string,
  sales_amount double)
PARTITIONED BY (month(sale_date))
TBLPROPERTIES ('table_type' = 'iceberg')

Confirming Bidirectional Writes

I inserted into the auto-discovered daily_sales3 from Snowflake, then checked whether it was visible from Athena.

INSERT INTO PENGUIN_S3TABLES_DIRECT_LINKED_DB.analytics.daily_sales3 (sale_date, product_category, sales_amount)
VALUES
    ('2026-08-14', 'Electronics', 15000.00),
    ('2026-08-14', 'Clothing', 8500.50),
    ('2026-08-14', 'Food', 3200.75);

Confirmed without issue on the Athena side. Just like the CREATE ICEBERG TABLE approach, the CLD approach also works correctly on the direct route.

How the Two Routes Compare

Putting the previous article's findings together with this one's:

Item	Via Glue (previous article)	Direct to S3 Tables (this article)
IAM policy	`s3tables:` + `lakeformation:GetDataAccess` + `glue:` actions	`s3tables:*` actions only
Lake Formation data location registration	Required (`register-resource --with-federation`)	Not required
Lake Formation grants (3 levels)	Required	Not required
Trust policy `SetSourceIdentity` / `SetContext`	Required	Not required
LF calls on read (CloudTrail)	Occur	Zero
LF calls on write (CloudTrail)	Occur	Zero
CLD auto-discovery and bidirectional writes	Succeeded (confirmed in previous article)	Succeeded (confirmed here)
Read/write operations	Succeeded (confirmed in previous article)	Succeeded (confirmed here)

The biggest difference is a clear tradeoff: do you want unified governance through Lake Formation, or a simpler permission design?

If you want to keep things simple, go with the direct S3 Tables route. If you need unified table management, centralized governance controls, and fine-grained access control, the Glue route is the way to go.

Conclusion

This time, I used Snowflake's Amazon S3 Tables Iceberg REST catalog integration, which went GA on 2026/8/10, to verify the new Glue-free direct route.

To summarize:

The new direct route (CATALOG_API_TYPE = AWS_S3TABLES) has no Lake Formation-related setup steps in the official documentation.
Even after completely removing all Lake Formation and Glue actions from the IAM policy, both reads and writes worked without any issues.
Checking CloudTrail confirmed that lakeformation:GetDataAccess calls from the direct role were zero throughout the entire test window.
Events from the direct role carry no invokedBy: glue.amazonaws.com field, and sourceIPAddress shows a real IP, further confirming that Snowflake accesses the S3 Tables endpoint directly, without going through Glue.
Catalog-Linked Database auto-discovery and bidirectional reads/writes also worked correctly on the direct route, and no Lake Formation calls occurred during the CLD's background sync either.

With the integration verified in this article, using the S3 Tables Iceberg REST endpoint, no Lake Formation-related permissions are needed at all. If you're willing to forgo unified governance through Lake Formation in exchange for a simpler permission design, this looks like a strong option.

I hope this article is helpful to anyone considering connecting S3 Tables and Snowflake.

A Base Directory Mismatch Between Amazon S3 Tables and Snowflake CLD

Aki — Tue, 11 Aug 2026 01:18:07 +0000

Original Japanese article: Amazon S3 Tables×Snowflake CLDでbase directory不整合が発生した話

Introduction

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

I had a setup where an Iceberg table on S3 Tables was being referenced from Snowflake through a Catalog-Linked Database (CLD). While running it, I hit an interesting error, so I'm sharing the investigation process here.

While looking at Data Preview for a table in Snowsight, I noticed the following error:

The parquet file 'data/xxxx/xxxx/xxxx/xxxxxxxx/target_date_month=2026-07/00000-xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-0-00001.parquet'
for table 'SAMPLE_DB."gold"."fact_daily_sample_metric"' was inaccessible.

Since it was complaining about being unable to access a parquet file, I ran ALTER ICEBERG TABLE ... REFRESH just to check the state, and got a completely different error this time:

Statement 1 Failed
One of the specified Iceberg metadata files does not conform to the required directory hierarchy.
All files must reside as a strict subpath under the defined base directory.
Current base directory: s3://aaaaaaaa-1111-4aaa-9999-aaaaaaaaaaaa--table-s3/
Conflicting file path: s3://bbbbbbbb-2222-4bbb-8888-bbbbbbbbbbbb--table-s3/metadata/00004-....metadata.json

This looked nothing like the first error, but once I dug in, both turned out to come from the same root cause.

Spoiler: the cause wasn't some other table's files leaking in. It was that the same table had been DROPed and re-CREATEd in a short window, and the old warehouse location ended up conflicting with the new one. It looks at first glance like "some other table's files got mixed in," but the mismatch was entirely self-contained within this one table.

Tracking down the cause took three stages of investigation: verifying metadata via Athena, checking S3 Tables' spec against the official AWS docs, and pinning down the exact events in CloudTrail. This article is a record of that process.

Auto-Sync Behavior of the Catalog-Linked Database

This setup uses the Catalog-Linked Database (CLD) I covered in an earlier article.

Connecting Amazon S3 Tables with Snowflake

CLD links a namespace (database) to a Glue Catalog, in this case backed by S3 Tables. As I confirmed in that earlier article, when a table is created or changed on the AWS side, it's automatically reflected on the Snowflake side without writing any DDL. That's a real operational win (you don't have to run CREATE ICEBERG TABLE for every single table), but this same "auto-follow" mechanism is also the precondition for the trouble in this article.

Specifically, CLD doesn't just sync the list of tables and their schemas (columns) under a namespace. It also automatically syncs each table's current metadata pointer (table name → location of the latest metadata.json). The "base directory" that caused today's problem is part of that synced state on the Snowflake side.

For what it's worth, the feature itself is genuinely convenient, and I plan to keep using it.

Test Environment

Catalog integration: Snowflake Catalog-Linked Database (CATALOG_SOURCE = ICEBERG_REST, connecting to S3 Tables via the Glue Iceberg REST endpoint)
S3 Tables table bucket: sample-s3-table-gold (anonymized)
Target table: fact_daily_sample_metric (anonymized)
Write job: Glue (Spark), DDL operations via Athena

Looking at the Error Message

To recap, the error is essentially saying "you tried to reference a file outside the path registered as the base directory."

Current base directory: s3://aaaaaaaa-1111-4aaa-9999-aaaaaaaaaaaa--table-s3/
Conflicting file path: s3://bbbbbbbb-2222-4bbb-8888-bbbbbbbbbbbb--table-s3/metadata/00004-....metadata.json

Both S3 paths point to different UUIDs under a --table-s3 suffix. The first thing I needed to figure out was whether these were genuinely two different tables, or whether this was all happening within a single table.

Verifying the Facts via Athena

Checking the current data file paths with `$files`

I used Iceberg's hidden metadata table $files to check which data file paths the table was currently referencing.

SELECT file_path
FROM "gold"."fact_daily_sample_metric$files";

Every path that came back was under bbbbbbbb-.... Not a single file referenced aaaaaaaa-....

Well, that tracks.

Going back through history with `$snapshots`

Next, I checked the past snapshot history using $snapshots.

SELECT snapshot_id, committed_at, manifest_list, summary
FROM "gold"."fact_daily_sample_metric$snapshots"
ORDER BY committed_at ASC;

Even going all the way back to the oldest snapshot, manifest_list was consistently under bbbbbbbb-.... So this wasn't a case of "contamination partway through": as far back as I could check, it had consistently referenced bbbbbbbb-....

Again, that tracks too.

At this point, all I'd confirmed was that "aaaaaaaa-... doesn't currently exist as an actual entity in the Glue Catalog." I still had no idea why it was showing up in the error message at all.

Checking S3 Tables' Spec in the Official Docs

At this point I decided to step back and check the spec for S3 Tables itself. I referenced the following official docs:

What I confirmed here is that S3 Tables automatically generates a unique warehouse location dedicated to each table, every time a table is created.

When you create a table, Amazon S3 automatically generates a warehouse location for that table, a unique S3 location that stores the objects associated with it.

It's also explicitly stated that the --table-s3 suffix is a bucket naming convention reserved exclusively for S3 Tables.

In other words: if you DROP a table and then CREATE it again under the same name, a brand-new warehouse location with a new UUID gets assigned. This felt like a strong candidate for the identity of the two different UUIDs in the error message.

Confirming It With CloudTrail

To test the hypothesis, I searched CloudTrail for this specific table's CreateTable and DeleteTable events. Filtering on those two event names, I was able to reconstruct the table's complete history.

The table's complete history

Time	Event	Entity UUID
Day 1, 11:53:37	Initial `CreateTable` (S3 Tables)	`aaaaaaaa-...` (anonymized)
Day 1, 11:54:13	`CreateTable` completed (Glue side)	Same as above
Day 3, 07:23:47	`DeleteTable` (Glue + S3 Tables, via Athena)	`aaaaaaaa-...` deleted
Day 3, 07:24:08	`CreateTable` again (Glue + S3 Tables, same actor)	`bbbbbbbb-...` created

The gap between the DROP completing (07:23:47) and the re-CREATE completing (07:24:08) was exactly 21 seconds. And these two UUIDs are literally the "base directory" (aaaaaaaa-...) and "conflicting file path" (bbbbbbbb-...) from the error message. So this table was created once on Day 1, then DROPed and re-CREATEd on Day 3, and in that process, its physical entity (the warehouse location) was swapped out entirely.

What this points to is a working hypothesis: even though the table had been recreated, Snowflake's side kept referencing the old location.

Why Did CLD Keep Referencing the Old Location?

Everything from here on is speculation, built from what I could confirm plus what's documented officially by Snowflake.

According to Snowflake's official docs (Use a catalog-linked database for Apache Iceberg tables), CLD polls the remote catalog on a 30-second interval by default (SYNC_INTERVAL_SECONDS).

More importantly, CLD actually has two distinct kinds of sync going on:

Table discovery (SYNC_INTERVAL_SECONDS, default 30s): detects tables added to or removed from the namespace
Table metadata refresh (REFRESH_INTERVAL_SECONDS, default 30s): updates each table's snapshot pointer (the location of the latest metadata.json)

There's also a documented mechanism for detecting table-uuid mismatches during automatic refresh: if the UUID of the external table doesn't match the UUID CLD has on record, the refresh fails and Snowflake drops that table from the CLD (without touching the remote side). So there is, on paper, a mechanism in place to detect that a table's underlying entity has been swapped out.

In this case, I think a timing conflict like this may have occurred:

Day 3, 07:23:47: the old table (aaaaaaaa-...) gets DROPed
21 seconds later, at 07:24:08: a new table with the same name (bbbbbbbb-...) is re-CREATEd
In between, CLD's table discovery hadn't yet detected that "the table disappeared" before a same-named new table showed up
As a result, this got processed not as "table deleted → re-created" but as "existing table updated," leaving the old base directory info in place

The mechanism for detecting a table-uuid mismatch and dropping the table from CLD is documented, and I actually confirmed this detection error firing directly, in the reproduction experiment described below. That said, I never observed the table actually getting dropped afterward (more on that below). My best explanation right now is that because the DROP-to-re-CREATE interval (21 seconds) was shorter than both sync intervals (30 seconds), this mechanism didn't get a chance to fire before the change was processed as an "update."

That said, CLD's internal implementation (exactly when discovery vs. refresh run, and which one wins a race) isn't fully documented, so this remains a hypothesis built from observed facts plus documentation, not something I can call confirmed.

Reproduction Experiment

To test the hypothesis, I tried reproducing the same behavior on a small test table.

-- 1. Create a test table
CREATE TABLE gold.test_dropcreate_repro (
    id INT,
    name STRING,
    created_at TIMESTAMP
);

-- 2. Insert one row just to confirm things are working
INSERT INTO gold.test_dropcreate_repro
VALUES (1, 'test_row', current_timestamp);

-- 3. DROP
DROP TABLE gold.test_dropcreate_repro;

-- 4. Re-CREATE
CREATE TABLE gold.test_dropcreate_repro (
    id INT,
    name STRING,
    created_at TIMESTAMP
);

-- 5. Insert a row again
INSERT INTO gold.test_dropcreate_repro
VALUES (1, 'test_row', current_timestamp);

I ran this three times total, and the same mismatch reproduced twice out of three.

Trial	DROP-to-re-CREATE interval	Result	Errors observed
1	(short)	Not reproduced	None (data displayed normally)
2	(short)	Reproduced	"0 Rows" in Data Preview / base directory error on `REFRESH`
3	(short)	Reproduced	Error Code 091391 (UUID mismatch) in Data Preview / base directory error on `REFRESH`

Trial 1: Not reproduced

The first time I tried this sequence, nothing happened. Data Preview showed the data normally in Snowsight, and ALTER ICEBERG TABLE ... REFRESH didn't throw anything either.

Trial 2: Reproduced (data disappears)

Running the same sequence again, with a different DROP-to-CREATE interval, Data Preview showed "0 Rows": the data had disappeared.

Running ALTER ICEBERG TABLE ... REFRESH at that point produced the following error:

One of the specified Iceberg metadata files does not conform to the required directory hierarchy.
All files must reside as a strict subpath under the defined base directory.
Current base directory: s3://cccccccc-3333-4ccc-7777-cccccccccccc--table-s3/.
Conflicting file path: s3://dddddddd-4444-4ddd-6666-dddddddddddd--table-s3/metadata/00001-....metadata.json.

This matched the pattern from the production incident exactly: base directory was still pointing at the old table's warehouse location (cccccccc-...), while trying to reference the new table's metadata (dddddddd-...), and failing.

Trial 3: Reproduced (UUID mismatch error + base directory error)

Running the same sequence one more time, opening Data Preview in Snowsight this time produced a slightly different error.

Error Code: 091391
Message: SQL compilation error: The UUID of Iceberg table 'test_dropcreate_repro2' does not match
the table UUID in metadata file 's3://eeeeeeee-5555-4eee-9999-eeeeeeeeeeee--table-s3/metadata/00001-....metadata.json'.

On top of that, running ALTER ICEBERG TABLE ... REFRESH against this same table produced the same "base directory mismatch" error as Trial 2:

One of the specified Iceberg metadata files does not conform to the required directory hierarchy.
All files must reside as a strict subpath under the defined base directory.
Current base directory: s3://ffffffff-6666-4fff-8888-ffffffffffff--table-s3/.
Conflicting file path: s3://gggggggg-7777-4ggg-5555-gggggggggggg--table-s3/metadata/00001-....metadata.json.

So in Trial 3, both the "UUID mismatch error (091391)" and the "base directory mismatch error" showed up on the same table. I think this is direct evidence of the table-uuid mismatch detection mechanism from the docs actually firing. The two errors look different on the surface, but they appear to share the same root cause: the old table's warehouse location still being held as the base directory.

The docs state that when this mismatch is detected, the refresh fails and Snowflake drops the table from CLD. In my reproduction, though, the table was never actually dropped from CLD after this error occurred. It just stayed there, displayed, with the error persisting. This matches exactly what happened in production too: the table itself continued to exist in CLD the whole time, with the error simply recurring. I wasn't able to determine, within what I observed, exactly when or under what conditions the documented auto-drop behavior actually kicks in.

This reproduction experiment (3 trials, 2 reproductions) ended up directly supporting the hypothesis laid out above.

The condition described in the hypothesis, "CLD's discovery hadn't detected the DROP before the same-named table showed up," turned out, through the reproduction experiment, to not really be about the absolute length of the interval (whether it's 21 seconds or 30 seconds), but about the relative timing of whether a poll happens to land between the DROP and the CREATE.
The one out of three trials that didn't reproduce is likely explained by a CLD poll happening to land between the DROP and the CREATE, correctly detecting the deletion. This looks like classic race-condition behavior: the same steps don't necessarily give you the same result every time.
The table-uuid mismatch detection mechanism does genuinely exist, and depending on conditions, it can surface as this detection error (Error Code 091391).

So "leave a sufficiently long gap" as a mitigation is valid in the sense that a longer gap increases the odds of at least one poll landing in that window, but there's no absolute safe threshold, and it's more accurate to think of it as a way to reduce the probability of hitting this rather than eliminating it.

How I Recovered

Since this was a CLD setup, rather than manually recreating the individual table on the Snowflake side, I fixed it from the AWS side (S3 Tables/Glue Catalog). Specifically: DROP the table, wait significantly longer than CLD's sync interval (30 seconds), then re-CREATE it. I never explicitly ran ALTER ICEBERG TABLE or CREATE OR REPLACE ICEBERG TABLE from the Snowflake side.

Since CLD polls the namespace state periodically and reflects it automatically, as long as I left enough of a gap between the DROP and re-CREATE on the AWS side, Snowflake picked up the new table's entity on its own and settled back into a normal state. This doesn't prove that "a short interval was the cause," but it did serve as one supporting data point for the hypothesis (see the reproduction experiment above for more).

Things to Keep in Mind Going Forward

DROPing and re-CREATEing a table from the catalog side carries a real risk of this kind of mismatch, caused by the combination of S3 Tables regenerating the physical location and CLD's sync timing.
The reproduction experiment backed up the hypothesis: the real issue isn't the absolute length of the DROP-to-re-CREATE interval, but whether CLD's polling manages to detect the DROP before the re-CREATE completes.
Because of that, "leave a sufficient gap" helps in the sense that a longer gap raises the odds of a poll landing in between, but it's not a guaranteed-safe threshold, and that's worth keeping in mind.
Periodically checking $snapshots and $files to confirm consistency between a table's actual entity and what's registered in the catalog should make it faster to isolate this kind of issue if it comes up.

Conclusion

In this article, I walked through investigating a base directory mismatch I hit while referencing an S3 Tables table through Snowflake CLD, starting with metadata verification in Athena, moving to spec-checking against the official AWS docs, and finishing with pinning down the exact events in CloudTrail.

To summarize:

The two different UUIDs in the error message weren't from two different tables. They were the "old location" and "new location" of the same table, from a single DROP and re-CREATE.
I confirmed in the docs that S3 Tables generates a new, unique warehouse location every time a table is (re-)created.
CloudTrail's actual events confirmed the gap between the DROP completing and the re-CREATE completing was 21 seconds.
Snowflake CLD has two distinct kinds of sync, table discovery (SYNC_INTERVAL_SECONDS) and table metadata refresh (REFRESH_INTERVAL_SECONDS), both defaulting to 30 seconds. There's also a documented protection mechanism that detects table-uuid mismatches and drops the table from CLD.
My working theory is that this 21-second DROP-to-re-CREATE interval, being shorter than both default sync intervals (30 seconds), meant table discovery hadn't yet detected the deletion by the time the same-named table reappeared, leaving the old location info in place.
A reproduction experiment on a small test table (3 trials, 2 reproductions) directly backed up that hypothesis. The real issue isn't the absolute length of the interval, it's the relative timing of whether CLD's polling detects the DROP before the re-CREATE completes. This remains a hypothesis, but reproducing the same error multiple times gives it strong empirical support.

When you stack an external catalog integration (CLD) on top of an open format like S3 Tables, where a table's physical location can shift dynamically, there's still a black box in how the two catalogs stay in sync. Even a seemingly simple operation like DROP-and-re-CREATE can trigger an unexpected mismatch in a setup like this, which is worth keeping in mind operationally.

To be clear: this is something I observed in my own environment (Snowflake CLD + S3 Tables), and I'm not claiming it as a confirmed Snowflake bug.

I hope this is useful to anyone running S3 Tables together with Snowflake CLD.

Comparing AWS Glue Job's Default Mode and VPC Mode

Aki — Tue, 04 Aug 2026 13:56:41 +0000

Original Japanese article: Glue JobのDefaultモードとVPCモードを比較する

Introduction

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

When you use AWS Glue, it's pretty common to run Glue Jobs in default mode, without a VPC at all.

If your job only needs to reach AWS-managed services like S3 or the Glue Data Catalog, default mode gives you a simpler setup. On the other hand, if you need a more secure environment, or your requirements call for it, you might reach for VPC mode instead.

I'd always had a vague sense that "VPC mode is probably slower," but I'd never actually measured how much of a difference there is between Default mode and VPC mode.

In this article, I'll use a simple pipeline — reading from S3 (Raw) and writing into S3 Tables — as a test case, and actually run both connection modes to compare them.

Test Environment

I'm reusing the resources from a previous article.

Hitting the Iceberg REST Catalog Directly: Understanding the Differences Between Glue Data Catalog and S3 Tables

Table bucket: penguin-rest-test
Namespace: analytics
Table: daily_sales (two columns: sales_date, amount)
Raw data location: s3://penguin-raw-test/daily_sales/ (CSV)
Glue Job: PySpark, G.1X worker, a simple job that reads CSV from S3 and writes it into S3 Tables as Iceberg

Since this article focuses on network reachability (Default vs. VPC mode), I'm skipping the authorization layer (IAM/Lake Formation) setup here. I'm assuming the table bucket and namespace are already registered, and that the three-tier Catalog/Database/Table grants are already in place, following the steps from a previous article.

Test Architecture

Default Mode

A very simple setup. The job runs on AWS-managed infrastructure without touching your own VPC, so you don't need to think about subnets or security groups.

Reachable destinations are limited to AWS-provided service endpoints, but for a setup like this one — S3, Glue Data Catalog, and S3 Tables only — that's more than enough.

VPC Mode

The Glue Job creates an ENI inside a private subnet at runtime and reaches each service through a VPC endpoint. A Glue Connection is used to create an ENI (Elastic Network Interface) in the specified subnet, and all traffic goes through it.

You'd choose this mode when you need reachability to VPC-internal resources like RDS or Redshift, or when you want fine-grained traffic control via security groups and NACLs — in short, when you have stricter security requirements.

Access to the Glue Data Catalog is officially documented as going "through a local proxy by default." More precisely, this means the traffic is proxied through AWS's Glue-managed VPC to reach the Glue API — which implies there needs to be a network path between that Glue-managed VPC and your own VPC in the first place. In a private subnet setup with no NAT Gateway or Internet Gateway, that path simply doesn't exist, so the local proxy can't do its job and the connection times out. In that case, you need to create an Interface VPC Endpoint for com.amazonaws.<region>.glue. I actually confirmed this in testing — without a Glue endpoint in place, Iceberg's GlueCatalog implementation timed out.

A Note on ENIs: There Are Two Kinds

One thing worth calling out here is that there are two ENIs with very different characteristics involved:

The Interface VPC Endpoint's ENI: a persistent resource you provision ahead of time. It isn't recreated on every job run — it's billed continuously by the hour as a fixed cost.
The Glue Job's own ENI: created inside the subnet on every job run, via the Glue Connection. The network initialization this involves is the extra element unique to VPC mode.

Sample Code for Testing

The Glue Job I'm using here is a simple PySpark script that reads a CSV from S3 (Raw) and writes it into an Iceberg table on S3 Tables. The job code itself is identical between Default and VPC mode — the only thing that changes is the network path.

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ["JOB_NAME"])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# Read the CSV from S3 (Raw)
raw_df = spark.read.option("header", "true").csv(
    "s3://penguin-raw-test/daily_sales/"
)

raw_df = raw_df.selectExpr(
    "CAST(sales_date AS date) AS sales_date",
    "CAST(amount AS long) AS amount",
)

# Write into the S3 Tables Iceberg table (Glue-integrated)
# The catalog is configured ahead of time in Spark to point through s3tablescatalog
raw_df.writeTo("glue_catalog.analytics.daily_sales").append()

job.commit()

On the Spark configuration side (Job Parameters, or %%configure in a notebook), I'm passing --conf settings to point the Iceberg catalog at the Glue catalog via s3tablescatalog.

--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.glue_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.glue_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.glue_catalog.glue.id=123456789012:s3tablescatalog/penguin-rest-test
--conf spark.sql.catalog.glue_catalog.glue.account-id=123456789012
--conf spark.sql.catalog.glue_catalog.glue.region=ap-northeast-1
--conf spark.sql.catalog.glue_catalog.warehouse=s3://penguin-rest-test/
--conf spark.sql.defaultCatalog=glue_catalog

For a notebook session, you pass this as JSON via the %%configure magic:

%%configure
{
  "--conf": "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions --conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog --conf spark.sql.catalog.glue_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog --conf spark.sql.catalog.glue_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO --conf spark.sql.catalog.glue_catalog.glue.id=123456789012:s3tablescatalog/penguin-rest-test --conf spark.sql.catalog.glue_catalog.glue.account-id=123456789012 --conf spark.sql.catalog.glue_catalog.glue.region=ap-northeast-1 --conf spark.sql.catalog.glue_catalog.warehouse=s3://penguin-rest-test/ --conf spark.sql.defaultCatalog=glue_catalog",
  "--datalake-formats": "iceberg"
}

To run in VPC mode, you first need to create a Glue Connection. The ConnectionType is set to NETWORK. Unlike connection types for data stores such as JDBC, this one simply grants reachability to a subnet inside your VPC.

aws glue create-connection \
  --connection-input '{
    "Name": "penguin-vpc-connection",
    "ConnectionType": "NETWORK",
    "PhysicalConnectionRequirements": {
      "SubnetId": "subnet-xxxxxxxxxxxxxxxxx",
      "SecurityGroupIdList": ["sg-xxxxxxxxxxxxxxxxx"],
      "AvailabilityZone": "ap-northeast-1a"
    }
  }' \
  --region ap-northeast-1

On the Glue Job side, you just add this connection name under Connections to switch it into VPC mode. For the Default mode job, you leave Connections unset and use it as-is.

For measuring execution time, I use ExecutionTime, StartedOn, and CompletedOn from get_job_run. StartedOn is defined in the official API reference only as "the time at which this job run was started" — it doesn't specify whether that's the transition into the STARTING state or the RUNNING state.

ExecutionTime, on the other hand, is officially defined as "the amount of time the job run consumed resources," which means it can include internal Glue processing time — such as SparkContext initialization — in addition to the actual ETL processing done by user code.

If you want to isolate pure ETL processing time, you'll need to separately check the CloudWatch metric glue.driver.aggregate.elapsedTime (ETL elapsed time that excludes bootstrap time). For even finer-grained measurement, tracking JobRunState transitions (STARTING, RUNNING, SUCCEEDED) via EventBridge would be a more precise approach.

Execution Time Comparison Results

For both Default and VPC mode, I pulled the full job run history via get-job-runs and compared total execution time (StartedOn to CompletedOn), ExecutionTime, and overhead (total time minus ExecutionTime). After excluding values that deviated significantly from the rest of the same-mode results (discussed below), I ended up with 15 samples for each mode.

Mode	Total time (mean / min / max / stddev)	ExecutionTime (mean / min / max / stddev)	Overhead (mean / min / max / stddev)	n
Default	80.2s / 62.5s / 110.3s / 11.6s	73.1s / 58s / 98s / 9.7s	7.1s / 4.5s / 12.3s / 2.4s	15
VPC	97.9s / 69.0s / 133.5s / 19.0s	87.7s / 64s / 109s / 14.1s	10.1s / 5.0s / 24.5s / 6.6s	15

The mean differences were +17.7s for total time, +14.7s for ExecutionTime, and +3.0s for overhead — VPC mode came out larger on every metric. Even accounting for the standard deviations (11.6s for Default, 19.0s for VPC on total time), VPC mode was consistently higher across the sample range I collected.

The gap in standard deviation itself is also worth noting: VPC mode's stddev is about 1.6x Default's (19.0s vs. 11.6s). In other words, VPC mode isn't just slower on average — its execution time is also more variable. This suggests that ENI creation and Interface VPC Endpoint API calls may be introducing latency that fluctuates from run to run.

The excluded outliers were two Default runs (150s and 146s ExecutionTime) and one VPC run (177s). All three deviated clearly from the rest of the samples within their own mode, so I excluded them from the statistics. Concretely, Default's normal values topped out at 98s, while the outliers were 146–150s (roughly 1.5–1.6x); VPC's normal values topped out at 109s, while its outlier was 177s (roughly 1.6x). Both sets of outliers are clearly separated from the rest of their mode's values.

Going in, I'd expected ExecutionTime to be roughly the same between the two modes, with only the ENI-creation overhead being larger for VPC mode. What I actually found was that the overhead gap (+3.0s) supports the direction of that hypothesis, but doesn't fully explain the result on its own. The absolute gap is larger on the ExecutionTime side (+14.7s) — so "the difference is just overhead" doesn't hold up.

Why the Gap Isn't Fully Explained by Overhead Alone

As for why ENI creation isn't showing up as as large an overhead as I'd expected, I have a few hypotheses:

Hypothesis 1: ExecutionTime is defined as "the time the job run spent consuming resources." It's possible that ENI creation is counted within the ExecutionTime window itself, rather than in the StartedOn-to-ExecutionTime-start gap I'm calling "overhead." Given that the overhead gap is only +3.0s while the total-time gap is +17.7s, it would make sense if most of the ENI-creation cost is being attributed to ExecutionTime rather than overhead.
Hypothesis 2: Now that access to the Glue Data Catalog goes through an Interface VPC Endpoint instead of the local proxy, the catalog API calls themselves might be taking longer. That said, Interface VPC Endpoint API latency is generally on the order of single-digit to double-digit milliseconds, which feels too small to account for a 14.7-second gap on its own. It's conceivable that repeated catalog API calls add up, but I don't think this is strong enough evidence to call it the primary cause.
Hypothesis 3: A combination of factors specific to VPC mode — network initialization for the Glue execution environment, DNS resolution, and Interface VPC Endpoint-based service access — could be contributing together.

None of these has solid supporting evidence; the only things I can say for certain are the facts drawn from the measurements themselves. Across 15 samples per mode, VPC mode ran about 17.7 seconds longer on average in total, with roughly 14.7 seconds of that on the ExecutionTime side and about 3.0 seconds on the overhead side. Every hypothesis here is speculation drawn from that data — including whether ENI creation is even included in the ExecutionTime measurement window — and none of it is backed by official documentation. Measuring more granularly within the ExecutionTime window could help confirm or rule these out.

Choosing Between Default and VPC Mode

Cost Comparison

What VPC mode adds is the hourly cost of Interface VPC Endpoints (for Glue and for S3 Tables). Access to CloudWatch Logs continues to go through the local proxy even with --disable-proxy-v2 enabled, so no additional Interface VPC Endpoint is needed there. Access to the Glue Data Catalog, however, does need one — in a private subnet setup without a NAT Gateway or Internet Gateway, the local proxy has no path to the Glue-managed VPC and simply doesn't work (more on this below).

I checked the actual rate in the AWS Pricing Calculator for the Tokyo region (Amazon VPC → AWS PrivateLink), and an Interface VPC Endpoint comes out to $0.014 per endpoint, per AZ, per hour.

Glue endpoint (Interface):        1 AZ × $0.014/hour
S3 Tables endpoint (Interface):   1 AZ × $0.014/hour

2 endpoints × 1 AZ × $0.014/hour × 730 hours/month
= ~$20.44/month (single-AZ setup)

For a multi-AZ (2 AZ) setup:
2 endpoints × 2 AZ × $0.014/hour × 730 hours/month
= ~$40.88/month

On top of that, there's a data processing charge based on the volume passing through each endpoint (for the first PB per month, $0.01/GB). For a small data movement like this S3 Raw → S3 Tables job, that charge is negligible — most of the monthly cost comes from the hourly endpoint charge.

Default mode doesn't carry any of these fixed costs, so for a setup where everything is reachable via AWS public services, you're looking at roughly a $20–40/month cost difference (single-AZ to multi-AZ).

Item	Default mode	VPC mode
Interface VPC Endpoint (Glue)	Not needed	Needed (per AZ)
Interface VPC Endpoint (S3 Tables)	Not needed	Needed (per AZ)
Gateway VPC Endpoint (S3)	Not needed	Needed (free)
CloudWatch Logs traffic	Via AWS-managed network	Via local proxy (no endpoint needed)
Job startup overhead	None	ENI creation (on every run)

One thing worth noting: S3 Tables routes different kinds of operations through different endpoints. Table bucket, namespace, and table creation/deletion operations go through the dedicated S3 Tables endpoint (s3tables.<region>.amazonaws.com), while object-level operations — reading and writing data files and metadata files — go through the S3 endpoint (s3.<region>.amazonaws.com). This s3tables endpoint can't be substituted with the S3 Gateway Endpoint; it needs to be created separately as an Interface endpoint. AWS's own documentation recommends creating two separate VPC endpoints — one for S3, one for S3 Tables — when accessing S3 Tables, which is exactly what this setup does.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-id \
  --service-name com.amazonaws.ap-northeast-1.s3tables \
  --subnet-ids subnet-1 subnet-2 \
  --vpc-endpoint-type Interface \
  --ip-address-type dualstack \
  --dns-options "DnsRecordIpType=dualstack" \
  --security-group-ids sg-id \
  --region ap-northeast-1

For CloudWatch Logs, the documentation states that even with --disable-proxy-v2 enabled, traffic continues going through the local proxy — so no additional Interface VPC Endpoint is needed there.

Access to the Glue Data Catalog is a different story, though. The local proxy mechanism relies on proxying requests through the Glue-managed VPC to reach the Glue API — and in a private subnet setup without a NAT Gateway or Internet Gateway, there's no path between your VPC and that Glue-managed VPC, so the proxy simply doesn't function. I ran into this directly during testing: connections to glue.<region>.amazonaws.com timed out, and creating an Interface VPC Endpoint for Glue (com.amazonaws.<region>.glue) resolved it.

As for STS, in a basic setup like this one — without Lake Formation credential vending — I found no evidence that it's needed. So for a setup like this, the conclusion is that you need two Interface VPC Endpoints: one for Glue, one for S3 Tables.

Thinking in Terms of Responsibility

Default mode: hands off responsibility for network control to AWS. You can focus purely on IAM permissions and job logic.
VPC mode: you own network control yourself, all the way down to subnet design, security groups, and endpoint placement.

This mirrors a structure I laid out in an earlier article about where authorization responsibility sits across IAM, Lake Formation, and s3tables IAM actions. That same lens — where does the responsibility live — applies just as well to Glue's network configuration.

Thinking in Terms of Security Requirements

VPC mode becomes necessary mainly in two situations:

You need reachability to VPC-internal resources like RDS, Redshift, or on-prem systems
You have an explicit requirement to keep your traffic fully private end-to-end (audit or compliance requirements, for example)

Conversely, if everything you're reaching is an AWS public service — S3, Glue Data Catalog, S3 Tables — there's not much of a reason to actively reach for VPC mode.

For a setup like this one, where everything is contained within S3, Glue Data Catalog, and S3 Tables, I'd treat Default mode as the first thing to reach for.

That said, this isn't really a "VPC is safer" vs. "Default is simpler" kind of choice. What you're actually deciding is how much of the responsibility for network control you want to hold onto yourself, within whatever scope is genuinely necessary. If you have a clear reason to own that responsibility — reachability into VPC-internal resources, an audit requirement — go with VPC mode. Otherwise, it's reasonable to hand it off to AWS.

Other Notes

Security groups need a self-referencing rule: to allow communication between the Glue Spark driver and executors, the security group you specify needs an inbound rule that allows all TCP traffic from itself as the source. Without this, the job can start but internal communication will fail.
Overly restrictive outbound rules can break ENI creation: the security group needs to allow HTTPS to the Glue and S3 Tables Interface VPC Endpoints, so make sure port 443/TCP is open to those endpoints. It's safer to start permissive and tighten gradually.
A Glue endpoint is required in a private subnet without NAT: without a NAT Gateway or Internet Gateway, the local proxy for Glue Data Catalog access won't work, and connections to glue.<region>.amazonaws.com will time out. Creating an Interface VPC Endpoint for com.amazonaws.<region>.glue resolves this.
VPC DNS settings: to run in VPC mode, both enableDnsHostnames and enableDnsSupport need to be true on the VPC. If they're not, Glue will fail to resolve hostnames — worth checking ahead of time.
Verifying the Gateway Endpoint path: VPC Flow Logs alone aren't enough to confidently confirm that traffic is going through the Gateway Endpoint. Since Gateway endpoints resolve via prefix lists in the route table, checking the route table configuration directly is more reliable. In this environment's route table, I found an active route with a destination of pl-xxxxxxxx (the S3 prefix list) and a target pointing to the Gateway VPC Endpoint I'd created — confirming that S3-bound traffic does resolve through that endpoint.

Conclusion

In this article, I used an S3 (Raw) → S3 Tables pipeline as a test case to compare AWS Glue Job's Default mode and VPC mode with actual measurements.

To summarize:

Default mode reaches AWS public services over AWS-managed networking, without touching your own VPC.
VPC mode creates an ENI in a subnet via a Glue Connection and routes traffic through it. It's the right choice when you need reachability to VPC-internal resources or full control over your network path.
Under the conditions tested here (G.1X, a simple S3 → S3 Tables write, 15 samples per mode), VPC mode ran about 17.7 seconds longer on average in total execution time. Of that, roughly 14.7 seconds showed up on the ExecutionTime side and about 3.0 seconds on the overhead side — meaning the gap was larger on the ExecutionTime side than my original hypothesis (that the difference would come entirely from ENI-creation overhead) predicted, and overhead alone doesn't explain it.
VPC mode's cost has two distinct components: the ongoing hourly charge for Interface VPC Endpoints (fixed cost), and network-initialization latency incurred on every job run.
In terms of responsibility, Default mode is the simpler choice that hands network control to AWS, while VPC mode means taking on that control yourself, in exchange for meeting security requirements or reaching resources inside your VPC.

Network architecture decisions tend to stick around once you make them — there's rarely a natural point to revisit them later. Having actual numbers on hand for how much of a difference a choice like this makes should be useful the next time a similar decision comes up.

I hope this article is useful to anyone weighing network configuration options for their Glue Jobs.

Comparing the Permission Models of the Iceberg REST APIs Provided by Glue Data Catalog and S3 Tables

Aki — Tue, 28 Jul 2026 00:07:18 +0000

Original Japanese article: Glue Data CatalogとS3TablesのそれぞれのIceberg REST APIの権限モデルを比べてみる

Introduction

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

Across two previous articles, I hit the Iceberg REST Catalog directly and compared the design of the Glue endpoint and the S3 Tables endpoint:

Both of those took the angle of "looking at the same table through two different entry points." This time I wanted to try a different angle: laying the official per-operation permission mapping tables for both endpoints side by side.

For both endpoints, AWS publishes a table mapping each Iceberg REST operation to its IAM action, its Lake Formation permission, and its CloudTrail event name. Just placing these two tables next to each other turned up some interesting findings and design differences, which I've summarized below.

This time, rather than hands-on testing like before, this is a documentation-based comparison. Wherever something lines up with what I actually verified in the previous articles, I've noted that explicitly.

The official documentation I referenced:

Glue side: https://docs.aws.amazon.com/glue/latest/dg/iceberg-rest-apis.html
S3 Tables side: https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-open-source.html

Lining Up the Permission Mapping by Operation

Operation	Glue: IAM action	Glue: LF permission	S3 Tables: IAM action
getConfig	`glue:GetCatalog`	Not required	`s3tables:GetTableBucket`
listNamespaces	`glue:GetDatabase`	ALL, DESCRIBE, SELECT	`s3tables:ListNamespaces`
createNamespace	`glue:CreateDatabase`	ALL, DESCRIBE, SELECT	`s3tables:CreateNamespace`
loadNamespaceMetadata	`glue:GetDatabase`	ALL, DESCRIBE, SELECT	`s3tables:GetNamespace`
updateNamespaceProperties	`glue:UpdateDatabase`	ALL, ALTER	(not listed)
dropNamespace	`glue:DeleteDatabase`	ALL, DROP	`s3tables:DeleteNamespace`
namespaceExists	(not listed)	-	`s3tables:GetNamespace`
listTables	`glue:GetTables`	ALL, SELECT, DESCRIBE	`s3tables:ListTables`
createTable	`glue:CreateTable`	ALL, CREATE_TABLE	`s3tables:CreateTable` + `s3tables:PutTableData`
loadTable	`glue:GetTable`	ALL, SELECT, DESCRIBE	`s3tables:GetTableMetadataLocation` + `s3tables:GetTableData`
updateTable	`glue:UpdateTable`	ALL, ALTER	`s3tables:UpdateTableMetadataLocation` + `s3tables:PutTableData` + `s3tables:GetTableData`
dropTable	`glue:DeleteTable`	ALL, DROP	`s3tables:DeleteTable`
renameTable	(not listed; only possible via the extension API's UpdateTable)	-	`s3tables:RenameTable`
tableExists	`glue:GetTable`	ALL, SELECT, DESCRIBE	`s3tables:GetTable`

Even just laying these side by side surfaces several differences.

The Number of IAM Actions Differs for Data Operations

The first thing that jumps out is here. For operations that touch data, such as loadTable, createTable, and updateTable, the number of IAM actions required differs between the two.

The Glue endpoint's loadTable needs only one action, glue:GetTable, while the S3 Tables endpoint's loadTable needs two: s3tables:GetTableMetadataLocation and s3tables:GetTableData. createTable and updateTable show the same pattern: the S3 Tables side splits requirements into a "metadata operation action" and a "data body operation action."

This lines up with something I confirmed in a previous article: calling S3 Tables' LoadTable logs a GetTableMetadataLocation management event in CloudTrail.

What this suggests is that S3 Tables cleanly separates access to metadata from access to the data body at the API level, while the Glue endpoint consolidates everything into the single glue:GetTable action and delegates the actual storage access to Lake Formation's vended credentials. That, I think, is the design difference at play here.

Note

The s3tables:CreateTable + s3tables:PutTableData pair shown above is specifically the permission set for the createTable operation as defined in the Iceberg REST API reference (s3-tables-integrating-open-source.html). A separate official document on SQL semantics (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-sql.html) states that the CreateTable API only creates an empty table inside the table bucket, and that setting the schema requires two more actions, UpdateTableMetadataLocation and GetTableMetadataLocation, for four in total.

In other words, "the API call that creates the table" and "actually getting a usable table with a schema set" require different numbers of permissions. If you only look at the REST API's permission table and assume two actions are enough, you can get tripped up during schema setup.

The renameTable / namespaceExists Difference

The next difference: renameTable appears in S3 Tables' list of supported APIs but not in Glue's.

Glue's official documentation has no independent renameTable operation. Instead, a note on the AWS Glue extension API's (/extensions/v1/...) StartUpdateTableTransaction says: "A rename operation can also be performed through this API. In that case, the caller must also have glue:CreateTable or the Lake Formation CREATE_TABLE permission for the destination table." So on the Glue side, renaming isn't its own operation; it's treated as a kind of update transaction.

namespaceExists, meanwhile, exists as its own operation on the S3 Tables side (HEAD /v1/{prefix}/namespaces/{namespace}), but I couldn't find it anywhere in Glue's list of standard Iceberg REST Catalog API operations. Even though both implement the same Iceberg REST spec, the design decision of "what gets carved out as its own API" clearly differs.

The updateNamespaceProperties Difference

updateNamespaceProperties existing only on the Glue side is another difference worth calling out. Glue has a clearly defined updateNamespaceProperties operation with the IAM action glue:UpdateDatabase, but this operation doesn't exist at all in S3 Tables' list of operations. S3 Tables' documented limitations say "only the owner property is supported for namespaces," but there's no corresponding independent operation listed in the official operations table.

This might get added in a future update, but as things stand, it's another point of difference between the two.

The dropTable purge Behavior Difference

According to the official documentation, S3 Tables' dropTable returns a 400 Bad Request if you specify purge=false, meaning purge must be true. Glue's DeleteTable (for tables on S3), on the other hand, is documented as failing the operation and not deleting the data if you specify purge=true.

Same "delete the table" operation, but the required value of purge looks like it's flipped between the two according to the docs.

This looked like a likely source of mistakes, so I decided to actually check it hands-on. Testing it turned up something interesting.

I tried it first against the S3 Tables endpoint.

S3 Tables' purge Behavior

I created a table, then called dropTable with no parameters at all:

python -m awscurl --service s3tables --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces/analytics/tables/purge_test"

Result (excerpt):

{
  "error": {
    "code": 400,
    "message": "DropTable operation failed. S3 Tables only supports dropping tables with purge enabled.",
    "type": "purge_enabled"
  }
}

As documented, this returned 400, and the table stayed in the listing.

Next, I re-ran it with the query parameter purge=true and got the exact same error. It turns out that, per the Iceberg REST Catalog spec, the query parameter for specifying purge on dropTable isn't purge; it's purgeRequested.

python -m awscurl --service s3tables --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces/analytics/tables/purge_test?purgeRequested=true"

This one succeeded with no response body, and I confirmed via the listing that the table had actually been deleted.

Note

The gist of "purge must be true" was correct per the documentation, but assuming the query parameter is named purge will trip you up. It's actually purgeRequested.

If you use both endpoints together, this alone is fertile ground for implementation mistakes.

Glue Data Catalog's purge Behavior

I then ran the same test on the Glue side.

My test environment has the Glue endpoint reaching S3 Tables-backed tables through the s3tablescatalog federated catalog. So I first called DeleteTable against this table via the Glue endpoint with purgeRequested=true specified, and it succeeded without any fuss.

python -m awscurl --service glue --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012:s3tablescatalog:penguin-rest-test/namespaces/analytics/tables/purge_test_glue?purgeRequested=true"

This contradicts the official documentation's claim that "Glue's DeleteTable fails if purge=true." So I set up another table and tried deleting it via Glue without specifying purgeRequested at all.

python -m awscurl --service glue --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012:s3tablescatalog:penguin-rest-test/namespaces/analytics/tables/purge_test_glue2"

Result (excerpt):

{
  "error": {
    "code": 400,
    "message": "PurgeRequested must be true for S3 federated iceberg tables.",
    "type": "InvalidInputException"
  }
}

The error message spells it out clearly: "S3 federated iceberg tables." So the Glue endpoint internally distinguishes whether a table's underlying entity is S3 Tables-backed (federated), and in that case it demands purgeRequested=true.

This tells us that the purge behavior of DeleteTable isn't determined by which endpoint you're hitting (Glue or S3 Tables). What determines it is the underlying entity of the table: whether the backend is an S3 Tables-federated table or a plain table on a general-purpose S3 bucket.

The documentation's statement that "Glue's DeleteTable fails for S3-backed tables if purge=true" is presumably describing a genuinely Glue-native Iceberg table on a general-purpose S3 bucket. For a table backed by S3 Tables, even when accessed through Glue, S3 Tables' own constraint (purgeRequested=true required) appears to pass straight through.

To test this hypothesis, I created an Iceberg table on a general-purpose S3 bucket via Athena and ran the same test through the Glue endpoint.

First, deleting without specifying purgeRequested succeeded:

python -m awscurl --service glue --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012/namespaces/general_iceberg_db/tables/purge_test_general"

Then, on a second table, specifying purgeRequested=true failed:

python -m awscurl --service glue --region ap-northeast-1 --profile your-profile \
  -X DELETE \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012/namespaces/general_iceberg_db/tables/purge_test_general2?purgeRequested=true"

Result (excerpt):

{
  "error": {
    "code": 400,
    "message": "PurgeRequested cannot be true for Glue iceberg tables.",
    "type": "InvalidInputException"
  }
}

This mirrors the earlier error for the S3 Tables-backed table (PurgeRequested must be true for S3 federated iceberg tables.) almost perfectly. AWS itself clearly distinguishes "Glue iceberg tables" from "S3 federated iceberg tables" in its code, and imposes opposite purgeRequested requirements on each.

Summary of purge Behavior for Each

Here's the full result across all four cases tested:

Table entity	Without `purgeRequested`	With `purgeRequested=true`
S3 Tables-backed (via Glue endpoint)	400 "PurgeRequested must be true for S3 federated iceberg tables"	Success
S3 Tables-backed (direct S3 Tables endpoint)	400 "S3 Tables only supports dropping tables with purge enabled"	Success
General-purpose S3, Glue-native table (via Glue endpoint)	Success	400 "PurgeRequested cannot be true for Glue iceberg tables"

Both failure cases without purgeRequested return the same status code, 400. The nature of the error is consistent regardless of which endpoint you hit; the only difference is what the message says caused the failure.

It's not the entry point (Glue endpoint vs. S3 Tables endpoint) that decides the purgeRequested requirement; it's the underlying table entity (Glue Iceberg Tables vs. S3 Federated Iceberg Tables). Both the hands-on results and the error messages back this up.

I'd honestly prefer they picked one convention and stuck with it...

CloudTrail Granularity Also Reflects the API Design Split

S3 Tables' official documentation states clearly that "LoadTable generates a GetTableMetadataLocation management event and a GetTableData data event." This lines up with the IAM action split described above. S3 Tables appears to be designed to separate "metadata" from "the data body" at the audit-log level too.

On the Glue side, the official documentation shows each operation's CloudTrail event name matching its IAM action name (glue:GetTable logs as glue:GetTable), with no split like the one seen on S3 Tables. That said, as I confirmed hands-on in a previous article, when the Glue endpoint calls Lake Formation's GetDataAccess, that gets logged separately as its own event. It seems Glue's audit trail is split across two distinct lineages: "the log of the API operation itself" and "the Lake Formation authorization log."

Conclusion

This time, taking a different approach from the hands-on investigations I've done so far, I laid the official documentation-based permission mapping tables for Glue Data Catalog's and S3 Tables' respective Iceberg REST APIs side by side.

To summarize:

Granularity of data-operation permissions: Glue consolidates each operation into a single IAM action, while S3 Tables splits metadata and data-body actions apart (createTable needs only two actions as a REST operation, but per the SQL semantics documentation, actually getting a usable table with a schema set requires four).
Rename operations: Glue has no independent API for this; it's handled as part of an update transaction. S3 Tables has its own dedicated renameTable operation.
namespaceExists: exists on the S3 Tables side but not in Glue's standard API list.
updateNamespaceProperties: exists on the Glue side but has no corresponding operation on S3 Tables (only the owner property is supported, in a limited way).
dropTable's purge behavior: the query parameter is purgeRequested, not purge. Whether purge is required turns out to be determined not by "Glue endpoint vs. S3 Tables endpoint" but by the table's underlying entity (S3 Tables-federated vs. Glue-native on general-purpose S3), and the requirement is the exact opposite in each case, which I confirmed hands-on across all four scenarios.
CloudTrail granularity: S3 Tables logs separate events for metadata operations and data operations, while Glue logs one event per operation, with Lake Formation evaluation showing up as a separate lineage.

Even though both implement the same Iceberg REST Catalog spec, it turns out the granularity of the permission model and the design decisions around what gets carved out as an independent API differ quite a bit between Glue and S3 Tables. I think this is the same structural difference I touched on in earlier articles, Glue as a catalog hub and S3 Tables as a thin translation layer over storage, showing up consistently even at the level of permission mapping tables.

Comparing hands-on results against the documentation turns up things you'd miss looking at either one alone, so I'd like to keep doing this kind of exercise going forward.

I hope this article is useful to anyone choosing between the two endpoints.

Connecting Amazon S3 Tables with Snowflake

Aki — Tue, 21 Jul 2026 00:06:40 +0000

Original Japanese article: Amazon S3 TablesとSnowflakeを連携する

Introduction

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

In a previous article, I introduced how to connect an Iceberg table built on a general purpose S3 bucket with Snowflake.

AWS Snowflake Lakehouse: 2 Practical Apache Iceberg Integration Patterns

This time, as a follow up, I'm going to read and write an Iceberg table on S3 Tables from Snowflake, since I've had more chances to use S3 Tables recently.

There were a few points that tripped me up along the way, so I put this together along with some personal reflections. Hope it's useful!

Test Environment

I'm reusing the same resources as in the previous article.

Verifying How IAM and Lake Formation Behave for the Glue REST Catalog and S3 Tables

Table bucket: penguin-rest-test
Namespace: analytics
Table: daily_sales (two columns, sales_date and amount)
Glue integration: enabled (mounted as s3tablescatalog/penguin-rest-test)

Read the account ID as 123456789012 throughout.

Reading S3 Tables Data from Snowflake

Creating the IAM Role

I'll create a role that lets Snowflake access S3 Tables through the Glue Iceberg REST endpoint.

I'm reusing the IAM actions from the previous article that were required for access through the Glue endpoint (s3tables:*, lakeformation:GetDataAccess, and the glue:GetCatalog family), and defining them as the policy for the catalog integration role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3TablesAccess",
            "Effect": "Allow",
            "Action": [
                "s3tables:ListTableBuckets",
                "s3tables:GetTableBucket",
                "s3tables:GetNamespace",
                "s3tables:ListNamespaces",
                "s3tables:GetTable",
                "s3tables:ListTables",
                "s3tables:GetTableMetadataLocation",
                "s3tables:UpdateTableMetadataLocation",
                "s3tables:GetTableData",
                "s3tables:PutTableData"
            ],
            "Resource": "*"
        },
        {
            "Sid": "LakeFormationAccess",
            "Effect": "Allow",
            "Action": "lakeformation:GetDataAccess",
            "Resource": "*"
        },
        {
            "Sid": "GlueS3TablesCatalogAccess",
            "Effect": "Allow",
            "Action": [
                "glue:GetCatalog",
                "glue:GetCatalogs",
                "glue:GetPartitions",
                "glue:GetPartition",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:GetTable",
                "glue:GetTables",
                "glue:UpdateTable"
            ],
            "Resource": [
                "arn:aws:glue:*:123456789012:catalog",
                "arn:aws:glue:*:123456789012:catalog/*",
                "arn:aws:glue:*:123456789012:database/*",
                "arn:aws:glue:*:123456789012:table/*/*"
            ]
        }
    ]
}

Alongside the read actions (GetTable, GetTableData, and so on), I've also included the write actions s3tables:PutTableData and glue:UpdateTable up front. Granting write permissions here means writes will also be possible once the integration is set up.

Creating the CATALOG INTEGRATION

On the Snowflake side, I'll create a catalog integration that connects to the Iceberg REST Catalog (AWS's Glue implementation).

CREATE OR REPLACE CATALOG INTEGRATION penguin_catalog_integration
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  CATALOG_NAMESPACE = 'analytics'
  REST_CONFIG = (
    CATALOG_URI = 'https://glue.ap-northeast-1.amazonaws.com/iceberg'
    CATALOG_API_TYPE = AWS_GLUE
    CATALOG_NAME = '123456789012:s3tablescatalog/penguin-rest-test'
    ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS
  )
  REST_AUTHENTICATION = (
    TYPE = SIGV4
    SIGV4_IAM_ROLE = 'arn:aws:iam::123456789012:role/Snowflake_Catalog_Integration'
    SIGV4_SIGNING_REGION = 'ap-northeast-1'
  )
  ENABLED = TRUE;

You can see that CATALOG_URI is the exact same Glue Iceberg REST endpoint I was hitting directly in the previous article.

CATALOG_NAME takes the nested catalog's prefix notation (account ID:s3tablescatalog/bucket name). This mixes colon and slash separators, matching the same --catalog-id format I confirmed against Glue's native API in the previous article.

Since I've specified ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS, Snowflake operates by receiving vended credentials issued from the Glue endpoint.

DESC CATALOG INTEGRATION

Once you create the catalog integration, Snowflake issues an IAM user ARN and an external ID for it to assume on the AWS side.

DESC CATALOG INTEGRATION penguin_catalog_integration;

Two properties, API_AWS_IAM_USER_ARN and API_AWS_EXTERNAL_ID, come back in the result. Keep these on hand.

Setting Up the Trust Policy

On the trust policy of the role specified in SIGV4_IAM_ROLE (Snowflake_Catalog_Integration), allow the Snowflake side IAM user obtained from DESC CATALOG INTEGRATION above, along with its external ID.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::999999999999:user/xxxx1000-s"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "SFCRole=2_(masked)"
                }
            }
        }
    ]
}

Principal is an IAM user that belongs to an AWS account managed by Snowflake. Attaching the sts:ExternalId condition prevents AssumeRole calls from anything other than this specific catalog integration on Snowflake's side. At this point, Snowflake can assume the role and use the IAM side permissions.

Note

The IAM policy body and the trust policy are two separate things. Even if you've included s3tables:PutTableData in the IAM policy, if the trust policy isn't set up correctly, the role can't be assumed and the catalog integration won't work. Check both.

Registering the Lake Formation Data Location

Separately from the trust policy, you also need to register this table bucket as a data lake location on the Lake Formation side.

This is the same idea as register-resource --with-federation that I covered in a previous article. Without this step, Lake Formation can't perform permission evaluation or issue vended credentials for this resource in the first place.

Registration requires an IAM role (a data access role) that can actually reach the target S3 location. This time I created a role named penguin-lakeformation-role.

The permission policy grants metadata reads via Glue, plus full access to S3 Tables tables and namespaces (read/write, along with Create/Delete/Rename operations).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetCatalog",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:GetTable",
                "glue:GetTables",
                "glue:GetPartitions"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ListBuckets",
            "Effect": "Allow",
            "Action": ["s3tables:ListTableBuckets"],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3tables:GetTableBucket",
                "s3tables:GetNamespace",
                "s3tables:ListNamespaces",
                "s3tables:GetTable",
                "s3tables:ListTables",
                "s3tables:GetTableMetadataLocation",
                "s3tables:UpdateTableMetadataLocation",
                "s3tables:GetTableData",
                "s3tables:PutTableData",
                "s3tables:CreateTable",
                "s3tables:DeleteTable",
                "s3tables:RenameTable",
                "s3tables:CreateNamespace",
                "s3tables:DeleteNamespace"
            ],
            "Resource": [
                "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/*"
            ]
        }
    ]
}

The trust policy allows AssumeRole from lakeformation.amazonaws.com, but it turned out I needed to allow not just sts:AssumeRole but also sts:SetSourceIdentity and sts:SetContext alongside it. I've also restricted calls to my own account with the aws:SourceAccount condition.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lakeformation.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:SetContext"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                }
            }
        }
    ]
}

With this role specified, register the table bucket as a federated Lake Formation resource.

aws lakeformation register-resource \
  --resource-arn "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/*" \
  --with-federation \
  --with-privileged-access \
  --role-arn arn:aws:iam::123456789012:role/penguin-lakeformation-role \
  --region ap-northeast-1

Specifying a wildcard (bucket/*) for --resource-arn also lets you skip having to re-register each table bucket individually.

Note: if you want more flexible control, such as registering table buckets individually with different settings per bucket, you'll need to specify each one separately.

If this location registration is missing, permission evaluation won't work correctly at actual access time, even if the IAM policy, trust policy, and Lake Formation grants are all set up correctly. By the way, S3 Tables location registration can't be done from the console, so command line operation is required here.

Note: I really wish this could be registered and edited from the console...

Lake Formation Grants (Three Tiers: Catalog, Database, Table)

Grant permissions to the Snowflake_Catalog_Integration role at each of the three tiers, Catalog, Database, and Table.

# Catalog tier
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/Snowflake_Catalog_Integration \
  --resource '{"Catalog":{"Id":"123456789012:s3tablescatalog/penguin-rest-test"}}' \
  --permissions "ALL DESCRIBE" \
  --permissions-with-grant-option "ALL DESCRIBE" \
  --region ap-northeast-1

# Database tier
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/Snowflake_Catalog_Integration \
  --resource '{"Database":{"CatalogId":"123456789012:s3tablescatalog/penguin-rest-test","Name":"analytics"}}' \
  --permissions "ALL CREATE_TABLE DESCRIBE" \
  --permissions-with-grant-option ALL CREATE_TABLE DESCRIBE \
  --region ap-northeast-1

# Table tier
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/Snowflake_Catalog_Integration \
  --resource '{"Table":{"CatalogId":"123456789012:s3tablescatalog/penguin-rest-test","DatabaseName":"analytics","Name":"daily_sales"}}' \
  --permissions "ALL" \
  --permissions-with-grant-option ALL \
  --region ap-northeast-1

CREATE OR REPLACE ICEBERG TABLE

With the catalog integration ready, register the Iceberg table individually on the Snowflake side.

CREATE OR REPLACE ICEBERG TABLE GOLD.GOLD.s3tables_table
  CATALOG = 'penguin_catalog_integration'
  CATALOG_NAMESPACE  = 'analytics'
  CATALOG_TABLE_NAME = 'daily_sales'
  AUTO_REFRESH       = TRUE
;

CATALOG_NAMESPACE and CATALOG_TABLE_NAME explicitly specify the namespace and table name on the S3 Tables side. This is the key point of this approach: you have to run this statement once for every single table you register. When a new table shows up on the S3 Tables side, it doesn't automatically appear on the Snowflake side.

Verification

I'll insert data into the Iceberg table from the Athena side and check whether it shows up from Snowflake.

-- Athena side
INSERT INTO "analytics"."daily_sales" (sales_date, amount)
VALUES
    (CAST('2025-01-01' AS DATE), CAST(10000 AS BIGINT)),
    (CAST('2025-01-02' AS DATE), CAST(15000 AS BIGINT)),
    (CAST('2025-01-03' AS DATE), CAST(12000 AS BIGINT)),
    (CAST('2025-01-04' AS DATE), CAST(18000 AS BIGINT)),
    (CAST('2025-01-05' AS DATE), CAST(20000 AS BIGINT));

After refreshing the table on the Snowflake side and running a SELECT, the data I'd inserted from Athena showed up without any issues!

ALTER ICEBERG TABLE GOLD.GOLD.s3tables_table REFRESH;
SELECT * FROM GOLD.GOLD.s3tables_table;

Using a Catalog-Linked Database

With the CREATE ICEBERG TABLE approach, I had to register tables one at a time by hand. Using a Catalog-Linked Database (CLD) lets you link an entire namespace (database) at once instead.

CREATE OR REPLACE DATABASE LINKED_DB
  LINKED_CATALOG = (
    CATALOG = 'penguin_catalog_integration'
  );

The moment I created it, daily_sales, which already existed under the analytics namespace, showed up in the table list automatically, with no DDL needed.

Verification (Auto Detection)

To confirm that auto detection actually works, let's create a new table from the AWS side.

-- Athena side
CREATE TABLE `analytics`.daily_sales2 (
  sale_date date,
  product_category string,
  sales_amount double)
PARTITIONED BY (month(sale_date))
TBLPROPERTIES ('table_type' = 'iceberg')

After the CREATE, checking Snowsight showed the newly created table had been added automatically!

Unlike the CREATE ICEBERG TABLE approach, there's no need to write DDL for each table. I confirmed that changes on the AWS side are reflected directly on the Snowflake side.

Writing from Snowflake

Up to this point, data had only flowed one way, from AWS to Snowflake. Let's also check whether data inserted from the Snowflake side shows up on the AWS side (Athena).

The Individually Added Table

First, let's write to the table that was added individually with CREATE ICEBERG TABLE.

INSERT INTO GOLD.GOLD.S3TABLES_TABLE (SALES_DATE, AMOUNT)
VALUES
    ('2026-07-16', 10000),
    ('2026-07-16', 15000),
    ('2026-07-16', 12000);

Let's check on the AWS side (Athena).

SELECT * FROM "analytics"."daily_sales" ORDER BY sales_date DESC limit 10;

The data I inserted from Snowflake showed up on the Athena side too, no problem! Even for an individually added table, reads and writes work in both directions.

Catalog-Linked Database

Next, let's write to daily_sales2, the table that was auto detected through the Catalog-Linked Database.

INSERT INTO LINKED_DB.analytics.daily_sales2 (sale_date, product_category, sales_amount)
VALUES
    ('2024-01-01', 'Electronics', 1500.00),
    ('2024-01-01', 'Clothing', 800.50),
    ('2024-01-02', 'Electronics', 2100.75),
    ('2024-01-02', 'Clothing', 950.25),
    ('2024-01-03', 'Food', 1200.00);

Let's check on the AWS side (Athena).

SELECT * FROM "analytics"."daily_sales2" limit 10;

This one wrote through without any issues too!

CREATE OR REPLACE ICEBERG TABLE vs. Catalog-Linked Database: Which to Use

Having actually tried both, here's how I'd sum up the comparison.

Approach	Table Registration	Auto Detection	Good Fit For
CATALOG INTEGRATION + CREATE ICEBERG TABLE	Manual, one at a time	None	Validation/PoC work, or when you only want to expose a small, specific set of tables
CATALOG INTEGRATION + Catalog-Linked Database	Automatic	Yes (tables on the Glue side show up automatically)	Production use where tables on the Glue/S3 Tables side keep getting added or changed

The CREATE ICEBERG TABLE approach lets you explicitly control which tables get exposed to Snowflake, but it comes with the cost of DDL maintenance every time a table is added. CLD removes that syncing overhead, but since essentially all tables under a namespace become visible, you'll want to design your permissions more carefully if you need to control the scope of what's exposed.

I confirmed this time that both approaches support bidirectional reads and writes, from Snowflake to the AWS side and from the AWS side to Snowflake.

What About a General Purpose Bucket?

Everything up to this point assumed S3 Tables (a table bucket). Reading and writing an Iceberg table on a general purpose S3 bucket from Snowflake comes with a slightly different set of constraints.

Combining this with the External Volume setup I touched on previously, here's how things currently stand.

Configuration	Read	Write
CATALOG INTEGRATION (`CATALOG_SOURCE = GLUE`) + External Volume	Yes	No
CATALOG INTEGRATION (`CATALOG_SOURCE = ICEBERG_REST`) + External Volume	Yes	Yes
CATALOG INTEGRATION (`CATALOG_SOURCE = ICEBERG_REST`) + Vended Credentials	Yes	Yes
CATALOG INTEGRATION + Catalog-Linked Database (REST)	Yes	Yes

Only the combination of CATALOG_SOURCE = GLUE (the legacy approach that uses the Glue Data Catalog API directly, rather than going through Iceberg REST) with External Volume ends up read only. Snowflake's own documentation explicitly states that tables created this way are treated as read only, as an "Externally Managed Iceberg Table." If you want to be able to write, it looks like choosing CATALOG_SOURCE = ICEBERG_REST is a prerequisite.

The S3 Tables configuration I tested this time (CATALOG_SOURCE = ICEBERG_REST with Vended Credentials) falls into the row that supports both reads and writes. That said, actually getting writes working required all three layers of permissions I've laid out here (IAM, Lake Formation, and the S3 Tables bucket policy) to be in place, and that was the real takeaway from this round of testing.

Conclusion

In this article, I actually built out reading and writing an Iceberg table on S3 Tables from Snowflake's Catalog Integration, and worked through the permissions issues I ran into along the way.

To summarize:

To access S3 Tables from Snowflake through the Glue Iceberg REST endpoint, you need all of the following in place: the IAM policy, the trust policy, the Lake Formation data location registration (register-resource with --with-federation --with-privileged-access and a dedicated data access role), the Lake Formation grants across the three tiers (Catalog, Database, and Table), and the S3 Tables table bucket policy.
The data access role's trust policy needs to allow not just sts:AssumeRole but also sts:SetSourceIdentity and sts:SetContext.
S3 Tables location registration can't be done from the console, and requires command line operations.
CREATE ICEBERG TABLE registers tables one at a time by hand, while Catalog-Linked Database auto detects at the namespace level. The underlying permission model is the same either way, the difference is purely in the registration effort.
I confirmed that both approaches support bidirectional reads and writes, from AWS to Snowflake and from Snowflake to AWS.
For an Iceberg table on a general purpose S3 bucket, only the CATALOG_SOURCE = GLUE plus External Volume combination is read only. Getting writes to work requires CATALOG_SOURCE = ICEBERG_REST.

Error messages around permissions, things like "Insufficient permissions" or "Access Denied," don't tell you on their own which layer, IAM, Lake Formation, or a resource policy, is actually blocking things. Untangling that meant tracing the actual events in CloudTrail one by one.

Lake Formation is also an important service for maintaining governance when integrating with Snowflake. It's a bit of a quirky service the first time you work with it, so I'd recommend reading through the documentation before diving in.

Note: I work with it fairly often myself, and I still trip up on it every single time...

I hope this article is useful to anyone considering connecting S3 Tables and Snowflake.

Verifying How IAM and Lake Formation Behave for the Glue REST Catalog and S3 Tables

Aki — Mon, 13 Jul 2026 22:07:59 +0000

Original Japanese article: Glue REST CatalogとS3TablesのIAMとLake Formationの挙動を確かめる

Introduction

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

In my previous article, I hit the Iceberg REST Catalog directly and confirmed the design differences between the Glue endpoint and the S3 Tables endpoint.

In that article I wrote that "accessing through the Glue endpoint requires a Lake Formation grant." This time, I'll deliberately vary the IAM policy and the Lake Formation grant to see exactly how the behavior of each endpoint changes.

Along the way, I'll also check whether GetDataAccess is actually being called via CloudTrail, to peek inside the authorization flow itself.

I previously wrote about the design differences between the Glue and S3 Tables Iceberg REST endpoints in another article, worth a read alongside this one: Hitting the Iceberg REST Catalog Directly: Understanding the Differences Between Glue Data Catalog and S3 Tables

What We're Verifying Today

According to AWS documentation, the Glue REST Catalog is authorized through a combination of IAM policy and Lake Formation grants, while the S3 Tables REST endpoint is authorized through IAM alone.

Glue endpoint: IAM authorization → Lake Formation authorization
S3 Tables endpoint: s3tables IAM authorization only

Let's verify how this actually plays out, using the following matrix:

Condition	Glue endpoint	S3 Tables endpoint
IAM ✓ / LF ✓	200 (baseline)	200 (baseline)
IAM ✓ / LF ✗	?	?
IAM ✗ / LF ✓	?	?

The IAM ✓ / LF ✗ cell is especially important:

If only the Glue endpoint returns 403 → Glue is genuinely enforcing Lake Formation authorization
If only the S3 Tables endpoint returns 200 → that confirms the difference in authorization flow

After each cell, I'll also check whether lakeformation:GetDataAccess was called via CloudTrail, to visualize the internal authorization flow.

Test Environment Setup

I'm reusing the resources created in the previous article.

Table bucket: penguin-rest-test
Namespace: analytics
Table: daily_sales
Glue integration: enabled
register-resource --with-federation: already configured (vended credentials are issued)

Note

In this test, when using Glue REST Catalog's federation, the Lake Formation permission-evaluation target was the IAM role used to vend credentials. This can be confirmed from the CloudTrail GetDataAccess event, where the session that assumed that IAM role is recorded as the userIdentity.

"IAM ✓" state: the test IAM user has the following policy attached.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["glue:GetCatalog", "glue:GetDatabase", "glue:GetTable"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTableBucket", "s3tables:GetNamespace", "s3tables:GetTable",
        "s3tables:GetTableData", "s3tables:GetTableMetadataLocation"
      ],
      "Resource": [
        "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test",
        "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test/table/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["lakeformation:GetDataAccess"],
      "Resource": "*"
    }
  ]
}

"LF ✓" state: the IAM role used to vend credentials (penguin-irc-test-role) has the following Lake Formation grants.

Database (analytics): DESCRIBE
Table (daily_sales): SELECT, DESCRIBE

IAM ✓ / LF ✓ (Baseline State)

Glue Endpoint

awscurl --service glue --region ap-northeast-1 --profile penguin-irc-test \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012:s3tablescatalog:penguin-rest-test/namespaces/analytics/tables/daily_sales"

Result (excerpt):

{
  "config": {
    "s3.access-key-id": "ASIAXXXXXXXXXXXXXXXX",
    "s3.secret-access-key": "(masked)",
    "s3.session-token": "(masked)"
  },
  "metadata-location": "s3://...(omitted)"
}

HTTP 200, with a response containing vended credentials.

S3 Tables Endpoint

BUCKET_ARN_PATH="arn:aws:s3tables:ap-northeast-1:123456789012:bucket%2Fpenguin-rest-test"

awscurl --service s3tables --region ap-northeast-1 --profile penguin-irc-test \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces/analytics/tables/daily_sales"

Result (excerpt):

{
  "config": {
    "tableBucketId": "3b2a6702-dd99-44f2-bc03-2f9f6b273104",
    "namespaceId": "20576faa-861e-499f-a30f-4d6c7550dd55",
    "tableId": "34c72c19-610d-4e5c-bee4-6ae9f093c583"
  },
  "metadata-location": "s3://...(omitted)"
}

HTTP 200, with a response containing internal IDs (no credentials).

Checking CloudTrail (Glue Endpoint → GetDataAccess)

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetDataAccess \
  --region ap-northeast-1 --max-results 3

Result (excerpt):

{
  "EventName": "GetDataAccess",
  "EventTime": "2026-07-10T14:39:35+09:00",
  "EventSource": "lakeformation.amazonaws.com",
  "Username": "penguin-irc-test-session",
  "CloudTrailEvent": "...\"invokedBy\":\"glue.amazonaws.com\"..."
}

GetDataAccess is recorded with invokedBy: glue.amazonaws.com. The event was logged within seconds of when the request was sent, which shows that Glue queries Lake Formation synchronously.

No GetDataAccess was recorded for the request made against the S3 Tables endpoint.

Checking CloudTrail (the S3 Tables Endpoint's Own Call)

In addition to confirming that GetDataAccess isn't recorded, let's also check how the S3 Tables endpoint's own API call (GetTableMetadataLocation) shows up in CloudTrail.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetTableMetadataLocation \
  --region ap-northeast-1 --max-results 3 --profile penguin-irc-test

Result (excerpt, masked):

{
  "EventName": "GetTableMetadataLocation",
  "EventTime": "2026-07-10T14:41:05+09:00",
  "EventSource": "s3tables.amazonaws.com",
  "Username": "penguin-irc-test-session",
  "CloudTrailEvent": "{\"userIdentity\":{\"type\":\"AssumedRole\",\"arn\":\"arn:aws:sts::123456789012:assumed-role/penguin-irc-test-role/penguin-irc-test-session\"},\"eventSource\":\"s3tables.amazonaws.com\",\"eventName\":\"GetTableMetadataLocation\",...}"
}

The eventSource is recorded simply as s3tables.amazonaws.com on its own, and there's no field equivalent to the invokedBy we saw in the Glue-side GetDataAccess event anywhere in the CloudTrailEvent. This confirms, from this angle as well, that authorization on the S3 Tables endpoint is a direct IAM evaluation of the caller's own credentials, rather than a delegated call through another service.

Whether Username shows up as penguin-irc-test (the IAM user itself) or penguin-irc-test-session (the session for the role used to vend credentials) lines up exactly with userIdentity.type (IAMUser vs. AssumedRole), giving us a way to tell which principal actually processed each request.

IAM ✓ / LF ✗ (Removing the LF Grant)

Let's remove the Lake Formation grant from the IAM role used to vend credentials (penguin-irc-test-role).

aws lakeformation revoke-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/penguin-irc-test-role \
  --permissions "SELECT" "DESCRIBE" \
  --resource '{"Table":{"CatalogId":"123456789012:s3tablescatalog/penguin-rest-test","DatabaseName":"analytics","Name":"daily_sales"}}'

aws lakeformation revoke-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/penguin-irc-test-role \
  --permissions "DESCRIBE" \
  --resource '{"Database":{"CatalogId":"123456789012:s3tablescatalog/penguin-rest-test","Name":"analytics"}}'

Glue Endpoint

{
  "error": {
    "code": 403,
    "message": "Insufficient Lake Formation permission(s): Required Describe on daily_sales",
    "type": "AccessDeniedException"
  }
}

HTTP 403, with an error indicating insufficient Lake Formation permissions.

S3 Tables Endpoint

{
  "config": {
    "tableBucketId": "3b2a6702-dd99-44f2-bc03-2f9f6b273104",
    "namespaceId": "20576faa-861e-499f-a30f-4d6c7550dd55",
    "tableId": "34c72c19-610d-4e5c-bee4-6ae9f093c583"
  },
  "metadata-location": "s3://...(omitted)"
}

Still 200, no change. Whether or not the Lake Formation grant exists has no effect on authorization for the S3 Tables endpoint.

Checking CloudTrail (Glue Endpoint → GetDataAccess)

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetDataAccess \
  --region ap-northeast-1 --max-results 3

Result (excerpt):

{
  "EventName": "GetDataAccess",
  "EventTime": "2026-07-10T14:51:29+09:00",
  "EventSource": "lakeformation.amazonaws.com",
  "Username": "penguin-irc-test-session",
  "CloudTrailEvent": "...\"invokedBy\":\"glue.amazonaws.com\"..."
}

Even after removing the Lake Formation grant, GetDataAccess is recorded with invokedBy: glue.amazonaws.com, at roughly the same time the request was sent. For the table-retrieval operation tested here on the Glue endpoint, GetDataAccess is recorded even in the 403 case, confirming that the request does reach Lake Formation's permission evaluation.

IAM ✗ / LF ✓ (Removing the s3tables IAM Actions)

After restoring the Lake Formation grant on the role, let's remove the s3tables-related actions from the IAM policy.

aws iam put-user-policy \
  --user-name penguin-irc-test \
  --policy-name GlueIRCMinimal \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["glue:GetCatalog","glue:GetDatabase","glue:GetTable"],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": ["lakeformation:GetDataAccess"],
        "Resource": "*"
      }
    ]
  }'

Glue Endpoint

{
  "error": {
    "code": 403,
    "message": "From federation source: User: arn:aws:iam::123456789012:user/penguin-irc-test is not authorized to perform: s3tables:GetTableBucket on resource: arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test because no identity-based policy allows the s3tables:GetTableBucket action",
    "type": "AccessDeniedException"
  }
}

HTTP 403. In this test, when the calling IAM user lacked s3tables permissions, we got a From federation source error, confirming that the request never even reaches Lake Formation's evaluation.

S3 Tables Endpoint

{
  "error": {
    "code": 403,
    "message": "User: arn:aws:iam::123456789012:user/penguin-irc-test is not authorized to perform: s3tables:GetTableMetadataLocation on resource: ...",
    "type": "forbidden"
  }
}

Also 403, unsurprising, since the s3tables IAM actions are missing.

Checking CloudTrail (Glue Endpoint → GetDataAccess)

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetDataAccess \
  --region ap-northeast-1 --max-results 3

Result (excerpt):

No matching GetDataAccess event was found.

No GetDataAccess was recorded corresponding to this request. This confirms that when the s3tables-related IAM permissions are removed, Lake Formation is never even queried in the first place, and the request is denied at the IAM authorization stage.

Results Summary

Condition	Glue endpoint	S3 Tables endpoint	GetDataAccess
IAM ✓ / LF ✓	200	200	Present (14:39:35, recorded under the federation role's session)
IAM ✓ / LF ✗	403	200	Present (14:51:29, recorded under the federation role's session)
IAM ✗ / LF ✓	403	403	Absent

Authorization Flow

The results confirm that each endpoint follows a genuinely different flow.

Glue REST Catalog

Calling IAM user
    |
    | Checks s3tables IAM permissions
    | via the Glue API
    ↓
Glue REST Catalog
    |
    | GetDataAccess
    | (evaluated as the federation IAM role)
    ↓
Lake Formation grant evaluation
    |
    ↓
Vended credentials issued

Here's what this test confirmed:

In this test, when the calling IAM user lacked s3tables IAM permissions, the request was denied at the IAM authorization stage without ever reaching Lake Formation's evaluation (this is where the From federation source error appears).
Once the s3tables IAM permissions are satisfied, Lake Formation permission evaluation is performed with the IAM role used to vend credentials as the principal.
GetDataAccess is recorded in CloudTrail as invokedBy: glue.amazonaws.com (it's recorded even in the 403 case when LF permissions are missing). The request time and the event time are nearly identical, showing that the evaluation happens synchronously.

S3 Tables REST Endpoint

Calling IAM user
    |
    | s3tables IAM authorization
    ↓
S3 Tables REST endpoint

This test confirmed that the S3 Tables REST endpoint operates purely on an IAM-based authorization model.

Here's what this test confirmed:

Access is controlled by the calling user's IAM policy for s3tables API authorization (no Lake Formation involvement was observed in this test).
Lake Formation-based permission control was not observed on this S3 Tables REST endpoint access path.
GetDataAccess is not recorded in CloudTrail.

Conclusion

In this article, I confirmed the authorization flow for the Glue REST Catalog and the S3 Tables REST endpoint by switching the IAM policy and Lake Formation grants on and off.

To summarize:

For the Glue REST Catalog, Lake Formation's GetDataAccess is executed only after the calling IAM user's s3tables-related IAM permissions are satisfied.
Lake Formation's permission evaluation is performed with the IAM role used to vend credentials as the principal, not the calling IAM user.
Even when a Lake Formation permission shortfall results in a 403, GetDataAccess is still recorded in CloudTrail, confirming that the request does reach Lake Formation's permission evaluation (the request time and event time are nearly identical).
On the other hand, when the calling IAM user's s3tables-related IAM permissions are insufficient, GetDataAccess is not recorded, and Lake Formation's permission evaluation never runs.
For the S3 Tables REST endpoint, within the scope of this test, GetDataAccess was never recorded and no Lake Formation involvement was observed. The S3 Tables endpoint's own CloudTrail events also have no field equivalent to invokedBy, further confirming that authorization is a direct IAM evaluation.

By combining CloudTrail with the actual API responses, I was able to observe the real authorization flow, something that isn't visible from the documentation's description of "Lake Formation is used" alone.

The CloudTrail logs also back up the difference that the Glue REST Catalog goes through both IAM and Lake Formation authorization, while the S3 Tables REST endpoint is authorized purely through IAM.

To be fair, this all matched the documented behavior, but going through it hands-on still surfaced plenty of small insights and things I learned along the way.

I've found that combining CloudTrail with API responses like this is a genuinely useful technique for understanding the internal behavior of other AWS services too. I'd like to keep running experiments like this to uncover things about AWS's internals that documentation alone doesn't show.

I hope this article is useful to anyone trying to understand the authorization architecture behind the Iceberg REST Catalog on AWS.

Hitting the Iceberg REST Catalog Directly: Understanding the Differences Between Glue Data Catalog and S3 Tables

Aki — Fri, 10 Jul 2026 03:32:10 +0000

Original Japanese article: Iceberg REST Catalogを直接叩いて、Glue Data CatalogとS3 Tablesの違いを理解する

Introduction

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

Most of the time, when working with Iceberg tables, we reach for PyIceberg or Spark. I'm no exception, and honestly there were parts of the PyIceberg configuration — rest.sigv4-enabled, rest.signing-name, warehouse — that I understood only vaguely.

Iceberg defines a standard called the Iceberg REST Catalog Open API specification, and AWS implements it through two separate endpoints:

The AWS Glue Iceberg REST endpoint (https://glue.<region>.amazonaws.com/iceberg)
The Amazon S3 Tables Iceberg REST endpoint (https://s3tables.<region>.amazonaws.com/iceberg)

If two implementations follow the same spec, sending the same requests to both and comparing the results should reveal what's actually different between them.

In this article, I'll bypass clients like PyIceberg entirely and hit the REST API directly to explore the differences between the two endpoints.

To state the conclusion up front:

Even though both implement the same Iceberg REST Catalog specification, Glue is designed as an "entry point to multiple catalogs," while S3 Tables is designed as an "entry point to a single table bucket." That difference is visible just by looking at the URL paths.

I previously wrote about the relationship between S3 Tables and Glue Data Catalog in another article — worth a read alongside this one:
Does Amazon S3 Tables Replace AWS Glue Data Catalog? Understanding Their Relationship

What Is the Iceberg REST Catalog?

The Iceberg REST Catalog is a specification that standardizes Iceberg catalog operations as an HTTP API. It's published as an OpenAPI definition (YAML), and any catalog that conforms to it can be accessed the same way from clients such as PyIceberg, Spark, and Trino.

The key points of the spec are:

URL paths follow a pattern like GET /v1/{prefix}/namespaces, where {prefix} is a free-form segment
Clients first call GET /v1/config to retrieve endpoint configuration (the default prefix and other settings)
The table metadata body (schema, snapshots, etc.) is returned as JSON in the LoadTable response

In other words, when you write catalog.load_table("ns.table") in PyIceberg, what's actually happening under the hood is an HTTP request to GET /v1/{prefix}/namespaces/ns/tables/table.

Here's a summary of the two AWS implementations before we dive in:

Item	Glue Iceberg REST endpoint	S3 Tables Iceberg REST endpoint
Endpoint	`https://glue.<region>.amazonaws.com/iceberg`	`https://s3tables.<region>.amazonaws.com/iceberg`
Contents of `{prefix}`	`/catalogs/{catalog}` (catalog hierarchy)	URL-encoded table bucket ARN
Value passed as `warehouse`	Glue catalog ID	Table bucket ARN
SigV4 signing service name	`glue`	`s3tables`
Access control	IAM + Lake Formation	s3tables IAM actions only

Here's the overall picture as a diagram:

              Iceberg REST Catalog spec
           GET /v1/{prefix}/namespaces/...
                        │
        ┌───────────────┴───────────────┐
        │                               │
  Glue endpoint                  S3 Tables endpoint
        │                               │
 prefix = /catalogs/{catalog}    prefix = table bucket ARN
 (multi-catalog hierarchy)       (one bucket = one catalog)
        │                               │
  IAM + Lake Formation           s3tables IAM actions
        │                               │
        └───────────────┬───────────────┘
                        │
              Same Iceberg table
          (points to the same metadata.json)

Note: a catalog doesn't manage the metadata.json file itself — it provides a reference to where the latest metadata-location is. The catalog's essential job is knowing where the current metadata.json lives.

Setting Up the Test Environment

Let's create a test table bucket, namespace, and table via the CLI. Read the region as Tokyo (ap-northeast-1) and the account ID as 123456789012.

# Create a table bucket
aws s3tables create-table-bucket \
  --name penguin-rest-test \
  --region ap-northeast-1

# Create a namespace
aws s3tables create-namespace \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test \
  --namespace analytics

# Create a table (with schema)
aws s3tables create-table \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test \
  --namespace analytics \
  --name daily_sales \
  --format ICEBERG \
  --metadata '{
    "iceberg": {
      "schema": {
        "fields": [
          {"name": "sales_date", "type": "date", "required": false},
          {"name": "amount", "type": "long", "required": false}
        ]
      }
    }
  }'

SigV4 Signing

You can't hit these endpoints with plain curl.

The Iceberg REST Catalog spec defines an OAuth2-based authentication flow, but AWS's implementation uses IAM SigV4 signing instead — a standard-spec API with AWS-flavored authentication.

That rest.sigv4-enabled: true setting in PyIceberg is exactly what enables this signing.

Computing SigV4 signatures by hand is painful, so I used awscurl for this exercise.

pip install awscurl

awscurl picks up credentials from environment variables or a profile and sends SigV4-signed requests for you.

The important part is the --service option, which must specify the correct service name for signing: glue for the Glue endpoint, s3tables for the S3 Tables endpoint.

Hitting the S3 Tables Iceberg REST Endpoint

Let's start with the simpler of the two — the S3 Tables endpoint.

GET /v1/config

getConfig is the first API a REST Catalog client calls. The warehouse query parameter takes the table bucket ARN.

Note

When using awscurl, pass the raw, unencoded ARN as the query parameter value. awscurl automatically URL-encodes query parameters before computing the signature, so if you pre-encode the value yourself, it gets double-encoded and you'll get a SignatureDoesNotMatch error.

BUCKET_ARN="arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test"

awscurl --service s3tables --region ap-northeast-1 \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/config?warehouse=${BUCKET_ARN}"

Result (excerpt):

{
  "defaults": {
    "prefix": "arn%3Aaws%3As3tables%3Aap-northeast-1%3A123456789012%3Abucket%2Fpenguin-rest-test",
    "io-impl": "org.apache.iceberg.aws.s3.S3FileIO",
    "write.object-storage.enabled": "true",
    "write.object-storage.partitioned-paths": "false",
    "s3.delete-enabled": "false",
    "rest-metrics-reporting-enabled": "false"
  },
  "overrides": {}
}

The interesting part is the prefix in the response. For the S3 Tables endpoint, prefix is exactly the URL-encoded table bucket ARN, and it lives under defaults. In other words, this endpoint is designed around a "one table bucket = one catalog" model — if you want to work with multiple table buckets, you register multiple catalogs on the client side.

defaults also included the write-side FileIO implementation (io-impl), object storage layout settings (write.object-storage.*), and a setting that disables S3 delete operations (s3.delete-enabled). It's interesting to see, from actual output, that some of the parameters we're used to configuring individually on the client (PyIceberg) side are actually being pushed down as server-side defaults through this config response.

Incidentally, this getConfig call is authorized under the s3tables:GetTableBucket IAM action. The official documentation includes a mapping table showing which s3tables IAM action corresponds to each REST operation.

Note

The spec's CatalogConfig also defines an endpoints field, which lets the server return a list of supported endpoints (in a format like "GET /v1/{prefix}/namespaces"). When I checked, the S3 Tables endpoint's response did not include an endpoints field.

Listing Namespaces and Tables

Now that we know the prefix, let's list namespaces and tables.

Note

There's a subtlety worth calling out here.

The warehouse query parameter for GET /v1/config needs the raw ARN, since awscurl automatically URL-encodes query parameters before signing — pre-encoding it yourself causes double-encoding and a SignatureDoesNotMatch error.

The {prefix} segment in the path, however, behaves differently. If you put the ARN into the path completely unencoded (colons and slashes as-is), the / characters inside the ARN get interpreted as path separators, and the request no longer matches the modeled URL pattern /v1/{prefix}/namespaces — you get an UnknownOperationException.

The correct approach is to leave the colons raw but percent-encode only the single / inside bucket/<table-bucket-name> as %2F. That makes the request match the correct route (and once it reaches the authorization layer, you'll get a 403 if you lack permissions, rather than a routing error).

Even though it's the same operation — putting an ARN into a URL — the encoding rules differ between query parameters and path segments. That's something you only really notice by actually hitting the endpoint.

BUCKET_ARN_PATH="arn:aws:s3tables:ap-northeast-1:123456789012:bucket%2Fpenguin-rest-test"

# List namespaces
awscurl --service s3tables --region ap-northeast-1 \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces"

# List tables
awscurl --service s3tables --region ap-northeast-1 \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces/analytics/tables"

Result (excerpt):

{
  "namespaces": [
    ["analytics"]
  ]
}

{
  "identifiers": [
    {
      "name": "daily_sales",
      "namespace": ["analytics"]
    }
  ]
}

There's one difference from the spec worth noting here: the Iceberg REST spec allows multi-level namespaces (like a.b.c), but S3 Tables only supports a single level.

Let's confirm this by trying to create a multi-level namespace:

awscurl --service s3tables --region ap-northeast-1 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"namespace": ["level1", "level2"]}' \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces"

Result (excerpt):

{
  "error": {
    "code": 400,
    "message": "Multipart namespaces are not supported.",
    "type": "bad_request"
  }
}

The error message spells it out directly — "multipart namespaces are not supported" — confirming the single-level restriction empirically.

Retrieving Metadata with LoadTable

This is the API I most wanted to check today.

awscurl --service s3tables --region ap-northeast-1 \
  "https://s3tables.ap-northeast-1.amazonaws.com/iceberg/v1/${BUCKET_ARN_PATH}/namespaces/analytics/tables/daily_sales"

Result (excerpt):

{
  "metadata-location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3/metadata/00000-163a447a-c64d-44f9-8619-5db9561e549b.metadata.json",
  "metadata": {
    "format-version": 2,
    "table-uuid": "9507ea2b-7a71-40a7-b6a9-1d6e633955e1",
    "location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3",
    "current-schema-id": 0,
    "schemas": [
      {
        "type": "struct",
        "schema-id": 0,
        "fields": [
          { "id": 1, "name": "sales_date", "required": false, "type": "date" },
          { "id": 2, "name": "amount", "required": false, "type": "long" }
        ]
      }
    ],
    "default-spec-id": 0,
    "partition-specs": [{ "spec-id": 0, "fields": [] }],
    "properties": {
      "write.parquet.compression-codec": "zstd"
    },
    "current-snapshot-id": -1,
    "snapshots": []
  },
  "config": {
    "tableBucketId": "3b2a6702-dd99-44f2-bc03-2f9f6b273104",
    "namespaceId": "20576faa-861e-499f-a30f-4d6c7550dd55",
    "tableId": "34c72c19-610d-4e5c-bee4-6ae9f093c583"
  }
}

This JSON is exactly what's behind the information we normally see through table.schema() or table.snapshots() in PyIceberg. The response directly confirms that a catalog's essential job is "managing and returning the S3 path of the latest metadata.json" (metadata-location).

Incidentally, the config field in the response contained S3 Tables-internal identifiers: tableBucketId, namespaceId, and tableId. Per spec, the Glue endpoint's config is supposed to include temporary credentials (vended credentials), but here on the S3 Tables endpoint there's no credential delegation at all — it just returns internal management IDs.

Note

The S3 Tables endpoint also documents a limit: operations against a table whose metadata.json exceeds 50MB return a 400 error. Worth keeping in mind — if metadata bloats from accumulated snapshots and similar growth, you could hit this API-level ceiling.

Checking What's Happening Under the Hood via CloudTrail

An interesting characteristic of the S3 Tables endpoint is that REST API calls get logged in CloudTrail as their corresponding native S3 Tables actions. Per the official documentation, a single LoadTable call logs both of the following:

GetTableMetadataLocation (a management event)
A data event corresponding to GetTableData

In other words, the audit log itself reveals that this endpoint is implemented as a proxy that translates the Iceberg REST API into native S3 Tables API calls.

Let's check CloudTrail directly:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetTableMetadataLocation \
  --region ap-northeast-1 \
| jq '.Events[0] | {time: .EventTime, user: .Username, event: .EventName}'

Result (excerpt):

{
  "time": "2026-07-09T13:46:44+00:00",
  "user": "penguin-test-user",
  "event": "GetTableMetadataLocation"
}

Even though we only called LoadTable over REST, CloudTrail logs it under the native S3 Tables event name s3tables:GetTableMetadataLocation, complete with the exact caller (IAM username).

Hitting the Glue Iceberg REST Endpoint

Now let's look at the Glue endpoint, which behaves quite differently.

GET /v1/config

awscurl --service glue --region ap-northeast-1 \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/config?warehouse=123456789012"

Result (excerpt):

{
  "defaults": {
    "prefix": "123456789012",
    "header.Content-Type": "application/x-amz-json-1.1",
    "rest.sigv4-enabled": "true",
    "rest.signing-name": "glue",
    "rest.signing-region": "ap-northeast-1",
    "rest-table-scan-enabled": "true",
    "rest-data-commit-enabled": "true",
    "token-refresh-enabled": "false"
  },
  "overrides": {
    "prefix": "catalogs/123456789012"
  }
}

There's a difference from the S3 Tables endpoint worth calling out here: defaults.prefix is "123456789012" (just the account ID), while overrides.prefix is "catalogs/123456789012" (with catalogs/ prepended) — the two values genuinely differ. Per spec, overrides takes precedence over defaults, so the prefix a client should actually use is catalogs/123456789012. It's confirmed, from actual output, that defaults and overrides really can disagree.

The other defaults entries are worth a look too — rest.sigv4-enabled and rest.signing-name map directly onto the PyIceberg configuration items of the same name. rest-table-scan-enabled and rest-data-commit-enabled are presumably feature flags for server-side scan planning and write commits, discussed further below.

Incidentally, this response also didn't include an endpoints field.

What you pass as warehouse for the Glue endpoint is a Glue catalog ID (defaulting to the current account's root catalog if omitted). Where the S3 Tables endpoint's warehouse was "a bucket ARN," here it's "where in the catalog hierarchy to connect."

Prefix Rules: Encoding the Catalog Hierarchy

The Glue endpoint's prefix always takes the form /catalogs/{catalog}. The official documentation defines the following rules for how {catalog} is written:

Target	Prefix notation	Example REST path
Default catalog of the current account	`:`	`GET /v1/catalogs/:/namespaces`
Default catalog of a specific account	Account ID	`GET /v1/catalogs/123456789012/namespaces`
Nested catalog	`catalog1:catalog2`	`GET /v1/catalogs/rmscatalog1:db1/namespaces`
Nested catalog of a specific account	`accountId:catalog1:catalog2`	`GET /v1/catalogs/123456789012:s3tablescatalog:bucket/namespaces`

The : notation for the default catalog is confusing at first glance, but it makes more sense once you think of it as "encoding the catalog hierarchy's separator as : instead of the path separator /." It's essentially using the free-form nature of the Iceberg REST spec's prefix to cram Glue's multi-catalog hierarchy into the URL.

Listing Namespaces (Default Catalog)

awscurl --service glue --region ap-northeast-1 \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012/namespaces"

Note

The default catalog can be expressed either as a single colon (:) or as the account ID. Here I'm using the catalogs/{accountId} form, which is also what showed up in overrides.prefix in the getConfig response above.

Result (excerpt):

{
  "namespaces": [
    ["hive"],
    ["icebergdb"]
  ]
}

What comes back is the familiar list of Glue databases — the response directly confirms the mapping "Glue database = Iceberg namespace." Notably, S3 Tables-backed databases under s3tablescatalog are not included here. The default catalog only covers Glue databases directly under the account; to see S3 Tables namespaces, you need to explicitly reach them via the nested catalog prefix, described below.

Incidentally, the Glue endpoint has the same single-level namespace restriction as S3 Tables. What looks like a multi-level structure isn't expressed by making namespaces deeper — it's expressed by nesting catalogs. That seems to be a consistent design choice on Glue's part.

Reading an S3 Tables Table Through the Glue Endpoint

This is the heart of today's investigation: reading the same table we read via the S3 Tables endpoint, this time through the Glue endpoint.

S3 Tables with Glue integration enabled is mounted under the s3tablescatalog federated catalog. In PyIceberg, you'd specify warehouse as 123456789012:s3tablescatalog/penguin-rest-test. Applying the earlier prefix-conversion rule, the path becomes:

awscurl --service glue --region ap-northeast-1 \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012:s3tablescatalog:penguin-rest-test/namespaces/analytics/tables/daily_sales"

Result (excerpt):

{
  "config": {
    "createdBy": "123456789012",
    "s3TableArn": "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test/table/34c72c19-610d-4e5c-bee4-6ae9f093c583",
    "ownerAccountId": "123456789012",
    "metadata_location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3/metadata/00000-163a447a-c64d-44f9-8619-5db9561e549b.metadata.json",
    "format": "ICEBERG",
    "warehouse_location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3",
    "table_type": "ICEBERG"
  },
  "metadata": {
    "format-version": 2,
    "table-uuid": "9507ea2b-7a71-40a7-b6a9-1d6e633955e1",
    "current-schema-id": 0,
    "schemas": [
      {
        "type": "struct",
        "schema-id": 0,
        "fields": [
          { "id": 1, "name": "sales_date", "required": false, "type": "date" },
          { "id": 2, "name": "amount", "required": false, "type": "long" }
        ]
      }
    ],
    "current-snapshot-id": -1
  },
  "metadata-location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3/metadata/00000-163a447a-c64d-44f9-8619-5db9561e549b.metadata.json"
}

Note

The nested-catalog prefix notation used above (accountId:s3tablescatalog:bucketName) was derived from the conversion-rule table in the official documentation. Sending an actual request in this format resulted in correct routing, and both authorization and the underlying data checked out.

The metadata-location and table-uuid (9507ea2b-7a71-40a7-b6a9-1d6e633955e1) here match exactly what we retrieved via the S3 Tables endpoint earlier. Different entry point, same underlying entity.

The config contents are worth noting too. In this request — where we didn't set the x-iceberg-access-delegation header — config didn't contain S3 access credentials, only metadata like s3TableArn (the original S3 Tables ARN) and warehouse_location (the actual S3 path). As I'll cover below, one more configuration step was needed before credentials would actually come back.

For the same table: through the S3 Tables endpoint the path is /v1/{bucketArn}/namespaces/analytics/tables/daily_sales, while through the Glue endpoint it's /v1/catalogs/{accountId}:s3tablescatalog:{bucketName}/namespaces/analytics/tables/daily_sales. Physically they point to the same metadata.json, but the path structures are completely different because the two services have entirely different mental models of "what a catalog is." That, I think, is the essential difference between the two endpoints.

Access Control Differences (Lake Formation)

Accessing via the Glue endpoint requires Lake Formation grants in addition to IAM policies (glue:GetCatalog, glue:GetTable, etc.), because S3 Tables tables get registered as Lake Formation resources when Glue integration is enabled.

Further, for an external engine to read the actual data, you need to enable full-table access for external engines in Lake Formation, and allow the IAM role to call lakeformation:GetDataAccess. This mechanism is what issues the temporary credentials known as vended credentials.

In practice, though, this alone wasn't enough. It took explicitly registering the table bucket as a federated Lake Formation resource via aws lakeformation register-resource --with-federation, and setting up a trust policy so the Lake Formation service itself (lakeformation.amazonaws.com) could assume the IAM role used for issuing credentials, before vended credentials actually started being issued. If this registration step is missing, requests with the header described below (even with otherwise-correct IAM policies and Lake Formation grants) just come back with a credential-less config — only s3TableArn and warehouse_location — with no error at all, which makes it an easy thing to miss.

When PyIceberg hits the Glue endpoint, it attaches this header to the request:

x-iceberg-access-delegation: vended-credentials

Per the Iceberg REST spec, this header signals to the server that the client wants credential delegation. However — at least in this environment — as long as the federation registration was complete, calling LoadTable without this header still returned credentials the same way.

In other words, what actually determines whether credentials come back doesn't seem to be the presence of the header, but whether the Lake Formation federation registration is complete. The header is the spec-compliant way to signal intent, but at least in this environment it wasn't the deciding factor in the Glue endpoint's behavior.

Still, to verify things properly per spec, let's call LoadTable with the header attached:

# With the vended-credentials header
awscurl --service glue --region ap-northeast-1 \
  -H "x-iceberg-access-delegation: vended-credentials" \
  "https://glue.ap-northeast-1.amazonaws.com/iceberg/v1/catalogs/123456789012:s3tablescatalog:penguin-rest-test/namespaces/analytics/tables/daily_sales"

Result (excerpt):

{
  "metadata-location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3/metadata/00000-163a447a-c64d-44f9-8619-5db9561e549b.metadata.json",
  "metadata": { "...": "..." },
  "config": {
    "s3.access-key-id": "(masked)",
    "s3.secret-access-key": "(masked)",
    "s3.session-token": "(masked)",
    "s3.session-token-expires-at-ms": "1783651228000",
    "s3TableArn": "arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test/table/34c72c19-610d-4e5c-bee4-6ae9f093c583",
    "warehouse_location": "s3://34c72c19-610d-4e5c-d8d1qwx3db1p3tbr8g9jch9n6e14sapn1b--table-s3"
  }
}

s3.access-key-id, s3.secret-access-key, and s3.session-token are actually present here — these are the vended credentials. Along with s3.session-token-expires-at-ms (session expiration in epoch milliseconds), this confirms from the response itself that the catalog is issuing a temporary storage key directly.

The S3 Tables endpoint, meanwhile, has no notion of Lake Formation at all — authorization there is handled entirely via s3tables:* IAM actions, and resource-based policies on the table bucket are also available.

Same underlying table, but the authorization model changes depending on which entry point you go through — something worth keeping in mind during access-design work. Incidentally, exactly how far you can deliberately vary Lake Formation permissions and what happens as a result (does removing a grant actually deny access, etc.) feels like enough material for its own article, so I'll leave that for another time.

Summarizing the Differences Between the Two Endpoints

Here's what actually turned up from hitting both endpoints directly.

Basic Structure

Item	Glue endpoint	S3 Tables endpoint
Endpoint	`glue.<region>.amazonaws.com/iceberg`	`s3tables.<region>.amazonaws.com/iceberg`
Signing service name	`glue`	`s3tables`
`warehouse` value	Glue catalog ID	Table bucket ARN
prefix	`/catalogs/{catalog}` (hierarchy encoding)	URL-encoded bucket ARN
Catalog scope	Account-wide (multi-catalog hierarchy)	Single table bucket
Storage targeted	General-purpose S3 Iceberg + S3 Tables	S3 Tables only
Access control	IAM + Lake Formation (hybrid possible)	s3tables IAM actions only
Credential vending	Vended credentials (requires `register-resource --with-federation`)	None (uses the caller's own credentials)

Where to Use Which, and Gotchas

The official documentation gives guidance on when to use each endpoint:

If you only need basic read/write access to a single table bucket: the S3 Tables endpoint
If you need to integrate multiple catalog sources, or need centralized governance and fine-grained access control via Lake Formation: the Glue endpoint

From actually hitting both directly, here are a few things I'd flag:

Getting the signing service name wrong (glue / s3tables) results in a 403. This is exactly the kind of mistake a wrong rest.signing-name in your client config produces.
Same table, different authorization model depending on which endpoint you go through (whether Lake Formation is involved). Be explicit up front about which path you're connecting through when designing permissions.
CTAS isn't supported on either endpoint. You can work around this by splitting it into CREATE TABLE + INSERT INTO.
dropTable on the S3 Tables endpoint requires purge=true. Depending on your Spark version, DROP TABLE PURGE can end up sending purge=false anyway — in that case, you'll need to delete via the native DeleteTable API instead.

Looking Ahead (Some Personal Thoughts)

Hitting both endpoints directly left me with the impression that each service's design philosophy shows through in how it uses the "free-form" parts of the Iceberg REST Catalog spec.

The S3 Tables endpoint — with its prefix being the bucket ARN, authorization handled through s3tables IAM actions, and CloudTrail logging it as a native API — looks, from this angle, like a thin translation layer over the storage API.

The Glue endpoint, on the other hand, encodes a catalog hierarchy into the prefix, has Lake Formation stepping into authorization, and (when configured correctly) issues temporary storage keys via vended credentials. Both general-purpose S3-based Iceberg and S3 Tables are visible through the same entry point — which lines up with something I speculated in an earlier article, that Glue Data Catalog may be evolving into a metadata plane for AWS as a whole. That same idea seems to show up directly in how the REST API's paths are designed.

The fact that authentication is SigV4 rather than the OAuth the spec assumes is another data point suggesting that how a vendor uses the "free" parts of a standard spec reveals something about its design thinking — probably not unique to the Iceberg REST Catalog.

One more thing I noticed while reading the spec: the latest version defines server-side scan planning endpoints (planTableScan and friends), where the server does the work of building a scan plan. Glue already has a separate extension endpoint (https://glue.<region>.amazonaws.com/extensions) that independently offers server-side scan planning for Redshift Managed Storage — so it looks like a capability that existed as a proprietary extension is now being absorbed into the standard spec. That's an interesting trend — a proprietary extension leading the way before the standard catches up — and I'd like to compare Glue's extension API against the standard plan-related endpoints in a future article.

Snowflake's Catalog-Linked Database (CATALOG_API_TYPE = AWS_GLUE) connects to exactly this Glue endpoint, so seeing how this API gets called from the Snowflake side is another topic I want to dig into going forward.

Conclusion

In this article, I hit the Iceberg REST Catalog directly to sort out the differences between the Glue Data Catalog and S3 Tables endpoints. It took some effort, but I came away with a clearer understanding and a few new insights.

To summarize:

Design philosophy: even though both implement the same Iceberg REST Catalog spec, Glue is an "entry point to multiple catalogs" while S3 Tables is an "entry point to a single table bucket" — a difference visible just from the URL paths.
Prefix design: the spec's free-form {prefix} is used by Glue to encode a catalog hierarchy (/catalogs/{catalog}), and by S3 Tables to encode the table bucket ARN.
Authentication: both use IAM SigV4. Getting the signing service name wrong (glue / s3tables) results in a 403.
Authorization model: for the same table, the Glue endpoint goes through IAM + Lake Formation, while the S3 Tables endpoint uses only s3tables IAM actions — the model changes depending on the path.
Vended credentials: temporary credentials aren't issued just by attaching the x-iceberg-access-delegation: vended-credentials header — you also need to complete resource registration via register-resource --with-federation.
Debugging tips: inspecting the actual CanonicalRequest and headers with awscurl -v, using CloudTrail's errorCode to triage error types, and pre-checking URL assembly with echo were all useful, unglamorous techniques.

Day to day, relying on PyIceberg's or Spark's abstractions is more than enough. But looking at the raw HTTP requests once gives you a clearer mental map between each client configuration item and "that part of that request," which raises the resolution you get when triaging connection errors.

I hope this article is useful to anyone trying to understand how the Iceberg REST Catalog actually works.

Does Amazon S3 Tables Replace AWS Glue Data Catalog? Understanding Their Relationship

Aki — Wed, 01 Jul 2026 14:16:20 +0000

Original Japanese article: S3 TablesはGlue Data Catalogを置き換えるのか考えてみた

Introduction

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

When I first started exploring Amazon S3 Tables, one question immediately came to mind:

"Does this service eventually replace AWS Glue Data Catalog?"

Perhaps not everyone has the same impression. However, because S3 Tables provides its own Iceberg REST Catalog endpoint and can create and manage namespaces and tables without integrating with Glue Data Catalog, I couldn't help but wonder about it.

The official documentation uses the term "integration", which suggests that the relationship is more nuanced than a simple replacement. Still, it can be difficult to understand how these two services actually fit together.

In this article, I'd like to organize the relationship between Amazon S3 Tables and AWS Glue Data Catalog based on the official AWS documentation.

To summarize upfront:

Amazon S3 Tables does not replace AWS Glue Data Catalog. Instead, it should be viewed as a new managed table storage service that provides its own Iceberg REST Catalog while also integrating with Glue Data Catalog.

Understanding the Roles of S3 Tables and Glue Data Catalog

To begin with, Amazon S3 Tables is not a replacement for Glue Data Catalog.

At the same time, it is not entirely accurate to think of S3 Tables as "just storage."

S3 Tables provides its own Iceberg REST Catalog endpoint:

https://s3tables.<region>.amazonaws.com/iceberg

Even without integrating with Glue Data Catalog, you can create, list, delete, and read/write namespaces and tables directly through this endpoint.

The official documentation describes this standalone endpoint as being suitable for scenarios where you only need basic read/write access to a single table bucket. For other scenarios, AWS recommends using the Glue Iceberg REST endpoint, which provides:

Integrated table management
Centralized governance
Fine-grained access control

The roles of the two services can be summarized as follows:

Service	Role
Amazon S3 Tables	A storage layer that stores Iceberg table data and metadata while also providing an Iceberg REST Catalog for a single table bucket
AWS Glue Data Catalog	A centralized metadata catalog for AWS tables and databases, including S3 Tables, providing unified access and governance across analytics services such as Athena and Redshift

In other words, the central catalog for governance across AWS analytics services is still Glue Data Catalog.

S3 Tables is simply one of the catalog sources that can be integrated into Glue Data Catalog as a federated catalog.

Considering recent features such as S3 Tables, Catalog Federation, S3 Metadata, and S3 Annotations, all of which bring various metadata sources under Glue Data Catalog, the role of Glue Data Catalog may become even more important in the future.

If you only need to manage a single table bucket, the standalone REST Catalog provided by S3 Tables may be sufficient.

However, if you need to work across multiple analytics services or multiple catalog sources, using Glue Data Catalog as the entry point is likely to be much easier operationally.

Understanding Federated Catalogs

By integrating S3 Tables with Glue Data Catalog, you can use a single catalog to discover and query data in Amazon S3 data lakes and even join that data with S3 Tables.

A federated catalog allows users to access metadata through Glue Data Catalog without needing to know where that metadata is actually stored.

From a user's perspective, S3 Tables integration works in a similar way—you can access it as another catalog within Glue Data Catalog without needing to know where the underlying metadata physically resides.

The integration maps S3 Tables resources into Glue Catalog objects as follows:

An S3 table bucket becomes a Data Catalog catalog.
An S3 namespace becomes an AWS Glue database.
An S3 table becomes an AWS Glue table.

When integration is enabled through the console, AWS automatically creates another layer on top called:

s3tablescatalog

When you integrate S3 Tables with Data Catalog through the Amazon S3 console, AWS creates a federated catalog named s3tablescatalog, which acts as the parent catalog for all existing and future S3 table buckets in that account and Region.

From the perspective of query engines, the architecture looks like this:

Athena / Redshift / Glue ETL
              │
              ▼
      Glue Data Catalog
              │
              ├── Traditional Glue Catalog Tables
              ├── S3 Tables (via s3tablescatalog)
              └── External Catalogs (via Catalog Federation)

Regardless of where the metadata actually resides, all of these sources appear as tables under Glue Data Catalog.

The hierarchy inside S3 Tables looks like this:

s3tablescatalog (federated catalog)
        └── analytics-bucket (child catalog = S3 table bucket)
                └── sales (database = S3 namespace)
                        └── transactions (table = S3 table)

For example, if you have a table bucket named analytics-bucket containing a namespace called sales and a table called transactions, it can conceptually be represented in Glue Data Catalog as:

s3tablescatalog/analytics-bucket/sales/transactions

In Athena SQL, the same table is referenced as:

"s3tablescatalog/analytics-bucket"."sales"."transactions"

The important thing to remember is that the parent catalog layer, s3tablescatalog, sits in front of the table bucket.

Note:
The four-level hierarchy described above applies to same-account scenarios.
In cross-account scenarios, individual S3 table buckets must be mounted manually into Data Catalog, resulting in a three-part hierarchy.

Trying It Out

Let's verify how an S3 table bucket becomes visible from Glue Data Catalog and how it can be queried from Athena.

Creating a Table Bucket

Create a table bucket in the console and enable the "Enable integration" checkbox.

If you're using the CLI:

aws s3tables create-table-bucket

At this point, integration with Glue Data Catalog is automatically configured.

Querying from Athena

To query the table from Athena, specify:

s3tablescatalog/<table-bucket-name>

as the catalog.

Viewing It from Glue Data Catalog

When you open the Glue Data Catalog console, you'll see the table bucket under s3tablescatalog, followed by its namespaces and tables.

You can also view the schema information directly.

One particularly nice aspect of this integration is that, without any special configuration, you can access S3 Tables data directly from the familiar Athena query editor and Glue Data Catalog console.

Existing Access Control Mechanisms Continue to Work

From an access management perspective, the existing Glue Data Catalog and Lake Formation mechanisms continue to work.

Data Catalog supports two access control modes for S3 Tables integration.

Mode	Description
IAM Access Control	Controls access to both S3 Tables and Data Catalog through IAM policies
AWS Lake Formation Access Control	Uses Lake Formation permissions in addition to Glue IAM permissions and supports database-, table-, column-, and row-level security

One important detail concerns credentials when using Lake Formation.

If a registered role is configured and credential vending is enabled, principals do not need direct S3 Tables IAM permissions.

This is because Lake Formation issues credentials on behalf of the principal using the registered role.

I have another article covering AWS Lake Formation in detail if you're interested.
Organizing How to Use AWS Lake Formation

Because you can migrate between access control modes as requirements evolve, a practical approach might be to start with IAM-only permissions and later move to Lake Formation for finer-grained control.

If Nothing Is Being Replaced, What Actually Changed?

The position of Glue Data Catalog itself has not changed.

What has changed is the operational layer around data management and table maintenance.

Traditionally, Iceberg on S3 consisted of:

A general-purpose S3 bucket
Glue Data Catalog
Table maintenance mechanisms

Even in the traditional architecture, Glue Table Optimizer can already manage:

Compaction
Snapshot retention
Orphan file deletion

Therefore, the major difference between traditional Iceberg on S3 and S3 Tables is not necessarily the existence of these features, but rather that they are enabled by default.

Item	Traditional Iceberg on S3	S3 Tables
Storage	General-purpose S3 bucket	Dedicated table bucket
Catalog	Glue Data Catalog	Native Iceberg REST Catalog or Glue Data Catalog
Compaction	Glue Table Optimizer (manual enablement)	Managed and enabled by default
Snapshot retention	Glue Table Optimizer (manual enablement)	Managed and enabled by default
Orphan file deletion	Glue Table Optimizer (manual enablement)	Managed and enabled by default

Of course, S3 Tables also provides dedicated resource types, optimized pricing models, and specialized APIs.

However, one of the biggest differences is the reduction in onboarding effort thanks to these capabilities being enabled from the start.

From the perspective of Glue Data Catalog, S3 Tables is simply another catalog source integrated as a federated catalog.

It does not require replacing existing crawler-based Glue Data Catalog environments. Both approaches can coexist.

When Should You Use It?

S3 Tables integration seems particularly well suited for:

Building new Iceberg tables with maintenance enabled by default.
Querying across multiple table buckets from Athena or Redshift.
Leveraging Lake Formation's fine-grained access controls.

Things to keep in mind:

Cross-account scenarios require manual mounting.
Query engines require the s3tablescatalog parent catalog path.
Existing crawler-based Glue Catalog environments do not need to be migrated to S3 Tables.

My Thoughts on the Future

As more specialized storage services like S3 Tables emerge, I believe Glue Data Catalog may evolve beyond being merely a Hive Metastore-compatible catalog and become more of an AWS-wide metadata hub.

Catalog Federation already allows external catalogs such as Snowflake Horizon Catalog and Databricks Unity Catalog to connect under Glue Data Catalog.

This suggests a future where:

The data can reside anywhere, but the catalog entry point is centralized in Glue Data Catalog.

The recently announced Amazon S3 Annotations feature also seems to support this direction.

S3 Annotations allows rich, mutable, and queryable metadata to be attached directly to S3 objects.

When annotation tables are enabled, S3 automatically indexes those annotations into fully managed Apache Iceberg tables that can be queried using Athena.

Interestingly, the official examples reference:

"s3tablescatalog/aws-s3"."b_my_media_bucket"."annotation"

which means that the s3tablescatalog hierarchy is now appearing outside the context of S3 Tables itself.

While S3 Tables turns data into Iceberg tables and integrates them into Glue Data Catalog, S3 Annotations appears to do something similar for object metadata.

AWS has not explicitly stated this direction.

However, when looking at S3 Tables, S3 Metadata, S3 Annotations, and Catalog Federation together, Glue Data Catalog increasingly looks like an AWS-wide metadata plane rather than simply a Hive Metastore-compatible service.

It feels as though AWS is moving toward a future where both data and metadata can be accessed through a common Iceberg-based access model.

If this trend continues, Glue Data Catalog may become even more important as the metadata plane for AWS data services.

The arrival of S3 Tables does not diminish the importance of Glue Data Catalog.

If anything, it clarifies its role as the hub that integrates multiple data sources and metadata sources.

Conclusion

To summarize:

Amazon S3 Tables does not replace AWS Glue Data Catalog.
S3 Tables integrates into Glue Data Catalog as a federated catalog.
Glue Data Catalog may become even more important as a hub that integrates multiple metadata sources.
The catalog hierarchy consists of:

Federated Catalog (s3tablescatalog)
        ↓
Child Catalog (table bucket)
        ↓
Database (namespace)
        ↓
Table

Access control can be implemented using either IAM or Lake Formation and migrated later if necessary.
The major change introduced by S3 Tables is that storage, metadata management, and table maintenance are now provided in a more integrated and managed manner through table buckets.

For building new AWS-native data lakes or lakehouses, S3 Tables is becoming a compelling option.

However, this is not because it replaces Glue Data Catalog.

Rather, it provides a more managed way to operate Iceberg tables on top of a metadata foundation centered around Glue Data Catalog.

I hope this article helps clarify the relationship between Amazon S3 Tables and AWS Glue Data Catalog.

Track Apache Iceberg Schema Changes in AWS Glue Data Catalog with aws glue get-table-versions

Aki — Mon, 15 Jun 2026 00:08:31 +0000

Original Japanese article: Iceberg × Glue Data Catalogのスキーマ変更履歴をaws glue get-table-versionsで確認する

Introduction

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

As Apache Iceberg adoption continues to grow in AWS-based lakehouse architectures, schema evolution has become one of its most valuable features.

At the same time, questions like the following inevitably arise:

When did the schema change?
Which columns were added or removed?
Who made the change?

Although you can view historical schema versions from the AWS Glue console, investigating these details can be cumbersome.

This is where aws glue get-table-versions becomes useful.

When your Apache Iceberg tables are managed through AWS Glue Data Catalog, this command allows you to retrieve schema change history over time.

In this article, I'll walk through the basics of get-table-versions, show how to extract column-level differences with jq, and explain how to identify the person who made a change by combining the results with CloudTrail.

What is `get-table-versions`?

aws glue get-table-versions is an AWS CLI command that retrieves historical versions of a table registered in AWS Glue Data Catalog.

Every time a Glue table definition is updated, a new VersionId is created. Each version stores the schema definition, partition information, table parameters, and other metadata.

In addition to schema tracking, Iceberg-specific parameters such as metadata_location are also recorded, making this command useful for Iceberg operational management.

Isn't the Console Enough?

You can actually view previous schema versions from the AWS Glue console by selecting an older version from the version dropdown in the upper-right corner of the table page.

However, the console only allows you to inspect one version at a time.

It does not show differences between versions, making it difficult to answer questions such as:

Which columns were added or removed?
In which version did the change occur?
When exactly was the schema updated?

If you need to compare multiple versions or quickly investigate schema-related incidents, using the CLI is far more efficient.

Basic Command Syntax

aws glue get-table-versions \
  --database-name <database-name> \
  --table-name <table-name> \
  --no-paginate \
  --region ap-northeast-1

Using --no-paginate retrieves all versions in a single request.

The response contains a TableVersions array. Each element includes:

VersionId
Table (full schema definition)
UpdateTime (timestamp when the Glue table definition was updated)

Example Output

{
  "Table": {
    "Name": "flights_1m",
    "DatabaseName": "icebergdb",
    "UpdateTime": "2026-06-12T05:21:18+00:00",
    "StorageDescriptor": {
      "Columns": [
        {
          "Name": "fl_date",
          "Type": "date",
          "Parameters": {
            "iceberg.field.current": "true",
            "iceberg.field.id": "1",
            "iceberg.field.optional": "true"
          }
        }
      ]
    },
    "Parameters": {
      "metadata_location": "s3://<your-bucket>/warehouse/flights_1m/metadata/00002-....metadata.json",
      "previous_metadata_location": "s3://<your-bucket>/warehouse/flights_1m/metadata/00001-....metadata.json",
      "table_type": "ICEBERG"
    },
    "VersionId": "5"
  }
}

Characteristics of Iceberg Tables

Compared to standard Glue tables, Iceberg tables have several notable characteristics.

First, you may notice that VersionId values become surprisingly large.

Glue VersionId values are not the same as Iceberg Snapshot IDs or commit counts. They increment whenever the Glue table definition stored in the catalog is updated.

Because Iceberg frequently updates metadata_location, Glue table definitions are also updated regularly, causing VersionId to increase much more rapidly than expected.

In one of my test environments, a table had already reached VersionId 318.

However, most of those versions were created by metadata updates associated with data writes rather than actual schema changes.

Another notable characteristic is the presence of iceberg.field.id within each column's Parameters.

This field represents Iceberg's internal column ID, which enables schema evolution features such as column renames without breaking data mapping.

The table-level Parameters section also contains:

metadata_location
previous_metadata_location

These point to Iceberg metadata files stored in Amazon S3.

Because Glue VersionId values correspond to Iceberg metadata updates, you can trace these files for deeper historical analysis when necessary.

Warning

AWS Glue Data Catalog has service quotas for the number of stored table versions.

In Iceberg environments, it's possible to hit these limits and encounter ResourceNumberLimitExceededException.

Consider periodically removing old versions or using the SkipArchive option of UpdateTable to reduce version growth.

Viewing Schema Change History

List Columns by Version

Let's start by displaying the update timestamp and column list for each version.

Using jq, we can extract VersionId, UpdateTime, and the column names:

aws glue get-table-versions \
  --database-name icebergdb \
  --table-name flights_1m \
  --no-paginate \
  --region ap-northeast-1 \
| jq -r '
    .TableVersions[]
    | {
        version: .VersionId,
        updated: .Table.UpdateTime,
        columns: [.Table.StorageDescriptor.Columns[].Name]
      }
    | "\(.version)\t\(.updated)\t\(.columns | join(", "))"
  '

Example output:

5    2026-06-12T05:21:18+00:00    fl_date, dep_delay, arr_delay, air_time, distance, dep_time, arr_time
4    2026-06-12T05:20:48+00:00    fl_date, dep_delay, arr_delay, air_time, distance, dep_time, double
3    2026-06-12T05:20:11+00:00    fl_date, dep_delay, arr_delay, air_time, distance, dep_time
2    2025-09-01T21:27:05+00:00    fl_date, dep_delay, arr_delay, air_time, distance, dep_time, arr_time

Note that VersionId values are not necessarily consecutive.

In this example they happen to be 2 → 3 → 4 → 5, but in production environments they may reach hundreds or even thousands.

Since Glue VersionId values do not directly correspond to Iceberg commits, you should not use them alone to estimate the number of schema changes.

Compare Differences Between Versions

To identify added and removed columns between adjacent versions, you can compare column arrays using the jq array difference (-) operator.

aws glue get-table-versions \
  --database-name icebergdb \
  --table-name flights_1m \
  --no-paginate \
  --region ap-northeast-1 \
| jq '
    [ .TableVersions[] | {
        v: .VersionId,
        cols: [.Table.StorageDescriptor.Columns[].Name]
      }
    ]
    | sort_by(.v | tonumber)
    | . as $sorted
    | range(1; length)
    | {
        from: $sorted[.].v,
        added:   ($sorted[.].cols - $sorted[. - 1].cols),
        removed: ($sorted[. - 1].cols - $sorted[.].cols)
      }
  '

Example output:

{ "from": "3", "added": [],           "removed": ["arr_time"] }
{ "from": "4", "added": ["double"],   "removed": [] }
{ "from": "5", "added": ["arr_time"], "removed": ["double"] }

This shows that:

arr_time was removed between v2 and v3.
double was added between v3 and v4.
double was removed and arr_time was restored between v4 and v5.

For full transparency, double was not generated automatically by Glue.

It was actually a mistake I made during testing. I intended to add the arr_time column but accidentally entered the data type name double as the column name.

The issue was corrected in v5, but it serves as a useful demonstration that both mistakes and subsequent fixes are preserved in the version history.

Find Versions Containing a Specific Column

If you need to answer a question such as:

"Which versions contained this column?"

you can use select and contains in jq:

TARGET_COLUMN="COLUMN_NAME"

aws glue get-table-versions \
  --database-name icebergdb \
  --table-name flights_1m \
  --no-paginate \
  --region ap-northeast-1 \
| jq --arg col "$TARGET_COLUMN" '
    .TableVersions[]
    | select(
        .Table.StorageDescriptor.Columns
        | map(.Name)
        | contains([$col])
      )
    | {version: .VersionId, updated: .Table.UpdateTime}
  '

Example output:

{
  "version": "4",
  "updated": "2026-06-12T05:20:48+00:00"
}

This confirms that the column double existed only in version 4.

Identify Who Changed the Schema with CloudTrail

While get-table-versions tells you when a schema changed, it does not tell you who made the change.

To identify the responsible user or role, you can correlate the schema update time with CloudTrail UpdateTable events.

Once you've identified the relevant timestamp, search CloudTrail around that period:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=UpdateTable \
  --start-time "2026-06-12T05:20:18+00:00" \
  --end-time "2026-06-12T05:21:18+00:00" \
  --region ap-northeast-1 \
| jq '.Events[] | {time: .EventTime, user: .Username, detail: .CloudTrailEvent | fromjson | .requestParameters}'

Example output:

{
  "time": "2026-06-12T05:21:18+00:00",
  "user": "XXXXX",
  "detail": {
    "catalogId": "123456789012",
    "databaseName": "icebergdb",
    "tableInput": {
      "name": "flights_1m"
    }
  }
}

The user field identifies the IAM user or role responsible for the update.

Additionally, detail.tableInput contains the updated table definition, allowing you to inspect the actual schema change directly from CloudTrail.

In many cases, reviewing UpdateTable events is sufficient.

However, depending on the tool or workflow being used, changes may also appear as:

CreateTable
BatchCreatePartition
Lake Formation-related events

If you cannot find the expected event, try expanding your search criteria.

Conclusion

In this article, we explored how to use aws glue get-table-versions to track schema changes in AWS Glue Data Catalog.

With this approach, you can:

Review schema history chronologically
Compare column additions and removals between versions
Identify which versions contained specific columns
Determine who made a change by correlating with CloudTrail

Glue Data Catalog is often viewed simply as a metadata catalog for current table definitions.

However, by leveraging Table Versions, it can also serve as a lightweight audit mechanism.

Because schema evolution is a fundamental feature of Apache Iceberg, understanding how to answer questions such as:

When did the schema change?
What changed?
Who changed it?

can be extremely valuable during troubleshooting and day-to-day operations.

I hope this article helps anyone managing Apache Iceberg tables with AWS Glue Data Catalog.

Organizing How to Use AWS Lake Formation

Aki — Mon, 08 Jun 2026 02:24:47 +0000

Original Japanese article: AWS Lake Formationの使い方について整理してみる

Introduction

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

Previously, I wrote an article titled Is AWS Glue Data Catalog Sufficient as a Data Catalog? Organizing Its Design, Limitations, and Complementary Strategies.
In that article, I mentioned that "AWS Lake Formation is necessary to complement data governance" but did not go into detail because it was outside the scope of the article.

This time, I'd like to organize my thoughts on Lake Formation, covering everything from the fundamentals to practical usage patterns.

Lake Formation is often perceived as a service that is "somewhat difficult" or "unnecessary because IAM is enough."
However, once you start implementing proper access control for a data lake, the necessity of Lake Formation becomes much clearer.

I hope this article helps you evaluate whether Lake Formation is worth adopting in your environment.

What Is Lake Formation?

AWS Lake Formation is a service that provides access management and governance for data lakes.

It allows you to centrally manage who can access which data and at what level.
One of its key strengths is the ability to manage access controls consistently across multiple AWS services such as Athena, Glue, and Redshift Spectrum.

Although they are often confused, Lake Formation and Glue Data Catalog serve different purposes.

Service	Role
Glue Data Catalog	A technical catalog that manages metadata such as schemas and partitions
Lake Formation	A governance layer that manages access permissions for data registered in the Glue Data Catalog

Amazon S3 (Actual Data)
        ↓
Glue Data Catalog (Metadata Management)
        ↓
Lake Formation (Access Control)
        ↓
Athena / Glue Job / Redshift Spectrum

In other words, data resides in S3, Glue Data Catalog manages metadata, and Lake Formation provides access control on top of that metadata layer.

How Lake Formation Differs from IAM

Isn't IAM Enough?

When managing a data lake on S3 using IAM alone, several challenges emerge:

Granularity limitations: IAM primarily operates at the bucket or prefix level, making table-, column-, and row-level access control difficult.
Operational complexity: As users and roles increase, S3 bucket policies and IAM policies become increasingly difficult to manage.
Cross-account sharing: Implementing data sharing across AWS accounts using only IAM can lead to complicated designs.
Limited visibility for auditing: It is difficult to easily understand who can access which tables.

Typical examples include:

More than ten Athena users need different levels of access, making permission management increasingly complicated.
Different departments should see different subsets of data. For example, the sales department should only see Eastern Japan sales, while executives can see all data.
Personally identifiable information (PII) such as email addresses and credit card numbers should be hidden from analysts.
Data needs to be shared with another AWS account.

Lake Formation addresses these challenges.

What Lake Formation Solves

With Lake Formation, you can implement:

Fine-grained table-, column-, and row-level access control
Permission management at the Glue Data Catalog database and table level
Tag-based access control (LF-TBAC) for large-scale environments
Cross-account data sharing through AWS RAM
Centralized auditing through CloudTrail integration

The Relationship Between IAM and Lake Formation

Lake Formation does not replace IAM; it works as an additional layer on top of IAM.

When a query is executed (for example, through Athena), access is granted only if both conditions are satisfied:

IAM Permission
        AND
Lake Formation Permission
        ↓
Access Allowed

Even if permissions are granted in Lake Formation, access is denied if IAM blocks it.

Likewise, even if IAM allows access, the request is denied if the corresponding Lake Formation permissions are missing.

Understanding this "AND" relationship is the foundation of permission design.

Lake Formation Permission Model

Lake Formation permissions are managed across multiple levels.

Level	Target	Example Permissions
Data Lake Administrator	Entire Lake Formation environment	Full permissions
Database Level	Glue Data Catalog database	CREATE TABLE, DROP
Table Level	Individual table	SELECT, INSERT, ALTER
Column Level	Specific columns within a table	SELECT on selected columns
Row Level	Rows matching specific conditions	SELECT on filtered rows

Permissions can be granted or revoked through the console, CLI, or SDK.

# Example: Grant SELECT permission on a table
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789:role/analyst-role \
  --permissions SELECT \
  --resource '{
    "Table": {
      "DatabaseName": "mydb",
      "Name": "sales_table"
    }
  }'

Column-Level and Row-Level Access Control

One of Lake Formation's strongest capabilities is fine-grained access control beyond the table level.

Both column-level and row-level security are implemented using a mechanism called Data Filters.
You create Data Filters in the console and reference them when granting permissions.

Column-Level Security

Access can be restricted to specific columns.

Suppose the customer table contains the following columns:

customer_id	name	email	credit_card	purchase_amount

You could allow analysts to access only customer_id, name, and purchase_amount, while hiding email and credit_card.

This can be achieved simply by specifying included or excluded columns in a Data Filter.
Excluded columns will not appear in Athena query results.

Row Filters

Row-level filters allow access only to rows matching specific conditions.

Filter expressions are written using PartiQL WHERE-clause syntax.

For example, if the sales table contains a region column and the Eastern Japan team should only see rows where region = 'east', you can create the following Data Filter:

aws lakeformation create-data-cells-filter \
  --table-data '{
    "TableCatalogId": "123456789012",
    "DatabaseName": "mydb",
    "TableName": "sales",
    "Name": "east-region-filter",
    "RowFilter": {
      "FilterExpression": "region = '\''east'\''"
    },
    "ColumnWildcard": {}
  }'

Combining column filters and row filters enables cell-level security, where users can access only specific columns within specific rows.

Data Filter Limitations

According to the official documentation:

Up to 100 filters per principal
array and map types are not supported in filter expressions (struct types can be used in row filters)
Cell-level security does not support nested columns, views, or resource links
Cell-level security is available in all regions when using Athena Engine Version 3 or Redshift Spectrum

Common Use Cases

Protecting PII such as email addresses and credit card numbers
Restricting business data by department or geographic region
Compliance requirements for regulated data

Tag-Based Access Control (LF-TBAC)

As the number of databases and tables grows, managing permissions table by table becomes increasingly difficult.

LF-TBAC (Lake Formation Tag-Based Access Control) addresses this problem.

What Are LF-Tags?

LF-Tags are key-value tags unique to Lake Formation.

They are separate from both S3 resource tags and IAM tags and are managed independently within Lake Formation.

aws lakeformation create-lf-tag \
  --tag-key "sensitivity" \
  --tag-values '["public", "internal", "confidential"]'

Tagging Resources and Mapping Permissions

LF-Tags can be assigned to databases, tables, and columns.

aws lakeformation add-lf-tags-to-resource \
  --resource '{"Table": {"DatabaseName": "mydb", "Name": "sales"}}' \
  --lf-tags '[{"TagKey": "sensitivity", "TagValues": ["internal"]}]'

Permissions are then granted based on tags rather than table names.

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789:role/analyst-role \
  --permissions SELECT \
  --resource '{
    "LFTagPolicy": {
      "ResourceType": "TABLE",
      "Expression": [{"TagKey": "sensitivity", "TagValues": ["public", "internal"]}]
    }
  }'

This grants SELECT access to all tables tagged with either sensitivity=public or sensitivity=internal.

When new tables are created, simply assigning the appropriate LF-Tag automatically applies the correct permissions.

Benefits in Large-Scale Environments

In environments with dozens or hundreds of tables, table-by-table permission management becomes unrealistic.

LF-TBAC enables a simpler model:

Roles can access data with specific tags.

However, tag design should be carefully planned from the beginning.
Defining categories such as sensitivity, domain, and owner early on can save significant effort later.

Integration with Glue Data Catalog

Lake Formation works closely with Glue Data Catalog.

Glue Data Catalog manages metadata, while Lake Formation governs access to that metadata.
Together they enable secure sharing and consumption of data stored in S3.

How Lake Formation Works with Data Catalog

When Lake Formation is enabled, access to Glue Data Catalog is routed through Lake Formation authorization checks.

This means that access to metadata itself—such as table definitions—can also be controlled.

Granting Lake Formation Permissions to Glue Jobs

When a Glue Job accesses data governed by Lake Formation, permissions must be granted not only through IAM but also through Lake Formation.

This is a common pitfall.

A typical issue is:

IAM permissions look correct, but the Glue Job still cannot read data.

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789:role/glue-job-role \
  --permissions SELECT \
  --resource '{
    "Table": {"DatabaseName": "mydb", "Name": "source_table"}
  }'

Cross-Account Sharing

Lake Formation supports cross-account data sharing through AWS RAM (Resource Access Manager).

Users in the target account can query shared tables directly from their own Athena environment.

Because Lake Formation permissions—including column and row filters—remain enforced, scenarios such as sharing data while excluding sensitive columns are supported.

To use cross-account sharing, the Data Catalog Cross Account Version setting must be configured to Version 3 or later.

Version 3 enables direct sharing with IAM principals in other accounts.
Version 4 adds support for hybrid access mode in cross-account scenarios.

Integration with Athena and Redshift Spectrum

Authorization Flow During Query Execution

When Athena accesses a Lake Formation-managed table:

A user executes a query in Athena.
Athena requests table metadata from Glue Data Catalog.
Lake Formation validates permissions.
If authorized, access to data in S3 is allowed.
Column and row filters are applied before results are returned.

This enables fine-grained access control without modifying S3 bucket policies.

Redshift Spectrum Integration

Since Redshift Spectrum also relies on Glue Data Catalog, Lake Formation permissions are enforced there as well.

This makes it easier to maintain consistent access control across Athena and Redshift Spectrum.

Adoption Challenges and Realistic Operations

Existing Environments: IAMAllowedPrincipals and Hybrid Access Mode

To preserve backward compatibility, Lake Formation grants the IAMAllowedPrincipals group Super permissions on existing Data Catalog resources by default.

In this state, access is effectively controlled by IAM alone, and Lake Formation's fine-grained controls are not enforced.

To fully leverage Lake Formation, these permissions must eventually be removed and replaced with explicit Lake Formation permissions.

However, switching everything at once can break existing workloads.

This is where Hybrid Access Mode becomes useful.

When registering S3 locations, Hybrid Access Mode allows selected principals to opt into Lake Formation authorization while other principals continue using IAM-only access.

This approach minimizes risk and enables gradual migration.

Personally, I believe this is the most practical approach for existing environments.

Common Pitfalls

Forgetting Lake Formation Permissions for Glue Jobs

As mentioned earlier, forgetting to grant Lake Formation permissions to Glue Job roles prevents ETL jobs from reading or writing data.

Many "it should work but doesn't" permission issues ultimately trace back to this.

I've forgotten it myself a few times and ended up scrambling to find the root cause.

Interaction with S3 Bucket Policies

Lake Formation does not override S3 bucket policies.

Even if access is granted in Lake Formation, requests are denied if the bucket policy blocks them.

When adopting Lake Formation, bucket policies must be designed to allow access through Lake Formation-authorized service roles.

Maintaining consistency among IAM, Lake Formation, and S3 bucket policies is critical.

Changing the design later can become painful, so it's worth thinking through carefully from the beginning.

Configuring Data Lake Administrators

When enabling Lake Formation for the first time, at least one Data Lake Administrator must be configured.

Relying on a single administrator can become an operational bottleneck, so I recommend assigning multiple administrators.

Athena Workgroups

When Athena Workgroups are used together with Lake Formation, behavior may vary depending on Workgroup configuration.

In particular, don't forget to grant permissions to the S3 bucket used for query results.

This is another thing I occasionally forget myself.

Incremental Adoption Strategy

For new environments, enabling Lake Formation from the start is usually the best option.

For existing environments, a phased approach tends to work better.

I've done this before, and while it's certainly possible, it's somewhat tedious.
If you're building a new environment, enabling Lake Formation from day one can save you trouble later.

Step 1: Gradual Opt-In with Hybrid Access Mode

Register S3 locations using Hybrid Access Mode
Opt in selected principals
Keep IAM-only access for others
Monitor access through CloudTrail

Step 2: Use Lake Formation for New Tables

Manage permissions for newly created tables through Lake Formation
Leave existing tables under IAMAllowedPrincipals

Step 3: Migrate Existing Tables

Gradually revoke IAMAllowedPrincipals permissions
Replace them with Lake Formation permissions
Validate behavior after each migration step

Where Lake Formation Excels—and Where It Doesn't

Lake Formation is particularly valuable for:

Fine-grained table-, column-, and row-level access control
Consistent authorization across Athena, Glue, and Redshift Spectrum
Scalable permission management using LF-TBAC
Cross-account data sharing

However, some areas remain outside its scope:

Direct access control to raw files in S3
Business metadata management
Data quality management

Relationship with Amazon DataZone

As discussed in my previous article, Lake Formation and DataZone have complementary responsibilities.

Service	Role
Lake Formation	Technical governance (who can access what)
Amazon DataZone	Business governance (discovering, understanding, and requesting data)

A useful way to think about them is:

Lake Formation = Technical foundation for governance
DataZone = Business foundation for governance

Combined with Glue Data Catalog, these services form a comprehensive data catalog and governance solution on AWS.

Conclusion

In this article, I reviewed AWS Lake Formation from its fundamentals through practical implementation patterns.

While there is a learning curve, it is an extremely important service for implementing proper data governance.

Key takeaways:

Lake Formation complements IAM rather than replacing it, adding fine-grained table-, column-, and row-level controls.
Column, row, and cell-level security are implemented through Data Filters.
LF-TBAC reduces operational overhead as the number of tables grows.
Lake Formation integrates tightly with Glue Data Catalog by adding a governance layer on top of metadata management.
Understanding IAMAllowedPrincipals and using Hybrid Access Mode for gradual adoption is essential in existing environments.

Lake Formation certainly introduces some complexity, but when implementing proper access control in a data lake, the limitations of IAM alone eventually become apparent.

In environments where data is consumed by multiple teams and a wide variety of users, Lake Formation is well worth considering.

That said, successful adoption depends on maintaining consistency across IAM, Lake Formation, and S3 bucket policies, so careful planning is essential.

I hope this article helps anyone considering the adoption of Lake Formation.

Rethinking Lakehouse Architecture Through Data Ownership: AWS vs. Snowflake

Aki — Mon, 01 Jun 2026 13:31:04 +0000

Original Japanese article: データの主導権から考えるAWSとSnowflakeのレイクハウスアーキテクチャ

Introduction

I'm Aki, an AWS Community Builder (@jitepengin).
When designing a data platform, discussions about whether to lean toward AWS or Snowflake are still very common.

However, with the rise of Apache Iceberg, data and platforms can now be decoupled. Because of this shift, I believe we need to reconsider the question itself.

Rather than asking:

Should we build around AWS or Snowflake?

A more fundamental question is:

Who owns the data?

In this article, I'd like to define what I mean by data ownership and explore the architectural trade-offs of AWS-centric and Snowflake-centric lakehouse designs.

Why Data Ownership Matters

Apache Iceberg has made it possible to separate data from the platform that accesses it.

Today, an Iceberg table stored on Amazon S3 can be accessed from Athena, Snowflake, Spark, and many other engines. As a result, choosing a product is becoming less important than deciding who is responsible for managing the data.

Before diving into architectural patterns, let's first examine why this shift matters.

Defining Ownership Across Three Layers

In this article, I define data ownership through the following three layers:

Layer	Question	Example
Catalog Ownership	Who owns the metadata?	Glue Data Catalog / Snowflake Open Catalog
Write Ownership	Who can update or delete data?	Glue ETL / Snowflake DML
Governance Ownership	Who controls access policies?	Lake Formation / Snowflake Horizon

Only when these three layers are consistently controlled by the same authority can we truly say that ownership exists.

Conversely, when ownership is distributed or unclear, complexity tends to emerge in architecture, operations, and security.

The Reality of Vendor Lock-In

Even in the Iceberg era, platform dependencies have not disappeared—they have simply changed form.

Catalog dependency: Tables managed by Snowflake Open Catalog still rely operationally on a Snowflake-managed service, although external engines can access them through the REST Catalog API.
Write-engine dependency: Snowflake-managed Iceberg tables are primarily updated through Snowflake, though Horizon Catalog now supports external writes from engines such as Spark. The choice of write engine remains closely tied to catalog design.
Governance dependency: Lake Formation's fine-grained permissions are fundamentally tied to the AWS ecosystem.

Therefore, saying that "Iceberg eliminates vendor lock-in" is only partially true.

What Iceberg removes is storage-format lock-in.

Dependencies around catalog management, governance, and operational processes still remain. In practice, migrating a data platform involves challenges such as governance policies, access control, metadata management, and platform-specific features.

Extensibility and Strategic Flexibility

Data platforms are never finished.

The rapid evolution of AI technologies and the continuous changes in the Modern Data Stack mean that architectures must adapt over time.

Common examples include:

Adding or changing analytics tools
Athena may be sufficient initially, but business users may later request Snowflake access.
Introducing AI workloads
Integration with SageMaker or Snowflake Cortex AI may become necessary.
Cost optimization initiatives
As query volumes grow, Snowflake compute costs may become significant, leading teams to move batch processing to EMR.
Stronger governance requirements
Column masking or row-level security may need to be introduced later.

When ownership across the three layers is clearly defined from the beginning, these changes become easier to evaluate and implement.

Without that clarity, every change raises new questions about where responsibilities and controls should reside.

What Changed After Iceberg?

Historically, data and platforms were tightly coupled.

	Snowflake-Centric	AWS-Centric
Data Location	Inside Snowflake	Inside S3
Management Ownership	Snowflake owns everything	AWS owns everything
Access from Other Engines	Not possible	Snowflake could not access directly

Iceberg fundamentally changed this model.

Iceberg Tables on S3
        ↓
Shared by Multiple Engines

Athena / Glue / Snowflake / Spark / Redshift ...

Iceberg adds a metadata layer on top of Parquet files stored in object storage, enabling ACID transactions and schema evolution independent of any specific compute engine.

A catalog tracks metadata such as schemas and active data files, allowing multiple engines to safely access the same table.

Data files are now shareable.

However, ownership of the catalog, write operations, and governance still depends on architectural decisions.

In other words, deciding who manages the catalog effectively determines who owns the data.

Major Iceberg Catalog Options

Catalog Type Characteristics

AWS Glue Data Catalog AWS-managed Supports REST Catalog API and integrates with Lake Formation governance

Snowflake Open Catalog Snowflake-managed (based on Apache Polaris) REST Catalog compliant and accessible from Spark, Trino, and others

Snowflake Horizon Catalog Snowflake service Exposes Snowflake-managed Iceberg tables through APIs; differs from Open Catalog because it is not a standalone metadata store

Catalog	Type	Characteristics
AWS Glue Data Catalog	AWS-managed	Supports REST Catalog API and integrates with Lake Formation governance
Snowflake Open Catalog	Snowflake-managed (based on Apache Polaris)	REST Catalog compliant and accessible from Spark, Trino, and others
Snowflake Horizon Catalog	Snowflake service	Exposes Snowflake-managed Iceberg tables through APIs; differs from Open Catalog because it is not a standalone metadata store

Snowflake-Centric Architecture

Characteristics

In this approach, Snowflake becomes the center of catalog management, governance, and analytics, while data files remain in external object storage such as S3.

This model prioritizes simplicity and a streamlined analytics experience.

Ownership Model

Layer	Owner
Catalog Ownership	Snowflake Open Catalog or Horizon Catalog
Write Ownership	Primarily Snowflake DML
Governance Ownership	Snowflake Horizon

Although data files remain on S3, external engines can access Snowflake-managed Iceberg tables through two mechanisms:

Via Open Catalog: Snowflake-managed Iceberg tables are synced to Open Catalog and exposed through the REST Catalog API. In this sync scenario, external engines have read-only access. (Note: when Open Catalog itself is used as an internal catalog, read/write access is supported.)
Via Horizon Catalog: Tables are exposed directly through the Horizon Iceberg REST Catalog API without syncing to Open Catalog. External engines can both read and write, and existing Snowflake users and roles can be used for access control.

Benefits

Governance policies such as column masking and row-level security can be applied to Iceberg tables in the same way as native Snowflake tables. When external engines access tables through Horizon Catalog, the same policies are enforced at read time. Note, however, that writing to tables with masking policies or tags applied is not supported from external engines — this is an important constraint to be aware of.
Rich ecosystem support for BI tools such as Power BI makes Snowflake a convenient analytics front end.
External engines can access Iceberg tables through Open Catalog or Horizon Catalog while reusing Snowflake users and roles as the unit of access control.

Drawbacks

Snowflake warehouse compute costs can be significant for write-heavy workloads. When external engines such as Spark write through Horizon Catalog, Snowflake warehouses are not used — but Horizon Catalog API calls are billed at 0.5 credits per million requests, so cost planning is still required.
Coordination is needed when AWS services such as Glue ETL also write to the same datasets. Clearly defining who holds catalog ownership is essential.

Even with Iceberg, many enterprises ultimately converge on a Snowflake-centric operating model because governance, metadata, and write operations all remain concentrated within Snowflake.

In such cases, Iceberg provides openness in theory, but ownership remains firmly within the Snowflake ecosystem.

AWS-Centric Architecture

Characteristics

This architecture uses S3 for storage, Glue Data Catalog for metadata, and AWS-native services for ETL, analytics, and governance.

Its primary advantages are flexibility and service interoperability.

Ownership Model

Layer	Owner
Catalog Ownership	AWS Glue Data Catalog
Write Ownership	Glue ETL / EMR
Governance Ownership	Lake Formation

Because Glue Data Catalog supports the Iceberg REST Catalog API, external engines such as Snowflake and Databricks can access the same tables.

This enables AWS to retain ownership while allowing Snowflake to serve as an analytics front end.

Benefits

Tight integration across Athena, Glue, EMR, and Redshift with a shared catalog.
Fine-grained column- and row-level governance through Lake Formation, applicable to Iceberg tables.
Ability to optimize compute engines for different workloads — EMR for large-scale batch, Athena for interactive queries.

Drawbacks

Increased architectural and operational complexity due to the number of AWS services involved.
Additional design considerations for multi-cloud environments, as the catalog remains AWS-dependent.

Lake Formation is powerful, but troubleshooting permission issues can become challenging. Identifying why a specific user cannot access a specific table or row often takes considerable time, requiring mature operational practices and careful permission design.

Combining AWS and Snowflake

A realistic approach is not choosing one platform over the other, but assigning clear responsibilities to each.

The key is defining ownership boundaries upfront.

AWS Owns the Data, Snowflake Powers Analytics

This is one of the most common patterns.

The goal is to maintain data ownership within AWS while leveraging Snowflake's analytics capabilities and its rich ecosystem of BI connectors.

┌──────────────────────────────────────────────────┐
│                       AWS                        │
│  S3 (Iceberg data files)                         │
│  Glue Data Catalog (Catalog Ownership)           │
│  Lake Formation (Governance Ownership)           │
│  Glue / EMR (Write Ownership)                    │
└──────────────────────┬───────────────────────────┘
                       │ Iceberg REST Catalog API
        ┌──────────────┼───────────────────┐
        ▼              ▼                   ▼
     Athena          Glue              Snowflake
  (Interactive)     (ETL)            (Analytics)

In this model:

Layer	Owner
Catalog Ownership	AWS
Write Ownership	AWS
Governance Ownership	AWS

Snowflake acts primarily as an analytical interface.

Two variations exist:

1. Glue Catalog Integration (Read-Only)

Snowflake accesses AWS-managed Iceberg tables through External Iceberg Tables. Write ownership and governance remain entirely with AWS. Lake Formation can be used as the single source of truth for access control.

2. Catalog-Linked Database (Read/Write)

Snowflake can update Iceberg tables through the Iceberg REST Catalog API while the data remains stored on S3. This approach is attractive when analysts and AI workloads primarily operate in Snowflake.

However, governance responsibilities become shared between AWS and Snowflake. Both Lake Formation and Snowflake-side access controls must be configured carefully — a misconfiguration in either can become a security gap. If the read-only pattern (option 1) is sufficient, consolidating governance in Lake Formation is simpler.

For step-by-step implementation details of these patterns — including how to set up External Volumes, Catalog Integrations, and Catalog-Linked Databases — see this companion article:

AWS Snowflake Lakehouse: 2 Practical Apache Iceberg Integration Patterns

Comparison: Three Architectural Patterns

Dimension	Snowflake-Centric	AWS-Centric	Hybrid
Catalog Ownership	Snowflake	AWS	AWS
Write Ownership	Snowflake	AWS	AWS
Governance Ownership	Snowflake Horizon	Lake Formation	AWS primary (①) / AWS+SF (②)
Compute Cost	Tends to be higher	Optimizable by workload	Optimizable by workload
Operational Complexity	Low to medium	Medium to high	High
Multi-Engine Flexibility	Medium (via REST API)	High	High

Choosing the Right Pattern

Based on the patterns above, here is a simplified decision guide:

Snowflake-centric tends to fit when:

Analytics is BI-driven or led by non-engineers
Development speed and analytics experience take priority over data volume
Centralized governance through Snowflake Horizon is preferred

AWS-centric tends to fit when:

Data volumes are large and ETL is the dominant workload
A dedicated data engineering team is already working within the AWS ecosystem
Fine-grained access control through Lake Formation is a requirement

Hybrid tends to fit when:

Different teams use different tools (e.g., engineers on AWS, analysts on Snowflake)
Future extensibility for AI, ML, or multi-engine workloads is a priority
AWS retains data ownership while Snowflake's query performance is still needed

What Happens When Ownership Is Unclear

A common anti-pattern is building a platform that "works" without explicitly defining ownership.

Typical symptoms include:

Nobody knows who is responsible for schema changes. When both Glue and Snowflake have schema owners, it becomes unclear which definition is authoritative.
Data written from Snowflake is not visible in Athena. When two catalogs attempt to manage the same table, one may lose track of the latest snapshot, causing metadata inconsistencies.
Governance rules drift between Lake Formation and Snowflake Horizon. Maintaining access policies in two places creates risk — a gap in either becomes a security vulnerability.
Incident response slows down. When multiple engines can write, identifying what happened and where becomes difficult, delaying recovery.

These issues often evolve from technical challenges into organizational problems:

Teams blame each other over unclear responsibilities.
Audits become difficult because nobody can fully explain who has access to what.
Incident recovery is delayed due to unclear decision-making authority.

A running system is not necessarily a well-designed system.

Ownership becomes increasingly difficult to fix after the platform has already grown.

"AWS or Snowflake?" Is a Secondary Question

In practice, organizations often begin by debating whether to standardize on AWS or Snowflake.

In the Iceberg era, I believe that is the wrong starting point.

The first questions should be:

Who owns the catalog?
Who owns writes?
Who owns governance?

Once these three ownership layers are defined, the platform choice naturally follows.

Want all three owned by Snowflake? → Snowflake-centric architecture.
Want all three owned by AWS? → AWS-centric architecture.
Want AWS to own data while Snowflake provides analytics? → Hybrid architecture.

Iceberg has dramatically increased flexibility around where data lives.

As flexibility increases, architects must become more deliberate about defining responsibility.

Starting with product selection often leads to contradictions later. A configuration where Snowflake is used as the query interface, Glue handles writes, and Lake Formation controls governance — without intentional design — is a classic symptom of ownership being distributed and unclear from the start.

The hardest challenge is no longer connectivity.

It is ownership.

Conclusion

Apache Iceberg has significantly reduced storage-level vendor lock-in.

However, catalog ownership, write ownership, and governance ownership still require deliberate architectural decisions.

A useful decision-making sequence is:

Decide who owns the catalog. (Glue / Snowflake Open Catalog / Snowflake Horizon)
Decide who owns writes. (AWS-native services / Snowflake)
Decide who owns governance. (Lake Formation / Snowflake Horizon / both)

Once those three decisions are made, choosing between AWS and Snowflake becomes much easier. From there, you can design the architecture that best fits your requirements.

Ultimately, the hardest part of a modern lakehouse architecture is often not the technology itself. It is agreeing on ownership boundaries — deciding which team manages the catalog, who is responsible for data updates, and where governance policies are enforced.

Technology evolves. The challenge of people and processes remains.

I hope this article helps anyone evaluating lakehouse architectures built on AWS, Snowflake, and Apache Iceberg.

Exploring Snowpark While Comparing It with Apache Spark

Aki — Mon, 01 Jun 2026 04:00:00 +0000

Original Japanese article: Snowparkを動かしながらSparkとの違いを整理してみる

Introduction

Recently, I've had more opportunities to work with Snowflake when building data platforms.

When working with modern data platforms, Apache Spark is often used for distributed data processing. Snowflake also provides its own data processing framework called Snowpark.

If you're already familiar with Spark or AWS Glue, you may find yourself wondering:

"Wait... how is Snowpark actually different from Spark?"

In this article, I'd like to organize my own understanding while exploring Snowpark's behavior and comparing it with Spark.

For this experiment, everything was done entirely within Snowflake Notebooks in Snowsight.

One of the biggest advantages is that no local environment setup or connection configuration is required—you can start experimenting immediately.

What is Snowpark?

Snowpark is a data processing framework provided by Snowflake.

Its biggest feature is the ability to write code in Python, Java, or Scala and execute it directly inside Snowflake.

Traditionally, Snowflake workloads were primarily implemented using SQL. With Snowpark, however, you can use a DataFrame API similar to Spark or Pandas while keeping all processing within Snowflake.

In other words, you no longer need to pull data into a local environment or AWS Lambda for processing.

Some key characteristics include:

Managed execution environment – Processing runs on Snowflake warehouses with no infrastructure management required.
DataFrame API – Similar developer experience to Spark and Pandas.
Pushdown execution – Code is executed within Snowflake, eliminating data transfer overhead.
UDF and UDTF support – Custom functions can be defined and executed inside Snowflake.
Snowflake Notebook integration – Interactive development is supported directly in Snowsight.

Personally, I still like Scala, but these days I write most data processing code in Python.

While Scala often offers better performance, Python's simplicity and extensive ecosystem make it the more practical choice in many situations.

Differences Between Spark and Snowpark

Many people immediately think of Spark when they hear the name Snowpark.

The names are similar, and the DataFrame APIs feel very familiar.

However, there are several important differences.

Aspect	Spark	Snowpark
Execution Environment	Distributed cluster	Snowflake warehouse
Data Source	HDFS, S3, and others	Primarily Snowflake tables
Scaling	Cluster size managed by user	Warehouse size adjustment
Languages	Scala, Java, Python, R, etc.	Python, Java, Scala
External Data Support	Broad ecosystem support	Primarily Snowflake-centric
Infrastructure Management	Cluster management required	Fully managed

Spark requires awareness of distributed clusters and execution mechanics.

Snowpark, on the other hand, is fundamentally a processing framework that operates on top of the Snowflake platform.

DataFrame operations are internally converted into SQL execution plans and executed by Snowflake's SQL engine.

Unlike Spark, user code is not distributed across worker nodes.

Scaling is handled by Snowflake warehouses.

UDFs are an exception. UDF code is pushed into Snowflake and executed in parallel by Snowflake's infrastructure.

A useful mental model is:

DataFrame operations → SQL generation

UDFs → Server-side parallel execution

In either case, users do not need to manage clusters or DAG execution as they would in Spark.

If your data is already centralized in Snowflake, Snowpark provides a convenient way to write Spark-like code without worrying about infrastructure management.

Of course, AWS Glue also provides a largely serverless experience, making it another convenient option in the AWS ecosystem.

Getting Started

All examples in this article are executed within Snowflake Notebooks in Snowsight.

No local Python environment or connection configuration is required—the entire workflow runs directly in the browser.

Prerequisites

From the Snowsight menu:

Create → Notebooks

Create a new notebook.

Snowpark for Python is already installed, so there is no need to run pip install.

You can start coding immediately.

Obtaining a Session

In local environments, Snowpark sessions are typically created using:

Session.builder.configs(...).create()

In Snowflake Notebooks, an active session already exists.

You can simply retrieve it:

from snowflake.snowpark.context import get_active_session

session = get_active_session()
print("Session acquired successfully!")

One of the major advantages of Snowflake Notebooks is that connection details never need to be written manually.

Basic DataFrame Operations

Let's create and manipulate a DataFrame from a table.

df = session.table("MY_DB.MY_SCHEMA.SALES_DATA")

result_df = df.select("ORDER_ID", "AMOUNT", "REGION") \
              .filter(df["REGION"] == "Asia") \
              .sort(df["AMOUNT"].desc())

result_df.show()

One important point is that no SQL is actually executed until show() is called.

We'll discuss this in more detail when covering lazy evaluation.

Aggregations

GroupBy operations feel almost identical to Spark.

from snowflake.snowpark import functions as F

summary_df = df.group_by("REGION") \
               .agg(
                   F.sum("AMOUNT").alias("TOTAL_AMOUNT"),
                   F.count("ORDER_ID").alias("ORDER_COUNT"),
                   F.avg("AMOUNT").alias("AVG_AMOUNT")
               )

summary_df.show()

When executed, these DataFrame operations are translated into SQL and run within Snowflake.

You can inspect the generated SQL using:

print(summary_df.queries)

Writing Results Back to a Table

To save results into a Snowflake table:

summary_df.write.mode("overwrite").save_as_table(
    "MY_DB.MY_SCHEMA.SALES_SUMMARY"
)

Since save_as_table() does not return a result, it's often useful to reload the table to verify the output.

session.table("MY_DB.MY_SCHEMA.SALES_SUMMARY").show()

The overwrite mode replaces the existing table.

Use append if you want to add rows instead.

How Does Lazy Evaluation Work?

Anyone familiar with Spark has likely encountered lazy evaluation.

Sometimes it can even lead to unexpected behavior during debugging.

Snowpark adopts the same fundamental concept.

Understanding Lazy Evaluation

DataFrame transformations such as:

select
filter
group_by

are not executed immediately.

These operations merely build an execution plan.

Actual execution occurs only when an action is triggered.

Common action operations include:

show()
collect()
count()
to_pandas()
write.save_as_table()

Verifying Lazy Evaluation

A convenient way to inspect behavior is through df.queries.

from snowflake.snowpark import functions as F

df_filtered = session.table("MY_DB.MY_SCHEMA.LARGE_TABLE") \
                     .filter(F.col("STATUS") == "ACTIVE") \
                     .select("ID", "NAME", "STATUS", "CREATED_AT")

print(df_filtered.queries)

result = df_filtered.collect()
print(f"{len(result)} rows retrieved")

The generated SQL can be inspected before execution, but no query has actually been sent to Snowflake yet.

To verify execution timing precisely, we can use Query History in Snowsight.

Open:

Monitoring → Query History

Then perform the following steps:

Define the DataFrame.
Check Query History.
Confirm that no SELECT statement has been executed.
Execute collect().
Refresh Query History.
Observe that the SELECT statement now appears.

Define the DataFrame

No corresponding query appears yet.

Execute collect()

After execution, the query becomes visible.

This confirms that DataFrame definitions alone do not trigger execution.

The SQL is executed only when collect() is called.

Differences from Spark's Lazy Evaluation

In Spark, lazy evaluation constructs a DAG that is optimized and executed across a cluster.

In Snowpark, lazy evaluation ultimately produces SQL, which is then optimized and executed by Snowflake's query optimizer.

The concept is similar, but the execution engine is fundamentally different.

One particularly useful feature is that generated SQL can be inspected via df.queries, making it easier to validate execution plans.

Can We Use Caching?

If you're coming from Spark, your first instinct may be to use cache().

Snowpark provides a similar capability through cache_result().

Differences from Spark cache()

Aspect	Spark `cache()`	Snowpark `cache_result()`
Storage	Memory (and disk)	Temporary table
Lifetime	Until application ends	Until session ends
Cost	No additional write	INSERT into temporary table

Internally, cache_result() materializes results into a temporary table.

Subsequent operations reuse that table rather than re-running expensive transformations.

Example

df_heavy = session.table("MY_DB.MY_SCHEMA.LARGE_TABLE") \
                  .filter(F.col("STATUS") == "ACTIVE") \
                  .join(
                      session.table("MY_DB.MY_SCHEMA.MASTER"),
                      "ID"
                  )

cached_df = df_heavy.cache_result()

result1 = cached_df.filter(
    F.col("REGION") == "Asia"
).collect()

result2 = cached_df.group_by("REGION") \
                   .agg(F.count("*")) \
                   .collect()

cached_df.drop_table()

Using a with block is often more convenient because the temporary table is automatically dropped when the block exits.

with df_heavy.cache_result() as cached_df:
    result1 = cached_df.filter(
        F.col("REGION") == "Asia"
    ).collect()

    result2 = cached_df.group_by("REGION") \
                       .agg(F.count("*")) \
                       .collect()

Since cache_result() performs an INSERT into a temporary table, it can actually make things slower when the DataFrame is only used once.

It's most effective when the same expensive transformation is reused multiple times.

You can also observe this behavior in Snowsight.

Temporary table creation:

Subsequent SELECT from the temporary table:

Another query reusing the same temporary table:

Use Cases

Let's consider some practical scenarios where Snowpark can be useful.

ETL Pipelines

Traditionally, pipelines often look like:

S3 → Glue → Redshift

With Snowpark, many transformations can be performed entirely within Snowflake.

This reduces data movement and simplifies overall architecture.

Example:

raw_df = session.table("MY_DB.MY_SCHEMA.RAW_EVENTS")

cleaned_df = raw_df \
    .filter(raw_df["EVENT_TYPE"] != "test") \
    .with_column(
        "EVENT_DATE",
        F.to_date(raw_df["EVENT_TIMESTAMP"])
    ) \
    .drop_duplicates([
        "USER_ID",
        "EVENT_DATE",
        "EVENT_TYPE"
    ])

aggregated_df = cleaned_df \
    .group_by("EVENT_DATE", "EVENT_TYPE") \
    .agg(
        F.count("USER_ID")
         .alias("USER_COUNT")
    )

aggregated_df.write.mode("overwrite") \
             .save_as_table(
                 "MY_DB.MY_SCHEMA.DAILY_EVENT_SUMMARY"
             )

session.table(
    "MY_DB.MY_SCHEMA.DAILY_EVENT_SUMMARY"
).show()

Custom Transformations Using UDFs

Snowpark UDFs allow complex logic that would be cumbersome in SQL to be implemented in Python.

You can register UDFs using either the @udf decorator or session.udf.register().

from snowflake.snowpark.functions import udf
from snowflake.snowpark.types import StringType

@udf(return_type=StringType(),
     input_types=[StringType()])
def normalize_region(region: str) -> str:
    region_map = {
        "US": "North America",
        "JP": "Asia",
        "DE": "Europe",
    }
    return region_map.get(region, "Other")

df = session.table("MY_DB.MY_SCHEMA.RAW_EVENTS")

df_with_region = df.with_column(
    "NORMALIZED_REGION",
    normalize_region(df["REGION_CODE"])
)

If type hints are available, explicit type definitions can be omitted:

from snowflake.snowpark.functions import udf

@udf
def normalize_region(region: str) -> str:
    region_map = {
        "US": "North America",
        "JP": "Asia",
        "DE": "Europe",
    }
    return region_map.get(region, "Other")

That said, simple transformations are often faster when implemented using built-in SQL functions.

As always, benchmark before deciding.

Data Quality Validation

Snowpark can also be used for data quality checks before processing continues.

total_count = df.count()
null_count = df.filter(
    F.col("AMOUNT").is_null()
).count()

null_rate = null_count / total_count

if null_rate > 0.10:
    raise ValueError(
        f"NULL rate exceeds the threshold: {null_rate:.1%}"
    )

print(
    f"Data quality check passed "
    f"(NULL rate: {null_rate:.1%})"
)

Conclusion

In this article, we explored Snowpark's fundamentals, compared it with Spark, and examined its lazy evaluation behavior.

For engineers already familiar with Spark, Snowpark should feel quite approachable.

However, it's important to remember that execution occurs on Snowflake warehouses rather than a Spark cluster.

Reviewing generated SQL and understanding how Snowflake executes queries can help avoid unexpected full-table scans and other performance issues.

If your data is already centralized in Snowflake, keeping processing inside Snowflake rather than moving data to Lambda or Glue Python Shell can be a significant advantage.

Reducing infrastructure management overhead and consolidating ETL processing within Snowflake can also improve maintainability.

One final note: throughout this experiment, I frequently relied on Cortex Code whenever I encountered errors.

The workflow of iteratively fixing notebook errors through Cortex Code was surprisingly convenient.

That said, just like any AI-assisted coding workflow, it's still important to carefully validate the generated code rather than accepting it blindly.

I hope this article helps anyone considering Snowpark for data processing within Snowflake.

DEV Community: Aki

Connecting Amazon S3 Tables and Snowflake (via the S3 Tables Iceberg REST Endpoint)

Introduction

Test Environment

Architecture

Differences from the Glue Route (Configuration)

Differences from the Glue Route (Setup Steps)

Creating the IAM Role

Creating the Catalog Integration

Setting Up the Trust Policy

Creating the Table

Verifying It Works (Read)

Confirming the Lake Formation Calls via CloudTrail

Verifying It Works (Write)

Checking Catalog-Linked Database

Confirming Auto-Discovery

Confirming Bidirectional Writes

How the Two Routes Compare

Conclusion

A Base Directory Mismatch Between Amazon S3 Tables and Snowflake CLD

Introduction

Auto-Sync Behavior of the Catalog-Linked Database

Test Environment

Looking at the Error Message

Verifying the Facts via Athena

Checking the current data file paths with $files

Going back through history with $snapshots

Checking S3 Tables' Spec in the Official Docs

Confirming It With CloudTrail

The table's complete history

Why Did CLD Keep Referencing the Old Location?

Reproduction Experiment

Trial 1: Not reproduced

Trial 2: Reproduced (data disappears)

Trial 3: Reproduced (UUID mismatch error + base directory error)

How I Recovered

Things to Keep in Mind Going Forward

Conclusion

Comparing AWS Glue Job's Default Mode and VPC Mode

Introduction

Test Environment

Test Architecture

Default Mode

VPC Mode

A Note on ENIs: There Are Two Kinds

Sample Code for Testing

Execution Time Comparison Results

Why the Gap Isn't Fully Explained by Overhead Alone

Choosing Between Default and VPC Mode

Cost Comparison

Thinking in Terms of Responsibility

Thinking in Terms of Security Requirements

Other Notes

Conclusion

Comparing the Permission Models of the Iceberg REST APIs Provided by Glue Data Catalog and S3 Tables

Introduction

Lining Up the Permission Mapping by Operation

The Number of IAM Actions Differs for Data Operations

The renameTable / namespaceExists Difference

The updateNamespaceProperties Difference

The dropTable purge Behavior Difference

S3 Tables' purge Behavior

Glue Data Catalog's purge Behavior

Summary of purge Behavior for Each

CloudTrail Granularity Also Reflects the API Design Split

Conclusion

Connecting Amazon S3 Tables with Snowflake

Introduction

Test Environment

Reading S3 Tables Data from Snowflake

Creating the IAM Role

Creating the CATALOG INTEGRATION

DESC CATALOG INTEGRATION

Setting Up the Trust Policy

Registering the Lake Formation Data Location

Lake Formation Grants (Three Tiers: Catalog, Database, Table)

CREATE OR REPLACE ICEBERG TABLE

Verification

Using a Catalog-Linked Database

Verification (Auto Detection)

Checking the current data file paths with `$files`

Going back through history with `$snapshots`

What is `get-table-versions`?