Decision Framework: When to Choose Cloud‑Native vs Hybrid for Regulated Workloads

Cloud-Native vs Hybrid for Regulated Workloads: the decision you should not make by instinct

For architects and procurement teams, the choice between cloud-native and hybrid cloud is rarely about technology preference alone. In regulated industries, it is a decision about control boundaries, evidence, operating model maturity, and the cost of future change. A rushed “move everything to cloud-native” strategy can create compliance friction, data residency issues, and hidden exit costs, while an overly conservative hybrid posture can preserve control at the expense of agility, scalability, and long-term TCO. The right answer depends on workload classification, regulatory obligations, and how much operational complexity your team can safely absorb.

This guide gives you a practical decision matrix for regulated workloads, plus migration paths, risk mitigations, and examples from healthcare and finance. It also connects the strategy to real-world procurement concerns such as vendor lock-in, audit readiness, and long-term service economics. If you need a broader lens on environment design, pair this guide with our overview of local presence and global brand architecture, and for compliance-heavy deployment patterns see regulatory tech transitions after acquisition. For teams optimizing observability as they scale, our article on metrics and observability for AI operating models is also useful.

1. What regulated workloads actually require

1.1 Regulation is broader than “security”

When people say a workload is regulated, they often mean it touches sensitive data. In practice, the obligation extends well beyond encryption and access control. You may need defensible retention policies, auditable change management, provable segregation of duties, country-specific data residency, and contractual commitments around subprocessors and breach notice timelines. Healthcare teams have to think about HIPAA and HITECH, while finance teams may map decisions to PCI DSS, GLBA, SOX, FFIEC guidance, or local banking authority expectations. The important point is that the control environment must be visible, repeatable, and provable—not merely “secure enough.”

The state of the U.S. medical data storage market reflects this shift. Source material shows strong adoption of cloud-based storage and hybrid architectures, with healthcare data growth driven by EHRs, imaging, genomics, and AI diagnostics. That market trajectory signals a simple truth: regulated industries are not avoiding cloud, they are modernizing within constraints. This is also why storage, identity, and observability must be evaluated as one system rather than as isolated products. If you are building an identity layer to support this, review our guidance on identity management in the era of digital impersonation.

1.2 Regulated workloads are usually not one thing

A common procurement mistake is treating “the application” as one uniform risk profile. In reality, a healthcare platform might contain low-risk public content, moderately sensitive scheduling data, and highly regulated PHI in the same estate. A finance platform might mix public market data, internal risk analytics, and transaction processing. Those components should not all land in the same landing zone by default. The most cost-effective designs usually separate workloads by data sensitivity, recovery objectives, geographic constraints, and integration dependency.

That segmentation is why a hybrid cloud architecture remains attractive for many regulated enterprises. It lets teams keep the most sensitive or latency-sensitive components under tighter operational control while still using cloud-native services for peripheral or bursty functions. Think of it as an architecture that recognizes that one size does not fit all. To frame the downstream financial impact, it can help to compare how infrastructure choices affect recurring spend; our article on long-term costs of document management systems uses a similar lifecycle approach.

1.3 The control question matters more than the label

Many teams ask, “Should we be cloud-native or hybrid?” A better question is, “Where do we need direct control, and where can we accept platform abstraction?” Cloud-native works best when the provider’s managed services align with your control objectives and compliance evidence model. Hybrid works best when you need some combination of legacy integration, jurisdictional control, dedicated appliances, predictable latency, or a staged migration path that reduces change risk. The label matters less than the boundaries you can enforce and document.

Pro Tip: If you cannot explain how your auditors would validate identity, logging, encryption, retention, and data residency in under five minutes, your architecture is probably too implicit for regulated production use.

2. Decision matrix: cloud-native vs hybrid cloud

2.1 The scoring model

A useful decision matrix should score each workload across risk, compliance, economics, and operating complexity. Start with the following dimensions: data sensitivity, residency constraints, integration complexity, latency tolerance, required uptime, change frequency, staff skill profile, and exit complexity. Assign a weight to each dimension based on business impact, then compare cloud-native and hybrid options using a simple 1-5 maturity score. This is less about mathematical precision and more about forcing explicit tradeoffs before procurement contracts are signed.

