NOTE

Vendor-neutral edition of the Bronze/Silver cost model. Companion to Iceberg Interoperability Has a Bill and iceberg-athena-vs-snowflake-calculator.xlsx.

Bronze and Silver Compute: Athena vs. Snowflake — Cost Calculator Method

Prepared for	Data platform teams evaluating Athena for Bronze and Silver processing on Iceberg
Prepared by	Ed Ost
Status	Vendor-neutral method note; illustrative inputs
Version / date	1.0 — 2026-10-30 (vendor-neutral edition of the 0.2 cost model)
Pricing current as of	2026-09-30 (published list prices; see Section 4)
Companion workbook	iceberg-athena-vs-snowflake-calculator.xlsx — performs every calculation in this document; inputs are editable

---

0. Read this first

This document gives a rough order of magnitude (ROM) estimate of the annual compute cost difference between running Bronze-tier standardization and Silver-tier conforming and de-duplication in Amazon Athena versus Snowflake. It covers two Athena pricing models: on-demand (per TB scanned) and capacity reservations (per DPU-hour).

Before using any number here, note the following:

1. Not based on any organization’s data. Every workload figure is an illustrative assumption for a large enterprise, such as a large bank or a multi-hospital health system. None of it is measured from a real system. The purpose is to size the opportunity and show which inputs matter, not to forecast any particular bill.
2. Wide uncertainty. Treat each result as accurate to roughly ±50% at best. The two models depend on different unknowns, and the reservation model’s key input (Section 7.2) can move the result from a net loss to a large saving.
3. List prices, not contract prices. Snowflake and AWS enterprise agreements typically include discounts and commitments that change both sides of the comparison. Section 4 states the one discount assumption used.
4. Not a vendor pricing commitment from AWS, Snowflake, or any other party.
5. Designed to be replaced by measurement. Section 9 gives the queries and benchmark steps that replace the assumptions with your own figures. The results should be recalculated once those are available.
6. Invalid inputs are flagged, not hidden. The workbook rejects a zero, blank or out-of-range value typed into an input cell. A pasted value can get past that check, so cell A4 on each Outcomes tab reads Inputs OK, or shows a red CHECK INPUTS warning. A formula that divides by an input returns 0 instead of an error when that input is 0, so ignore every result while the warning shows. The plausible-band rows show “n/a” when no baseline row is flagged Y.

---

1. Summary

Question: if Bronze and Silver processing moves from Snowflake warehouses to Athena, what is the likely annual net compute saving?

Answer, for an assumed current Snowflake spend of 1M–4M a year on these two tiers:

Athena pricing model	Conservative assumptions	Mid assumptions	Optimistic assumptions
On-demand (per TB scanned)	0.06M – 0.76M	0.21M – 1.34M	0.32M – 1.79M
Capacity reservations (per DPU-hour)	–0.16M – –0.12M (a net cost)	0.33M – 1.78M	0.56M – 2.69M

Net figures are after offsets for table maintenance, Snowflake-side refresh of Silver data, and running a second governance estate. Sections 6.4 and 7.4 give the full matrices, including a 0.4M and a 1.5M baseline.

Key findings:

• Both models plausibly save money at the mid assumptions, but for different reasons. On-demand wins when Snowflake warehouses are under-used relative to the data they scan. Reservations win when Athena’s engine can do a Snowflake credit-hour’s worth of work with modest capacity.
• Reservations have the higher upside and a real downside. The outcome depends almost entirely on one unmeasured ratio: how many Athena DPU-hours it takes to match one Snowflake credit-hour of work (Section 7.2). At the conservative value, reservations cost more than they save.
• On-demand’s main risk is re-scanning. Frequent MERGE statements into large Silver tables re-read those tables each run. Because on-demand bills per TB read, high-frequency micro-batching erodes its advantage.
• At a $0.4M baseline, neither model reliably pays back the fixed cost of operating a second governance estate.
• In practice a hybrid is likely: reservations for steady, predictable CDC processing, on-demand for bursty or ad-hoc work. Section 8 explains how to decide.

---

2. Scope

In scope:

