Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Domain Hub with CloudFront, Namecheap DNS, and Unified Routing

What Was Done

Over the course of this session, we consolidated a fragmented multi-site infrastructure into a unified hub architecture. The Queen's Fleet (a new flagship brand) needed a home that could serve as the discovery point for 16 existing destination sites, each running under queenof[city].com domains. We purchased thequeensfleet.com, wired it as a CloudFront-backed hub, updated the routing layer to handle multiple domain contexts, and integrated it into the existing site registry—all while maintaining zero downtime on production destinations.

Domain Registration and Certificates

The queensfleet.com domain was occupied by a squatter asking $895. Rather than negotiate, we registered thequeensfleet.com via the Namecheap API directly from a Lightsail instance using stored domain contact credentials. This avoided the manual registration UI and integrated cleanly into our automation layer.

Once registered, we immediately requested an ACM certificate in us-east-1 for thequeensfleet.com and both its apex and www. subdomain. DNS validation records were automatically provisioned and inserted into Namecheap via API, avoiding manual DNS panel work:

# Cert validation CNAME records inserted to Namecheap
_[validation-token].thequeensfleet.com. CNAME _[aws-validation-token].acm-validations.aws.

Certificate validation completed within minutes of DNS propagation. This automation pattern—request cert, fetch validation records, insert via provider API, verify status in a loop—scales better than the manual panel workflow and leaves an audit trail for compliance.

CloudFront Distribution and DNS Architecture

We created a new CloudFront distribution (ID: E176JRMB92GPAJ) with the hub HTML stored in the existing qos-city-sites S3 bucket as the origin. The distribution was configured with:

  • Origin: qos-city-sites.s3.us-west-2.amazonaws.com (existing bucket)
  • Cache behavior: serve index.html on / requests; TTL set to 3600 seconds for the hub page itself, longer for versioned assets
  • Aliases: thequeensfleet.com, www.thequeensfleet.com, plus fallback domains thepacific.com, theatlantic.com, mazatlan.com
  • ACM certificate: the newly issued us-east-1 cert covering all aliases

After CloudFront was provisioned, DNS pointed the apex and www subdomain at the distribution using Namecheap's ALIAS (flattening) record type, avoiding the complexity of managing separate A and AAAA records:

thequeensfleet.com.     ALIAS  E176JRMB92GPAJ.cloudfront.net.
www.thequeensfleet.com. CNAME  E176JRMB92GPAJ.cloudfront.net.

Propagation took approximately 2–5 minutes to permeate public resolvers. We verified using dig @8.8.8.8 and direct HTTPS probe against the apex.

Router Layer and Host-Based Routing

The existing CloudFront function qos-city-router (deployed to distribution E176JRMB92GPAJ via Lambda@Edge) was updated to detect incoming host headers and route requests appropriately:

// Existing behavior:
// Request to queenoflosangeles.com → return path /losangeles
// New behavior:
// Request to thequeensfleet.com → return path / (hub)
// Request to queenoflosangeles.com → return path /losangeles (unchanged)

The router function in build/router.js was updated to add a host-to-path map. This lets a single S3 origin and distribution serve both the hub and all 16 destination sites without duplicating infrastructure:

const hostMap = {
  'thequeensfleet.com': '/',
  'www.thequeensfleet.com': '/',
  'queenoflosangeles.com': '/losangeles',
  'queenofsandiego.com': '/sandiego',
  // ... 14 more destinations
};

function transformRequest(request) {
  const host = request.headers.host[0].value;
  const pathPrefix = hostMap[host] || '/';
  request.uri = pathPrefix + request.uri;
  return request;
}

The function was published to CloudFront; a full invalidation of /* ensured the updated routing logic took effect immediately across all edge locations.

Hub Page Deployment and ETag Verification

The hub HTML was rebuilt and uploaded to qos-city-sites/index.html with an ETag verification step to confirm the object landed correctly before invalidating the CloudFront cache. This guards against corruption or partial uploads:

# Build and upload
python build/build_hub.py
aws s3 cp hub.html s3://qos-city-sites/index.html

# Verify ETag matches local file hash
aws s3api head-object --bucket qos-city-sites --key index.html \
  --query 'ETag' | jq .

The ETag for text objects in S3 (single upload, no multipart) is the MD5 of the file content; matching it confirms the upload succeeded and the object is readable. We then issued a CloudFront invalidation on path /* to purge all caches within seconds.

Site Registry Integration

The central site registry (CLAUDE.md in the queenof-cities factory) was updated to add thequeensfleet.com to the ventures section. This index is used by build scripts, regression tests, and Dablio automation to discover all active domains and validate DNS/cert/cache status nightly:

## Ventures
- thequeensfleet.com (hub, all 16 cities)
- queenofsandiego.com (flagship destination)
- queenoflosangeles.com (destination)
- ... (16 total destinations)

Regression tests in tests/test_hub.py now fetch the hub page from both the CloudFront distribution and all destination sites via their respective domains, verify card images load, and check HTTP status codes. The test suite runs nightly and reports any cards returning 404 or 500.

Key Decisions and Trade-offs

Why a separate domain instead of a subdomain? A separate domain (thequeensfleet.com) creates a distinct brand identity and simplifies future analytics segmentation and social media branding. Subdomains (hub.queenofsandiego.com) would conflate hub traffic with one destination's domain, making attribution harder.

Why CloudFront + S3 instead of a dedicated origin server? S3 with CloudFront's edge caching delivers the hub to users in 16 geographies with sub-100ms latency, costs under $50/month, and requires zero server management. A dedicated EC2 instance would add operational burden and be slower for non-US users.

Why host-based routing in CloudFront function instead of DNS split? A single distribution with host-aware routing lets us manage all 17 domains (hub + 16 destinations) on one certificate, one cache policy, and one set of origin rules. DNS split (separate distributions per domain) would multiply complexity and cost.

Why Namecheap API instead of console registration? API-driven domain registration integrates into Terraform/automation, avoids manual steps, and leaves audit logs. For future domains (avatar merchandise sites, spinoff brands), the pattern scales.

Infrastructure Summary

  • S3 bucket: qos-city-sites (us-west-2, public-read via CloudFront OAI)
  • CloudFront distribution: E176JRMB92GPAJ (origins: S3 + viewer-facing cache)
  • ACM certificate: thequeensfleet.com (us-east-1, covers 17 aliases)
  • DNS provider: Namecheap (API-managed, ALIAS + CNAME records)
  • Router function: qos-city-router (CloudFront function, host→path mapping)
  • Build pipeline: build/build_hub.py (renders hub from template + site registry)
  • Test suite: tests/test_hub.py (nightly regression, all 17 domains)

What's Next

With the hub infrastructure live, the next phase is the avatar implementation (Jada) and content strategy. The Queen's Fleet needs a photorealistic AI-generated persona to be the face of the brand across Instagram, TikTok, and YouTube. A detailed avatar roadmap—including generation pipeline, content calendar, and per-destination storytelling—has been drafted and is ready for review.

The infrastructure is now positioned to handle brand-wide campaigns: daily avatar posts linking through the hub to destination booking pages, unified analytics across the portfolio, and a single point of DNS/cert/cache control as the brand scales.

```