The example below is intentionally practical rather than theoretical. It recognizes that a cloud-native solution can be the right answer even for regulated workloads if evidence, resilience, and exit planning are built in. Likewise, a hybrid design can be an expensive compromise if it is used to paper over weak application modernization discipline. For a parallel view of how providers should be judged on infrastructure metrics, see data center KPIs for better hosting choices.

2.2 A practical interpretation of the matrix

Cloud-native is usually favored when the workload benefits from rapid change, automated scaling, resilient managed services, and geographically distributed delivery. It tends to win for new digital products, analytics platforms, AI-assisted services, and customer-facing apps that need a fast feedback loop. Hybrid cloud tends to win when the organization is carrying a large legacy estate, has strict control requirements, or must preserve specialized hardware and network adjacency. In other words, cloud-native is a better default for innovation velocity, while hybrid is often a better default for bounded risk.

Procurement should not stop at sticker price. The real question is whether the operating model includes staffing, migration, observability, security tooling, backup, testing, and the contract terms that govern exit. If you need a lens on buying decisions and contracts, our guide to pricing and contract lifecycle for SaaS vendors on federal schedules shows how service terms shape long-term economics. That same discipline should be applied to cloud infrastructure agreements.

2.3 When the matrix points to a mixed answer

In many enterprises, the answer is not “cloud-native or hybrid,” but “both, intentionally.” A common pattern is to keep systems of record in tightly controlled environments while building customer-facing or analytics layers in cloud-native services. Another pattern is to run regulated transaction processing in a private or dedicated zone while using cloud-native data pipelines for anonymized reporting. This approach lowers risk while preserving a path to modern architecture.

Used well, hybrid becomes a migration strategy rather than a permanent compromise. Used poorly, it becomes a zombie architecture with duplicated controls, fragmented data, and unclear accountability. That distinction is important because hybrid cloud has a habit of growing into complexity if no team is responsible for its end state. For teams designing enterprise-wide domains, our article on subdomains and local domains for enterprise flex spaces is a helpful analogy for managing boundaries cleanly.

3. Cloud-native: where it wins and where it can fail

3.1 Strengths: speed, elasticity, and managed controls

Cloud-native platforms shine when regulated organizations need to launch quickly without building every operational layer themselves. Managed databases, object storage, serverless compute, policy engines, and infrastructure-as-code can dramatically reduce lead time. For a healthcare startup launching a new telehealth or imaging workflow, that speed can be the difference between validating the clinical product and spending a year assembling infrastructure. Cloud-native also improves consistency because controls can be encoded and replicated across environments.

That is why the medical storage market is seeing sustained cloud-native adoption. The source material highlights strong growth in cloud-based storage and hybrid storage architectures, driven by volume growth and AI support needs. For regulated workloads, the key advantage is not just scale, but the ability to build repeatable controls into the platform from day one. If you are also exploring how to authenticate users and reduce impersonation risk, our guide on identity management best practices complements this model well.

3.2 Weaknesses: hidden coupling and service sprawl

Cloud-native designs can introduce dependency sprawl. Teams adopt managed services because they are convenient, then discover that portability is low and migration paths are vague. A design that uses proprietary queues, event buses, data warehouses, and IAM patterns can be extremely effective—until a regulator, internal policy, or merger activity requires relocation. The more deeply you depend on provider-specific primitives, the more you must compensate with contract review, data export design, and tested exit tooling.

Cloud-native can also fail when operational discipline is weak. If logs are not centralized, tags are inconsistent, or infrastructure definitions are not version-controlled, the organization gets the worst of both worlds: complexity without control. Teams that want cloud-native but are still building their observability backbone should study how to define the right signals using metrics and observability frameworks. Control without observability is theater.

3.3 Best-fit examples

Cloud-native is often ideal for a regulated digital front door: appointment booking, customer onboarding, fraud monitoring, or claims status services. It is also a strong fit for analytics environments where data is de-identified or tokenized before processing. In finance, it suits non-core experiences like customer portals, machine learning feature stores, and risk dashboards that consume—not originate—book-of-record transactions. These are the places where responsiveness and elasticity create outsized value.

But cloud-native should be approached carefully for systems that directly create regulated records of truth, especially where the jurisdictional or evidentiary bar is high. In those cases, even if the cloud provider is compliant, the enterprise may still need tighter retention and change control than a fully managed service comfortably supports. Teams should evaluate whether they are buying a platform or a problem they will later need to unpick.

