NOAA will begin moving GFS and GEFS to Google Cloud in early 2027. H4D has scaling data, but no cited result shows a full operational cycle meeting NOAA's production window.
NOAA plans to begin moving its principal operational weather models to Google Cloud in early 2027, with completion targeted for December of that year, according to contemporary reporting. Google's whole-host H4D virtual machines will provide the primary computing backbone for the next Weather and Climate Operational Supercomputing System, or WCOSS, according to Google's announcement. NOAA identifies the Global Forecast System and Global Ensemble Forecast System among the workloads moving to the new environment.
The public evidence already shows that weather workloads can run in a commercial cloud. It does not show the complete production suite, including data assimilation, forecast execution, I/O and product delivery, repeatedly finishing inside NOAA's operational clock.
This is a change in service model, not a simple move from ownership to outsourcing. General Dynamics Information Technology described the current WCOSS agreement as supercomputing resources as a service. That contract had a total estimated value of $505 million, and GDIT designed, deployed and operated the Dogwood and Cactus systems. Google is also the "primary" provider rather than the announced exclusive provider. Those distinctions matter when judging what NOAA is replacing.
The GFS runs four times a day and produces forecasts out to 16 days, according to the National Centers for Environmental Prediction. Each cycle must ingest observations, perform data assimilation, execute the forecast and generate products for downstream use. A production forecast is judged by more than throughput. It must finish early enough for processing, dissemination and operational decisions.
That timing pressure appears in NOAA's GFS version 16 records. An implementation presentation recorded a 760-node high-water mark for the real-time parallel. A separate project plan said the data-assimilation workload required roughly three times as many nodes to remain inside its operational window, leaving a five-minute margin. The documents describe an earlier hardware environment, but they show why end-to-end timing, not a processor count, is the relevant standard.
GFS is a tightly coupled Message Passing Interface workload. Slow communication between ranks can hold up the full job, while storage and post-processing can create bottlenecks after the forecast executable finishes. Traditional dynamical numerical weather prediction also depends on memory bandwidth and double-precision computation. The field is adapting those requirements to hardware optimized for AI, a tension SCN examined in its analysis of FP64 emulation and native FP64 performance. NOAA's selected H4D backbone is CPU-only, although that does not exclude GPUs or AI accelerators elsewhere in its forecasting workflow. An all-CPU design is not a handicap by itself; LineShine took the top of the 67th TOP500 list on both LINPACK and HPCG with no accelerators.
NOAA and its Earth Prediction Innovation Center have tested Unified Forecast System workloads across AWS, Microsoft Azure and Google Cloud. A 2022 EPIC presentation, labeled draft and predecisional, reported comparable results across the three providers as the team increased core counts.
An earlier experiment gives the clearest measured example. A 60-hour Rapid Refresh Forecast System run finished in 3.96 hours on 80 AWS c5n.18xlarge instances, compared with 4.68 hours on 80 nodes of NOAA's Hera research system, according to NOAA's 2021 webinar slides. The result demonstrated feasibility, not architectural superiority. The machines differed, RRFS is not GFS, and equal node counts do not provide equal processors, memory or networking.
H4D addresses several requirements of tightly coupled work. Each VM exposes 192 vCPUs, with each vCPU representing an entire physical core because simultaneous multithreading is disabled. Google offers configurations with as much as 1,488 GB of memory, up to 200 Gbps of network bandwidth and Cloud RDMA. An H4D instance uses all vCPUs on its host, with no CPU overcommitment, according to Google's machine-series documentation. It remains a standardized cloud product operating within Google's regional provisioning, storage and maintenance architecture.
The largest-scale result highlighted in Google's H4D launch post used 192 VMs, approximately 37,000 cores, to run the LAMMPS molecular-dynamics benchmark at 92 percent parallel efficiency. That is a Google-reported, vendor-run result for a different scientific code. It provides evidence about H4D scaling. It does not establish that GFS or GEFS can meet NOAA's production window.
The acceptance test needs to cover the production system, not a best-case execution of the forecast model. SCN made that argument when Sandia accepted Spectra and the real gate turned out to be the mission-code run that followed. NOAA needs repeated measurements across full cycles, including observation ingest, data assimilation, forecast execution, storage, product generation and dissemination. Tail performance matters more than an average. A few late cycles can be operationally consequential even when the mean looks good. Tests should cover ordinary cycles and peak seasonal demand, not one reserved demonstration window.
Recovery behavior belongs in the same test. Google's documentation says H4D does not support live migration, and planned maintenance terminates the VM after typically seven days' notice. The documented maintenance frequency is approximate, not guaranteed. NOAA therefore needs to demonstrate checkpoint and restart, recovery from host maintenance, and the ability to keep a cycle inside its window after a failure.
Capacity is another acceptance condition. A production suite should not rely solely on interruptible capacity because termination or delayed acquisition could break the operational window. Google's H4D service supports on-demand use, committed-use options and scheduled capacity through Dynamic Workload Scheduler. The operative question is what start-time, placement and capacity guarantees apply to every NOAA cycle, including during a regional demand spike.
Storage and topology also need explicit tests. H4D's standard machine type limits shared-disk options, caps Hyperdisk Balanced performance at 15,000 IOPS and 240 MBps, and limits internet egress to 1 Gbps. NOAA may pair H4D with separate storage and dissemination services, but neither announcement describes that design. Acceptance should cover I/O saturation, reproducibility and performance variance, zone or region failover, and parallel operation with the existing WCOSS environment before cutover.
Neither NOAA's announcement, Google's announcement nor the cited H4D benchmark material provides an end-to-end GFS or GEFS production result on the target configuration.
The UK Met Office moved operational forecasting to a Microsoft-operated service in May 2025 after running the old and new systems in parallel. Microsoft built that service around dedicated HPE Cray EX supercomputers integrated with Azure, housed in facilities designed for the program's power, cooling and network requirements. Data Center Dynamics reported that Microsoft described it as separate from standard public-cloud hosting.
The Met Office still describes its system as cloud operated, and that language is reasonable. The architectural distinction is narrower: the Met Office uses dedicated Cray systems in purpose-designed halls, while NOAA plans to use a standardized, whole-host Google Cloud VM series within Google's regional cloud architecture. Of the two programs, NOAA is the one placing its operational suite on a standard public-cloud VM product.
NOAA's announcement and Google's announcement do not identify several details needed to assess the transition:
The service model transfers more hardware-refresh responsibility to Google, subject to NOAA's contract and qualification requirements. It also makes the capacity less visible as an identifiable machine, part of the broader gap SCN has documented between public rankings and large systems that operate outside the TOP500 record.
NOAA's transition will be proven by repeated, end-to-end production cycles that meet the forecast clock. Google's scaling chart cannot answer that question. Phase 2 must.
The SCN Staff is a small AI editorial squad working under human direction. Each agent owns one job.
Scout does the research. It runs down primary sources and checks what's already been published, on SCN and everywhere else, before a story gets written. If a claim can't be traced back to a real document, Scout flags it.
Forge writes. It takes what Scout found and turns it into a draft, argument and sentences and all. Every SCN piece starts here, then gets sharpened.
Cipher handles search: the titles, descriptions, and keyphrase work that decides whether a good article ever gets found. Least glamorous job on the squad. Also one that matters more than it looks.
Pixel makes the visuals. Images, charts, the occasional diagram, all built to SCN's brand instead of pulled from a stock library. When something's easier to see than to read, it goes to Pixel.
Editorial judgment and the final call stay with the humans. So does the fact-checking.
