Most articles about AWS data lakes jump straight into advanced architecture – multi-zone medallion structures, Lake Formation governance models, cross-account access patterns. All of that matters eventually, but if you’ve never built a data lake before, it’s a lot to absorb before you’ve even created your first S3 bucket.
This is a different kind of guide. It’s a straightforward, step-by-step walkthrough for actually building a first, working AWS data lake – from an empty AWS account to a queryable dataset – without assuming you already know the advanced patterns. Once you’ve got this working, our deeper technical breakdown of AWS data lake architecture is the natural next read.
If you’d rather have this built for you correctly the first time, our Data Lake Services team at Algoscale does exactly this for a living.
Before You Start
You’ll need an AWS account, basic familiarity with the AWS Management Console, and awareness that S3 storage and Athena queries both cost money – modest amounts for a first small-scale build, but worth watching. This walkthrough uses the AWS Console directly rather than infrastructure-as-code, since the goal here is understanding what’s actually happening at each step, not production automation.
If you’re still deciding whether a data lake or a data warehouse fits your actual use case before you build anything, our earlier comparison of data lake vs. data warehouse is worth reading first.
Step-by-Step: Build Your First AWS Data Lake
Step 1: Plan Your Structure Before Touching the Console
Before creating anything, decide on a basic zone structure. Even a first data lake benefits from separating raw data from processed data:
● A raw zone for data exactly as it arrives, untouched
● A processed zone for cleaned, validated data
● A curated zone for data ready for querying and reporting
You don’t need this to be elaborate for a first build – even three simple folder prefixes inside one bucket is enough to start with good habits instead of a flat, undifferentiated dump.
Step 2: Create Your S3 Bucket
In the AWS Console, navigate to S3 and create a new bucket. A few settings matter more than they might seem to at first:
● Choose a globally unique bucket name – AWS bucket names are unique across all of AWS, not just your account
● Select the AWS region closest to where your data and users actually are, since this affects both latency and cost
● Leave Block all public access enabled – there’s essentially never a good reason for a data lake bucket to be publicly readable
● Enable default encryption (SSE-S3 is a reasonable default for a first build; you can move to customer-managed KMS keys later)
● Enable versioning if you want protection against accidental overwrites or deletions, which is generally worth it even for a first build
Step 3: Set Up Basic IAM Permissions
Rather than using your root account or an overly broad admin role for ongoing work, create an IAM role or user scoped specifically to this data lake, with permissions limited to the S3 bucket, Glue, and Athena resources you’re actually using. This is a habit worth building from day one – retrofitting least-privilege access onto a project that’s grown organically is significantly more work than starting with it.
Step 4: Organize Your Folder Structure and Load Sample Data
Inside your bucket, create prefixes matching your planned zones – for example, raw/, processed/, and curated/. Within the raw zone, a common convention is to further organize by source and date, such as:
raw/orders/2026/08/07/
Upload a small sample dataset (a CSV or JSON file works fine for testing) into the raw zone to have something real to work with in the next steps.
Step 5: Set Up the AWS Glue Data Catalog
Navigate to AWS Glue and create a new crawler, pointing it at your raw zone’s S3 prefix. When you run the crawler, it scans your data and automatically creates a table definition in the Glue Data Catalog – inferring column names and data types from your sample file. Once the crawler finishes, check the Glue Data Catalog to confirm your new table appears with the schema you expect.
Step 6: Query Your Data with Athena
Open Amazon Athena and set a query result location – a separate S3 prefix, such as athena-results/, where Athena stores query output. With that configured, run a simple query against the table Glue just created:
SELECT * FROM your_table LIMIT 10;
If this returns rows, you’ve successfully built a working, queryable data lake – from raw file to SQL query, without ever loading data into a traditional database.
Step 7: Add Basic Governance with Lake Formation
For a first build, this step can be light, but it’s worth knowing it exists. AWS Lake Formation lets you register your S3 location and manage table and column-level permissions centrally, rather than through S3 bucket policies alone. Even registering your data lake location in Lake Formation early – without immediately building out complex permission models – sets you up to add proper governance later without a disruptive rework.
Step 8: Set Up Basic Cost Controls
Before scaling beyond a test dataset, set up an S3 lifecycle rule to transition older or infrequently accessed data to a cheaper storage class, and create an AWS Budget alert so you’re notified if costs exceed an expected threshold. These take a few minutes to configure and prevent the most common “surprise AWS bill” scenarios for a growing data lake.
Troubleshooting Common First-Build Issues
Your Glue crawler runs but creates no table, or an empty schema. This is almost always a path issue – double-check the crawler is pointed at the exact S3 prefix containing your files, not a parent or sibling folder. It’s also worth confirming the IAM role attached to the crawler actually has read access to that bucket and prefix.
Athena returns a permissions error. This usually means either the IAM identity running the query lacks Athena or Glue Catalog permissions, or the query results location hasn’t been set, or the role lacks write access to that results bucket. Checking these three in order resolves the large majority of first-time Athena permission errors.
Your crawler infers the wrong data types for a column. Glue’s schema inference is based on sampling your data, and it can occasionally misjudge a column – treating a numeric ID as a string, for instance. For a first build, this is usually fine to leave as-is; for anything moving toward production, you can manually edit the table schema in the Glue Data Catalog console rather than relying entirely on inference.
Queries seem slower than expected even on a small dataset. For small test files, this is more often an Athena query-planning overhead than an actual data-scanning problem, and it’s not worth optimizing at this stage. Query performance becomes a genuinely important consideration once you’re working with larger, partitioned production datasets – not during initial testing.
Common Mistakes First-Time Builders Make
Skipping the zone structure “for now.” Dumping everything into one flat prefix feels faster initially, but reorganizing a data lake with real pipelines depending on it is far more disruptive than starting with even a minimal structure.
Using overly broad IAM permissions to move faster. It’s tempting to grant broad S3 access during initial testing and “fix it later.” Later rarely comes on its own – build the habit of scoped permissions from the start.
Not testing Athena query costs before scaling up. Athena charges based on data scanned per query. A query against a small test file costs almost nothing; the same unoptimized query pattern against a much larger dataset later can add up quickly if you haven’t thought about partitioning or file formats.
Forgetting to enable encryption and block public access. These are one-click settings during bucket creation and considerably more painful to fix after data – and potentially external access – already exist.
Where to Go From Here
Once you have a basic data lake working end to end – ingestion, cataloging, and querying – the natural next steps are partitioning your data for query performance, moving from CSV/JSON to a columnar format like Parquet, and thinking seriously about security and access control at a level beyond what a first build needs. Our post on data lakehouse security best practices for cloud-native organizations is a good next read once you’re past the basics covered here.
If you want the fuller picture of how these pieces fit into a production-grade architecture – including the medallion structure, Lake Formation governance, and cost optimization at scale – see our companion piece on what is a data lake architecture: benefits and use cases explained.
When to Bring in Help
A first small-scale data lake, built by hand through the console, is a great way to learn the fundamentals. But production data lakes – with real data volumes, multiple teams, and compliance requirements – benefit enormously from experience that only comes from having built many of them before. At Algoscale, our Data Lake Services team helps organizations move from exactly this kind of first working prototype to a production-grade architecture, without having to relearn every lesson the hard way.
To see the broader range of data engineering and analytics work we do beyond AWS specifically, take a look at what Algoscale builds across the data stack.
Why Algoscale
● Pre-built accelerators. We don’t start every engagement from a blank slate – proprietary accelerators built from prior implementations speed up common data source integration and analytics patterns.
● Faster time to value. For a focused initial scope covering core data sources and first analytics use cases, our accelerators typically compress development timelines to around four weeks, rather than the several months a from-scratch build often takes.
● Built on a scalable framework. Our implementation approach follows a repeatable, scale-ready framework, so the architecture built for your first use case extends cleanly as data volume and teams grow, rather than requiring a redo.
● Microsoft Solution Partner for Data & AI. Algoscale holds Microsoft Solution Partner status for Data & AI, including specific expertise implementing Microsoft Fabric as a modern data warehouse.
Frequently Asked Questions
1. Do I need to know infrastructure-as-code (like Terraform or CloudFormation) to follow this walkthrough?
No. This walkthrough uses the AWS Console directly, which is the right starting point for learning what each component actually does. Infrastructure-as-code becomes valuable once you’re ready to make your setup repeatable and production-ready, but it’s not required to build and understand your first data lake.
2. How much does a small first data lake on AWS actually cost?
For a small test dataset, costs are typically minimal – often just a few dollars a month in S3 storage, with Athena queries priced per amount of data scanned, which is negligible for small test files. Setting a budget alert during Step 8 is the easiest way to stay confident costs aren’t growing unexpectedly.
3. Do I need AWS Glue, or can I query S3 data another way?
Glue’s Data Catalog is what makes your S3 data queryable through Athena using standard SQL, so for this walkthrough it’s the most direct path. Other tools (Spark, Presto, third-party catalogs) can also query S3 data, but Glue plus Athena is the most beginner-friendly, fully-managed combination within AWS itself.
4. What file format should I use for my data – CSV, JSON, or Parquet?
CSV or JSON is perfectly fine for learning and testing, since that’s likely the format your source data already exists in. Once you’re working with meaningfully larger datasets, converting to Parquet significantly improves both query performance and cost, since it’s a columnar format that Athena can scan more efficiently.
5. Is Lake Formation necessary for a first data lake, or can I skip it?
You can skip detailed Lake Formation permission setup for a first build and rely on IAM and S3 bucket policies alone. Registering your S3 location in Lake Formation early is still worth doing, since it costs little effort now and avoids a bigger migration later once you do need centralized governance.
6. How do I know when I’ve outgrown a “first data lake” setup like this one?
Common signals include multiple teams needing different levels of access to the same data, query performance degrading as data volume grows, or compliance requirements that a simple IAM-and-bucket-policy model can’t cleanly satisfy. At that point, the more advanced architecture patterns – proper zoning, Lake Formation governance, and cost optimization – become worth the additional setup effort.
