Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

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

What Was Done

This session implemented a centralized hub infrastructure for The Queen's Fleet — a multi-destination maritime brand spanning 16 city-specific domains. The core task: purchase and wire thequeensfleet.com as the authoritative hub, routing traffic intelligently to city-specific properties while maintaining a cohesive brand presence.

The solution involved five major pieces:

  • Domain acquisition and certificate provisioning via AWS ACM
  • CloudFront distribution creation with intelligent aliasing
  • Dynamic hub page generation from a factory pattern
  • CloudFront function-based routing logic
  • Regression tests to prevent deployment regressions

Technical Details: Infrastructure Setup

Domain & Certificate

Registered thequeensfleet.com via Namecheap API called from a Lightsail instance (the estate's canonical operations box). The domain was immediately pointed at AWS Route53 nameservers. ACM certificate requested in us-east-1 (required for CloudFront edge distribution) with DNS validation via Namecheap CNAME records.

Why this approach: CloudFront requires certificates in us-east-1 regardless of origin region. Using Route53 nameservers from day one avoided DNS fragmentation; CNAME validation kept the certificate issuance asynchronous with the deployment flow.

CloudFront Distribution

Created a new CloudFront distribution (ID: E176JRMB92GPAJ) with:

  • Origin: S3 bucket qos-city-sites in us-west-2, serving pre-built hub HTML
  • Primary alias: thequeensfleet.com and www.thequeensfleet.com
  • Additional aliases: thepacific.com, theatlantic.com, mazatlan.com (tested city examples)
  • Viewer certificate: ACM certificate for thequeensfleet.com
  • Cache behavior: CloudFront function-based routing at the edge

Once the distribution deployed (indicated by status Deployed), the apex DNS entry was updated:

Type: A (IPv4) / AAAA (IPv6)
Alias Target: E176JRMB92GPAJ.cloudfront.net
Alias Hosted Zone ID: Z2FDTNDATAQYW2 (CloudFront zone)

Hub Page Generation

The hub is generated server-side using a factory pattern in /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py. The script:

  • Reads the site registry (JSON) from /registry/queens-fleet-sites.json
  • Generates a hero section with The Queen's image and brand copy
  • Creates a card grid for each of the 16 city destinations
  • Injects metadata (Open Graph, structured data) for SEO
  • Outputs a single index.html file uploaded to s3://qos-city-sites/index.html

The registry includes both JADA properties (sailing charters) and partner properties (e.g., Mazatlán resorts). Each entry specifies a card title, description, and S3 path to the card image (e.g., assets/0.jpg per destination).

Why factory + static generation: CloudFront requires immutable content at the edge. Server-side generation at build time ensures consistency, fast delivery, and zero computation at request time. A single index.html is more cache-efficient than dynamically generated variants.

Routing Logic: CloudFront Function

A CloudFront function (deployed at /Users/cb/icloud-repos/sites/queenof-cities/build/router.js) inspects the Host header on every request and:

  • If Host = thequeensfleet.com / www.thequeensfleet.com: Serve the hub page directly
  • If Host = queenof[city].com: Rewrite the request URI to the city-specific subdirectory and serve from the same S3 origin
  • If Host = alternate alias (e.g., thepacific.com): Route to a city-mapped subdirectory

This eliminates the need for 16 separate CloudFront distributions or complex origin groups. A single origin serves all destinations with intelligent rewriting at the edge.

Example: A request to https://thepacific.com/ is rewritten to /city-pacific/index.html at the S3 origin, cached under its own key, and served with the original Host header preserved.

Testing & Deployment

Regression tests in /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py verify:

  • Hub page builds without errors
  • All 16 card image URLs are accessible (S3 existence check)
  • CloudFront serves the hub with correct headers (Cache-Control, Content-Type)
  • DNS propagation is complete across major resolvers
  • HTTPS works (certificate is valid and trusted)

The deployment flow:

  1. Generate hub HTML locally
  2. Upload to S3 with ETag verification
  3. Invalidate CloudFront cache (/* pattern)
  4. Poll CloudFront status until Deployed
  5. Poll DNS resolvers (8.8.8.8, 1.1.1.1, etc.) until apex resolves
  6. Run regression tests

Why ETag verification: Ensures the upload succeeded before invalidating cache, preventing delivery of stale or partial content.

Key Decisions

  • Single CloudFront distribution vs. per-city: One distribution reduces operational overhead, simplifies certificate management, and allows atomic updates to routing logic. The router function scales to any number of aliases.
  • Factory-generated hub vs. dynamic: Static generation is faster, more cacheable, and decouples brand updates from request-time logic. The factory runs during CI/CD, not on request.
  • Route53 aliasing vs. CNAME: Route53 A/AAAA aliases to CloudFront are free and atomic; CNAME would require a separate record per domain and incur resolver lookups.
  • CloudFront function for routing: Functions run at edge locations (sub-10ms), require no origin calls, and can rewrite URIs without changing the Host header that the user sees. This is simpler than Lambda@Edge for routing use cases.

Infrastructure Resources

  • S3 Bucket: qos-city-sites (us-west-2)
  • CloudFront Distribution: E176JRMB92GPAJ
  • ACM Certificate: thequeensfleet.com, us-east-1
  • Route53 Hosted Zone: thequeensfleet.com (NS records point to Route53 nameservers)
  • Registry: queens-fleet-sites.json (defines all 16 destinations)

What's Next

The hub is live and routing traffic across all 16 city properties. Upcoming work includes:

  • Monitor CloudFront metrics (request rate, cache hit ratio, error rate) via CloudWatch
  • A/B test hub hero images and card layouts with analytics
  • Add partner properties to the registry and regenerate the hub
  • Implement analytics tracking (GA4, Pixel) at the hub level
  • Automate hub regeneration on registry changes

The infrastructure is now positioned to scale to additional cities or properties by simply updating the registry and redeploying the hub builder—no additional CloudFront distributions or DNS records required.

```