Are AWS Glue crawlers free? (2026)

A Glue crawler looks like free infrastructure. It has no instance to size, no cluster to leave running, and it finishes in a couple of minutes. It is metered like a Spark job, with a minimum charge per run that is longer than most crawls take, which means the schedule you pick decides the bill and the amount of data barely matters.

Are AWS Glue crawlers free?

No. There is no free tier for crawler runtime. The AWS Glue pricing page puts crawlers in the same sentence as ETL jobs: "with AWS Glue, you pay an hourly rate, billed by the second, for crawlers (discovering data) and extract, transform, and load (ETL) jobs (processing and loading data)."

The full statement of how a crawler bills:

"There is an hourly rate for AWS Glue crawler runtime to discover data and populate the AWS Glue Data Catalog. You are charged an hourly rate based on the number of Data Processing Units (or DPUs) used to run your crawler. A single DPU provides 4 vCPU and 16 GB of memory. You are billed in increments of 1 second, rounded up to the nearest second, with a 10-minute minimum duration for each crawl."

The Data Catalog itself does have a free tier, and it is generous: "the first million objects stored are free, and the first million accesses are free." Those are two different meters from crawler runtime, and confusing them is why people believe crawlers are free.

What does one AWS Glue crawler run cost?

The pricing page's own worked example gives the rate in prose: "AWS Glue Crawlers are billed at $0.44 per DPU-hour, so you will pay for 2 DPUs * 0.5 hour at $0.44 per DPU-hour, which equals $0.44." That example assumes a crawler that runs for thirty minutes on two DPUs.

Most crawls are nothing like thirty minutes. A crawler over a tidy S3 prefix finishes in under a minute, and that is where the minimum takes over. Two DPUs for the minimum ten minutes is 2 × (10/60) × $0.44, which is about $0.147 per run no matter how fast the crawl actually was.

That is per crawler. An account with thirty crawlers on hourly schedules, which is an ordinary state for a data platform that grew one table at a time, is spending tens of thousands of dollars a year on catalog maintenance for datasets that change once a day.

Why does the 10-minute minimum dominate a Glue crawler bill?

Because crawl duration and crawl cost stop being related. Below ten minutes you pay for ten minutes, so halving the work you give a crawler saves nothing. The only two variables that move the number are how many DPUs the crawl uses and how many times it runs.

It is worth noticing how different this is from the Glue jobs on the same page. Spark jobs on "AWS Glue versions 2.0 and later have a 1-minute minimum", and Python Shell jobs "have a 1-minute minimum billing duration". Crawlers get ten. The service that does the least work per invocation has the longest floor.

One thing genuinely does add runtime, and it is easy to walk into: "if the file that is crawled is compressed, the crawler must download it to process it." A crawler over a large set of gzipped objects is not just listing keys, it is pulling data across to look inside.

What does the AWS Glue Data Catalog charge for?

Two things, both after a free million. The Data Catalog is the metadata store Athena and Glue jobs read from, and it bills on what is in it and how often it is asked. Storage: "the first million objects stored are free". Requests: "the first million metadata access requests to the Data Catalog per month are free. If you exceed a million metadata requests in a month, you will be charged $1.00 per million requests over the first million."

The request meter is the one that catches analytics platforms, because the calls are not made by people. AWS names the common ones: "some of the common requests are CreateTable, CreatePartition, GetTable, GetPartitions, and GetColumnStatisticsForTable." Every Athena query against a catalog-registered table makes some of these, and a crawler writing partitions makes a great many.

A million requests a month is roughly 23 a minute sustained, which a busy dashboard refreshing across dozens of tables reaches without anybody noticing. Which columns those dashboards should be summing is a separate decision, set out in amortized vs unblended cost. At $1.00 per million past that, the charge stays small, but it is the meter that tells you how chatty your catalog is.

How often should an AWS Glue crawler run?

As rarely as your data changes shape, which for most tables is far less often than the schedule people set. A crawler is not reading your data on a schedule; it is looking for structural change. AWS describes the incremental behaviour: "if your crawler runs more than once, perhaps on a schedule, it looks for new or changed files or tables in your data store. The output of the crawler includes new tables and partitions found since a previous run."

So the question to ask about any crawler schedule is: what new thing would this crawl find? For a table whose schema is fixed and whose partitions arrive on a predictable path, the answer is a partition it could have computed instead of discovered. For a landing zone where new datasets appear from unknown producers, the answer is a genuinely new table, and the crawler is earning its ten minutes.

When is an AWS Glue crawler worth running?

Three cases, and they have something in common: you do not know the shape in advance.

• Schema inference on unfamiliar data. AWS's list of what a crawler does starts with classification: "a crawler runs any custom classifiers that you choose to infer the format and schema of your data", using "built-in classifiers to infer schemas from common files with formats that include JSON, CSV, and Apache Avro."
• Table discovery in a shared bucket. The crawler decides what is a table and what is a partition: "when an AWS Glue crawler scans Amazon S3 data store and detects multiple folders in a bucket, it determines the root of a table in the folder structure and which folders are partitions of a table."
• One-off onboarding. Run it once, take the catalog it produces, then delete the schedule. Nothing about a crawler requires it to be recurring.

The counter-case is the one that applies to almost every cost dataset. AWS says so on the pricing page itself, in a sentence that most crawler users have never read: "use of AWS Glue crawlers is optional, and you can populate the Data Catalog directly through the API."

How do you cut AWS Glue crawler cost?

In order of how much they save, and the first one is a step change rather than a saving.

• Delete the crawler where the partition scheme is predictable. A dataset partitioned on a date or an account ID does not need discovering, because Athena can derive the partitions from the path pattern. We run this across our own lake: the CUR 2.0, FOCUS and Kubernetes metrics tables in s3://akalcloud-cur-datalake/ are all partitioned by account and billing period, and there are no crawlers at all against any of them. What those tables contain, and why we export both formats, is in CUR 2.0 vs FOCUS. How that is configured, and what it costs to get wrong, is in query your CUR in Athena, no crawler.
• Lengthen the schedule. Every halving of frequency halves the bill exactly, because the per-run cost is fixed by the minimum. Hourly to daily is a 24x reduction with no engineering.
• Trigger instead of schedule. A crawler that runs when new data lands runs as often as data lands, which for a daily CUR delivery is once a day. A crawler on a schedule runs whether or not anything happened, and pays the ten-minute minimum for finding nothing.
• Narrow the include path. Pointing a crawler at a bucket root rather than at the table prefix makes it list everything in the bucket. That is runtime, and past ten minutes it is money.
• Count the crawlers you have. aws glue list-crawlers takes a second, and the schedule on each one is visible in aws glue get-crawler --name. Most accounts have more than anyone remembers creating.

Where does Glue crawler cost show up in your bill?

Under AWS Glue, on a DPU-hour usage type, not under Athena or S3. Athena charges by the terabyte scanned, on its own pricing page, and the two never appear on the same line. That separation is why crawler spend often survives a cost review: the team looking at query cost is looking at Athena's per-TB scan charge and the team looking at storage is looking at S3, while the catalog maintenance bill sits under a third service that nobody has opened.

If you are attributing that spend to a team, note that a crawler is a shared resource in exactly the way that makes tagging hard, and the usual failure modes apply: see why cost allocation tags show up empty.