Deploying a Static Proposal Page: S3 + CloudFront + Route53 Architecture for a Charter Services Site

What Was Done

Created and deployed a new static HTML proposal page for a charter service offering at queenofsandiego.com/proposals/jada-charter-proposal-sue.html. The page presents two pricing tiers for ash scattering ceremonies, includes regulatory compliance notes, historical context, and a contact form. The deployment leveraged existing static site infrastructure: S3 for storage, CloudFront for caching and edge delivery, and Route53 for DNS resolution.

Technical Details

File Structure & Content Organization

The proposal file was created at:

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

This follows the existing site directory structure where proposal templates are stored in the /proposals subdirectory. The file is a static HTML document with embedded CSS for styling and no external dependencies beyond the site's standard stylesheet patterns.

Content sections included:

  • Pricing Options: Two discrete service tiers (2-hour Captain-only option at $750; 3-hour full-crew option at $1,575) designed to minimize decision fatigue while offering choice
  • Regulatory Compliance: Notes on USCG licensing, EPA/MPRSA ash scattering regulations, and bareboat charter legal distinctions—critical for liability and customer clarity
  • Brand Context: Historical Hollywood connection narrative (Bogart, Bacall, Flynn, Wayne) to differentiate the service offering
  • Call-to-Action: Contact form using bookings@queenofsandiego.com as the destination email

No Meta Tags or Internal Metadata

Per site standards documented in /Users/cb/.claude/projects/-Users-cb-Documents-repos/memory/feedback_no_meta_copy_in_proposals.md, proposal pages are intentionally kept free of duplicated meta information. This reduces maintenance overhead and prevents copy drift between metadata and page content. The proposal is indexed naturally through the site's public URL structure rather than through explicit meta tag SEO.

Infrastructure & Deployment Pipeline

S3 Upload

The file was uploaded to the S3 bucket configured in the site's deployment scripts (referenced in /Users/cb/Documents/repos/sites/queenofsandiego.com/publish_static_site.sh). The upload command:

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

Credentials were sourced from environment variables loaded via /Users/cb/Documents/repos/.secrets/repos.env (standard practice for CI/CD security in this codebase).

CloudFront Invalidation

After S3 upload, a CloudFront cache invalidation was issued to remove the old cached version (if any) and propagate the new content to edge locations globally:

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

This ensures that users requesting the page within seconds of deployment receive the latest version rather than stale cached content. The distribution ID is maintained in the deployment configuration and tied to the primary domain queenofsandiego.com.

Route53 & DNS Resolution

No Route53 changes were required for this deployment—the path /proposals/jada-charter-proposal-sue.html is served by the existing A record pointing to the CloudFront distribution for queenofsandiego.com. The domain's DNS configuration already supports arbitrary path patterns through CloudFront's origin behavior rules.

Key Architectural Decisions

Static HTML Over Dynamic Rendering

The proposal was deployed as pure static HTML rather than as a dynamic page generated from a template engine or CMS. Rationale:

  • Zero runtime overhead—no server-side rendering or database queries
  • Maximum CloudFront cache efficiency—entire page is cacheable with a long TTL
  • Version control compatibility—the HTML file is tracked in Git alongside other site content
  • Proposal-specific content (pricing, regulatory disclaimers, contact instructions) is infrequently updated and benefits from explicit file management

S3 + CloudFront + Route53 Trio

This is the site's standard architecture for all static content. Benefits:

  • S3: Durable, versioned storage with low operational overhead
  • CloudFront: Global edge caching with automatic HTTPS, reducing latency for users worldwide and absorbing traffic spikes without additional server scaling
  • Route53: Managed DNS with health checks and failover capability (not used for this specific page, but part of the overall architecture)

No Personal Data in Proposals

The file explicitly excludes personal contact information (e.g., Carole's name or personal email) from its body. Instead, a generic booking email (bookings@queenofsandiego.com) is used as the contact destination. This pattern prevents accidental leakage of PII into a publicly indexed proposal and centralizes contact routing to a monitored mailbox.

Verification & Live Testing

After deployment, the page was verified as live and accessible:

curl -s "https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html" | grep -E "[specific_content_pattern]"

This confirmed that CloudFront was serving the new content and that the invalidation had propagated through the edge network.

What's Next

  • Image Integration: Photo assets for the proposal (vessel banner, interior shots, photo strips) are pending. Once file paths are provided, they will be copied to /Users/cb/Documents/repos/sites/queenofsandiego.com/assets/images/interior/ and referenced in the HTML with relative paths
  • Payment Integration: Stripe payment links for deposits may be wired into the contact form or pricing section (infrastructure already exists in other parts of the site)
  • Form Backend: The contact form currently lacks a backend handler; this should point to a serverless function or email service integration to route submissions to bookings@queenofsandiego.com
  • Analytics: Consider adding CloudFront access logs or a client-side analytics snippet to track proposal engagement and conversion