Agencies measure resilience against recovery time objectives written into a contract years ago, and those are easy to hit inside a single provider.
On August 20, scheduled fiber maintenance in Google Cloud’s us-west1 region cut network capacity between data centers, and the automated rerouting built to shift traffic around that kind of fault didn’t do it. Congestion built instead. More than two dozen services logged elevated errors and provisioning failures for two hours and 22 minutes; Compute Engine, Cloud Storage, Kubernetes Engine and Identity and Access Management among them. Google’s own incident report is worth reading to the end, because the remediation list includes stricter safety checks before routine maintenance and better automatic failover when capacity drops suddenly. Most customers assume both are already in place.
Three months earlier, a cooling failure in a single Northern Virginia data hall shut down servers in AWS’s us-east-1 region. Temperatures passed operating thresholds, hardware protected itself, and recovery ran into the following day.
Neither provider collapsed. One region degraded at Google. One availability zone lost power at AWS. Both failures started in physical infrastructure, and in both cases the automation meant to absorb them didn’t.
A provider doesn’t have to go under for a citizen to lose access. One region is enough. And the systems that break first are the ones people can least afford to lose. Benefits eligibility. Permitting. Case management. The public-facing front door of an agency that has no phone tree left to fall back on.
The mandate arrived without the engineers
Plenty of agencies didn’t choose multi-cloud. They were told to run it. After the Joint Enterprise Defense Infrastructure (JEDI) program collapsed, the Defense Department replaced it with the Joint Warfighting Cloud Capability program and spread defense cloud work across four providers instead of one. Bank regulators push the institutions they supervise the same direction, so no single provider becomes a concentration risk. Removing the single point of failure is the right instinct.
What the mandate doesn’t come with is the engineering bench to meet it. Government IT runs lean. The people who can architect cross-cloud failover are expensive and hard to keep, so the work goes to contractors, and the picture of how the estate actually fits together ends up scattered across three or four vendor teams. Nobody holds the whole map. At 8 a.m. on a Thursday when a region starts throwing errors, somebody has to assemble it from four vendor teams before anyone can act.
Moving accounts inside one provider took us eight months
I underestimated this before I lived it. My last company was acquired by Tenable, and the job in front of us was moving a set of accounts from one AWS account to another. Same provider. Same region. Same tooling. It took us eight to nine months.
Identity, domain name systems (DNS), networking and storage sit on each provider’s proprietary stack, and they don’t move without real work. Most of that work is discovery: figuring out what depends on what, in what order, under which permissions. We had a strong team and years of experience between us and it still ran most of a year.
Now do that between two different providers, under pressure, on the morning one of them is down.
That gap is why “we’re multi-cloud” and “we can move” are two different claims. Most agencies that describe themselves as multi-cloud are running multiple regions inside one certified cloud. It’s cheaper, and on paper it meets the recovery targets written into the contract. It also leaves them exposed to exactly what happened in Oregon in August.
The compliance math changed in July
Every cloud you add multiplies the evidence you have to produce and keep current. A team running three providers carries three sets of certification obligations it can’t let lapse, usually with the same people who handle everything else.
That math got harder this summer, because FedRAMP rewrote the rules underneath everyone. The Consolidated Rules for 2026 took effect July 4, and enforcement begins January 1, 2027. “FedRAMP authorization” is now FedRAMP Certification. Impact levels are now Certification Classes A through D. Continuous monitoring is now Ongoing Certification, and FedRAMP is explicit that the rename is deliberate, because the old term had collapsed into a synonym for vulnerability scans when the requirements are considerably broader. Plans of Action and Milestones are gone, replaced by a list of Accepted Weaknesses. FedRAMP has pushed vulnerability detection and response well past the traditional monthly scan. Word and Excel templates give way to JSON.
FedRAMP stops accepting new Rev5 certifications on June 11, 2027. Existing Rev5 certifications stay active until at least the end of 2028.
Those deadlines collide with the failover problem. The same small team that would have to execute a cross-cloud move is the team rebuilding its certification package into machine-readable data over the next 18 months. Something slips, and it’s usually the failover work, because no auditor asks about it.
Two questions worth answering before the next incident
Could you move a citizen-facing workload to your second provider this quarter? Not in a tabletop exercise. Actually move it, with identity and networking intact, and serve real traffic from it.
And could you produce the certification evidence for that move while it was underway?
Most public sector teams can’t answer yes to either one today, and money is rarely the reason. Nobody has asked them the question. Agencies measure resilience against recovery time objectives written into a contract years ago, and those are easy to hit inside a single provider. Start measuring how long it takes to stand up a working service somewhere you don’t normally run it. Do it once a quarter, with a real workload and a stopwatch. Whatever number comes back will tell you more than the continuity plan sitting in the file.
Sharad Kumar is co-founder and CEO of FluidCloud.
Copyright
© 2026 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
