See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
Draw the zones, not the buckets
Every lake has a raw zone, at least one processed zone, and a curated or consumption zone. Teams call them raw, cleansed, curated, or bronze, silver, gold, and the naming argument is not worth having on a diagram. What matters is that each zone carries a contract: raw is immutable and schema-on-read, curated is modelled and queried by people.
Whether those zones are three buckets or three prefixes in one bucket is an implementation choice driven by lifecycle policies, replication, and account boundaries. The diagram should show three zones either way, with a small label saying which physical layout you chose. A reader who needs the bucket names will look them up; a reader who needs to know where the contract changes needs the zones.
Put the partition scheme on the zone label. Partitioning by ingestion date versus by event date is the single most consequential decision in the lake, it determines what a query scans, and it belongs on the picture rather than in a runbook. Add Glacier storage classes as a note on the raw zone if you tier old partitions out.
Glue is three things and needs three boxes
AWS Glue is a crawler service, a metadata catalog, and an ETL engine, and diagrams that draw one Glue square for all three lose the most useful distinction in the architecture. Crawlers scan S3 prefixes and register or update tables. The Data Catalog holds those table definitions. Glue ETL jobs read and write data.
Only the ETL jobs sit in the data path. The catalog sits beside it. Draw the catalog once, off to the side, with dashed edges to Athena, Redshift Spectrum, EMR, and Glue jobs, because all four read table definitions from it. Solid arrows for data, dashed for metadata, and the diagram stops implying that queries route through the catalog.
If you use Glue crawlers on a schedule, put the schedule on the crawler node. Stale partitions in the catalog are a top-three cause of a query returning fewer rows than expected, and the schedule is the fact that explains it.
Lake Formation is a permission plane, not a hop
The most common wrong edge in an AWS lake diagram is S3 to Lake Formation to Athena. No data flows through Lake Formation. It holds table, column, row, and cell level grants that Athena, Redshift Spectrum, EMR, and Glue enforce when they resolve a table, and it manages the S3 locations registered to it.
Draw it as a governance band spanning the consumption side, or as a lane above the zones, with dashed control edges to each engine and to the registered S3 locations. That layout answers the question Lake Formation exists to answer, which is who can see which columns, without inventing a data flow that does not exist.
The same treatment works for the IAM roles behind the engines and for any Glue Data Quality rules. Control planes go in a band; data planes go in the flow.
Sibling page
What survives when the diagram is generated from the Terraform
A lake defined in Terraform is where the completeness instinct does the most damage, because bucket policies, IAM roles, Glue table definitions and Lake Formation permissions genuinely are most of the resource count. Drawing them all is how you get a correct diagram nobody reads.
The parser here resolves that with a fixed curation rather than a judgement call. Anything matching role, permission, grant, policy attachment, member, iam, entitlement or acl is classified as wiring: never a node, counted in a note. A bucket policy attaches to its bucket as a container relationship rather than a separate box. Repeated minor resources of the same type inside one module collapse into a single node carrying the count and the member names, so three catalog databases arrive as one node reading "Glue catalog databases x3: raw, cleansed, curated" rather than three near-identical squares.
The numbers behind those rules came from a real repository. The first version drew every resource it could justify, and a 123-resource platform came back as 62 boxes in one column: complete, correct, and useless. The current draw plan caps a module at eight drawn nodes, or sixteen when one module is the subject of the whole repository, and pushes the overflow into a named supporting-resources node. Nothing is lost, because the full inventory lands in the module reference table of the generated architecture document while the canvas keeps the zones a reader can hold in their head.
The edges in and the edges out
Ingestion into the raw zone usually comes from four directions: Kinesis Data Firehose for streams, Database Migration Service for change data capture out of operational databases, AppFlow for SaaS sources, and plain S3 uploads or DataSync for files. Each has its own icon in the official set, and naming the mechanism on the arrow is what tells a reader whether the lake is minutes fresh or a day behind.
Consumption is Athena for ad hoc SQL, Redshift or Redshift Spectrum for the warehouse workload, EMR for Spark, SageMaker for training sets, and QuickSight for dashboards. Draw the consumers reading the curated zone, not the raw zone, and if someone really does query raw, draw that edge too, because it is usually the thing the review is about.
Datadef ships all of these marks: 439 AWS icons inside a library of 2,098 files. Type the architecture and the icons land in place, or grab a single file from the S3 icon page and the Lake Formation icon page.
FAQ
Should a data lake diagram use one S3 bucket or three?
Where does the Glue Data Catalog belong on the diagram?
Is Lake Formation in the data path?
What is the difference between a data lake diagram and a lakehouse diagram?
How do I keep the diagram current as new tables land?