S3 Select in 2026: Why New Accounts Get MethodNotAllowed, and What to Use Instead

SELECT * FROM S3Object s LIMIT 5 

That was the query I expected to work. I had uploaded a tiny CSV to Amazon S3, checked its metadata, and previewed the contents. When I clicked Run Query in Buckets by Serverless Creed, I got this instead:

The specified method is not allowed against this resource. 

Changing the SQL didn't resolve it. Running the equivalent operation through AWS CLI returned MethodNotAllowed too.

This post follows that investigation across four scenarios in Buckets v2.8.7 and v2.8.9. It also explains the S3 Select availability change behind a plausible diagnosis, and the alternatives I would consider for a new project in 2026.

What S3 Select was designed to do

S3 Select lets an application send a SQL expression against one S3 object and receive selected records instead of downloading the entire object first.

It supports a subset of SQL over CSV, JSON and Apache Parquet inputs, with CSV or JSON output. For example, an application could request particular employee fields or filter records by department.

The single-object scope matters. A query against S3Object isn't a query across a bucket or a database of related tables.

What changed on July 25, 2024

In its July 2024 announcement, AWS closed new customer access to S3 Select, effective July 25, 2024. Existing eligible customers can continue using it. AWS also stated that it did not plan to introduce new capabilities.

The distinction is eligibility to use S3 Select, rather than simply how old an AWS account is. An older account isn't automatically evidence of existing S3 Select access.

My observed MethodNotAllowed response is consistent with these availability restrictions. However, AWS Support did not independently confirm the test account's eligibility, and the error alone does not establish the exact cause.

That qualification matters throughout the tests below.

The CSV query in Buckets — TC-S3SEL-001

I created a CSV with six employee records and a header row. It was 166 bytes, uncompressed, and encrypted with SSE-S3 (AES256).

The upload, metadata verification and object preview succeeded. In the query dialog, I chose CSV input, None for compression, and CSV output, then submitted the query at the start of this post.

Detail crops from the same testing screenshot: the CSV settings and failure notification.

Buckets displayed the failure rather than query results. Being able to upload and preview the object established that those workflows worked; it did not establish that S3 Select was available.

SSE-S3 also wasn't inherently an incompatible choice: the SelectObjectContent API documentation supports server-side encrypted objects, including SSE-S3.

Reproducing it outside Buckets

I next used AWS CLI to separate the application interface from the underlying service operation. This is the equivalent command with generic resource names:

aws s3api select-object-content \ --bucket example-test-bucket \ --key data/report.csv \ --expression "SELECT * FROM S3Object s LIMIT 5" \ --expression-type SQL \ --input-serialization \ '{"CSV":{"FileHeaderInfo":"USE"},"CompressionType":"NONE"}' \ --output-serialization '{"CSV":{}}' \ --region us-east-1 \ /tmp/select-results.csv 

FileHeaderInfo: USE tells S3 Select to treat the first CSV line as a header. The operation and serialization options are documented in the AWS CLI reference.

My independent CLI attempt returned:

An error occurred (MethodNotAllowed) when calling the SelectObjectContent operation: The specified method is not allowed against this resource. 

The independent CLI attempt returned the same error. Private resource and profile details are covered.

This was the strongest evidence in the investigation: the failure was reproducible without Buckets. It narrowed the investigation, while leaving the exact AWS-side reason unresolved.

Invalid SQL didn't produce a syntax error — TC-S3SEL-002

The next scenario was intended to check SQL error handling. I deliberately submitted:

SELECT FROM S3Object s 

I received the same MethodNotAllowed response. Correcting the expression and retrying didn't change the outcome.

Invalid SQL produced the same service response as the corrected query.

The editor remained responsive and let me retry. But I did not verify how Buckets presents an actual SQL syntax error: no parser-specific response was observed. The test also cannot reveal AWS's internal order of request validation.

JSON reached the same boundary — TC-S3SEL-003

I then created an uncompressed JSON Lines file with five employee records, totaling 314 bytes. Buckets identified it as JSON. With JSON input and CSV output selected, I submitted:

SELECT s.name, s.department FROM S3Object s WHERE s.department = 'Engineering' 

The JSON query also returned MethodNotAllowed; no matching records were returned.

The expression was intended to select names and departments for Engineering employees. That describes the query's intention, rather than an observed result. AWS rejected this request with the same error as the CSV request.

A clearer explanation in Buckets v2.8.9

During the later JSON testing, v2.8.9 gave a more useful explanation of the service restriction. It discussed possible S3 Select availability issues and retained the original AWS error code, response and request identifiers.

The explanation was careful about uncertainty: possible causes included account eligibility and unsupported resource types. The AWS API reference confirms that directory buckets and S3 on Outposts do not support this operation. Those are documented possibilities, not confirmed findings about my test environment.