• Compute for Bronze standardization (type, format and code standardization of landed CDC data).
• Compute for Silver conforming and de-duplication (joins to reference data, MERGE into conformed tables, de-duplication).
• Direct offsets caused by the move: Iceberg table maintenance, Snowflake-side refresh of Silver data, and operating two governance estates.

Out of scope (each is material and should be assessed separately):

Item	Why excluded
CDC landing and apply into Bronze	Depends on the ingestion architecture (Section 3). May be a larger lever than Bronze and Silver transforms.
Gold-tier processing	Stays in Snowflake in both architectures.
Storage	Iceberg data sits in S3 in both cases; storage cost doesn’t change.
Cross-region egress	All components assumed to be in one AWS region.
Software licensing (ingestion tooling, Snowflake, AWS support)	Not compute.
One-time migration and SQL-rewrite effort	Not a run-rate cost; see Section 8.3.

---

3. Architectural context

The comparison only applies where Athena can actually do the work.

Architecture	Can Athena perform Bronze and Silver processing?	Applicability of this ROM
Lake-owned catalog — CDC lands in Iceberg tables catalogued in AWS Glue. Silver is registered in Snowflake as externally managed Iceberg tables for Gold.	Yes. Athena reads and writes Glue-catalogued Iceberg tables natively.	Directly applicable.
Snowflake-centric — CDC lands in Snowflake-managed Iceberg tables (Horizon catalog).	Only with split ownership. Athena SQL can’t write to Snowflake-managed Iceberg tables. It works only with Iceberg tables in the Glue catalog, and its path to Horizon (Glue catalog federation) is read-only. Silver tables would have to be Glue-owned and read back into Snowflake.	Applicable to the split-ownership pattern, plus small Horizon catalog API charges (0.5 credits per million calls). Athena for Apache Spark writing directly to Horizon is not modeled here (Section 8.3).

One technical constraint affects both architectures: Athena SQL operates only on Iceberg v2 tables. Any table Athena must read or write has to remain v2.

---

4. Pricing inputs

Input	Value used	Source / note
Athena SQL on-demand	$5.00 per TB scanned, 10 MB minimum per query	AWS Athena pricing page
Athena capacity reservation	$0.30 per DPU-hour; minimum 4 DPUs; 1-minute reservations (since Feb 2026)	AWS pricing page; AWS announcement 2026-02-10
Athena DPU	”typically 4 vCPUs and 16 GB of memory”	Athena User Guide, capacity management
S3 requests and Glue catalog calls	~$0.50 per TB scanned (≈10% uplift on the on-demand rate)	Assumption. S3 GET 0.40 per million, LIST 5.00 per million; varies with file layout
Snowflake credit	$3.50	Assumption: Business Critical list price on AWS US East is ~$4.00 per credit; a ~12.5% contract discount is assumed
Snowflake warehouse sizes	M = 4, L = 8 credits/hour (Gen1). Gen2 = 1.35× on AWS	Published Snowflake rates
Snowflake billing	Per second, 60-second minimum each time a warehouse resumes	Published Snowflake billing rules
Fully loaded engineer cost	$200K per FTE-year	Assumption, used for the governance offset

---

5. Common assumptions (both models)

5.1 Baseline: current Snowflake spend on Bronze and Silver

Four baselines are modeled. They are expressed as the equivalent number of Large (8 credits/hour) warehouses running 24×7 at $3.50 per credit, as a sanity anchor:

Baseline (annual Snowflake compute, prod + non-prod)	Credits per year	≈ Large warehouses running 24×7
$0.4M	~114K	~1.6
$1.0M	~286K	~4
$1.5M	~429K	~6
$4.0M	~1.14M	~16

Assumption: a large enterprise, such as a large bank or a multi-hospital health system, most plausibly falls in the 1M–4M band for these two tiers. The largest global enterprises would likely exceed 10M. 0.4M is included as a lower bound.

5.2 Offsets (costs that exist only after moving to Athena)

