You Don’t Need to Self-Host Everything

A Practical Case for Keeping Sensitive Data In-House While Running the Edge in Multiple Clouds

Cloud platforms are extraordinarily useful. But “put everything in one cloud” should no longer be treated as the default answer.

Recent large-scale outages have shown how failures in DNS, authorization, configuration propagation, and private connectivity can take down systems that are otherwise distributed across zones or regions. Security incidents have also shown that a cloud platform itself does not need to be breached: stolen credentials and an over-concentrated data estate may be enough.

This article proposes a selective form of self-hosting:

Keep credentials, personally identifiable information (PII), and authoritative data inside a boundary you control. Put the public-facing portal in the cloud—and, when availability justifies the cost, in more than one cloud.

This is not a call to abandon the cloud or rebuild the server rooms of the past. It is a way to decide what should be entrusted to a provider and what should remain under your direct control.

Why I Started Thinking About This

My interest in multi-cloud architecture did not begin as an abstract exercise.

An AWS VPC endpoint incident made one of our portals unavailable. Other large services were affected during the same period. A dependency that looked like internal cloud plumbing had become a single failure domain for the entire application.

The lesson was not simply that “AWS can fail.” Every infrastructure provider—and every private data center—can fail. The more useful lesson was this:

Availability boundaries do not necessarily follow the boxes in an architecture diagram.

An application may span several availability zones and still depend on one regional control plane, DNS system, identity provider, edge configuration, or private connectivity path.

That experience led me toward multi-cloud delivery. It also led to a more important conclusion: not every organization needs to implement the final multi-cloud design on day one.

For many systems, separating sensitive data from the public application is already a meaningful destination.

What Recent Incidents Tell Us

Several major incidents in 2024 and 2025 shared a pattern: the initiating failure was not merely a broken server. It was a failure in automation, authorization, DNS, or configuration distribution.

Three conclusions follow:

1. Control-plane and connectivity failures can be more consequential than individual hardware failures.
2. Multi-AZ—and sometimes multi-region—redundancy inside one provider does not cover every failure mode.
3. Recovery may take hours rather than minutes.

Managed infrastructure removes a great deal of operational work. It does not remove concentration risk.

Security Is Also a Concentration Problem

The 2024 campaign against Snowflake customer environments is an important example. According to Mandiant, attackers used credentials obtained outside Snowflake and targeted customer instances that often lacked enforced multi-factor authentication. The core Snowflake platform did not need to contain a vulnerability for large datasets to be exfiltrated.

The Change Healthcare incident offers a related lesson. Remote access without MFA was identified as an important entry point, and the disruption spread through a system on which a large part of US healthcare depended.

These incidents do not prove that on-premises systems are inherently safer. A poorly maintained private environment can be much less secure than a well-operated cloud service.

The real questions are:

• Where is the authoritative copy of the data?
• Who controls the identity boundary?
• How much data can one valid credential reach?
• What remains available when the identity provider or network link fails?
• Can sensitive fields be removed before data crosses the boundary?

Selective self-hosting changes the ownership and size of the trust boundary. Its value comes from deliberate separation, not from the physical location of a server alone.

The Architecture: A Data-Sovereignty Boundary

The design has three layers:

Internet / Users
        |
        v
Neutral dual-provider traffic management
        |
        +--------------------+
        |                    |
   Cloud A (GCP)        Cloud B (AWS)
   non-sensitive        non-sensitive
        |                    |
        +------ redundant encrypted links ------+
                             |
                       On-premises
        credentials / PII / authoritative data

The cloud is responsible for presentation, edge protection, and elastic delivery. The self-hosted environment is responsible for identity, sensitive records, authoritative writes, and sanitization.

Inside the controlled boundary

The operating rule is:

Credentials, PII, and master data do not leave the controlled boundary.

Cloud systems receive short-lived tokens, reference identifiers, and explicitly allowlisted results. PII should not be placed in JWT claims or application logs. Sanitization is a product requirement, not a cosmetic filter added at the end.

In each cloud

Both stacks contain only non-sensitive data. If availability requirements justify it, they run active-active and either stack is sized to accept all traffic.

The two cloud deployments are useful only if their shared dependencies are also examined. DNS, container registries, observability, payment services, secrets, and deployment systems can quietly reintroduce a single provider dependency.

Why This Requires Less Hardware Than Traditional On-Premises IT

“Move data back on-premises” often evokes an entire legacy data center. That is not the proposal.

The public UI, WAF, BFF, and elastic workloads remain in the cloud. The local footprint is limited to the sensitive path: identity, keys, authoritative data, sanitization, and audit.

The exact size depends on workload, RTO, RPO, retention, and compliance requirements. “A few nodes” is not a universal sizing rule. It is an observation that a narrowly defined trust boundary can be dramatically smaller than an entire enterprise application estate.