4. Hybrid cloud: where it wins and where it becomes expensive

4.1 Strengths: sovereignty, continuity, and controlled modernization

Hybrid cloud is often the most pragmatic choice when data residency, sovereignty, and legacy integration are first-order requirements. It gives regulated enterprises a way to modernize one layer at a time without forcing a risky big-bang migration. In healthcare, that might mean keeping PHI inside a private environment while shifting analytics, dev/test, or patient engagement to cloud-native services. In finance, it may mean keeping core transaction engines in a tightly managed private footprint while moving reporting, machine learning, or digital channels to the cloud.

This staged pattern is especially useful when the business cannot tolerate major change windows. It lowers the blast radius of migration and allows teams to prove controls incrementally. That matters in regulated environments because a successful modernization effort is often less about the final target architecture than about whether the organization can continuously demonstrate compliance throughout the transition. For organizations managing external stakeholders, our guide on governance cycles and advocacy timelines offers a useful model for sequencing communication and control.

4.2 Weaknesses: duplication and slow drift

Hybrid cloud can be operationally expensive because it often duplicates identity, monitoring, backup, and security processes across environments. That duplication is not just a staffing issue; it also increases the chance that policy drift will create audit findings or incident response confusion. Every additional boundary between environments raises the cost of troubleshooting and the probability of configuration mismatch. In practice, hybrid is not “half as hard” as cloud-native—it can be harder if the control plane is poorly designed.

Hybrid designs also invite inaction. Teams can keep justifying the old environment because the new one is difficult to complete, and that can lead to a permanent half-modern state. To avoid this, a hybrid program needs a clear migration exit criterion: which workloads will remain, which will move, and which will be retired. Otherwise, the organization pays for two worlds and gets the benefits of neither.

4.3 Best-fit examples

Hybrid is often best for core banking platforms, healthcare imaging archives, and clinical systems that depend on specialized networking or hardware. It is also a good fit where regional rules require some data to remain in-country while other workloads can be placed in shared cloud regions. In finance, hybrid is often the safest route when auditors, regulators, or counterparties expect preexisting controls and a strong on-prem evidence trail. In healthcare, it is attractive when EHR integrations, medical devices, or data sovereignty concerns make the risk of a full move too high.

That said, hybrid is not a shield against modernization requirements. If your vendor or your internal platform team cannot show a plan for interoperability, backup, and continuity across the boundary, the environment becomes fragile. For a practical analogy in another domain, see what platform dependency means for data and features; the lesson is the same: integration convenience can hide architectural dependence.

5. Migration strategy: choosing the route, not just the destination

5.1 The safest migration pattern for regulated estates

The best migration strategy is rarely lift-and-shift for the entire estate. For regulated workloads, a safer model is classify, segment, refactor, and then relocate. Begin by identifying which datasets are restricted, which are sensitive but portable, and which are effectively non-regulated. Then split the application into layers: edge, identity, workflow, data, and archival. This gives you a controlled sequence in which the least risky components move first, while the most sensitive systems stay protected until controls are proven.

That sequencing also creates a more honest TCO picture. If you try to move a deeply entangled workload as-is, you often pay twice: once for migration effort and again for post-migration rework. Teams evaluating this path should treat the migration budget as an architecture expense, not just an implementation cost. For a good example of how infrastructure choices affect long-term operating expense, review long-term document management system costs.

5.2 Anti-patterns to avoid

The most common anti-pattern is the “hybrid forever” plan. It sounds flexible, but without milestones it simply preserves uncertainty. Another anti-pattern is moving regulated data to cloud-native while leaving identity, logging, and key management behind in disconnected systems. That creates a compliance story that is technically possible but operationally fragile. A third anti-pattern is assuming that replication equals resilience; if both sides of a hybrid architecture share the same operational assumptions, they may fail together under stress.

A better approach is to define exit criteria at each stage. For example, move test and non-prod environments first, then reporting, then customer-facing but non-transactional services, then selected regulated data flows, and only finally the most sensitive records. Each stage should include a rollback plan, a compliance checkpoint, and a cost comparison. Procurement teams should insist on these checkpoints before signing long-term commitments because that is where vendor lock-in often starts to accumulate.

5.3 Case example: healthcare modernization