Offset	Value	Rationale
Iceberg table maintenance (compaction, snapshot expiry, orphan-file cleanup)	10% of Athena compute	On Snowflake-managed tables this is handled by Snowflake. On Glue-owned tables it becomes an explicit job (Athena OPTIMIZE/VACUUM, Glue table optimizers, or the ingestion tool’s own optimizer).
Snowflake-side refresh of Silver data	$0.02M a year	Metadata refresh of mirrored or catalog-linked tables so Gold can read Silver.
Second governance estate	0.15M / 0.20M / 0.25M / 0.40M for the four baselines (≈0.75–2 FTE)	Access policies, row filters and masks must be maintained in AWS Lake Formation as well as Snowflake. Policies do not carry across catalogs.

---

6. Analysis A — Athena on-demand (per TB scanned)

6.1 How the comparison works

The two services bill on different units:

• Snowflake bills by time. An hour of a running warehouse costs credits per hour × $ per credit, whatever that hour accomplishes, including idle time before auto-suspend and 60-second resume minimums.
• Athena on-demand bills by data read. Scanning X TB costs $5 × X, however long it takes.

Setting the two equal gives the break-even throughput, the TB a warehouse must scan per billed hour to be cheaper than Athena:

credits/hour × /credit = 5 × X → X = (credits/hour × /credit) ÷ 5

Warehouse	Cost per billed hour at $3.50/credit	Break-even at $5.00/TB	Break-even at $5.50/TB (incl. S3/Glue)
Medium (4 credits/hour)	$14	2.8 TB/hour	2.5 TB/hour
Large (8 credits/hour)	$28	5.6 TB/hour	5.1 TB/hour

A warehouse scanning below this rate, averaged over every billed hour, is more expensive than Athena on-demand for the same scans.

6.2 Model

The break-even is generalized using the effective Snowflake cost per TB scanned, S:

S = (Snowflake credits billed × $/credit) ÷ TB scanned by the same warehouses

• Athena compute = B × (k × A) ÷ S
• Gross saving = B − Athena compute
• Net saving = gross saving − maintenance (10% of Athena compute) − Snowflake refresh − small-query minimum uplift − governance offset

where B = baseline Snowflake spend, A = $5.50 (Athena on-demand plus S3/Glue overhead), and k = TB Athena scans ÷ TB Snowflake scans for the same work.

6.3 Parameters

Parameter	Conservative	Mid	Optimistic	Basis
S — Snowflake effective $ per TB scanned	$9.50	$12.00	$15.00	Assumption. Measurable directly (Section 9.1).
k — Athena ÷ Snowflake bytes scanned	1.1	1.1	1.1	Assumption. Pruning and caching differ between engines; ±30% uncertainty.
Small-query minimum uplift	$0.02M	$0.02M	$0.02M	Upper-bound illustration: ~1M queries a day each billed at the 10 MB minimum ≈ 10 TB/day ≈ $18K a year.
Resulting gross saving	36%	50%	60%	1 − (k × A ÷ S)

6.4 Results (annual, $M)

Baseline	Athena compute (Cons / Mid / Opt)	Gross saving (Cons / Mid / Opt)	Net saving (Cons / Mid / Opt)
$0.4M	0.25 / 0.20 / 0.16	0.15 / 0.20 / 0.24	–0.07 / –0.01 / 0.03
$1.0M	0.64 / 0.50 / 0.40	0.36 / 0.50 / 0.60	0.06 / 0.21 / 0.32
$1.5M	0.96 / 0.76 / 0.61	0.55 / 0.74 / 0.90	0.16 / 0.38 / 0.54
$4.0M	2.55 / 2.02 / 1.61	1.45 / 1.98 / 2.39	0.76 / 1.34 / 1.79

Worked example (1.5M baseline, mid): Athena compute = 1.5 × (1.1 × 5.50) ÷ 12.00 = 0.76M. Gross saving = 0.74M. Net = 0.74 − 0.076 (maintenance) − 0.02 (refresh) − 0.02 (small queries) − 0.25 (governance) ≈ **0.38M**.

6.5 What moves the on-demand result

