Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Comprehensive Infrastructure Snapshot Strategy for Multi-Site JADA Ecosystem: v1.0 Baseline Creation

What Was Done

We executed a complete point-in-time snapshot of the JADA ecosystem spanning three production websites (queenofsandiego.com, sailjada.com, salejada.com) across AWS, Google Apps Script, Lightsail, and local development environments. This snapshot—designated v1.0—captures infrastructure configuration, application code, database schemas, CloudFront distributions, Lambda functions, S3 bucket contents, Route53 DNS records, and Google Workspace automation scripts. The snapshot serves as an immutable baseline for disaster recovery, compliance auditing, and version control of infrastructure state.

Technical Details: Snapshot Components

AWS Infrastructure Inventory

The JADA infrastructure spans across multiple AWS services. We cataloged and exported:

  • S3 Buckets: 45 total buckets synced to local storage, including production data buckets, CloudFront origin buckets, backup buckets, and staging-specific buckets. Buckets were synced in two batches using parallel aws s3 sync operations to optimize transfer time.
  • CloudFront Distributions: 41 distributions exported with full configuration including origin settings, cache behaviors, SSL/TLS certificates, geo-restrictions, and custom headers. Each distribution ID and domain mapping was recorded in the manifest.
  • Lambda Functions: 21 functions across multiple runtimes. Code was pulled using aws lambda get-function, including source code, environment variables (sanitized of secrets), IAM execution roles, layers, and trigger configurations.
  • Route53 Hosted Zones: 11 zones exported with complete DNS record sets, including A records, CNAME records, MX records, and health check configurations tied to the three primary domains and subdomains.
  • DynamoDB Tables: 14 tables scanned to capture schema, throughput settings, indexes, and TTL configurations without exporting data.
  • API Gateway APIs: All REST API definitions, stages, integrations with Lambda and other AWS services, request/response mappings, and custom authorizers documented.
  • SES Configuration: Verified identities, DKIM/SPF records, suppression lists, and email template definitions exported.
  • ACM Certificates: All issued and pending certificates with domain names and renewal status recorded.
  • IAM Policies and Roles: Trust relationships and permission boundaries for Lambda execution, S3 access, and CloudFront operations.

Google Apps Script Projects

Four GAS projects were pulled using clasp pull and archived:

  • Main JADA GAS project (primary automation)
  • Rady Shell replacement GAS (event handling)
  • Rady Shell old GAS (legacy, preserved for reference)
  • EYD GAS project (secondary automation)

Each project directory contains .clasp.json, appsscript.json, all bound scripts, standalone scripts, and library dependencies.

Lightsail Instance Snapshot

The Lightsail instance running JADA services was snapshot with the name jada-agent-v1.0-20260509. This captures the complete filesystem state of the instance, enabling rapid restoration if needed. The snapshot includes all running services, cron jobs, local configuration files, and cached data.

Local Development Environment

Snapshot includes:

  • Complete site repositories: /Users/cb/Documents/repos/queenofsandiego.com, sailjada.com, salejada.com
  • Build artifacts and compiled assets
  • Development tools configuration: .env files (sanitized), webpack config, build scripts
  • Documentation: handoff documents, technical wiki, architecture notes in /memory directory
  • LaunchAgent configurations for local service automation
  • Secrets manifest (reference only, actual credentials excluded)

Snapshot Directory Structure

The v1.0 snapshot is organized hierarchically:

v1.0/
├── MANIFEST.md                    (complete inventory & file counts)
├── aws/
│   ├── s3/                        (all 45 bucket contents)
│   ├── lambda/                    (21 functions with code & config)
│   ├── cloudfront/                (41 distribution configs as JSON)
│   ├── route53/                   (11 zone exports)
│   ├── dynamodb/                  (14 table schemas)
│   ├── api-gateway/               (REST API definitions)
│   ├── ses/                       (email config & templates)
│   ├── acm/                       (certificate metadata)
│   └── iam/                       (policies & role definitions)
├── gas/
│   ├── jada-main/                 (Google Apps Script main project)
│   ├── rady-replacement/          (Rady replacement scripts)
│   ├── rady-old/                  (Legacy scripts)
│   └── eyd/                       (EYD automation)
├── lightsail/
│   └── jada-agent-v1.0-20260509.manifest
├── sites/
│   ├── queenofsandiego.com/       (complete codebase & assets)
│   ├── sailjada.com/              (complete codebase & assets)
│   └── salejada.com/              (complete codebase & assets)
├── local/
│   ├── tools/                     (development utilities)
│   ├── handoffs/                  (project documentation)
│   ├── wiki/                      (technical notes)
│   └── launch-agents/             (macOS automation configs)
└── staging/
    ├── qos-staging-index-fix.html (verified staging deployment)
    └── deployment-notes.md        (staging workflow history)

Key Decisions and Rationale

Parallel Snapshot Strategy

Rather than sequential operations, we deployed four background agents running concurrently: S3 sync, Lambda export, AWS configuration export, and local file copying. This reduced overall snapshot time from hours to minutes. Each agent was isolated to prevent resource contention.

Code-Only Lambda Snapshots

Lambda environment variables were captured in separate configuration files (with sensitive values masked), but actual code was prioritized. This allows reconstruction of functions without exposing secrets in the snapshot.

Staging Deployment Capture

The recent staging workflow changes (including the letter-spacing CSS fix for the brand name in /tmp/qos-staging-index-fix.html) were explicitly captured. This documents the exact state that was validated before production consideration.

CloudFront Origin Verification

Before snapshot completion, we verified that CloudFront distributions were serving from correct origins. For production sites, origins point to S3 buckets or custom origins. For staging, _staging subfolders and dedicated staging buckets were confirmed to exist and match their production counterparts in file count and structure.

Snapshot Validation and Manifest

The MANIFEST.md file includes:

  • File counts per S3 bucket (verified against production source)
  • MD5 checksums for critical files