Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Creating a Proposal Page: Static Site Generation, S3 Deployment, and CloudFront Cache Invalidation

What Was Done

A charter proposal page was created and deployed to production at queenofsandiego.com/proposals/jada-charter-proposal-sue.html. The page consolidates pricing options, legal compliance information, historical context, and a contact form into a single, decision-optimized proposal document. This required:

  • Creating the HTML file in the proposals directory
  • Uploading assets to S3
  • Invalidating CloudFront cache distribution
  • Verifying live deployment

Technical Details: File Structure and Content Organization

The proposal file was created at:

/Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/jada-charter-proposal-sue.html

Rather than creating a new template, the existing site structure was leveraged. The page includes:

  • Pricing section: Two clearly differentiated options (Option A: 2-hour, Captain Sergio only at $750; Option B: 3-hour, full crew at $1,575)
  • Legal compliance notes: USCG licensing disclaimers and EPA/MPRSA regulations for ash scattering ceremonies
  • Historical context: Golden Age Hollywood maritime references (Bogart, Bacall, Flynn, Wayne) to establish brand narrative
  • Contact form: Simplified Q&A submission targeting bookings@queenofsandiego.com

The page was intentionally designed with decision fatigue in mind—two options instead of four, one explicitly recommended—to improve conversion rates and reduce analysis paralysis for prospects.

Infrastructure: Static Site Deployment Pipeline

The deployment followed the established static site workflow for the queenofsandiego.com domain:

S3 Upload

The HTML file was uploaded to the S3 bucket backing the production site using the AWS CLI:

aws s3 cp proposals/jada-charter-proposal-sue.html s3://[BUCKET_NAME]/proposals/jada-charter-proposal-sue.html --acl public-read

The bucket is configured with:

  • Static website hosting enabled
  • Public read ACL for all objects (site is publicly accessible)
  • Secrets stored in /Users/cb/Documents/repos/.secrets/repos.env sourced at deployment time

CloudFront Cache Invalidation

After S3 upload, the CloudFront distribution cache was invalidated to ensure immediate propagation:

aws cloudfront create-invalidation --distribution-id [DISTRIBUTION_ID] --paths "/proposals/jada-charter-proposal-sue.html"

This invalidation:

  • Clears the edge cache across all CloudFront edge locations globally
  • Forces the next request to fetch fresh content from the S3 origin
  • Propagates within 30-60 seconds to all edge locations
  • Uses the distribution ID sourced from environment variables (not hardcoded)

DNS and Routing

No Route53 changes were required—the domain queenofsandiego.com already routes through CloudFront, which serves content from the S3 origin. The new path /proposals/jada-charter-proposal-sue.html is automatically accessible once the object exists in S3 and the cache is invalidated.

Architecture Pattern: Origin + CDN + Versioning

The deployment leverages a standard three-tier static site architecture:

  • Origin (S3): Authoritative source for all HTML, assets, and static content
  • CDN (CloudFront): Global edge cache, SSL/TLS termination, request routing
  • Client: Receives content from nearest edge location, fallback to origin if miss

This pattern provides:

  • Low latency globally (users in San Diego, NYC, Europe all served from nearest edge)
  • Origin protection (S3 bucket not directly exposed to internet traffic)
  • Cost efficiency (CloudFront cheaper than server bandwidth for scale)
  • Simple deployment (file upload + cache invalidation, no build step required)

Key Decisions and Rationale

Why Not Use a New Template System?

The proposal could have been generated from a template or build process, but static HTML was chosen because:

  • Simplicity: One-time proposal for one client—no template reuse pattern identified yet
  • Speed: Direct S3 upload faster than build process (no Jekyll, Hugo, or Node build step)
  • Control: Full HTML control without abstraction layers
  • Future proposal generation can be refactored into a template system if volume increases

Why Invalidate the Entire Path?

Rather than invalidating /proposals/*, only the specific file was invalidated to:

  • Minimize CloudFront cache churn (smaller invalidation footprint)
  • Avoid unnecessary eviction of other proposal files from edge caches
  • Reduce invalidation request count (CloudFront charges per path invalidated)

Email Routing: bookings@queenofsandiego.com

The form targets a generic booking email rather than an individual address to enable organizational flexibility—proposal responses aren't tied to one person's inbox. This reduces single points of failure for prospect communication.

Deployment Verification

After deployment, the page was verified live at:

https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html

Verification steps included:

  • HTTP 200 response code
  • Content-Type header correctly set to text/html; charset=utf-8
  • Form submission targeting correct endpoint
  • No mixed content warnings (all resources over HTTPS)

Next Steps

  • Photo assets: Pending file paths for proposal images—once provided, they'll be copied to /Users/cb/Documents/repos/sites/queenofsandiego.com/assets/images/proposals/ and uploaded to S3
  • Pricing validation: Confirm $750 and $1,575 figures are accurate (original card notation was truncated)
  • Form backend: Verify email delivery and response handling for bookings@queenofsandiego.com
  • Template abstraction: If additional proposals are needed, create a proposal template system to reduce file duplication
```