SHART.CLOUD | DESKTOP | LABROULETTE | MULTI-CLOUD-DNS-FAILOVER.YAML
01 - Labroulette - Health-Checked DNS Failover Across AWS and GCP
| shart.cloud / labroulette / multi-cloud-dns-failover |
MULTI *** ~130 min $6-14 reviewed 6/29/2026

Health-Checked DNS Failover Across AWS and GCP

Run the status page in both AWS and GCP and put a health-checked DNS layer in front so traffic serves from the healthy provider and fails over to the other within minutes when one goes dark — no human paging required.

#dns#resilience#networking
Lab Pingdread, a status-page company whose own status page is single-cloud — a fact that became deeply embarrassing the day its only provider had a regional incident and customers had nowhere to check whether anything was down. all labs
02 - Actions
score -- - -- votes
-- completed
State loading
03 - Scenario

Pingdread, a status-page company whose own status page is single-cloud — a fact that became deeply embarrassing the day its only provider had a regional incident and customers had nowhere to check whether anything was down.

Run the status page in both AWS and GCP and put a health-checked DNS layer in front so traffic serves from the healthy provider and fails over to the other within minutes when one goes dark — no human paging required.

Constraints

  • Active in both clouds; neither is a cold standby that needs manual promotion
  • Automatic cutover under 5 minutes on a provider-down health check
  • DNS layer and both origins fully described in one Terraform root module
  • Failover must be demonstrable by killing one origin's health endpoint
Scenario MULTI - advanced
05 - Steps
  1. STEP_01

    Stand up the GCP origin

    Deploy the status-page origin in GCP and attach a health check that polls its health endpoint, so GCP has its own opinion about whether that origin is alive.

    Terraform docs

  2. STEP_03

    Health-check the AWS origin

    Define a Route 53 health check against the AWS origin's health endpoint. Tune failure_threshold and request_interval so a real outage trips inside your 5-minute budget without flapping on one slow response.

    Terraform docs

  3. STEP_04

    Wire the failover records

    In the Route 53 zone, create a PRIMARY failover record for the AWS origin tied to its health check and a SECONDARY record pointing at the GCP origin. Set a short TTL so resolvers pick up the cutover quickly.

    Hint: TTL is half the battle — a 300s record means resolvers can cache the dead primary for up to 5 minutes regardless of how fast your health check trips.

    Terraform docs

  4. STEP_05

    Prove the cutover

    Kill the AWS origin's health endpoint, then resolve the name on a loop and watch the answer flip to the GCP origin. Record wall-clock time from "primary down" to "serving secondary" and compare it to your 5-minute RTO.

    Terraform docs

Steps 5 tasks
06 - Deliverables
  • A Terraform root module that provisions both cloud origins and the failover DNS layer
  • A README documenting the measured cutover time vs. the 5-minute target
  • A note on how DNS TTL bounds your real-world failover speed
Deliverables 3 required
07 - Rubric
The workload runs as a live origin in both AWS and GCP 25%
Health checks exist for the primary and drive automatic failover 30%
DNS failover records cut over to the secondary cloud without manual steps 25%
Measured cutover time is documented and within the 5-minute RTO 20%
Rubric self-assessed