Privacy-friendly site analytics with CloudFront logs and Athena

Thu, 08 Oct 2026 00:00:00 GMT

For a personal site, a JavaScript analytics tag is often overkill: it slows pages down, needs a consent banner in the EU, and gets blocked by a large share of visitors anyway. CloudFront already records every request. You just need a way to ask questions of those logs.

The setup

Enable standard logging on the distribution, writing to a dedicated S3 bucket.
Create an Athena table over that bucket.
Query with SQL when you are curious.

There is nothing to run between queries, so the cost is S3 storage plus Athena’s per-query data scanned — negligible at personal-site traffic. Add an S3 lifecycle rule so old logs expire.

The table

CloudFront standard logs are gzipped, tab-separated files with two header lines. Columns must be declared in order; trailing ones you don’t need can be left off.

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs (
  `date`        DATE,
  `time`        STRING,
  location      STRING,
  bytes         BIGINT,
  request_ip    STRING,
  method        STRING,
  host          STRING,
  uri           STRING,
  status        INT,
  referrer      STRING,
  user_agent    STRING,
  query_string  STRING,
  cookie        STRING,
  result_type   STRING,
  request_id    STRING,
  host_header   STRING,
  request_protocol STRING,
  request_bytes BIGINT,
  time_taken    FLOAT
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
LOCATION 's3://my-cloudfront-logs/site/'
TBLPROPERTIES ('skip.header.line.count' = '2');

Questions worth asking

Most-read articles over the last 30 days, ignoring assets and bots:

SELECT uri, count(*) AS views
FROM cloudfront_logs
WHERE "date" >= current_date - INTERVAL '30' DAY
  AND status = 200
  AND uri LIKE '/blog/%'
  AND uri NOT LIKE '%.%'
  AND lower(user_agent) NOT LIKE '%bot%'
GROUP BY uri
ORDER BY views DESC
LIMIT 20;

Swap the GROUP BY for referrer to see where readers come from, or for result_type to check your cache hit ratio.

Trade-offs

It counts requests, not people. That’s fine for “what do readers care about?”.
Logs land with a delay, so this is not real-time.
IP addresses are personal data under GDPR: keep retention short and restrict who can query the bucket.

For a blog, that’s a fair deal: no script, no cookies, full ownership of the data.

Why your CSS won’t load from S3 behind CloudFront

Thu, 01 Oct 2026 00:00:00 GMT

You deploy a static site to S3, put CloudFront in front of it, open the URL — and get a page of unstyled HTML. The CSS file is there, the path is right, the browser even downloads it. It just refuses to apply it.

The symptom

Open the browser console and you will see something like:

Refused to apply style from 'https://example.com/_astro/index.css'
because its MIME type ('binary/octet-stream') is not a supported stylesheet MIME type.

The browser is doing exactly what it should. With X-Content-Type-Options: nosniff (which you want on), it will only apply a stylesheet served as text/css.

The cause

When Terraform uploads files with aws_s3_object, S3 stores whatever content_type you give it. Give it nothing and you get binary/octet-stream — for every file. CloudFront then faithfully serves that header to the browser.

The fix: a MIME map

Derive the extension from each file name and look it up in a map:

locals {
  site_dir = "${path.module}/../../apps/web/dist"

  mime_types = {
    html  = "text/html; charset=utf-8"
    css   = "text/css; charset=utf-8"
    js    = "text/javascript; charset=utf-8"
    json  = "application/json"
    xml   = "application/xml"
    txt   = "text/plain; charset=utf-8"
    md    = "text/markdown; charset=utf-8"
    svg   = "image/svg+xml"
    png   = "image/png"
    webp  = "image/webp"
    avif  = "image/avif"
    woff2 = "font/woff2"
  }
}

resource "aws_s3_object" "site" {
  for_each = fileset(local.site_dir, "**")

  bucket = aws_s3_bucket.site.id
  key    = each.value
  source = "${local.site_dir}/${each.value}"
  etag   = filemd5("${local.site_dir}/${each.value}")

  content_type = lookup(
    local.mime_types,
    element(split(".", each.value), length(split(".", each.value)) - 1),
    "application/octet-stream",
  )
}

The element(split(...)) expression takes the last segment after a dot, so index.4f2a.css resolves to css, not 4f2a.

Check it

curl -sI https://example.com/_astro/index.css | grep -i content-type

If CloudFront still serves the old header, remember it cached the old object: invalidate the path (or deploy with hashed file names, which Astro does for you).

Takeaways

S3 never guesses MIME types for you when uploading through the API.
Keep nosniff on; fix the metadata instead.
Put the MIME map in your static-site module once, and every site you deploy gets it right.

Jimmy Morin — Blog