Original Japanese article: メダリオンアーキテクチャのLanding ZoneはBronzeレイヤーなのか考えてみる

Introduction

I'm Aki, an AWS Community Builder (@jitepengin).

When you design a medallion architecture, the question "Should the landing zone be part of Bronze?" always comes up at some point.
Is the place where files from source systems land the same layer as the Bronze tables, or a different one?

It may look like a naming question, but I don't think it is.
How you answer it changes where you validate schemas, where you keep data that was rejected at ingestion, and where you rebuild from when something fails.

To give the conclusion up front, I think the answer is decided not by "whether to include the landing zone" but by "what you want the Bronze layer to guarantee."

In this article, I compare how two books define these layers, and then walk through why I placed the landing zone outside Bronze on a real project and what that decision was based on.

How the Books Define It

I referred to the following two books.

1. James Serra, Deciphering Data Architectures

https://www.oreilly.com/library/view/deciphering-data-architectures/9781098150754/

Deciphering Data Architectures is a great book for getting an organized view of data architecture as a whole.

1. Piethein Strengholt, Building Medallion Architectures

https://www.oreilly.com/library/view/building-medallion-architectures/9781098178826/

Building Medallion Architectures is recommended for anyone who wants a deep understanding of the medallion architecture.

Let's start with James Serra's Deciphering Data Architectures.
Chapter 5, "Data Lake," describes the layers of a data lake in the order Raw, Conformed, Cleansed, and Presentation.
The raw layer holds data in its original state, immutable and with no transformations applied, and its alternative names are listed as "bronze layer, staging layer, or landing area."
The conformed layer converts files in different formats, such as CSV, JSON, and Parquet, into a single format (usually Parquet), and is also called the base layer or standardized layer.

Chapter 12, "Data Lakehouse," shows two areas, Raw and Conformed, inside the raw zone.
Inside the raw zone, "Raw" and "Conformed (parquet)" sit side by side, with Delta Lake shown between them.
Delta Lake is a mechanism that manages tables by combining Parquet files with a transaction log.
Conformed can therefore be read as the area where data is stored as Delta Lake tables and the format is standardized.

Simplifying the book's architecture diagram down to just the layers gives the following.

flowchart LR subgraph RZ["Raw zone"] direction LR R["Raw<br/>(files as received)"] -- "stored as Delta Lake" --> C["Conformed<br/>(Delta Lake)"] end C --> CL["Cleaned"] --> P["Presentation"]

Note: The architecture diagram does not use the name "Bronze." Since Chapter 5 lists bronze as an alternative name for Raw, this article reads the raw zone as the equivalent of Bronze.

Read that way, Serra's lakehouse puts both the files as received and the data converted to Delta Lake inside Bronze.

On the other hand, Piethein Strengholt's Building Medallion Architectures lists Landing and Bronze as separate rows in the table of layers in Chapter 3.
Landing is where data from the source is placed as is, in the file format it was delivered in, without transformation. Bronze is validated raw data represented in a table format such as Delta or Iceberg.

Simplifying the book's structure in the same way gives the following.

flowchart LR L["Landing<br/>(files as received)"] --> B["Bronze<br/>(Delta / Iceberg tables)"] --> S["Silver"] --> G["Gold"]

That said, Strengholt doesn't insist that they are separate layers either.
In Chapter 2, he writes about the landing zone: "It's up to you to decide whether to label this layer as Bronze."
Chapter 3 also mentions structures where Bronze has internal sublayers such as a staging area, and describes the number of physical layers as depending on whether the landing zone is included.

Putting them side by side:

What Matters Is Where You Draw the Line

Lining them up, all three include a stage that lands data as received and a stage that standardizes the format.
In a data lake, the data is still Parquet files after the format is standardized, but in a lakehouse, this is the stage where it becomes a Delta Lake or Iceberg table.

What differs is where the boundary of Bronze is drawn.
In my reading, Serra groups both stages into the raw zone (Bronze equivalent) even in the lakehouse, and performs the conversion to Delta Lake inside it.
Strengholt draws the Bronze boundary around only the table stage, and puts the files as received outside as Landing.

In other words, the question "Is the landing zone Bronze?" can be rephrased as "Do you put it inside Bronze as a sublayer, or outside Bronze as a separate layer?"

From here on, the diagrams are not from the books but conceptual diagrams I put together for this article. Here are the two patterns.

Pattern 1: Put it inside Bronze

flowchart LR S1["Source"] --> R1 subgraph B1["Bronze"] direction LR R1["Land as received<br/>(files)"] --> C1["Standardize format<br/>(tables)"] end C1 --> SV1["Silver"]

