Published 18/09/2026 By nAG
How nAG HPC Services helped an aerospace and defense manufacturer extend their on-premises compute into Google Cloud, without loosening a single control.
An aerospace and defense manufacturer came to us with a familiar problem and a complex challenge.
The familiar part: their on-premises HPC cluster was saturated. Simulation queues were measured in days, engineering teams were competing for the same nodes, and the next hardware refresh was both expensive and slow to arrive.
The challenge was different: nearly every workload touched controlled technical data, which put the environment squarely inside NIST SP 800-171, export compliance requirements, and a set of internal security standards written years before anyone at the organization had considered running a workload outside their own data center.
Their security team’s opening position was reasonable and, in our experience, extremely common: this data does not leave our building.
The environment we ended up building does exactly what they needed anyway: scheduling, orchestration, and control plane logic running in Google Cloud, with compute capacity extending across a private link into their existing on-premises data center. Cloud provides the elasticity and the automation, while the controlled workloads remain exactly where the compliance posture requires them to be.
Getting there took longer than building it.
We want to be honest about where the effort actually went, because it’s rarely where people expect.
Standing up a Slurm cluster with Cluster Toolkit is well-trodden ground, and wiring private connectivity between a cloud VPC and a corporate data center is a solved problem; our engineers could have had a functioning hybrid scheduler running within weeks.
What took months was requirements decomposition.
NIST SP 800-171 sets out 110 requirements written in the context of information systems, not cloud primitives. A line such as “Limit system access to authorized users” reads simply enough on the page, but turning it into an IAM model that can survive an assessor’s questions (one that covers service accounts, break-glass access, scheduler daemons acting on behalf of users, and the boundary between cloud-side orchestration and on-prem execution) is an architecture decision with a dozen downstream consequences.
Multiply that by export compliance requirements around personnel eligibility and data handling, then layer the client’s own internal security standards on top, and the real deliverable becomes clear. We weren’t building a cluster so much as a defensible, documented argument that every control in their compliance baseline had a specific, verifiable implementation in the new environment. That argument is the product; the infrastructure is what falls out of it.
Once the requirements were mapped, the implementation followed a principle we hold to on every regulated engagement: controls should be structural, not procedural. If compliance depends on an engineer remembering to do the right thing, it will eventually fail; if it depends on the platform refusing to do the wrong thing, it won’t.
In practice, that meant:
None of these components are exotic; what made the engagement difficult was proving, control by control, that the combination satisfied a compliance baseline nobody had previously mapped to cloud services.
The technical work was necessary, but it wasn’t sufficient.
The genuine milestone in this project was the moment the client’s security organization stopped treating the cloud environment as a risk to be contained and started treating it as a control surface they trusted more than the one they had. That shift didn’t happen in a design review; it happened over months of sitting with their security architects, their compliance leads, and eventually their assessors, answering the same question in increasing detail: show me exactly how this requirement is met, and show me how you’d prove it.
A few things made the difference:
Three things worth passing on to anyone facing a similar problem:
Strict compliance requirements don’t have to mean stalled modernization. If you’re running HPC or research workloads under NIST 800-171, export compliance obligations, or a comparable regime, and you’re being told cloud isn’t an option, it often is. It just requires doing the interpretation work properly, with people who’ve done it before.
We’d be glad to talk through your environment.
The architecture pattern (splitting control plane from compute plane) applies wherever controlled data needs to stay on-premises while scheduling and orchestration benefit from cloud elasticity. We’ve applied the same principle across defense, manufacturing, and research environments with comparable data handling requirements. What changes case to case is the specific control mapping, not the underlying design.
That was the client’s starting position, and it’s a reasonable one. The problem is that it doesn’t solve the actual constraint, which is queue time and elasticity, and it locks in a fixed capacity ceiling that a hardware refresh only pushes out a few years. Hybrid lets the controlled workloads stay exactly where compliance requires while the scheduling and automation layer gets cloud-native elasticity.
Longer than the infrastructure build. In this engagement, standing up the Slurm cluster and private connectivity took weeks; mapping 110 NIST requirements to specific, evidenced cloud implementations took months. Any timeline estimate that doesn’t budget separately for requirements decomposition is likely to be optimistic.
Directly, and from the start. Controls designed with the people who have to defend them get approved; controls presented at the end get challenged. We sit with security architects, compliance leads, and eventually assessors throughout, not just at sign-off.
Assured Workloads, VPC Service Controls, CMEK with external key management, and Organization Policy constraints, working together rather than individually. The goal is a boundary that’s a property of the environment itself, not something that depends on a policy document being followed correctly.
The specific controls named here are Google Cloud primitives, but the architecture pattern, hybrid scheduling with a private link and a clearly defined compliance perimeter, translates to other major cloud providers with their equivalent controls.
That’s the norm rather than the exception. The mapping exercise has to account for the client’s own internal standards layered on top of the regulatory baseline, and in our experience those internal standards are often the more demanding layer of the two.