New to Claude Skills? Learn how to install them →

aws on GitHub

Ingest into Data Lake

OfficialFree

Efficiently import data into AWS data lakes from various sources.

by aws2.3k stars on aws/agent-toolkit-for-aws
3 views
Updated Aug 10, 2026
Get this skill

Free · Opens the source repo

What Ingest into Data Lake does

The Ingest into Data Lake skill provides a streamlined approach for importing data into AWS data lakes. It supports a variety of data sources including local files, S3 buckets, JDBC databases (like Oracle, SQL Server, and MySQL), Amazon Redshift, Snowflake, BigQuery, and DynamoDB. This flexibility allows users to easily move data into a queryable format within their data lakes, primarily targeting S3 Tables by default. If S3 Tables are not adopted in the user’s environment, it intelligently recommends using standard Iceberg on existing general-purpose buckets instead.

This skill is designed for data engineers and developers who need to set up data ingestion pipelines or migrate existing data into AWS environments. It provides a comprehensive workflow that begins with verifying dependencies and context, classifying the source data, confirming connections, and clarifying target configurations. Each step is guided by detailed references to ensure that users can handle various data formats and sources effectively.

In addition to one-time loads, the skill supports recurring pipelines, making it suitable for ongoing data synchronization needs. Users can also validate the integrity of ingested data by checking row counts and performing null checks on critical columns. The skill emphasizes best practices in data ingestion and quality validation, ensuring that the data loaded into the lake is reliable and ready for analysis.

Overall, this skill is a valuable tool for anyone looking to efficiently manage data ingestion into AWS data lakes, providing clear guidance and robust support for a wide range of data sources and formats.

When to use it

Use this skill when you need to import or migrate data from various sources into AWS data lakes, particularly when setting up data pipelines or performing one-time loads.

When not to use it

This skill is not suitable for setting up Glue connections, creating empty tables, or querying data lakes. For those tasks, other skills should be utilized.

What you can build with it

One-time Data Load from S3

Use this skill to efficiently load a large dataset from S3 into your data lake for immediate analysis.

Recurring Data Ingestion from Snowflake

Set up a scheduled pipeline to regularly ingest data from Snowflake into your AWS data lake.

Migrating Existing Glue Catalog Tables

Utilize this skill to migrate existing tables in your Glue catalog to a more efficient Iceberg format.

How to install Ingest into Data Lake

View source

1. Install with the skills CLI

npx skills add aws/agent-toolkit-for-aws/ingesting-into-data-lake --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by aws

Ingest into Data Lake

Move data from a source into a queryable table in the data lake. This skill assumes the source connection (if one is needed) already exists. For Glue connection setup or troubleshooting, delegate to connecting-to-data-source.

Philosophy

Default to S3 Tables unless the environment says otherwise. S3 Tables is the recommended target for new data lake work. If the user's catalog inventory shows they haven't adopted S3 Tables, recommend standard Iceberg on their existing general-purpose bucket instead of forcing them to change posture.

Common Tasks

You MUST execute commands using AWS MCP server tools when connected -- they provide validation, sandboxed execution, and audit logging. Fall back to AWS CLI only if MCP is unavailable. You MUST explain each step before executing.

Workflow

1. Verify Dependencies and Context

  • You MUST check whether AWS MCP tools or AWS CLI are available and inform the user if missing
  • You MUST confirm target AWS region and verify credentials with aws sts get-caller-identity
  • For SageMaker Unified Studio project roles, note that target tables and connections may be scoped to the project. See the caller ARN detection pattern in querying-data-lake.

2. Classify the Source

User says...Source typeReference
"upload my file", "local CSV", "move to S3"Local filelocal-upload.md
"load from S3", "import CSV/JSON/Parquet from s3://"S3 filess3-files.md
"import from Oracle/Postgres/MySQL/SQL Server/Redshift/RDS/Aurora"JDBCjdbc-ingest.md
"pull from Snowflake", "Snowflake table to S3"Snowflakesnowflake-ingest.md
"import from BigQuery", "GCP analytics to S3"BigQuerybigquery-ingest.md
"export DynamoDB", "DynamoDB to data lake"DynamoDBdynamodb-ingest.md
"migrate Glue table", "convert Hive to Iceberg"Catalog migrationcatalog-migration.md

If the user names Salesforce, ServiceNow, SAP, MongoDB, Kafka, or another SaaS/streaming source, decline -- these are not supported in this release.

If the source table is referenced by a fuzzy or business name ("migrate our orders table", "pull from the sales warehouse"), delegate to finding-data-lake-assets to resolve before proceeding.

3. Confirm Connection Exists (if applicable)

For JDBC, Snowflake, and BigQuery sources, a Glue connection is required. Check:

aws glue get-connection --name <CONNECTION_NAME> --region <REGION>

If the connection does not exist, stop and delegate to connecting-to-data-source to create and test it. Do not proceed with ingest until the connection is verified.

Local files, S3 files, DynamoDB, and catalog migration do not need a Glue connection.

4. Clarify the Target

You MUST ask the user (or suggest based on catalog inventory) before creating or writing to any table:

  • Database/namespace: Does a specific target database exist? Or should one be created?
  • Table: Existing table (append/merge) or new table (delegate to creating-data-lake-table)?
  • Format: S3 Tables (default), standard Iceberg, or raw Parquet?

Inventory-aware defaults:

If you have already run exploring-data-catalog or can quickly check, use what exists:

  • Account has an s3tablescatalog federated catalog and active table buckets: recommend S3 Tables
  • Account has general-purpose buckets with Iceberg tables and no S3 Tables usage: recommend standard Iceberg on their existing bucket
  • Account uses Parquet/ORC on S3 without Iceberg metadata: ask whether to adopt Iceberg now (recommend yes) or continue with raw files

Do not force S3 Tables on customers who haven't adopted it. See iceberg-catalog-config-and-usage.md.

Delegations from this step:

  • Target table doesn't exist -> creating-data-lake-table
  • Target database named by fuzzy term -> finding-data-lake-assets
  • User doesn't know what exists -> exploring-data-catalog

5. Execute Source Workflow

Read the source-specific reference and follow its phases. Each is self-contained with job templates, gotchas, and troubleshooting:

  • Local / S3 / JDBC / Snowflake / BigQuery / DynamoDB / catalog migration -- one reference per source

Common Glue 5.1 or higher job configuration and PySpark templates are shared in glue-job-config.md and glue-job-scripts.md.

6. Validate

Run all three, do not skip:

  1. Row count matches expected (source vs target)
  2. Null check on critical columns
  3. Spot-check 3-5 sample rows

See data-quality-validation.md.

7. Schedule (if recurring)

For recurring pipelines, create a Glue Trigger with a cron schedule. See testing-and-scheduling.md. Simple single-step pipelines use Glue Triggers; multi-step with branching uses MWAA.

Argument Routing

  • S3 path only: Infer one-time load, start Step 2 with S3 files
  • Connection name: Start Step 3 with the named connection
  • Table name: Start Step 4, ask whether this is source or target
  • --target flag: Pre-fill the target format in Step 4
  • No args: Walk through interactively

Gotchas

  • S3 Tables requires Glue 5.1 or higher and --datalake-formats iceberg job argument
  • All spark.sql.catalog.* config MUST go in --conf job arguments, never in spark.conf.set(). Glue 5.x throws AnalysisException: Cannot modify the value of a static config otherwise. See iceberg-catalog-config-and-usage.md for correct catalog configs.
  • The warehouse parameter is required in S3 Tables catalog config. Without it Spark fails with "Cannot derive default warehouse location".
  • Table and column names in S3 Tables MUST be all lowercase
  • overwritePartitions() only replaces partitions present in the DataFrame -- for full refresh with deletes, use createOrReplace()
  • Standard Iceberg targets MUST include a LOCATION clause; S3 Tables MUST NOT
  • DynamoDB does not need a Glue connection -- do not attempt to create one
  • Connection failures during ingest delegate back to connecting-to-data-source; do not debug network/credentials in this skill
  • For target tables in SageMaker Unified Studio projects, ensure the project role has write access to the target namespace before the Glue job runs

Troubleshooting

ErrorLikely causeAction
Access Denied on S3Missing IAM permissionsCheck Glue role has s3:GetObject, s3:PutObject
Access Denied on S3 TablesMissing s3tables:* permissionsAdd S3 Tables inline policy to Glue role
CTAS timeoutDataset too large for AthenaSwitch to Glue ETL or batch with WHERE filters
JDBC connection timeout/auth failureConnection-level issueDelegate to connecting-to-data-source
Throughput exceeded (DynamoDB)Read percent too highLower read.percent or use native export

See error-handling.md for the full catalog.

References

Source-specific

Cross-cutting

Migration-specific

JDBC-specific

Frequently asked questions about Ingest into Data Lake

Similar skills