Power, cooling, physical security, backups, spare parts, independent network paths, monitoring, and tested recovery procedures still matter. The hardware may be smaller; the operational responsibility is not optional.

The Most Important Trade-Offs

1. The local site can become the new single point of failure

If every login and read crosses an encrypted link to one on-premises site, losing that site stalls the portal even when both cloud frontends are healthy.

A production design must define its degraded mode:

• Can an existing session continue while new logins are unavailable?
• Can cloud services validate already-issued JWTs from cached signing keys?
• Is a read-only, sanitized cache allowed?
• How stale may that cache become?
• Is the controlled boundary itself replicated to a second physical site?

These decisions should be driven by explicit RTO and RPO targets.

2. The identity provider and reader set the throughput ceiling

Scaling cloud frontends does not help if all requests converge on a local identity service or Sanitized Reader. Capacity tests must include the links and the services behind them.

3. Sanitization is the substance of the sovereignty claim

An allowlist should define exactly which fields may cross the boundary. Joins, aggregates, small cohorts, and stable identifiers can make supposedly anonymous data identifiable again.

4. Caching improves availability but weakens the boundary

A short-lived cache of non-sensitive results may be a reasonable compromise. Replicating what is effectively the master dataset into both clouds is not the same architecture.

5. Multi-cloud has a real operational cost

Active-active delivery requires:

• provider-neutral or dual-provider traffic management;
• both stacks to remain hot and tested;
• each stack to handle 100% of production traffic;
• independent deployment and rollback paths;
• regular failure exercises;
• removal of hidden single-cloud dependencies.

Multi-cloud should be reserved for workloads whose availability requirements justify that cost. Even AWS’s own prescriptive guidance recommends using it when a single provider cannot meet the actual technical or business requirement—not as a default badge of maturity.

A Three-Phase Adoption Path

Trying to build the full diagram at once is a good way to make the project too expensive to approve.

Phase 1 — Separate the data

• Classify credentials, PII, master data, and non-sensitive fields.
• Remove sensitive records from cloud databases where the threat model requires it.
• Replace embedded PII with reference identifiers.
• Remove personal information from JWTs and logs.
• Document and test the allowlist for data that may leave the boundary.

For organizations primarily concerned with data control, auditability, or breach radius, Phase 1 can be the destination.

Phase 2 — Bring the identity authority under your control

• Keep the authoritative credentials and sensitive identity attributes inside the boundary.
• Require MFA or passkeys by default.
• Keep sensitive authentication audit records locally.
• Design session validation and degraded behavior before migration.

This phase addresses identity concentration directly, but it also creates a service that must be operated and recovered exceptionally well.

Phase 3 — Add a second cloud for availability

• Replicate the stateless portal and BFF to another provider.
• Introduce neutral traffic management or a tested client-side fallback.
• Size and test each cloud independently.
• Audit registries, secrets, monitoring, payment systems, and deployment pipelines for shared failure domains.

This phase is for systems that must remain accessible through a provider, region, or private-connectivity failure.

Phase 1 Is Not Merely a Prelude

Architecture diagrams encourage us to admire the completed system. Real projects should stop where the business problem has been solved.

Treating Phase 1 as a complete deliverable makes selective self-hosting accessible to many more organizations. It creates a documented data boundary, reduces unnecessary copies, and prepares the system for later changes without committing immediately to multi-cloud operations.

The point is not to self-host more. It is to self-host the right things.

Conclusion

The lesson from recent outages is not that cloud platforms are immature. It is that very large systems inevitably contain shared control planes and hidden concentration points.

The lesson from recent security incidents is not that private hardware is magically safe. It is that centralized data combined with valid stolen credentials can create an enormous blast radius.

A practical response is neither “cloud everything” nor “bring everything home”:

Keep the authoritative sensitive path under a boundary you control, while using cloud platforms for public delivery and elasticity.

Start by classifying and separating the data. If that solves the problem, stop there with confidence. Add self-hosted identity when control of authentication justifies the responsibility. Add multi-cloud delivery only when the availability requirement justifies the cost.

Cloud is still part of the answer. It is simply no longer the place where every answer must live.

References

• Google Cloud Service Health — June 2025 incident
• Summary of the Amazon DynamoDB Service Disruption in us-east-1 — AWS
• Azure Front Door: implementing lessons learned following October outages — Microsoft
• Cloudflare outage on November 18, 2025 — Cloudflare
• UNC5537 Targets Snowflake Customer Instances — Mandiant / Google Cloud
• Written testimony on weak identity protections in the healthcare sector — US Congress
• Tiered hybrid pattern — Google Cloud Architecture Center
• Data Residency and Hybrid Cloud Lens — AWS Well-Architected Framework
• Strategy for single, hybrid, and multicloud environments — AWS Prescriptive Guidance