Architecture Visual

One Lambda function, two API Gateway front doors: an open HTTP API for the frontend, and a key-protected REST API behind a custom domain, both proxying into the same weather lookup.

HTTP API Path (Open, CORS-Enabled)

language Frontend / Browser fetch() with lat/lon
→
hub HTTP API weather-demo-api, no auth
→
bolt Lambda Proxy get-weather-demo, Python
→
cloud Open-Meteo API Current weather conditions

REST API Path (API Key + Custom Domain)

vpn_key Client + x-api-key curl or authenticated caller
→
dns weather-api.joesparkman.com Regional custom domain, ACM cert
→
shield REST API + Usage Plan Throttle 10 rps, 1000/day quota
→
bolt Same Lambda Function Shared backend with HTTP API

DNS and Certificate (Manual, GoDaddy)

verified_user ACM Certificate DNS-validated, us-east-2
→
dns GoDaddy CNAME Records Validation + domain mapping
→
hub API Gateway Custom Domain Regional endpoint
→
link Mapped to REST API Stage weather-demo-rest-api / dev

Both gateways proxy into the exact same Lambda function, so every behavioral difference visitors see (auth, throttling, custom domain) comes from the API Gateway configuration, not the backend code.

hubHTTP API: Lightweight, low-cost gateway type, CORS-enabled, open by default, what the frontend calls.
shieldREST API: Full-featured gateway type, requires an x-api-key header and enforces a usage plan (throttling and daily quota).
boltLambda: A single Python function calls Open-Meteo with the incoming lat/lon and returns current conditions as JSON, shared by both gateways.
verified_userACM: A regional certificate for weather-api.joesparkman.com, validated via a CNAME record added by hand in GoDaddy.
dnsDNS: joesparkman.com is managed outside Route 53, so the certificate validation and domain-mapping CNAMEs are added manually rather than via CloudFormation.
savingsCost: Runs entirely within AWS free-tier limits; the API key lives in SSM Parameter Store (SecureString) instead of Secrets Manager to keep cost at zero.
Open App Build Story View Source