The cost of an AWS data lake comes from three places, not one: S3 storage billed per gigabyte by storage class, S3 request charges on the operations that read and write objects, and per query scan costs from engines such as Athena that bill on how much data each query reads. Teams budget for storage and are then surprised by the query line, because at scale a poorly laid out lake makes every query scan far more data than it needs, and the scan cost compounds with every analyst and every dashboard refresh. The way to keep a lake cheap is to attack all three together: store data in compressed columnar formats, partition it so queries read only what they need, and tier storage to match how often data is actually accessed. Get the layout right and the same data costs a fraction to query.
Here is where each cost sits and the design choices that control it.
What drives the cost of an AWS data lake?
Break the bill into its parts. Storage is the obvious one: every object in S3 is billed per gigabyte per month at a rate that depends on its storage class. Requests are the quiet one: GET, PUT, LIST, and other operations each carry a small per request charge that becomes material when pipelines write millions of small objects or list large prefixes repeatedly. Query scan is the one that scales fastest: serverless engines like Athena bill per terabyte of data scanned, so a query that reads an entire dataset to return a few rows pays for all of it. In a mature lake the query and request lines frequently exceed the storage line, which is why optimizing storage alone leaves most of the saving untouched.
How do file format and layout cut cost?
This is the highest leverage move in the whole lake. Storing data in a columnar format such as Parquet, with compression applied, means an engine reads only the columns a query references rather than every field in every row. Partitioning the data by the dimensions queries filter on, date, region, or tenant, means the engine prunes whole partitions it does not need instead of scanning them. Because Athena and similar engines bill per terabyte scanned, the combination of columnar format, compression, and sensible partitioning routinely cuts query cost by an order of magnitude on identical underlying data. Add compaction so the lake holds fewer, larger files rather than millions of tiny ones, and you cut the request charges at the same time.
A Fortune 500 retailer ran an analytics lake on S3 where raw event data landed as uncompressed row oriented files and analysts queried it with Athena. The per query scan cost had grown into the dominant line on the lake's bill because every query scanned far more data than it returned. Converting the data to compressed Parquet, partitioning by date and region, and compacting small files so the lake held larger objects cut the average data scanned per query dramatically. Lifecycle policies then moved cold partitions to Infrequent Access and archival tiers. Query cost fell by roughly an order of magnitude on the heaviest dashboards and the overall lake spend dropped by close to a third, with no change to the questions analysts could ask. The figures are verified against billing data and anonymised.
Should data lake storage move to cheaper tiers?
Yes, matched to how often data is read. S3 offers a ladder of storage classes from Standard for hot data, through Standard Infrequent Access and Intelligent Tiering for cooler data, down to Glacier Instant Retrieval, Flexible Retrieval, and Deep Archive for cold and archival data. The rates fall steeply as you descend, but so does retrieval speed and, in the archive classes, retrieval cost. The right design maps each dataset to a tier by access pattern and automates the transitions with lifecycle policies, so a partition that is queried daily this month and never again next quarter moves down the ladder on its own. Intelligent Tiering is a pragmatic default for data with unpredictable access, since it shifts objects between tiers automatically for a small monitoring fee. The principle is to pay Standard rates only for data you actually read often.
Where do query engine choices fit?
The engine and its pricing model shape the query line as much as the data layout does. Athena's per terabyte scanned model rewards the format and partitioning work above, and it suits intermittent, ad hoc querying because you pay nothing when no one queries. For heavy, constant query loads, a provisioned engine or a warehouse such as Redshift Spectrum querying the same S3 data may be cheaper per unit of work, since you are not paying scan rates on every dashboard refresh. The decision is the same one that runs through cloud cost work generally: match the pricing model to the usage shape. Spiky and occasional favours pay per scan; steady and heavy favours provisioned capacity. Model both against your real query volume before committing.
Frequently asked questions
What drives the cost of an AWS data lake?
How do file format and layout cut data lake cost?
Should data lake storage move to cheaper tiers?
Make your data lake economical with us
We optimize AWS data lakes end to end, from Parquet conversion and partitioning to storage tiering and query engine choice, so the lake stays cheap as it grows. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.