If you’ve built a “data lake” on AWS, you already know the trade-off: Amazon object storage is brilliantly cheap and flexible… but tables are a layer you normally have to assemble (and babysit) yourself.
S3 Tables is AWS’s answer rolled into the S3 service. These are purpose-built S3 storage, designed for tabular data that is managed as Apache Iceberg tables, with ongoing optimization and maintenance that is handled for you.
The three building blocks
S3 Tables introduces a simple hierarchy:
- Table bucket – a bucket type designed specifically for tables
- Namespace – a logical grouping (think “database”) inside a table bucket
- Table – the actual dataset (metadata + data files), stored as an Iceberg table
Security and governance
S3 Tables supports both:
- Identity-based permissions (IAM policies attached to roles/users)
- Resource-based policies (policies attached to table buckets and/or individual tables, with bucket policies able to scope to namespace/table)
If you integrate with Lake Formation, you can grant permissions at table/column/row granularity for supported engines (like Athena and Redshift).
Encryption is also “table-bucket native”:
- Default encryption is SSE-S3 (S3-managed keys), applied automatically.
- You can use SSE-KMS if you need customer-managed keys.
Costs to watch out for
With S3 Tables you still pay for storage and your query engine — but there are also table-specific operational charges, especially around maintenance.
From AWS pricing examples, S3 Tables includes charges such as:
- Compaction (priced per objects processed and per GB processed)
- Table updates (example pricing is shown per 1,000 table updates)
AWS has also announced significant compaction price reductions
Rule of thumb: if your ingestion pattern creates lots of small files (streaming/micro-batch), keep a close eye on maintenance behaviour and costs; “managed” doesn’t mean “free”.
When S3 Tables is a good fit (and when it isn’t)
S3 Tables is a strong fit when…
- You want an Iceberg-style lakehouse with less ops overhead (compaction/snapshot cleanup handled for you).
- You’re using (or plan to use) multiple engines that speak Iceberg
- You want tighter governance with a mix of IAM and (optionally) Lake Formation-style grants.
You might stick with “regular S3 + Iceberg tooling” when…
- You already have mature compaction/optimization pipelines and strong observability around them.
- Your workload has unusual optimisation needs you prefer to control explicitly.
Categories: AWS
greenchapel.dev 
Leave a comment