Factor	Effect
MERGE frequency × Silver table size	Each MERGE re-reads the target partitions it touches. Batches every 5–15 minutes into large, poorly partitioned tables multiply TB scanned, pushing S down and the saving toward zero or below. Hourly or daily batches on well-partitioned tables favor Athena.
Snowflake warehouse utilization	Idle time, oversized warehouses and 60-second resume minimums all raise S, which favors Athena.
Athena DML concurrency quotas	On-demand DML is subject to per-account concurrency quotas. High-frequency processing across thousands of tables must be checked against them. Reserved capacity is not subject to these quotas.
File layout	Many small files increase S3 request charges. Keep compaction current.

---

7. Analysis B — Athena capacity reservations (per DPU-hour)

7.1 How the comparison works

Reserved queries incur no per-TB scan charge. You pay for DPUs held, per minute, whether or not they are busy. This makes the comparison time-for-time, like Snowflake, so the question becomes:

How much Athena capacity does it take to do the useful work of one Snowflake credit-hour, and how fully is each side’s paid capacity used?

The break-even formula from Analysis A does not apply here.

7.2 Model

• Productive Snowflake credit-hours = (B ÷ p) × Usf
• Athena DPU-hours reserved = productive credit-hours × E ÷ Uath
• Athena compute = DPU-hours reserved × $0.30 + S3/Glue request overhead
• Net saving = B − Athena compute − maintenance (10% of reservation cost) − Snowflake refresh − governance offset

where:

• p = $3.50 per credit.
• Usf = fraction of billed Snowflake warehouse time spent actually running queries.
• E = Athena DPU-hours needed to do the work of one productive Snowflake credit-hour. This is the key unknown. Snowflake does not publish the hardware behind a credit, so E can only be established by benchmark (Section 9.2).
• Uath = fraction of reserved DPU time in use. It reflects peak-to-average sizing and how actively the reservation is scaled; reservations can be adjusted in 1-minute increments.
• S3/Glue overhead is estimated at 0.50 per TB scanned, with scan volume derived from the on-demand mid case (*S* = 12, k = 1.1).

Break-even value of E, ignoring offsets: E* = (Uath × p) ÷ (Usf × $0.30). Athena reservations are cheaper whenever the true E is below E*.

7.3 Parameters

Parameter	Conservative	Mid	Optimistic	Basis
Usf — Snowflake productive fraction	0.7	0.6	0.5	Assumption. Measurable (Section 9.1).
E — DPU-hours per Snowflake credit-hour	8	5	3	Assumption — least certain input. Must be benchmarked.
Uath — reservation utilization	0.6	0.7	0.8	Assumption. Depends on scheduling discipline.
Break-even E*	10.0	13.6	18.7	Formula above
Resulting gross saving (before S3/Glue)	20%	63%	84%	1 − (Usf × E × 0.30) ÷ (Uath × p)

Reading the mid case: reservations beat Snowflake unless it takes more than about 14 Athena DPU-hours (≈54 vCPU-hours at 4 vCPUs per DPU) to do what one productive Snowflake credit-hour does.

7.4 Results (annual, $M)

Baseline	Reservation cost (Cons / Mid / Opt)	Avg. reserved DPUs (Cons / Mid / Opt)	Net saving (Cons / Mid / Opt)
$0.4M	0.32 / 0.15 / 0.06	122 / 56 / 24	–0.14 / 0.05 / 0.14
$1.0M	0.80 / 0.37 / 0.16	304 / 140 / 61	–0.15 / 0.33 / 0.56
$1.5M	1.20 / 0.55 / 0.24	457 / 210 / 92	–0.16 / 0.56 / 0.90
$4.0M	3.20 / 1.47 / 0.64	1,218 / 559 / 245	–0.12 / 1.78 / 2.69

Each net figure also deducts S3/Glue request overhead of 0.02M / 0.05M / 0.07M / 0.18M for the four baselines.

Worked example (1.5M baseline, mid): productive credit-hours = 1.5M ÷ 3.50 × 0.6 ≈ 257K. DPU-hours reserved = 257K × 5 ÷ 0.7 ≈ 1.84M. Cost = 1.84M × 0.30 ≈ 0.55M, plus 0.07M S3/Glue. Gross saving ≈ 0.88M. Net = 0.88 − 0.055 (maintenance) − 0.02 (refresh) − 0.25 (governance) ≈ **0.56M**.

