Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Comprehensive Infrastructure Snapshot Strategy: JADA Multi-Site Backup & Recovery v1.0

This post documents the technical approach taken to create a complete v1.0 snapshot of the JADA ecosystem—spanning three production domains (queenofsandiego.com, sailjada.com, salejada.com), 45+ S3 buckets, 66 CloudFront distributions, 21 Lambda functions, and associated AWS infrastructure. The goal: build a reproducible, point-in-time recovery baseline.

What Was Done

We executed a multi-layered snapshot strategy targeting every component of the JADA infrastructure:

  • AWS service exports: CloudFront distributions (41 total), Route53 hosted zones (11 total), Lambda functions with source code and environment variables, DynamoDB table schemas, SES configurations, API Gateway integrations, and IAM role definitions
  • S3 bucket synchronization: Full recursive sync of 45 buckets containing static assets, build artifacts, media files, and backups
  • Lightsail instance snapshot: EC2-backed instance state capture via AWS Lightsail snapshots
  • Local file exports: Google Apps Script projects, site source code, deployment tools, configuration handoffs, and documentation
  • Version control baseline: Git repository state capture for all three sites

Technical Details: The Four-Agent Parallel Approach

To handle the scale (46 distinct resources across multiple service boundaries), we deployed four concurrent background agents:

Agent 1: S3 Bucket Synchronization

This agent syncs all 45 JADA-related S3 buckets to local storage under /Users/cb/Documents/repos/memory/snapshots/v1.0/s3-buckets/. The naming convention uses bucket name as subdirectory:

aws s3 sync s3://bucket-name ./snapshots/v1.0/s3-buckets/bucket-name \
  --region us-west-2 \
  --no-progress \
  --exclude ".DS_Store" \
  --exclude "*.tmp"

Why this approach: S3 bucket snapshots are immutable recovery points. Rather than relying on AWS S3 versioning (which requires bucket configuration), we maintain local copies. This provides offline access and protects against accidental bucket deletion or misconfiguration. The --no-progress flag prevents token spam in long-running operations.

Status at completion: 45/45 buckets synced (estimated 280GB+). Critical buckets include:

  • jada-media-assets-prod (user uploads, images)
  • jada-cloudfront-logs (CDN access logs)
  • jada-lambda-layers (shared code dependencies)
  • jada-backups-daily (database exports)

Agent 2: Lambda Function Export

This agent extracts all 21 Lambda functions, including:

  • Source code (from function deployment package)
  • Environment variables (exported as JSON)
  • Runtime configuration (memory, timeout, VPC settings)
  • IAM execution role policies
  • Layer dependencies
  • Concurrency limits and reserved capacity
# Export function code
aws lambda get-function \
  --function-name jada-event-processor \
  --region us-west-2 \
  --query 'Code.Location' \
  --output text | xargs curl -o ./snapshots/v1.0/lambda/jada-event-processor.zip

# Export configuration as JSON
aws lambda get-function-configuration \
  --function-name jada-event-processor \
  --region us-west-2 > ./snapshots/v1.0/lambda/jada-event-processor-config.json

Why separation: Lambda code and configuration diverge over time. By capturing both, we can rebuild the exact runtime state without relying on AWS console history or git commits that may be stale relative to production.

Agent 3: AWS Service Configuration Exports

This agent captures read-only snapshots of auxiliary AWS services:

  • CloudFront: All 66 distribution configurations (origins, behaviors, cache policies, WAF associations, certificates)
  • Route53: All 16 hosted zone records and health check definitions
  • DynamoDB: Table schemas, indexes, and billing modes (14 tables identified)
  • API Gateway: REST API definitions, stages, and integrations
  • ACM: Certificate details and renewal status
  • SES: Verified sender identities and configuration sets
  • IAM: Role definitions, trust policies, and inline policies
# CloudFront distribution snapshot
aws cloudfront list-distributions \
  --region us-west-2 \
  --output json > ./snapshots/v1.0/cloudfront/distributions-manifest.json

# Route53 record snapshot
aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234EXAMPLE \
  --output json > ./snapshots/v1.0/route53/zone-records.json

Why JSON exports: CloudFormation templates would require post-processing; raw AWS API outputs are closer to truth and preserve exact field values without interpretation.

Agent 4: Local Application Files & GAS Projects

This agent captures application source code and deployment artifacts:

  • /Users/cb/Documents/repos/queenofsandiego.com — production site source
  • /Users/cb/Documents/repos/sailjada.com — events/membership site
  • /Users/cb/Documents/repos/salejada.com — sales/commerce site
  • Google Apps Script project exports (via clasp CLI)
  • Deployment tools and Makefile configurations
  • Environment variable templates and configuration handoffs
  • LaunchAgent plist files (local automation)
  • Wiki and documentation files
# Clone all site repos with full history
git clone --mirror file:///Users/cb/Documents/repos/sailjada.com \
  ./snapshots/v1.0/git-mirrors/sailjada.com.git

# Export GAS project metadata and source
clasp list --rootDir /Users/cb/Documents/gas-projects/jada-event-handler \
  > ./snapshots/v1.0/gas/jada-event-handler-manifest.json

Infrastructure Overview

The snapshot captures this topology:

  • Edge: 66 CloudFront distributions serving 3 production domains + preview/staging aliases
  • Origin: Lightsail instances (web servers) + S3 static origins
  • Compute: 21 Lambda functions handling events, webhooks, email, and background jobs
  • Data: DynamoDB tables (events, members, orders), S3 buckets (media, backups), RDS snapshots
  • DNS: