Why does hosting reports in an S3 bucket get complicated?

Because a report is not a website. You end up maintaining a bucket policy, a CloudFront distribution to get HTTPS and a decent content type, an invalidation on every publish, and some scheme for access — signed URLs that expire, or an OAI plus an identity layer you build yourself. None of that work is about the report.

Are S3 presigned URLs good enough for sharing a report?

They are a capability, not an identity. Anyone the link is forwarded to has the same access, you cannot revoke one person, and nothing records who opened it. They also expire — which breaks the link in the doc where you pasted it, usually right when someone goes back to it.

Can I serve a multi-file HTML bundle from S3?

Yes, that is the case S3 handles well — upload the tree, set the index document, and relative references resolve. The cost is the same as any static site: a sync step, a cache invalidation, and no notion of a version anyone can diff.

What is a lighter alternative for internal reports?

A publishing layer that treats one report as the unit. Comma takes the HTML file or the whole folder, gives it a URL with identity-based visibility (private, team, email-domain, named reviewers), anchored comments, and a revision per republish on a stable id — no bucket policy, no distribution, no invalidation.

When is S3 still the right answer?

When the artifact really is a site or an app, when it must live inside your own AWS account for compliance reasons, or when it is being served at a scale and cost profile where owning the CDN matters. Those are good reasons; 'we needed to share an HTML file' is not one of them.

S3 static hosting alternatives for reports

It starts reasonably. Someone needs to share an HTML report, there is already an AWS account, and aws s3 cp is one line. Six weeks later the setup is:

a bucket, with a policy nobody wants to touch,
a CloudFront distribution, because S3 website endpoints do not do HTTPS on a custom domain,
an invalidation on every publish, and a stale-report bug the one time it was forgotten,
presigned URLs that expire, or an OAI plus a Lambda@Edge auth check somebody wrote once and nobody understands,
and no answer at all to "what changed since last week" or "where do I leave a comment".

You did not want a static site. You wanted to send someone a report.

Where the bucket model runs out

Presigned URLs are capabilities, not identity. Forwardable, unrevocable per person, unlogged per person, and they expire — so the link in the doc dies quietly.
No version anyone can read. S3 versioning stores old objects; it does not give a reviewer a diff between this week's report and last week's.
No review layer. The feedback happens in Slack, detached from the artifact, and is gone by the next publish.
Every publish is a deploy. Sync, invalidate, hope. For a document that changes daily, that is a pipeline maintained for no product reason.

The shortlist

1. Comma — the report is the unit

Drag the file or folder into the app, or POST it from the job that generated it:

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html out/index.html '{html: $html}')"

No bucket policy, no distribution, no invalidation. Visibility is identity — private, team, email-domain-gated, named reviewers, or public. Each publish to the same id appends a revision with a diff, and comments anchor to the rendered content. Multi-file output uploads as a bundle with relative references rewritten.

Not for: hosting an application, or content that must physically reside in your own AWS account.

Pricing: Free — unlimited reports, commenters and revision history.

2. Cloudflare Pages + Access — the same idea, better ergonomics

If you genuinely want to operate static hosting, Pages plus Access is a significantly lighter version of the S3 + CloudFront + custom-auth stack, with real SSO gating and no invalidation dance. Still no review layer. Full tradeoff: Cloudflare Access alternatives.

3. Netlify / Vercel — when it became a site

If the artifact grew routes and a build step, it is an app now and belongs on an app platform. See Vercel alternatives for where that line sits.

4. Keep S3 — for the archive, not the audience

A perfectly good pattern: write the raw artifact to S3 for retention and compliance, publish the human-readable version where humans will read it. These are two different jobs and there is no rule that one bucket does both.

At a glance

Option	Access model	Versions readers can diff	Comments	Ops per publish
Comma	Identity: team / domain / named	Yes	Yes	One request
S3 + presigned	Expiring capability	No	No	Upload
S3 + CloudFront	You build it	No	No	Upload + invalidate
CF Pages + Access	Real SSO	Per deploy	No	Deploy

Checked August 2026. Verify current plans before committing.

How to choose

It's a site or an app? Static hosting, and this page stops applying.
Compliance says it stays in your account? S3, and budget for the auth layer honestly.
It's a report someone should read and respond to? Publish it — share an HTML report — and keep the bucket for the archive.