7.5 Reservation-specific constraints

Constraint	Implication
Maximum 1,000 DPUs per account per region across all reservations	The conservative $4M case (≈1,218 average DPUs, higher at peak) exceeds this. It would need multiple AWS accounts, a quota review, or on-demand overflow.
DML queries are allocated 4–124 DPUs each, automatically	Concurrency scales with reservation size. Queued queries wait up to 10 hours.
Queries on reserved capacity do not count against DML/DDL quotas	Removes the on-demand concurrency concern for high-frequency CDC.
Maximum 20 workgroups per reservation; Spark workgroups not supported	Workgroup design must align with reservations.
Utilization is an operational discipline	Savings depend on scaling reservations to the processing schedule, for example with scheduled resizing driven by configuration. Idle reserved DPUs are billed.

---

8. Comparing the two models

8.1 Where each wins

Workload characteristic	Favors
Steady, predictable, continuous CDC processing	Reservations
Bursty, irregular, or ad-hoc processing	On-demand
Frequent MERGE into very large tables (high scan volume per unit of work)	Reservations (no per-TB charge)
Many very small queries	Reservations (no 10 MB-per-query minimum)
Low, unpredictable volume; no appetite to manage capacity	On-demand

8.2 Choosing between them using Athena’s own numbers

For a given workload, reservations beat on-demand when each reserved DPU-hour does more than 0.30 ÷ 5.00 = 0.06 TB (60 GB) of scanning, measured at the achieved utilization. Running the same workload once in each mode gives this directly. Both modes can coexist in one account, so a hybrid split by workgroup is practical.

8.3 Factors outside both models

• Snowflake capacity commitments. If you have a multi-year Snowflake commitment, reduced consumption lowers the bill only at renewal. Until then the saving shows up as credits freed for other workloads.
• One-time costs (not included): rewriting Snowflake SQL and procedures for Athena’s SQL dialect, parallel running, and validating results between the two.
• CDC apply compute. In the Snowflake-centric architecture, continuous CDC apply into Bronze also consumes Snowflake warehouse credits. Moving that apply out of Snowflake could be a larger lever than Bronze and Silver transforms and should be modeled separately.
• Athena for Apache Spark ($0.35 per DPU-hour) is not modeled. It is time-billed like reservations but has its own efficiency ratio E, and it is the only Athena option that could write directly to Snowflake-managed Iceberg tables (unverified; requires a test).
• Iceberg v2 constraint. Athena SQL operates only on v2 tables, which rules out v3 deletion vectors for any table Athena touches.

---

9. Calibration plan: replacing assumptions with measurements

9.1 From Snowflake (if the workload already runs there)

Effective cost per TB scanned (S):

SET price_per_credit = 3.50;   -- replace with contracted rate
 
WITH q AS (
  SELECT warehouse_name,
         SUM(bytes_scanned) / POWER(1024, 4) AS tb_scanned
  FROM snowflake.account_usage.query_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  GROUP BY 1
), m AS (
  SELECT warehouse_name, SUM(credits_used) AS credits
  FROM snowflake.account_usage.warehouse_metering_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  GROUP BY 1
)
SELECT q.warehouse_name, tb_scanned, credits,
       credits * $price_per_credit / NULLIF(tb_scanned, 0) AS usd_per_tb_scanned
FROM q JOIN m USING (warehouse_name)
WHERE q.warehouse_name IN ('BRONZE_WH', 'SILVER_WH');   -- replace with actual names

Interpretation: below ~6 per TB, on-demand savings are marginal. 9.50–15 corresponds to this document's range. Above 15, savings exceed the optimistic case.

Productive fraction (Usf), approximate:

SET credits_per_hour = 8;   -- warehouse size (L = 8; multiply by 1.35 for Gen2)
 
WITH busy AS (
  SELECT warehouse_name,
         SUM(IFF(avg_running > 0, DATEDIFF(second, start_time, end_time), 0)) / 3600 AS busy_hours
  FROM snowflake.account_usage.warehouse_load_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  GROUP BY 1
), billed AS (
  SELECT warehouse_name,
         SUM(credits_used_compute) / $credits_per_hour AS billed_hours
  FROM snowflake.account_usage.warehouse_metering_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  GROUP BY 1
)
SELECT b.warehouse_name, busy_hours, billed_hours,
       busy_hours / NULLIF(billed_hours, 0) AS u_sf_proxy
