Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-City Hub with CloudFront, ACM, and Dynamic Routing

This post documents the infrastructure and deployment strategy for launching thequeensfleet.com as a central hub connecting 16 pre-existing city-specific domain sites (queenof[city].com). The work involved domain registration, SSL certificate provisioning, CloudFront distribution setup, DNS routing, hub generation, and regression testing—all coordinated to enable a single authoritative hub while preserving existing city site traffic.

What Was Done

  • Domain Registration: Registered thequeensfleet.com via Namecheap API (queensfleet.com was squatted at $895 via HugeDomains; reserved for future acquisition)
  • SSL/TLS: Requested and validated an ACM certificate for thequeensfleet.com in us-east-1 region
  • CDN: Created a new CloudFront distribution (ID: E12G09B4XHLS8Y) with origin pointing to the hub S3 bucket
  • DNS: Configured apex ALIAS and www CNAME via Namecheap API to point to CloudFront
  • Hub Builder: Wrote a Python script to generate dynamic hub HTML with links to all 16 city destinations
  • Router: Updated CloudFront Function to route requests from queenof-cities bucket to city-specific origins based on Host header
  • Testing: Created and ran regression test suite to validate hub rendering, CloudFront behavior, and origin routing
  • Registry: Added thequeensfleet.com to the site registry under the ventures section

Technical Details

Hub Generation

The hub is generated by /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py, which:

  • Reads the factory CONTEXT.md to discover all registered city destinations and metadata (16 cities)
  • Generates a single index.html file with semantic markup, responsive CSS, and a grid of linked city cards
  • Uploads the result to the hub S3 bucket with cache headers and ETag verification
  • Invalidates CloudFront cache to ensure immediate propagation

The builder uses Python's pathlib and string templating to avoid vendor lock-in; city list is derived from the factory registry, not hardcoded. This allows adding new city sites without regenerating the hub builder.

CloudFront Distribution and Routing

The new distribution E12G09B4XHLS8Y serves as the public face of thequeensfleet.com with two behaviors:

  • Default behavior: Origin: hub S3 bucket, Path pattern: /*, Caching: standard CloudFront defaults
  • City routing: Origin: queenof-cities bucket (factory), Path pattern: /cities/*, Cache behavior with CloudFront Function triggered on viewer request

The CloudFront Function at /Users/cb/icloud-repos/sites/queenof-cities/build/router.js inspects the Host header and rewrites the request URI to route to the correct city origin within the factory bucket:

// Pseudocode: if Host == queenofbostion.com, rewrite /path -> /boston/path
// Actual function handles 16 cities with O(1) lookup via object map

This pattern avoids maintaining 16 separate CloudFront distributions while preserving SEO and user experience for city-specific domains.

Certificate and DNS Validation

ACM certificate for thequeensfleet.com was requested in us-east-1 (required for CloudFront). Validation occurred via DNS CNAME records provisioned through the Namecheap API:

  • Retrieved validation records from ACM console
  • Called Namecheap API to add CNAME records to thequeensfleet.com DNS
  • Polled ACM certificate status until validation completed (typically 2–5 minutes)
  • Certificate was then available for CloudFront origin binding

DNS is hosted on Namecheap; all changes (including CloudFront ALIAS flattening for apex, www CNAME, and validation CNAMEs) were made via API to enable reproducible infrastructure-as-code patterns.

Infrastructure

Resources:

  • Domain: thequeensfleet.com (registrar: Namecheap)
  • DNS: Namecheap authoritative (ALIAS apex to CloudFront, www CNAME to CloudFront)
  • CDN: CloudFront distribution E12G09B4XHLS8Y
  • Certificate: ACM certificate for thequeensfleet.com in us-east-1
  • Origins: Hub S3 bucket (index.html), queenof-cities factory S3 bucket (16 city subfolders)
  • Invalidation: CloudFront cache invalidations via CloudFront API after hub rebuilds

Deployment artifacts:

  • /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py — Hub generation script
  • /Users/cb/icloud-repos/sites/queenof-cities/build/router.js — CloudFront Function for Host-based routing
  • /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py — Regression test suite (3 test cases: hub renders, cloudfront serves, router routes correctly)
  • /Users/cb/icloud-repos/sites/queenof-cities/infra.md — Infrastructure documentation with distribution ID, origin details, and cache invalidation procedure

Key Decisions

Why a separate CloudFront distribution for the hub? The hub needed its own SSL certificate and distribution to serve cleanly from thequeensfleet.com apex while routing city requests to the existing queenof-cities factory. A single monolithic distribution would have required refactoring city origins and risked breaking live city traffic.

Why CloudFront Function instead of Lambda@Edge for routing? CloudFront Functions execute at the viewer-request stage with <100ms latency, lower cost, and no cold starts. Lambda@Edge would add complexity for a simple Host header rewrite; Functions are sufficient and faster for this use case.

Why DNS ALIAS for apex instead of CNAME? CNAME records cannot point to ALIAS targets at the zone apex; Namecheap's API supports ALIAS flattening, which points the apex directly to CloudFront's distribution domain. This avoids the need for an intermediate redirect.

Why ETag verification on hub uploads? ETag is checked before CloudFront invalidation to ensure the new hub HTML actually wrote to S3; this prevents invalidating stale content and avoids cache inconsistencies during rapid rebuilds.

What's Next

  • Apex monitoring: A background watch task is in place to confirm apex DNS and HTTP propagation across nameserver caches (typically complete within 15 minutes)
  • queensfleet.com acquisition: If budget allows, HugeDomains listing at $895 can be purchased; the router is pre-configured to handle both thequeensfleet.com and queensfleet.com if acquired
  • Registry expansion: thequeensfleet.com has been added to the site registry ventures section; future city sites can be added to factory CONTEXT.md and will automatically appear on hub rebuild
  • Performance tuning: CloudFront cache behaviors and TTLs can be adjusted based on traffic patterns; Function logic can be extended to support subdomain routing (e.g., blog.thequeensfleet.com)

All changes are documented in /Users/cb/icloud-repos/sites/queenof-cities/infra.md and CLAUDE.md for future operator reference.

```