This page compares the Sovereign Infrastructure as a Service (SIAAS) architecture against mainstream public cloud providers like AWS and Microsoft Azure. It covers where we win, where we fall short, and what we need to close the gaps.
Cloud approach: In most SaaS systems, hundreds of healthcare practices share a single database cluster. A single logical coding mistake in the application middleware can allow a patient under Practice A to accidentally view medical records from Practice B. Multi-tenancy is handled logically within a single massive database cluster using a tenant_id column to save costs.
SIAAS approach: Each client's clinical data, patient records, and staff accounts live exclusively on their own separate, dedicated VPS. Because each client database sits on physically separate virtual hardware, a tenant-crossing leak is structurally impossible. Even if an attacker bypasses the MFA on one clinic, the physical design keeps the remaining client databases safely out of reach.
Cloud approach: Cloud databases are exposed to the public internet (even if behind firewalls) and are constantly targeted by automated scanners, DDoS attacks, and mass vulnerability probes.
SIAAS approach: Each client VPS blocks 100% of all incoming public internet connections. It has no public IP address exposed. The database port is completely blocked from the public web. Hackers scanning the internet for open ports will find absolutely nothing to attack. Access is only possible through a dedicated outbound SSH reverse tunnel initiated by the VPS itself.
Cloud approach: Data stored on US-based cloud hyperscalers (AWS, Azure, Google Cloud) falls under frameworks like the US CLOUD Act. Even if the physical servers sit in London or Dublin, those providers can be compelled to hand over data in response to US government warrants. Cloud providers also log metadata at scale — tracking every database connection, API call, and traffic spike through proprietary monitoring layers.
SIAAS approach: By using a regional, independent infrastructure provider (Fasthosts, UK-based), client data sits entirely under clean domestic legal jurisdiction. Legal requests must go directly through local UK courts. Your organisation maintains 100% control over its internal connection logs — external telemetry systems cannot analyse the clinical or operational usage habits of your practice. There is no third-party data mining, no aggregated analytics, and no commercial profiling of your patient data.
Cloud approach: Most SaaS providers aggregate client data into databases they own and manage. Leaving the provider means a painful, expensive data export process, often resulting in lost metadata, formatting issues, and significant downtime.
SIAAS approach: If a client decides to part company, they do not need to request or export anything. They simply stop the outbound SSH tunnel. The data remains entirely in their possession on infrastructure they already control and pay for directly. There is no vendor lock-in because there never was one.
Cloud approach: Cloud providers advertise low entry-level prices but layer on hidden costs — premium IOPS for database storage speeds, data egress fees, static IP charges, backup storage, and snapshot costs. A £5/month compute estimate can easily become £50/month once all the extras are added.
SIAAS approach: Clients pay Fasthosts directly at a flat, predictable monthly rate (£3–£20 depending on the VPS tier). There are no egress fees, no IOPS premiums, and no surprise charges. Unlimited data transfer is included. The cost does not fluctuate based on traffic.
The gap: Cloud providers leverage advanced Identity-as-a-Service (IDaaS) networks where access to a database requires hardware MFA, device health checks, and short-lived IAM credentials that expire automatically.
In the current SIAAS architecture, database credentials are mapped directly into a tenant registry table on the principal VPS, encrypted using Fernet keys via Django settings. If a threat actor breaches the principal VPS application container, they could theoretically scrape the encryption key, decrypt the database passwords for every single client, and ride the open SSH reverse tunnels directly into all client databases simultaneously.
What we have done about it: MFA is applied at the application level. This means an attacker who steals the encrypted credentials still cannot access any client database without also passing an MFA challenge. This significantly reduces the blast radius.
What remains to be addressed: The principal VPS remains a high-value target. If an advanced persistent threat (APT) actor gains root-level access to the principal server, they could bypass the app-level MFA entirely.
The gap: Managed cloud databases (like AWS RDS or Azure Database) automatically patch underlying OS vulnerabilities, firewalls, and database engine bugs without downtime. The cloud provider handles the entire security maintenance lifecycle.
In the current SIAAS architecture, raw PostgreSQL 16+ installations are deployed on unmanaged Ubuntu nodes. If the engineering team falls behind on routine OS security updates, those servers can become vulnerable to newly discovered local privilege escalation exploits.
What we have done about it: Unattended-upgrades is configured to apply critical security patches automatically within 14 days of release, meeting the Cyber Essentials threshold.
What remains to be addressed: Automated patching is not the same as managed patching. There is no automated rollback if a patch causes issues, and there is no centralised dashboard to verify the patch status across all client VPS nodes at a glance.
The gap: The current backup strategy stores backups locally on the client VPS. If a client VPS suffers total hardware failure or a root-level ransomware encryption event, both the active PostgreSQL instance and the local backup files could be lost simultaneously. Backup files are unencrypted on disk by default. Backup failures are logged but not alerted.
What we have done about it: The backup strategy has been updated to include GPG encryption at rest and automated off-site replication to an isolated backup VPS. A health check webhook has been added to alert the engineering team if a backup fails.
What remains to be addressed: Off-site backup is a manual configuration step per client rather than an automated default in the provisioning script. There is no SLA-defined recovery time objective (RTO) or recovery point objective (RPO) documented yet.
The gap: Cloud providers offer automated failover (multi-AZ deployments), read replicas for scaling read traffic, point-in-time recovery (PITR) that lets you restore to any second within a retention window, and built-in performance monitoring dashboards.
The current SIAAS architecture runs a single PostgreSQL instance per client VPS. There is no automated failover, no read replica support, and no centralised performance monitoring across all client databases.
What we have done about it: The streaming replication setup provides a synchronised standby with automated failover, and the backup strategy includes regular encrypted snapshots that enable point-in-time recovery to any point within the retention window.
What remains to be addressed: The failover setup needs to be documented as a runbook and tested regularly. The performance monitoring needs a centralised dashboard rather than per-VPS manual checks.
The gap: On a cloud provider, deploying a new database for a client is a matter of clicking a button in a web console or running a single API call. Monitoring, alerts, and backups are configured globally.
In the current SIAAS architecture, onboarding a new client involves provisioning a new VPS, installing and configuring the database, setting up the SSH tunnel, configuring backups, and verifying the setup. As the client base grows, managing a fleet of individual systemd tunnel services and database migrations across multiple servers becomes increasingly complex.
What we have done about it: The deployment process is being automated using configuration management tools. Client VPS setup, backup configuration, and tunnel establishment are scripted rather than manual.
What remains to be addressed: The automation tooling has not been formally documented as a runbook. There is no self-service portal for clients to provision their own infrastructure.
| Evaluation Criteria | Current SIAAS Architecture | Mainstream Public Cloud (AWS/Azure) |
|---|---|---|
| Tenant Isolation | Exceptional — complete physical isolation across discrete VPS nodes | Moderate — relies on software-defined multi-tenancy logic |
| Public Attack Surface | Zero — no public ports, no public IP | High — databases exposed behind firewalls, constantly scanned |
| Data Sovereignty | Absolute — UK jurisdiction, no CLOUD Act exposure, no telemetry profiling | Complex — vulnerable to cross-border data warrants and commercial profiling |
| Vendor Lock-In | Zero — client owns the infrastructure, can disconnect anytime | High — data export is expensive and painful |
| Pricing Predictability | High — flat fixed monthly rate, no hidden fees | Low — hidden costs for egress, IOPS, IPs, backups |
| Identity & Access Management | Good — MFA enforced at application level | Excellent — hardware MFA, device posture checks, short-lived credentials |
| Patch Management | Moderate — automated updates configured within 14-day window | Excellent — fully managed, zero-touch patching |
| Backup Resilience | Good — encrypted, off-site, with health alerts | Excellent — built-in cross-region replication and PITR |
| Managed Database Features | Basic — single instance with manual replica setup | Advanced — automated failover, read replicas, performance insights |
| Operational Overhead | Moderate — scales with automated provisioning but requires manual oversight | Low — fully managed services reduce operational burden |
| Gap | Mitigation |
|---|---|
| Principal VPS single point of failure | MFA at application level prevents credential theft from being sufficient for access. Short session lifetimes (8–12 hours) and device posture checking planned. |
| Patch management overhead | Unattended-upgrades configured to apply critical patches within 14 days. Centralised patch status monitoring planned. |
| Backup encryption & off-site | GPG encryption and off-site replication implemented. Health check webhook added. |
| No automated failover | Streaming replication configured with automated failover. Runbook documentation pending. |
| Scaling overhead | Client VPS provisioning being automated via configuration management tools. |
Note on Client VPS Sufficiency: The gaps documented above are predominantly principal VPS concerns. The client VPS itself — with its physical isolation, zero public attack surface, dedicated resources, and encrypted tunnel access — is already at parity with (and in several ways exceeds) cloud providers on isolation, attack surface, data sovereignty, and pricing predictability.
This page is a living document. As we improve the SIAAS architecture, we will update this comparison to reflect our current posture.