S3 Select's MethodNotAllowed errors traced to AWS closing the feature to new accounts

A developer investigating a failed SQL query against an S3 object has traced the problem to a quiet availability change: AWS stopped granting S3 Select access to new customers in July 2024, and accounts without eligibility now receive a MethodNotAllowed error on every query attempt.

The write-up, published on dev.to, walks through four test scenarios in the Buckets desktop app (versions 2.8.7 and 2.8.9) and, more importantly, in a direct AWS CLI call.

How the failure surfaced

The author uploaded a small CSV — six employee records plus a header row, 166 bytes, uncompressed, encrypted with SSE-S3 — to a test bucket. Upload, metadata verification and object preview all succeeded. But submitting SELECT * FROM S3Object s LIMIT 5 returned the error message "the specified method is not allowed against this resource".

Rewriting the SQL didn't help. Notably, a deliberately malformed expression, SELECT FROM S3Object s, produced the same MethodNotAllowed response rather than a SQL syntax error, suggesting the request was rejected before expression parsing — though the author stresses the tests cannot reveal AWS's internal validation order.

The encryption choice wasn't the culprit either: according to the dev.to post, the SelectObjectContent API documentation supports server-side encrypted objects, including SSE-S3.

Reproduced outside the app

To rule out the application layer, the author ran the equivalent select-object-content call through the AWS CLI, with CSV input serialization and FileHeaderInfo set to USE so the first line is treated as a header. The CLI returned the identical MethodNotAllowed error.

A separate JSON Lines file — five employee records, 314 bytes, uncompressed — failed the same way when queried with SELECT s.name, s.department FROM S3Object s WHERE s.department = 'Engineering'.

According to the dev.to post, this cross-tool reproduction was the strongest evidence in the investigation: the failure exists without Buckets, pointing to the AWS service side while still leaving the exact AWS-side reason unresolved.

What changed in July 2024

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

The post adds two careful qualifications. First, eligibility is not simply a matter of account age — an older account is not automatically proof of S3 Select access. Second, AWS Support did not independently confirm the test account's eligibility, so while the observed MethodNotAllowed responses are consistent with the availability restriction, the error alone does not establish the exact cause.

Other documented possibilities exist: the AWS API reference confirms that directory buckets and S3 on Outposts do not support the operation. A later version of the Buckets app, v2.8.9, surfaced a more useful explanation citing possible S3 Select availability issues, while preserving the original error code and request identifiers.

Documented limits that still apply

For accounts that do have access, the format rules remain in place. CSV and JSON inputs support no compression, GZIP or BZIP2; Parquet supports columnar GZIP or Snappy with no whole-object compression. SQL expressions are capped at 256 KB, and input and result records at 1 MB each — constraints the post notes are separate from service eligibility.

The author's compression test — selecting BZIP2 in the UI dropdown for an uncompressed object — still returned MethodNotAllowed, with no mismatch warning beforehand. The post acknowledges the dropdown worked only as a UI control, and that properly testing AWS-side decompression behavior would itself require working S3 Select access.

Why it matters

S3 Select is in a maintenance-only twilight: existing users keep it, new accounts cannot get it, and no new features are coming. Three consequences stand out. Pipelines designed in 2026 simply cannot adopt S3 Select, so architectures that assume server-side filtering of a single object need a different approach. Existing code that depends on it works today but sits on a frozen API, which makes long-term planning risky. And because the restriction surfaces as a generic MethodNotAllowed rather than an explicit availability message, debugging it burns time — exactly the trap the dev.to investigation documents. Anyone hitting this error on SelectObjectContent should check account eligibility before rewriting another query.