Pattern 2: Put it outside Bronze

flowchart LR S2["Source"] --> L2 subgraph LZ["Landing"] L2["Everything received<br/>is kept<br/>(files)"] end L2 -- "schema check" --> B2 subgraph BR["Bronze"] B2["Only data meeting<br/>the schema gets in<br/>(tables)"] end B2 --> SV2["Silver"]

Inside or Outside?

Either way, you can build essentially the same data flow.
Even if you put it inside, you can keep the received files and still reject schema violations by splitting Bronze into a sublayer that keeps everything and a sublayer that only accepts data that passed validation.

Where they differ, I think, is in what the name "Bronze" guarantees.

If you put it inside, a single Bronze layer guarantees two things of a different nature: that everything received is kept, and that only data meeting the agreed schema gets in.
When someone says "the data in Bronze," which one they mean depends on context, and that makes it harder to decide permissions, retention, and quality on a per-layer basis.
If you put it outside, each layer guarantees just one thing.

Landing is "the place where everything received is kept," and Bronze is "a table that only contains data meeting the contracted schema."
Since the layer boundary becomes the validation boundary, you can say with confidence: "If it's in Bronze, its schema is guaranteed."

The schema validation here refers to the structure agreed with the source (columns, types, and required fields).
It doesn't mean Bronze also handles data quality checks such as value validity, deduplication, or consistency across tables. Those are the job of Silver and beyond.
I treat guaranteeing structure and guaranteeing quality as separate things.

Note: "Everything is kept" does not mean forever.
If there are constraints such as personal data or contractual terms, a retention period is set and data is deleted.
What is guaranteed here is that, within the retention period, the received originals are kept unmodified.

On AWS, They Are Physically Separate

If you use S3 Tables for Bronze on AWS, this boundary becomes even clearer.
Landing files are received in an S3 general purpose bucket, but an S3 Tables table bucket is not a place where you can put arbitrary files, so you can't drop CSV or JSON files into it as is.

Different bucket types mean you need to think separately not only about access control and encryption, but also about retention and deletion, maintenance, and auditing.
For example, S3 Tables provides table maintenance features such as compaction and snapshot expiration as managed capabilities, so its management model itself differs from that of a general purpose bucket.

Also, this snapshot management exists to manage table history, not to retain received originals over the long term.
When snapshots expire, data files referenced only by those snapshots are treated as noncurrent and are deleted after the number of days set in the unreferenced file removal policy.
That's why retaining originals and managing table history need to be treated as separate requirements.

If you treat Landing as a sublayer of Bronze, a single layer ends up spanning two types of buckets. If you want the logical layers and the physical storage locations to line up, I think putting it outside is more natural.

Note: If you build Iceberg tables on general purpose buckets, you can keep Landing and Bronze in the same type of bucket.

What I Decided on a Real Project

On a data platform project I worked on, dozens of source pipelines started from an S3 landing zone and transformed data through the medallion layers.
There, I placed the landing zone outside Bronze and split the roles as follows.

The main reason for this split was where schema validation lives.
On this project, the schema defined with each source was fixed, and data violating it was rejected at the point of ingestion into Bronze.

In operation, rejected files also remain in Landing, so you can investigate later why they were rejected, and re-ingest from the same files once the source side has fixed the issue.

The same thinking applies to recovery. Because Landing files are never modified, if something goes wrong in Bronze or beyond, you can re-ingest starting from Landing.
You can rerun only the affected scope, or rebuild everything if needed.
Never having to wonder where to rebuild from was, I feel, the biggest operational benefit.

Which Should You Choose?

Let's think about some guidelines.
These assume a setup centered on file-based ingestion, like the one above.
Even if sources arrive in a table format, it can still make sense to have Landing if you need to keep originals or reprocess data, and some setups receive CDC change data as files first.

If you can ingest directly from the source in a table format, there's no need for Landing in the first place. Strengholt also says it's reasonable to skip the landing zone and ingest directly into Bronze when the source side is stable.
Conversely, if data arrives as files and you want to reject it via validation at ingestion, I think putting Landing outside keeps what each layer guarantees simpler.

Conclusion

In this article, I thought about whether the landing zone should be part of Bronze.

I believe whether Landing is Bronze is not a naming question but a question of where you draw the line.
If you're unsure which to choose, starting from what you want the name "Bronze" to guarantee may be a good approach.

I hope this article is helpful to anyone thinking through the layer design of a medallion architecture.