Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Consolidating Static Assets: Migrating adamcherrycomics.dangerouscentaur.com to Shared dc-sites Infrastructure

What Was Done

During this development session, we completed a decommissioning task for the adamcherrycomics.dangerouscentaur.com static asset bucket. The site itself remains live and fully functional, but we removed a stale S3 bucket that was no longer part of the serving path—a remnant from an earlier per-site bucket architecture.

  • Verified that s3://adamcherrycomics.dangerouscentaur.com/ was genuinely empty and not in use
  • Confirmed CloudFront distribution was already pointing to the shared dc-sites bucket
  • Deleted the orphaned bucket to reduce operational surface area
  • Updated dashboard ticket t-29664f2c (which was already completed)

Why This Bucket Was Deletable: Architecture Review

Understanding why this bucket could be safely removed requires looking at how the dangerouscentaur.com multi-tenant infrastructure evolved:

Current Serving Path

DNS: adamcherrycomics.dangerouscentaur.com (CNAME)
  ↓
CloudFront Distribution: E2Q4UU71SRNTMB
  ↓
CF Origin: dc-sites.s3.us-east-1.amazonaws.com (shared bucket)
  ↓
CF Function (dc-sites-router): rewrites request path to
  dc-sites/adamcherrycomics.dangerouscentaur.com/index.html
  ↓
Object served from shared bucket

Previous Architecture (Now Removed)

The stale bucket s3://adamcherrycomics.dangerouscentaur.com/ was created when each site had its own dedicated bucket. This pattern worked but created operational overhead—each new site required:

  • A new S3 bucket with globally unique naming
  • Separate bucket policies and CORS configuration
  • Individual CloudFront distributions or origin configurations
  • Separate monitoring and cost allocation

Why the Bucket Was Safe to Delete

Three key verifications confirmed the bucket was not on the serving path:

  1. Bucket State: Total object count was zero. No assets, no old redirects, no fallback content.
  2. DNS Independence: The CNAME record at Namecheap pointed to dclu4nl5nln98.cloudfront.net (the CloudFront distribution), not to an S3 website endpoint. If the bucket had been deleted before this session, zero DNS lookups would have failed.
  3. Origin Verification: CloudFront distribution E2Q4UU71SRNTMB had exactly one origin: dc-sites.s3.us-east-1.amazonaws.com. No behavior rule or alternate origin pointed to the hostname-named bucket.

Technical Details: The Shared Bucket Pattern

The current architecture consolidates all dangerouscentaur.com sites into a single S3 bucket with a logical namespace and a stateless routing function:

S3 Structure

dc-sites/
├── adamcherrycomics.dangerouscentaur.com/
│   ├── index.html
│   ├── about.html
│   ├── assets/
│   │   ├── css/
│   │   ├── js/
│   │   └── images/
│   ├── img/
│   │   └── IMG_2567.jpeg (new artist portrait)
│   └── ...
├── [other-site-name]/
│   └── (similar structure)
└── [shared-assets]/
    └── (optional common resources)

CloudFront Function: dc-sites-router

The routing logic lives in a CloudFront Function (not Lambda@Edge—faster, lower latency, no cold starts). When a request arrives at https://adamcherrycomics.dangerouscentaur.com/:

// Pseudocode: dc-sites-router CloudFront Function
request.uri = "/adamcherrycomics.dangerouscentaur.com" + request.uri
// Request forwarded to dc-sites bucket with rewritten path
// S3 serves: dc-sites/adamcherrycomics.dangerouscentaur.com/index.html

This pattern decouples the request hostname from the S3 object namespace, allowing multiple sites to share infrastructure without DNS or bucket wildcard complexities.

Related Fixes From Session 2026-05-21

While the bucket consolidation was straightforward, the adamcherrycomics site had required two critical fixes in the prior session that inform the current architecture:

DNS: RFC 1034 CNAME Shadowing

BEFORE (broken):
  *.dangerouscentaur.com CNAME dclu4nl5nln98.cloudfront.net
  www.adamcherrycomics CNAME adamcherrycomics.dangerouscentaur.com (shadowed!)
  
AFTER (fixed):
  *.dangerouscentaur.com CNAME dclu4nl5nln98.cloudfront.net
  adamcherrycomics CNAME dclu4nl5nln98.cloudfront.net (explicit, no shadowing)
  www.adamcherrycomics CNAME adamcherrycomics.dangerouscentaur.com (now resolves)

The explicit adamcherrycomics CNAME added at Namecheap ensured the subdomain resolved before the wildcard could interfere.

Stripe Checkout: Deprecated Embedded Mode

The Lambda function powering the Buy Now → Stripe checkout flow had two issues:

  • Missing Dependency: The deployment package was missing typing_extensions, required by stripe-python 15.1.0+.
  • Deprecated UI Mode: The code used ui_mode="embedded", which Stripe deprecated. Switched to ui_mode="hosted_page", and the frontend now redirects to the session URL returned by the Lambda.

These fixes ensured the booking funnel worked end-to-end: custom checkout page → Lambda creates Stripe session → frontend redirects → Stripe-hosted page → success confirmation.

Key Decisions

  • Shared Bucket Over Per-Site: Consolidation reduces blast radius, simplifies access control (single bucket policy), and makes cost allocation easier via object tags or CloudFront logs.
  • CloudFront Function for Routing: Stateless, sub-50ms execution, no cold starts, and no Lambda@Edge scaling concerns. Suitable for deterministic path rewriting.
  • Explicit DNS CNAMEs: While wildcards are convenient, explicit records for heavily-trafficked subdomains prevent RFC 1034 shadowing and improve debuggability.
  • Bucket Deletion Over Archive: An empty bucket incurs minimal cost, but removing it eliminates accidental misconfiguration and keeps IAM policies focused. If needed,