# Hybrid Cloud for Regulated Workloads: Not All On-Prem - Author: Abdullah Chaudary - Category: Infrastructure - Published: 2026-11-04T18:37:01.256Z - Updated: 2026-11-04T18:37:01.277Z - Reading time: 5 min - Tags: Hybrid Cloud, Self-Hosted Infrastructure, Kubernetes, Terraform, GitLab CI > Hybrid cloud for regulated workloads, from client engagements in health, pharma and education: most services moved on-prem, while model training and some backups stayed in the cloud. On the engagements I worked on, hybrid cloud for regulated workloads was never the plan. Everything started in the cloud. Then most services moved on-prem, to cut cost and to get better security and compliance. Model training stayed in the cloud, and so did some backups. These were separate client engagements across healthcare, pharma, education, edtech and marketing: large scale, with many services across two environments (staging and production). [Moving one EdTech platform off AWS](/blog/aws-self-hosted-migration-cost) was a different engagement, with its own write-up. **TL;DR:** Most services moved on-prem to bare-metal Kubernetes, while model training and some backups stayed in the cloud. The results: 99.95% uptime based on the SLAs, and 45% lower monthly cloud spend per the accounts department. HIPAA, GDPR and FERPA ask for safeguards, restorable copies and control, and none of the quoted passages names a hosting location. ## How do you split a hybrid cloud for regulated workloads? On these engagements, most services ran on-prem and model training, and sometimes backups, ran in the cloud. The split was not a greenfield design: everything had been in the cloud first. - On-prem: most services, on bare-metal Kubernetes clusters. - Cloud: model training, and sometimes backups. - Tooling: Terraform managed everything. GitLab CI/CD ran the pipelines. The migration went smoothly. This post is about the split. ## What do HIPAA, GDPR and FERPA require of where data runs? HIPAA, GDPR and FERPA require safeguards, restorable copies and control over who handles the data. In the passages below, none of the three names a hosting location. Across these engagements, the frameworks in play were HIPAA, GDPR and FERPA, plus ISO standards. - HIPAA, 45 CFR 164.306(a): covered entities and business associates must "ensure the confidentiality, integrity, and availability of all electronic protected health information" that they create, receive, maintain or transmit. - HIPAA, 45 CFR 164.308(b)(1) and (b)(3): a covered entity may let a business associate handle electronic protected health information only after obtaining assurances that it will "appropriately safeguard the information", documented "through a written contract or other arrangement". - HIPAA, 45 CFR 164.308(a)(7)(ii)(A): the data backup plan must "create and maintain retrievable exact copies of electronic protected health information". - GDPR, Article 32(1): the controller and the processor "shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", including, as appropriate, "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident". - GDPR, Article 28(1): a controller "shall use only processors providing sufficient guarantees" of those measures. - GDPR, Article 44: a transfer of personal data to a third country takes place "only if" the conditions of Chapter V are met. That clause is why the choice of cloud region can be a compliance question, not only a latency one. - FERPA, 34 CFR 99.31(a)(1)(i)(B): an outside party can count as a school official if, among other conditions, it performs a function the institution would otherwise use employees for and "is under the direct control of the agency or institution with respect to the use and maintenance of education records". HIPAA, GDPR and FERPA, read together, describe outcomes: records stay confidential, copies can be restored, an outside party is under contract and control, and personal data does not leave for a third country without meeting Chapter V. On-prem is one way to meet them. A cloud provider under contract is another. ## Which workloads stayed in the cloud? Model training stayed in the cloud on these engagements, and sometimes backups did too, while the rest moved on-prem. In general, training load tends to arrive in bursts, and paying for cloud capacity during a burst can cost less than buying hardware that sits idle between runs. Services that run all day are the opposite case. A backup in the cloud is also a copy that does not sit in the same building as the original. ## What does running bare-metal Kubernetes involve? A bare-metal Kubernetes cluster has to supply for itself what a cloud provider would: load balancers, monitoring and the hardware. On these engagements, on-prem ran bare-metal Kubernetes clusters, Terraform managed everything, and GitLab CI/CD ran the pipelines. The Kubernetes documentation says: "On cloud providers which support external load balancers, setting the `type` field to `LoadBalancer` provisions a load balancer for your Service." A cluster on your own hardware has no cloud provider behind it. That piece becomes your job, and so do the monitoring and the hardware itself. For the monitoring side on a smaller scale, I wrote up [alerting for a small team with Prometheus, Grafana and Loki](/blog/prometheus-grafana-loki-alerting-small-team). For the pipeline side, [a GitLab CI security gate with Trivy and Snyk](/blog/trivy-snyk-gitlab-ci-security-gate) covers one of the checks a regulated pipeline tends to need. Neither post describes these engagements. ## What does 99.95% uptime mean in minutes of downtime? A 99.95% uptime figure allows 0.05% downtime: 21.6 minutes in a 30-day month, or about 4.38 hours in a 365-day year. That is the budget a 99.95% SLA leaves you. On these engagements, 99.95% uptime is the figure based on the SLAs. ## Limitations - This is an account of a decision across separate engagements, not an incident story. - How the 99.95% was measured, and over what window, is not published. - The baseline and period behind the 45% are not published. The figure comes from the accounts department. - Not covered: migration order, rollback plan, duration, which cloud provider, what was trained, which compliance clause applied to which workload, and any tool versions or configuration. - The HIPAA and FERPA quotes are regulation text from eCFR, and the GDPR quotes are from the Official Journal text, not regulator guidance. None of this is legal advice. - The reasoning about burst workloads, off-site backups and load balancers is general. Most of a regulated system can run on-prem, and nothing in the passages quoted here says the parts that stayed in the cloud had to leave it. [The rest of the Infrastructure field notes](/blog/category/infrastructure) cover other parts of this work. If you moved a regulated system on-prem, which workloads did you leave in the cloud, and what decided it? ## References - [45 CFR 164.306, Security standards: General rules](https://www.ecfr.gov/current/title-45/section-164.306): paragraph (a), general requirements. - [45 CFR 164.308, Administrative safeguards](https://www.ecfr.gov/current/title-45/section-164.308): paragraphs (b)(1) and (b)(3) on business associate contracts and (a)(7)(ii)(A) on the data backup plan. - [Regulation (EU) 2016/679 (GDPR), Official Journal text](https://publications.europa.eu/resource/celex/32016R0679): Article 28(1), Article 32(1) and Article 44. - [34 CFR 99.31, Under what conditions is prior consent not required to disclose information?](https://www.ecfr.gov/current/title-34/section-99.31): paragraph (a)(1)(i)(B), the school official condition. - [Kubernetes documentation: Service, type LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/): external load balancers on cloud providers. - My own experience on these engagements, as of 4 November 2026: the source for every statement about what ran where.