S3 Tables vs your own Iceberg on S3: cost and trade-offs

Amazon S3 Tables keeps your Apache Iceberg tables in a table bucket and runs their upkeep for you: it compacts small files, expires old snapshots and deletes files nothing uses any more. Your own Iceberg table in a general purpose S3 bucket uses the same Open Table FormatOpen Table FormatA published way of storing a table as plain data files plus a log of changes, so many engines can read and safely write it. Delta Lake and Apache Iceberg are the best known. and costs about 15% less to store, but those 3 jobs are yours to run. On a table of a few terabytes the difference is a few dollars to a few tens of dollars a month; it grows large only on very big tables that change little.

So the question is not "is S3 Tables cheaper". It is not, on the invoice. The question is whether your own maintenance, and the person who looks after it, costs less than the gap.

What you pay for in each

Prices are AWS's list prices for US East (N. Virginia), from its price list for Amazon S3.

Requests cost the same on both sides, so they never decide this. What you are comparing is a storage premium and 2 small fees on one side against the compute and the care that maintenance takes on the other. If you keep the table yourself, the managed option on AWS is the Glue Data Catalog's table optimizers, at $0.44 per DPU-hour (a DPU is 4 vCPU and 16 GB of memory).

A 10 TB table, both ways

Take a 10 TB event table. Writers add 1,000 GB a month in files of about 10 MB, and nobody has set a sort order, so compaction uses binpack.

The gap is $43.67 a month, 19% more. Of that, $35.84 is the higher storage price. Monitoring and compaction together are under $8.

$43.67 buys about 99 DPU-hours of Glue's optimizers. Whether your own maintenance stays under that depends on how often it runs and how much it rewrites, and AWS publishes no DPU figure per GB for its optimizers, so measure your own run before you count on it. Try your own table here:

Try itWhat S3 Tables adds to the bill

Table size

10 TB

1 TB50 TB500 TB

Written each month

1000 GB

1 MB10 MB100 MB

BinpackSort or z-order

S3 Tables$279

Storage $271Monitoring $2.62Compaction $5.20

Your own Iceberg on S3 Standard$236

The gap: $43.67 a month = about 99 DPU-hours of Glue table optimizers

Move the sliders and 3 things stand out:

• Size drives the gap, not traffic. A 500 TB table that takes 2,000 GB a month in 100 MB files costs about $13,156 a month in S3 Tables against $11,315 in S3 Standard. The gap, about $1,841, is almost all storage. This is where keeping the table yourself pays.
• Small files hardly move the fees. Going from 10 MB to 1 MB files on the 10 TB table adds under $2 of compaction, because the per-object fee is $0.002 per 1,000. Small files hurt the queries, not this bill.
• Sort and z-order double the per-GB fee. At $0.01 per GB the 10 TB table's compaction goes from $5.20 to $10.20. Worth it when your queries filter on the sort columns; the CompactionCompactionReplacing the older part of a long conversation with a summary, so an agent can keep working when its context fills up. concept shows why.

The maintenance you forget costs more than the premium

The comparison above assumes your own table is kept as tidy as S3 Tables keeps its own. Often it is not.

Iceberg never deletes a data file on its own. A compaction writes new large files, but the old small ones stay on S3, because the older snapshots still point at them. They go only when you expire those snapshots, and files left by failed jobs go only when you remove orphans. Iceberg's own docs list snapshot expiry and orphan removal as the maintenance every table needs.

On the 10 TB table, compacting 1 TB a month without expiring snapshots keeps that 1 TB of small files. By our sum, after 6 months that is 6 TB of dead files at $0.023, about $141 a month, 3 times the S3 Tables premium, and still growing. Every MERGE and overwrite adds more. A self-managed table with compaction running and no snapshot expiry is the most expensive of the 3 setups.

What S3 Tables runs for you, and what Glue runs if you ask

The auto strategy in S3 Tables uses sort compaction when the table has a sort order in its metadata and binpack when it has none. Glue's optimizers offer the same 3 strategies and work on Iceberg v3 tables, which S3 Tables also supports (deletion vectors, row lineage, the variant type).

The catches in S3 Tables

AWS's documentation lists these. Each one has caught teams that assumed a table bucket behaves like a normal bucket with Iceberg in it.