Consider a hospital network that wants to modernize imaging workflows. The archive remains on-prem or in a private cloud because of residency, latency, and control needs, but metadata indexing and physician collaboration tools move to cloud-native services. The result is better user experience, faster search, and lower infrastructure bottlenecks without putting the entire archive at risk. If clinical AI is later approved, de-identified subsets can be processed in cloud-native pipelines while the source data remains protected in the core system.

This pattern fits the market signals from the U.S. medical enterprise storage report, which points to increasing demand for cloud-native storage and hybrid architectures. The lesson is not that cloud replaces on-prem; it is that regulated healthcare is becoming a layered architecture where each layer has a different control profile. Teams that understand this can modernize incrementally instead of waiting for a perfect platform that never arrives.

6. Risk assessment: the controls that actually matter

6.1 The core risk domains

Whether you choose cloud-native or hybrid, risk assessment should focus on a handful of practical domains: data classification, encryption and key ownership, identity and access management, logging and evidence retention, resilience, backup/restore, portability, and contractual controls. If you skip any of these, you do not have an architecture decision—you have an assumption. In regulated environments, assumptions are expensive because they show up later as audit gaps or incident surprises.

Risk assessment should also be continuous, not one-time. Cloud-native services change quickly, and hybrid environments often drift because teams manage them differently. A quarterly review is often the minimum acceptable cadence for reconciling configuration, access, and contract terms. If your organization needs a template for evaluating operational readiness, our guide on hosting KPIs can be adapted into an architecture control checklist.

6.2 Data residency and key management

Data residency is often the deciding factor in regulated workloads because it affects legal exposure, latency, and sovereignty. Cloud-native can satisfy residency requirements if the provider offers suitable regions, replication controls, and administrative boundaries. But residency is not just “where the bits sit.” It includes where backups go, where logs are stored, where support personnel can access metadata, and which jurisdictions govern dispute resolution. Procurement teams need contract language that reflects these nuances.

Key management is equally important. If the provider holds the keys, your control posture may be too weak for certain regulated workloads. Bring-your-own-key or customer-managed key models can reduce risk, but they also increase operational burden and incident complexity. The right choice depends on whether the organization can reliably manage key rotation, recovery, escrow, and separation of duties. A design that looks strong on paper can still fail if key procedures are not practiced.

6.3 Vendor lock-in and exit readiness

Vendor lock-in is often described as a licensing problem, but in architecture it is usually an operability problem. The deeper your workload embeds provider-specific networking, storage semantics, IAM, and managed databases, the more expensive exit becomes. That does not mean avoiding managed services entirely; it means intentionally classifying which services are acceptable to couple and which must remain portable. For highly regulated systems, the most valuable lock-in question is not “can we leave?” but “how long would it take, and what evidence would we need to reproduce elsewhere?”

Teams that are serious about exit readiness should maintain data export tests, schema documentation, IaC modules, dependency maps, and recovery runbooks. They should also model a provider failure or contract termination scenario before signing the contract. If your procurement process is mature, you may find the same discipline in contract lifecycle analysis used for SaaS procurement. That kind of rigor is what keeps vendor lock-in from becoming a surprise.

7. Finance example: trading agility against control

7.1 A conservative baseline for financial services

In finance, the default posture is usually cautious because the cost of a control failure can include regulatory scrutiny, customer trust erosion, and direct financial loss. For core transaction processing, many institutions keep the highest-risk systems in a private or tightly governed hybrid environment. That allows them to preserve stable control over journaling, audit trails, and change approval while still modernizing edge experiences. Cloud-native is often introduced first in lower-risk layers such as internal analytics, customer notifications, and fraud investigation workflows.

This is the essence of a hybrid cloud migration strategy: not rejecting cloud-native, but sequencing it around institutional risk. Teams can adopt managed services where they reduce cycle time and operational burden, while keeping book-of-record processes under stricter control. Done well, that improves time-to-market without creating systemic dependence on a single provider. Done poorly, it creates a split brain between modern and legacy teams that neither side can fully govern.

7.2 Where cloud-native can be a strategic win

Financial institutions can gain substantial value by moving analytics and product experimentation to cloud-native platforms. Risk models, customer segmentation, and digital onboarding tools benefit from elastic scale and faster iteration. These are excellent candidates for immutable infrastructure, policy-as-code, and automation-heavy deployment pipelines. The advantage is especially strong when the business wants short feedback loops, A/B testing, or seasonal elasticity.

