Building a Data Lake on AWS S3: Zones, Formats and Governance
Modern enterprise data engineering has largely converged on Amazon S3 as the primary storage layer for analytics, business intelligence, and machine learning workloads. However, deploying an unstructu
Published 10/24/2026 · Izan Technologies
Want this built for your team?
Senior engineers, your cloud, your IP.
Modern enterprise data engineering has largely converged on Amazon S3 as the primary storage layer for analytics, business intelligence, and machine learning workloads. However, deploying an unstructured collection of objects inside an S3 bucket is a recipe for a data swamp, not a competitive advantage. When executed correctly, building a data lake turns low-cost object storage into a performant, decoupled analytical ecosystem capable of handling petabyte-scale queries with sub-second latencies.
The rise of open table formats and unified metadata layers has blurred the lines between analytical warehouses and object stores, making modern architecture fundamentally centered on the convergence of data lakes & lakehouse design patterns. To extract maximum value from this architecture, data leaders must design their platforms around three pillars: clean zone topology, performant file and table formats, and rigorous unified governance.
Zone Topology: Structuring S3 Buckets for Production
A robust data lake architecture enforces immutability, data quality, and lineage by dividing storage into logically and physically isolated tiers. On AWS, this is best implemented using discrete S3 buckets with independent bucket policies, lifecycle rules, and AWS Key Management Service (KMS) keys rather than merely using prefixes within a single bucket.
Raw/Bronze Bucket (s3://company-data-raw/)
└── source_system=salesforce/
└── entity=contacts/
└── year=2024/month=03/day=15/load_id=abc1234.json.gz
Cleaned/Silver Bucket (s3://company-data-silver/)
└── domain=crm/
└── table=contacts/
├── metadata/
└── data/snappy-part-00000.parquet
Curated/Gold Bucket (s3://company-data-gold/)
└── marts=revenue_attribution/
└── table=arr_daily/
├── metadata/
└── data/zstd-part-00000.parquet
1. Raw Zone (Bronze)
The raw zone acts as an append-only, immutable landing zone. Incoming payloads—whether micro-batches from CDC tools like Debezium or AWS Database Migration Service (DMS), bulk API dumps, or streaming events via Amazon Kinesis Data Firehose—must be written in their native formats (JSON, CSV, Avro).
- Partitioning strategy: Partition strictly by ingestion timestamp:
s3://bucket-raw/<source>/<entity>/year=YYYY/month=MM/day=DD/. - Immutability: Enable S3 Object Lock or strict IAM Deny policies for
s3:DeleteObjectands3:PutObjecton existing keys. - Retention: Apply S3 Lifecycle policies to transition raw objects to S3 Glacier Flexible Retrieval or Deep Archive after 90 to 180 days.
2. Standardized Zone (Silver)
The silver zone transforms unstructured and raw payloads into validated, typed, and enriched datasets. Here, schemas are strictly enforced, duplicates are eliminated using merge operations, and sensitive identifiers (PII) are either tokenized or hashed.
- Data is stored exclusively in columnar formats (such as Parquet) or managed via table formats like Apache Iceberg or Delta Lake.
- Partitions align with high-cardinality query access patterns—typically business dates (
event_date=YYYY-MM-DD) or regional tenant codes.
3. Curated Zone (Gold)
The curated layer contains production-grade, domain-specific data models optimized for business intelligence tools, ad-hoc Athena queries, or feature ingestion pipelines for SageMaker.
- Data is aggregated, normalized, and modeled into dimensional schemas (Kimball star schemas) or denormalized analytical views.
- Partition granularities should be evaluated carefully; over-partitioning here often introduces file system bloat that impairs query planning.
Formats: Moving Beyond Plain Parquet to Open Table Formats
While columnar Apache Parquet files significantly lower storage and compute costs compared to CSV or JSON, raw Parquet files lack transactional integrity, atomic mutations, and metadata versioning. Modern data architectures on AWS resolve this limitation by deploying an open table format—most notably Apache Iceberg or Delta Lake—directly on top of S3.
These formats introduce a metadata manifest layer, unlocking features previously reserved for traditional data warehouses:
- ACID Transactions: Eliminates partial read errors during active writes or concurrent batch jobs.
- Schema Evolution: Allows teams to rename, add, or drop columns without breaking downstream readers or rewriting historical partitions.
- Time Travel & Rollbacks: Enables engineers to query historical snapshots for auditing or machine learning reproducibility.
- In-place File Compaction: Solves the notorious "small file problem" without locking the table.
Evaluating Storage Layers on AWS S3
| Feature / Metric | Apache Parquet (Raw) | Delta Lake | Apache Iceberg |
|---|---|---|---|
| ACID Support | No (atomic writes per file only) | Full ACID via _delta_log | Full ACID via metadata tree |
| AWS Native Integration | Native across Athena, Glue, EMR, Redshift | Athena (via connector/manifest), EMR, Databricks | Native Athena (v3+ engine), Glue Catalog, EMR |
| Partition Evolution | No (requires total rewrite of data) | Limited | Native (hidden partitioning, no path rewrite) |
| Concurrency Model | None (risk of dirty reads) | Optimistic Concurrency Control (OCC) | Optimistic Concurrency Control (OCC) |
| Target Workload | High-throughput raw landing | Spark-first, Databricks-centric ecosystems | Engine-agnostic engines (Athena, Trino, Spark, Flink) |
For architectures utilizing native AWS services (Athena, AWS Glue, Amazon EMR), Apache Iceberg backed by the AWS Glue Data Catalog has become the standard pattern due to its decoupled catalog abstractions and transparent partition evolution.
Mitigating the Small File Problem
Streaming ingestion and high-frequency micro-batch pipelines inevitably produce thousands of small files (kilobyte to low-megabyte sizes). When distributed query engines like Trino, Amazon Athena, or EMR Spark execute queries against these files, execution time is dominated by S3 GET metadata overhead and file open calls rather than actual compute processing.
To maintain performance:
- Target File Size: Aim for files between 128 MB and 512 MB in the Silver and Gold zones.
- Compaction Jobs: Schedule automated compaction pipelines. For Apache Iceberg tables, utilize the AWS Glue Iceberg compaction utility or run scheduled Spark jobs invoking
CALL system.rewrite_data_files(). - Snappy vs. Zstandard: Use Snappy compression for Silver layers prioritized for fast read/write cycle speeds; use Zstandard (zstd) in Gold layers to maximize compression ratios without sacrificing decompression throughput.
Governance, Security, and Fine-Grained Access
A performant data lake is useless if compliance failures or data leaks compromise enterprise trust. Enterprise-grade AWS environments enforce governance through an integrated identity and metadata plane.
1. Fine-Grained Authorization with AWS Lake Formation
Rather than managing sprawling S3 bucket policies and IAM roles for every analytical consumer, AWS Lake Formation provides centralized, Tag-Based Access Control (LF-TBAC).
- Column- and Row-Level Filtering: Restrict access to sensitive columns (e.g., masking credit card details) or limit rows (e.g., users can only view
region = 'EMEA') dynamically based on user identity. - Centralized Grants: Permissions are registered against the AWS Glue Data Catalog, allowing downstream query engines like Athena and Redshift Spectrum to enforce identical policies uniformly.
IAM Identity / Role
│
▼
AWS Lake Formation (LF-TBAC Policy Engine)
│
┌────┴─────────────────────────────┐
▼ ▼
Glue Catalog Metadata S3 Path Permissions
(Database/Table/Column Access) (Vended short-lived credentials)
2. Encryption and Networking
- KMS Key Isolation: Encrypt raw, silver, and gold buckets using distinct Customer Managed Keys (SSE-KMS). Apply S3 Bucket Keys to reduce AWS KMS request costs by up to 99%.
- Private Network Ingestion: Isolate analytical traffic entirely within your VPC using AWS PrivateLink and S3 Gateway VPC Endpoints, bypassing the public internet for all internal ETL data paths.
How Izan Technologies Helps
Designing a reliable, cost-effective data platform requires deep expertise across cloud infrastructure, distributed systems, and modern table designs. At Izan Technologies, we help enterprises architect, implement, and optimize scalable data pipelines and modern lakehouse platforms across AWS, Azure, Databricks, and Snowflake.
Unlike agencies that lock clients into proprietary tooling, Izan Technologies builds tailor-made, enterprise-grade solutions where our clients retain 100% ownership of all intellectual property, source code, and cloud infrastructure we deploy.
Whether you are starting from scratch or resolving performance bottlenecks in an existing deployment:
- Try our Smart AI DataStudio to explore intelligent data preparation and orchestration workflows.
- Or talk to an expert to discuss building your enterprise data lakehouse with our senior cloud engineers.
Want this built for your team?
Senior engineers, your cloud, your IP.