1. Snapshot management stops for the whole table if the table has any user-defined tag or branch, or if history.expire.max-snapshot-age-ms or history.expire.min-snapshots-to-keep is set as a table property. Nothing expires and storage grows. Set retention through the maintenance API, not table properties, and check get-table-maintenance-job-status for a FAILED status.
2. Deletes are permanent. Once a file has been noncurrent for nonCurrentDays, it is gone. Seeing or recovering a noncurrent file needs AWS Support.
3. Slow commits lose files. A streaming writer that uploads a file and commits it later can see that file marked as unreferenced first. Set unreferencedDays longer than your longest gap between writing a file and committing it, retries included.
4. Compaction can clash with your writers. Iceberg resolves concurrent commits optimistically, so a write can fail when compaction commits first. Compaction retries; give your pipeline retries too.
5. The storage class is fixed at creation. A table starts in S3 Standard and cannot be moved to Intelligent-Tiering later. Intelligent-Tiering inside S3 Tables also costs more than its S3 twin: $0.0144 per GB-month for Infrequent Access against $0.0125, and $0.0046 for Archive Instant Access against $0.004. Compaction skips the colder tiers, so delete files on old data wait until that data is read again.
6. It is not a general purpose bucket. No public access, no presigned URLs for a table's files, and default quotas of 10,000 tables per table bucket and 100 table buckets per Region.
7. Compaction has format limits: Parquet, Avro and ORC only, no brotli or lz4 compression and no Fixed type.

In return you get things a normal bucket does not have: IAM policies on single tables in their own s3tables namespace, replication of whole tables to other Regions or accounts with commits in order, and higher transactions a second and query throughput than a self-managed table in a general purpose bucket (AWS's pricing page says up to 3 times faster queries and up to 10 times more transactions a second).

Keeping it yourself: the 3 jobs

If you keep your own Iceberg table in a general purpose bucket, these 3 Spark procedures are the maintenance, run on EMR, Glue or any Spark with the Iceberg runtime. The names and arguments are from Iceberg's own docs.

-- 1. Compaction: rewrite small files into large ones (sort or z-order when you filter on columns)
CALL glue_catalog.system.rewrite_data_files(
  table => 'sales.events',
  strategy => 'sort',
  sort_order => 'zorder(customer_id, event_date)'
);

-- 2. Snapshot expiry: drop snapshots older than 5 days, keep at least 1 (both are the defaults)
CALL glue_catalog.system.expire_snapshots(
  table => 'sales.events',
  older_than => TIMESTAMP '2026-10-18 00:00:00',
  retain_last => 1
);

-- 3. Orphan files: list first, then delete
CALL glue_catalog.system.remove_orphan_files(table => 'sales.events', dry_run => true);

Run expiry after compaction, or the compacted-away files stay. Run orphan removal last, with an age longer than your slowest commit, for the same reason as catch 3 above. Glue's own orphan optimizer adds 2 rules worth knowing: it never deletes files created before the optimizer was, and it scans the whole table location, so a location shared with other data can lose files that are not orphans at all.

Running Spark on these jobs is ordinary Spark tuning; our Spark shuffle partition calculator helps size a sort compaction. The tools that read the table are the same either way. Athena, for one, charges by the data it scans whichever bucket holds the files, and well-compacted files keep that bill down: see what an Athena query costs.

Which to choose

Choose S3 Tables when you have many tables and no one whose job is their upkeep, when writers make many small files (streaming, frequent MERGEs), when you want table-level IAM or ordered cross-Region replicas, or when the gap in the widget is smaller than a few hours of an engineer's month.

Keep your own Iceberg when the table is hundreds of terabytes and changes little, so the storage premium is large and maintenance is light; when another catalog must own the table's metadata, when you need presigned URLs, or Iceberg tags and branches for releases or audits; or when you already run Spark jobs that can take the 3 procedures on.

Both are the same Iceberg underneath, so the choice is not forever: any Iceberg engine reads either. If you are still choosing the format itself, read Delta Lake vs Apache Iceberg, and for where tables like these sit in a data platform, the LakehouseLakehouseOne store for all of an organisation's data: cheap files in cloud storage, as in a data lake, with the tables, transactions and fast queries of a data warehouse on top. concept.