Even here, the governance model matters. You need controls for PII masking, model lineage, and change approvals. Cloud-native accelerates experimentation, but it does not remove the responsibility to show why a model is valid and how data is protected. If your team is evaluating AI-heavy workflows, our article on observability for AI operating models helps frame the measurement side of the problem. For regulated finance, this becomes part of model risk management, not optional tooling.

7.3 How procurement should frame TCO in finance

In finance, TCO should include compliance engineering, audit support, retained staff, test environments, network egress, backup, key management, and exit costs. Focusing only on instance pricing or storage rates hides the real economics. A cloud-native architecture may look more expensive in unit costs but cheaper overall if it compresses release cycles and eliminates duplicated operations. A hybrid architecture may look safer initially but become costly if it requires parallel environments, specialized hardware refreshes, and manual controls.

Procurement teams should ask for a five-year TCO model with explicit migration assumptions, not just a one-year rate card. They should also test the model against a “provider change” scenario. If the answer changes materially when you replace one service with a similar alternative, you have found a lock-in hotspot. That is not necessarily a deal-breaker, but it should be visible before commitment.

8. Healthcare example: balancing patient data, AI, and residency

8.1 The healthcare control problem

Healthcare organizations increasingly need to support EHR growth, medical imaging, genomics, and AI-enabled diagnostics. The source market data points to strong expansion in cloud-based and hybrid storage solutions, which is consistent with the reality that healthcare workloads have highly variable sensitivity and growth patterns. A single architecture rarely suits all data classes. Patient data, research datasets, and operations telemetry often have different retention and residency obligations, and they should not be forced into one operational model.

Cloud-native can be excellent for patient engagement apps, remote monitoring, and de-identified analytics. Hybrid is often preferable for archive systems, clinical integration buses, and workloads where local processing still matters. The important part is to keep control boundaries explicit. If a service touches PHI, the security design, logging, and contracts should be stronger than those used for ordinary enterprise SaaS.

8.2 A practical split architecture

A useful healthcare pattern is to keep clinical records and source imaging data in a tightly managed core, while using cloud-native services for search, analytics, and non-sensitive workflow orchestration. This lets clinicians access richer experiences without moving the most sensitive data more broadly than necessary. Anonymized or tokenized data can feed machine learning pipelines, which reduces risk while still enabling innovation. In many cases this is the shortest route to useful AI without crossing residency or governance lines.

If you need to think about the compliance implications of identity and linked services, revisit platform dependency and data exposure and compare it with your own third-party risk inventory. The point is not that every external service is dangerous; it is that any service holding regulated data must be judged through a residency, access, and contract lens. That discipline is especially important when clinical data starts flowing through AI-assisted systems.

8.3 What healthcare procurement should ask vendors

Healthcare procurement teams should ask vendors to prove where data resides, how backups are handled, how staff access is logged, and how encryption keys are controlled. They should also require clarity on incident response and data export formats. If the vendor cannot provide a clean exit path, the team should treat that as a future operational risk, not a minor contract detail. These questions are especially important when procurement is under pressure to move quickly because the most expensive mistakes are usually the ones made in haste.

One useful test is the “audit Friday” test: if the regulator asked for evidence tomorrow, could the team produce it without manual heroics? If not, then the architecture is not yet mature enough for the workload in question. Cloud-native can still be the target, but the implementation needs more rigor before it becomes a safe default.

9. Procurement and governance: making the decision defensible

9.1 The questions procurement must force into the open

Procurement teams should not behave like order takers. They need to ensure that the business owner, architect, security team, and legal team agree on the workload’s sensitivity, retention, residency, and exit obligations. Ask whether the application will create, transform, or simply display regulated data. Ask whether the provider’s standard region and support model are sufficient, and whether the contract permits the enterprise to prove compliance without relying on undocumented exceptions. These questions determine whether the chosen architecture is sustainable.

When evaluating cloud-native versus hybrid, procurement should require a written rationale for the selected control model. That rationale should include known risks, compensating controls, and triggers for reevaluation. It should also be paired with a vendor comparison that includes not only rates but portability and support terms. For teams used to evaluating service terms, the contract thinking in SaaS pricing and contract lifecycle provides a useful procurement template.

9.2 TCO is not just a finance metric