FROM busy b JOIN billed m USING (warehouse_name)
WHERE b.warehouse_name IN ('BRONZE_WH', 'SILVER_WH');

This is a proxy: it counts any interval with a running query as fully busy, and it assumes a single fixed warehouse size (run it per warehouse for multi-cluster or resized warehouses).

9.2 From a side-by-side benchmark

1. Choose a representative set of Bronze and Silver statements (e.g., 20–50), including the largest MERGE targets and the most frequent micro-batches.
2. Run them in Snowflake and record per-statement credits (ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY, which attributes compute to queries and excludes warehouse idle time, matching the “productive credit-hour” in E) and bytes scanned.
3. Run the same statements in an Athena on-demand workgroup and record data scanned per query. This gives k.
4. Run them in an Athena workgroup attached to a fixed-size reservation and record elapsed time × DPUs. Dividing by the Snowflake credits for the same statements gives E.
5. Replace the assumptions in Sections 6.3 and 7.3 with the measured values and recompute.

9.3 Inputs needed from your environment

Input	Used for
Current or projected Snowflake spend on Bronze and Silver (prod and non-prod)	Baseline B
Contracted Snowflake credit price and commitment terms	p; timing of realized savings
CDC batch frequency and size of the largest Silver MERGE targets	Scan amplification, S, and the choice of on-demand vs. reservations
Number of source tables in scope	Small-query uplift; concurrency sizing
Target architecture (lake-owned catalog or Snowflake-centric)	Applicability (Section 3)

---

Appendix A — Formula reference

Symbol	Meaning
B	Baseline annual Snowflake compute spend for Bronze and Silver
p	Snowflake $ per credit
S	Snowflake effective $ per TB scanned
A	Athena on-demand effective per TB, including S3/Glue (5.50)
k	Athena TB scanned ÷ Snowflake TB scanned for the same work
Usf	Productive fraction of billed Snowflake warehouse time
Uath	Utilized fraction of reserved Athena DPU time
E	Athena DPU-hours per productive Snowflake credit-hour

• On-demand break-even throughput per warehouse: (credits/hour × p) ÷ $5
• On-demand Athena compute: B × k × A ÷ S
• Reservation Athena compute: (B ÷ p) × Usf × E ÷ Uath × $0.30 (+ S3/Glue)
• Reservation break-even: E* = (Uath × p) ÷ (Usf × $0.30)
• Athena reservation vs. on-demand crossover: 0.06 TB scanned per reserved DPU-hour

Appendix B — Sources

• Amazon Athena pricing — https://aws.amazon.com/athena/pricing/
• Amazon Athena now supports 1-minute reservations and 4 DPU minimum capacity (2026-02-10) — https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-athena-one-minute-capacity-reservations
• Athena User Guide: Manage query processing capacity — https://docs.aws.amazon.com/athena/latest/ug/capacity-management.html
• Athena User Guide: Query Apache Iceberg tables — https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html
• Amazon Athena Pricing in 2026 (Cloudburn; secondary) — https://cloudburn.io/blog/amazon-athena-pricing
• Snowflake pricing explained 2026 (Flexera; secondary) — https://www.flexera.com/blog/finops/ultimate-snowflake-cost-optimization-guide-reduce-snowflake-costs-pay-as-you-go-pricing-in-snowflake/
• Snowflake Pricing 2026 (Costbench; secondary) — https://costbench.com/software/data-warehousing/snowflake/
• Access Iceberg tables with an external engine through Snowflake Horizon Catalog (billing for catalog API calls) — https://docs.snowflake.com/en/user-guide/tables-iceberg-access-using-external-query-engine-snowflake-horizon
• Saving on Amazon Athena costs by using Provisioned Capacity (State Farm Engineering; practitioner experience) — https://engineering.statefarm.com/blog/athena-provisioned-capacity/