Building a modern data lake on Amazon Web Services (AWS) using Amazon S3, AWS Glue, and Amazon Athena provides engineering teams with elastic, serverless analytics without the overhead of managing physical database clusters. However, as data volumes grow from gigabytes to hundreds of terabytes, unoptimized cloud architectures can lead to ballooning monthly bills.
According to engineering analyses documented in Hammad Tariq’s AWS Glue Cost Optimization Guide, AWS data lake costs are rarely dominated by storage alone. Instead, up to 70% of total spend stems from inefficient compute provisioning in AWS Glue Data Processing Units (DPUs), excessive data scanned during unpartitioned Athena queries, and sub-optimal S3 object lifecycle policies.
Without targeted architectural governance, teams frequently encounter the “small-file problem”, redundant DPU allocations, and full-bucket scans that erode cloud ROI.
This technical guide delivers an engineering-first blueprint to systematically reduce AWS data lake expenditure by 40% to 60% across S3, Glue, and Athena while accelerating pipeline throughput.
1. The 3 Core Cost Drivers in AWS Data Lakes
Optimizing AWS data infrastructure requires identifying where compute and storage inefficiencies compound:
┌────────────────────────────────────────────────────────────────────────┐
│ AWS DATA LAKE COST TRIANGLE │
│ │
│ ┌─────────────────────────┐ │
│ │ AMAZON S3 STORAGE │ │
│ │ • API Request Volume │ │
│ │ • Storage Class Tiers │ │
│ │ • Small File Overhead │ │
│ └────────────┬────────────┘ │
│ │ │
│ ┌───────────────┴───────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────────────────┐ ┌──────────────────────────────────┐ │
│ │ AWS GLUE ETL │ │ AMAZON ATHENA │ │
│ │ • Over-provisioned DPUs │ │ • Full S3 Scans ($5/TB scanned) │ │
│ │ • Unoptimized Worker Types │ │ • Missing Columnar Formats │ │
│ │ • Excessive Job Timeouts │ │ • Unpruned Partitions │ │
│ └─────────────────────────────┘ └──────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
2. Amazon S3 Storage & API Cost Reduction
While standard S3 storage ($0.023/GB/month) is relatively economical, API requests (PUT, COPY, LIST, GET) and multipart upload metadata often comprise a significant portion of the bill in high-frequency streaming architectures as detailed in GoCloud’s Lakehouse Architecture Guide.
Automated S3 Lifecycle Tiering
Transitioning raw landing zones to lower-cost storage tiers prevents historical data from accumulating in standard S3:
| S3 Storage Class | Cost / GB / Month | Retrieval Latency | Optimal Data Phase |
| S3 Standard | ~$0.023 | Milliseconds | Active ingestion (Bronze / Raw) |
| S3 Standard-IA | ~$0.0125 | Milliseconds | Processed historical data accessed 1–2x/month |
| S3 Glacier Instant | ~$0.004 | Milliseconds | Compliance archives requiring fast retrieval |
| S3 Glacier Flexible | ~$0.0036 | Minutes–Hours | Long-term historical cold storage (>90 days) |
Resolving the “Small File Problem”
Streaming engines (e.g., Kinesis Firehose, Kafka Connect) often write thousands of tiny (10KB–500KB) JSON/CSV files per hour. This creates two cost penalties:
- High
PUTandLISTAPI request charges. - Athena and Glue engines spend more time opening/closing S3 connections than executing compute tasks.
Solution: Compact small files into 128MB–512MB compressed Apache Parquet or Apache Iceberg files during the Silver/Gold transformation layer.
3. AWS Glue ETL: Right-Sizing DPUs and Worker Types
AWS Glue bills based on Data Processing Unit (DPU) hours consumed ($0.44 per DPU-Hour). A standard Glue job defaulting to 10 G.1X workers consumes 10 DPUs.
Choosing the Right Worker Type (G.1X vs G.2X vs Flex)
G.1X Worker: 1 DPU = 4 vCPU, 16 GB RAM (Best for standard I/O bound batch jobs)
G.2X Worker: 2 DPU = 8 vCPU, 32 GB RAM (Best for memory-intensive joins & ML transformations)
Glue Flex: ~35% discount for non-urgent workloads and dev/staging environments
Dynamic Frame to Spark DataFrame Conversion
AWS Glue DynamicFrames offer schema flexibility, but standard PySpark DataFrames execute significantly faster on structured data due to Catalyst Optimizer enhancements:
Python
# AWS Glue PySpark Optimization Pattern
import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext
from pyspark.sql.functions import col
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
# Enable S3 optimized committer and broadcast thresholds
spark.conf.set("spark.sql.sources.commitProtocolClass",
"org.apache.spark.internal.io.cloud.PathOutputCommitProtocol")
spark.conf.set("spark.sql.parquet.output.committer.class",
"org.apache.parquet.hadoop.ParquetOutputCommitter")
# Read directly as Spark DataFrame to bypass DynamicFrame overhead
df = spark.read.parquet("s3://tny-datalake-bronze/events/year=2026/month=08/")
# Filter early to reduce memory footprint
filtered_df = df.filter(col("status") == "COMPLETED") \
.repartition(col("event_date"))
# Write optimized Parquet with Snappy compression
filtered_df.write \
.mode("append") \
.partitionBy("event_date") \
.option("compression", "snappy") \
.parquet("s3://tny-datalake-silver/events/")
Enforce Job Execution Timeouts
Set explicit job execution timeouts in Glue jobs (e.g., Timeout = 30 minutes instead of the default 2880 minutes) to prevent hung jobs from consuming DPUs indefinitely.
4. Amazon Athena Query Optimization & Lakehouse Formats
Amazon Athena queries are billed at $5.00 per terabyte (TB) of data scanned from S3. Reducing query costs requires minimizing scanned byte volumes as highlighted in CloudThat’s S3 Glue Athena Best Practices.
Unpartitioned CSV Query (Full Bucket Scan: 500 GB) ──▶ Cost: $2.50 per query
Partitioned Parquet / Iceberg Query (Pruned Scan: 2 GB) ──▶ Cost: $0.01 per query
The 4 Pillars of Athena Query Cost Reduction:
- Columnar Formats (Parquet / ORC): Columnar compression reads only the specific columns referenced in the
SELECTstatement rather than full rows. - Partition Projection: For high-cardinality partitions (e.g., date, tenant), use AWS Glue Partition Projection to eliminate metadata search latency and query planning overhead.
- Adopt Apache Iceberg on S3: Apache Iceberg maintains file-level min/max statistics in metadata manifests. Athena uses these manifests to skip irrelevant S3 objects entirely without reading data files.
- Enforce Workgroup Scan Limits: Configure Athena Workgroups with strict per-query data scan limits to terminate accidental
SELECT *runaway queries.
5. Summary & Actionable FinOps Checklist
| Focus Area | Action Item | Expected Savings |
| S3 Storage | Implement S3 Lifecycle rules (Standard $\rightarrow$ Glacier Instant) | 30% – 50% on storage |
| File Sizing | Compact streaming small files to 128MB+ Parquet | 20% – 40% on API + compute |
| AWS Glue | Downsize DPUs, enable Glue Flex for non-critical jobs | 35% – 50% on ETL compute |
| Amazon Athena | Convert to partitioned Iceberg/Parquet, apply scan limits | 60% – 90% on query costs |
Maximize Your Cloud ROI with TnY Systems
Building a high-throughput, cost-effective data architecture requires seasoned engineering expertise across cloud infrastructure, lakehouses, and real-time streaming pipelines. TnY Systems specializes in architecting enterprise data platforms, optimizing AWS Glue/S3/Athena workloads, and modernizing legacy stacks across multi-cloud environments.
Looking to reduce your cloud data lake spend? Schedule an architectural review with TnY Systems to assess your pipelines and build an optimization roadmap.