The expanded response is visible in the BZIP2 screenshot below, with request identifiers covered. It helped explain why repeatedly rewriting the SQL might not resolve this particular failure.

What the compression controls proved — TC-S3SEL-005

Buckets offered None, GZIP and BZIP2 in its compression dropdown. I could select GZIP and BZIP2 successfully.

GZIP was selectable. Selecting an option does not compress the stored object.

I reused the existing uncompressed JSON object and selected BZIP2. No compression-specific mismatch warning appeared before submission. When I ran the query, AWS returned MethodNotAllowed again.

BZIP2 selected for an uncompressed object. The displayed explanation concerns S3 Select availability, not a detected compression mismatch.

The dropdown worked as a UI control. Actual AWS decompression and compression-mismatch handling were not verified. I cannot claim that Buckets detected the mismatch.

AWS's format requirements distinguish these cases:

S3 Select also has a 256 KB SQL-expression limit and a 1 MB input/result-record limit. These constraints are separate from service eligibility. Proper compression testing would need working S3 Select access and correctly compressed fixtures as well as mismatch cases.

Separating service behavior from application behavior

These tests made the responsibility boundary clearer:

The CLI reproduction supports treating this observed failure as an AWS service response rather than assuming a defect in the Buckets SQL editor. It doesn't certify every part of the application: successful execution, syntax-error presentation and compression processing still need verification in an eligible environment.

Amazon Athena as an alternative

For SQL over a dataset spanning many S3 objects, Amazon Athena is a more suitable direction. It is a serverless analytics service that queries S3 data using SQL, with broader analytical capabilities than S3 Select's single-object API.

In a common setup, the AWS Glue Data Catalog stores table metadata: column names and types, data locations, format information and partitions. A crawler can discover that metadata, or it can be defined manually. A crawler is optional; see the Glue catalog documentation.

Illustrative architecture. Glue supplies metadata; it is not an intermediate store for the source records.

After defining a suitable employee table, the equivalent analytical query could be:

SELECT name, department FROM employees WHERE department = 'Engineering'; 

This is an illustrative Athena query, not something successfully executed during these S3 Select tests. Moving to Athena requires table definitions, permissions and result configuration; it isn't just changing an API name.

Where the results go

With customer-managed results, Athena writes to an S3 location selected by the client or workgroup. An enforced workgroup setting takes precedence. For API calls, StartQueryExecution.OutputLocation supplies the client-side location; a console setting alone does not configure API calls. See result-location settings.

Alternatively, a workgroup can enable Athena managed query results. This removes the need to supply your own results bucket. Results are retained for 24 hours at no additional managed-results storage cost, then automatically deleted. This mode does not support query-result reuse.

Costs, limits and when I would process locally

AWS currently illustrates on-demand Athena SQL pricing at US$5 per TB scanned on its pricing page. Check the applicable Region and current rate before estimating a workload. Billing concerns data scanned, rather than just the rows returned. AWS documents rounding to the next MB and a 10 MB minimum per query in its cost-model guidance.

Other models include SQL Capacity Reservations, billed for compute capacity, and Apache Spark, billed for compute use. S3 storage, requests and applicable transfer charges remain relevant, including customer-managed results. Glue catalog usage can incur charges beyond its free allowance; optional crawlers and ETL jobs are billed separately under Glue pricing.

For larger datasets, partitioning, compression and columnar formats such as Parquet can reduce scans. Workgroup scan controls can help constrain query usage.

Athena still has service quotas, including regional concurrency and query timeouts, and a 262,144-byte query-string limit. Its SQL limitations include a 32 MB row/column size ceiling.

For my 166-byte CSV or 314-byte JSON fixture, I would usually download the object and filter it with Python, pandas or DuckDB. That avoids catalog setup for a tiny one-off task, though S3 requests, transfer and local resources still matter. Athena becomes more compelling when the dataset and repeated analytical work justify that setup.

What I learned

No scenario produced successful S3 Select query results. The useful findings were the independent CLI reproduction, the working input controls, and the clearer explanation in v2.8.9.

The lesson I will carry forward is to reproduce an unexpected service error outside the application before deciding which layer needs fixing. Here, that prevented a blocked execution test from becoming an unsupported claim about SQL or compression behavior.

My next article will follow the Glue, Athena and S3 Tables workflow: defining queryable data, running SQL, inspecting result storage and understanding the costs. Those are the next steps to test, rather than outcomes established here.

References

• AWS: S3 Select availability announcement
• S3 Select formats and limits · CLI reference
• Athena User Guide · Pricing
• Glue Data Catalog
• Athena result locations · Managed results