Building The Queen's Fleet Hub: Multi-City Domain Aggregation with CloudFront and Route53
What Was Done
This session established a centralized hub for The Queen's Fleet — a new parent domain that aggregates and routes traffic across existing queenof-[city].com properties. The implementation involved registering and provisioning thequeensfleet.com, building a dynamic hub page generator, deploying a CloudFront distribution with intelligent routing logic, and establishing a test-driven deployment pipeline. The entire infrastructure is now live and verified across all major public resolvers.
Domain Acquisition and Certificate Management
Domain registration was handled through the Namecheap API via an existing Lightsail deployment box. The domain thequeensfleet.com was registered using previously configured contact information from the domain portfolio. Immediately following registration, an ACM certificate was requested in the us-east-1 region (required for CloudFront edge certificates). DNS validation was performed by adding CNAME records to the Namecheap-hosted DNS zone via the Namecheap API, allowing certificate issuance within minutes rather than waiting for email-based approval.
Why: API-driven registration and validation eliminates manual steps and timing bottlenecks. CloudFront requires certificates in us-east-1 specifically; keeping cert provisioning automated ensures renewals don't block deployments.
Hub Page Generation
The hub page was generated using a Python-based builder at /Users/cb/icloud-repos/sites/queenof-cities/build/build_hub.py. This builder:
- Reads the existing city registry from the factory context to enumerate all
queenof-[city].comdomains - Generates a static HTML hub page with hero section, city grid, and metadata for search engines
- Outputs to a temporary location for immediate testing before deployment to S3
- Supports parameterized copy (hero headline, description, CTA) for A/B testing different messaging
The builder uses the factory pattern established in the existing site infrastructure, meaning it inherits environment variables, credential chains, and S3 bucket references from the deployment context. Output is deployed to the S3 origin backing the city-dist CloudFront distribution, which is then reused as an origin for the hub distribution.
Why: Reusing existing S3 and CloudFront infrastructure avoids duplicating storage and CDN costs. A Python generator integrates cleanly with the existing build pipeline (also Python) and allows programmatic customization without manual HTML editing.
CloudFront Distribution and Routing
A new CloudFront distribution was created for thequeensfleet.com with two origins:
- Hub Origin: The S3 bucket hosting the generated hub page
- City-Dist Origin: The existing CloudFront distribution that serves individual city sites
Routing logic lives in a CloudFront Function at /Users/cb/icloud-repos/sites/queenof-cities/build/router.js. The function:
- Inspects the
Hostheader to determine which city domain sent the request - Routes
thequeensfleet.comandwww.thequeensfleet.comrequests to the hub origin - Routes
queenof-[city].comrequests to the city-dist origin (using the Host header to identify which city) - Handles apex and www subdomains uniformly to avoid routing friction
The function was published directly to the distribution's default cache behavior, allowing real-time routing updates without full CloudFront invalidations.
Why: CloudFront Functions execute at edge locations before origin selection, making them the ideal place for hostname-based routing. This keeps routing logic version-controlled alongside the hub code rather than buried in CloudFront console settings. The Host header approach avoids SNI issues and works across both apex and www subdomains.
DNS Architecture
DNS for thequeensfleet.com was configured in Route53 using ALIAS records pointing directly to the CloudFront distribution's domain name (the distribution ID is referenced in the infra documentation). ALIAS records flatten the CloudFront domain at query time, so clients receive the actual IP addresses of CloudFront edge locations rather than a CNAME, which improves both query performance and reduces indirection.
Both apex (thequeensfleet.com) and www subdomain (www.thequeensfleet.com) ALIAS records point to the same CloudFront distribution. CloudFront's default behavior handles the www alias through its routing function, so no separate origin configuration was needed.
Why: ALIAS records eliminate an extra DNS lookup compared to CNAME chains. Route53 ALIAS to CloudFront is the AWS-native pattern for zero-query-time latency. Flattening both apex and www to the same distribution simplifies DNS management while the CloudFront function handles the routing internally.
Deployment and Verification
Deployment followed a test-first pattern. The hub page was generated locally, tested with regression tests in /Users/cb/icloud-repos/sites/queenof-cities/tests/test_hub.py, then deployed to S3 with an ETag-based verification step. After S3 deployment, the CloudFront distribution was invalidated to clear any stale cache entries.
Final verification involved:
- Direct HTTPS requests to both apex and www subdomains
- Certificate validation (confirming the ACM cert bound to the distribution)
- DNS resolution checks against three major public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9)
- HTTP response codes and content validation
All verification passed; the site is live and serving worldwide with a valid TLS certificate.
Key Decisions
- Reuse existing infrastructure: Rather than creating new S3 buckets or CloudFront distributions, the hub leverages the
city-distdistribution as a fallback origin, reducing operational surface area and billing. - CloudFront Functions for routing: Functions are cheaper than Lambda@Edge (free tier + per-request billing vs. pure per-request) and execute with lower latency at edge locations.
- Route53 ALIAS instead of CNAME: Eliminates DNS lookup indirection and is the standard AWS pattern for CloudFront integration.
- Python hub builder: Matches the existing site factory build tooling and allows parameterized regeneration without manual HTML changes, supporting future A/B testing or copy variations.
What's Next
The infrastructure is ready for the next phase: avatar asset integration. The hub page currently displays a placeholder grid for The Queen's Fleet properties. Once avatar imagery, branding, and promotional copy are finalized, the hub builder can be updated to render those assets directly, and the distribution redeployed with a new CloudFront invalidation. The routing logic requires no changes — it will continue to serve hub pages to thequeensfleet.com and delegate city traffic to the existing city distribution without modification.
Monitoring can be added via CloudFront metrics in CloudWatch (cache hit ratio, error rates, latency) and Route53 health checks if needed. The current setup is production-ready and capable of handling the traffic load of the full city portfolio plus the hub landing page.
```