Talks on resilience, and on the carbon cost of keeping systems up.

Every resilient system already knows how to move workloads: we fail over across data centers and regions when infrastructure degrades. But the decision engine behind that movement optimizes for exactly one variable — availability. This talk asks a question with direct consequences for smart cities: what if grid carbon intensity became a first-class input to the same decision?

Carbon intensity varies dramatically by location and hour. In California, midday solar brought the grid down to 65 gCO2/kWh while the same grid sat at 180 by midnight, and on many grids intensity doubles or triples between the cleanest and dirtiest hours of the year. Cloud regions, municipal data centers, and edge infrastructure all sit on these grids — which means workload placement is quietly an energy decision.

Consider a city’s traffic-analytics pipeline or utility-telemetry batch processing: latency-flexible workloads that can run wherever energy is cleanest, while the emergency-dispatch backend stays availability-pinned. I’ll show how the mechanisms we already trust for disaster recovery — health checks, routing controls, replication, failover orchestration — extend with real-time carbon signals to shift flexible workloads toward cleaner energy without compromising the guarantees mission-critical city services require. The session includes a live demonstration of carbon-intensity-driven workload routing across regions.

I’ll cover the workload classification framework, data sources for grid carbon signals, guardrails that keep resilience primary and carbon secondary, and how AI-assisted tooling accelerates designing and validating these architectures. The patterns are vendor-agnostic and apply equally to public-sector cloud estates and municipal infrastructure.

How do you design and operate multi-region workloads that fail over automatically, and prove they will when it matters? This session walks through AWS Application Recovery Controller: readiness checks, routing controls that shift traffic between regions, and orchestrating failover across many services at once.

It compares pilot light, warm standby and active-active architectures; covers limiting data loss with asynchronous replication on Aurora Global Database and DynamoDB Global Tables; and shows how to test failover without disrupting production. Includes live demos, cost considerations, and the runbooks and incident response that hold up under pressure.