In regulated architecture, TCO is a governance metric because it determines how much process the organization can afford to sustain. If the “cheaper” environment requires too much manual control, then the savings may simply be a transfer of burden to internal teams. Conversely, an expensive managed service can still lower overall risk and operational drag if it meaningfully reduces headcount load and incident exposure. Good TCO models include both direct spend and the hidden cost of compliance evidence, downtime, and rework.

Ask finance teams to model three scenarios: conservative hybrid, cloud-native target, and failure-case hybrid with duplicated controls. The third scenario is the one most often overlooked, but it is the one that reveals whether hybrid complexity is truly manageable. This is a practical way to turn abstract architecture preferences into something procurement can approve, reject, or conditionally accept.

9.3 Governance artifacts that make auditors and executives happy

To make the decision defensible, maintain a one-page decision record, a risk register, a data-flow diagram, and an exit plan. These documents should explain why the workload is in cloud-native, hybrid, or a split model, and what would cause that choice to change. This paper trail matters because regulated enterprises need continuity of reasoning, not just continuity of technology. If the team changes, the decision should still make sense.

For broader operational consistency, it helps to align with structured change communication practices. Our article on governance cycles can serve as a model for timing approvals, and our guidance on domain structure and regional control helps make boundary decisions more legible to stakeholders. Clarity is a control in itself.

10. A practical recommendation model by workload type

10.1 Use cloud-native when...

Choose cloud-native when the workload is new, modular, elastic, and not tightly coupled to a legacy control stack. It is a strong choice when you can encode compliance requirements in automation, when data can be tokenized or regionally scoped, and when you need rapid iteration. It is also preferred when the service is customer-facing and the business impact of fast delivery outweighs the benefit of local control. If the team can explain the exit path and the controls, cloud-native is often the best long-term option.

10.2 Use hybrid cloud when...

Choose hybrid cloud when data residency is strict, integration with legacy systems is unavoidable, or the regulatory evidence model is already anchored in your private environment. It is also sensible when the organization needs to migrate in phases while preserving service continuity and reducing the blast radius of change. Hybrid is the right answer if the most sensitive data or processes must stay under tighter operational governance for the foreseeable future. It buys time, but that time must be used deliberately.

10.3 Use a split model when...

Use a split model when the application has distinct zones of sensitivity or function. For example, keep the record system controlled and local, while moving presentation, analytics, or collaboration layers to cloud-native services. This pattern is often the highest-value answer for regulated industries because it lets teams modernize without forcing every component into the same risk bucket. In many cases, this is the most realistic compromise between agility and control.

Pro Tip: If a workload is both highly regulated and highly changeable, the correct question is rarely “cloud or hybrid?” It is “which parts should be isolated, which should be automated, and which should remain portable?”

Conclusion: the best architecture is the one you can govern, prove, and evolve

For regulated workloads, cloud-native and hybrid cloud are not ideological opposites. They are tools for different phases of control maturity, modernization, and business risk. Cloud-native tends to win when agility, scale, and automation matter most. Hybrid tends to win when evidence, locality, and legacy continuity are non-negotiable. The winning strategy is usually not choosing one forever, but choosing a sequence that moves the organization toward better control and lower friction over time.

If you are building your decision package now, start with workload classification, then run the decision matrix, then model migration paths and exit costs. Make sure procurement, security, legal, and architecture all review the same assumptions. And remember that the cheapest environment is often the one that prevents rework, limits lock-in, and can survive an audit without heroics. For more guidance on evaluating control surfaces and hosting choices, revisit our article on infrastructure KPIs, and for governance-adjacent operational planning see observability for AI operating models.

FAQ

Related Reading

• Competing with AI: Navigating the Legal Tech Landscape Post-Acquisition - Useful for understanding how platform change affects governed workflows.
• Measure What Matters: Building Metrics and Observability for 'AI as an Operating Model' - Helps teams design evidence-rich operations.
• Pricing and Contract Lifecycle for SaaS E-Sign Vendors on Federal Schedules - A procurement lens you can apply to cloud contracts.
• From Data Center KPIs to Better Hosting Choices: What Marketing Teams Should Ask Providers - A practical framework for vendor evaluation.
• Local Presence, Global Brand: Structuring Subdomains and Local Domains for Enterprise Flex Spaces - Helpful for thinking about regional boundaries and control.